Date: Sat, 4 Nov 2000 10:15:57 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Randy Bush <randy@psg.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 68-80 on curdle second scsi chan Message-ID: <Pine.LNX.4.10.10011040934380.701-100000@linux.local> In-Reply-To: <E13rqfn-0000vT-00@rip.psg.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Nov 2000, Randy Bush wrote: Let me quote your message here: > i think it is terminated properly. the mobo termination is enabled. the= re > is a terminator at the end of the 68-pin cable, an LVD/SE TRM-8915 from= =20 > <http://www.scsi-cables.com/line/scsiterm.htm>. >=20 > i ain't sayin' that termination is not the problem. i am saying that, if= it > needs to be done differently, please apply clue-by-four. I just caught that you put the adapter on the LVD/SE cable. Your initial message was unclear to me and I thought your put it at adapter side. Based on the log messages below, the driver is telling that both channels are currently LVD mode: > >> sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > >> sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking Hmmm... I will not assume that you sent me the boot messages corresponding to the problem. If it was so, then the problem would be a termination problem, unless your old CD/ROMs are LVD capable which is pretty improbable. You must read at least the following when your CDROMs are connected, sym1: Symbios NVRAM, ID 7, Fast-40, SE, parity checking ^^ for the problem to have a chance not to be a termination problem. But this is not enough to make sure it is not a termination problem. G=E9rard. PS: The switching to SE mode of all devices on a SCSI BUS, including initiators and terminators is based on the electrical level of the DIFFSENS signal. On SE devices, this signal must be provided as grounded by the device and actually connected to the SCSI BUS. > >> the asus cur-dls has a sym dual controller > >>=20 > >> sym0: <896> port 0xb400-0xb4ff mem 0xf9000000-0xf9001fff,\ > >> 0xf9800000-0xf98003ff irq 9 at device 5.0 on pci1 > >> sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > >> sym0: open drain IRQ line driver, using on-chip SRAM > >> sym0: using LOAD/STORE-based firmware. > >> sym0: handling phase mismatch from SCRIPTS. > >> sym1: <896> port 0xb000-0xb0ff mem 0xf8000000-0xf8001fff,\ > >> 0xf8800000-0xf88003ff irq 9 at device 5.1 on pci1 > >> sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking > >> sym1: open drain IRQ line driver, using on-chip SRAM > >> sym1: using LOAD/STORE-based firmware. > >> sym1: handling phase mismatch from SCRIPTS. > >> (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > >> (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > >> da0 at sym0 bus 0 target 0 lun 0 > >> da1 at sym0 bus 0 target 1 lun 0 > >> Waiting 5 seconds for SCSI devices to settle > >> (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. > >> (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. > >> Mounting root from ufs:/dev/da0a > >> da0 at sym0 bus 0 target 0 lun 0 > >> da0: <IBM DDYS-T18350N S93E> Fixed Direct Access SCSI-3 device=20 > >> da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ > >> =09 Tagged Queueing Enabled > >> da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > >> da1 at sym0 bus 0 target 1 lun 0 > >> da1: <IBM DDYS-T18350N S93E> Fixed Direct Access SCSI-3 device=20 > >> da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), \ > >> =09 Tagged Queueing Enabled > >> da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > >>=20 > >> it seems quite happy with the two ultra-2 drives on a 68pin cable on c= han 0. > >>=20 > >> the second channel is also a 68pin. i want to put on two old cd-rom > >> drives. so i got a nicely terminated cable [0], and put on two 68m-to= -80 > >> adapters, see <http://www.scsi-cables.com/images/50large.gif>. > >>=20 > >> when booting, the system takes a loooooong time to scan the second scs= i > >> channel, and does not see the drives. > >>=20 > >> i am probably doing something very naive/stoopid. clues solicited. > >=20 > > It may well be a termination problem, in my opinion. > >=20 > > Given what you want to achieve, the Wide BUS must be terminated with SE > > (single ended signaling) at controller side and the Narrow one must be = SE > > terminated at the other end. > >=20 > > The Wide-to-Narrow adapter you are using seems to just connect the low > > part of the Wide BUS to its output and just doesn't care of the high pa= rt. > >=20 > > Cause can be, for example: > >=20 > > - If your SCSI controller uses some kind of auto-termination magic, it = may > > well be confused by your configuration and not terminate the Wide BUS= =20 > > properly at the controller side. > > - If there is no terminator (normally LVD/SE capable) on the controller= , > > then the BUS is just not terminated at this side. > >=20 > > Basically, as long as you cannot make sure that the BUS is actually > > terminated as required by the tinking you want to achieve, you should n= ot > > expect your SCSI system to work properly. >=20 > i think it is terminated properly. the mobo termination is enabled. the= re > is a terminator at the end of the 68-pin cable, an LVD/SE TRM-8915 from= =20 > <http://www.scsi-cables.com/line/scsiterm.htm>. >=20 > i ain't sayin' that termination is not the problem. i am saying that, if= it > needs to be done differently, please apply clue-by-four. >=20 > randy >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message 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.4.10.10011040934380.701-100000>