On Sat, 2010-12-25 at 15:05 +0100, Frank Wille wrote: > > 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? Yeah - one possibility is that, were the initial calls to ehci_device_isoc_start (outside of intr context) somehow interlaced with an interrupt that freed/allocated itds, the seen behavior could occur. However, I would have expected the big kernel lock to take care of that. > > 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. Jared made some changes to video.c on the 14th Dec, but they don't appear to contain anything dangerous; you could try without those modifications though. > > If you try streaming with that kernel again a few times, does it panic > > 100% of the time? > > Yes, always. :| Uugh. Of course, if you disable option DEBUG then the kmem_alloc kassert won't be tested, and it's unlikely the kernel will run out of memory + sleep while you test the video stuff. But that'd be fairly hacky. > Yes. Disassembling ehci.o shows that you're right. Do you know the PowerPC memory managment facilities at all? I've been wondering if the way the "scatter IO" routines in video.c work could offend PowerPC (specifically through mmap). However, I don't know anything about PowerPC memory stuff. -- Thanks, Jeremy
Attachment:
signature.asc
Description: This is a digitally signed message part