On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
>> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote:
>> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> >>> 2010/9/20 Andy Walls <awalls@xxxxxxxxxxxxxxxx>:
>> >>> > On Mon, 2010-09-20 at 20:29 +0200, RafaÅ MiÅecki wrote:
>> >>> >> 2010/9/20 Andy Walls <awalls@xxxxxxxxxxxxxxxx>:
>
>> >> 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
>
>
--
Jon Smirl
jonsmirl@xxxxxxxxx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
