From owner-freebsd-scsi Sat Jan 1 7:28:41 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from piper.kspu.kr.ua (piper.kspu.kr.ua [195.5.1.122]) by hub.freebsd.org (Postfix) with ESMTP id 323DD14D7C for ; Sat, 1 Jan 2000 07:28:36 -0800 (PST) (envelope-from john@piper.kspu.kr.ua) Received: (from john@localhost) by piper.kspu.kr.ua (8.9.3/8.9.3) id RAA19826 for freebsd-scsi@FreeBSD.ORG; Sat, 1 Jan 2000 17:28:30 +0200 (EET) Date: Sat, 1 Jan 2000 17:28:30 +0200 From: John Savitsky To: freebsd-scsi@FreeBSD.ORG Subject: Re: SCB 0x34 timed out in dataout phase, Again (sorry) Message-ID: <20000101172830.A19801@kspu.kr.ua> Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: <19991221112014.A5291@kspu.kr.ua> <19991225164151.A24504@kspu.kr.ua> <19991226143408.A26528@kspu.kr.ua> <19991227172458.A87258@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991227172458.A87258@panzer.kdm.org>; from ken@kdm.org on Mon, Dec 27, 1999 at 05:24:58PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Happy New Y2K! ;-) On Mon, Dec 27, 1999 at 05:24:58PM -0700, Kenneth D. Merry wrote: > > It could be that your problem was that you were running 3.2. There is a > bug in the 7890 that Justin worked around shortly after 3.3 was released. > So with 3.4, you've got the fix. > > Anyway, if you continue to have problems, send mail to the list. After a while of testing, here the results. It is much less annoying bug that it was with the old drivers, but I have some problems anyway: o every time I taking a new tape and labeling it with amlabel, I getting a "(sa0:ahc0:0:3:0) tape is now frozen-" error. Note, that this error was absent before. o I still encounter a "time out in dataout phase" error (but less frequently, about 1 on 3--4 backups). > Ken > -- > Kenneth Merry > ken@kdm.org -- Sincerely yours, John Savitsky DE UR5VIB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 2 2: 0:20 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 84BF714BF2 for ; Sun, 2 Jan 2000 02:00:14 -0800 (PST) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id KAA25598; Sun, 2 Jan 2000 10:59:49 +0100 (MET) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.9.0/8.9.0) with ESMTP id LAA36530; Sun, 2 Jan 2000 11:00:17 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id KAA33340; Sun, 2 Jan 2000 10:59:46 +0100 (CET) (envelope-from ticso) Date: Sun, 2 Jan 2000 10:59:46 +0100 From: Bernd Walter To: Gerard Roudier Cc: freebsd-scsi@freebsd.org Subject: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000102105945.B33204@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm using the sym driver under FreeBSD alpha and I have two drives that are configured to need a start command. The drives in question are da6 and either da2 or da3. Usually I would think it's a problem in a general layer but the drive on the ahc0 apapter starts just fine. Some interesting side point - SRM can't boot from from the sym1 controller even if it's alone in the host but ARC can. The cards are nearly the same but sym1 already has the lsi logo and only sym0 has an external oszilator. ahc0@pci0:5:0: class=0x010000 card=0x78819004 chip=0x81789004 rev=0x01 hdr=0x00 sym0@pci0:6:0: class=0x010000 card=0x00000000 chip=0x00011000 rev=0x12 hdr=0x00 sym1@pci0:7:0: class=0x010000 card=0x10001000 chip=0x00011000 rev=0x23 hdr=0x00 FreeBSD 4.0-CURRENT #5: Sat Jan 1 17:31:50 CET 2000 root@:/var/d2/src-1999-12-18-fschange/src/sys/compile/CICELY9 EB164 Digital AlphaPC 164 500 MHz, 500MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x1000800020117 real memory = 64577536 (63064K bytes) avail memory = 57901056 (56544K bytes) Preloaded elf kernel "kernel" at 0xfffffc00005b8000. cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 ahc0: irq 2 at device 5.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: interrupting at CIA irq 2 sym0: <810a> irq 0 at device 6.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, parity checking sym0: interrupting at CIA irq 0 sym1: <810a> irq 1 at device 7.0 on pci0 sym1: No NVRAM, ID 7, Fast-10, parity checking sym1: interrupting at CIA irq 1 isab0: at device 8.0 on pci0 isa0: on isab0 de0: irq 3 at device 9.0 on pci0 de0: interrupting at CIA irq 3 de0: Cogent 21143 [10-100Mb/s] pass 2.1 de0: address 00:00:d1:19:de:1f ata-pci0: irq 5 at device 11.0 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 mcclock0: at port 0x70-0x71 on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o fdc0: interrupting at ISA irq 6 fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting at ISA irq 1 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> struct nfssvc_sock bloated (> 256bytes) Try reducing NFS_UIDHASHSIZ struct nfsuid bloated (> 128bytes) Try unionizing the nu_nickname and nu_flag fields Timecounter "alpha" frequency 500005500 Hz ad0: ATA-0 disk at ata0 as master ad0: 1219MB (2496816 sectors), 2477 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, PIO Waiting 15 seconds for SCSI devices to settle de0: enabling 100baseTX port de0: enabling Full Duplex 100baseTX port de0: link down: cable problem? da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da0: 1041MB (2131992 512 byte sectors: 255H 63S/T 132C) da2 at ahc0 bus 0 target 9 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da3 at ahc0 bus 0 target 10 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-CCS device da1: 3.300MB/s transfers da1: 638MB (1308087 512 byte sectors: 64H 32S/T 638C) da6 at sym1 bus 0 target 2 lun 0 da6: Fixed Direct Access SCSI-CCS device da6: 3.300MB/s transfers da6: 316MB (649040 512 byte sectors: 64H 32S/T 316C) da4 at sym0 bus 0 target 2 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 5.000MB/s transfers (5.000MHz, offset 7) da4: 103MB (210944 512 byte sectors: 64H 32S/T 103C) da5 at sym0 bus 0 target 4 lun 0 da5: Fixed Direct Access SCSI-CCS device da5: 3.300MB/s transfers da5: 405MB (830340 512 byte sectors: 64H 32S/T 405C) cd0 at sym1 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 8) cd0: cd present [314602 x 2048 byte records] da7 at sym1 bus 0 target 3 lun 0 da7: Fixed Direct Access SCSI-CCS device da7: 3.300MB/s transfers da7: 170MB (349770 512 byte sectors: 64H 32S/T 170C) Mounting root from ufs:/dev/da0a -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 2 13:14:21 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by hub.freebsd.org (Postfix) with ESMTP id D4FA914CAC for ; Sun, 2 Jan 2000 13:14:17 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-102-69.villette.club-internet.fr [194.158.102.69]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA05006; Sun, 2 Jan 2000 22:14:12 +0100 (MET) Date: Sun, 2 Jan 2000 22:41:21 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost Reply-To: Gerard Roudier To: Bernd Walter Cc: freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha In-Reply-To: <20000102105945.B33204@cicely8.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 2 Jan 2000, Bernd Walter wrote: > I'm using the sym driver under FreeBSD alpha and I have two drives that > are configured to need a start command. >=20 > The drives in question are da6 and either da2 or da3. > Usually I would think it's a problem in a general layer but the drive on = the > ahc0 apapter starts just fine. >=20 > Some interesting side point - SRM can't boot from from the sym1 > controller even if it's alone in the host but ARC can. I can't help you here, since I haven't ever played with alpha machines. > The cards are nearly the same but sym1 already has the lsi logo and only = sym0 > has an external oszilator. Could that mean that sym1 HA is taking the SCSI clock from the PCI BUS clock? This is fairly stupid since 10 Mega-transfers/second will not be possible using a 33 MHz SCSI clock, but this can obviously exist. Btw, the sym driver only detects 40MHz, 50MHz and 80MHz SCSI clock and assumes 40 MHz in such situation. A 33MHz wrongly assumed 40 MHz SCSI clock may slightly affect SCSI timing, but since the offending drive (da6) seems to want asynchronous transfers, I don't think such a SCSI clock mismatch to be the cause of the problem.=20 The XPT takes decision of starting the device unit based on the sense information returned by the device. The device (da6) should return CHECK CONDITION status on TUR (test unit ready command) and then provide the corresponding sense information on a subsequent REQUEST SENSE command. The REQUEST SENSE is automatically sent by the SIM (sym driver for da6) if a CHECK CONDITION status is returned.=20 It would be interesting to know how drive da6 responds to a TUR. You may use the following command and report result:=20 camcontrol tur da6 -v You probably noticed that the device is claiming SCSI-CCS which is kind of pre-scsi-2 standard. This may explain the difference if the sense data returned by the device are not understood by the CAM XPT. Just a guess.=20 I suggest you to play with 'camcontrol', and, for example, to send explicit start_stop commands to the device, try sync negotiations with it and see how it behaves.=20 G=E9rard.=20 Just quoting da2/3/6: =20 > da2 at ahc0 bus 0 target 9 lun 0 > da2: Fixed Direct Access SCSI-2 device=20 > da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing E= nabled > da2: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) > da3 at ahc0 bus 0 target 10 lun 0 > da3: Fixed Direct Access SCSI-2 device=20 > da3: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing E= nabled > da3: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) > da6 at sym1 bus 0 target 2 lun 0 > da6: Fixed Direct Access SCSI-CCS device=20 > da6: 3.300MB/s transfers > da6: 316MB (649040 512 byte sectors: 64H 32S/T 316C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 2 14:40:27 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 9230C14DE6 for ; Sun, 2 Jan 2000 14:40:09 -0800 (PST) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id XAA18117; Sun, 2 Jan 2000 23:39:44 +0100 (MET) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.9.0/8.9.0) with ESMTP id XAA38113; Sun, 2 Jan 2000 23:40:16 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id XAA87641; Sun, 2 Jan 2000 23:39:45 +0100 (CET) (envelope-from ticso) Date: Sun, 2 Jan 2000 23:39:44 +0100 From: Bernd Walter To: Gerard Roudier Cc: Bernd Walter , freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000102233944.B87267@cicely8.cicely.de> References: <20000102105945.B33204@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 02, 2000 at 10:41:21PM +0100, Gerard Roudier wrote: > > On Sun, 2 Jan 2000, Bernd Walter wrote: > > > I'm using the sym driver under FreeBSD alpha and I have two drives that > > are configured to need a start command. > > > > The drives in question are da6 and either da2 or da3. > > Usually I would think it's a problem in a general layer but the drive on the > > ahc0 apapter starts just fine. > > > > Some interesting side point - SRM can't boot from from the sym1 > > controller even if it's alone in the host but ARC can. > > I can't help you here, since I haven't ever played with alpha machines. I asume noone can help me here beside digital/compaq - I just wanted to note this. It causes no problems for me because I can boot with the other controller. > > > The cards are nearly the same but sym1 already has the lsi logo and only sym0 > > has an external oszilator. > > Could that mean that sym1 HA is taking the SCSI clock from the PCI BUS > clock? This is fairly stupid since 10 Mega-transfers/second will not be > possible using a 33 MHz SCSI clock, but this can obviously exist. Btw, the > sym driver only detects 40MHz, 50MHz and 80MHz SCSI clock and assumes 40 > MHz in such situation. A 33MHz wrongly assumed 40 MHz SCSI clock may > slightly affect SCSI timing, but since the offending drive (da6) seems to > want asynchronous transfers, I don't think such a SCSI clock mismatch to > be the cause of the problem. I don't know where they get the clock from and the only sync device on this bus is the cdrom which is negotiated with the usual frequency for this kind of drive. I have the same controller in an i386 host using the old ncr driver and both drives are negotiated to 10MHz. Wonder if it realy does 10MHz? One of the disks can do nearly 10MB/sec if the data is in the cache - and it does less currently. There's free space for an Oszilator on the PCB - Guess I should solder one. I remember that there is a configuration wire soldered which might have something to do with the clock - Maybe that's the reason for the SRM problem. > The XPT takes decision of starting the device unit based on the sense > information returned by the device. The device (da6) should return CHECK > CONDITION status on TUR (test unit ready command) and then provide the > corresponding sense information on a subsequent REQUEST SENSE command. The > REQUEST SENSE is automatically sent by the SIM (sym driver for da6) if a > CHECK CONDITION status is returned. > > It would be interesting to know how drive da6 responds to a TUR. You may > use the following command and report result: > > camcontrol tur da6 -v > bash-2.03# camcontrol tur -u 6 -n da Unit is not ready nothing unusual here. > You probably noticed that the device is claiming SCSI-CCS which is kind of > pre-scsi-2 standard. This may explain the difference if the sense data > returned by the device are not understood by the CAM XPT. Just a guess. That's a possible reason - I never thought about something special with the drive as I never got such problems - but all of my other CCS drives start up direct after power-on. Nevertheless TUR shows that the drive returns te right sense so it's not the TUR itself what confuses XPT. > I suggest you to play with 'camcontrol', and, for example, to send > explicit start_stop commands to the device, try sync negotiations with it > and see how it behaves. The drive can't do sync transfers so async is correct. There is nothing unusual beside that I need to manualy send a start command to the drive. Anyway if you think it has nothing to do with your driver and it's not worth to think about the reason - I can live with it as it's only a camcontrol command in /etc/rc . I just worried it might happen on other drives too. > > da6 at sym1 bus 0 target 2 lun 0 > > da6: Fixed Direct Access SCSI-CCS device > > da6: 3.300MB/s transfers > > da6: 316MB (649040 512 byte sectors: 64H 32S/T 316C) -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 2 19:23: 1 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles551.castles.com [208.214.165.115]) by hub.freebsd.org (Postfix) with ESMTP id 7868414E14 for ; Sun, 2 Jan 2000 19:22:56 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id TAA13368; Sun, 2 Jan 2000 19:28:05 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001030328.TAA13368@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bernd Walter Cc: Gerard Roudier , freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha In-reply-to: Your message of "Sun, 02 Jan 2000 23:39:44 +0100." <20000102233944.B87267@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Jan 2000 19:28:05 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Some interesting side point - SRM can't boot from from the sym1 > > > controller even if it's alone in the host but ARC can. > > > > I can't help you here, since I haven't ever played with alpha machines. > > I asume noone can help me here beside digital/compaq - I just wanted to > note this. It's probably an issue because your SRM doesn't recognise the controller as being something it supports. You _may_ be able to improve the situation by updating to a more recent SRM. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 2 23:42:51 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 7A2B014F39; Sun, 2 Jan 2000 23:42:48 -0800 (PST) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id IAA18631; Mon, 3 Jan 2000 08:42:25 +0100 (MET) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.9.0/8.9.0) with ESMTP id IAA39541; Mon, 3 Jan 2000 08:42:57 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id IAA88444; Mon, 3 Jan 2000 08:42:28 +0100 (CET) (envelope-from ticso) Date: Mon, 3 Jan 2000 08:42:27 +0100 From: Bernd Walter To: Mike Smith Cc: Bernd Walter , Gerard Roudier , freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000103084227.A88428@cicely8.cicely.de> References: <20000102233944.B87267@cicely8.cicely.de> <200001030328.TAA13368@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200001030328.TAA13368@mass.cdrom.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 02, 2000 at 07:28:05PM -0800, Mike Smith wrote: > > > > Some interesting side point - SRM can't boot from from the sym1 > > > > controller even if it's alone in the host but ARC can. > > > > > > I can't help you here, since I haven't ever played with alpha machines. > > > > I asume noone can help me here beside digital/compaq - I just wanted to > > note this. > > It's probably an issue because your SRM doesn't recognise the controller > as being something it supports. You _may_ be able to improve the > situation by updating to a more recent SRM. > It is already the newest. SRM detects the controller as an 810 just like the other controller but sh device does not show any device on this controller including ID7. I will try to get another clock source ASAP just to see if it's the reason. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 1: 4:36 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 94ADD14FDD for ; Mon, 3 Jan 2000 01:04:33 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id KAA23891; Mon, 3 Jan 2000 10:00:34 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA15691; Sun, 2 Jan 2000 23:15:52 +0100 (CET) (envelope-from wilko) Date: Sun, 2 Jan 2000 23:15:52 +0100 From: Wilko Bulte To: Gerard Roudier Cc: Bernd Walter , freebsd-scsi@FreeBSD.ORG Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000102231552.A15615@yedi.iaf.nl> References: <20000102105945.B33204@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from groudier@club-internet.fr on Sun, Jan 02, 2000 at 10:41:21PM +0100 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 02, 2000 at 10:41:21PM +0100, Gerard Roudier wrote: > On Sun, 2 Jan 2000, Bernd Walter wrote: > > > I'm using the sym driver under FreeBSD alpha and I have two drives that > > are configured to need a start command. > > > > The drives in question are da6 and either da2 or da3. > > Usually I would think it's a problem in a general layer but the drive on the > > ahc0 apapter starts just fine. > > > > Some interesting side point - SRM can't boot from from the sym1 > > controller even if it's alone in the host but ARC can. > > I can't help you here, since I haven't ever played with alpha machines. For Alpha's to be able to boot from an adapter it must be known by the SRM code. This means an ncr810(a) or (some SRM versions only) ncr875 chips. Or a QLogic 10[24]0 based card. ncr810 cards are known as KZPAA and Qlogic is known as KZPBA in DEC speak. -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 5:39: 7 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from relativity.student.utwente.nl (wit389306.student.utwente.nl [130.89.234.166]) by hub.freebsd.org (Postfix) with ESMTP id D184F1510A for ; Mon, 3 Jan 2000 05:39:02 -0800 (PST) (envelope-from djb@Wit389306.student.utwente.nl) Received: by relativity.student.utwente.nl (Postfix, from userid 1001) id 052241E2F; Mon, 3 Jan 2000 14:38:54 +0100 (CET) Date: Mon, 3 Jan 2000 14:38:54 +0100 From: "Dave J. Boers" To: freebsd-scsi@freebsd.org Subject: n/a Message-ID: <20000103143854.A460@relativity.student.utwente.nl> Reply-To: djb@relativity.student.utwente.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 13:39:54 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id DA29A15126 for ; Mon, 3 Jan 2000 13:39:49 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id QAA00905 for ; Mon, 3 Jan 2000 16:39:48 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Mon, 3 Jan 2000 16:39:48 -0500 (EST) From: Adam To: scsi@freebsd.org Subject: sym troubles Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I dont recall if this happened when I tried the driver last (two weeks ago) but a -current from today does this for me: Jan 3 16:00:13 sapphire /kernel: sym0: <875> irq 10 at device 15.0 on pci0 Jan 3 16:00:13 sapphire /kernel: sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking Jan 3 16:00:40 sapphire /kernel: cd1 at sym0 bus 0 target 3 lun 0 Jan 3 16:00:40 sapphire /kernel: cd1: Removable C D-ROM SCSI-2 device Jan 3 16:00:40 sapphire /kernel: cd1: 6.600MB/s transfers (16bit) Jan 3 16:00:40 sapphire /kernel: cd1: Attempt to query device size failed: NOT READY, Medium not present This is a UltraWide cdrom drive so it should show 40MB/sec right? Jan 3 16:36:07 sapphire /kernel: ncr0: irq 11 at device 15.0 on pci0 Jan 3 16:36:48 sapphire /kernel: cd1 at ncr0 bus 0 target 3 lun 0 Jan 3 16:36:48 sapphire /kernel: cd1: Removable C D-ROM SCSI-2 device Jan 3 16:36:48 sapphire /kernel: cd1: 40.000MB/s transfers (20.000MHz, offset 1 5, 16bit) Jan 3 16:36:48 sapphire /kernel: cd1: Attempt to query device size failed: NOT READY, Medium not present To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 13:44:33 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0121515098 for ; Mon, 3 Jan 2000 13:44:31 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA06728; Mon, 3 Jan 2000 13:42:08 -0800 Date: Mon, 3 Jan 2000 13:44:19 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Umm- at 6.6MB/s, I'd guess that the midlayer isn't seeing SYNC MODE being set, so it's taking the default ASYNC speed (3.3MB/s) and doubling it for a wide bus. It may in fact be running at full rates and this is just a reporting foulup. On Mon, 3 Jan 2000, Adam wrote: > I dont recall if this happened when I tried the driver last (two weeks > ago) but a -current from today does this for me: > > Jan 3 16:00:13 sapphire /kernel: sym0: <875> irq 10 at device 15.0 on > pci0 > Jan 3 16:00:13 sapphire /kernel: sym0: Tekram NVRAM, ID 7, Fast-20, SE, > parity > checking > Jan 3 16:00:40 sapphire /kernel: cd1 at sym0 bus 0 target 3 lun 0 > Jan 3 16:00:40 sapphire /kernel: cd1: > Removable C > D-ROM SCSI-2 device > Jan 3 16:00:40 sapphire /kernel: cd1: 6.600MB/s transfers (16bit) > Jan 3 16:00:40 sapphire /kernel: cd1: Attempt to query device size > failed: NOT > READY, Medium not present > > This is a UltraWide cdrom drive so it should show 40MB/sec right? > > > Jan 3 16:36:07 sapphire /kernel: ncr0: irq > 11 at > device 15.0 on pci0 > Jan 3 16:36:48 sapphire /kernel: cd1 at ncr0 bus 0 target 3 lun 0 > Jan 3 16:36:48 sapphire /kernel: cd1: > Removable C > D-ROM SCSI-2 device > Jan 3 16:36:48 sapphire /kernel: cd1: 40.000MB/s transfers (20.000MHz, > offset 1 > 5, 16bit) > Jan 3 16:36:48 sapphire /kernel: cd1: Attempt to query device size > failed: NOT > READY, Medium not present > > > > > 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 From owner-freebsd-scsi Mon Jan 3 13:55:57 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id B36FD1500C for ; Mon, 3 Jan 2000 13:55:54 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id QAA01029; Mon, 3 Jan 2000 16:55:51 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Mon, 3 Jan 2000 16:55:51 -0500 (EST) From: Adam To: Matthew Jacob Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm, I wonder if theres any way to find out.. 40x * 150 is only 6MB/sec so it wouldnt be noticable if I did a speed test, and I have it alone on a bus so I wouldn't be able to tell if it slowed down other things either. So I guess all I can do is test patches :P The cdrom and controller are sort-of spare parts for me, so it isnt a critical issue to fix. I have a Tekram 390F btw. On Mon, 3 Jan 2000, Matthew Jacob wrote: > > >Umm- at 6.6MB/s, I'd guess that the midlayer isn't seeing SYNC MODE being >set, so it's taking the default ASYNC speed (3.3MB/s) and doubling it for >a wide bus. > >It may in fact be running at full rates and this is just a reporting >foulup. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 14:10: 5 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 213CC1500C for ; Mon, 3 Jan 2000 14:09:59 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA06807; Mon, 3 Jan 2000 14:07:42 -0800 Date: Mon, 3 Jan 2000 14:09:53 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Usually drives cache some amount of info- CDs, maybe not. Use the attached to find out. > Hmm, I wonder if theres any way to find out.. 40x * 150 is only 6MB/sec so > it wouldnt be noticable if I did a speed test, and I have it alone on a > bus so I wouldn't be able to tell if it slowed down other things > either. So I guess all I can do is test patches :P The cdrom and > controller are sort-of spare parts for me, so it isnt a critical issue to > fix. I have a Tekram 390F btw. > > On Mon, 3 Jan 2000, Matthew Jacob wrote: /* * Copyright (c) 1998, Matthew Jacob * * This software is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; version 2. * * This software is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Library General Public License for more details. * * You should have received a copy of the GNU Library General Public * License along with this software; if not, write to the Free * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * The author may be reached via electronic communications at * * mjacob@feral.com * * or, via United States Postal Address * * Matthew Jacob * 1831 Castro Street * San Francisco, CA, 94131 * *************************************************************************** */ #include #include #include #include #include #if defined(__osf__) || defined(__linux__) || defined(__FreeBSD__) #include #else #include #endif #include #include #ifdef __linux__ #include #endif static unsigned long szarg(char *); static char *progname(char *); int main(int a, char **v) { int (*iofunc)(int, char *, int); int fd, r, oflags; unsigned long blksize, offset, nblks, count, loc, etime; struct timeval st, et; char *name, *bptr; double kbsec; if (a != 5) { fprintf(stderr, "Usage: %s device blksize offsetblk nblks\n", *v); return (1); } if (strcmp(progname(v[0]), "rdsame") == 0) { iofunc = (int (*)())read; oflags = O_RDONLY; } else { iofunc = (int (*)())write; oflags = O_WRONLY; } name = v[1]; blksize = szarg(v[2]); offset = szarg(v[3]); nblks = szarg(v[4]); bptr = malloc(blksize); if (bptr == NULL) { perror("malloc"); return (1); } fd = open(name, oflags); if (fd < 0) { perror(name); return (1); } #ifdef __linux__ if (ioctl (fd, BLKFLSBUF, 0) < 0) { perror("BLKFLSBUF"); } #endif loc = offset * blksize; if (gettimeofday(&st, (struct timezone *) 0) < 0) { perror("gettimeofday"); return (1); } for (count = 0; count < nblks; count++) { if (lseek(fd, loc, 0) != loc) { perror("lseek"); return (1); } if ((r = (*iofunc)(fd, bptr, (int) blksize)) != (int) blksize) { fprintf(stderr, "I/O returned %d, err is %s\n", r, strerror(errno)); return (1); } } if (gettimeofday(&et, (struct timezone *) 0) < 0) { perror("\ngettimeofday"); return (1); } etime = et.tv_sec - st.tv_sec; if (et.tv_usec < st.tv_usec) { etime--; etime *= 1000000; etime += (et.tv_usec + 1000000 - st.tv_usec); } else { etime *= 1000000; etime += (et.tv_usec - st.tv_usec); } kbsec = (double) blksize * (double) count; /* total bytes */ kbsec /= (double) 1024.0; kbsec *= (double) 1000000.0; kbsec /= (double) etime; fprintf(stdout, "%s %ld bytes in %d.%d seconds, %5.2fKB/sec in %ld " "byte blocks\n", (oflags == O_RDONLY)? "Read" : "Wrote", blksize * count, etime / 1000000, etime % 1000000, kbsec, blksize); return (0); } static unsigned long szarg(char *n) { register int shift = 0; register char s, *q = n; unsigned long result; while (*q != (char) 0) q++; q--; if (*q == 'b' || *q == 'B') q--; s = *q; if (*q == 'k' || *q == 'K') { shift = 10; *q = 0; } else if (*q == 'm' || *q == 'M') { shift = 20; *q = 0; } else if (*q == 'g' || *q == 'G') { shift = 30; *q = 0; } result = strtoul((const char *)n, (char **) NULL, 0) << shift; *q = s; return (result); } static char * progname(char *name) { char *p = strrchr(name, '/'); if (p) return (++p); else return (name); } /* * --------------------------------------------------------------------------- * Local variables: * c-indent-level: 4 * c-brace-imaginary-offset: 0 * c-brace-offset: -4 * c-argdecl-indent: 4 * c-label-offset: -4 * c-continued-statement-offset: 4 * c-continued-brace-offset: 0 * End: */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 14:24:20 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by hub.freebsd.org (Postfix) with ESMTP id 1F4D214D7F for ; Mon, 3 Jan 2000 14:24:13 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-159-49.villette.club-internet.fr [195.36.159.49]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA14101; Mon, 3 Jan 2000 23:23:21 +0100 (MET) Date: Mon, 3 Jan 2000 23:51:01 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, The sym driver gets USER settings of SCSI devices from controller NVRAM and reports these values as USER settings to CAM. The XPT just suggests SIM to apply USER settings at initialization. But you can manually change to better settings using camcontrol, once the system is up.=20 Could you check how the device is user-configured in the NVRAM ? You may let me know if the sym driver is not behaving as it should regarding sync/wide negotiation. Thanks. I will provide a man page for the sym driver, but I donnot have found time= =20 for writing it for the moment. Regards, G=E9rard. On Mon, 3 Jan 2000, Adam wrote: > I dont recall if this happened when I tried the driver last (two weeks > ago) but a -current from today does this for me: >=20 > Jan 3 16:00:13 sapphire /kernel: sym0: <875> irq 10 at device 15.0 on > pci0 > Jan 3 16:00:13 sapphire /kernel: sym0: Tekram NVRAM, ID 7, Fast-20, SE, > parity=20 > checking > Jan 3 16:00:40 sapphire /kernel: cd1 at sym0 bus 0 target 3 lun 0 > Jan 3 16:00:40 sapphire /kernel: cd1: > Removable C > D-ROM SCSI-2 device=20 > Jan 3 16:00:40 sapphire /kernel: cd1: 6.600MB/s transfers (16bit) > Jan 3 16:00:40 sapphire /kernel: cd1: Attempt to query device size > failed: NOT=20 > READY, Medium not present >=20 > This is a UltraWide cdrom drive so it should show 40MB/sec right? >=20 >=20 > Jan 3 16:36:07 sapphire /kernel: ncr0: irq > 11 at=20 > device 15.0 on pci0 > Jan 3 16:36:48 sapphire /kernel: cd1 at ncr0 bus 0 target 3 lun 0 > Jan 3 16:36:48 sapphire /kernel: cd1: > Removable C > D-ROM SCSI-2 device=20 > Jan 3 16:36:48 sapphire /kernel: cd1: 40.000MB/s transfers (20.000MHz, > offset 1 > 5, 16bit) > Jan 3 16:36:48 sapphire /kernel: cd1: Attempt to query device size > failed: NOT=20 > READY, Medium not present To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 15:12:11 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by hub.freebsd.org (Postfix) with ESMTP id 766E914BC9 for ; Mon, 3 Jan 2000 15:11:59 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-107-87.villette.club-internet.fr [194.158.107.87]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA28811; Tue, 4 Jan 2000 00:11:54 +0100 (MET) Date: Tue, 4 Jan 2000 00:39:08 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Bernd Walter Cc: freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha In-Reply-To: <20000102233944.B87267@cicely8.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 2 Jan 2000, Bernd Walter wrote: > On Sun, Jan 02, 2000 at 10:41:21PM +0100, Gerard Roudier wrote: > >=20 > > On Sun, 2 Jan 2000, Bernd Walter wrote: > > The XPT takes decision of starting the device unit based on the sense > > information returned by the device. The device (da6) should return CHEC= K > > CONDITION status on TUR (test unit ready command) and then provide the > > corresponding sense information on a subsequent REQUEST SENSE command. = The > > REQUEST SENSE is automatically sent by the SIM (sym driver for da6) if = a > > CHECK CONDITION status is returned.=20 > >=20 > > It would be interesting to know how drive da6 responds to a TUR. You ma= y > > use the following command and report result:=20 > >=20 > > camcontrol tur da6 -v > >=20 > bash-2.03# camcontrol tur -u 6 -n da > Unit is not ready I was expecting the whole sense data or at least asc/ascq values. There are numerous way to be not ready for a device and only one is documented by SCSI as suggesting a start command to be sent by the initiator. Values are ASC=3D4, ASCQ=3D2 ASC=3D4 means 'not ready', ASCQ value tells about the reason or suggests th= e=20 next action to apply. ASCQ=3D2 when ASC=3D4 suggest initializing command to= be=20 sent to the device. If your device does not return these values, then quirked it should be, in my opinion. 'man camcontrol' talk about the -v option used with tur subcommand to display sense data in case of CHECK CONDITION. Could you give a try with the -v option and report result. > nothing unusual here. But not enough to make sure CAM received relevant information from the device. > > You probably noticed that the device is claiming SCSI-CCS which is kind= of > > pre-scsi-2 standard. This may explain the difference if the sense data > > returned by the device are not understood by the CAM XPT. Just a guess.= =20 >=20 > That's a possible reason - I never thought about something special with > the drive as I never got such problems - but all of my other CCS drives > start up direct after power-on. > Nevertheless TUR shows that the drive returns te right sense so it's not > the TUR itself what confuses XPT. May-be the XPT has not been confused but just misinformed by the device. > > I suggest you to play with 'camcontrol', and, for example, to send > > explicit start_stop commands to the device, try sync negotiations with = it > > and see how it behaves.=20 >=20 > The drive can't do sync transfers so async is correct. Ok. =20 > There is nothing unusual beside that I need to manualy send a start comma= nd > to the drive. >=20 > Anyway if you think it has nothing to do with your driver and it's not wo= rth > to think about the reason - I can live with it as it's only a camcontrol > command in /etc/rc . I just worried it might happen on other drives too. By the way, some devices seem already quirked in scsi_all.c for CAM to send them a start command appropriately. :) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 17:31:32 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id DE65814C26 for ; Mon, 3 Jan 2000 17:31:29 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id UAA02456; Mon, 3 Jan 2000 20:30:12 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Mon, 3 Jan 2000 20:30:12 -0500 (EST) From: Adam To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you mean the wide and mhz settings in the card "bios" setup (F2 at boot), I have the cdrom set to wide and 20mhz. I just noticed too that it reports the proper speeds when the cdrom drive contains a cdrom during boot.=20 On Mon, 3 Jan 2000, Gerard Roudier wrote: > >Hello, > >The sym driver gets USER settings of SCSI devices from controller NVRAM >and reports these values as USER settings to CAM. The XPT just suggests >SIM to apply USER settings at initialization. But you can manually change >to better settings using camcontrol, once the system is up.=20 > >Could you check how the device is user-configured in the NVRAM ? >You may let me know if the sym driver is not behaving as it should >regarding sync/wide negotiation. Thanks. > >I will provide a man page for the sym driver, but I donnot have found time= =20 >for writing it for the moment. > >Regards, > G=E9rard. > >On Mon, 3 Jan 2000, Adam wrote: > >> I dont recall if this happened when I tried the driver last (two weeks >> ago) but a -current from today does this for me: >>=20 >> Jan 3 16:00:13 sapphire /kernel: sym0: <875> irq 10 at device 15.0 on >> pci0 >> Jan 3 16:00:13 sapphire /kernel: sym0: Tekram NVRAM, ID 7, Fast-20, SE, >> parity=20 >> checking >> Jan 3 16:00:40 sapphire /kernel: cd1 at sym0 bus 0 target 3 lun 0 >> Jan 3 16:00:40 sapphire /kernel: cd1: >> Removable C >> D-ROM SCSI-2 device=20 >> Jan 3 16:00:40 sapphire /kernel: cd1: 6.600MB/s transfers (16bit) >> Jan 3 16:00:40 sapphire /kernel: cd1: Attempt to query device size >> failed: NOT=20 >> READY, Medium not present >>=20 >> This is a UltraWide cdrom drive so it should show 40MB/sec right? >>=20 >>=20 >> Jan 3 16:36:07 sapphire /kernel: ncr0: ir= q >> 11 at=20 >> device 15.0 on pci0 >> Jan 3 16:36:48 sapphire /kernel: cd1 at ncr0 bus 0 target 3 lun 0 >> Jan 3 16:36:48 sapphire /kernel: cd1: >> Removable C >> D-ROM SCSI-2 device=20 >> Jan 3 16:36:48 sapphire /kernel: cd1: 40.000MB/s transfers (20.000MHz, >> offset 1 >> 5, 16bit) >> Jan 3 16:36:48 sapphire /kernel: cd1: Attempt to query device size >> failed: NOT=20 >> READY, Medium not present > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 17:32: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 9842B14C26 for ; Mon, 3 Jan 2000 17:32:01 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id UAA02472; Mon, 3 Jan 2000 20:32:00 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Mon, 3 Jan 2000 20:32:00 -0500 (EST) From: Adam To: Matthew Jacob Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (user1)sapphire:/root % ./stuff Usage: ./stuff device blksize offsetblk nblks Huh? On Mon, 3 Jan 2000, Matthew Jacob wrote: > >Usually drives cache some amount of info- CDs, maybe not. Use the attached >to find out. > > >> On Mon, 3 Jan 2000, Matthew Jacob wrote: >/* > * Copyright (c) 1998, Matthew Jacob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 17:49:53 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1E79E1511D for ; Mon, 3 Jan 2000 17:49:52 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id RAA07312; Mon, 3 Jan 2000 17:47:38 -0800 Date: Mon, 3 Jan 2000 17:49:49 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org semuta.feral.com > root rdsame /dev/rwd0c 2k 0 1000 Read 2048000 bytes in 0.866316 seconds, 2308.63KB/sec in 2048 byte blocks semuta.feral.com > root rdsame /dev/rwd0c 1k 0 10 Read 10240 bytes in 0.6581 seconds, 1519.53KB/sec in 1024 byte blocks ... reads from device in blocksize blocks (m or k suffix to indicate KByte or MByte) starting at seek offset OFFSETBLK repeated NBLKS times. On Mon, 3 Jan 2000, Adam wrote: > (user1)sapphire:/root % ./stuff > Usage: ./stuff device blksize offsetblk nblks > Huh? > > On Mon, 3 Jan 2000, Matthew Jacob wrote: > > > > >Usually drives cache some amount of info- CDs, maybe not. Use the attached > >to find out. > > > > > >> On Mon, 3 Jan 2000, Matthew Jacob wrote: > >/* > > * Copyright (c) 1998, Matthew Jacob > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 20: 0: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 07F7D15189 for ; Mon, 3 Jan 2000 19:59:58 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id WAA03413; Mon, 3 Jan 2000 22:59:46 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Mon, 3 Jan 2000 22:59:46 -0500 (EST) From: Adam To: Matthew Jacob Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ah. but would this help seeing as how the max speed of a 40x cdrom would be 40 * 150kb/sec = 6MB/sec? On Mon, 3 Jan 2000, Matthew Jacob wrote: > >semuta.feral.com > root rdsame /dev/rwd0c 2k 0 1000 >Read 2048000 bytes in 0.866316 seconds, 2308.63KB/sec in 2048 byte blocks >semuta.feral.com > root rdsame /dev/rwd0c 1k 0 10 >Read 10240 bytes in 0.6581 seconds, 1519.53KB/sec in 1024 byte blocks > >... > >reads from device in blocksize blocks (m or k suffix to indicate KByte or >MByte) starting at seek offset OFFSETBLK repeated NBLKS times. > > >On Mon, 3 Jan 2000, Adam wrote: > >> (user1)sapphire:/root % ./stuff >> Usage: ./stuff device blksize offsetblk nblks >> Huh? >> >> On Mon, 3 Jan 2000, Matthew Jacob wrote: >> >> > >> >Usually drives cache some amount of info- CDs, maybe not. Use the attached >> >to find out. >> > >> > >> >> On Mon, 3 Jan 2000, Matthew Jacob wrote: >> >/* >> > * Copyright (c) 1998, Matthew Jacob >> > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 21: 9:59 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0CBBB14E54 for ; Mon, 3 Jan 2000 21:09:55 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id VAA07767; Mon, 3 Jan 2000 21:07:40 -0800 Date: Mon, 3 Jan 2000 21:09:52 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not if the xfer size is small enough such that it's held in the drive's buffer, in which case the bus speed should show up. On Mon, 3 Jan 2000, Adam wrote: > Ah. but would this help seeing as how the max speed of a 40x cdrom would > be 40 * 150kb/sec = 6MB/sec? > > On Mon, 3 Jan 2000, Matthew Jacob wrote: > > > > >semuta.feral.com > root rdsame /dev/rwd0c 2k 0 1000 > >Read 2048000 bytes in 0.866316 seconds, 2308.63KB/sec in 2048 byte blocks > >semuta.feral.com > root rdsame /dev/rwd0c 1k 0 10 > >Read 10240 bytes in 0.6581 seconds, 1519.53KB/sec in 1024 byte blocks > > > >... > > > >reads from device in blocksize blocks (m or k suffix to indicate KByte or > >MByte) starting at seek offset OFFSETBLK repeated NBLKS times. > > > > > >On Mon, 3 Jan 2000, Adam wrote: > > > >> (user1)sapphire:/root % ./stuff > >> Usage: ./stuff device blksize offsetblk nblks > >> Huh? > >> > >> On Mon, 3 Jan 2000, Matthew Jacob wrote: > >> > >> > > >> >Usually drives cache some amount of info- CDs, maybe not. Use the attached > >> >to find out. > >> > > >> > > >> >> On Mon, 3 Jan 2000, Matthew Jacob wrote: > >> >/* > >> > * Copyright (c) 1998, Matthew Jacob > >> > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 21:20:52 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 6FC8B14EB0 for ; Mon, 3 Jan 2000 21:20:49 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA10054; Mon, 3 Jan 2000 22:19:08 -0700 (MST) (envelope-from ken) Date: Mon, 3 Jan 2000 22:19:08 -0700 From: "Kenneth D. Merry" To: Gerard Roudier Cc: Bernd Walter , freebsd-scsi@FreeBSD.ORG Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000103221908.A10024@panzer.kdm.org> References: <20000102233944.B87267@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from groudier@club-internet.fr on Tue, Jan 04, 2000 at 12:39:08AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 04, 2000 at 00:39:08 +0100, Gerard Roudier wrote: > On Sun, 2 Jan 2000, Bernd Walter wrote: > > On Sun, Jan 02, 2000 at 10:41:21PM +0100, Gerard Roudier wrote: > > > On Sun, 2 Jan 2000, Bernd Walter wrote: > > > The XPT takes decision of starting the device unit based on the sense > > > information returned by the device. The device (da6) should return CHECK > > > CONDITION status on TUR (test unit ready command) and then provide the > > > corresponding sense information on a subsequent REQUEST SENSE command. The > > > REQUEST SENSE is automatically sent by the SIM (sym driver for da6) if a > > > CHECK CONDITION status is returned. > > > > > > It would be interesting to know how drive da6 responds to a TUR. You may > > > use the following command and report result: > > > > > > camcontrol tur da6 -v > > > > > bash-2.03# camcontrol tur -u 6 -n da > > Unit is not ready > > I was expecting the whole sense data or at least asc/ascq values. There > are numerous way to be not ready for a device and only one is documented by > SCSI as suggesting a start command to be sent by the initiator. > Values are ASC=4, ASCQ=2 > ASC=4 means 'not ready', ASCQ value tells about the reason or suggests the > next action to apply. ASCQ=2 when ASC=4 suggest initializing command to be > sent to the device. > > If your device does not return these values, then quirked it should be, in > my opinion. Yes, it should be quirked if it doesn't return the usual values. There is already one precedent for this, and a second I've had sitting in my tree for a good while. > 'man camcontrol' talk about the -v option used with tur subcommand to > display sense data in case of CHECK CONDITION. Could you give a try with > the -v option and report result. Yep, we can't really determine anything about the cause of the problem without sense information. > > Anyway if you think it has nothing to do with your driver and it's not worth > > to think about the reason - I can live with it as it's only a camcontrol > > command in /etc/rc . I just worried it might happen on other drives too. > > By the way, some devices seem already quirked in scsi_all.c for CAM to > send them a start command appropriately. :) Quantum decided to return a vendor-specific ASC/ASCQ with their Fireball ST drives when they aren't spun up. I'm not sure why, but this is just another example of Quantum's "skill" when it comes to writing firmware. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 21:52:41 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id D63F014CDE; Mon, 3 Jan 2000 21:52:33 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA10347; Mon, 3 Jan 2000 22:52:25 -0700 (MST) (envelope-from ken) Date: Mon, 3 Jan 2000 22:52:25 -0700 From: "Kenneth D. Merry" To: Bill Swingle Cc: scsi@FreeBSD.ORG, Mike Smith , gibbs@FreeBSD.ORG Subject: Re: Invalidating pack messages Message-ID: <20000103225224.B10024@panzer.kdm.org> References: <19991228162311.A15296@dub.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991228162311.A15296@dub.net>; from unfurl@dub.net on Tue, Dec 28, 1999 at 04:23:11PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 28, 1999 at 16:23:11 -0800, Bill Swingle wrote: > Hey all, > > I've encountered a strange error. I have a quad PII xeon with a built in > dual channel adaptec XXXX scsi controller. I have two 8gb IBM drives and > two Toshiba cdrom drives hanging off of it. > > It's running -current from yesterday evening, around 7pm PST. > > Today I fired up four copies of ripit.pl and let the machine go crazy > rippingand encoding mp3's. Out of the blue I got this error, without any > previous errors: > > (pass2:ahc0:0:5:0): READ(10). CDB: 28 0 0 4 4a 70 0 0 a 0 > (pass2:ahc0:0:5:0): ILLEGAL REQUEST asc:21,0 > (pass2:ahc0:0:5:0): Logical block address out of range > #cd/2 invalid sector size 2352 > #cd/2 invalid sector size 2352 This means that whatever program you were using to read the CD tried to read a block that was past the end of the CD. I doubt this is related to the invalidating pack message below, especially since there was a 10 minute interval between the two. > Then about 10 minutes later with no other errors inbetween, it barfed > this several times: > > (da0:ahc0:0:0:0): Invalidating pack I'm not sure why it would spit that out multiple times. The "Invalidating pack" message is issued by the da driver when it gets an ENXIO error from the error recovery code. This can happen if the retry count is exhausted on one of several sense codes (you can search through scsi_all.c for ENXIO) or if the retry count is exhaused on selection timeouts. For selection timeouts, we give the device half a second to recover before retrying the command. The da driver has 60 second timeouts on read/write commands, and 4 retries. So it is able to recover in many cases. There probably should have been an error message of some sort before that message, perhaps unless it was a result of a selection timeout. If you boot with -v, you'll see more error output, and that might shed some light on things. > At which point the machine (obviously) became quite unusable. > > Here are the boot messages from the drives/controller: > > ahc0: irq 23 at device 9.0 on pci1 > ahc0: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc1: irq 23 at device 9.1 on pci1 > ahc1: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs I take it this is an onboard controller? What kind of motherboard is it? (Intel or AMI? I recall any other quad Xeon boards.) > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 11.626MB/s transfers (5.813MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) > cd0 at ahc0 bus 0 target 5 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 5.813MB/s transfers (5.813MHz, offset 16) > cd0: Attempt to query device size failed: NOT READY, Medium not present > cd1 at ahc0 bus 0 target 6 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: 5.813MB/s transfers (5.813MHz, offset 16) > cd1: Attempt to query device size failed: NOT READY, Medium not present > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 11.626MB/s transfers (5.813MHz, offset 15, 16bit), Tagged Queueing Enabled > da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) > > Thoughts? Well, first off, all the sync rates seem to be off. I've seen this before, but it's most likely a problem for Justin (CCed) to tackle. Second, you might want to put your LVD devices on one bus, and your single ended devices on another, so you can get LVD speeds out of the LVD devices. That is, unless you've got a 3860 bridge on there, so you can run LVD and SE on the same bus. (Unlikely, since you've got a 7896.) Third, make sure you check your cabling and termination. Remember that LVD drives don't have terminators, so you have to use a SE device to terminate the chain on a SE bus, or use the twisty LVD cables with terminator blocks on the end. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 3 23:20:58 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id D3C2714D29 for ; Mon, 3 Jan 2000 23:19:34 -0800 (PST) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id IAA11657 for ; Tue, 4 Jan 2000 08:17:44 +0100 (MET) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.9.0/8.9.0) with ESMTP id IAA42651; Tue, 4 Jan 2000 08:18:19 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id IAA89924; Tue, 4 Jan 2000 08:16:29 +0100 (CET) (envelope-from ticso) Date: Tue, 4 Jan 2000 08:16:29 +0100 From: Bernd Walter To: Gerard Roudier Cc: Bernd Walter , freebsd-scsi@freebsd.org Subject: Re: drive does not spinup using sym driver under FreeBSD-alpha Message-ID: <20000104081628.A89901@cicely8.cicely.de> References: <20000102233944.B87267@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 04, 2000 at 12:39:08AM +0100, Gerard Roudier wrote: > > > On Sun, 2 Jan 2000, Bernd Walter wrote: > > > bash-2.03# camcontrol tur -u 6 -n da > > Unit is not ready > > I was expecting the whole sense data or at least asc/ascq values. There > are numerous way to be not ready for a device and only one is documented by > SCSI as suggesting a start command to be sent by the initiator. > Values are ASC=4, ASCQ=2 > ASC=4 means 'not ready', ASCQ value tells about the reason or suggests the > next action to apply. ASCQ=2 when ASC=4 suggest initializing command to be > sent to the device. > > If your device does not return these values, then quirked it should be, in > my opinion. Sorry - here it is: bash-2.03# camcontrol tur -u 6 -n da -v Unit is not ready (pass6:sym1:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass6:sym1:0:2:0): NOT READY asc:4,0 (pass6:sym1:0:2:0): Logical unit not ready, cause not reportable Now the difference is clear. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 5:23:53 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from ns2.ge.com (ns2.ge.com [192.35.39.25]) by hub.freebsd.org (Postfix) with ESMTP id DD2D215277; Tue, 4 Jan 2000 05:23:48 -0800 (PST) (envelope-from burg@burg.is.ge.com) Received: from thomas3.ge.com (thomas3.ge.com [3.47.28.17]) by ns2.ge.com (8.9.3/8.9.3) with ESMTP id IAA08337; Tue, 4 Jan 2000 08:23:47 -0500 (EST) Received: from burg.is.ge.com (burg.is.ge.com [3.19.120.24]) by thomas3.ge.com (8.9.3/8.9.3) with ESMTP id IAA10812; Tue, 4 Jan 2000 08:23:46 -0500 (EST) Received: (from burg@localhost) by burg.is.ge.com (8.9.3/8.9.3) id OAA05413; Tue, 4 Jan 2000 14:01:15 +0100 (MET) From: Dick van den Burg MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14449.61210.942735.204355@burg.is.ge.com> Date: Tue, 4 Jan 2000 14:01:14 +0100 (MET) To: freebsd-questions@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: NCR and SUN disk X-Mailer: VM 6.71 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am trying to install FreeBSD 3.3 on a HP Kayak XA with a Symbios Logic PCI (SYM53C875) controller. There is a Quantum Viking 4..5 W880R disk that is recognized without problems. When I attach another external disk 'SEAGATE ST19171W SUN0766' from SUN I get the following errors: .... Waiting 15 seconds for SCSI devices to settle ncro:1: ERROR (0:11) (9-ae-0) (f/9d) @ (script 6bc:19000000). ncr0: script cmd = 89030000 ncr0: regdump: da 10 80 9d 47 0f 01 0f 03 09 81 ae 80 00 0e 00. ncr0: have to clear fifos. ncr0: restart (fatal error). (probe:ncr0:0:0:3) COMMAND FAILED (9 ff) @0xc0cfca00. (probe:ncr0:0:1:1) COMMAND FAILED (9 ff) @0xc0cfa200. ncr0: timeout nccb=0x0cfxa00 (skip) ncr0: timeout nccb=0xocfa200 (skip) I checked the termination on the external disk: It should be auto-terminating, but even with an active terminator the error persists. I tried another cable. I turned of SCAM recognition and queue tagging. I tried the 3.4 floppies. The internal disc is UW (40mbs), the external is 8 bit (20mbs) Neither NT not Linux have problems with this setup. There must be something basically wrong in my setup, because even an old 2.2.5 FreeBSD gave similar errors. Is there anything in the error messages that would point to something I should check? Thanks Dick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 5:39:37 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by hub.freebsd.org (Postfix) with ESMTP id 5AC6C14C81 for ; Tue, 4 Jan 2000 05:39:27 -0800 (PST) (envelope-from robert.schofield@philips.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id OAA16364 for ; Tue, 4 Jan 2000 14:39:25 +0100 (MET) (envelope-from robert.schofield@philips.com) From: robert.schofield@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma016362; Tue, 4 Jan 00 14:39:25 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA02805 for ; Tue, 4 Jan 2000 14:39:24 +0100 (MET) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA24455 for ; Tue, 4 Jan 2000 14:39:23 +0100 (MET) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA2 id 0056890007757270; Tue, 4 Jan 2000 14:39:22 +0100 To: Subject: Re: NCR and SUN disk Message-ID: <0056890007757270000002L902*@MHS> Date: Tue, 4 Jan 2000 14:39:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 01/04/00 14:37:16" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The internal disc is UW (40mbs), the external is 8 bit (20mbs) Hmmm.... if you are operating the bus UW to the external connector, th= en you place a narrow device on it, if this is the last (terminated) device on this segment o= f your bus chain, you may have neglected to terminate the upper half of the bus. Have you got a W= (16) -> N (8) adaptor in place that performs this termination between the UW segment and the = disk unit? (I have to confess that this looks unlikley, but I have observed that a= 2940UW and an unterminated top byte seemed to work OK under NT 4). Rob Schofield -- "Not quick, but brilliant!" - quote from a (good) friend. = To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 12: 2: 4 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 1CD8814C85; Tue, 4 Jan 2000 12:02:02 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA01667; Tue, 4 Jan 2000 12:04:42 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001042004.MAA01667@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Kenneth D. Merry" Cc: Bill Swingle , scsi@FreeBSD.ORG, gibbs@FreeBSD.ORG Subject: Re: Invalidating pack messages In-reply-to: Your message of "Mon, 03 Jan 2000 22:52:25 MST." <20000103225224.B10024@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jan 2000 12:04:42 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Then about 10 minutes later with no other errors inbetween, it barfed > > this several times: > > > > (da0:ahc0:0:0:0): Invalidating pack > > I'm not sure why it would spit that out multiple times. The "Invalidating > pack" message is issued by the da driver when it gets an ENXIO error from > the error recovery code. This can happen if the retry count is exhausted > on one of several sense codes (you can search through scsi_all.c for ENXIO) > or if the retry count is exhaused on selection timeouts. Perhaps we might get one message per SCB that's failed recovery? > There probably should have been an error message of some sort before that > message, perhaps unless it was a result of a selection timeout. If you > boot with -v, you'll see more error output, and that might shed some light > on things. I'm sure Bill will do this, since it just locked up again. > > At which point the machine (obviously) became quite unusable. > > > > Here are the boot messages from the drives/controller: > > > > ahc0: irq 23 at device 9.0 on pci1 > > ahc0: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs > > ahc1: irq 23 at device 9.1 on pci1 > > ahc1: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs > > I take it this is an onboard controller? What kind of motherboard is it? > (Intel or AMI? I recall any other quad Xeon boards.) It's actually an Acer X5; the onboard part is an aic7896N > Second, you might want to put your LVD devices on one bus, and your single > ended devices on another, so you can get LVD speeds out of the LVD devices. > That is, unless you've got a 3860 bridge on there, so you can run LVD and > SE on the same bus. (Unlikely, since you've got a 7896.) There is indeed a 3860 in there. For some odd reason, the low-speed bus is bridged off bus A, not bus B on the 7896. > Third, make sure you check your cabling and termination. Remember that LVD > drives don't have terminators, so you have to use a SE device to terminate > the chain on a SE bus, or use the twisty LVD cables with terminator blocks > on the end. The box is as-built by Acer; the internal LVD cabling is all OK, the hotswap bay units are properly terminated and the SE cable has a crimp-on terminator at the end. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 12: 6:55 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by hub.freebsd.org (Postfix) with ESMTP id 30B5614C88 for ; Tue, 4 Jan 2000 12:06:48 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-108-171.villette.club-internet.fr [194.158.108.171]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA28926; Tue, 4 Jan 2000 21:06:11 +0100 (MET) Date: Tue, 4 Jan 2000 21:33:27 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 3 Jan 2000, Adam wrote: > If you mean the wide and mhz settings in the card "bios" setup (F2 at > boot), I have the cdrom set to wide and 20mhz. I just noticed too that i= t > reports the proper speeds when the cdrom drive contains a cdrom during > boot.=20 The driver renegotiates for WIDE=3D0 and so for NARROW/ASYNC prior to sending the REQUEST SENSE command following a CHECK CONDITION status returned on the previous command. This is the behaviour I choose for the driver in order to succeed the read of SENSE DATA when a UNIT ATTENTION is present at the device side (due to a BDR sent by another initiator for example, or the device having been switched off then on, etc ...).=20 Anyway, I expected the driver to renegotiate for the user wished settings on the next SCSI commands (2 commands are needed due to the driver negotiating WIDE on a command and then SYNC on the next command). If this does not happen, then something has to be fixed. Will check the code and prepare a fix if (as?) needed. Thanks for your report. Regards, G=E9rard.=20 > On Mon, 3 Jan 2000, Gerard Roudier wrote: >=20 > > > >Hello, > > > >The sym driver gets USER settings of SCSI devices from controller NVRAM > >and reports these values as USER settings to CAM. The XPT just suggests > >SIM to apply USER settings at initialization. But you can manually chang= e > >to better settings using camcontrol, once the system is up.=20 > > > >Could you check how the device is user-configured in the NVRAM ? > >You may let me know if the sym driver is not behaving as it should > >regarding sync/wide negotiation. Thanks. > > > >I will provide a man page for the sym driver, but I donnot have found ti= me=20 > >for writing it for the moment. > > > >Regards, > > G=E9rard. > > > >On Mon, 3 Jan 2000, Adam wrote: > > > >> I dont recall if this happened when I tried the driver last (two weeks > >> ago) but a -current from today does this for me: > >>=20 > >> Jan 3 16:00:13 sapphire /kernel: sym0: <875> irq 10 at device 15.0 on > >> pci0 > >> Jan 3 16:00:13 sapphire /kernel: sym0: Tekram NVRAM, ID 7, Fast-20, S= E, > >> parity=20 > >> checking > >> Jan 3 16:00:40 sapphire /kernel: cd1 at sym0 bus 0 target 3 lun 0 > >> Jan 3 16:00:40 sapphire /kernel: cd1: > >> Removable C > >> D-ROM SCSI-2 device=20 > >> Jan 3 16:00:40 sapphire /kernel: cd1: 6.600MB/s transfers (16bit) > >> Jan 3 16:00:40 sapphire /kernel: cd1: Attempt to query device size > >> failed: NOT=20 > >> READY, Medium not present > >>=20 > >> This is a UltraWide cdrom drive so it should show 40MB/sec right? > >>=20 > >>=20 > >> Jan 3 16:36:07 sapphire /kernel: ncr0: = irq > >> 11 at=20 > >> device 15.0 on pci0 > >> Jan 3 16:36:48 sapphire /kernel: cd1 at ncr0 bus 0 target 3 lun 0 > >> Jan 3 16:36:48 sapphire /kernel: cd1: > >> Removable C > >> D-ROM SCSI-2 device=20 > >> Jan 3 16:36:48 sapphire /kernel: cd1: 40.000MB/s transfers (20.000MHz= , > >> offset 1 > >> 5, 16bit) > >> Jan 3 16:36:48 sapphire /kernel: cd1: Attempt to query device size > >> failed: NOT=20 > >> READY, Medium not present > > > > >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 12:29:45 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by hub.freebsd.org (Postfix) with ESMTP id 67C7914CB5 for ; Tue, 4 Jan 2000 12:29:22 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-115-207.villette.club-internet.fr [194.158.115.207]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA13831; Tue, 4 Jan 2000 21:28:21 +0100 (MET) Date: Tue, 4 Jan 2000 21:56:07 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 4 Jan 2000, Gerard Roudier wrote: > On Mon, 3 Jan 2000, Adam wrote: >=20 > > If you mean the wide and mhz settings in the card "bios" setup (F2 at > > boot), I have the cdrom set to wide and 20mhz. I just noticed too that= it > > reports the proper speeds when the cdrom drive contains a cdrom during > > boot.=20 >=20 > The driver renegotiates for WIDE=3D0 and so for NARROW/ASYNC=20 I should wrote: 'The driver renegotiates WIDE using the current settings of the device if it is not 8 bit, otherwise it renegotiates SYNC using the current settings of the device if it is not async (offset !=3D 0)', otherwise it does not perform a negotiation' > prior to > sending the REQUEST SENSE command following a CHECK CONDITION status > returned on the previous command. This is the behaviour I choose for the > driver in order to succeed the read of SENSE DATA when a UNIT ATTENTION i= s > present at the device side (due to a BDR sent by another initiator for > example, or the device having been switched off then on, etc ...).=20 >=20 > Anyway, I expected the driver to renegotiate for the user wished settings > on the next SCSI commands (2 commands are needed due to the driver > negotiating WIDE on a command and then SYNC on the next command). If this > does not happen, then something has to be fixed. Will check the code and > prepare a fix if (as?) needed. >=20 > Thanks for your report. >=20 > Regards, > G=E9rard.=20 Sorry for the waste of bandwidth. (Btw, no explanation of the problem, for now). G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 13:11:59 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by hub.freebsd.org (Postfix) with ESMTP id A39BE14CA0 for ; Tue, 4 Jan 2000 13:11:41 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-109-159.villette.club-internet.fr [194.158.109.159]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id WAA06249; Tue, 4 Jan 2000 22:11:15 +0100 (MET) Date: Tue, 4 Jan 2000 22:38:28 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 3 Jan 2000, Adam wrote: > If you mean the wide and mhz settings in the card "bios" setup (F2 at > boot), I have the cdrom set to wide and 20mhz. I just noticed too that i= t > reports the proper speeds when the cdrom drive contains a cdrom during > boot.=20 Juts simulating on paper leads to nothing wrong in theory: 1) SCSI/IO INQUIRY 2) TRANS_SETTINGS WIDE=3D1 SYNC=3D20MHz 3) SCSI/IO TEST UNIT READY + NEGO WIDE=3D1 -> 6,600 MB/s (16 bit) 4) SCSI/IO READ CAPACITY + NEGO SYNC=3D20MHz --> returns CHECK CONDITION 5) AUTO-SENSE + WIDE=3D1 (not to be stuck with Unit Attention condition) -> 6.600 MB/s (16 bit) 6) ANNOUNCE -> 6,600 MB/s (16 bit)=20 which matches observations, btw. The driver will probably try to negotiate SYNC=3D20MHz on the next SCSI IO,= =20 but this will not be announced and lead to user frustration. ;-) Sorry for that, but I donnot have any immediate solution. Will think about such. But may-be you can check the above by trying the following: 1) Send a TUR from camcontrol -> SIM should silently negotiate SYNC=3D20MHz 2) Tell camcontrol to read current settings (if possible, is it ?) 3) If result is 40.000 MB/s (16 bit), then practice matches the theory=20 for once. :) G=E9rard. > On Mon, 3 Jan 2000, Gerard Roudier wrote: >=20 > > > >Hello, > > > >The sym driver gets USER settings of SCSI devices from controller NVRAM > >and reports these values as USER settings to CAM. The XPT just suggests > >SIM to apply USER settings at initialization. But you can manually chang= e > >to better settings using camcontrol, once the system is up.=20 > > > >Could you check how the device is user-configured in the NVRAM ? > >You may let me know if the sym driver is not behaving as it should > >regarding sync/wide negotiation. Thanks. > > > >I will provide a man page for the sym driver, but I donnot have found ti= me=20 > >for writing it for the moment. > > > >Regards, > > G=E9rard. > > > >On Mon, 3 Jan 2000, Adam wrote: > > > >> I dont recall if this happened when I tried the driver last (two weeks > >> ago) but a -current from today does this for me: > >>=20 > >> Jan 3 16:00:13 sapphire /kernel: sym0: <875> irq 10 at device 15.0 on > >> pci0 > >> Jan 3 16:00:13 sapphire /kernel: sym0: Tekram NVRAM, ID 7, Fast-20, S= E, > >> parity=20 > >> checking > >> Jan 3 16:00:40 sapphire /kernel: cd1 at sym0 bus 0 target 3 lun 0 > >> Jan 3 16:00:40 sapphire /kernel: cd1: > >> Removable C > >> D-ROM SCSI-2 device=20 > >> Jan 3 16:00:40 sapphire /kernel: cd1: 6.600MB/s transfers (16bit) > >> Jan 3 16:00:40 sapphire /kernel: cd1: Attempt to query device size > >> failed: NOT=20 > >> READY, Medium not present > >>=20 > >> This is a UltraWide cdrom drive so it should show 40MB/sec right? > >>=20 > >>=20 > >> Jan 3 16:36:07 sapphire /kernel: ncr0: = irq > >> 11 at=20 > >> device 15.0 on pci0 > >> Jan 3 16:36:48 sapphire /kernel: cd1 at ncr0 bus 0 target 3 lun 0 > >> Jan 3 16:36:48 sapphire /kernel: cd1: > >> Removable C > >> D-ROM SCSI-2 device=20 > >> Jan 3 16:36:48 sapphire /kernel: cd1: 40.000MB/s transfers (20.000MHz= , > >> offset 1 > >> 5, 16bit) > >> Jan 3 16:36:48 sapphire /kernel: cd1: Attempt to query device size > >> failed: NOT=20 > >> READY, Medium not present To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 14: 3:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 25F6A14C82 for ; Tue, 4 Jan 2000 14:03:14 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id RAA10155; Tue, 4 Jan 2000 17:03:04 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Tue, 4 Jan 2000 17:03:04 -0500 (EST) From: Adam To: Matthew Jacob Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sapphire:/dev % cp /usr/src/etc/MAKEDEV . sapphire:/dev % ./MAKEDEV cd2 sapphire:/dev % ls -l cd* crw-r----- 1 root operator 15, 0 Jan 4 16:54 cd0a crw-r----- 1 root operator 15, 2 Jan 4 16:54 cd0c crw-r----- 1 root operator 15, 8 Jan 4 16:54 cd1a crw-r----- 1 root operator 15, 10 Jan 4 16:54 cd1c sapphire:/dev % ls -l rcd* crw-r----- 1 root operator 15, 0 Jan 4 16:54 rcd0a crw-r----- 1 root operator 15, 2 Jan 4 16:54 rcd0c crw-r----- 1 root operator 15, 8 Jan 4 16:54 rcd1a crw-r----- 1 root operator 15, 10 Jan 4 16:54 rcd1c sapphire:/dev % cd /root sapphire:/root % ./stuff /dev/rcd1c 2k 0 1000 I/O returned -1, err is Operation not supported by device sapphire:/root % ./stuff /dev/cd1c 2k 0 1000 I/O returned -1, err is Operation not supported by device sapphire:/root % dd if=/dev/rcd1c of=/dev/null bs=2048 count=2000 2000+0 records in 2000+0 records out 4096000 bytes transferred in 1.632706 secs (2508719 bytes/sec) dd'ing small counts doesnt seem to hint that it is caching any. Plextor's website thinks it has cache though, but dd causes the disk access light to light up each time as well as spinning up / keeping the disk spun up. On Mon, 3 Jan 2000, Matthew Jacob wrote: >Not if the xfer size is small enough such that it's held in the drive's >buffer, in which case the bus speed should show up. > > >> >semuta.feral.com > root rdsame /dev/rwd0c 2k 0 1000 >> >Read 2048000 bytes in 0.866316 seconds, 2308.63KB/sec in 2048 byte blocks >> >semuta.feral.com > root rdsame /dev/rwd0c 1k 0 10 >> >Read 10240 bytes in 0.6581 seconds, 1519.53KB/sec in 1024 byte blocks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 14: 9:58 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id BBED414F32 for ; Tue, 4 Jan 2000 14:09:50 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id RAA10210; Tue, 4 Jan 2000 17:09:23 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Tue, 4 Jan 2000 17:09:23 -0500 (EST) From: Adam To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >But may-be you can check the above by trying the following: > >1) Send a TUR from camcontrol -> SIM should silently negotiate > SYNC=20MHz >2) Tell camcontrol to read current settings (if possible, is it ?) >3) If result is 40.000 MB/s (16 bit), then practice matches the theory > for once. :) > (with disk in) sapphire:/root % camcontrol tur cd1 Unit is ready sapphire:/root % camcontrol inquiry cd1 pass1: Removable CD-ROM SCSI-2 device pass1: 6.600MB/s transfers (16bit) I do not know if inquiry shows current settings though. sapphire:/root % camcontrol negotiate cd1 -R 20 -W 16 -a Current Parameters: (pass1:sym0:0:3:0): sync parameter: 0 (pass1:sym0:0:3:0): offset: 0 (pass1:sym0:0:3:0): bus width: 16 bits (pass1:sym0:0:3:0): disconnection is enabled (pass1:sym0:0:3:0): tagged queueing is disabled New Parameters: (pass1:sym0:0:3:0): sync parameter: 12 (pass1:sym0:0:3:0): frequencey: 20.000MHz (pass1:sym0:0:3:0): offset: 15 (pass1:sym0:0:3:0): bus width: 16 bits (pass1:sym0:0:3:0): disconnection is enabled (pass1:sym0:0:3:0): tagged queueing is disabled sapphire:/root % camcontrol negotiate cd1 Current Parameters: (pass1:sym0:0:3:0): sync parameter: 12 (pass1:sym0:0:3:0): frequencey: 20.000MHz (pass1:sym0:0:3:0): offset: 15 (pass1:sym0:0:3:0): bus width: 16 bits (pass1:sym0:0:3:0): disconnection is enabled (pass1:sym0:0:3:0): tagged queueing is disabled sapphire:/root % camcontrol inquiry cd1 pass1: Removable CD-ROM SCSI-2 device pass1: 6.600MB/s transfers (16bit) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 14:19:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by hub.freebsd.org (Postfix) with ESMTP id 8F00514F4D for ; Tue, 4 Jan 2000 14:19:34 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-170-96.villette.club-internet.fr [195.36.170.96]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA19523; Tue, 4 Jan 2000 23:18:50 +0100 (MET) Date: Tue, 4 Jan 2000 23:45:42 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Matthew Jacob Cc: Adam , scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 3 Jan 2000, Matthew Jacob wrote: > Not if the xfer size is small enough such that it's held in the drive's > buffer, in which case the bus speed should show up. This may just not happen with some recent devices that are quite aware of modern O/Ses performing proper caching. Throwing away data that have just been read is the right thing to do given common O/Ses caching policy.=20 May-be setting the read retention priority to 0xf in the caching page may ensure such a behaviour. Anyway, I expect smart SCSI devices to throw away just read data from their cache by default. I agree that this worked as you describe with common SCSI-2 devices in the past, but this seem to have changed.=20 If you want to make sure to read from the device cache in your benchmark you may use the LOCK UNLOCK CACHE command with appropriate parameters prior to reading multiple times the corresponding data. G=E9rard. > On Mon, 3 Jan 2000, Adam wrote: >=20 > > Ah. but would this help seeing as how the max speed of a 40x cdrom woul= d > > be 40 * 150kb/sec =3D 6MB/sec? > >=20 > > On Mon, 3 Jan 2000, Matthew Jacob wrote: > >=20 > > > > > >semuta.feral.com > root rdsame /dev/rwd0c 2k 0 1000 > > >Read 2048000 bytes in 0.866316 seconds, 2308.63KB/sec in 2048 byte blo= cks > > >semuta.feral.com > root rdsame /dev/rwd0c 1k 0 10 =20 > > >Read 10240 bytes in 0.6581 seconds, 1519.53KB/sec in 1024 byte blocks > > > > > >... > > > > > >reads from device in blocksize blocks (m or k suffix to indicate KByte= or > > >MByte) starting at seek offset OFFSETBLK repeated NBLKS times. > > > > > > > > >On Mon, 3 Jan 2000, Adam wrote: > > > > > >> (user1)sapphire:/root % ./stuff > > >> Usage: ./stuff device blksize offsetblk nblks > > >> Huh? > > >>=20 > > >> On Mon, 3 Jan 2000, Matthew Jacob wrote: > > >>=20 > > >> > > > >> >Usually drives cache some amount of info- CDs, maybe not. Use the a= ttached > > >> >to find out. > > >> > > > >> > > > >> >> On Mon, 3 Jan 2000, Matthew Jacob wrote: > > >> >/* > > >> > * Copyright (c) 1998, Matthew Jacob > > >>=20 > > > > > > > >=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 15:33:17 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56]) by hub.freebsd.org (Postfix) with ESMTP id 7835214E3A for ; Tue, 4 Jan 2000 15:33:13 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-168-201.villette.club-internet.fr [195.36.168.201]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA23408; Wed, 5 Jan 2000 00:32:58 +0100 (MET) Date: Wed, 5 Jan 2000 01:00:16 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 4 Jan 2000, Adam wrote: > >But may-be you can check the above by trying the following: > > > >1) Send a TUR from camcontrol -> SIM should silently negotiate > > SYNC=3D20MHz > >2) Tell camcontrol to read current settings (if possible, is it ?) > >3) If result is 40.000 MB/s (16 bit), then practice matches the theory= =20 > > for once. :) > > >=20 > (with disk in) > sapphire:/root % camcontrol tur cd1 > Unit is ready > sapphire:/root % camcontrol inquiry cd1 > pass1: Removable CD-ROM SCSI-2 device=20 > pass1: 6.600MB/s transfers (16bit) Your device does not support the UNIT SERIAL NUMBER page. This can be=20 guessed from camcontrol not printing out this information by default. What happens may be: SCSI/IO INQUIRY (evpd=3D0) + Nego SYNC=3D20 MHz SCSI/IO INQUIRY (evpd=3D1, #page=3DUNIT_SERIAL_NUMBER) -> CHECK CONDITION (since not supported) AUTO_SENSE + Nego WIDE=3D1 -> 6.600 MHz (16 bit) So, nothing looks wrong there, excepted the frustrating announce that don't want to go away: :)=20 I suggest you the following magic command that should avoid the offending CHECK CONDITION and should allow the driver to negotiate SYNC=3D20MHz on=20 the normal INQUIRY command and prove us it did so as expected: ******************************** * camcontrol inquiry cd1 -D -R * ******************************** I expect this one to finally tell us the truth. Answer should resemble the following as you know: pass1: Removable CD-ROM SCSI-2 device=20 pass1: 40.000MB/s transfers (16bit) + some BLAH BLAH BLAH G=E9rard. =20 > I do not know if inquiry shows current settings though. =20 >=20 > sapphire:/root % camcontrol negotiate cd1 -R 20 -W 16 -a > Current Parameters: > (pass1:sym0:0:3:0): sync parameter: 0 > (pass1:sym0:0:3:0): offset: 0 > (pass1:sym0:0:3:0): bus width: 16 bits > (pass1:sym0:0:3:0): disconnection is enabled > (pass1:sym0:0:3:0): tagged queueing is disabled > New Parameters: > (pass1:sym0:0:3:0): sync parameter: 12 > (pass1:sym0:0:3:0): frequencey: 20.000MHz > (pass1:sym0:0:3:0): offset: 15 > (pass1:sym0:0:3:0): bus width: 16 bits > (pass1:sym0:0:3:0): disconnection is enabled > (pass1:sym0:0:3:0): tagged queueing is disabled > sapphire:/root % camcontrol negotiate cd1 > Current Parameters: > (pass1:sym0:0:3:0): sync parameter: 12 > (pass1:sym0:0:3:0): frequencey: 20.000MHz > (pass1:sym0:0:3:0): offset: 15 > (pass1:sym0:0:3:0): bus width: 16 bits > (pass1:sym0:0:3:0): disconnection is enabled > (pass1:sym0:0:3:0): tagged queueing is disabled > sapphire:/root % camcontrol inquiry cd1 > pass1: Removable CD-ROM SCSI-2 device=20 > pass1: 6.600MB/s transfers (16bit) >=20 >=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 16:34:20 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 6979E15043 for ; Tue, 4 Jan 2000 16:34:15 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id TAA11176; Tue, 4 Jan 2000 19:34:17 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Tue, 4 Jan 2000 19:34:17 -0500 (EST) From: Adam To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 5 Jan 2000, Gerard Roudier wrote: >I suggest you the following magic command that should avoid the offending >CHECK CONDITION and should allow the driver to negotiate SYNC=3D20MHz on= =20 >the normal INQUIRY command and prove us it did so as expected: > > ******************************** > * camcontrol inquiry cd1 -D -R * > ******************************** > >I expect this one to finally tell us the truth. Answer should resemble the >following as you know: > >pass1: Removable CD-ROM SCSI-2 device=20 >pass1: 40.000MB/s transfers (16bit) + some BLAH BLAH BLAH > > G=E9rard. True! :) Does this mean it is operating properly a) without special prodding b) only with prodding c) never? I'm just curious if any of this would bring down the bus speed when accessing the cdrom if I had any UW hd's on the bus for example, or if it is purely a cosmetic issue. Also wondering why ncr0 works fine with it :P sapphire:~ % camcontrol inquiry cd1 -D -R=20 pass1: Removable CD-ROM SCSI-2 device=20 pass1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) sapphire:~ % camcontrol inquiry cd1=20 pass1: Removable CD-ROM SCSI-2 device=20 pass1: 6.600MB/s transfers (16bit) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 4 18:28: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 9D7AA15044 for ; Tue, 4 Jan 2000 18:28:01 -0800 (PST) (envelope-from unfurl@magnesium.net) Received: (qmail 82898 invoked by uid 1001); 5 Jan 2000 02:28:00 -0000 Date: 4 Jan 2000 18:28:00 -0800 Date: Tue, 4 Jan 2000 18:28:00 -0800 From: Bill Swingle To: scsi@freebsd.org Subject: Re: Invalidating pack messages Message-ID: <20000104182800.B82529@dub.net> References: <19991228162311.A15296@dub.net> <199912300101.SAA51799@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <199912300101.SAA51799@narnia.plutotech.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 29, 1999 at 06:01:21PM -0700, Justin T. Gibbs wrote: > In article <19991228162311.A15296@dub.net> you wrote: > > It's running -current from yesterday evening, around 7pm PST. > > > > Today I fired up four copies of ripit.pl and let the machine go crazy > > rippingand encoding mp3's. Out of the blue I got this error, without any > > previous errors: > > > > (pass2:ahc0:0:5:0): READ(10). CDB: 28 0 0 4 4a 70 0 0 a 0 > > (pass2:ahc0:0:5:0): ILLEGAL REQUEST asc:21,0 > > (pass2:ahc0:0:5:0): Logical block address out of range > > #cd/2 invalid sector size 2352 > > #cd/2 invalid sector size 2352 > > ripit.pl must not be very robust. It seems to have requested an > audio block outside the range of valid media on this particular disk. > > > Then about 10 minutes later with no other errors inbetween, it barfed > > this several times: > > > > (da0:ahc0:0:0:0): Invalidating pack > > > > At which point the machine (obviously) became quite unusable. > > For some reason the system was unable to access da0. Perhaps the > cd drive refused to release the bus completely after the invalid > request above. Its hard to say without an analyzer on the bus. As a follow up, Here are *all* the errors I get when booted with a -v: ahc0: target 0 using 8bit transfers ahc0: target 0 using asyncronous transfers ahc0: target 6 using asyncronous transfers (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack (pass2:ahc0:0:5:0): SCB 0x4 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x44 (pass2:ahc0:0:5:0): Queueing a BDR SCB (pass2:ahc0:0:5:0): no longer in timeout, status = 34a (da0:ahc0:0:0:0): Invalidating pack (da0:ahc0:0:0:0): Invalidating pack -Bill -- -=| --- B i l l S w i n g l e --- http://www.dub.net/ -=| unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com -=| Different all twisty a of in maze are you, passages little To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 5 11: 5: 9 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from relay.ioffe.rssi.ru (relay.ioffe.rssi.ru [194.85.224.33]) by hub.freebsd.org (Postfix) with ESMTP id BC51814F66; Wed, 5 Jan 2000 11:04:43 -0800 (PST) (envelope-from ak@astro.ioffe.rssi.ru) Received: from astro.ioffe.rssi.ru (astro.ioffe.rssi.ru [194.85.227.65]) by relay.ioffe.rssi.ru (8.9.1/8.9.1) with ESMTP id WAA28193; Wed, 5 Jan 2000 22:04:41 +0300 (MSK) Received: by astro.ioffe.rssi.ru (8.9.3/Clnt-2.14-AS-eef) id WAA04185; Wed, 5 Jan 2000 22:04:10 +0300 (MSK) Date: Wed, 5 Jan 2000 22:04:10 +0300 (MSK) From: Alexey Koptsevich To: freebsd-scsi@freebsd.org, freebsd-smp@freebsd.org Subject: dual CPU support and AIC-7896 onboard Intel L440GX Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello to all, I have Intel L440GX motherboard with embedded Adaptec AIC-7896 U2W/UW SCSI, two PIII 500, not overclocked. Firstly I attached there disk with FreeBSD 3.3, which earlier worked on old PPro, and everything went fine with one-CPU kernel, -- all disks worked (and some narrow ones connected with another Adaptec 2940 adapter also). Then I tried to compile SMP kernel for this machine (see config below), but it refused to load (see error message below). Then I tried to install 3.4. Strange things: when disk (IBM 18LZX 9.1 Gb) is connected to the adapter, rather long pause (about a minute) occurs before something begins to load from boot diskettes. When disk is not connected (bus is free), installer begins to boot normally. But in both cases, after the message `Waiting 15 sec for SCSI devices to settle', everything stop, only error messages are issued. The same with 3.3 installation. I saw considerable amount of threads dedicated to close subjects, but, unfortunately, have not found any answer that clarify the situation. Similar systems sometimes work, but are unstable (e.g., as in message Pine.BSF.4.10.9908171543470.45414-100000@caxton.correionet.com.br), Some systems do not... Maybe, kernel SMP options must be set to specific values? But I do not know what any of them means, except of `number of CPUs'. Where could I find more detailed explanation (LINT is too brief)? How do these parameters named in motherboard specification? Would be grateful for any help. I would neither like to migrate to another UNIX, nor to get hardware back, -- in FreeBSD `Releas notes' is written, that AIC789x onboard adapters are supported... Yours, Alexey ##### kernel config ##### # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.freebsd.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.143.2.22 1999/09/14 22:53:30 jkh Exp $ machine "i386" #cpu "I386_CPU" #cpu "I486_CPU" #cpu "I586_CPU" cpu "I686_CPU" ident "ASTRO_3_3_DUAL4" maxusers 64 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed #options MSDOSFS #MSDOS Filesystem #options "CD9660" #ISO 9660 Filesystem #options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] #options SCSI_DELAY=2000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores config kernel root on da1 # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs controller isa0 controller pnp0 # PnP support for ISA controller eisa0 controller pci0 # Floppy drives controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 #disk fd1 at fdc0 drive 1 # IDE controller and disks options "CMD640" # work around CMD640 chip deficiency controller wdc0 at isa? port "IO_WD1" bio irq 14 disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 #controller wdc1 at isa? port "IO_WD2" bio irq 15 #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 # ATAPI devices options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM device wfd0 #IDE Floppy (e.g. LS-120) # SCSI Controllers # A single entry for any of these controllers (ncr, ahb, ahc) is # sufficient for any number of installed devices. #controller ncr0 # NCR/Symbios Logic #controller ahb0 # EISA AHA1742 family #controller ahc0 # AHA2940 and onboard AIC7xxx devices #controller amd0 # AMD 53C974 (Teckram DC-390(T)) #controller isp0 # Qlogic family #controller dpt0 # DPT Smartcache - See LINT for options! #controller adv0 at isa? port ? cam irq ? #controller adw0 #controller bt0 at isa? port ? cam irq ? #controller aha0 at isa? port ? cam irq ? # SCSI peripherals # Only one of each of these is needed, they are dynamically allocated. #controller scbus0 # SCSI bus (required) #device da0 # Direct Access (disks) #device sa0 # Sequential Access (tape etc) #device cd0 # CD #device pass0 # Passthrough device (direct SCSI) # Proprietary or custom CD-ROM Interfaces #device wt0 at isa? port 0x300 bio irq 5 drq 1 #device mcd0 at isa? port 0x300 bio irq 10 #device matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # atkbdc0 controls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver device vt0 at isa? tty #options XSERVER # support for X server #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at isa? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at isa? disable flags 0x31 # Advanced Power Management # PCCARD (PCMCIA) support #controller card0 #device pcic0 at card? #device pcic1 at card? # Serial (COM) ports device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 device sio2 at isa? disable port "IO_COM3" tty irq 5 device sio3 at isa? disable port "IO_COM4" tty irq 9 # Parallel port device ppc0 at isa? port? flags 0x40 net irq 7 controller ppbus0 # Parallel port bus (required) device lpt0 at ppbus? # Printer device plip0 at ppbus? # TCP/IP over parallel device ppi0 at ppbus? # Parallel port interface device #controller vpo0 at ppbus? # Requires scbus and da0 # PCI Ethernet NICs. #device al0 # ADMtek AL981 (``Comet'') #device ax0 # ASIX AX88140A #device de0 # DEC/Intel DC21x4x (``Tulip'') device fxp0 # Intel EtherExpress PRO/100B (82557, 82558) #device mx0 # Macronix 98713/98715/98725 (``PMAC'') #device pn0 # Lite-On 82c168/82c169 (``PNIC'') #device rl0 # RealTek 8129/8139 #device sf0 # Adaptec AIC-6915 DuraLAN (``Starfire'') #device tl0 # Texas Instruments ThunderLAN #device tx0 # SMC 9432TX (83c170 ``EPIC'') #device vr0 # VIA Rhine, Rhine II #device vx0 # 3Com 3c590, 3c595 (``Vortex'') #device wb0 # Winbond W89C840F #device xl0 # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. #device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 #device ie0 at isa? port 0x300 net irq 10 iomem 0xd0000 #device ep0 at isa? port 0x300 net irq 10 #device ex0 at isa? port? net irq? #device fe0 at isa? port 0x300 net irq ? #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 net irq 10 drq 0 #device cs0 at isa? port 0x300 net irq ? # requires PCCARD (PCMCIA) support to be activated #device xe0 at isa? port? net irq ? # PCCARD NIC drivers. # ze and zp take over the pcic and cannot coexist with generic pccard # support, nor the ed and ep drivers they replace. #device ze0 at isa? port 0x300 net irq 10 iomem 0xd8000 #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support #pseudo-device sl 1 # Kernel SLIP #pseudo-device ppp 1 # Kernel PPP #pseudo-device tun 1 # Packet tunnel pseudo-device pty 128 # Pseudo-ttys (telnet etc) pseudo-device gzip # Exec gzipped a.out's # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpfilter 1 #Berkeley packet filter ################ pseudo-device snp 1 pseudo-device vn options QUOTA options LKM options INCLUDE_CONFIG_FILE options USER_LDT options SOFTUPDATES #options PERFMON ##### kernel config ##### ##### kernel error message ##### Fatal trap 12: page fault while in kernel mode mp_lock = 00000002; cpuid = 0; lapic.id = 01000000 fault virtual address = 0x58 fault code = supervisor read, page not present instruction pointer = 0x8: 0xc01f4c23 stack pointer = 0x10: 0xc02e7f84 frame pointer = 0x10: 0xc02e7f88 code segment = base 0x0, limit oxfffff, type ox1b = DPL 0, pres 1, def321, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 0 () interrup mask = <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000002; cpuid = 0; lapic.id = 01000000 ##### kernel error message ##### To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 5 12:48:30 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57]) by hub.freebsd.org (Postfix) with ESMTP id C401C155C2 for ; Wed, 5 Jan 2000 12:48:25 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-163-168.villette.club-internet.fr [195.36.163.168]) by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA02090; Wed, 5 Jan 2000 21:48:04 +0100 (MET) Date: Wed, 5 Jan 2000 22:15:22 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Adam Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 4 Jan 2000, Adam wrote: > On Wed, 5 Jan 2000, Gerard Roudier wrote: >=20 > >I suggest you the following magic command that should avoid the offendin= g > >CHECK CONDITION and should allow the driver to negotiate SYNC=3D20MHz on= =20 > >the normal INQUIRY command and prove us it did so as expected: > > > > ******************************** > > * camcontrol inquiry cd1 -D -R * > > ******************************** > > > >I expect this one to finally tell us the truth. Answer should resemble t= he > >following as you know: > > > >pass1: Removable CD-ROM SCSI-2 device=20 > >pass1: 40.000MB/s transfers (16bit) + some BLAH BLAH BLAH > > > > G=E9rard. >=20 > True! :) Does this mean it is operating properly a) without > special prodding b) only with prodding c) never? It means that I haven't been wrong a single time in my explanation of the= =20 apparent trouble. > I'm just curious if any of this would bring down the bus speed when > accessing the cdrom if I had any UW hd's on the bus for example, or if it > is purely a cosmetic issue. Also wondering why ncr0 works fine with it := P The sym driver will give you full speed for the transfer of useful data for all the devices on the BUS. Justin suggested me the right thing to do by private email. Anyway, both the ncr and the sym will operate at 40 MB/second when transferring data.=20 The CAM/SCSI/camcontrol just announce the speed after a CHECK CONDITION and this is the only time where data transfer is turned to ASYNC by sym.=20 The sym _does_ negotiate SYNC on the next command, but you are not notifying of that. By the way both the ncr and the sym require 2 SCSI commands for negotiating WIDE+SYNC (kind of legacy :) ), but the ncr does not renegotiate WIDE on AUTO-SENSE and this makes the difference you observe.= =20 The aic7xxx does all the work (WIDE+SYNC) in a single SCSI command as=20 Justin Gibbs suggested me to implement in the sym driver. =20 The change is on my todo list for the sym. But I will not provide an immediate change given that this will not improve anything in essence and= =20 does not affect either stability or speed. Now, if you donnot beleive me, you have the choice to use the ncr instead. You CD/ROM will be equally fast, in my opinion. Thanks for your problem report, G=E9rard. PS: I donnot see what may still be unclear about this topic. So, if something is still unclear for you, private email should be more reasonnable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 5 15: 7:20 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id E2A6315481 for ; Wed, 5 Jan 2000 15:07:15 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id SAA20053; Wed, 5 Jan 2000 18:06:16 -0500 (EST) (envelope-from bsdx@looksharp.net) Date: Wed, 5 Jan 2000 18:06:16 -0500 (EST) From: Adam To: Gerard Roudier Cc: scsi@FreeBSD.ORG Subject: Re: sym troubles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Now, if you donnot beleive me, you have the choice to use the ncr instead. >You CD/ROM will be equally fast, in my opinion. Thanks, I believe you. I was just making sure. I'm not concerned about the speed it reported as long as it isnt used :) > >Thanks for your problem report, > G=E9rard. > >PS: I donnot see what may still be unclear about this topic. So, if > something is still unclear for you, private email should be more > reasonnable. > > > >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 From owner-freebsd-scsi Wed Jan 5 15:11:42 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id EA863153A3 for ; Wed, 5 Jan 2000 15:11:39 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id QAA62289; Wed, 5 Jan 2000 16:01:30 -0700 (MST) Date: Wed, 5 Jan 2000 16:01:30 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <200001052301.QAA62289@narnia.plutotech.com> To: Alexey Koptsevich Cc: scsi@FreeBSD.org Subject: Re: dual CPU support and AIC-7896 onboard Intel L440GX X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Then I tried to install 3.4. Strange things: when disk (IBM 18LZX 9.1 Gb) > is connected to the adapter, rather long pause (about a minute) occurs > before something begins to load from boot diskettes. When disk is not > connected (bus is free), installer begins to boot normally. But in both > cases, after the message `Waiting 15 sec for SCSI devices to settle', > everything stop, only error messages are issued. The same with 3.3 > installation. What error messages are issued? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 5 21: 5:16 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id ADDC815509; Wed, 5 Jan 2000 21:05:12 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA31232; Wed, 5 Jan 2000 22:05:11 -0700 (MST) (envelope-from ken) Date: Wed, 5 Jan 2000 22:05:11 -0700 From: "Kenneth D. Merry" To: Mike Smith Cc: Bill Swingle , scsi@FreeBSD.ORG, gibbs@FreeBSD.ORG Subject: Re: Invalidating pack messages Message-ID: <20000105220511.A31109@panzer.kdm.org> References: <20000103225224.B10024@panzer.kdm.org> <200001042004.MAA01667@mass.cdrom.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" X-Mailer: Mutt 1.0i In-Reply-To: <200001042004.MAA01667@mass.cdrom.com>; from msmith@FreeBSD.ORG on Tue, Jan 04, 2000 at 12:04:42PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii On Tue, Jan 04, 2000 at 12:04:42 -0800, Mike Smith wrote: > > > Then about 10 minutes later with no other errors inbetween, it barfed > > > this several times: > > > > > > (da0:ahc0:0:0:0): Invalidating pack > > > > I'm not sure why it would spit that out multiple times. The "Invalidating > > pack" message is issued by the da driver when it gets an ENXIO error from > > the error recovery code. This can happen if the retry count is exhausted > > on one of several sense codes (you can search through scsi_all.c for ENXIO) > > or if the retry count is exhaused on selection timeouts. > > Perhaps we might get one message per SCB that's failed recovery? That's probably it, since you've probably got multiple transactions outstanding when the problem occurs. > > > Here are the boot messages from the drives/controller: > > > > > > ahc0: irq 23 at device 9.0 on pci1 > > > ahc0: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs > > > ahc1: irq 23 at device 9.1 on pci1 > > > ahc1: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs > > > > I take it this is an onboard controller? What kind of motherboard is it? > > (Intel or AMI? I recall any other quad Xeon boards.) > > It's actually an Acer X5; the onboard part is an aic7896N > > > Second, you might want to put your LVD devices on one bus, and your single > > ended devices on another, so you can get LVD speeds out of the LVD devices. > > That is, unless you've got a 3860 bridge on there, so you can run LVD and > > SE on the same bus. (Unlikely, since you've got a 7896.) > > There is indeed a 3860 in there. For some odd reason, the low-speed bus > is bridged off bus A, not bus B on the 7896. > > > Third, make sure you check your cabling and termination. Remember that LVD > > drives don't have terminators, so you have to use a SE device to terminate > > the chain on a SE bus, or use the twisty LVD cables with terminator blocks > > on the end. > > The box is as-built by Acer; the internal LVD cabling is all OK, the > hotswap bay units are properly terminated and the SE cable has a crimp-on > terminator at the end. My guess here is that you're running into selection timeouts. (Especially since Bill's later mail didn't show any additional error messages.) If you apply the attached patch to cam_periph.c, it should print out an error message when you get a fatal selection timeout. This could be related to the sync rate problems you're having. It could be the device just going out to lunch. It could be cabling or termination somehow, if the cabling problem would cause intermittent selection problems. I think the best course to take on this problem is for Justin to try to tackle your sync rate problem first. The sync rate problem is most likely an Adaptec driver interaction problem with your particular motherboard and 7896 implementation. Once he gets that fixed, we can see if you're still having the problems. If so, they'll be narrowed to a bogus drive, bad cabling/terminaton, or some other problem I haven't thought of. :) (What good is an answer if you don't hedge it? :) Ken -- Kenneth Merry ken@kdm.org --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cam_periph.c.selto.010500" ==== //depot/FreeBSD-ken3/src/sys/cam/cam_periph.c#1 - /a/ken/perforce/FreeBSD-ken3/src/sys/cam/cam_periph.c ==== *** /tmp/tmp.31211.0 Wed Jan 5 22:02:29 2000 --- /a/ken/perforce/FreeBSD-ken3/src/sys/cam/cam_periph.c Wed Jan 5 22:02:12 2000 *************** *** 1607,1612 **** --- 1607,1617 ---- } else { error = ENXIO; } + + if (error == ENXIO) { + xpt_print_path(periph->path); + printf("got selection timeout\n"); + } break; } case CAM_REQ_INVALID: --SUOF0GtieIMvvwua-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 0:22:18 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.cdrom.com (castles516.castles.com [208.214.165.80]) by hub.freebsd.org (Postfix) with ESMTP id 262EB15558; Thu, 6 Jan 2000 00:22:15 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA01011; Thu, 6 Jan 2000 00:27:40 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001060827.AAA01011@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alexey Koptsevich Cc: freebsd-scsi@freebsd.org, freebsd-smp@freebsd.org Subject: Re: dual CPU support and AIC-7896 onboard Intel L440GX In-reply-to: Your message of "Wed, 05 Jan 2000 22:04:10 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jan 2000 00:27:40 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Then I tried to install 3.4. Strange things: when disk (IBM 18LZX 9.1 Gb) > is connected to the adapter, rather long pause (about a minute) occurs > before something begins to load from boot diskettes. When disk is not > connected (bus is free), installer begins to boot normally. But in both > cases, after the message `Waiting 15 sec for SCSI devices to settle', > everything stop, only error messages are issued. The same with 3.3 > installation. It's pretty clear that you have a SCSI bus problem unrelated to FreeBSD here. Check your termination, cables, connectors, BIOS settings, etc. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 0:27:37 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id BCE44155C0; Thu, 6 Jan 2000 00:27:32 -0800 (PST) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id CAA59681; Thu, 6 Jan 2000 02:27:25 -0600 (CST) (envelope-from toasty) From: Kevin Day Message-Id: <200001060827.CAA59681@celery.dragondata.com> Subject: Re: dual CPU support and AIC-7896 onboard Intel L440GX To: msmith@FreeBSD.ORG (Mike Smith) Date: Thu, 6 Jan 2000 02:27:25 -0600 (CST) Cc: ak@astro.ioffe.rssi.ru (Alexey Koptsevich), freebsd-scsi@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG In-Reply-To: <200001060827.AAA01011@mass.cdrom.com> from "Mike Smith" at Jan 06, 2000 12:27:40 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Then I tried to install 3.4. Strange things: when disk (IBM 18LZX 9.1 Gb) > > is connected to the adapter, rather long pause (about a minute) occurs > > before something begins to load from boot diskettes. When disk is not > > connected (bus is free), installer begins to boot normally. But in both > > cases, after the message `Waiting 15 sec for SCSI devices to settle', > > everything stop, only error messages are issued. The same with 3.3 > > installation. > > It's pretty clear that you have a SCSI bus problem unrelated to FreeBSD > here. Check your termination, cables, connectors, BIOS settings, etc. Newer adaptec SCSI cards seem to take ages to do the automatic termination checking. Make sure it's turned off in the SCSI card's bios. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 10:20:26 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from relay.ioffe.rssi.ru (relay.ioffe.rssi.ru [194.85.224.33]) by hub.freebsd.org (Postfix) with ESMTP id CF7D2157DD; Thu, 6 Jan 2000 10:20:16 -0800 (PST) (envelope-from ak@astro.ioffe.rssi.ru) Received: from astro.ioffe.rssi.ru (astro.ioffe.rssi.ru [194.85.227.65]) by relay.ioffe.rssi.ru (8.9.1/8.9.1) with ESMTP id VAA24608; Thu, 6 Jan 2000 21:20:08 +0300 (MSK) Received: by astro.ioffe.rssi.ru (8.9.3/Clnt-2.14-AS-eef) id VAA09671; Thu, 6 Jan 2000 21:19:37 +0300 (MSK) Date: Thu, 6 Jan 2000 21:19:37 +0300 (MSK) From: Alexey Koptsevich To: ferebsd-smp@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: dual CPU support and AIC-7896 onboard Intel L440GX Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Thank for your replies and sorry for bother! I have just found that problem with installation of 3.4 was due to conflict between first channel SCSI adapter and ISA network card. SMP kernel in 3.4 loads and detects both CPUs. All the best, Alexey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 10:31:30 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from zoe.qserve.net (zoe.qserve.net [207.250.219.7]) by hub.freebsd.org (Postfix) with ESMTP id A7EFF156DA for ; Thu, 6 Jan 2000 10:31:27 -0800 (PST) (envelope-from rch@qserve.net) Received: from acidic.qserve.net (acidic.qserve.net [207.250.219.40]) by zoe.qserve.net (8.9.1/8.9.1) with ESMTP id NAA26593 for ; Thu, 6 Jan 2000 13:31:26 -0500 (EST) Date: Thu, 6 Jan 2000 13:31:47 -0500 (EST) From: Robert Hough To: freebsd-scsi@freebsd.org Subject: Compaq SMART Array & FreeBSD 3.3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We just picked up a use Compaq Proliant 1500R, with an EISA SMART array card, and 5 2gb drives. I've been trying to get FreeBSD on the machine, but so far, have been far from successful. Can someone give me some tips/hints/urls or something I can turn to? If stick a drive on the internal scsi adapter, freebsd see's that just fine - it just doesn't seem to aknowledge that the array is there. -=)> Robert Hough (rch@qserve.net) -=)> Phone: 317-802-3036 Ext. 11 -=)> http://www.qserve.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 15:23:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.39.177.166]) by hub.freebsd.org (Postfix) with ESMTP id C86671576A; Thu, 6 Jan 2000 15:22:54 -0800 (PST) (envelope-from root@nihil.plaut.de) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id AAA41804; Fri, 7 Jan 2000 00:21:18 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.9.3/8.8.8) with ESMTP id AAA01966; Fri, 7 Jan 2000 00:19:48 +0100 (CET) (envelope-from root@nihil.plaut.de) Date: Fri, 7 Jan 2000 00:19:48 +0100 (CET) From: Michael Reifenberger To: FreeBSD-SCSI Cc: FreeBSD-Current Subject: Problem exposed with sym driver Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1845788462-947200788=:1789" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1845788462-947200788=:1789 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, after enabling the sym-driver I get drive-lockups after some time of accessing the disks hanging on the sym-driver. It seems that at least on disk hangs up (steady disk light) until a bus-reset "(noperiph:sym0:0:-1:-1): SCSI BUS reset detected" occurs. A difference between ncr and sym-driver is that the sym-driver probes the disks as (excerpt from dmesg_sym.txt): da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) whereas the ncr-driver probes as (excerpt from dmesg_ncr.txt): da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) Usually the IBM-FAQ suspects a cabling/termination Problem if one has a Problem at 40MHZ. But I have the 4 disks in a external case from kingston with a proper kable and terminator and furthermore LVD-drives should have a better signal quality. Furthermore I have zero problems at 20MHZ. You can see in neg_before.txt the output of a 'camcontrol neg' which look right, in neg_after.txt the output of the same command after the disk hang up and the bus reseted. neg_ncr.txt contains the output using the ncr-driver. BTW: I have the same problems with the ncr-driver when using the kernel-config parameter: SCSI_NCR_DFLT_SYNC=10 And now the question: Whats going wrong? If it is the HW, how can it be proven? Are it the IBM-disks? Kabel?... Is it the Software? If I want to live with 40MB/s is there a knob to pre-set the speed in the kernel-config or at boot-time? Any clues? Bye! ---- Michael Reifenberger Plaut Software GmbH, R/3 Basis --0-1845788462-947200788=:1789 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg_ncr.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dmesg_ncr.txt" ZyA9IDINCiAgRmVhdHVyZXM9MHgzODNmYmZmPEZQVSxWTUUsREUsUFNFLFRT QyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1Ys UEFULFBTRTM2LE1NWCxGWFNSLFhNTT4NCnJlYWwgbWVtb3J5ICA9IDI2ODQy MzE2OCAoMjYyMTMySyBieXRlcykNCmNvbmZpZz4gI2ZsYWdzIHdkYzAgMHhh MGZmYTBmZg0KSW52YWxpZCBjb21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8n IGZvciBoZWxwLg0KY29uZmlnPiAjZmxhZ3Mgd2RjMSAweGEwZmZhMGZmDQpJ bnZhbGlkIGNvbW1hbmQgb3Igc3ludGF4LiAgVHlwZSBgPycgZm9yIGhlbHAu DQpjb25maWc+ICNpcnEgaXNpYzAgMTANCkludmFsaWQgY29tbWFuZCBvciBz eW50YXguICBUeXBlIGA/JyBmb3IgaGVscC4NCmNvbmZpZz4gI3BucCAxIDAg YmlvcyBlbmFibGUgcG9ydDAgMHgyMjAgaXJxMCA1IGRycTAgMSBkcnExIDMN CkludmFsaWQgY29tbWFuZCBvciBzeW50YXguICBUeXBlIGA/JyBmb3IgaGVs cC4NCmNvbmZpZz4gI3BucCAxIDAgYmlvcyBlbmFibGUgcG9ydDAgMHhkODAg aXJxMCAxMQ0KSW52YWxpZCBjb21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8n IGZvciBoZWxwLg0KY29uZmlnPiBwbnAgMSAxIG9zIGVuYWJsZSBpcnEwIDUg ZHJxMCAxIHBvcnQwIDB4MjIwDQpJbnZhbGlkIGNvbW1hbmQgb3Igc3ludGF4 LiAgVHlwZSBgPycgZm9yIGhlbHAuDQpjb25maWc+ICNpb3NpeiBucHgwIDI2 MjE0NA0KSW52YWxpZCBjb21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8nIGZv ciBoZWxwLg0KY29uZmlnPiBxdWl0DQphdmFpbCBtZW1vcnkgPSAyNTY3MTI3 MDQgKDI1MDY5NksgYnl0ZXMpDQpQcm9ncmFtbWluZyAyNCBwaW5zIGluIElP QVBJQyAjMA0KSU9BUElDICMwIGludHBpbiAyIC0+IGlycSAwDQpGcmVlQlNE L1NNUDogTXVsdGlwcm9jZXNzb3IgbW90aGVyYm9hcmQNCiBjcHUwIChCU1Ap OiBhcGljIGlkOiAgMSwgdmVyc2lvbjogMHgwMDA0MDAxMSwgYXQgMHhmZWUw MDAwMA0KIGNwdTEgKEFQKTogIGFwaWMgaWQ6ICAwLCB2ZXJzaW9uOiAweDAw MDQwMDExLCBhdCAweGZlZTAwMDAwDQogaW8wIChBUElDKTogYXBpYyBpZDog IDIsIHZlcnNpb246IDB4MDAxNzAwMTEsIGF0IDB4ZmVjMDAwMDANClByZWxv YWRlZCBlbGYga2VybmVsICJrZXJuZWwiIGF0IDB4YzAzNjIwMDAuDQpQcmVs b2FkZWQgdXNlcmNvbmZpZ19zY3JpcHQgIi9ib290L2tlcm5lbC5jb25mIiBh dCAweGMwMzYyMDljLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgImJrdHIua28i IGF0IDB4YzAzNjIwZWMuDQpWRVNBOiB2Mi4wLCA4MTkyayBtZW1vcnksIGZs YWdzOjB4MSwgbW9kZSB0YWJsZToweGMwMmY1YjQyICgxMDAwMDIyKQ0KVkVT QTogTWF0cm94IEdyYXBoaWNzIEluYy4NClBlbnRpdW0gUHJvIE1UUlIgc3Vw cG9ydCBlbmFibGVkDQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhl cmJvYXJkDQpucHgwOiBJTlQgMTYgaW50ZXJmYWNlDQpwY2liMDogPEludGVs IDgyNDQzQlggKDQ0MCBCWCkgaG9zdCB0byBQQ0kgYnJpZGdlPiBvbiBtb3Ro ZXJib2FyZA0KcGNpMDogPFBDSSBidXM+IG9uIHBjaWIwDQpwY2liMTogPElu dGVsIDgyNDQzQlggKDQ0MCBCWCkgUENJLVBDSSAoQUdQKSBicmlkZ2U+IGF0 IGRldmljZSAxLjAgb24gcGNpMA0KcGNpMTogPFBDSSBidXM+IG9uIHBjaWIx DQp2Z2EtcGNpMDogPE1hdHJveCBtb2RlbCAwNTIxIGdyYXBoaWNzIGFjY2Vs ZXJhdG9yPiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxDQppc2FiMDog PEludGVsIDgyMzcxQUIgUENJIHRvIElTQSBicmlkZ2U+IGF0IGRldmljZSA0 LjAgb24gcGNpMA0KaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQpwY2kwOiBJ bnRlbCBQSUlYNCBBVEEgY29udHJvbGxlciAodmVuZG9yPTB4ODA4NiwgZGV2 PTB4NzExMSkgYXQgNC4xDQp1aGNpMDogPEludGVsIDgyMzcxQUIvRUIgKFBJ SVg0KSBVU0IgY29udHJvbGxlcj4gaXJxIDE5IGF0IGRldmljZSA0LjIgb24g cGNpMA0KdXNiMDogPEludGVsIDgyMzcxQUIvRUIgKFBJSVg0KSBVU0IgY29u dHJvbGxlcj4gb24gdWhjaTANCnVzYjA6IFVTQiByZXZpc2lvbiAxLjANCnVo dWIwOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMQ0KdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkDQppbnRwbTA6IDxJbnRlbCA4MjM3MUFCIFBvd2Vy IG1hbmFnZW1lbnQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDQuMyBvbiBwY2kw DQppbnRwbTA6IEkvTyBtYXBwZWQgZTgwMA0KaW50cG0wOiBpbnRyIElSUSA5 IGVuYWJsZWQgcmV2aXNpb24gMA0Kc21idXMwOiA8U3lzdGVtIE1hbmFnZW1l bnQgQnVzPiBvbiBpbnRzbWIwDQpzbWIwOiA8U01CdXMgZ2VuZXJhbCBwdXJw b3NlIEkvTz4gb24gc21idXMwDQppbnRwbTA6IFBNIEkvTyBtYXBwZWQgZTQw MCANCmFoYzA6IDxBZGFwdGVjIGFpYzc4OTAvOTEgVWx0cmEyIFNDU0kgYWRh cHRlcj4gaXJxIDE5IGF0IGRldmljZSA2LjAgb24gcGNpMA0KYWhjMDogYWlj Nzg5MC85MSBXaWRlIENoYW5uZWwgQSwgU0NTSSBJZD03LCAxNi8yNTUgU0NC cw0KcGNpMDogdW5rbm93biBjYXJkICh2ZW5kb3I9MHgxMGI3LCBkZXY9MHg5 MDU1KSBhdCA5LjAgaXJxIDE5DQpia3RyMDogPEJyb29rVHJlZSA4Nzg+IGly cSAxOCBhdCBkZXZpY2UgMTAuMCBvbiBwY2kwDQpia3RyMDogSGF1cHBhdWdl IE1vZGVsIDYxMzQ0IEQxMjENCmJrdHIwOiBEZXRlY3RlZCBhIE1TUDM0MTBE LUI0IGF0IDB4ODANCkhhdXBwYXVnZSBXaW5DYXN0L1RWLCBQaGlsaXBzIEZS MTIxNiBQQUwgRk0gdHVuZXIsIG1zcDM0MDBjIHN0ZXJlbywgcmVtb3RlIGNv bnRyb2wuDQpwY2kwOiB1bmtub3duIGNhcmQgKHZlbmRvcj0weDEwOWUsIGRl dj0weDA4NzgpIGF0IDEwLjEgaXJxIDE4DQpuY3IwOiA8bmNyIDUzYzg5NSBm YXN0NDAgd2lkZSBzY3NpPiBpcnEgMTcgYXQgZGV2aWNlIDExLjAgb24gcGNp MA0KaXNpYzA6IDxFTFNBIE1pY3JvTGluayBJU0ROL1BDST4gaXJxIDE2IGF0 IGRldmljZSAxMi4wIG9uIHBjaTANCmlzaWMwOiBFcnJvciwgSVBBQyB2ZXJz aW9uIDIgdW5rbm93biENCmRldmljZV9wcm9iZV9hbmRfYXR0YWNoOiBpc2lj MCBhdHRhY2ggcmV0dXJuZWQgNg0KaXNhMDogdG9vIG1hbnkgbWVtb3J5IHJh bmdlc2ZkYzA6IDxORUMgNzIwNjVCIG9yIGNsb25lPiBhdCBwb3J0IDB4M2Yw LTB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTANCmZkYzA6IEZJRk8gZW5hYmxl ZCwgOCBieXRlcyB0aHJlc2hvbGQNCmZkMDogPDE0NDAtS0IgMy41IiBkcml2 ZT4gb24gZmRjMCBkcml2ZSAwDQphdGtiZGMwOiA8a2V5Ym9hcmQgY29udHJv bGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAtMHg2ZiBvbiBpc2EwDQphdGti ZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMA0KdmdhMDogPEdl bmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNiMC0weDNkZiBpb21lbSAweGEw MDAwLTB4YmZmZmYgb24gaXNhMA0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IG9u IGlzYTANCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0w eDIwMD4NCnNpbzAgYXQgcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAw eDEwIG9uIGlzYTANCnNpbzA6IHR5cGUgMTY1NTBBDQpzaW8xIGF0IHBvcnQg MHgyZjgtMHgyZmYgaXJxIDMgb24gaXNhMA0Kc2lvMTogdHlwZSAxNjU1MEEN CnNpbzI6IGNvbmZpZ3VyZWQgaXJxIDE5IG5vdCBpbiBiaXRtYXAgb2YgcHJv YmVkIGlycXMgMA0Kc2lvMzogY29uZmlndXJlZCBpcnEgMTkgbm90IGluIGJp dG1hcCBvZiBwcm9iZWQgaXJxcyAwDQpwcGMwIGF0IHBvcnQgMHgzNzgtMHgz N2YgaXJxIDcgZmxhZ3MgMHg0MCBvbiBpc2EwDQpwcGMwOiBTTUMtbGlrZSBj aGlwc2V0IChFQ1AvRVBQL1BTMi9OSUJCTEUpIGluIENPTVBBVElCTEUgbW9k ZQ0KcHBjMDogRklGTyB3aXRoIDE2LzE2LzkgYnl0ZXMgdGhyZXNob2xkDQps cHQwOiA8Z2VuZXJpYyBwcmludGVyPiBvbiBwcGJ1cyAwDQpscHQwOiBJbnRl cnJ1cHQtZHJpdmVuIHBvcnQNCnBwaTA6IDxnZW5lcmljIHBhcmFsbGVsIGkv bz4gb24gcHBidXMgMA0KdW5rbm93bjA6IDxFU1MgRVMxODY4IFBsdWcgYW5k IFBsYXkgQXVkaW9Ecml2ZT4gYXQgcG9ydCAweDgwMC0weDgwNyBvbiBpc2Ew DQpzYmMwOiA8RVNTIEVTMTg2OD4gYXQgcG9ydCAweDIyMC0weDIyZiwweDM4 OC0weDM4YiwweDMzMC0weDMzMSBpcnEgNSBkcnEgMSwwIG9uIGlzYTANCnBj bTA6IDxTQiBEU1AgMy4wMSAoRVNTIG1vZGUpPiBvbiBzYmMwDQp1bmtub3du MTogPEVTUyBFUzE4NjggUGx1ZyBhbmQgUGxheSBBdWRpb0RyaXZlPiBhdCBw b3J0IDB4MjAxIG9uIGlzYTANCnVua25vd24yOiA8RVNTIEVTMTg2OCBQbHVn IGFuZCBQbGF5IEF1ZGlvRHJpdmU+IGF0IHBvcnQgMHgxNjgtMHgxNmYsMHgz NmUtMHgzNmYgaXJxIDEyIG9uIGlzYTANCnVua25vd246IDxQTlAwNDAxPiBj YW4ndCBhc3NpZ24gcmVzb3VyY2VzDQp1bmtub3duOiA8UE5QMDUwMT4gY2Fu J3QgYXNzaWduIHJlc291cmNlcw0KdW5rbm93bjogPFBOUDA1MDE+IGNhbid0 IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246IDxQTlAwNzAwPiBjYW4ndCBh c3NpZ24gcmVzb3VyY2VzDQp1bmtub3duMzogPFBOUDBjMDE+IGF0IGlvbWVt IDAtMHg5ZmZmZiwweDEwMDAwMC0weGZmZmZmZmYsMHhlODAwMC0weGVmZmZm LDB4ZjAwMDAtMHhmM2ZmZiwweGY0MDAwLTB4ZjdmZmYsMHhmODAwMC0weGZm ZmZmLDB4ZDM4MDAtMHhkM2ZmZiwweGZlYzAwMDAwLTB4ZmVjMDBmZmYgb24g aXNhMA0KdW5rbm93bjogPFBOUDAwMDA+IGNhbid0IGFzc2lnbiByZXNvdXJj ZXMNCnVua25vd240OiA8UE5QMDEwMD4gYXQgcG9ydCAweDQwLTB4NDMgaXJx IDAgb24gaXNhMA0KdW5rbm93bjU6IDxQTlAwYjAwPiBhdCBwb3J0IDB4NzAt MHg3MSBpcnEgOCBvbiBpc2EwDQp1bmtub3duOiA8UE5QMDMwMz4gY2FuJ3Qg YXNzaWduIHJlc291cmNlcw0KdW5rbm93bjY6IDxQTlAwYzA0PiBhdCBwb3J0 IDB4ZjAgaXJxIDEzIG9uIGlzYTANCnVua25vd243OiA8UE5QMDIwMD4gYXQg cG9ydCAwLTB4ZiwweDgwLTB4OTAsMHg5NC0weDlmLDB4YzAtMHhkZSBkcnEg NCBvbiBpc2EwDQp1bmtub3duOiA8UE5QMDgwMD4gY2FuJ3QgYXNzaWduIHJl c291cmNlcw0KdW5rbm93bjg6IDxQTlAwYTAzPiBhdCBwb3J0IDB4Y2Y4LTB4 Y2ZmIG9uIGlzYTANCnVua25vd246IDxQTlAwYzAyPiBjYW4ndCBhc3NpZ24g cmVzb3VyY2VzDQpBUElDX0lPOiBUZXN0aW5nIDgyNTQgaW50ZXJydXB0IGRl bGl2ZXJ5DQpBUElDX0lPOiByb3V0aW5nIDgyNTQgdmlhIElPQVBJQyAjMCBp bnRwaW4gMg0KaTRidHJjOiA0IElTRE4gdHJhY2UgZGV2aWNlKHMpIGF0dGFj aGVkDQppNGJyYmNoOiA0IHJhdyBCIGNoYW5uZWwgYWNjZXNzIGRldmljZShz KSBhdHRhY2hlZA0KaTRidGVsOiAyIElTRE4gdGVsZXBob255IGludGVyZmFj ZSBkZXZpY2UocykgYXR0YWNoZWQNCmk0YmlwcjogNCBJUCBvdmVyIHJhdyBI RExDIElTRE4gZGV2aWNlKHMpIGF0dGFjaGVkDQppNGJjdGw6IElTRE4gc3lz dGVtIGNvbnRyb2wgcG9ydCBhdHRhY2hlZA0KaTRiaXNwcHA6IDQgSVNETiBT eW5jUFBQIGRldmljZShzKSBhdHRhY2hlZA0KaTRiOiBJU0ROIGNhbGwgY29u dHJvbCBkZXZpY2UgYXR0YWNoZWQNCklQIHBhY2tldCBmaWx0ZXJpbmcgaW5p dGlhbGl6ZWQsIGRpdmVydCBlbmFibGVkLCBydWxlLWJhc2VkIGZvcndhcmRp bmcgZGlzYWJsZWQsIGxvZ2dpbmcgbGltaXRlZCB0byAxMDAgcGFja2V0cy9l bnRyeSBieSBkZWZhdWx0DQpXYWl0aW5nIDIgc2Vjb25kcyBmb3IgU0NTSSBk ZXZpY2VzIHRvIHNldHRsZQ0KU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhDQpN b3VudGluZyByb290IGZyb20gdWZzOi9kZXYvZGEwczFhDQpkYTMgYXQgbmNy MCBidXMgMCB0YXJnZXQgMyBsdW4gMA0KZGEzOiA8SUJNIEREUlMtMzkxMzBE IERDMUI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRldmljZSANCmRh MzogNDAuMDAwTUIvcyB0cmFuc2ZlcnMgKDIwLjAwME1Ieiwgb2Zmc2V0IDE1 LCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkDQpkYTM6IDg3MTVN QiAoMTc4NTAwMDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAxMTEx QykNCmRhNCBhdCBuY3IwIGJ1cyAwIHRhcmdldCA0IGx1biAwDQpkYTQ6IDxJ Qk0gRERSUy0zOTEzMEQgREMxQj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJ LTIgZGV2aWNlIA0KZGE0OiA0MC4wMDBNQi9zIHRyYW5zZmVycyAoMjAuMDAw TUh6LCBvZmZzZXQgMTUsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJs ZWQNCmRhNDogODcxNU1CICgxNzg1MDAwMCA1MTIgYnl0ZSBzZWN0b3JzOiAy NTVIIDYzUy9UIDExMTFDKQ0KZGExIGF0IG5jcjAgYnVzIDAgdGFyZ2V0IDEg bHVuIDANCmRhMTogPElCTSBERFJTLTM5MTMwRCBEQzFCPiBGaXhlZCBEaXJl Y3QgQWNjZXNzIFNDU0ktMiBkZXZpY2UgDQpkYTE6IDQwLjAwME1CL3MgdHJh bnNmZXJzICgyMC4wMDBNSHosIG9mZnNldCAxNSwgMTZiaXQpLCBUYWdnZWQg UXVldWVpbmcgRW5hYmxlZA0KZGExOiA4NzE1TUIgKDE3ODUwMDAwIDUxMiBi eXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMTExMUMpDQpkYTAgYXQgYWhjMCBi dXMgMCB0YXJnZXQgMCBsdW4gMA0KZGEwOiA8SUJNIEREUlMtMzQ1NjBEIERD MUI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRldmljZSANCmRhMDog ODAuMDAwTUIvcyB0cmFuc2ZlcnMgKDQwLjAwME1Ieiwgb2Zmc2V0IDE1LCAx NmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkDQpkYTA6IDQzNTdNQiAo ODkyNTAwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDU1NUMpDQpk YTIgYXQgbmNyMCBidXMgMCB0YXJnZXQgMiBsdW4gMA0KZGEyOiA8SUJNIERE UlMtMzkxMzBEIERDMUI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRl dmljZSANCmRhMjogNDAuMDAwTUIvcyB0cmFuc2ZlcnMgKDIwLjAwME1Ieiwg b2Zmc2V0IDE1LCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkDQpk YTI6IDg3MTVNQiAoMTc4NTAwMDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2 M1MvVCAxMTExQykNCnZpbnVtOiBsb2FkZWQNCnZpbnVtOiByZWFkaW5nIGNv bmZpZ3VyYXRpb24gZnJvbSAvZGV2L2RhMXMxZA0KdmludW06IHVwZGF0aW5n IGNvbmZpZ3VyYXRpb24gZnJvbSAvZGV2L2RhMnMxZA0KdmludW06IHVwZGF0 aW5nIGNvbmZpZ3VyYXRpb24gZnJvbSAvZGV2L2RhM3MxZA0KdmludW06IHVw ZGF0aW5nIGNvbmZpZ3VyYXRpb24gZnJvbSAvZGV2L2RhNHMxZA0KdmludW1p b2N0bDogaW52YWxpZCBpb2N0bCBmcm9tIHByb2Nlc3MgMTYgKHZpbnVtKTog YzBiODQ2NDMNCnBjaTA6IEludGVsIFBJSVg0IEFUQSBjb250cm9sbGVyICh2 ZW5kb3I9MHg4MDg2LCBkZXY9MHg3MTExKSBhdCA0LjENCnhsMDogPDNDb20g M2M5MDVCLVRYIEZhc3QgRXRoZXJsaW5rIFhMPiBpcnEgMTkgYXQgZGV2aWNl IDkuMCBvbiBwY2kwDQp4bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOjVh OmQ1OjliOjQzDQpwY2kwOiB1bmtub3duIGNhcmQgKHZlbmRvcj0weDEwOWUs IGRldj0weDA4NzgpIGF0IDEwLjEgaXJxIDE4DQppc2ljMDogPEVMU0EgTWlj cm9MaW5rIElTRE4vUENJPiBpcnEgMTYgYXQgZGV2aWNlIDEyLjAgb24gcGNp MA0KaXNpYzA6IEVycm9yLCBJUEFDIHZlcnNpb24gMiB1bmtub3duIQ0KZGV2 aWNlX3Byb2JlX2FuZF9hdHRhY2g6IGlzaWMwIGF0dGFjaCByZXR1cm5lZCA2 DQptaWlidXMwOiA8TUlJIGJ1cz4gb24geGwwDQp4bHBoeTA6IDwzQ29tIGlu dGVybmFsIG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMA0KeGxwaHkwOiAg MTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZE WCwgYXV0bw0KY2QwIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDQgbHVuIDANCmNk MDogPFBMRVhUT1IgQ0QtUk9NIFBYLTQwVFMgMS4wMD4gUmVtb3ZhYmxlIENE LVJPTSBTQ1NJLTIgZGV2aWNlIA0KY2QwOiAyMC4wMDBNQi9zIHRyYW5zZmVy cyAoMjAuMDAwTUh6LCBvZmZzZXQgMTUpDQpjZDA6IGNkIHByZXNlbnQgWzMy NzY4OSB4IDIwNDggYnl0ZSByZWNvcmRzXQ0KY2QxIGF0IGFoYzAgYnVzIDAg dGFyZ2V0IDYgbHVuIDANCmNkMTogPFlBTUFIQSBDUlc2NDE2UyAxLjBjPiBS ZW1vdmFibGUgQ0QtUk9NIFNDU0ktMiBkZXZpY2UgDQpjZDE6IDEwLjAwME1C L3MgdHJhbnNmZXJzICgxMC4wMDBNSHosIG9mZnNldCAxNSkNCmNkMTogQXR0 ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwg TWVkaXVtIG5vdCBwcmVzZW50IC0gdHJheSBjbG9zZWQNCg== --0-1845788462-947200788=:1789 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg_sym.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dmesg_sym.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDAgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk4MiwgMTk4NiwgMTk4OSwgMTk5MSwgMTk5Mw0K CVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEu IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIDQuMC1DVVJSRU5UICM0 OiBUaHUgSmFuICA2IDIwOjQ1OjQ1IENFVCAyMDAwDQogICAgcm9vdEBudWxs dW0ucGxhdXQuZGU6L3Vzci9zcmMvc3lzL2NvbXBpbGUvbnVsbHVtDQpUaW1l Y291bnRlciAiaTgyNTQiICBmcmVxdWVuY3kgMTE5MzE4MiBIeg0KQ1BVOiBQ ZW50aXVtIElJSS9YZW9uICg0NTEuMDItTUh6IDY4Ni1jbGFzcyBDUFUpDQog IE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NjcyICBTdGVwcGlu ZyA9IDINCiAgRmVhdHVyZXM9MHgzODNmYmZmPEZQVSxWTUUsREUsUFNFLFRT QyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1Ys UEFULFBTRTM2LE1NWCxGWFNSLFhNTT4NCnJlYWwgbWVtb3J5ICA9IDI2ODQy MzE2OCAoMjYyMTMySyBieXRlcykNCmNvbmZpZz4gI2ZsYWdzIHdkYzAgMHhh MGZmYTBmZg0KSW52YWxpZCBjb21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8n IGZvciBoZWxwLg0KY29uZmlnPiAjZmxhZ3Mgd2RjMSAweGEwZmZhMGZmDQpJ bnZhbGlkIGNvbW1hbmQgb3Igc3ludGF4LiAgVHlwZSBgPycgZm9yIGhlbHAu DQpjb25maWc+ICNpcnEgaXNpYzAgMTANCkludmFsaWQgY29tbWFuZCBvciBz eW50YXguICBUeXBlIGA/JyBmb3IgaGVscC4NCmNvbmZpZz4gI3BucCAxIDAg YmlvcyBlbmFibGUgcG9ydDAgMHgyMjAgaXJxMCA1IGRycTAgMSBkcnExIDMN CkludmFsaWQgY29tbWFuZCBvciBzeW50YXguICBUeXBlIGA/JyBmb3IgaGVs cC4NCmNvbmZpZz4gI3BucCAxIDAgYmlvcyBlbmFibGUgcG9ydDAgMHhkODAg aXJxMCAxMQ0KSW52YWxpZCBjb21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8n IGZvciBoZWxwLg0KY29uZmlnPiBwbnAgMSAxIG9zIGVuYWJsZSBpcnEwIDUg ZHJxMCAxIHBvcnQwIDB4MjIwDQpJbnZhbGlkIGNvbW1hbmQgb3Igc3ludGF4 LiAgVHlwZSBgPycgZm9yIGhlbHAuDQpjb25maWc+ICNpb3NpeiBucHgwIDI2 MjE0NA0KSW52YWxpZCBjb21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8nIGZv ciBoZWxwLg0KY29uZmlnPiBxdWl0DQphdmFpbCBtZW1vcnkgPSAyNTY2Njc2 NDggKDI1MDY1MksgYnl0ZXMpDQpQcm9ncmFtbWluZyAyNCBwaW5zIGluIElP QVBJQyAjMA0KSU9BUElDICMwIGludHBpbiAyIC0+IGlycSAwDQpGcmVlQlNE L1NNUDogTXVsdGlwcm9jZXNzb3IgbW90aGVyYm9hcmQNCiBjcHUwIChCU1Ap OiBhcGljIGlkOiAgMSwgdmVyc2lvbjogMHgwMDA0MDAxMSwgYXQgMHhmZWUw MDAwMA0KIGNwdTEgKEFQKTogIGFwaWMgaWQ6ICAwLCB2ZXJzaW9uOiAweDAw MDQwMDExLCBhdCAweGZlZTAwMDAwDQogaW8wIChBUElDKTogYXBpYyBpZDog IDIsIHZlcnNpb246IDB4MDAxNzAwMTEsIGF0IDB4ZmVjMDAwMDANClByZWxv YWRlZCBlbGYga2VybmVsICJrZXJuZWwueHh4IiBhdCAweGMwMzZkMDAwLg0K UHJlbG9hZGVkIHVzZXJjb25maWdfc2NyaXB0ICIvYm9vdC9rZXJuZWwuY29u ZiIgYXQgMHhjMDM2ZDBhYy4NClByZWxvYWRlZCBlbGYgbW9kdWxlICJia3Ry LmtvIiBhdCAweGMwMzZkMGZjLg0KVkVTQTogdjIuMCwgODE5MmsgbWVtb3J5 LCBmbGFnczoweDEsIG1vZGUgdGFibGU6MHhjMDJmZjNjMiAoMTAwMDAyMikN ClZFU0E6IE1hdHJveCBHcmFwaGljcyBJbmMuDQpQZW50aXVtIFBybyBNVFJS IHN1cHBvcnQgZW5hYmxlZA0KbnB4MDogPG1hdGggcHJvY2Vzc29yPiBvbiBt b3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGludGVyZmFjZQ0KcGNpYjA6IDxJ bnRlbCA4MjQ0M0JYICg0NDAgQlgpIGhvc3QgdG8gUENJIGJyaWRnZT4gb24g bW90aGVyYm9hcmQNCnBjaTA6IDxQQ0kgYnVzPiBvbiBwY2liMA0KcGNpYjE6 IDxJbnRlbCA4MjQ0M0JYICg0NDAgQlgpIFBDSS1QQ0kgKEFHUCkgYnJpZGdl PiBhdCBkZXZpY2UgMS4wIG9uIHBjaTANCnBjaTE6IDxQQ0kgYnVzPiBvbiBw Y2liMQ0KdmdhLXBjaTA6IDxNYXRyb3ggbW9kZWwgMDUyMSBncmFwaGljcyBh Y2NlbGVyYXRvcj4gaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMQ0KaXNh YjA6IDxJbnRlbCA4MjM3MUFCIFBDSSB0byBJU0EgYnJpZGdlPiBhdCBkZXZp Y2UgNC4wIG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KcGNp MDogSW50ZWwgUElJWDQgQVRBIGNvbnRyb2xsZXIgKHZlbmRvcj0weDgwODYs IGRldj0weDcxMTEpIGF0IDQuMQ0KdWhjaTA6IDxJbnRlbCA4MjM3MUFCL0VC IChQSUlYNCkgVVNCIGNvbnRyb2xsZXI+IGlycSAxOSBhdCBkZXZpY2UgNC4y IG9uIHBjaTANCnVzYjA6IDxJbnRlbCA4MjM3MUFCL0VCIChQSUlYNCkgVVNC IGNvbnRyb2xsZXI+IG9uIHVoY2kwDQp1c2IwOiBVU0IgcmV2aXNpb24gMS4w DQp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDENCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KaW50cG0wOiA8SW50ZWwgODIzNzFBQiBQ b3dlciBtYW5hZ2VtZW50IGNvbnRyb2xsZXI+IGF0IGRldmljZSA0LjMgb24g cGNpMA0KaW50cG0wOiBJL08gbWFwcGVkIGU4MDANCmludHBtMDogaW50ciBJ UlEgOSBlbmFibGVkIHJldmlzaW9uIDANCnNtYnVzMDogPFN5c3RlbSBNYW5h Z2VtZW50IEJ1cz4gb24gaW50c21iMA0Kc21iMDogPFNNQnVzIGdlbmVyYWwg cHVycG9zZSBJL08+IG9uIHNtYnVzMA0KaW50cG0wOiBQTSBJL08gbWFwcGVk IGU0MDAgDQphaGMwOiA8QWRhcHRlYyBhaWM3ODkwLzkxIFVsdHJhMiBTQ1NJ IGFkYXB0ZXI+IGlycSAxOSBhdCBkZXZpY2UgNi4wIG9uIHBjaTANCmFoYzA6 IGFpYzc4OTAvOTEgV2lkZSBDaGFubmVsIEEsIFNDU0kgSWQ9NywgMTYvMjU1 IFNDQnMNCnBjaTA6IHVua25vd24gY2FyZCAodmVuZG9yPTB4MTBiNywgZGV2 PTB4OTA1NSkgYXQgOS4wIGlycSAxOQ0KYmt0cjA6IDxCcm9va1RyZWUgODc4 PiBpcnEgMTggYXQgZGV2aWNlIDEwLjAgb24gcGNpMA0KYmt0cjA6IEhhdXBw YXVnZSBNb2RlbCA2MTM0NCBEMTIxDQpia3RyMDogRGV0ZWN0ZWQgYSBNU1Az NDEwRC1CNCBhdCAweDgwDQpIYXVwcGF1Z2UgV2luQ2FzdC9UViwgUGhpbGlw cyBGUjEyMTYgUEFMIEZNIHR1bmVyLCBtc3AzNDAwYyBzdGVyZW8sIHJlbW90 ZSBjb250cm9sLg0KcGNpMDogdW5rbm93biBjYXJkICh2ZW5kb3I9MHgxMDll LCBkZXY9MHgwODc4KSBhdCAxMC4xIGlycSAxOA0Kc3ltMDogPDg5NT4gaXJx IDE3IGF0IGRldmljZSAxMS4wIG9uIHBjaTANCnN5bTA6IFN5bWJpb3MgTlZS QU0sIElEIDcsIEZhc3QtNDAsIExWRCwgcGFyaXR5IGNoZWNraW5nDQpzeW0w OiBvcGVuIGRyYWluIElSUSBsaW5lIGRyaXZlciwgdXNpbmcgb24tY2hpcCBT UkFNDQppc2ljMDogPEVMU0EgTWljcm9MaW5rIElTRE4vUENJPiBpcnEgMTYg YXQgZGV2aWNlIDEyLjAgb24gcGNpMA0KaXNpYzA6IEVycm9yLCBJUEFDIHZl cnNpb24gMiB1bmtub3duIQ0KZGV2aWNlX3Byb2JlX2FuZF9hdHRhY2g6IGlz aWMwIGF0dGFjaCByZXR1cm5lZCA2DQppc2EwOiB0b28gbWFueSBtZW1vcnkg cmFuZ2VzZmRjMDogPE5FQyA3MjA2NUIgb3IgY2xvbmU+IGF0IHBvcnQgMHgz ZjAtMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhMA0KZmRjMDogRklGTyBlbmFi bGVkLCA4IGJ5dGVzIHRocmVzaG9sZA0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRy aXZlPiBvbiBmZGMwIGRyaXZlIDANCmF0a2JkYzA6IDxrZXlib2FyZCBjb250 cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MC0weDZmIG9uIGlzYTANCmF0 a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQp2Z2EwOiA8 R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2IwLTB4M2RmIGlvbWVtIDB4 YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQpzYzA6IDxTeXN0ZW0gY29uc29sZT4g b24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdz PTB4MjAwPg0Kc2lvMCBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdz IDB4MTAgb24gaXNhMA0Kc2lvMDogdHlwZSAxNjU1MEENCnNpbzEgYXQgcG9y dCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwDQpzaW8xOiB0eXBlIDE2NTUw QQ0Kc2lvMjogY29uZmlndXJlZCBpcnEgMTkgbm90IGluIGJpdG1hcCBvZiBw cm9iZWQgaXJxcyAwDQpzaW8zOiBjb25maWd1cmVkIGlycSAxOSBub3QgaW4g Yml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnBwYzAgYXQgcG9ydCAweDM3OC0w eDM3ZiBpcnEgNyBmbGFncyAweDQwIG9uIGlzYTANCnBwYzA6IFNNQy1saWtl IGNoaXBzZXQgKEVDUC9FUFAvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBt b2RlDQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOSBieXRlcyB0aHJlc2hvbGQN CmxwdDA6IDxnZW5lcmljIHByaW50ZXI+IG9uIHBwYnVzIDANCmxwdDA6IElu dGVycnVwdC1kcml2ZW4gcG9ydA0KcHBpMDogPGdlbmVyaWMgcGFyYWxsZWwg aS9vPiBvbiBwcGJ1cyAwDQp1bmtub3duMDogPEVTUyBFUzE4NjggUGx1ZyBh bmQgUGxheSBBdWRpb0RyaXZlPiBhdCBwb3J0IDB4ODAwLTB4ODA3IG9uIGlz YTANCnNiYzA6IDxFU1MgRVMxODY4PiBhdCBwb3J0IDB4MjIwLTB4MjJmLDB4 Mzg4LTB4MzhiLDB4MzMwLTB4MzMxIGlycSA1IGRycSAxLDAgb24gaXNhMA0K cGNtMDogPFNCIERTUCAzLjAxIChFU1MgbW9kZSk+IG9uIHNiYzANCnVua25v d24xOiA8RVNTIEVTMTg2OCBQbHVnIGFuZCBQbGF5IEF1ZGlvRHJpdmU+IGF0 IHBvcnQgMHgyMDEgb24gaXNhMA0KdW5rbm93bjI6IDxFU1MgRVMxODY4IFBs dWcgYW5kIFBsYXkgQXVkaW9Ecml2ZT4gYXQgcG9ydCAweDE2OC0weDE2Ziww eDM2ZS0weDM2ZiBpcnEgMTIgb24gaXNhMA0KdW5rbm93bjogPFBOUDA0MDE+ IGNhbid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246IDxQTlAwNTAxPiBj YW4ndCBhc3NpZ24gcmVzb3VyY2VzDQp1bmtub3duOiA8UE5QMDUwMT4gY2Fu J3QgYXNzaWduIHJlc291cmNlcw0KdW5rbm93bjogPFBOUDA3MDA+IGNhbid0 IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd24zOiA8UE5QMGMwMT4gYXQgaW9t ZW0gMC0weDlmZmZmLDB4MTAwMDAwLTB4ZmZmZmZmZiwweGU4MDAwLTB4ZWZm ZmYsMHhmMDAwMC0weGYzZmZmLDB4ZjQwMDAtMHhmN2ZmZiwweGY4MDAwLTB4 ZmZmZmYsMHhkMzgwMC0weGQzZmZmLDB4ZmVjMDAwMDAtMHhmZWMwMGZmZiBv biBpc2EwDQp1bmtub3duOiA8UE5QMDAwMD4gY2FuJ3QgYXNzaWduIHJlc291 cmNlcw0KdW5rbm93bjQ6IDxQTlAwMTAwPiBhdCBwb3J0IDB4NDAtMHg0MyBp cnEgMCBvbiBpc2EwDQp1bmtub3duNTogPFBOUDBiMDA+IGF0IHBvcnQgMHg3 MC0weDcxIGlycSA4IG9uIGlzYTANCnVua25vd246IDxQTlAwMzAzPiBjYW4n dCBhc3NpZ24gcmVzb3VyY2VzDQp1bmtub3duNjogPFBOUDBjMDQ+IGF0IHBv cnQgMHhmMCBpcnEgMTMgb24gaXNhMA0KdW5rbm93bjc6IDxQTlAwMjAwPiBh dCBwb3J0IDAtMHhmLDB4ODAtMHg5MCwweDk0LTB4OWYsMHhjMC0weGRlIGRy cSA0IG9uIGlzYTANCnVua25vd246IDxQTlAwODAwPiBjYW4ndCBhc3NpZ24g cmVzb3VyY2VzDQp1bmtub3duODogPFBOUDBhMDM+IGF0IHBvcnQgMHhjZjgt MHhjZmYgb24gaXNhMA0KdW5rbm93bjogPFBOUDBjMDI+IGNhbid0IGFzc2ln biByZXNvdXJjZXMNCkFQSUNfSU86IFRlc3RpbmcgODI1NCBpbnRlcnJ1cHQg ZGVsaXZlcnkNCkFQSUNfSU86IHJvdXRpbmcgODI1NCB2aWEgSU9BUElDICMw IGludHBpbiAyDQppNGJ0cmM6IDQgSVNETiB0cmFjZSBkZXZpY2UocykgYXR0 YWNoZWQNCmk0YnJiY2g6IDQgcmF3IEIgY2hhbm5lbCBhY2Nlc3MgZGV2aWNl KHMpIGF0dGFjaGVkDQppNGJ0ZWw6IDIgSVNETiB0ZWxlcGhvbnkgaW50ZXJm YWNlIGRldmljZShzKSBhdHRhY2hlZA0KaTRiaXByOiA0IElQIG92ZXIgcmF3 IEhETEMgSVNETiBkZXZpY2UocykgYXR0YWNoZWQNCmk0YmN0bDogSVNETiBz eXN0ZW0gY29udHJvbCBwb3J0IGF0dGFjaGVkDQppNGJpc3BwcDogNCBJU0RO IFN5bmNQUFAgZGV2aWNlKHMpIGF0dGFjaGVkDQppNGI6IElTRE4gY2FsbCBj b250cm9sIGRldmljZSBhdHRhY2hlZA0KSVAgcGFja2V0IGZpbHRlcmluZyBp bml0aWFsaXplZCwgZGl2ZXJ0IGVuYWJsZWQsIHJ1bGUtYmFzZWQgZm9yd2Fy ZGluZyBkaXNhYmxlZCwgbG9nZ2luZyBsaW1pdGVkIHRvIDEwMCBwYWNrZXRz L2VudHJ5IGJ5IGRlZmF1bHQNCldhaXRpbmcgMiBzZWNvbmRzIGZvciBTQ1NJ IGRldmljZXMgdG8gc2V0dGxlDQoobm9wZXJpcGg6c3ltMDowOi0xOi0xKTog U0NTSSBCVVMgcmVzZXQgZGVsaXZlcmVkLg0KU01QOiBBUCBDUFUgIzEgTGF1 bmNoZWQhDQpNb3VudGluZyByb290IGZyb20gdWZzOi9kZXYvZGEwczFhDQpk YTEgYXQgc3ltMCBidXMgMCB0YXJnZXQgMSBsdW4gMA0KZGExOiA8SUJNIERE UlMtMzkxMzBEIERDMUI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRl dmljZSANCmRhMTogODAuMDAwTUIvcyB0cmFuc2ZlcnMgKDQwLjAwME1Ieiwg b2Zmc2V0IDE1LCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkDQpk YTE6IDg3MTVNQiAoMTc4NTAwMDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2 M1MvVCAxMTExQykNCmRhMCBhdCBhaGMwIGJ1cyAwIHRhcmdldCAwIGx1biAw DQpkYTA6IDxJQk0gRERSUy0zNDU2MEQgREMxQj4gRml4ZWQgRGlyZWN0IEFj Y2VzcyBTQ1NJLTIgZGV2aWNlIA0KZGEwOiA4MC4wMDBNQi9zIHRyYW5zZmVy cyAoNDAuMDAwTUh6LCBvZmZzZXQgMTUsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVl aW5nIEVuYWJsZWQNCmRhMDogNDM1N01CICg4OTI1MDAwIDUxMiBieXRlIHNl Y3RvcnM6IDI1NUggNjNTL1QgNTU1QykNCmRhMiBhdCBzeW0wIGJ1cyAwIHRh cmdldCAyIGx1biAwDQpkYTI6IDxJQk0gRERSUy0zOTEzMEQgREMxQj4gRml4 ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNlIA0KZGEyOiA4MC4wMDBN Qi9zIHRyYW5zZmVycyAoNDAuMDAwTUh6LCBvZmZzZXQgMTUsIDE2Yml0KSwg VGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQNCmRhMjogODcxNU1CICgxNzg1MDAw MCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDExMTFDKQ0KZGEzIGF0 IHN5bTAgYnVzIDAgdGFyZ2V0IDMgbHVuIDANCmRhMzogPElCTSBERFJTLTM5 MTMwRCBEQzFCPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMiBkZXZpY2Ug DQpkYTM6IDgwLjAwME1CL3MgdHJhbnNmZXJzICg0MC4wMDBNSHosIG9mZnNl dCAxNSwgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEzOiA4 NzE1TUIgKDE3ODUwMDAwIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1Qg MTExMUMpDQpkYTQgYXQgc3ltMCBidXMgMCB0YXJnZXQgNCBsdW4gMA0KZGE0 OiA8SUJNIEREUlMtMzkxMzBEIERDMUI+IEZpeGVkIERpcmVjdCBBY2Nlc3Mg U0NTSS0yIGRldmljZSANCmRhNDogODAuMDAwTUIvcyB0cmFuc2ZlcnMgKDQw LjAwME1Ieiwgb2Zmc2V0IDE1LCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBF bmFibGVkDQpkYTQ6IDg3MTVNQiAoMTc4NTAwMDAgNTEyIGJ5dGUgc2VjdG9y czogMjU1SCA2M1MvVCAxMTExQykNCmNkMCBhdCBhaGMwIGJ1cyAwIHRhcmdl dCA0IGx1biAwDQpjZDA6IDxQTEVYVE9SIENELVJPTSBQWC00MFRTIDEuMDA+ IFJlbW92YWJsZSBDRC1ST00gU0NTSS0yIGRldmljZSANCmNkMDogMjAuMDAw TUIvcyB0cmFuc2ZlcnMgKDIwLjAwME1Ieiwgb2Zmc2V0IDE1KQ0KY2QwOiBj ZCBwcmVzZW50IFszMjc2ODkgeCAyMDQ4IGJ5dGUgcmVjb3Jkc10NCnZpbnVt OiBsb2FkZWQNCnZpbnVtOiByZWFkaW5nIGNvbmZpZ3VyYXRpb24gZnJvbSAv ZGV2L2RhNHMxZA0KdmludW06IHVwZGF0aW5nIGNvbmZpZ3VyYXRpb24gZnJv bSAvZGV2L2RhMXMxZA0KdmludW06IHVwZGF0aW5nIGNvbmZpZ3VyYXRpb24g ZnJvbSAvZGV2L2RhMnMxZA0KdmludW06IHVwZGF0aW5nIGNvbmZpZ3VyYXRp b24gZnJvbSAvZGV2L2RhM3MxZA0KY2QxIGF0IGFoYzAgYnVzIDAgdGFyZ2V0 IDYgbHVuIDANCmNkMTogPFlBTUFIQSBDUlc2NDE2UyAxLjBjPiBSZW1vdmFi bGUgQ0QtUk9NIFNDU0ktMiBkZXZpY2UgDQpjZDE6IDEwLjAwME1CL3MgdHJh bnNmZXJzICgxMC4wMDBNSHosIG9mZnNldCAxNSkNCmNkMTogQXR0ZW1wdCB0 byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVt IG5vdCBwcmVzZW50IC0gdHJheSBjbG9zZWQNCg== --0-1845788462-947200788=:1789 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="neg_before.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="neg_before.txt" Q3VycmVudCBQYXJhbWV0ZXJzOg0KKHBhc3M2OnN5bTA6MDo0OjApOiBzeW5j IHBhcmFtZXRlcjogMTANCihwYXNzNjpzeW0wOjA6NDowKTogZnJlcXVlbmNl eTogNDAuMDAwTUh6DQoocGFzczY6c3ltMDowOjQ6MCk6IG9mZnNldDogMTUN CihwYXNzNjpzeW0wOjA6NDowKTogYnVzIHdpZHRoOiAxNiBiaXRzDQoocGFz czY6c3ltMDowOjQ6MCk6IGRpc2Nvbm5lY3Rpb24gaXMgZW5hYmxlZA0KKHBh c3M2OnN5bTA6MDo0OjApOiB0YWdnZWQgcXVldWVpbmcgaXMgZW5hYmxlZA0K --0-1845788462-947200788=:1789 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="neg_after.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="neg_after.txt" Q3VycmVudCBQYXJhbWV0ZXJzOg0KKHBhc3MzOnN5bTA6MDoxOjApOiBzeW5j IHBhcmFtZXRlcjogMA0KKHBhc3MzOnN5bTA6MDoxOjApOiBvZmZzZXQ6IDAN CihwYXNzMzpzeW0wOjA6MTowKTogYnVzIHdpZHRoOiA4IGJpdHMNCihwYXNz MzpzeW0wOjA6MTowKTogZGlzY29ubmVjdGlvbiBpcyBlbmFibGVkDQoocGFz czM6c3ltMDowOjE6MCk6IHRhZ2dlZCBxdWV1ZWluZyBpcyBlbmFibGVkDQo= --0-1845788462-947200788=:1789 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="neg_ncr.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="neg_ncr.txt" Q3VycmVudCBQYXJhbWV0ZXJzOg0KKHBhc3MzOm5jcjA6MDoxOjApOiBzeW5j IHBhcmFtZXRlcjogMTINCihwYXNzMzpuY3IwOjA6MTowKTogZnJlcXVlbmNl eTogMjAuMDAwTUh6DQoocGFzczM6bmNyMDowOjE6MCk6IG9mZnNldDogMTUN CihwYXNzMzpuY3IwOjA6MTowKTogYnVzIHdpZHRoOiAxNiBiaXRzDQoocGFz czM6bmNyMDowOjE6MCk6IGRpc2Nvbm5lY3Rpb24gaXMgZW5hYmxlZA0KKHBh c3MzOm5jcjA6MDoxOjApOiB0YWdnZWQgcXVldWVpbmcgaXMgZW5hYmxlZA0K --0-1845788462-947200788=:1789-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 17:45:52 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id CADF21574C for ; Thu, 6 Jan 2000 17:45:49 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id RAA45208 for ; Thu, 6 Jan 2000 17:19:25 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Date: Thu, 6 Jan 2000 17:19:25 -0800 (PST) From: Doug White To: scsi@freebsd.org Subject: stuck traffic light on l440gx+ mobo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey all... We have several servers with Intel L440GX+ motherboards. These have a builtin AIC-7896 controler running v2.20S1B1 of their BIOS. I installed a kernel on them today with ahc support compiled in (haven't before, we don't use the onboard SCSI until today) and noticed that machines with this board and only IDE channels (ie nothing plugged into the mobo SCSI ports) have the disk access light stuck on. The machine operates normally otherwise, but the stuck light is masking the acitivity I really want to see :-) It sticks on just after the 'Waiting 2 seconds for SCSI devices to settle' prompt. This is on a late 3.2-STABLE. Curious to know if this is fixed or if there's a simple workaround beyond compiling out ahc. :) Thanks! Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 17:56:40 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 95D241522B for ; Thu, 6 Jan 2000 17:56:34 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id SAA40069; Thu, 6 Jan 2000 18:51:31 -0700 (MST) (envelope-from ken) Date: Thu, 6 Jan 2000 18:51:31 -0700 From: "Kenneth D. Merry" To: Doug White Cc: scsi@FreeBSD.ORG Subject: Re: stuck traffic light on l440gx+ mobo Message-ID: <20000106185131.A40033@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from dwhite@resnet.uoregon.edu on Thu, Jan 06, 2000 at 05:19:25PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 06, 2000 at 17:19:25 -0800, Doug White wrote: > Hey all... > > We have several servers with Intel L440GX+ motherboards. These have a > builtin AIC-7896 controler running v2.20S1B1 of their BIOS. > > I installed a kernel on them today with ahc support compiled in (haven't > before, we don't use the onboard SCSI until today) and noticed that > machines with this board and only IDE channels (ie nothing plugged into > the mobo SCSI ports) have the disk access light stuck on. > > The machine operates normally otherwise, but the stuck light is masking > the acitivity I really want to see :-) It sticks on just after the > 'Waiting 2 seconds for SCSI devices to settle' prompt. This is on a late > 3.2-STABLE. > > Curious to know if this is fixed or if there's a simple workaround beyond > compiling out ahc. :) Thanks! I believe Justin fixed the problem (the drive light for my 3950U2 now works correctly, it was stuck before), but I can't remember when. I had my led unhooked for a long time because of the driver bug. :) You may be able to test whether or not it is fixed by trying a boot floppy from 3.4 or a -stable snapshot. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 6 20:25:46 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from richard2.pil.net (richard2.pil.net [207.8.164.9]) by hub.freebsd.org (Postfix) with SMTP id 21E3014E65 for ; Thu, 6 Jan 2000 20:25:41 -0800 (PST) (envelope-from up@3.am) Received: (qmail 73309 invoked by uid 1825); 7 Jan 2000 04:20:56 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jan 2000 04:20:56 -0000 Date: Thu, 6 Jan 2000 23:20:56 -0500 (EST) From: X-Sender: up@richard2.pil.net To: Doug White Cc: scsi@freebsd.org Subject: Re: stuck traffic light on l440gx+ mobo In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 6 Jan 2000, Doug White wrote: > Hey all... > > We have several servers with Intel L440GX+ motherboards. These have a > builtin AIC-7896 controler running v2.20S1B1 of their BIOS. > > I installed a kernel on them today with ahc support compiled in (haven't > before, we don't use the onboard SCSI until today) and noticed that > machines with this board and only IDE channels (ie nothing plugged into > the mobo SCSI ports) have the disk access light stuck on. > > The machine operates normally otherwise, but the stuck light is masking > the acitivity I really want to see :-) It sticks on just after the > 'Waiting 2 seconds for SCSI devices to settle' prompt. This is on a late > 3.2-STABLE. > > Curious to know if this is fixed or if there's a simple workaround beyond > compiling out ahc. :) Thanks! I noticed the same thing (same hardware and FBSD version here). It went away, and the light flickers with access now, when I put an externat tape drive and terminator on the second SCSI bus. I'd guess it was termination of that bus that did it.... James Smallacombe PlantageNet, Inc. CEO and Janitor up@3.am http://3.am ========================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 7 8:19:12 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id EE777157D1 for ; Fri, 7 Jan 2000 08:19:08 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id IAA55914; Fri, 7 Jan 2000 08:19:07 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Date: Fri, 7 Jan 2000 08:19:06 -0800 (PST) From: Doug White To: "Kenneth D. Merry" Cc: scsi@FreeBSD.ORG Subject: Re: stuck traffic light on l440gx+ mobo In-Reply-To: <20000106185131.A40033@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 6 Jan 2000, Kenneth D. Merry wrote: > > I installed a kernel on them today with ahc support compiled in (haven't > > before, we don't use the onboard SCSI until today) and noticed that > > machines with this board and only IDE channels (ie nothing plugged into > > the mobo SCSI ports) have the disk access light stuck on. > > > I believe Justin fixed the problem (the drive light for my 3950U2 now works > correctly, it was stuck before), but I can't remember when. I had my led > unhooked for a long time because of the driver bug. :) > > You may be able to test whether or not it is fixed by trying a boot floppy > from 3.4 or a -stable snapshot. Good point, when I have time I'll try a newer release. I wanted to make sure the problem was at least known. Thanks! Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 7 11:44:34 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 61DC51565A for ; Fri, 7 Jan 2000 11:44:29 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id MAA64364; Fri, 7 Jan 2000 12:34:26 -0700 (MST) Date: Fri, 7 Jan 2000 12:34:26 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <200001071934.MAA64364@narnia.plutotech.com> To: Doug White Cc: scsi@FreeBSD.org Subject: Re: stuck traffic light on l440gx+ mobo X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> I believe Justin fixed the problem (the drive light for my 3950U2 now works >> correctly, it was stuck before), but I can't remember when. I had my led >> unhooked for a long time because of the driver bug. :) >> >> You may be able to test whether or not it is fixed by trying a boot floppy >> from 3.4 or a -stable snapshot. > > Good point, when I have time I'll try a newer release. I wanted to make > sure the problem was at least known. Thanks! The problem occured for any probed bus that did not have a device attached. The LED would stay on after a selection timeout. The bug was fixed in rev 1.37 of aic7xxx.c on 1999/09/20. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 7 12:40:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from zoe.qserve.net (zoe.qserve.net [207.250.219.7]) by hub.freebsd.org (Postfix) with ESMTP id D9BF714E98 for ; Fri, 7 Jan 2000 12:40:20 -0800 (PST) (envelope-from rch@qserve.net) Received: from acidic.qserve.net (acidic.qserve.net [207.250.219.40]) by zoe.qserve.net (8.9.1/8.9.1) with ESMTP id PAA29131 for ; Fri, 7 Jan 2000 15:40:19 -0500 (EST) Date: Fri, 7 Jan 2000 15:40:52 -0500 (EST) From: Robert Hough To: freebsd-scsi@freebsd.org Subject: Newest Problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I found the IDA section in the LINT config, and added it to my kernel config as suggested (after the wdc controller entries), compilied and hoped for the best. The only mention of the ida0 controller is the following: ida: port address (0xffffffff) out of range ida0 not found What exactly is it trying to tell me here? This card is an eisa card, would that make any differance in the config? Should the entry for the controller just be: controller ida0? The card in question is a SMART Array Controller, running with the latest firmware update off of Compaq's site. Any thoughts on this would be appreciated. Thanks -=)> Robert Hough (rch@qserve.net) -=)> Phone: 317-802-3036 Ext. 11 -=)> http://www.qserve.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 7 13: 2: 9 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by hub.freebsd.org (Postfix) with ESMTP id 31FD714F65; Fri, 7 Jan 2000 13:01:45 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-223-192.villette.club-internet.fr [195.36.223.192]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA12512; Fri, 7 Jan 2000 21:58:42 +0100 (MET) Date: Fri, 7 Jan 2000 22:28:44 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost Reply-To: Gerard Roudier To: Michael Reifenberger Cc: FreeBSD-SCSI , FreeBSD-Current Subject: Re: Problem exposed with sym driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 7 Jan 2000, Michael Reifenberger wrote: > Hi, > after enabling the sym-driver I get drive-lockups after some time of acce= ssing > the disks hanging on the sym-driver. > It seems that at least on disk hangs up (steady disk light) until a bus-r= eset > "(noperiph:sym0:0:-1:-1): SCSI BUS reset detected" occurs. >=20 > A difference between ncr and sym-driver is that the sym-driver probes the= disks > as (excerpt from dmesg_sym.txt): >=20 > da1 at sym0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing = Enabled > da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) >=20 > whereas the ncr-driver probes as (excerpt from dmesg_ncr.txt): >=20 > da1 at ncr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing = Enabled > da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) >=20 > Usually the IBM-FAQ suspects a cabling/termination Problem if one has a P= roblem > at 40MHZ. Any SCSI related FAQ will suggest the same, in my opinion. But some SCSI devices may have larger margin than some others regarding cabling / termination problems and can be able to accomodate tiny problems. Some other devices may just fail in same situations. > But I have the 4 disks in a external case from kingston with a proper kab= le and > terminator and furthermore LVD-drives should have a better signal quality= =2E > Furthermore I have zero problems at 20MHZ. FYI, I have seen UltraWide SCSI Buses (single-ended) that continued work reasonnably well with a terminator just missing (was intentionnal for testing purpose). As a strangeness, only a single disk (had 4 on the BUS)= =20 required to decrease speed at 33 MB/s (16.? MHz wide) for it to work apparently (seems actually) well. As you can see, even a serious BUS problem may, in some situations, allow the SCSI system to work by just lowering speed of some devices on the bus. > You can see in neg_before.txt the output of a 'camcontrol neg' which look= right, > in neg_after.txt the output of the same command after the disk hang up an= d > the bus reseted. > neg_ncr.txt contains the output using the ncr-driver. >=20 > BTW: I have the same problems with the ncr-driver when using the kernel-c= onfig > parameter: SCSI_NCR_DFLT_SYNC=3D10=20 >=20 > And now the question: Whats going wrong? Probably something related to the SCSI BUS (or devices), but not to software drivers, in my opinion.=20 > If it is the HW, how can it be proven? Are it the IBM-disks? Kabel?... > Is it the Software? > If I want to live with 40MB/s is there a knob to pre-set the speed in the > kernel-config or at boot-time? For the sym driver, you just have to configure SCSI devices accordingly in the NVRAM. The sym driver hears from you by reading the NVRAM when it is able to understand its layout and your kernel log messages let me think it was able to read the controller NVRAM. (Ctrl/C at boot-up for the SYMBIOS SDMS BIOS, and then configure your device settings).=20 > Any clues? Regards, G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 8 5:36: 2 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from queeg.ludd.luth.se (queeg.ludd.luth.se [130.240.16.109]) by hub.freebsd.org (Postfix) with ESMTP id 7832315060 for ; Sat, 8 Jan 2000 05:35:59 -0800 (PST) (envelope-from pantzer@ludd.luth.se) Received: from speedy.ludd.luth.se (pantzer@speedy.ludd.luth.se [130.240.16.164]) by queeg.ludd.luth.se (8.9.3/8.9.3) with ESMTP id OAA08152 for ; Sat, 8 Jan 2000 14:35:57 +0100 (CET) Message-Id: <200001081335.OAA08152@queeg.ludd.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@freebsd.org Subject: SCSI DVD support Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Jan 2000 14:35:56 +0100 From: Mattias Pantzare Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is anyone working on implementing the DVD ioctls for SCSI? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 8 5:43:53 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 292FE152F5 for ; Sat, 8 Jan 2000 05:43:51 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id IAA97769; Sat, 8 Jan 2000 08:43:45 -0500 (EST) Date: Sat, 8 Jan 2000 08:43:44 -0500 (EST) From: "Matthew N. Dodd" To: Robert Hough Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Newest Problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 7 Jan 2000, Robert Hough wrote: > What exactly is it trying to tell me here? This card is an eisa card, > would that make any differance in the config? EISA devices aren't supported. There was code for them in the old IDA driver patch but the driver in the tree lacks the support required. I've got a EISA bus front end but until the rest of the driver can deal with the EISA quirks that code isn't going to do much good. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 8 10:47: 3 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id BD03214F56 for ; Sat, 8 Jan 2000 10:46:59 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA59307; Sat, 8 Jan 2000 11:46:53 -0700 (MST) (envelope-from ken) Date: Sat, 8 Jan 2000 11:46:53 -0700 From: "Kenneth D. Merry" To: Mattias Pantzare Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DVD support Message-ID: <20000108114653.A59050@panzer.kdm.org> References: <200001081335.OAA08152@queeg.ludd.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001081335.OAA08152@queeg.ludd.luth.se>; from pantzer@ludd.luth.se on Sat, Jan 08, 2000 at 02:35:56PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 08, 2000 at 14:35:56 +0100, Mattias Pantzare wrote: > Is anyone working on implementing the DVD ioctls for SCSI? > Well, if someone sends me the hardware, it probably wouldn't be too hard to do. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message