On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls awalls@md.metrocast.net wrote:
On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote: > 2010/9/20 Andy Walls awalls@md.metrocast.net:
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
Andy, this sure looks like a broken VBIOS to me.
Well sure.
But that problem causes other problems in error handling code paths to surface. It also brings to light that there are some cases that are undecidable, or not worth the effort, for the error handling code paths on what the proper action should be.
First thing would be to update your VBIOS if possible to get a correct table for your hardware.
Um, no.
I will not risk taking an operational machine down due to flash write failure, however small the probability, due to the high impact. The reward of shutting up kernel error messages, is not worth the risk.
Second would be to add a quirk in the kernel.
I have expressed my thoughts on quirks in a previous post.
There are lots of cases where the kernel does odd things when the BIOS feeds it bad information. Do we really want hundreds of switches in sysfs allowing adjustments for broken BIOS features?
I see very little downside in giving the user more control over his system. A thousand knobs and switches are worth it for the user, for the one switch that is there when the user needs it to solve a problem.
To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver to dump the ROM. That would have consumed a lot of time. Luckily for me, there was a switch to turn on the ROM and dump it:
The ROM is turned off by default due to a provision in the PCI spec that allows the address space of it to be reused after boot. A few old PCI devices make use of this feature. If you turn the ROM on in those machines they will crash.
# echo 1 > /sys/class/drm/card0/device/rom # dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin # echo 0 > /sys/class/drm/card0/device/rom
I never used it before and will likely never use it again. But when I had a problem I needed to solve, its availability made the solution simple and efficient. Time to accomplish tasks is my scarcest resource; time efficiency is very important to me.
The only downside to hundreds of switches and control knobs I can really think of is possibly complexity for the end user. But it turns out, that ignoring the available controls, or ignoring large subsets of the available controls, is how people are going to deal with that complexity. Heck, I ignore most of sysfs almost all the time. I also ignore almost every module option available. My system runs fine without me caring about a majority of the existing switches.
BTW, we already have thousands of switches and controls for kernel internals in linux without sysfs and ioctl()'s:
$ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} ; | grep '^parm:' | wc -l 3387
Why do we have that many? They are low cost in complexity, as they can easily be ignored. They are high value in utility, as they give the user control over his system to deal with unusual circumstances.
</rant>
We already have the quirk scheme for addressing this.
A simpler solution for reducing the log spam would be to only report the error once, instead of every 10 seconds. The driver could remember it has made the error report and then log another message later if the error was cleared.
My sysfs implementation was only 69 changed lines in one file:
drivers/gpu/drm/drm_sysfs.c | 69 +++++++++++
I doubt a solution to add logic to the error paths, to try and divine all the sources of EDID errors by saving state and applying rules to take the correct action, is going to be less change than that. I know more than one file will have to change.
Regards, Andy