lkml.org 
[lkml]   [2008]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: radeonfb lockup in .28-rc (bisected)
Date
>>>>> "David" == David Miller <davem@davemloft.net> writes:

David> Please quote at least the headerline of the commit so that it can
David> come into our memory quickly when reading your report.

Good point.

David> The actual key here is that when setfont runs, the framebuffer
David> layer sets the acceleration options for the framebuffer for the
David> first time to their final settings.

Explains why it breaks. Thanks!

>> -Memory: 512232k/524200k available (4376k kernel code, 11428k reserved, 1707k data, 320k init, 0k highmem)
>> +Memory: 512272k/524200k available (4354k kernel code, 11388k reserved, 1693k data, 316k init, 0k highmem)

David> That's just all due to the text size change because of the
David> different acceleration code.

I left a bit too much unsaid there, but that was the point I was
making. Ie, nothing of issue.

Incidently, it only took 14 hours of compiling to accomplish the
bisect. And that was after a s/=m$/=n/. on my .27 .config.

Anyone bisecting should know that the new HID code is not bisect-safe.
The dell, lg, bright and sony hid drivers all are auto Y if hid is Y and
embedded is N and fail to link (when bisecting) due to missing symbols.

-JimC (still waking up)
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6


\
 
 \ /
  Last update: 2008-10-28 02:49    [W:0.635 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site