Jeremy Morse wrote: >> 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.
Yes. Disassembling ehci.o shows that you're right. > 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. Ok. So the initial itds should be guaranteed to be allocated outside of interrupt context? > happening is due to a race, or some other fluke condition. Certainly, > adding those printfs and memset can only have altered timings. Doesn't seem to be the case. I removed your patch, and reading from /dev/video0 still makes the system reboot. I fear this is partly my fault, because I updated the kernel sources during the last days, and there must be some modification which causes these problems. Now I tried it with sources from the 20th and from the 22nd of December, and both behave the same. So we have to interrupt our tests until this problem is resolved. > If you try streaming with that kernel again a few times, does it panic > 100% of the time? Yes, always. :| -- Frank Wille
