The good news is that DRMKMS doesn't crash any more on boot on that machine; Xorg shows the cursor in the screen centre and a small white rectangle in the top left corner; the machine is reachable from outside, but the console is unresponsive from this moment on; if I try something further (like startx or [kg]dm), I get a hard reset.
Chavdar On 23 August 2014 17:39, Chavdar Ivanov <ci4...@gmail.com> wrote: > On 22 August 2014 23:39, Chavdar Ivanov <ci4...@gmail.com> wrote: >> On 22 August 2014 22:35, Robert Swindells <r...@fdy2.co.uk> wrote: >>> >>> Chavdar Ivanov wrote: >>>>On 22 August 2014 16:56, Taylor R Campbell <riastr...@netbsd.org> wrote: >>>>> Date: Fri, 22 Aug 2014 10:18:59 +0100 >>>>> From: Chavdar Ivanov <ci4...@gmail.com> >>>>> >>>>> A DRMKMS kernel from 15th works as suggested above - switches to >>>>> 1280x1024 and is fine after (Xorg panics earlier; with the latest >>>>> build from yesterday it even wedged the machine completely). >>>>> >>>>> On the other hand yesterday's kernel panics as follows: >>>>> [...] >>>>> drm kern error: radeon_cp: Failed to load firmware "radeon/R300_cp.bin" >>>>> >>>>> Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root >>>>> file system? >>>> >>>>Yes, the kernel from 15th of August loads it fine: >>>> >>>>$ uname -a >>>>NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug >>>>15 14:06:51 BST 2014 >>>>root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 >>>>$ ls -l /usr/libdata/firmware/radeon/R300_cp.bin >>>>-r--r--r-- 1 root wheel 2048 Jul 6 2010 >>>>/usr/libdata/firmware/radeon/R300_cp.bin >>>>$ dmesg | grep Microcode >>>>drm: Loading R300 Microcode >>>>... >>> >>> I tried a custom kernel with sources from yesterday on i386 with a >>> R300 and it works fine. >>> >>>>> We really ought to have a better story if it's not, but that's my >>>>> first guess about the problem. >>>>> >>>>> panic: kernel diagnostic assertion "ttm->caching_state == tt_cached" >>>>> failed: file "../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c", >>>>> line 423 >>>>> >>>>> This is a bug in the rat's nest of error branches in the Radeon code, >>>>> ugh... >>>> >>>>Well, it doesn't show up in the earlier version, so it looks a regression. >>> >>> The panic is triggered while cleaning up from the failure to load the >>> microcode. >>> >>> One change between your working kernel and now was to enable wedges, they >>> are disabled in my custom kernel. >> >> I have to say, this came to my mind as well. However, that machine has >> been using raidframe and wedges for ages: >> >> ~ df -k -t ffs >> Filesystem 1K-blocks Used Avail %Cap Mounted on >> /dev/raid0a 105311462 31680686 68365204 31% / > > However, I have to notice that in the case of the working > non-default-slice kernel, the root is not on a wedge, so there may be > something about the order in which the wedges are recognized and the > firmware loaded. > > Chavdar > > > >> /dev/dk0 116306664 65608 110425728 0% /spare >> /dev/dk1 71674768 61557912 6533120 90% /data >> ~ raidctl -s raid0 >> Components: >> /dev/wd5a: optimal >> /dev/wd4a: optimal >> ... >> ~ raidctl -s raid1 >> Components: >> /dev/wd0a: optimal >> /dev/wd2a: optimal >> /dev/wd3a: optimal >> ... >> ~ gpt show raid0 >> start size index contents >> 0 234441472 >> ~ gpt show raid1 >> start size index contents >> 0 1 PMBR >> 1 1 Pri GPT header >> 2 32 Pri GPT table >> 34 144607293 1 GPT part - NetBSD FFSv1/FFSv2 >> 144607327 32 Sec GPT table >> 144607359 1 Sec GPT header >> ~ dkctl raid1 listwedges >> /dev/rraid1d: 1 wedge: >> dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs >> >> (from the working kernel from 15th). >> >> >>> >>> Robert Swindells >>> >>> >> >> Chavdar >> >> >> -- >> ---- > > > > -- > ---- -- ----