On Mon, Dec 28, 2020 at 05:14:52AM +0100, Pierre Pronchery wrote: > Hi tech-pkg@, > > While trying to debug an issue with my Radeon HD4870 during initialisation > (the UVD firmware does not load) I noticed an error in the kernel trap. The > important part of the backtrace is as follows: (copied manually) > > > kernel: page fault trap, code=0 > > Stopped in pid 0.100 (system) at netbsd:workqueue_enqueue+0x16: testb > > $0x2,10(%rdi) > > workqueue_enqueue() at netbsd:workqueue_enqueue+0x16 > > biodone2() at netbsd:biodone2+0xd8 > > [â¦] > > trap() at netbsd:trap+0x70c > > --- trap (number 6) --- > > copy() at netbsd:kcopy+0x15 > > uiomove() at netbsd:uiomove+0x93 > > [â¦] > > firmware_read() at netbsd:firmware_read+0x5e > > > I figured that the call to workqueue_enqueue() is performed on an > uninitialised queue, in main() (âaiodonedâ). > When moving its initialisation before mounting the root file system, the > error while loading the firmware seems to be caught: > > > radeon0: unable to attach drm: 22 > > > Let me know if the patch attached is therefore correct. (I am working on the > netbsd-9 branch)
That change is fine for netbsd-9. I fixed it differently in HEAD, but I made some mistakes and it took a few commits to get it straightened out, and I'm not sure I could find all the related commits now. > Of course, any help for the actual problem preventing the radeon DRM code > from loading RV770_uvd.bin is welcome. > It is the 5th file out of 5 to be loaded, and the 4 previous firmware files > load correctly, with seemingly identical code. > The correct file is present in the filesystem (booting with a ramdisk) and > request_firmware() sees the correct size > (90668 bytes compared to 3392, 5440, 4096, and 16656 earlier). I have no idea about this part, my only suggestion is to keep adding printf's down the call stack. -Chuck