On Thu, Sep 15, 2011 at 22:25, Alex Deucher alexdeucher@gmail.com wrote:
On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten mfwitten@gmail.com wrote:
I hope you find this adventure interesting, and I hope you provide me with some insight.
Recently, I booted my computer, a Dell Latitude D810 that has a Radeon Mobility x600 (R300); all systems were waking up as normal:
- The Dell logo popped up in some ancient VGA mode.
- The GRUB menu appeared for 3 seconds as instructed.
- Linux loaded and started spewing out log messages.
and then:
BAM!
At around:
2011-09-09 20:27:07 +0000
the Darkness overcame me; my laptop's LCD panel went black with nary a sign of life. After poking around a bit via ssh, I couldn't figure out what was going on; I had been running all the relevant code without trouble for some time now, so it just didn't make sense, and I began suspecting hardware failure.
I strolled on over to freenode/#radeon, where I explained that I was still getting graphics at early boot time, but that it was dying shortly after Linux loaded. A one named Tari suggested that I boot with `nomodeset' in order to avoid anything more complicated than the standards of the Ancients.
And Lo! With that very kernel command line parameter, the boot process did indeed land me safely in a working, albeit cramped VGA-backed virtual console.
Searching the logs a bit more revealed the following:
[drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't calculate constants, dotclock = 0!
Then (skipping a few interesting adventures), I ultimately discovered this kernel message:
[drm] Panel Size 1920x4095
which is curious indeed!, because my laptop's panel size should be `1920x1200'. I booted into the computer's BIOS only to find that it too was being fooled into thinking that the display dimensions are `1920x4095'.
Why might this have happened? Are bits stuck? Did something get fried?
Looks like your bios got corrupted somehow. All of the vertical timing in your panel modeline is bogus. You'll need to patch up all the vertical timing values the same way you patched up the vdisplay in radeon_combios.c. You'll have to try and find the native mode timing for your panel. Note that other data that the driver uses from the vbios may also be corrupt.
The xserver defaults to 96dpi because there are too many broken EDIDs out there and no good way to deal with different DPIs across different monitors in multi-head desktops. Also, a lot of users expect 96 dpi and file bugs when it's something else.
Thanks for the reply.
I did indeed end up hardcoding modeline values in that same function, which basically solved the problem for the time being; I plan[ned] on posting a follow-up email sometime soon (including my attempts to thwart future corruption).
Thanks again.