Re: CURRENT broken on Raspberry Pi 2?

[mlelstv%serpens.de@localhost (Michael van Elst)]

herbert%gojira.at@localhost ("Herbert J. Skuhra") writes:

>today I am getting a new panic:

>[   1.7517449] usb0 at dwctwo0: USB revision 2.0
>[   1.8817175] panic: uhub0 at usb0: NetBSD (0000) DWC2 root hub (0000), class 9/0, rev 2.00/1.00, addr 1
>[   1.8917219] specificdata_setspecific
>[   1.8917219] cpu0: Begin traceback...
>[   1.9024390] 0x811e7ee4: netbsd:db_panic+0x14
>[   1.9024390] 0x811e7efc: netbsd:vpanic+0x194
>[   1.9120679] 0x811e7f14: netbsd:snprintf
>[   1.9120679] 0x811e7f5c: netbsd:tvtohz
>[   1.9120679] 0x811e7fac: netbsd:linux_workqueue_thread+0x54
>[   1.9233013] cpu0: End traceback...
>Undefined instruction 0xe7ffffff in kernel at 0x8001dc90 (LR 0x80375c50 SP 0x811


That's a crude bug in the USB host driver.

In dwc2_hcd.c a linux-style workqueue is used. The code for these
workqueue comes from drm2 support code in

sys/external/bsd/common/linux/linux_work.c

That code gets initialized when loading DRM in linux_workqueue_init(),
in particular the linux_workqueue_key is allocated and some DRM specific
workqueues are created. But without DRM in place, nothing is initialized.

The USB driver uses the same support code and creates such a workqueue
without the key ever been allocated. The linux_workqueue_thread then tries
to use that key which causes it to panic with "specificdata_setspecific".

The question is, why does it happen now.

The panic is raised when a key is used larger than all allocated keys.
So if any key has been allocated before dwc2_hcd.c, you don't see a panic,
but possibly two unrelated subsystems trash each others specificdata.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."