On Sun, 2 May 2010, Michael Buesch wrote: > The following NULL pointer dereference was triggered by my USB application > on the 2.6.33.2 kernel. > The (Python) application accesses an USB device through libusb (pyusb). > The application sent crap to the device. As this device does not like being > crapped on, it immediately stopped working. It's completely unresponsive after that. > So far no problem, but the kernel possibly(!) noticed the broken device and tried to recover. > I'm not really sure on that, however. Fact is that this oops is a (direct or indirect) > response to a device going wild. > > PowerPC-32 oops attached. > > [701675.857024] usb 3-1: USB disconnect, address 11 > [701680.166866] hub 1-0:1.0: over-current change on port 2 > [701681.383492] usb 4-1: new full speed USB device using ohci_hcd and address 3 > [701681.561185] usb 4-1: too many configurations: 25, using maximum allowed: 8 > [701681.617183] usb 4-1: New USB device found, idVendor=2471, idProduct=0853 > [701681.617193] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 > [707199.443949] Unable to handle kernel paging request for data at address 0x00000008 > [707199.443960] Faulting instruction address: 0xc05d56f4 > [707199.443974] Oops: Kernel access of bad area, sig: 11 [#1] > [707199.443977] PREEMPT PowerMac > [707199.443980] Modules linked in: b43 ssb mac80211 appletouch lp parport md_mod dm_crypt [last unloaded: mac80211] > [707199.443993] NIP: c05d56f4 LR: c05e1104 CTR: c05df670 > [707199.443998] REGS: df8a9d20 TRAP: 0300 Tainted: G W (2.6.33.2) > [707199.444002] MSR: 00009032 <EE,ME,IR,DR> CR: 84442422 XER: 20000000 > [707199.444010] DAR: 00000008, DSISR: 40000000 > [707199.444014] TASK = eb4c5f90[6046] 'python' THREAD: df8a8000 > [707199.444017] GPR00: 00000054 df8a9dd0 eb4c5f90 00000000 00000000 eee67408 c05df6a0 00000000 > [707199.444025] GPR08: c0b97fa8 eee67498 00000000 00000000 00000000 1016fd84 10169518 101294cc > [707199.444033] GPR16: 10160000 00000001 4803b2f0 1033798c 104ee990 ec852c00 40045505 c098522c > [707199.444041] GPR24: ebffe000 eec1b400 ffffff92 00000000 efbc84c4 ebffe050 ec852c00 00000001 > [707199.444058] NIP [c05d56f4] usb_altnum_to_altsetting+0x0/0x48 Can you figure out what statement corresponds to the faulting instruction address, and which pointer is NULL? There has been another report of a similar problem in usb_altnum_to_altsetting(), but so far nobody has managed to figure out the reason for the problem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
