Date: Sat, 9 May 1998 12:37:21 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: cdillon@wolves.k12.mo.us, hackers@FreeBSD.ORG, Eivind Eklund <eivind@yes.no> Subject: Re: Call for testers for ThunderLAN ethernet driver Message-ID: <19980509123721.29564@mi.uni-koeln.de> In-Reply-To: <199805051527.LAA29903@skynet.ctr.columbia.edu>; from Bill Paul on Tue, May 05, 1998 at 11:27:52AM -0400 References: <19980505165604.36955@follo.net> <199805051527.LAA29903@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1998-05-05 11:27 -0400, Bill Paul <wpaul@skynet.ctr.columbia.edu> wrote: > 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 I've got some other Compaq machine at work which can't be installed over the network currently for lack of a NetFlex / ThunderLan driver. When are you going to commit the driver ? > 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. Hmmm, that should not depend on the driver, actually. A simple test should be a "dd" to /dev/null from both /dev/rsd0c and /dev/sd0c and to measure the impact on the simultanous "ls -l". Then you should copy a large amount of data (/dev/zero :) into a file in the same partition were you perform the ls, and to another disk drive, if possible. The results of these tests should point out the effect of the buffer cache vs. raw accesses to the device, and of the driver vs. the drive (impact of large transfer to one drive on another drive ...) There has been quite some discussion of delays caused by the elevator algorithm in pathological cases, one or two years ago. (IIRC, writing huge amounts of data to a new file system could block other processes.) Regards, STefan 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?19980509123721.29564>