Introduction
Introduction Statistics Contact Development Disclaimer Help
View source
# 2025-11-21 - BSD Versus Linux
In 1999 i set up my first Linux server in a professional context. I
used existing hardware and Debian 2.1 (Slink). It worked great
except for a kernel OOPS that happened several times per month,
requiring a reboot. I couldn't understand the garbledygook in the
kernel messages, so i asked for help, probably on a Debian mailing
list. Nobody replied.
I tried NetBSD (1.4?) on the same hardware, and it was rock solid.
The NetBSD bug tracking system and mailing lists were a much
friendlier place for me, as a Unix newbie, compared to Debian.
So i went with that.
A year or so later, my supervisor figured out the root cause of the
Debian server instability. Linux was enabling Ultra DMA 3 for
faster disk access, which requires an 80-conductor ribbon cable. The
server only had a 40-conductor ribbon cable. This resulted in
cross-talk and data corruption, causing random, sporadic crashes.
The solution was to replace it with an 80-conductor ribbon cable.
UDMA
I am no longer a newbie and i still don't understand why NetBSD
worked better. Reviewing the source code, i see that NetBSD 1.4
supported Ultra DMA. It should have enabled whatever level of UDMA
the disk claimed to support.
wd(4) from NetBSD 1.4
For some reason NetBSD operated the disk at a lower speed, so it
never crashed. The 40 conductor ribbon cable happened to be good
enough. Perhaps NetBSD's cache flushing and filesystem defaults were
simply more conservative and sane compared to Linux.
It was a happy accident that it worked at all. In my experience this
is true of much of technology. To pretend that the technology is
pure or correct is a mistake. The important aspect is the social
aspect, keeping in mind human creators and human users. Otherwise
your dogma might get run over by your karma.
This human centered approach is what made BSD superior to Linux in
my book. I was willing to trade performance losses for better
community, documentation, and organization.
This is essentially the same point i made in another post:
SystemD versus SYSV
p.s.
Today someone told me that i could have worked around this with
the NODMA Linux kernel command line option.
Debian 2.1 (Slink) used Linux kernel version 2.0.
Debian Linux Kernel 2.0.33 Source Code (6 MB)
Documentation/ide.txt says:
> Bus-Master DMA support for Intel PCI Triton chipset IDE interfaces
> for details, see comments at top of triton.c
drivers/block/triton.c says:
> The hdparm-2.4 (or later) utility can be used for manually
> enabling/disabling DMA support, but must be (re-)compiled against
> this kernel version or later.
So if i had understood the garbledygook that the Linux kernel OOPS
had printed on my console, i could have minimized my risk of crashes
by editing my boot scripts and adding the following command to force
Ultra DMA 2:
hdparm -d1 -X18 /dev/hda
Later, Linux got boot parameters to disable DMA:
* Linux 2.4 -- ide=nodma
* Linux 2.6 -- ide0=nodma
* Later -- ide_core.nodma=0.0
* Even later -- libata.dma = 0
In contrast, NetBSD's option to disable DMA has remained the same:
wd* at atabus? drive ? flags 0x0f00
Now if only i had a time machine to send this information to my
befuddled self in 1999.
tags: bencollver,retrocomputing,technical,unix
# Tags
bencollver
retrocomputing
technical
unix
You are viewing proxied material from tilde.pink. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.