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
_______________________________________________
Linux-IrDA mailing list  -  [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda

Reply via email to