Re: More amd64 drmkms radeon

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On 22 August 2014 22:35, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>
> Chavdar Ivanov wrote:
>>On 22 August 2014 16:56, Taylor R Campbell <riastradh%netbsd.org@localhost> 
>>wrote:
>>>    Date: Fri, 22 Aug 2014 10:18:59 +0100
>>>    From: Chavdar Ivanov <ci4ic4%gmail.com@localhost>
>>>
>>>    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% /
/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


-- 
----