Re: uvideo webcam on big-endian systems

[Frank Wille <frank%phoenix.owl.de@localhost>]

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