lkml.org 
[lkml]   [1997]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: serial input overrun(s) using ide-cd
On 16 Oct, John Kelly wrote:

> The CMD640 and RZ1000 problems are well known, and defensive
> programming of the chipset can circumvent the problem. FreeBSD does
^^^^^^^^^^^^
> so without any need to disable interrupts during IDE disk I/O.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

<RANT ON>
Puh-leese. This argument, in and of itself is so ridiculous that no
person in their right mind should ever utter such garbage. Let me
explain. The argument implies that the FreeBSD IDE driver does not
disable interrupts by default, and therefore the linux driver should do
so as well. Involved in making this argument, there are several
implicit premises involved in the above argument in order to make the
first premise flow into the conclusion. One possible path of premises
is as follows:

A. The FreeBSD IDE driver does not disable interrupts by default
B. No FreeBSD system has FS corruption as a result of A.
C. The linux IDE driver is the same as the FreeBSD driver.

Therefore, the linux IDE driver can do the same.

Well, that one falls flat without any further inspection since the linux
and FreeBSD IDE drivers are *not* the same. Furthermore, even were they
the same, it would still be fallacious unless you could show that linux
was never used on any computer upon which FreeBSD wasn't also used. One
can write other possible scenarios to try and justify your statement,
but they only get more ridiculous the more you try. As a matter of
argument, the following counter argument to yours can be made (and
justified):

A. The FreeBSD user community is comprised of a higher percentage of
highly skilled users and server platforms than is the linux
user community (aka, we have a much larger number of the
unwashed masses using linux than does FreeBSD).
B. Statistical reports of problems or successes with certain hardware
and drivers in the FreeBSD community represent said community.
C. Statistical reports of the FreeBSD community do not include a
significant number of samples from the "unwashed masses" and
the hardware and software run by said "unwashed masses" in
relation to the linux community.

Therefore, statistical reports from the FreeBSD community are not a
valid statistical sample arena upon which to draw conclusions for the
linux community as a whole.

So, can we now stop the "FreeBSD does it so linux should too" crap
before I loose my dinner? Really, the worst implied premise in that
argument is the premise that FreeBSD can do no wrong, since if that
argument is applied unilaterally to the FreeBSD kernel, then it indeed
implies that the FreeBSD kernel is doing things the right way in all
cases. Give me a break.
<RANT OFF>

> With such a small number of users to be affected, It would be much
> better to enable interrupts during IDE disk I/O in the kernel and give
> users a LILO/LOADLIN parameter to override the default behavior.

Sure, so now we cause disk corruption on flaky machines by default.

> The various distributions could even apply the override in their boot
> disks if they were fearful of negative user feedback.

OK...so now we don't cause disk corruption on those machines by
default. Hmmm...seems to me we are right back where we started except
now we are confusing people by changing around the way we do things but
ending up with the exact same results.

> Changing the Linux kernel default to ENABLE interrupts during IDE disk
> I/O would be FAR SUPERIOR to probing for a recognizable PCI controller
> in an effort to determine whether it seems "safe" to enable interrupts
> during IDE disk I/O. With so many PCI users now, why go to such great
> lengths merely to maintain a Linux tradition?

Because the tradition, unlike your proposal, is safe and avoids tons of
repetitive email about disk corruption. I'd rather have people email
about serial overruns, which are harmless, than email about "Why did
linux trash my hard drive and loose the source code for my project
that's due tomorrow?"

> Any why be hidebound by tradition? Just change the default and give
> users a boot-time parm to override it!

<RANT ON, AGAIN>
Sure, like the unwashed masses mentioned above are going to magically
know that they should use this boot param on their particular drive and
controller setup. Maybe they absorbed the information via osmosis as
they slept with their tidy RedHat manual resting on their forehead
since we all know that most people don't bother to actually read the
damn things.
<RANT OFF>


--
*****************************************************************************
* Doug Ledford * Unix, Novell, Dos, Windows 3.x, *
* dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician *
* PPP access $14.95/month *****************************************
* Springfield, MO and surrounding * Usenet news, e-mail and shell account.*
* communities. Sign-up online at * Web page creation and hosting, other *
* 873-9000 V.34 * services available, call for info. *
*****************************************************************************


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.048 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site