Re: Re: Occasional panics with 0.2.2 and DWL-122

<[email protected]> Wed, 26 Oct 2005 9:20:46 +0100
Newsgroups gmane.linux.linux-wlan.user
Message-ID <20051026082046.CJQH6564.aamta09-winn.ispmail.ntl.com@smtp.ntlworld.com>
> I had another panic when I booted up this morning. I had configured
> syslog to be the first service started in runlevels 2-5 but that
> evidently isn't early enough. By default FC4 configures it to start
> just after network, presumably in case you're logging remotely. For
> local logging I suppose it could be started any time after / is
> remounted rw, which happens in rc.sysinit . Not sure how that relates
> to the timing of rc1.d etc. Karl, how do you start yours?

I'm on Ubuntu (Debian), so the script dirs are a bit
different, but essentially I started syslog as early
as I sensibly could (in rcS.d, which is probably
equiv to your rc1.d). As you say, you really just need
the disks to be mounted rw and syslog should be able
to start.


> 
> Anyway the following was captured by birolog ;-)
> 
> hcd_submit_urb+0x2de/0x480
> error_code+0x4f/0x54
> skb_under_panic+0x59/0x67
> hfa384x_usbin_rx+0x2b7/0x304 [prism2_usb]
> hfa384x_usbin_rx+0x2c0/0x304 [prism2_usb]
> usb_hcd_giveback_urb+0x21/0x63
> uhci_finish_urb+0x84/0x266 [uhci_hcd]
> uhci_transfer_result+0x23a/0x37f [uhci_hcd]
> uhci_finish_completion+0x44/0x56 [uhci_hcd]
> uhci_scan_schedule+0xb4/0x15e [uhci_hcd]
> ide_dma_intr+0x0/0xb5
> uhci_irq+0x10b/0x6bc [uhci_hcd]
> uhci_hcd_irq+0x22/0x52
> handle_IRQ_event+0x2e/0x5a
> __do_IRQ+0x1c7/0x577
> do_IRQ+0x4a/0x82
> =====================================
> schedule+0x356/0x938
> common_interrupt+0x1a/0x20
> acpi_processor_idle+0x0/0x272
> acpi_processor_idle+0xf0/0x272
> cpu_idle+0x34/0x4c
> start_kernel+0x164/0x1be
> unknown_bootoption+0x0/0x1b6
> 

Good biro work!

It seems ood to me that there are two
hfa384x_usbin_rx lines in the trace.

I'll see if I can find out what skb_under_panic is
all about in the kernel. Perhaps un-recoverable
error condition.

The scenario you have in this trace is when the
prism card sends back a usb message (known as a urb).
This comes in as an interrupt (IRQ), which the usb
sw stack picks up and sends to the prism driver
(hfa384x_usbin_rx). One of the first things this
procedure does is submit a new urb in readiness
for a future communication with the card. Its somewhere
there that things are going wrong.


Karl

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software 
Visit www.ntlworld.com/security for more information