On Thu, Sep 15, 2011 at 22:25, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Mon, Sep 12, 2011 at 2:13 PM, Michael Witten <mfwitten@xxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
