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 > > > -- > ---- -- ----