Consider these two senerios:
1. Device gets blacklisted while not deserving it.
Consequence: Hardware doesn't perform to its maximum.
Fix: Test the blacklisted feature, if it works turn the feature on
after the boot, if not leave feature turned off.
2. Device is not blacklisted when it should be.
Consequence: a. Hardware fails during boot, can't continue
b. Hardware fails silently, corruption occurs.
Fix: a. throw out bad hardware, replace.
b. after months of wondering what's wrong, throw out bad
hardware, replace.
Which senerio seems to be easier to live with. In my opinion 1 seems
easier to cope with on the downside. Of course the natural argument
is to blacklist all possible problems then whitelist known good
combinations... This smells like kernel bloat to me.
-- Jeffrey Hundstad
On 8 Sep, Andre M. Hedrick wrote:
> On Tue, 8 Sep 1998, Chris Wedgwood wrote:
>
>> On Tue, Sep 08, 1998 at 12:39:44AM -0400, Gregory Maxwell wrote:
>>
>> > I'm worried that alot of people will have hardware compatibility
>> > probs with 2.2. Consider the VIA dma bug, how many more like that
>> > are there, they we just havn't notices because no one with the
>> > nessassary weird hardware combo to bright it out is running 2.1?
>>
>> Linux makes marginal hardware break... I've got hardware that works
>> 100% under NT, but under Linux, bad things happen.
>>
>> Some of this breakage has acceptable work-arounds, and if these
>> devices are know, when can black list them.
>>
>> I didn't follow the VIA thread, but I suspect we can black-list DMA
>> for VIA chipsets.
>>
>
> No you may not do a generic blacklist.
>
> For VIA hardware that is robust (ie VP3) (U)DMA is fully function all.
> The VP2 has a reported incomplete UDMA standard, but straight DMA mode 2
> is functional.
>
> As I have suggested else where, we may need to consider doing a split
> enable/disable of UDMA and DMA on a case by case basis. This is
> ugly and painful, but less than a wholesale disable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html