Date: Fri, 28 Apr 1995 22:02:48 -0400 From: "House of Debuggin'" <wpaul@skynet.ctr.columbia.edu> To: faulkner@mpd.tandem.com, kelly@fsl.noaa.gov Cc: hackers@FreeBSD.org, jkh@time.cdrom.com, root@morton.cdrom.com, wpaul@skynet.ctr.columbia.edu Subject: Re: What I'd *really like* for 2.0.5 Message-ID: <199504290202.WAA02751@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
They say this Sean Kelly person was kidding when he wrote:
> By the way: did we ever get a -a option in ifconfig?
Not only did I put in a -a flag, I also added a -ad flag and a -au
flag (-ad for all down interfaces and -au for all up interfaces).
I even documented them in the man page.
> --
> Sean Kelly
> NOAA Forecast Systems Lab, Boulder Colorado USA
>
> TASK: Shoot yourself in the foot. In Paradox: Not only can you shoot
> yourself in the foot, your users can, too.
Oh, one thing while I'm here: I was mistaken when I said you only
have to edit the defaultdomain setting in /etc/sysconfig to activate
NIS. You also need to change the nis_clientflags from "NO" to something
other than "NO". I recommend "-s" to run ypbind in secure mode.
Also, here's a short story for you. Yesterday, the UPS guy dropped off
three Intel Pentium 90mhz (EISA) systems for the Image lab. Seems Intel
actually donated the buggers to us. I later discovered that, as with the
Gateway 2000 Pentiums that they Image lab purchased recently, they
were meant to be used with some sort of MPEG endoder/decoder hardware
for one of their projects. (I think they're trying to show that they can
use PCs as video on demand clients just as easily as you could a
workstation, with the difference being that PCs tend to be much cheaper.)
They also purchased ATI Mach64 PCI video adapters (I'm a bit confused by
this since the machines have on-board graphics -- i think they want them
for the feature connector.)
The machines are completely EISA (no PCI, no local bus), with Adaptec
2740T Twin Channel SCSI controllers (AIC-7770), 16 megs of RAM, on-board
Western Digital SVGA display hardware, Intel EtherExpress 16 network adapters
and Seagate 1 GB drives. Oh, and PS/2 bus meeses. On the whole, they're
very nice machines.
There's just one problem, which you may have already divined: the
machines have no PCI slots, whereas the MPEG cards and video adapters
are PCI devices. That's planning for you.
I don't think they make EISA versions of the MPEG boards (they make
a VESA version, but that too won't work), so I strongly suspect the
machines will be going back. ("Hello, Intel? Remember those 3 Pentium
machines you sort of gave us? Uhm, well...")
Anyway, before I found this out, I'd managed to start installing FreeBSD
on one of them to see how it liked the hardware. I had the April 12th
snap floppies handy so I used those for the install. I later built a
kernel from -current. (This I did largely because I couldn't get the
Crynwr packet driver for the EtherExpress 16 to initialize the ethernet
adapter, which left me without a way to hook it to the network.) Along
the way I made the following observations:
- The Intel EtherExpress is very often misidentified by other drivers
(I set mine to 0x300, irq 10, iomem 0xd0000 to match the GENERIC kernel
settings. Yes, I know I could have used -c to change the settings.)
The Mitsumi CD-ROM driver tripped over it twice. Once it was wrongly
identified as a Wangtek tape controller. I don't blame anyone for
this other than Intel.
- The 'dset' stuff actually came in *very* handy here, as it saved me
the trouble of having to disable the Mitsumi and Wangtek drivers
at each reboot (ditto the matcd driver, which was buggy in this SNAP
and spammed me with messages when the GENERIC kernel came up).
- When it was correctly identified as ix0, the EtherExpress worked great
with FreeBSD. (Rod: I hope BPF support for the ix driver is not too
far off.)
- The printf()s from the slicing code irritate the hell out of me:
sd0s4: type 0xa5, start 32, end = 2061107, size 2061076
sd0s4: C/H/S start 0/1/1 (20) != start 32: invalid
sd0s4: C/H/S end 1006/25/20 (523639) != end 2061107: invalid
sd0: rejecting partition in BSD label: it isn't entirely within the slice
sd0: start 32, end 2061107, size 2061076
sd0d: start 0, end 2061107, size 2061108
[same thing repeated 2 more times]
I installed FreeBSD on slice four, using the default values provided
by the install program. In spite of these ominous warnings, the system
seems to work fine. I think I know what it's telling me, but I'm not
in the mood to fiddle with the thing now that I have it working.
Regardless, I have this terrible urge to sweep this all under
bootverbose.
- The SCSI disk probe messages also irritate the hell out of me:
ahc0: reading board settings
ahc0: 274x Twin Channel, A SCSI Id=7, B SCSI Id=7, aic7770 >= Rev E, 16 SCBs
ahc0: Downloading Sequencer Program...Done
ahc0 at 0x1000-0x10ff irq 11 on eisa slot 1
ahc0: Probing channel A
ahc0: target 0 synchronous at 10.0MB/s, offset = 0x19
(ahc0:0:0): "SEAGATE ST31200N 9022" type 0 fixed SCSI 2
sd0(ahc0:0:0): Direct-Access 1006MB (2061108 512 byte sectors)
I'd rather see something like:
ahc0 at 0x1000-0x10ff irq 11 on eisa slot 1
aha0: <Adaptec 274x Twin Channel>
ahc0: Probing channel A
ahc0: target 0 synchronous at 10.0MB/s, offset = 0x19
sd0 at ahc0 target 0 unit 0
sd0: <SEAGATE ST31200N 9022> (1006MB, 2061108 512 byte sectors)
(Everything else should probably also be hidden under bootverbose.)
The latter strikes me as more consistent and more BSDish. (We are
still BSD, right? ;)
I may be overly critical here, but the last time I saw a Linux
box boot, I was stunned by the jumble of inconsistent probe messages
that it generated. Every driver author seemed to have his own idea
of what the probe messages should look like, and I hated all of them.
- When I tried to 'wire down' sd0, sd1 and cd0 in my new kernel config,
the system panicked when it went to probe channel B of the 2740T. The
messages I got were:
ahc0: Probing Channel B
extend_set: entry 0 already has storage
panic: scsi_attachdevs: malloc
Exactly how does the ahc driver handle the other channel? If ahc0:0:0
on channel A is sd0, what does that make ahc0:0:0 on channel B?
Maybe I should be disabling channel B since I have no devices on it?
- I discovered another NIS-related bug in /usr/src/lib/libc/getgrent.c.
This is my problem though, and one that I'll be hacking on shortly.
Briefly, the +:*: line is falsely identified by getgrgid() as being
an entry for GID 0. This is bogus. You can work around it if you're
clever, but I also found another null pointer dereference condition
that needs to be fixed.
I saw some glitches in the install, but these have already been reported
so I won't bother rehashing them. Once I got FreeBSD up, it ran like a
top. I brought up X on the WD90Cxx SVGA display in 1024x768x8 and it
looks superb (there's only 1 meg of video memory, unfortunately) not to
mention pretty darn snappy. Snappier even than the SPARC 5 with the
microSPARC 85Mhz CPU and Solaris 2.3 sitting a few tables away in the
lab. The SPARC has double the RAM and swap space of the Intel machine
too. *sigh*
-Bill
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Bill Paul (212) 854-6020 | System Manager
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Møøse Illuminati: ignore it and be confused, or join it and be confusing!
~~~~~~~~~ FreeBSD 2.1: "We can kick your operating system's ass!" ~~~~~~~~~~
#
# NAKEDGUN -- Generic machine with AHx family disks
#
machine "i386"
cpu "I586_CPU"
ident NAKEDGUN
maxusers 20
options INET #InterNETworking
options FFS #Berkeley Fast Filesystem
options NFS #Network Filesystem
options MSDOSFS #MSDOS Filesystem
options "CD9660" #ISO 9660 Filesystem
options PROCFS #Process filesystem
options "COMPAT_43" #Compatible with BSD 4.3
options "SCSI_DELAY=5" #Be pessimistic about Joe SCSI device
options UCONSOLE #Allow users to grab the console
options ALLOW_CONFLICT_IOADDR # PS/2 mouse lossage
config kernel swap generic # Am I the only one who uses this?
controller isa0
controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk fd0 at fdc0 drive 0
disk fd1 at fdc0 drive 1
device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr
device npx0 at isa? port "IO_NPX" irq 13 vector npxintr
device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
device lpt0 at isa? port? tty irq 7 vector lptintr
device psm0 at isa? port "IO_KBD" tty irq 12 vector psmintr
controller ahc0 at isa? bio irq ? vector ahcintr
controller scbus0 at ahc0 # config complains without this
disk sd0 at scbus0 target 0 unit 0
disk sd1 at scbus0 target 1 unit 0
device cd0 at scbus0 target 6 unit 0 # Is this legal?
device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr
pseudo-device loop
pseudo-device ether
pseudo-device log
pseudo-device pty 64
pseudo-device speaker
pseudo-device gzip # Exec gzipped a.out's
pseudo-device vn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504290202.WAA02751>