Re: uvideo webcam on big-endian systems

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