Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: More amd64 drmkms radeon
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 <ci4ic4%gmail.com@localhost> wrote:
> 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
>>
>>
>> --
>> ----
>
>
>
> --
> ----
--
----
Home |
Main Index |
Thread Index |
Old Index