Hi,
To me it sounds like somebody have sent a frame down the IrDA stack, that
is still one somebodies list, or somebody is some how touching the skb next pointer
after it's been passed down the stack. The frame has been queued by IrLAP waiting
for ack, but somebody is changing the list pointer (next) while it's sitting in this
queue.
So when an incomming frame acks this frame, and IrLAP tries to dequeue it, then
it will try to follow that NULL pointer.
Are you sure nobody changes the skb after it's been passed down the stack? Maybe
it's sitting on somebodies list further up, or somebody clears it's struct or
something!?
-- Dag
On Wed, 13 Dec 2000 11:17:31 -0800, you wrote:
> On Wed, Dec 13, 2000 at 10:53:37AM +0100, Christian Gennerat wrote:
> > Jean Tourrilhes a �crit :
> >
> > > Anything that is IrDA related is worth sending. I still don't
> > > understand why your IrDA stack behave differently.
> >
> > Is a Pentium 75 too slow?
>
> Nope, should do fine...
>
> > my last oops (5 occurences) is a looping oops:
> [...]
> > >>EIP; c3058ea5 <[irda]irlap_update_nr_received+4d/130> <=====
> > Trace; c305bb6d <[irda]irlap_state_nrm_s+151/76c>
> > Trace; c3059c71 <[irda]irlap_do_event+65/17c>
> > Trace; c3063ae6 <[irda]async_unwrap_char+2a/34>
> > Trace; c305e184 <[irda]irlap_driver_rcv+2ac/318>
> > Trace; c3075100 <[irda]irda_packet_type+0/14>
>
> This doesn't make sense. You can't have async_unwrap_char at
> this point. You would need something like irlap_recv_XXX_frame to make
> sense.
> Hum... Smell like corruption...
>
> > Code; c3058ea5 <[irda]irlap_update_nr_received+4d/130>
> > 00000000 <_EIP>:
> > Code; c3058ea5 <[irda]irlap_update_nr_received+4d/130> <=====
> > 0: 89 58 04 mov %ebx,0x4(%eax) <=====
> > Code; c3058ea8 <[irda]irlap_update_nr_received+50/130>
> > 3: 89 03 mov %eax,(%ebx)
> > Code; c3058eaa <[irda]irlap_update_nr_received+52/130>
> > 5: c7 02 00 00 00 00 movl $0x0,(%edx)
> > Code; c3058eb0 <[irda]irlap_update_nr_received+58/130>
> > b: c7 42 04 00 00 00 00 movl $0x0,0x4(%edx)
> > Code; c3058eb7 <[irda]irlap_update_nr_received+5f/130>
> > 12: c7 42 00 00 00 00 00 movl $0x0,0x0(%edx)
>
> As far as I can tell, the Oops occur in __skb_dequeue(), which
> is inlined (see include/linux/skbuff.h @ 495), at "next->prev = prev".
> Those skb functions have been thouroughly debugged by Alan
> Cox, and I don't expect a bug lying here. Getting an invalid skb on
> the list is quite difficult.
>
> Therefore, I suspect an internal corruption of the IrDA stack,
> like something copying bytes were it should not or a buffer overrun
> (likely in the previous skb).
> I've seen that happening. Factors that seem to increase the
> probability of getting there are :
> o SMP
> o Compiling IrDA stack static and not modular (don't ask me why)
> o High level of IrDA noise
>
> At this point, I would like to ask Dag if he has any clues...
>
> The second trace is totally space. I can't make sense of it...
>
> Regards,
>
> Jean
>
>
----
Dag Brattli, Mail: [EMAIL PROTECTED]
Senior Systems Engineer Web: http://www.fastsearch.com/
Fast Search & Transfer ASA Phone: +47 776 96 688
P.O. Box 1126 Fax: +47 776 96 689
NO-9261 Troms�, NORWAY Cell: +47 415 72 969 (new)
Try FAST Mobile Search: http://mobile.alltheweb.com/
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
