Date: Tue, 5 May 1998 11:27:52 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: eivind@yes.no (Eivind Eklund) Cc: cdillon@wolves.k12.mo.us, hackers@FreeBSD.ORG Subject: Re: Call for testers for ThunderLAN ethernet driver Message-ID: <199805051527.LAA29903@skynet.ctr.columbia.edu> In-Reply-To: <19980505165604.36955@follo.net> from "Eivind Eklund" at May 5, 98 04:56:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Eivind Eklund had to walk into mine and say: > On Tue, May 05, 1998 at 08:14:52AM -0500, Chris Dillon wrote: > > On Tue, 5 May 1998, Bill Paul wrote: > > > > > I would appreciate if people running FreeBSD 2.2.6 that have Compaq > > > hardware could test this driver to make sure it works, and if people > > > > I have an older Compaq ProsiginiaVS server (486-66, EISA) running 2.2.5 > > which has onboard Ethernet and SCSI, neither of which I got working (the > > onboard Ether is a Lance/PCnet chip, i think, so it should work), and the > > SCSI is an NCR chip of some kind. I do have a Compaq (Netflex2/TR??) card > > sitting in a drawer that was Ethernet/TokenRing selectable, and I might be > > able to pop it back into Ethernet mode, plug it in, and test it out, maybe > > even as early as July. ;-> (production box).. I wish someone would come up > > with a driver for the stinkin' Compaq SCSI stuff, too. :-) Well, the ThunerLAN is a PCI-only chip and looks nothing like the LANCE in terms of its programming interface, so I can't help you there. A lot of the time the hard part is getting the chip probed correctly; if it is a LANCE then maybe the le driver will work with it, but you have to make the le driver realize it's there first. Also, the ThunderLAN chip does support either ethernet or token ring physical interfaces (PHYs) so it's very likely that the Netflex card you have is a ThunderLAN and will work with this driver, provided it's a PCI adapter. I didn't include token ring support though. > The stinkin' Compaq SCSI stuff worked fine for me, but I never took > that box beyond 2.1 (I've quit the company where I used it). Ditto > for the Lance-based NetFlexes. > > There were some initial problems getting the PCI probed correctly, but > merging from (then) 2.2-current made them go away. > > Eivind. The Prosignia server I have uses an NCR SCSI card in one of its PCI slots. Dmesg says: Probing for devices on PCI bus 0: chip0 <Intel 82440FX (Natoma) PCI and memory controller> rev 2 on pci0:0:0 vga0 <VGA-compatible display device> rev 0 on pci0:11:0 ncr0 <ncr 53c875 fast20 wide scsi> rev 4 int a irq 5 on pci0:12:0 (ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15) (ncr0:0:0): "COMPAQ WDE4360W 1.52" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled sd0(ncr0:0:0): 40.0 MB/s (50 ns, offset 15) 4094MB (8386000 512 byte sectors) tlc0 <Compaq NetFlex-3/P Integrated> rev 16 int a irq 9 on pci0:16:0 tlc0: Ethernet address: 00:80:5f:7d:fb:b7 tl0 at tlc0 physical interface 1 tl0: <National Semiconductor DP83840A> 10/100Mbps full duplex autonegotiating tl0: autoneg complete, link status good (full-duplex, 100Mb/s) chip1 <Intel 82371SB PCI-ISA bridge> rev 1 on pci0:20:0 chip2 <Intel 82371SB IDE interface> rev 0 on pci0:20:1 It's worked fine from the moment I booted the FreeBSD 2.2.6 install kernel. Which reminds me: both the Prosignia and Deskpro machines that I have access to use ATAPI CD-ROM drives, however you can boot from them. (Same is true of the newer Dells I've seen.) It's great to be able to just pop CD #1 into the drive, reset the machine, and go. It's also wonderful for recovery: boot from install CD, then select fixit mode using the live filesystem CD and presto! you have a whole recovery system running off CD. Now if you could boot from the life filesystem CD and have the kernel mount it as the rootfs... be still my heart. Old habits die hard though: I still spent ten minutes rummaging around for a floppy before it occured to me to try booting from CD. :) One thing I have noticed about the NCR SCSI subsystem though. While I was working on the driver I used a debugging kernel built using config -g. This results in a large kernel image because of all the debug symbols; typically the image was 9MB or so. (Of course used strip -d to make a second image to actually boot from; the debug image is just for gdb.) When time came to link the image, this naturally resulted in a lot of disk activity, however I noticed that during this time, there seemed to be a delay when trying to initiate disk I/O in another process. That is, if I switched to another terminal and tried to do an 'ls -l' on some directory (which hadn't been cached yet) while the kernel was linking, the 'ls' command would hang there for a second or so until the disk activity from the linker process died down. In other words, it seems as though one I/O bound process can sort of monopolize the SCSI bus. This could easily be SOP, but I hadn't noticed behavior like this with other hardware before. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805051527.LAA29903>