Messages in this thread | | | From | James Cloos <> | Subject | Re: radeonfb lockup in .28-rc (bisected) | Date | Mon, 27 Oct 2008 21:46:52 -0400 |
| |
>>>>> "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
| |