Re: radeonfb lockup in .28-rc (bisected)

[James Cloos <cloos@jhcloos.com>]

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