Re: uvideo webcam on big-endian systems

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

Jeremy Morse wrote:

> So, the UVC headers on each packet are intact, and there's nothing else
> uvideo can really do wrong, which leaves ehci and video(4). The

Ok, we're getting closer.


> attached uvideo_mset.diff should rule out one of them: if you get a
> plain green mplayer window with the patch applied, the fault is with
> ehci. If mplayer still produces the output you've been seeing (or
> something else), then video is knarling things up.

Unfortunately I cannot tell, because the system reboots now before any
mplayer output is generated. :(

This is what happened until I lose connection:

---8<---
uvideo0 at uhub3 port 2 configuration 1 interface 0: Sonix Technology Co.,
Ltd. USB 2.0 Camera, rev 2.00/1.00, addr 2
video_match: hw=0x53b0f4
video0 at uvideo0video_print: pnp is NULL
: Sonix Technology Co., Ltd. USB 2.0 Camera, rev 2.00/1.00, addr 2
video_attach: sc=0xd5541808 hwif=0x53b0f4
videoopen
videoopen: flags=0x3 sc=0xd5541808 parent=0xd5827e08
video: unknown v4l2 pixel format 842094169
video alloc 2 bufs
enqueue 0xd5833e30
enqueue 0xd5833e48
---8<---

After a reboot I saw in "messages" that the kernel (5.99.41) panicked:

---8<---
panic: kernel diagnostic assertion "!cpu_softintr_p()" failed: file
"/home/frank/netbsd/current/src/sys/kern/subr_kmem.c", line 196
cpu0: Begin traceback...
0xd453fca0: at kern_assert+0x4c
0xd453fcb0: at kmem_alloc+0x1b4
0xd453fce0: at kmem_zalloc+0x18
0xd453fd00: at usb_block_allocmem+0xe4
0xd453fd30: at usb_allocmem+0x40
0xd453fd60: at ehci_device_isoc_start+0x244
0xd453fdd0: at usbd_transfer+0x78
0xd453fe00: at uvideo_stream_recv_isoc_start1+0x74
0xd453fe20: at uvideo_stream_recv_isoc_complete+0xd8
0xd453fe60: at usb_transfer_complete+0x300
0xd453fe90: at ehci_idone+0x1a0
0xd453fec0: at ehci_softintr+0x260
0xd453fef0: at softint_thread+0x104
0xd453ff40: at emptyidlespin+0x10
saved LR(0x6db6db69) is invalid.cpu0: End traceback...
---8<---

A kmem_alloc() doesn't seem to be allowed in an interrupt (hard and soft).
And this definitely was a soft-interrupt for ehci.

I don't understand why that didn't happen before though.


-- 
Frank Wille