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