On Thu, 2010-12-23 at 20:29 +0100, Frank Wille wrote: > Unfortunately I cannot tell, because the system reboots now before any > mplayer output is generated. :( > After a reboot I saw in "messages" that the kernel (5.99.41) panicked: > 0xd453fd30: at usb_allocmem+0x40 > 0xd453fd60: at ehci_device_isoc_start+0x244 > 0xd453fdd0: at usbd_transfer+0x78 Particularly interesting because ehci_device_isoc_start doesn't call usb_allocmem - I'm going to assume the compiler inlined ehci_alloc_itd. What normally occurs is ehci_device_isoc_start allocates itd's for a transfer outside of interrupt context. When the transfer completes, they get put on a free queue, then immediately taken off again when the usb transfer gets rescheduled. Normally that means no new memory gets allocated when ehci_device_isoc_start follows ehci_device_isoc_done. Clearly something's gone wrong here though. Ultimately usb should be using pool_cache(9) for memory, unfortunately usb predates it. However, I think the only reason this panic is happening is due to a race, or some other fluke condition. Certainly, adding those printfs and memset can only have altered timings. If you try streaming with that kernel again a few times, does it panic 100% of the time? -- Thanks, Jeremy
Attachment:
signature.asc
Description: This is a digitally signed message part