Assistance debugging a Micrel network driver

Assistance debugging a Micrel network driver

[Greg Huber]

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

Re: Assistance debugging a Micrel network driver

[Jesper Juhl]

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

Re: Assistance debugging a Micrel network driver

[Andi Kleen]

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