Mailing List Archive

Assistance debugging a Micrel network driver
Hello,
I hope this is the right place to request some assistance, my apologizes
if its not.

I'm currently developing a network driver for a new controller chip. The
driver is mostly complete and appears to be working,
with the exception that messages received and sent up the stack appear
to get dropped by a higher layer. Specifically we
are seeing ARP "who is" requests go out, and the response come back
(only 2 nodes on this network), the skb is configured
and the frame is sent up with netif_rx (we haven't started supporting
NAPI yet). The response seems to get dropped somewhere
as another ARP "who is" request is sent. I am using the 2.6.21.5 kernel
(compilied with network debugging turned on) and we
have also tested with the 2.6.17 kernel, all acted the same.

The upper layers obviously work so I'm sure it's something in my driver.

I have turned on as much debugging in the kernel as I could find, but I
get no messages. Could someone please let me know if
there is additional debugging I should consider or if there is a dynamic
way to turn on debugging in L2 and/or L3.

Additionally, if anyone has any idea what might be happening, I would
greatly appreciate any information.

Thank You

Greg

--

Greg Huber
Principal Engineer
Vanteon Corporation
255 Woodcliff Drive, Suite 200
Fairport, NY 14450
Office: (585) 419-9564
Fax: (585) 248-0537
www.vanteon.com <http://www.vanteon.com> - Embedded for Your Future

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Assistance debugging a Micrel network driver [ In reply to ]
On 29/06/07, Greg Huber <ghuber@vanteon.com> wrote:
> Hello,
> I hope this is the right place to request some assistance, my apologizes
> if its not.
>
> I'm currently developing a network driver for a new controller chip. The
> driver is mostly complete and appears to be working,
> with the exception that messages received and sent up the stack appear
> to get dropped by a higher layer. Specifically we
> are seeing ARP "who is" requests go out, and the response come back
> (only 2 nodes on this network), the skb is configured
> and the frame is sent up with netif_rx (we haven't started supporting
> NAPI yet). The response seems to get dropped somewhere
> as another ARP "who is" request is sent. I am using the 2.6.21.5 kernel
> (compilied with network debugging turned on) and we
> have also tested with the 2.6.17 kernel, all acted the same.
>
> The upper layers obviously work so I'm sure it's something in my driver.
>
> I have turned on as much debugging in the kernel as I could find, but I
> get no messages. Could someone please let me know if
> there is additional debugging I should consider or if there is a dynamic
> way to turn on debugging in L2 and/or L3.
>
> Additionally, if anyone has any idea what might be happening, I would
> greatly appreciate any information.
>

You could start by publishing your complete source code. That would
make it a lot more likely that people can help you spot and fix
problems.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Assistance debugging a Micrel network driver [ In reply to ]
Greg Huber <ghuber@vanteon.com> writes:
>
> The upper layers obviously work so I'm sure it's something in my driver.

netstat -s output might give some clue. Most packet drop
points have a counter.

>
> I have turned on as much debugging in the kernel as I could find, but
> I get no messages. Could someone please let me know if
> there is additional debugging I should consider or if there is a
> dynamic way to turn on debugging in L2 and/or L3.

The usual is to just add printks to the kernel source code until you
find where the packet is dropped.

Or perhaps check in __kfree_skb if the skb is coming from your
driver and force a backtrace with show_stack().

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/