Re: More amd64 drmkms radeon

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

On 22 August 2014 23:39, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> 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% /

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



-- 
----