Date: Fri, 5 Nov 1999 23:47:57 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: Ollivier Robert <roberto@keltia.freenix.fr> Cc: scsi@FreeBSD.ORG Subject: Re: SYM driver available for -stable Message-ID: <Pine.LNX.3.95.991105232622.543A-100000@localhost> In-Reply-To: <19991104224808.A1140@keltia.freenix.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Nov 1999, Ollivier Robert wrote: > According to Gerard Roudier: > > I just made available SYM driver 0.9.0 as a tar file that contains full= =20 > > driver files. This avoids applying 8 nasty patches successively. >=20 > I'm now running with your new driver and it seems to run fine. Dunno real= ly if=20 > it faster or not (seems a bit but Bonnie -- a poor benchmark I know -- is > almost the same). BTW, I've the same problem with your driver than I had = with > the ncr one: the LED is constantly on... With the ncr driver, adding >=20 > options SCSI_NCR_SYMBIOS_COMPAT # for LEDs For controllers with NVRAM probed as SYMBIOS format, the driver should drive the LED, but I heven't tested it since my box has no available LED. I had proposed STefan this SCSI_NCR_SYMBIOS_COMPAT option since the ncr driver (and the Linux ncr53c8xx driver) was unable to read the NVRAM at this time. For now, the sym driver is not fully integrated in the kernel options scheme (this will happen for version 1.0). Options are gathered in the sym_conf.h file. You may edit this file, define SYMSETUP_SCSI_LED to 1 and let us know if the 810a now is just fine for your next Christmas tree. :)= =20 > "fixes" the problem. Which #define does the same for sym0 ? SYM_OPT_LED0 = ? >=20 > -------Sequential Output-------- ---Sequential Input-- --Ra= ndom-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Se= eks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /se= c %CPU > ncr0 200 4950 65.8 4938 20.7 1907 9.0 5665 47.8 5867 15.8 91.= 2 3.6 >=20 > -------Sequential Output-------- ---Sequential Input-- --Ra= ndom-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Se= eks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /se= c %CPU > sym0 200 4902 62.7 4627 16.8 1965 8.2 5005 40.8 5884 13.9 136.= 0 4.3 Some differences are strange, especially the random seek one. Even a 1542C against the fastest possible HBA/driver pair should not lead to a so large difference. The CPU difference seems a bit high too. If you have time for, could you check the effect of number of tags with your drive using the sym driver. Basically, the following values should be enough to check if this makes significant differences:=20 1 (no tags), 4, 8, 16. > The disk is an 5400 rpm IBM. >=20 > sym0: <875> irq 9 at device 11.0 on pci0 > sym0: Symbios NVRAM, ID 7, Fast-20, parity checking > sym0: open drain IRQ line driver, using on-chip SRAM > sym1: <810a> irq 11 at device 12.0 on pci0 > sym1: No NVRAM, ID 7, Fast-10, parity checking > sym0: Downloading SCSI SCRIPTS. > (noperiph:sym0:0:-1:-1): SCSI bus reset delivered. > Creating DISK da0 > Creating DISK da1 > Creating DISK da2 > Creating DISK da12 > da0 at sym0 bus 0 target 0 lun 0 > da0: <IBM DCAS-34330W S65A> Fixed Direct Access SCSI-2 device=20 > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing = Enabled > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) >=20 > BTW I got the following two messages when playing with camcontrol... >=20 > WARNING: driver xpt should register devices with make_dev() (dev_t =3D "#= xpt/0") > WARNING: driver pass should register devices with make_dev() (dev_t =3D "= #pass/0") G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991105232622.543A-100000>