From owner-freebsd-hackers Fri Apr 28 20:06:10 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA04908 for hackers-outgoing; Fri, 28 Apr 1995 20:06:10 -0700 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA04902 for ; Fri, 28 Apr 1995 20:06:03 -0700 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.8/8.6.6) id WAA02751; Fri, 28 Apr 1995 22:02:48 -0400 Date: Fri, 28 Apr 1995 22:02:48 -0400 From: "House of Debuggin'" Message-Id: <199504290202.WAA02751@skynet.ctr.columbia.edu> To: faulkner@mpd.tandem.com, kelly@fsl.noaa.gov Subject: Re: What I'd *really like* for 2.0.5 Cc: hackers@FreeBSD.org, jkh@time.cdrom.com, root@morton.cdrom.com, wpaul@skynet.ctr.columbia.edu Sender: hackers-owner@FreeBSD.org Precedence: bulk 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: ahc0: Probing channel A ahc0: target 0 synchronous at 10.0MB/s, offset = 0x19 sd0 at ahc0 target 0 unit 0 sd0: (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