linux-kernel - Re: Linux-2.6.27-rc5, drm errors in log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <21d7e9970808302340w71483645macb34f8470a85c66@mail.gmail.com>
Date:	Sun, 31 Aug 2008 16:40:59 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	"Gene Heskett" <gene.heskett@...izon.net>
Cc:	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: Linux-2.6.27-rc5, drm errors in log

On Sun, Aug 31, 2008 at 12:19 PM, Gene Heskett <gene.heskett@...izon.net> wrote:
> On Saturday 30 August 2008, Bridgman, John wrote:
>>))I'm drowning in these errors:
>>))
>>))Aug 30 13:21:05 coyote kernel: [14927.850078] [drm] wait for fifo failed
>> status : 0x80076100 0x00000000
>>
>>I'm just going on the code in your email - can't view git until later today
>> - but in this case it seems like the timeouts were always happening and now
>> there is code to print an error message.
>>
>>IIRC the usual fix is to bump the timeout but (Michael ?) has suggested a
>> couple of times that the ideal solution would be to change the logic so
>> that the driver never times out while the chip is making progress (ie while
>> the number of slots available in the fifo is increasing, even if it hasn't
>> increased enough yet).
>>
> FWIW, I added the 3 lines that cause that printout to the 2.6.27-rc4 tree and
> rebuilt it.  There are no more errors being reported now by 2.6.27-rc4, and
> there were none without those 3 added lines prior to this, so it is rc5
> specific.

Hmm I'm just looking at the patches I put in for rc5, and there is no
functional difference to the
r200 codepath that I can see from those patches apart from the debug prints.

Can you get a clean -rc4 and apply just 54f961a628b737f66710eca0b0d95346645dd33e
to it.

See if you can get that to produce the errors, if it does, apply just
the drm info chunks, try again, if that works, try adding
the isync cntl chunk. and re-testing. I can't see how writing isync
cntl here would affect things though.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/