From owner-freebsd-scsi Sun Apr 19 21:16:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10864 for freebsd-scsi-outgoing; Sun, 19 Apr 1998 21:16:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA10636 for ; Mon, 20 Apr 1998 04:15:58 GMT (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id GAA06385; Mon, 20 Apr 1998 06:15:09 +0200 (MET DST) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Mon, 20 Apr 1998 06:15:08 +0200 (MET DST) Mime-Version: 1.0 To: Raul Zighelboim Cc: "'Mike Tancsa'" , "'scsi@freebsd.org'" , "'n@nectar.com'" Subject: Re: Help ! Scsi buss going down ! References: Organization: Gutteklubben Terrasse / KRST / PUMS / YASMW X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-Stop-Spam: http://www.cauce.org From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 20 Apr 1998 06:15:08 +0200 In-Reply-To: Raul Zighelboim's message of "Sat, 18 Apr 1998 18:02:55 -0500" Message-ID: Lines: 8 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Raul Zighelboim writes: > - It is not the cables (maybe it is - I had to cut longer cables to get > what I needed) How much longer? -- Noone else has a .sig like this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 06:17:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17332 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 06:17:25 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from psv.oss.uswest.net (psv.oss.uswest.net [204.147.85.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17326 for ; Mon, 20 Apr 1998 13:17:24 GMT (envelope-from greg@psv.oss.uswest.net) Received: (from greg@localhost) by psv.oss.uswest.net (8.8.7/8.8.5) id IAA22887; Mon, 20 Apr 1998 08:16:51 -0500 (CDT) From: "Greg Rowe" Message-Id: <9804201316.ZM22885@psv.oss.uswest.net> Date: Mon, 20 Apr 1998 13:16:50 +0000 In-Reply-To: Raul Zighelboim "Help ! Scsi buss going down !" (Apr 18, 11:32am) References: X-Mailer: Z-Mail (3.2.1 10apr95) To: Raul Zighelboim , "'scsi@freebsd.org'" Subject: Re: Help ! Scsi buss going down ! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Last week we discovered a problem with a number of our new systems that contained Adaptec 2940UW Revision E chips. All systems containing the E revision chips are failing under load with SCSI resets. The 'D' revision works fine in those systems. Our hardware vendor is trying to get some information out of Adaptec on this problem, but it almost looks like they discovered a bug in that version and yanked it. All Adaptec 2940's coming out of the channels now seem to be Revision 'D'. You can check dmesg to determine what version you have. ahc0 rev 1 int a irq 9 on pci0:13 The "rev 1" is the E revision and "rev 0" is D. Dropping the transfer rate to 10mbs/sec on all your drives will also correct(hide) the problem. Greg On Apr 18, 11:32am, Raul Zighelboim wrote: > Subject: Help ! Scsi buss going down ! > > Hello there; I have replace the drives, I have replaced the controller. > I will replace the external cable, and switch from 'external active > termination' to 'drive built in termination' for the scsi bus. > It cannot be a driver/software issue, there are two busses involved, and > it is always the same one the on with the problem. > > Is tehre something I am missing ? > > I keep getting this on the console: > > sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > Ordered Tag queued > sd3(ahc0:2:0): SCB 0xc timedout while recovery in progress > sd3(ahc0:2:0): SCB 0x5 timedout while recovery in progress > sd3(ahc0:2:0): SCB 0xd timedout while recovery in progress > sd4(ahc0:4:0): SCB 0xa timedout while recovery in progress > sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xe6 > SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > sd3(ahc0:2:0): abort message in message buffer > sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xf6 > SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > sd3(ahc0:2:0): no longer in timeout > ahc0: Issued Channel A Bus Reset. 10 SCBs aborted > sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, > SCSISIGI == 0x0 > SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > Ordered Tag queued > sd0(ahc0:3:0): SCB 0xf timedout while recovery in progress > sd3(ahc0:2:0): SCB 0xd timedout while recovery in progress > sd3(ahc0:2:0): SCB 0xc timedout while recovery in progress > sd4(ahc0:4:0): SCB 0xa timedout while recovery in progress > sd3(ahc0:2:0): SCB 0x5 timedout while recovery in progress > sd0(ahc0:3:0): SCB 0x4 timedout while recovery in progress > sd0(ahc0:3:0): SCB 0x2 timedout while recovery in progress > sd3(ahc0:2:0): SCB 0x1 timedout while recovery in progress > sd4(ahc0:4:0): SCB 0x0 timedout while recovery in progress > sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, > SCSISIGI == 0x0 > SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > sd0(ahc0:3:0): Queueing an Abort SCB > sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, > SCSISIGI == 0x0 > SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > sd0(ahc0:3:0): no longer in timeout > ahc0: Issued Channel A Bus Reset. 11 SCBs aborted > sd0(ahc0:3:0): UNIT ATTENTION asc:29,0 > sd0(ahc0:3:0): Power on, reset, or bus device reset occurred field > replaceable unit: 80 > , retries:2 > sd3(ahc0:2:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > , retries:2 > sd9(ahc0:5:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > , retries:4 > sd4(ahc0:4:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > , retries:2 > sd1(ahc0:0:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > , retries:4 > sd10(ahc0:6:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > , retries:4 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >-- End of excerpt from Raul Zighelboim -- Greg Rowe US WEST - !NTERACT Internet Services "To err is human, to really foul up requires the root password." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 06:37:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20285 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 06:37:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20202; Mon, 20 Apr 1998 13:36:56 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id VAA04663; Mon, 20 Apr 1998 21:36:42 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804201336.VAA04663@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: gibbs@FreeBSD.ORG cc: scsi@FreeBSD.ORG Subject: New CAM w/ buslogic doesn't do bounce buffers correctly.. Date: Mon, 20 Apr 1998 21:36:41 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems that when bt_ccb's are allocated, the dmamap pointer isn't initialized, so it stays null. This causes a few things to hit a fatal trap at first call since map == NULL isn't checked in a few critical places (bus_dmamap_load for starters). add_bounce_page() doesn;'t work if the map = NULL -> map = &nobounce_dmamap conversion happens since the bpages SLIST isn't initialized there either. dev/buslogic/bt.c: segs = sg_map->sg_vaddr; physaddr = sg_map->sg_physaddr; newcount = (PAGE_SIZE / (BT_NSEG * sizeof(bt_sg_t))); for (i = 0; bt->num_ccbs < bt->max_ccbs && i < newcount; i++) { next_ccb->sg_list = segs; next_ccb->sg_list_phys = physaddr; next_ccb->flags = BCCB_FREE; >> what about next_ccb->dmamap?? SLIST_INSERT_HEAD(&bt->free_bt_ccbs, next_ccb, links); segs += BT_NSEG; physaddr += (BT_NSEG * sizeof(bt_sg_t)); next_ccb++; bt->num_ccbs++; } At a guess, it should be set pointing to the instance of the containing page's sg->sg_dmamap. so, perhaps + new_ccb->dmamap = sg->sg_dmamap? And then there's this: int bus_dmamap_load(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, bus_size_t buflen, bus_dmamap_callback_t *callback, void *callback_arg, int flags) { [..] if (dmat->lowaddr < ptoa(Maxmem) && map->pagesneeded == 0) { [..] } if (map == NULL) map = &nobounce_dmamap; [later] do { [..] if (map->pagesneeded != 0 && run_filter(dmat, paddr)) { paddr = add_bounce_page(dmat, map, vaddr, size); } [..] And add_bounce_page() does: [..] bpage->datavaddr = vaddr; bpage->datacount = size; STAILQ_INSERT_TAIL(&(map->bpages), bpage, links); return (bpage->busaddr); } In the instance where map = &nobounce_dmamap, the STAILQ_INSERT_TAIL() faults since the bpages list is never intialised. If the map = NULL stuff isn't really needed (or I'm sure the bus_dmamap_load stuff would have been noticed by now :-), then perhaps it's just some bit-rot that needs to be trimmed. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 08:03:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA09041 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 08:03:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08894; Mon, 20 Apr 1998 15:02:54 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id XAA05663; Mon, 20 Apr 1998 23:02:14 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804201502.XAA05663@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: gibbs@FreeBSD.ORG cc: scsi@FreeBSD.ORG Subject: ahh, I think I see part of the problem.. (CAM bouncing) Date: Mon, 20 Apr 1998 23:02:13 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems that bus_dmamem_alloc() is flawed if a filter function is active, for starters. With a Bt-445S, it's got to bounce the 'paddr % 16MB == biosaddr' pages, so the contigmalloc() will allocate pages from the entire memory pool (since the 445S has a 32bit dma limit), and yet bouncing may still need to happen. Incidently, what happens if contigmalloc() allocates a page from the shadow of the bios rom addr? :-) Also, there doesn't appear to be anything to stop the DMA counters crossing the dreaded 16MB boundary.. I have a revision of the card that does not incrememt the top 8 bits at the end of the 16MB space. Ie: the counters wrap from 15MB->0MB instead of 15MB->16MB (and 31MB->16MB instead of 31MB-> 32MB). Damn this card. :-) (However, I seem to recall that this particular problem was fixable with a firmware upgrade (microprocessor firmware, not the PC bios), unlike the incomplete address decode problem that creates the bios shadow). Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 08:26:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA13506 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 08:26:34 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA13338 for ; Mon, 20 Apr 1998 15:24:37 GMT (envelope-from rzig@verio.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Mon, 20 Apr 1998 10:23:49 -0500 Message-ID: From: Raul Zighelboim To: "'scsi@freebsd.org'" Subject: RE: Help ! Scsi buss going down ! Date: Mon, 20 Apr 1998 10:23:46 -0500 X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This system seems to have suffer from a massive stroke! With lots of testing, we got to the same conclusion yesterday revision E has problems over load (run iozone and see the system freeze). I am running 3 revision D cards, but maybe one of them is defective. We will keep replacing cards. Unrelated , every time we reboot the server, we get an error message at reboot. It does not matter how clean the shutdown was: (sync; sync; sync; /sbin/umount -a; /sbin/shutdown -h now)... fsck complains at reboot: Cannot alloc 3317710 bytes for blockmap Cannot check file system .... running fsck manually will show a clean fs. Any idea on how I can fix this >? ================================================== Raul Zighelboim rzig@verio.net > -----Original Message----- > From: Greg Rowe [SMTP:greg@uswest.net] > Sent: Monday, April 20, 1998 8:17 AM > To: Raul Zighelboim; 'scsi@freebsd.org' > Subject: Re: Help ! Scsi buss going down ! > > Last week we discovered a problem with a number of our new systems > that > contained Adaptec 2940UW Revision E chips. All systems containing the > E > revision chips are failing under load with SCSI resets. The 'D' > revision works > fine in those systems. Our hardware vendor is trying to get some > information > out of Adaptec on this problem, but it almost looks like they > discovered a bug > in that version and yanked it. All Adaptec 2940's coming out of the > channels > now seem to be Revision 'D'. You can check dmesg to determine what > version you > have. > > ahc0 rev 1 int a irq 9 on > pci0:13 > > The "rev 1" is the E revision and "rev 0" is D. Dropping the transfer > rate to > 10mbs/sec on all your drives will also correct(hide) the problem. > > Greg > > > On Apr 18, 11:32am, Raul Zighelboim wrote: > > Subject: Help ! Scsi buss going down ! > > > > Hello there; I have replace the drives, I have replaced the > controller. > > I will replace the external cable, and switch from 'external active > > termination' to 'drive built in termination' for the scsi bus. > > It cannot be a driver/software issue, there are two busses involved, > and > > it is always the same one the on with the problem. > > > > Is tehre something I am missing ? > > > > I keep getting this on the console: > > > > sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == > 0xe6 > > SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > > Ordered Tag queued > > sd3(ahc0:2:0): SCB 0xc timedout while recovery in progress > > sd3(ahc0:2:0): SCB 0x5 timedout while recovery in progress > > sd3(ahc0:2:0): SCB 0xd timedout while recovery in progress > > sd4(ahc0:4:0): SCB 0xa timedout while recovery in progress > > sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == > 0xe6 > > SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > > sd3(ahc0:2:0): abort message in message buffer > > sd3(ahc0:2:0): SCB 0x1 - timed out in dataout phase, SCSISIGI == > 0xf6 > > SEQADDR = 0x12e SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 > > sd3(ahc0:2:0): no longer in timeout > > ahc0: Issued Channel A Bus Reset. 10 SCBs aborted > > sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, > > SCSISIGI == 0x0 > > SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > > Ordered Tag queued > > sd0(ahc0:3:0): SCB 0xf timedout while recovery in progress > > sd3(ahc0:2:0): SCB 0xd timedout while recovery in progress > > sd3(ahc0:2:0): SCB 0xc timedout while recovery in progress > > sd4(ahc0:4:0): SCB 0xa timedout while recovery in progress > > sd3(ahc0:2:0): SCB 0x5 timedout while recovery in progress > > sd0(ahc0:3:0): SCB 0x4 timedout while recovery in progress > > sd0(ahc0:3:0): SCB 0x2 timedout while recovery in progress > > sd3(ahc0:2:0): SCB 0x1 timedout while recovery in progress > > sd4(ahc0:4:0): SCB 0x0 timedout while recovery in progress > > sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, > > SCSISIGI == 0x0 > > SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > > sd0(ahc0:3:0): Queueing an Abort SCB > > sd0(ahc0:3:0): SCB 0x10 - timed out while idle, LASTPHASE == 0x1, > > SCSISIGI == 0x0 > > SEQADDR = 0x17c SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 > > sd0(ahc0:3:0): no longer in timeout > > ahc0: Issued Channel A Bus Reset. 11 SCBs aborted > > sd0(ahc0:3:0): UNIT ATTENTION asc:29,0 > > sd0(ahc0:3:0): Power on, reset, or bus device reset occurred field > > replaceable unit: 80 > > , retries:2 > > sd3(ahc0:2:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > > , retries:2 > > sd9(ahc0:5:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > > , retries:4 > > sd4(ahc0:4:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > > , retries:2 > > sd1(ahc0:0:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > > , retries:4 > > sd10(ahc0:6:0): UNIT ATTENTION asc:29,2 field replaceable unit: 2 > > , retries:4 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-scsi" in the body of the message > >-- End of excerpt from Raul Zighelboim > > > > -- > Greg Rowe US WEST - !NTERACT Internet Services > "To err is human, to really foul up requires the root password." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 09:33:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA01717 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 09:33:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01540 for ; Mon, 20 Apr 1998 16:32:06 GMT (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id KAA17559; Mon, 20 Apr 1998 10:31:49 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199804201631.KAA17559@panzer.plutotech.com> Subject: Re: Help ! Scsi buss going down ! In-Reply-To: from Raul Zighelboim at "Apr 20, 98 10:23:46 am" To: rzig@verio.net (Raul Zighelboim) Date: Mon, 20 Apr 1998 10:31:49 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] 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 Raul Zighelboim wrote... > > This system seems to have suffer from a massive stroke! > > With lots of testing, we got to the same conclusion yesterday revision E > has problems over load (run iozone and see the system freeze). I am > running 3 revision D cards, but maybe one of them is defective. We will > keep replacing cards. Have you considered running CAM? There are many bugs that have been fixed in the CAM version of the Adaptec driver. At the very least, the error recovery code in CAM is generally better than the old code, so that might help stabilize your system somewhat. To see what is involved, see: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/README or ftp://ftp.kdm.org/pub/FreeBSD/cam/README You'll have to run -current, which may or may not work in your case. If not, you'll have to wait until Justin gets time to port CAM to 2.2-stable. > Unrelated , every time we reboot the server, we get an error message at > reboot. It does not matter how clean the shutdown was: (sync; sync; > sync; /sbin/umount -a; /sbin/shutdown -h now)... > > fsck complains at reboot: > Cannot alloc 3317710 bytes for blockmap > Cannot check file system > .... > running fsck manually will show a clean fs. > > Any idea on how I can fix this >? You need to adjust the amount of memory that the 'daemon' class is allowed to use in /etc/login.conf. Problems like that typically show up when you try to fsck a large filesystem, or run savecore on a RAM image from a system with a lot of memory. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 09:49:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06491 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 09:49:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06326; Mon, 20 Apr 1998 16:48:26 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA27912; Mon, 20 Apr 1998 10:48:14 -0600 (MDT) Message-Id: <199804201648.KAA27912@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Peter Wemm cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: New CAM w/ buslogic doesn't do bounce buffers correctly.. In-reply-to: Your message of "Mon, 20 Apr 1998 21:36:41 +0800." <199804201336.VAA04663@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Apr 1998 10:44:25 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It seems that when bt_ccb's are allocated, the dmamap pointer isn't >initialized, so it stays null. This causes a few things to hit a fatal >trap at first call since map == NULL isn't checked in a few critical >places (bus_dmamap_load for starters). add_bounce_page() doesn;'t work if >the map = NULL -> map = &nobounce_dmamap conversion happens since the >bpages SLIST isn't initialized there either. The idea was that a NULL map meant that bouncing wasn't possible. Because of coding flaws in the bt driver where the map wasn't initialized, this "heuristic" didn't work for your cards. I've changed the bus dma code to explicitly set maps to the nobounce map instead of relying on NULL. >At a guess, it should be set pointing to the instance of the >containing page's sg->sg_dmamap. so, perhaps >+ new_ccb->dmamap = sg->sg_dmamap? Nope. It needs to be allocating a new dmamap for each CCB that can occur concurrently using the bt->buffer_dmat. > do { >[..] > if (map->pagesneeded != 0 && run_filter(dmat, paddr)) { > paddr = add_bounce_page(dmat, map, vaddr, size); > } >[..] > >And add_bounce_page() does: You should never get to either of these locations if bouncing is not required. >In the instance where map = &nobounce_dmamap, the STAILQ_INSERT_TAIL() >faults since the bpages list is never intialised. Which is a good thing because it's a bug if any bounce pages are added to the nobounce_dmamap. It's only a place holder. >Cheers, >-Peter >-- >Peter Wemm Netplex Consulting -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 09:57:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09161 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 09:57:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09109; Mon, 20 Apr 1998 16:57:15 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA28393; Mon, 20 Apr 1998 10:57:01 -0600 (MDT) Message-Id: <199804201657.KAA28393@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Peter Wemm cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Mon, 20 Apr 1998 23:02:13 +0800." <199804201502.XAA05663@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Apr 1998 10:53:12 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It seems that bus_dmamem_alloc() is flawed if a filter function is active, >for starters. With a Bt-445S, it's got to bounce the 'paddr % 16MB == >biosaddr' pages, so the contigmalloc() will allocate pages from the entire >memory pool (since the 445S has a 32bit dma limit), and yet bouncing may >still need to happen. Incidently, what happens if contigmalloc() >allocates a page from the shadow of the bios rom addr? :-) Take a good look at the initialization code in bt_isa.c. If we have to install a filter, we set the address range for the filter to be 16MB->4GB. bus_dmamem_alloc and the code that allocates bounce pages only allocates space below the low address specified in the dma tag. This should ensure that we allocate pages that can replace any page rejected by the filter. So, the setup for a broken 445S is the same as an ISA card except that we include a filter that will allow 99% of the pages above 16MB. >Also, there doesn't appear to be anything to stop the DMA counters crossing >the dreaded 16MB boundary.. ??? If you are talking about the problem below, feel free to adjust the filter to exclude the pages that may cause a wrap. >I have a revision of the card that does not >incrememt the top 8 bits at the end of the 16MB space. Ie: the counters >wrap from 15MB->0MB instead of 15MB->16MB (and 31MB->16MB instead of 31MB-> >32MB). Damn this card. :-) (However, I seem to recall that this >particular problem was fixable with a firmware upgrade (microprocessor >firmware, not the PC bios), unlike the incomplete address decode problem >that creates the bios shadow). This I don't know about, but Mylex was happy to send me a firmware upgrade for my 747C without charge, just last week. > >Cheers, >-Peter >-- >Peter Wemm Netplex Consulting Here are the patches I promised... -- Justin ==== //depot/cam/sys/dev/buslogic/bt.c#6 - /a/perforce/src/sys/dev/buslogic/bt.c ==== *** /tmp/tmp.14455.1 Mon Apr 20 10:27:58 1998 --- /a/perforce/src/sys/dev/buslogic/bt.c Mon Apr 20 10:25:38 1998 *************** *** 865,873 **** --- 865,879 ---- newcount = (PAGE_SIZE / (BT_NSEG * sizeof(bt_sg_t))); for (i = 0; bt->num_ccbs < bt->max_ccbs && i < newcount; i++) { + int error; + next_ccb->sg_list = segs; next_ccb->sg_list_phys = physaddr; next_ccb->flags = BCCB_FREE; + error = bus_dmamap_create(bt->buffer_dmat, /*flags*/0, + &next_ccb->dmamap); + if (error != 0) + break; SLIST_INSERT_HEAD(&bt->free_bt_ccbs, next_ccb, links); segs += BT_NSEG; physaddr += (BT_NSEG * sizeof(bt_sg_t)); *************** *** 1240,1260 **** return; } - s = splcam(); - - /* - * Last time we need to check if this CCB needs to - * be aborted. - */ - if (ccb->ccb_h.status != CAM_REQ_INPROG) { - if (nseg != 0) - bus_dmamap_unload(bt->buffer_dmat, bccb->dmamap); - btfreeccb(bt, bccb); - xpt_done(ccb); - splx(s); - return; - } - if (nseg != 0) { bt_sg_t *sg; bus_dma_segment_t *end_seg; --- 1246,1251 ---- *************** *** 1291,1296 **** --- 1282,1302 ---- bccb->hccb.opcode = INITIATOR_SG_CCB; bccb->hccb.data_len = 0; bccb->hccb.data_addr = 0; + } + + s = splcam(); + + /* + * Last time we need to check if this CCB needs to + * be aborted. + */ + if (ccb->ccb_h.status != CAM_REQ_INPROG) { + if (nseg != 0) + bus_dmamap_unload(bt->buffer_dmat, bccb->dmamap); + btfreeccb(bt, bccb); + xpt_done(ccb); + splx(s); + return; } bccb->flags = BCCB_ACTIVE; ==== //depot/cam/sys/i386/i386/busdma_machdep.c#13 - /a/perforce/src/sys/i386/i386/busdma_machdep.c ==== *** /tmp/tmp.14455.3 Mon Apr 20 10:27:58 1998 --- /a/perforce/src/sys/i386/i386/busdma_machdep.c Mon Apr 20 10:21:17 1998 *************** *** 280,286 **** } } } else { ! *mapp = NULL; } if (error == 0) dmat->map_count++; --- 280,286 ---- } } } else { ! *mapp = &nobounce_dmamap; } if (error == 0) dmat->map_count++; *************** *** 314,320 **** bus_dmamap_t *mapp) { /* If we succeed, no mapping/bouncing will be required */ ! *mapp = NULL; if ((dmat->maxsize <= PAGE_SIZE) && dmat->lowaddr >= ptoa(Maxmem)) { *vaddr = malloc(dmat->maxsize, M_DEVBUF, --- 314,320 ---- bus_dmamap_t *mapp) { /* If we succeed, no mapping/bouncing will be required */ ! *mapp = &nobounce_dmamap; if ((dmat->maxsize <= PAGE_SIZE) && dmat->lowaddr >= ptoa(Maxmem)) { *vaddr = malloc(dmat->maxsize, M_DEVBUF, *************** *** 401,409 **** vaddr += PAGE_SIZE; } } - - if (map == NULL) - map = &nobounce_dmamap; /* Reserve Necessary Bounce Pages */ if (map->pagesneeded != 0) { --- 401,406 ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 10:48:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21714 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 10:48:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from eyelab.psy.msu.edu (eyelab.psy.msu.edu [35.8.64.179]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21704 for ; Mon, 20 Apr 1998 17:48:13 GMT (envelope-from root@eyelab.psy.msu.edu) Received: from iso221.psy.msu.edu (blah@iso221.psy.msu.edu [35.8.110.61]) by eyelab.psy.msu.edu (8.8.8/8.8.7) with SMTP id NAA19524 for ; Mon, 20 Apr 1998 13:47:09 -0400 (EDT) (envelope-from root@eyelab.psy.msu.edu) Message-Id: <199804201747.NAA19524@eyelab.psy.msu.edu> X-Sender: root@eyelab.msu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 20 Apr 1998 13:49:15 -0400 To: freebsd-scsi@FreeBSD.ORG From: Gary Schrock Subject: bad request errors on scsi tape drive Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, I've been getting periodic bad request errors on a scsi drive in a machine here. The drive is a conner drive, id's to: "CONNER CTMS 3200 7.00" type 1 removable SCSI 2 on bootup. These errors occur when I try to do a dump (and as far as I've seen so far, only happen when I do a remote dump). From reading the archives I've seen that I need to enable the scsidebug stuff for any chance of getting some help on this, so I'll be sticking the results from that below. Glancing through the logs that I got from this, from my limited knowledge I'm guessing that the error is this: Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): Apr 20 13:39:39 vision /kernel: ststrategy st0(ahc0:2:0): 1 bytes @ blk0 Apr 20 13:39:39 vision /kernel: st0: bad request, must be between 5 and 65536 Looking back in the logs where it was succeeding, the lines looked more like this: Apr 20 13:39:36 vision /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): Apr 20 13:39:36 vision /kernel: ststrategy st0(ahc0:2:0): 8192 bytes @ blk20176 Apr 20 13:39:36 vision /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd I'm attaching everything that seems to have happened in the log from where the login for the dump occurred below this. If anyone has any ideas, I'd appreciate hearing from them. Apr 20 13:39:37 vision /kernel: st0(ahc0:2:0): calling private start() Apr 20 13:39:37 vision /kernel: st0(ahc0:2:0): ststart Apr 20 13:39:38 vision sshd[242]: log: ROOT LOGIN as 'root' from eyelab.psy.msu.edu Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): scsi_cmd Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): get_xs Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): returning Apr 20 13:39:38 vision /kernel: xs(0xf04abb00): flg(0x60)sc_link(0xf04abb80)retr(0x2)timo(0x186a0)cmd(0xf04abb58)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): scsi_done Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): back in cmd() Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): free_xs Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): calling private start() Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): get_xs Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): returning Apr 20 13:39:38 vision /kernel: xs(0xf04abb00): flg(0x20)sc_link(0xf04abb80)retr(0x2)timo(0x186a0)cmd(0xf04abb58)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): scsi_done Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): back in cmd() Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): free_xs Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): calling private start() Apr 20 13:39:38 vision /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): get_xs Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): returning Apr 20 13:39:39 vision /kernel: xs(0xf04abb00): flg(0xe0)sc_link(0xf04abb80)retr(0x2)timo(0x1388)cmd(0xf04abb58)len(0x6)data (0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1e,0,0,0,1,0-[0 bytes] Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): scsi_done Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): command: 1e,0,0,0,1,0-[0 bytes] Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): back in cmd() Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): free_xs Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): calling private start() Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): Open complete Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): stopen: dev=0xe01 (unit 0) result 0 Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): Apr 20 13:39:39 vision /kernel: ststrategy st0(ahc0:2:0): 1 bytes @ blk0 Apr 20 13:39:39 vision /kernel: st0: bad request, must be between 5 and 65536 Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): stclose: Closing device Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): scsi_cmd Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): get_xs Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): returning Apr 20 13:39:39 vision /kernel: xs(0xf04abb00): flg(0x60)sc_link(0xf04abb80)retr(0x2)timo(0x1388)cmd(0xf04abb58)len(0x6)data (0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1e,0,0,0,0,0-[0 bytes] Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): scsi_done Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): command: 1e,0,0,0,0,0-[0 bytes] Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): back in cmd() Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): free_xs Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): calling private start() Apr 20 13:39:39 vision /kernel: st0(ahc0:2:0): ststart Thanks, Gary Schrock root@eyelab.msu.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 11:03:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25829 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 11:03:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25680 for ; Mon, 20 Apr 1998 18:03:15 GMT (envelope-from michael_class@hp.com) Received: from pc-micha.mc.hp.com (apc1mc10.bbn.hp.com [15.124.134.10]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id OAA21054 for ; Mon, 20 Apr 1998 14:02:30 -0400 (EDT) Received: from hp.com (localhost.mc.hp.com [127.0.0.1]) by pc-micha.mc.hp.com (8.8.8/8.7.3) with ESMTP id RAA00377 for ; Sun, 19 Apr 1998 17:55:17 +0200 (MEST) Message-ID: <353A1E64.DBD1A5D2@hp.com> Date: Sun, 19 Apr 1998 17:55:16 +0200 From: Micha Class X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: scsi@FreeBSD.ORG Subject: handling of XS_SELTIMEOUT for UMAX scanner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, just a question regarding the handling of XS_SELTIMEOUT in scsi_ioctl.c. I ran into the problem of getting error like "uk0: unknown error category from host adapter code" from scsi_ioctl.c when I added a scanner (Umax Stra 1200S) to my FreeBSD 3.0 (very) current system. This caused some followup problems in sane. After digging a little bit into this, it looks like the ncr.c driver gives back a status of XS_SELTIMEOUT for some status inquiries, which are not handled in routine scsi_usr_done in scsi_ioctl.c. This causes the above error-message. Question: Is this intended? Should XS_SELTIMEOUT be handled here? For me all the problems (with the exception of a couple of core-dumps in the gtk-frontend of sane) go away if I handle XS_SELTIMEOUT the same as XS_TIMEOUT in scsi_user_done. Will this cause some problems in other cases? Michael This is the patch I am using: *** scsi_ioctl.c Sun Apr 19 17:50:00 1998 --- scsi_ioctl.c.NEW Sun Apr 19 17:49:49 1998 *************** *** 121,126 **** --- 121,127 ---- break; case XS_TIMEOUT: + case XS_SELTIMEOUT: SC_DEBUG(xs->sc_link,SDEV_DB3,("timeout\n")); screq->retsts = SCCMD_TIMEOUT; break; -- ------------------------------------------------------------------------- michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: michael_class@hp.com Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 11:08:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26915 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 11:08:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA26725 for ; Mon, 20 Apr 1998 18:08:11 GMT (envelope-from michael_class@hp.com) Received: from hpbbse.bbn.hp.com (root@hpbbse.bbn.hp.com [15.136.26.26]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id LAA28526 for ; Mon, 20 Apr 1998 11:08:02 -0700 (PDT) Received: from hp.com (apc1mc10.bbn.hp.com [15.124.134.10]) by hpbbse.bbn.hp.com with ESMTP (8.7.6/8.7.3) id TAA23211 for ; Mon, 20 Apr 1998 19:07:59 +0100 (MEZ) Message-ID: <353B8EE4.2DCCAF0F@hp.com> Date: Mon, 20 Apr 1998 20:07:32 +0200 From: Micha Class X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: scsi@FreeBSD.ORG Subject: UMAX-Scanner SCANNER, SCSI and XS_TIMEOUT in ncr.c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, just a question regarding the handling of XS_SELTIMEOUT in scsi_ioctl.c. I ran into the problem of getting error like "uk0: unknown error category from host adapter code" from scsi_ioctl.c when I added a scanner (Umax Stra 1200S) to my FreeBSD 3.0 (very) current system. This caused some followup problems in sane. After digginig a little bit into this, it looks like the ncr.c driver gives back a status of XS_SELTIMEOUT for some status inquiries, which are not handled in routine scsi_usr_done in scsi_ioctl.c. This causes the above error-message. Question: Is this intended? Should XS_SELTIMEOUT be handled here? For me all the problems (with the exception of a couple of core-dumps in the gtk-frontend of sane) go away if I handle XS_SELTIMEOUT the same as XS_TIMEOUT in scsi_user_done. Will this cause some problems in other cases? Michael This is the patch I am using: *** scsi_ioctl.c Sun Apr 19 17:50:00 1998 --- scsi_ioctl.c.NEW Sun Apr 19 17:49:49 1998 *************** *** 121,126 **** --- 121,127 ---- break; case XS_TIMEOUT: + case XS_SELTIMEOUT: SC_DEBUG(xs->sc_link,SDEV_DB3,("timeout\n")); screq->retsts = SCCMD_TIMEOUT; break; -- ------------------------------------------------------------------------- michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: michael_class@hp.com Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 11:14:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28278 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 11:14:01 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from george.arc.nasa.gov (george.arc.nasa.gov [128.102.194.142]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28085 for ; Mon, 20 Apr 1998 18:13:21 GMT (envelope-from lamaster@george.arc.nasa.gov) Received: (from lamaster@localhost) by george.arc.nasa.gov (8.8.7/8.8.7) id LAA01255; Mon, 20 Apr 1998 11:13:03 -0700 (PDT) Date: Mon, 20 Apr 1998 11:13:01 -0700 (PDT) From: Hugh LaMaster To: freebsd-scsi@FreeBSD.ORG Subject: Re: Adaptec 7895 On-Board SCSI Controller 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, 27 Mar 1998, Cory Kempf wrote: [somebody wrote:] > >>I'm thinking about buying the 333mhz pentium ii and > >>intel dk 440lx m/b, usb, wol, agp chipset, crystal audio, > >>dual scsi, raid connection. Which I understand is using > >>Adaptec 7895 MB controller. Will this work with FreeBSD? The new BX-based boards from Supermicro also use the 7895. It seems to be catching on. So, although it may not be what people prefer, I guess we will have to live with it. > >You need to run -current, you need CAM, and (last I checked), you need to > >have a kernel based on the March 12 source base. > > > >To install, you will need the CAM based floppy kernel. Look in /incomming. > >Once you have installed, and installed the cam-kernel via the fixit floppy, > >you will need to boot with -a at the boot prompt -- at least I did. > > > >Not sure that AGP is working, I chickened out and went with PCI for my > >first graphics card. Why would the 7895/SCSI affect AGP? > >So far, I don't have working audio or serial, and have not tried RAID. > > > >Good luck: you will need it. Well, it has been a while now. Any update on the status of how well the 7895 code is working? Is it kind-of/sort-of safe to use now? Several new and possibly attractive boards are using the 7895. -- Hugh LaMaster, M/S 233-21, ASCII Email: hlamaster@mail.arc.nasa.gov NASA Ames Research Center Or: lamaster@george.arc.nasa.gov Moffett Field, CA 94035-1000 No Junkmail: USC 18 section 2701 Phone: 650/604-1056 Disclaimer: Unofficial, personal *opinion*. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 11:15:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28798 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 11:15:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28561; Mon, 20 Apr 1998 18:14:50 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id BAA07818; Tue, 21 Apr 1998 01:50:30 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804201750.BAA07818@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Mon, 20 Apr 1998 10:53:12 CST." <199804201657.KAA28393@pluto.plutotech.com> Date: Tue, 21 Apr 1998 01:50:29 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: > >It seems that bus_dmamem_alloc() is flawed if a filter function is active, > >for starters. With a Bt-445S, it's got to bounce the 'paddr % 16MB == > >biosaddr' pages, so the contigmalloc() will allocate pages from the entire > >memory pool (since the 445S has a 32bit dma limit), and yet bouncing may > >still need to happen. Incidently, what happens if contigmalloc() > >allocates a page from the shadow of the bios rom addr? :-) > > Take a good look at the initialization code in bt_isa.c. If we have to > install a filter, we set the address range for the filter to be 16MB->4GB. > bus_dmamem_alloc and the code that allocates bounce pages only allocates > space below the low address specified in the dma tag. This should ensure > that we allocate pages that can replace any page rejected by the filter. > So, the setup for a broken 445S is the same as an ISA card except that we > include a filter that will allow 99% of the pages above 16MB. Right, I hadn't got that far along in working out what was happening.. I was confused about what lowaddr actually meant, and I thought the filter was running on all queries. > >Also, there doesn't appear to be anything to stop the DMA counters crossing > >the dreaded 16MB boundary.. > > ??? If you are talking about the problem below, feel free to adjust the > filter to exclude the pages that may cause a wrap. Well, a page won't cause a wrap, but a single dma transfer shouldn't be allowed to cross the boundary. I guess the 'if (paddr == nextpaddr)' test would be the place to be thinking about attacking that. contigmalloc() can be told to not cross the boundary by specifying the 'boundary' as 0x1000000. Hmm.. after some rummaging around, I found some (very) old notes that suggest that there is a different firmware rom image for card revs A-D (3.36) and rev E only (3.37). Rev.E has the known hardware problems fixed on the PCB. Going from memory, rev 3.35 firmware (which I have) had the 16MB boundary wrap problem, and I think it was patched in firmware rev 3.36 and later. > >I have a revision of the card that does not > >incrememt the top 8 bits at the end of the 16MB space. Ie: the counters > >wrap from 15MB->0MB instead of 15MB->16MB (and 31MB->16MB instead of 31MB-> > >32MB). Damn this card. :-) (However, I seem to recall that this > >particular problem was fixable with a firmware upgrade (microprocessor > >firmware, not the PC bios), unlike the incomplete address decode problem > >that creates the bios shadow). > > This I don't know about, but Mylex was happy to send me a firmware upgrade > for my 747C without charge, just last week. I can ask I guess. :-) I have the v3.36/v4.72 firmware/bios images ready to burn onto eprom - but last time I tried, I couldn't get eproms fast enough and the slower set that I used had to have the clock speed lowered. > >Cheers, > >-Peter > >-- > >Peter Wemm Netplex Consulting > > Here are the patches I promised... Thanks.. :-) Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 11:18:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29639 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 11:18:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (root@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29464 for ; Mon, 20 Apr 1998 18:18:03 GMT (envelope-from mjacob@feral.com) Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id LAA16196; Mon, 20 Apr 1998 11:17:10 -0700 Message-ID: <353B9125.7832C852@feral.com> Date: Mon, 20 Apr 1998 11:17:09 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Micha Class CC: scsi@FreeBSD.ORG Subject: Re: handling of XS_SELTIMEOUT for UMAX scanner References: <353A1E64.DBD1A5D2@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would think it shouldn't be handled this way. A selection timeout implies you couldn't acquire the SCSI bus to talk to the target, so the command in fact didn't start- hence saying it 'timed out' is misleading. I'd put a separate case to handle it (if only to quiesce the error message) and either return SCCMD_UNKNOWN, or extend the semantics here so that something, say, SCCMD_BUSFART, is returned (indicating a non-nexus specific error has occurred). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 11:25:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02481 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 11:25:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02291; Mon, 20 Apr 1998 18:25:09 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id MAA02812; Mon, 20 Apr 1998 12:24:01 -0600 (MDT) Message-Id: <199804201824.MAA02812@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: "Justin T. Gibbs" cc: Peter Wemm , gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Mon, 20 Apr 1998 12:18:21 MDT." <199804201822.MAA02724@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Apr 1998 12:20:11 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Well, a page won't cause a wrap, but a single dma transfer shouldn't be >>allowed to cross the boundary. > >I wasn't trying to be that specific. If you have the filter reject all >pages just above the wrap point, the transfer cannot span the wrap point. I mean the single page just above any wrap points. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 11:43:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01766 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 11:23:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01528; Mon, 20 Apr 1998 18:23:28 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id MAA02724; Mon, 20 Apr 1998 12:22:09 -0600 (MDT) Message-Id: <199804201822.MAA02724@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Peter Wemm cc: "Justin T. Gibbs" , gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Tue, 21 Apr 1998 01:50:29 +0800." <199804201750.BAA07818@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Apr 1998 12:18:21 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >Also, there doesn't appear to be anything to stop the DMA counters crossing >> >the dreaded 16MB boundary.. >> >> ??? If you are talking about the problem below, feel free to adjust the >> filter to exclude the pages that may cause a wrap. > >Well, a page won't cause a wrap, but a single dma transfer shouldn't be >allowed to cross the boundary. I wasn't trying to be that specific. If you have the filter reject all pages just above the wrap point, the transfer cannot span the wrap point. This breaks apart transfers that start at that page location as well as those that span it, but it does do what you want without having to but a special case into the code. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 12:35:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23050 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 12:35:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA23036 for ; Mon, 20 Apr 1998 19:35:21 GMT (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id NAA17845; Mon, 20 Apr 1998 13:31:30 -0600 (MDT) Date: Mon, 20 Apr 1998 13:31:30 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804201931.NAA17845@narnia.plutotech.com> To: Hugh LaMaster cc: scsi@FreeBSD.ORG Subject: Re: Adaptec 7895 On-Board SCSI Controller Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Well, it has been a while now. Any update on the status of how > well the 7895 code is working? Is it kind-of/sort-of safe to use > now? Several new and possibly attractive boards are using the 7895. The 7895 should work just fine if you use CAM. > -- > Hugh LaMaster, M/S 233-21, ASCII Email: hlamaster@mail.arc.nasa.gov > NASA Ames Research Center Or: lamaster@george.arc.nasa.gov > Moffett Field, CA 94035-1000 No Junkmail: USC 18 section 2701 > Phone: 650/604-1056 Disclaimer: Unofficial, personal *opinion*. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 12:41:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA24686 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 12:41:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA24653; Mon, 20 Apr 1998 19:41:08 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id DAA08958; Tue, 21 Apr 1998 03:33:06 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804201933.DAA08958@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Mon, 20 Apr 1998 12:20:11 CST." <199804201824.MAA02812@pluto.plutotech.com> Date: Tue, 21 Apr 1998 03:33:05 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: > >>Well, a page won't cause a wrap, but a single dma transfer shouldn't be > >>allowed to cross the boundary. > > > >I wasn't trying to be that specific. If you have the filter reject all > >pages just above the wrap point, the transfer cannot span the wrap point. > > I mean the single page just above any wrap points. I tried the previous patch that you posted but had a pretty spectacular explosion on a BT545S.. It "found" devices all the way up to da11 (at target 2 lun 5) and failed to mount root. The probes were reporting garbage.. Hmm.. Are all the allocations being zeroed? I added a 'if (addr == 0) return (1)' type test at the end of the vlfilter function, but the 445S doesn't work properly either. Things get SEGV during bootup to multi-user (eg: sendmail, nmbd etc), and the system usually panics with a 'vm_fault on nofault entry' type panic fairly shortly after that. I suspect the bios shadow avoidance has kicked in and a bug has been triggered (it doesn't work on the 545S at all, so that's why I suspect the bouncing). Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 12:45:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25595 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 12:45:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25556 for ; Mon, 20 Apr 1998 19:45:10 GMT (envelope-from jambi@oceana.nlanr.net) Received: from localhost (jambi@localhost) by nlanr.net (8.8.6/8.8.6) with SMTP id MAA15043; Mon, 20 Apr 1998 12:44:51 -0700 (PDT) Date: Mon, 20 Apr 1998 12:44:51 -0700 (PDT) From: Jambi Ganbar To: "Justin T. Gibbs" cc: Hugh LaMaster , scsi@FreeBSD.ORG Subject: Adaptec 2940 U2W support In-Reply-To: <199804201931.NAA17845@narnia.plutotech.com> 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, I have an adaptec 2940U2W controler which I'd like to use in FreeBSD based OC3MON. The issues that I'm trying to atack here is the fact that with a saturated oc3 link we can expect a contiuous write to disk on 38.5MB/sec. I know that there is support for the card with the CAM stuff, but I am relactent to use 3.0 as it might A) Break the oc3mon stuff, B)might not be stable/secure enough for oiur purposes. What I'd like to know is if there will be CAM patches to 2.2.6 or 2.2.5 source trees and if so where and when. Thanx for the time, Jambi _______________________________________________ Jambi Ganbar | (619) 8220938 | jambi@nlanr.net San Diego SuperComputer Center ________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 14:12:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20271 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 14:12:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20121 for ; Mon, 20 Apr 1998 21:12:18 GMT (envelope-from rzig@verio.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Mon, 20 Apr 1998 16:11:23 -0500 Message-ID: From: Raul Zighelboim To: "'Kenneth D. Merry'" Cc: scsi@FreeBSD.ORG Subject: RE: Help ! Scsi buss going down ! Date: Mon, 20 Apr 1998 16:11:22 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org were leaving the adaptec and getting a dpt for this server soon (as fast as UPS can deliver), so, no, not considered CAM at this point. In any case, it seems that we track down the problem (the initial problem, not the one we caused trying to fix it ;-|) We had an adaptec card going bad, we got a replacement (revision E of the bios) that was worse than bad. ================================================== Raul Zighelboim rzig@verio.net > -----Original Message----- > From: Kenneth D. Merry [SMTP:ken@plutotech.com] > Sent: Monday, April 20, 1998 11:32 AM > To: Raul Zighelboim > Cc: scsi@FreeBSD.ORG > Subject: Re: Help ! Scsi buss going down ! > > Raul Zighelboim wrote... > > > > This system seems to have suffer from a massive stroke! > > > > With lots of testing, we got to the same conclusion yesterday > revision E > > has problems over load (run iozone and see the system freeze). I am > > running 3 revision D cards, but maybe one of them is defective. We > will > > keep replacing cards. > > Have you considered running CAM? There are many bugs that have > been fixed in the CAM version of the Adaptec driver. At the very > least, > the error recovery code in CAM is generally better than the old code, > so > that might help stabilize your system somewhat. To see what is > involved, > see: > > ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/README > > or > > ftp://ftp.kdm.org/pub/FreeBSD/cam/README > > You'll have to run -current, which may or may not work in your > case. If not, you'll have to wait until Justin gets time to port CAM > to > 2.2-stable. > > > Unrelated , every time we reboot the server, we get an error message > at > > reboot. It does not matter how clean the shutdown was: (sync; sync; > > sync; /sbin/umount -a; /sbin/shutdown -h now)... > > > > fsck complains at reboot: > > Cannot alloc 3317710 bytes for blockmap > > Cannot check file system > > .... > > running fsck manually will show a clean fs. > > > > Any idea on how I can fix this >? > > You need to adjust the amount of memory that the 'daemon' class > is > allowed to use in /etc/login.conf. Problems like that typically show > up > when you try to fsck a large filesystem, or run savecore on a RAM > image > from a system with a lot of memory. > > Ken > -- > Kenneth Merry > ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 15:41:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA13989 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 15:41:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA13900 for ; Mon, 20 Apr 1998 22:40:32 GMT (envelope-from jak@cetlink.net) Received: from EXIT10 (i485-gw.cetlink.net [209.198.15.97]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id SAA14504; Mon, 20 Apr 1998 18:40:09 -0400 (EDT) From: jak@cetlink.net (John Kelly) To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) Date: Mon, 20 Apr 1998 22:42:17 GMT Message-ID: <353cce7e.94813933@mail.cetlink.net> References: <199804201657.KAA28393@pluto.plutotech.com> In-Reply-To: <199804201657.KAA28393@pluto.plutotech.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id WAA13925 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Apr 1998 10:53:12 -0600, "Justin T. Gibbs" wrote: >>It seems that bus_dmamem_alloc() is flawed if a filter function is active, >>for starters. With a Bt-445S, it's got to bounce the 'paddr % 16MB == >>biosaddr' pages, so the contigmalloc() will allocate pages from the entire >>memory pool (since the 445S has a 32bit dma limit), and yet bouncing may >>still need to happen. Incidently, what happens if contigmalloc() >>allocates a page from the shadow of the bios rom addr? :-) > >Take a good look at the initialization code in bt_isa.c. If we have to >install a filter, we set the address range for the filter to be 16MB->4GB. >bus_dmamem_alloc and the code that allocates bounce pages only allocates >space below the low address specified in the dma tag. This should ensure >that we allocate pages that can replace any page rejected by the filter. >So, the setup for a broken 445S is the same as an ISA card except that we >include a filter that will allow 99% of the pages above 16MB. After reading this I don't understand what's broken about the 445S. Could you put it in more simple language? I have some 445C adapters and I wonder if they have the same characteristic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 16:22:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA22955 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 16:22:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA22846 for ; Mon, 20 Apr 1998 23:22:02 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id RAA17435; Mon, 20 Apr 1998 17:21:39 -0600 (MDT) Message-Id: <199804202321.RAA17435@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: jak@cetlink.net (John Kelly) cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Mon, 20 Apr 1998 22:42:17 GMT." <353cce7e.94813933@mail.cetlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Apr 1998 17:17:50 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >After reading this I don't understand what's broken about the 445S. >Could you put it in more simple language? I have some 445C adapters >and I wonder if they have the same characteristic. The 445S cannot properly transfer data to or from any address between (16MB * n) + BiosAddres and (16MB * n) + BiosAddress + BiosSize For n > 0 I do not believe that the 445C has this problem. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 17:07:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA05257 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 17:07:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA05250 for ; Tue, 21 Apr 1998 00:07:13 GMT (envelope-from jak@cetlink.net) Received: from EXIT10 (i485-gw.cetlink.net [209.198.15.97]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id UAA23584; Mon, 20 Apr 1998 20:07:07 -0400 (EDT) From: jak@cetlink.net (John Kelly) To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) Date: Tue, 21 Apr 1998 00:09:16 GMT Message-ID: <353fe202.99810970@mail.cetlink.net> References: <199804202321.RAA17435@pluto.plutotech.com> In-Reply-To: <199804202321.RAA17435@pluto.plutotech.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id AAA05252 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Apr 1998 17:17:50 -0600, "Justin T. Gibbs" wrote: >The 445S cannot properly transfer data to or from any address between > > (16MB * n) + BiosAddres >and > (16MB * n) + BiosAddress + BiosSize > >For n > 0 > >I do not believe that the 445C has this problem. So in any 16MB region above the first, there's this little area the same size as the BIOS you can't use? Now I understand why you said a filter would allow 99% of all pages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 17:38:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08610 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 17:38:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08510 for ; Tue, 21 Apr 1998 00:37:57 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id SAA20039; Mon, 20 Apr 1998 18:21:35 -0600 (MDT) Message-Id: <199804210021.SAA20039@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: jak@cetlink.net (John Kelly) cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Tue, 21 Apr 1998 00:09:16 GMT." <353fe202.99810970@mail.cetlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Apr 1998 18:17:46 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >So in any 16MB region above the first, there's this little area the >same size as the BIOS you can't use? Now I understand why you said a >filter would allow 99% of all pages. Yes. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 22:33:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00320 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 22:33:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from haywire.dialix.com.au (news@haywire.dialix.com.au [202.12.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA00296 for ; Tue, 21 Apr 1998 05:33:09 GMT (envelope-from usenet-request@haywire.dialix.com.au) Received: (from news@localhost) by haywire.dialix.com.au (8.8.8/8.8.8/Haywire) id NAA08746 for freebsd-scsi@freebsd.org; Tue, 21 Apr 1998 13:32:42 +0800 (WST) (envelope-from usenet-request@haywire.dialix.com.au) X-Authentication-Warning: haywire.dialix.com.au: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.dialix.com.au with netnews for freebsd-scsi@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-scsi@FreeBSD.ORG Date: 21 Apr 1998 05:32:41 GMT From: peter@netplex.com.au (Peter Wemm) Message-ID: <6hhb1p$7m7$1@haywire.dialix.com.au> Organization: DIALix Services, Perth, Australia. References: <353cce7e.94813933@mail.cetlink.net> Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199804202321.RAA17435@pluto.plutotech.com>, gibbs@plutotech.com (Justin T. Gibbs) writes: >>After reading this I don't understand what's broken about the 445S. >>Could you put it in more simple language? I have some 445C adapters >>and I wonder if they have the same characteristic. > > The 445S cannot properly transfer data to or from any address between > > (16MB * n) + BiosAddres > and > (16MB * n) + BiosAddress + BiosSize > > For n > 0 To be specific, this is a hardware defect on rev A - D cards. Rev E (which has firmware rev 3.37) does not have the problem. You (apparently) cannot use 3.37 firmware on the older A-D cards. Firmware rev 3.35 has an additional problem. Apparently the DMA counters are 24bit plus an 8-bit latch. This means that the bus-master DMA engine cannot DMA across a 16MB boundary. This means that the DMA "counter" wraps from 0x00ffffff to 0x00000000 instead of 0x01000000. This also happens at the 32MB, 48MB etc boundaries. Apparently the 3.36 firmware (for the A-D revision 445S cards) will do the transfer in one stage, reset the upper 8 bits and then do the second stage. I am not _sure_ if that upper 8 bit address is a latch or a counter that was missing the carry from the 3rd stage. There was talk of a hardware patch to the rev A-D cards to fix one of these problems, but I cannot remember the specifics and can't find my old archive of the stuff I downloaded. My gut feeling was that the wraparound was fixable in firmware (a simple matter of splitting a request), but the bios shadow problem was not. > I do not believe that the 445C has this problem. Yes, the 445C has none of these problems. The 445S are very old cards, mine was built in 1993. > -- > Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 20 23:25:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA07104 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 23:25:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA07096; Tue, 21 Apr 1998 06:25:27 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id AAA03372; Tue, 21 Apr 1998 00:24:28 -0600 (MDT) Message-Id: <199804210624.AAA03372@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Peter Wemm cc: "Justin T. Gibbs" , gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Tue, 21 Apr 1998 03:33:05 +0800." <199804201933.DAA08958@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 00:20:39 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I tried the previous patch that you posted but had a pretty spectacular >explosion on a BT545S.. It "found" devices all the way up to da11 (at >target 2 lun 5) and failed to mount root. The probes were reporting >garbage.. Hmm.. Are all the allocations being zeroed? I don't think that is the problem. It is more likely caused by using the wrong dmat on line 261 of bt_isa.c: if (bus_dmamem_alloc(bt->sense_dmat, <= Used to be mailbox_dmat This would allocate the incorrect amount of sense bounce space causing untold trouble. >I added a 'if (addr == 0) return (1)' type test at the end of the vlfilter >function, but the 445S doesn't work properly either. Things get SEGV >during bootup to multi-user (eg: sendmail, nmbd etc), and the system >usually panics with a 'vm_fault on nofault entry' type panic fairly >shortly after that. I suspect the bios shadow avoidance has kicked in and >a bug has been triggered (it doesn't work on the 545S at all, so that's >why I suspect the bouncing). It is probably the sense buffering bug again, but it is only triggered after more commands are run as the VL card has more CCBs than the ISA card and the size of the mailbox_dmat is based on number of CCBs. I hate writing code blind. I'd rather catch my coding bugs myself than have others suffer through it. 8-) >Cheers, >-Peter >-- >Peter Wemm Netplex Consulting -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 00:17:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA12426 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 00:17:47 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from haywire.dialix.com.au (news@haywire.dialix.com.au [202.12.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA12417 for ; Tue, 21 Apr 1998 07:17:39 GMT (envelope-from usenet-request@haywire.dialix.com.au) Received: (from news@localhost) by haywire.dialix.com.au (8.8.8/8.8.8/Haywire) id PAA14453 for freebsd-scsi@freebsd.org; Tue, 21 Apr 1998 15:17:28 +0800 (WST) (envelope-from usenet-request@haywire.dialix.com.au) X-Authentication-Warning: haywire.dialix.com.au: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.dialix.com.au with netnews for freebsd-scsi@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-scsi@FreeBSD.ORG Date: 21 Apr 1998 07:17:27 GMT From: peter@netplex.com.au (Peter Wemm) Message-ID: <6hhh67$7m7$2@haywire.dialix.com.au> Organization: DIALix Services, Perth, Australia. References: <199804201933.DAA08958@spinner.netplex.com.au> Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199804210624.AAA03372@pluto.plutotech.com>, gibbs@plutotech.com (Justin T. Gibbs) writes: >>I tried the previous patch that you posted but had a pretty spectacular >>explosion on a BT545S.. It "found" devices all the way up to da11 (at >>target 2 lun 5) and failed to mount root. The probes were reporting >>garbage.. Hmm.. Are all the allocations being zeroed? > > I don't think that is the problem. It is more likely caused by using > the wrong dmat on line 261 of bt_isa.c: > > if (bus_dmamem_alloc(bt->sense_dmat, <= Used to be mailbox_dmat > > This would allocate the incorrect amount of sense bounce space causing > untold trouble. I'll say.. :-) >>I added a 'if (addr == 0) return (1)' type test at the end of the vlfilter >>function, but the 445S doesn't work properly either. Things get SEGV >>during bootup to multi-user (eg: sendmail, nmbd etc), and the system >>usually panics with a 'vm_fault on nofault entry' type panic fairly >>shortly after that. I suspect the bios shadow avoidance has kicked in and >>a bug has been triggered (it doesn't work on the 545S at all, so that's >>why I suspect the bouncing). > > It is probably the sense buffering bug again, but it is only triggered > after more commands are run as the VL card has more CCBs than the ISA > card and the size of the mailbox_dmat is based on number of CCBs. > > I hate writing code blind. I'd rather catch my coding bugs myself than > have others suffer through it. 8-) That's what testers are for.. Although I'm quietly thankful that it hasn't scrambled block read commands to make them look like scsi 'format disk' commands... :-) Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 01:56:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25493 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 01:56:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.artcom.de (tui.artcom.de [192.76.129.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA25487 for ; Tue, 21 Apr 1998 08:56:17 GMT (envelope-from hans@artcom.de) Received: from transrapid.artcom.de by mail.artcom.de with smtp id m0yRYqe-000008C; Tue, 21 Apr 1998 10:56:16 +0200 (MEST) Date: Tue, 21 Apr 1998 10:56:16 +0200 (MEST) From: Hans Huebner To: freebsd-scsi@FreeBSD.ORG Subject: SCSI-Disk hot-swappability? 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 there, has the issue of making the SCSI disk driver able to support hot-swapping of disks been discussed already? What I'd like to be able to do is: Configure the SCSI disk driver so that it creates sd devices upon boot for any SCSI ID's I specify (i.e. 'device sd0 at scbus2 target 0 unit 0 flags 0xwhatever). The sd driver seems to be prepared for this, but the necessary changes to scsiconf.c do not seem to be there. We'd also need a set of utilities to make the kernel reprobe a given SCSI device. Is anyone reading this already working in that direction? Or is there an alternative sd driver with more features available? We'd even consider commercial alternatives, provided that source code is also available. Thanks, Hans To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 02:21:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA28938 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 02:21:44 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA28906 for ; Tue, 21 Apr 1998 09:21:38 GMT (envelope-from pantzer@father.ludd.luth.se) Received: from father.ludd.luth.se (pantzer@father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.8.5/8.8.5) with SMTP id LAA20948; Tue, 21 Apr 1998 11:21:34 +0200 Message-Id: <199804210921.LAA20948@zed.ludd.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: Hans Huebner cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI-Disk hot-swappability? In-reply-to: Your message of "Tue, 21 Apr 1998 10:56:16 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 11:21:33 +0200 From: Mattias Pantzare Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hello there, > > has the issue of making the SCSI disk driver able to support hot-swapping > of disks been discussed already? > > What I'd like to be able to do is: > > Configure the SCSI disk driver so that it creates sd devices upon boot for > any SCSI ID's I specify (i.e. 'device sd0 at scbus2 target 0 unit 0 flags > 0xwhatever). Why not just type this in your configfile for the kernel? disk sd0 at scbus0 target 0 disk sd1 at scbus0 target 1 disk sd2 at scbus0 target 2 disk sd3 at scbus0 target 3 disk sd4 at scbus0 target 4 disk sd5 at scbus0 target 5 disk sd6 at scbus0 target 6 > The sd driver seems to be prepared for this, but the necessary changes to > scsiconf.c do not seem to be there. We'd also need a set of utilities to > make the kernel reprobe a given SCSI device. The manpage for scsi tells me that it can do that. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 04:44:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA21364 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 04:44:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21239; Tue, 21 Apr 1998 11:43:47 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id TAA19500; Tue, 21 Apr 1998 19:42:31 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804211142.TAA19500@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Tue, 21 Apr 1998 00:20:39 CST." <199804210624.AAA03372@pluto.plutotech.com> Date: Tue, 21 Apr 1998 19:42:30 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: > >I tried the previous patch that you posted but had a pretty spectacular > >explosion on a BT545S.. It "found" devices all the way up to da11 (at > >target 2 lun 5) and failed to mount root. The probes were reporting > >garbage.. Hmm.. Are all the allocations being zeroed? > > I don't think that is the problem. It is more likely caused by using > the wrong dmat on line 261 of bt_isa.c: > > if (bus_dmamem_alloc(bt->sense_dmat, <= Used to be mailbox_dm at > > This would allocate the incorrect amount of sense bounce space causing > untold trouble. Just to be sure, I tried this diff and it still fails with the broken probes. --- bt_isa.c.save Tue Apr 21 00:59:42 1998 +++ bt_isa.c Tue Apr 21 15:15:23 1998 @@ -268,7 +268,7 @@ bt->init_level++; /* And permanently map them */ - bus_dmamap_load(bt->sense_dmat, bt->sense_dmamap, + bus_dmamap_load(bt->mailbox_dmat, bt->sense_dmamap, bt->sense_buffers, bt->max_ccbs * sizeof(*bt->sense_buffers), btmapsensebuffers, bt, /*flags*/0); In this particular case I've been using the 545S since it panics on startup rather than after the system is 95% of the way through booting. After the bad probe, it finally fails with things like: sd0: invalid partition table (or is that invalid partition magic?) error 22: panic: cannot mount root (2) If I do a trace at that point, the nesting is so deep that it scrolls well off the screen so I can't see the more interesting top few stack frames. Do you have a nutshell summary of what all the bus dma calls do so that I have a better chance of finding more useful hints as to what's wrong? Also, what is the function of this variable? static bus_addr_t bounce_lowaddr = BUS_SPACE_MAXADDR; It's set to 0xffffffff. (2^32-1) but appears to be used in a role that I'd almost expect that it was meant to be 0x00ffffff.. On the other hand, it almost looks stale too since contigmalloc always gives a good page. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 10:04:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15394 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:04:25 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15337 for ; Tue, 21 Apr 1998 17:04:12 GMT (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.8.7/8.6.12) id RAA21405; Tue, 21 Apr 1998 17:04:03 GMT Message-ID: <19980421100403.15807@nuxi.com> Date: Tue, 21 Apr 1998 10:04:03 -0700 From: "David O'Brien" To: Mattias Pantzare Cc: Hans Huebner , freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI-Disk hot-swappability? Reply-To: obrien@NUXI.com References: <199804210921.LAA20948@zed.ludd.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199804210921.LAA20948@zed.ludd.luth.se>; from Mattias Pantzare on Tue, Apr 21, 1998 at 11:21:33AM +0200 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.5-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The sd driver seems to be prepared for this, but the necessary changes to > > scsiconf.c do not seem to be there. We'd also need a set of utilities to > > make the kernel reprobe a given SCSI device. I'm not sure which of these gave me re-probability, but... ls /dev/*scsi* crw------- 1 root wheel 18, 0 Nov 4 23:55 scsisuper In my kernel config file: # These are only for watching for bitrot in old SCSI code. # also need to execute: ``(umask 077; mknod /dev/scsisuper c 18 0)'' pseudo-device su #scsi user pseudo-device ssc #super scsi Then run (assuming you didn't swap out your boot drive): /sbin/scsi -f /dev/rsd0.ctl -r And to test, do an inquiry of the device just added (say sd2): /sbin/scsi -f /dev/rsd2.ctl -c "12 0 0 0 v 0" 0x40 -i 64 "s8 z8 z16 z4" -- -- David (obrien@NUXI.ucdavis.edu -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 10:24:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19248 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:24:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19134; Tue, 21 Apr 1998 17:24:04 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA29727; Tue, 21 Apr 1998 11:23:45 -0600 (MDT) Message-Id: <199804211723.LAA29727@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Peter Wemm cc: "Justin T. Gibbs" , gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Tue, 21 Apr 1998 19:42:30 +0800." <199804211142.TAA19500@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 11:19:56 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >In this particular case I've been using the 545S since it panics on >startup rather than after the system is 95% of the way through booting. > >After the bad probe, it finally fails with things like: > >sd0: invalid partition table (or is that invalid partition magic?) >error 22: panic: cannot mount root (2) > >If I do a trace at that point, the nesting is so deep that it scrolls well >off the screen so I can't see the more interesting top few stack frames. Serial debugger??? You should probably trap the first completed transaction and have a look around. >Do you have a nutshell summary of what all the bus dma calls do so that I >have a better chance of finding more useful hints as to what's wrong? Here goes. DMA tags encapsulate the dma characteristics of a particular class of transfers. These include maximum size, alignment, boundary, address limits, and filter function. DMA tag attributes are inherited from parent to child and in final form the dma tag used by a driver might look like this: ISA Bus tag | Driver ISA Attach Tag | MailBox Allocation Tag In the case of the BT driver, there is no parent bus tag to inherit from yet, so a tag is created without a parent in the probe/attach routines. This tag lists all of the constraints of the device. Going one step further down, the MailBox tag, allocated in MI code, lists the MI restrictions on the DMA (for example it must be representable by a 32bit counter), but as it is related to a more restrictive tag, even if the attributes used to create this low level tag are less restrictive than a parent, the system still honors the parents restrictions. Tags are created with the bus_dma_tag_create() function. Once you have a tag, you need to allocate a mapping object for each transfer instance that will use a particular tag. If you wish to map memory that you don't own and hence cannot allocate in a special way to minimize the overhead of the mapping (e.g. the data in a buffer object), you must use the bus_dmamap_create() function. If you can allocate the space yourself, you can allocate the space and the mapping associated with it using the bus_dmamem_alloc() routine. In order to perform a bus dma transfer, you must: 1) Map the object into bus dma space using bus_dmamap_load(). This will call your callback function when a mapping is possible or call it with an error code. 2) Perform a bus_dmamap_sync operation (PREREAD, PREWRITE) to prepare that memory for the transfer. Depending on the platform, this may perform the actual bounce operation, invalidate the cache, etc. 3) Tell the hardware to perform the transfer. 4) Perform another sync operation on the map (POSTREAD, POSTWRITE). This performs the "bounce back" for bounce buffer reads. 5) Unload the mapping. It just so happens that I forgot to perform steps 4 and 5 in the BT driver. Ooops. Diff attached. >Also, what is the function of this variable? >static bus_addr_t bounce_lowaddr = BUS_SPACE_MAXADDR; >It's set to 0xffffffff. (2^32-1) but appears to be used in a role that I'd >almost expect that it was meant to be 0x00ffffff.. On the other hand, it >almost looks stale too since contigmalloc always gives a good page. See my description of DMA tags above. If the MI code does not wish to further restrict a component of the tag it is creating, it uses that of its parent by specifying the maximum possible value. >Cheers, >-Peter >-- >Peter Wemm Netplex Consulting -- Justin ==== //depot/cam/sys/dev/buslogic/bt.c#7 - /a/perforce/src/sys/dev/buslogic/bt.c ==== *** /tmp/tmp.28790.0 Tue Apr 21 11:19:15 1998 --- /a/perforce/src/sys/dev/buslogic/bt.c Tue Apr 21 11:14:32 1998 *************** *** 1358,1363 **** --- 1358,1374 ---- ccb = bccb->ccb; csio = &bccb->ccb->csio; + if ((ccb->ccb_h.flags & CAM_DIR_MASK) != CAM_DIR_NONE) { + bus_dmasync_op_t op; + + if ((ccb->ccb_h.flags & CAM_DIR_MASK) == CAM_DIR_IN) + op = BUS_DMASYNC_POSTREAD; + else + op = BUS_DMASYNC_POSTWRITE; + bus_dmamap_sync(bt->buffer_dmat, bccb->dmamap, op); + bus_dmamap_unload(bt->buffer_dmat, bccb->dmamap); + } + if (bccb == bt->recovery_bccb) { /* * The recovery BCCB does not have a CCB associated To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 10:27:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19961 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:27:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19912 for ; Tue, 21 Apr 1998 17:27:03 GMT (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id LAA23796; Tue, 21 Apr 1998 11:26:48 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199804211726.LAA23796@panzer.plutotech.com> Subject: Re: SCSI-Disk hot-swappability? In-Reply-To: <19980421100403.15807@nuxi.com> from David O'Brien at "Apr 21, 98 10:04:03 am" To: obrien@NUXI.com Date: Tue, 21 Apr 1998 11:26:48 -0600 (MDT) Cc: pantzer@ludd.luth.se, hans@artcom.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] 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 David O'Brien wrote... > > > The sd driver seems to be prepared for this, but the necessary changes to > > > scsiconf.c do not seem to be there. We'd also need a set of utilities to > > > make the kernel reprobe a given SCSI device. > > I'm not sure which of these gave me re-probability, but... > > ls /dev/*scsi* > crw------- 1 root wheel 18, 0 Nov 4 23:55 scsisuper > > In my kernel config file: > # These are only for watching for bitrot in old SCSI code. > # also need to execute: ``(umask 077; mknod /dev/scsisuper c 18 0)'' > pseudo-device su #scsi user > pseudo-device ssc #super scsi > > Then run (assuming you didn't swap out your boot drive): > /sbin/scsi -f /dev/rsd0.ctl -r > > And to test, do an inquiry of the device just added (say sd2): > /sbin/scsi -f /dev/rsd2.ctl -c "12 0 0 0 v 0" 0x40 -i 64 "s8 z8 z16 z4" For what it's worth, CAM has built-in hot swap capability. Here's how it works: - Plug a disk in your hot-swap chassis - Type 'camcontrol -r bus', where bus is the number of the SCSI bus that the disk is on. If you know the target/lun of the drive, you can do something like: 'camcontrol -r 3:1:0' to rescan bus 3, target 1. - If the disk is spun down, it will be automatically spun up by the probe code, and you'll see a probe message, like the one that comes up at boot, e.g.: da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: Serial Number PCB=2011300001 ; HDA=184704011751 da1: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) And the code works for pulling devices out as well. If you pull a drive out, turn one off, etc., and then do I/O to the device, the selection timeout will cause the device to be invalidated. You can also rescan the bus so the kernel will see that the device is gone. Once the device is finally closed, it will completely go away. For instance: I have an Exabyte Eliant on my test box. sa2 at adv1 bus 0 target 2 lun 0 sa2: Removable Sequential Access SCSI2 device sa2: Serial Number 16012000 sa2: 5.0MB/s transfers (5.0MHz, offset 15) Now, I turn it off, and try to do a mt status: {bladerunner:/usr/home/ken:20:0} mt -f /dev/nrsa2 status mt: /dev/nrsa2: Device not configured and the following message pops up on the console: (sa2:adv1:0:2:0): lost device (sa2:adv1:0:2:0): removing device entry "lost device" is printed when the kernel notices that the device is gone, either via a selection timeout, or a manual rescan. Now, I turn the drive back on, and rescan bus 2: {bladerunner:/usr/home/ken:22:0} camcontrol -r 2 Re-scan of bus 2 was successful And the following pops up on the console: sa2 at adv1 bus 0 target 2 lun 0 sa2: Removable Sequential Access SCSI2 device sa2: Serial Number 16012000 sa2: 5.0MB/s transfers (5.0MHz, offset 15) Losing devices affects all peripheral drivers attached to a particular physical device. So, when the tape drive went away, the tape driver and the passthrough driver for that drive both went away. The passthrough driver's messages are hidden behind bootverbose, so the kernel won't be excessively chatty. (otherwise, you'd get two peripheral driver probe messages for every SCSI device in the system) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 10:37:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22690 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:37:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22607 for ; Tue, 21 Apr 1998 17:36:53 GMT (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.8.7/8.6.12) id RAA21631; Tue, 21 Apr 1998 17:36:48 GMT Message-ID: <19980421103647.37532@nuxi.com> Date: Tue, 21 Apr 1998 10:36:47 -0700 From: "David O'Brien" To: "Kenneth D. Merry" Cc: pantzer@ludd.luth.se, hans@artcom.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI-Disk hot-swappability? Reply-To: obrien@NUXI.com References: <19980421100403.15807@nuxi.com> <199804211726.LAA23796@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199804211726.LAA23796@panzer.plutotech.com>; from Kenneth D. Merry on Tue, Apr 21, 1998 at 11:26:48AM -0600 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.5-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > - Plug a disk in your hot-swap chassis You mean you don't just yank the terminator off the last device and add the new one to the live scsi chain, like so many SunOS admins are accustomed to? ;-)) -- -- David (obrien@NUXI.ucdavis.edu -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 10:39:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23220 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:39:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Masters.leader-group.com (masters.leader-group.com [12.10.238.70]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23078 for ; Tue, 21 Apr 1998 17:38:36 GMT (envelope-from bmccloskey@leader-group.com) Received: from leader-group.com ([172.20.149.128]) by Masters.leader-group.com (Netscape Messaging Server 3.0) with ESMTP id AAA11111; Tue, 21 Apr 1998 11:35:23 -0600 Message-ID: <353CD8D2.F29D2111@leader-group.com> Date: Tue, 21 Apr 1998 11:35:14 -0600 From: "Brian McCloskey" Organization: Leader Group X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: Hugh LaMaster , scsi@FreeBSD.ORG Subject: Re: Adaptec 7895 On-Board SCSI Controller References: <199804201931.NAA17845@narnia.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin T. Gibbs wrote: > In article you wrote: > > > > Well, it has been a while now. Any update on the status of how > > well the 7895 code is working? Is it kind-of/sort-of safe to use > > now? Several new and possibly attractive boards are using the 7895. > > The 7895 should work just fine if you use CAM. > I don't know if I have done something wrong or not, and I will try the -a option at the boot prompt when I try it again, but I installed FreeBSD 3.0, and used the fixit floppy with the CAM files to install the new kernel. Then when I reboot, the system starts to come up, and configures all of the devices and then at the end brings up a message like "Reboot of the system in 15 seconds. Press any key to abort reboot". I can't remember the exact message, but along those lines. It's been a week since I've tried anything. But for some reason I just can't get the system to boot due to this. Does anybody have any ideas? (could be that I need the -a option at the boot prompt, but I don't know). Thanks, Brian -- _________________________________________________ Brian McCloskey | Leader Group Consultant | 5200 DTC Parkway ph: 303-773-9700 | Suite 500 fax: 303-773-9610 | Englewood, CO 80111 ____________________________|____________________ http://www.leader-group.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 10:50:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26685 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:50:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26678 for ; Tue, 21 Apr 1998 17:50:03 GMT (envelope-from dan@math.berkeley.edu) Received: from rain.berkeley.edu (rain.Berkeley.EDU [128.32.183.196]) by math.berkeley.edu (8.8.7/8.8.7) with ESMTP id KAA13838; Tue, 21 Apr 1998 10:49:52 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Received: (dan@localhost) by rain.berkeley.edu (8.8.5/8.6.4) id KAA13234; Tue, 21 Apr 1998 10:49:51 -0700 (PDT) Date: Tue, 21 Apr 1998 10:49:51 -0700 (PDT) Message-Id: <199804211749.KAA13234@rain.berkeley.edu> To: hans@artcom.de, pantzer@ludd.luth.se Subject: Re: SCSI-Disk hot-swappability? Cc: freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Why not just type this in your configfile for the kernel? > > disk sd0 at scbus0 target 0 > disk sd1 at scbus0 target 1 ... > > The sd driver seems to be prepared for this, but the necessary changes to > > scsiconf.c do not seem to be there. We'd also need a set of utilities to > > make the kernel reprobe a given SCSI device. > > The manpage for scsi tells me that it can do that. There may be a problem. I tried it once and it didn't work. This was a while back, so perhaps it is old news. I actually prefer static drive unit definitions over dynamic definitions (at least for the first few drives) because then file systems don't move around on you when a drive dies. Some additional considerations: 1) It would be nice if the SCSI disk driver would react to an attention condition on a drive by reloading the disk labels. It would be nice if this produced console/syslog messages. 2) I once turned an external drive off for a while a while because it was so terribly noisy. After I turned it back on, it was so terribly slow. Speculation: the synchronous transfer parameters were not renegotiated. 3) Since attention conditions might be missed, it would be nice if the drive was also "reinitialized" during each drive open(). Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 10:53:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA27076 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:53:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA27071 for ; Tue, 21 Apr 1998 17:53:25 GMT (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id RAA29813; Tue, 21 Apr 1998 17:53:23 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA04130; Tue, 21 Apr 1998 19:53:22 +0200 (MET DST) Message-ID: <19980421195322.01991@follo.net> Date: Tue, 21 Apr 1998 19:53:22 +0200 From: Eivind Eklund To: Brian McCloskey Cc: scsi@FreeBSD.ORG Subject: Re: Adaptec 7895 On-Board SCSI Controller References: <199804201931.NAA17845@narnia.plutotech.com> <353CD8D2.F29D2111@leader-group.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <353CD8D2.F29D2111@leader-group.com>; from Brian McCloskey on Tue, Apr 21, 1998 at 11:35:14AM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 21, 1998 at 11:35:14AM -0600, Brian McCloskey wrote: > I don't know if I have done something wrong or not, and I will try > the -a option at the boot prompt when I try it again, but I > installed FreeBSD 3.0, and used the fixit floppy with the CAM files > to install the new kernel. Then when I reboot, the system starts to > come up, and configures all of the devices and then at the end > brings up a message like "Reboot of the system in 15 seconds. Press > any key to abort reboot". I can't remember the exact message, but > along those lines. That's the _end_ of a panic message, where you're told why it panic()s. Probably a case of "can't mount root", but you'd be interested in looking at where it tries to mount root from (and which devices are up - possibly not all, even if it looks like "a lot of them"). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 11:28:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08481 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 11:28:28 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA08356 for ; Tue, 21 Apr 1998 18:28:03 GMT (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA10485; Tue, 21 Apr 1998 11:26:36 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd010483; Tue Apr 21 18:26:32 1998 Message-ID: <353CE399.398A68D@whistle.com> Date: Tue, 21 Apr 1998 11:21:13 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Dan Strick CC: hans@artcom.de, pantzer@ludd.luth.se, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI-Disk hot-swappability? References: <199804211749.KAA13234@rain.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dan Strick wrote: > > > Why not just type this in your configfile for the kernel? > > > > disk sd0 at scbus0 target 0 > > disk sd1 at scbus0 target 1 > ... > > > The sd driver seems to be prepared for this, but the necessary changes to > > > scsiconf.c do not seem to be there. We'd also need a set of utilities to > > > make the kernel reprobe a given SCSI device. > > > > The manpage for scsi tells me that it can do that. > > There may be a problem. I tried it once and it didn't work. > This was a while back, so perhaps it is old news. > > I actually prefer static drive unit definitions over dynamic > definitions (at least for the first few drives) because then file > systems don't move around on you when a drive dies. > > Some additional considerations: > > 1) It would be nice if the SCSI disk driver would react to > an attention condition on a drive by reloading the disk > labels. It would be nice if this produced console/syslog > messages. This is done by the DEVFS/SLICE code, but it's not quite correct at this time.. It doesn't know it it's the same disk or just one formatted the same so it assumes the worst and invalidates the filesystems. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 11:29:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA24100 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 10:42:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23907 for ; Tue, 21 Apr 1998 17:41:38 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA00670; Tue, 21 Apr 1998 11:41:15 -0600 (MDT) Message-Id: <199804211741.LAA00670@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: "Brian McCloskey" cc: "Justin T. Gibbs" , Hugh LaMaster , scsi@FreeBSD.ORG Subject: Re: Adaptec 7895 On-Board SCSI Controller In-reply-to: Your message of "Tue, 21 Apr 1998 11:35:14 MDT." <353CD8D2.F29D2111@leader-group.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 11:37:26 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I don't know if I have done something wrong or not, and I will try the -a >opti on at the boot prompt when I try it again, but I installed FreeBSD >3.0, and used the fix it floppy with the CAM files to install the new >kernel. Then when I reboot, the system starts to come up, and configures >all of the devices and then at the end brings up a mes sage like "Reboot of >the system in 15 seconds. Press any key to abort reboot". I can't >remember the exact message, but along those lines. It's been a week since >I've tried a nything. But for some reason I just can't get the system to >boot due to this. You probably need a new version of the mount command or boot blocks as it sounds like the system is picking the wrong root. It's hard to say without more exact boot messages. >Thanks, >Brian -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 21:08:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05847 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 21:08:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA05764; Wed, 22 Apr 1998 04:07:28 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id MAA01011; Wed, 22 Apr 1998 12:06:49 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804220406.MAA01011@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Tue, 21 Apr 1998 11:19:56 CST." <199804211723.LAA29727@pluto.plutotech.com> Date: Wed, 22 Apr 1998 12:06:48 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: [..] > 3) Tell the hardware to perform the transfer. > > 4) Perform another sync operation on the map (POSTREAD, POSTWRITE). This > performs the "bounce back" for bounce buffer reads. > > 5) Unload the mapping. > > It just so happens that I forgot to perform steps 4 and 5 in the BT driver. > Ooops. Diff attached. Ahh... Yes, this indeed does make a lot of difference. :-) It's running now "just fine" so far (touch wood) on both a BT545S and 445S (with 16MB crossover blocked). --- bt_isa.c.save Tue Apr 21 00:59:42 1998 +++ bt_isa.c Tue Apr 21 15:15:23 1998 @@ -304,6 +304,8 @@ if (addr >= bt->bios_addr && addr < (bt->bios_addr + BIOS_MAP_SIZE)) + return (1); + if (addr == 0) return (1); return (0); } Since addr at that point is masked to a 24 bit address, this is quick and convenient. It hardly seems worth testing for firmware rev 3.35 or earlier.. (although it would be relatively simple to store an extra flag in the bt_softc at probe time and simply test it here rather than a string compare for each filter call.) bt0 at 0x330 irq 11 on isa bt0: BT-445S FW Rev. 3.35 Narrow SCSI Host Adapter, SCSI ID 7, 30 CCBs [..] sa0 at bt0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI1 device sa0: 3.300MB/s transfers da1 at bt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: Serial Number 399741110024 da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da1: 2014MB (4124736 512 byte sectors: 128H 32S/T 1007C) cd0 at bt0 bus 0 target 2 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 4.32MB/s transfers (4.32MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at bt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 10.0MB/s transfers (10.0MHz, offset 8) da0: 516MB (1057758 512 byte sectors: 64H 32S/T 516C) (da1:bt0:0:1:0): tagged openings now 25 (da1:bt0:0:1:0): tagged openings now 24 (da1:bt0:0:1:0): tagged openings now 23 (da1:bt0:0:1:0): tagged openings now 22 (da1:bt0:0:1:0): tagged openings now 21 (da1:bt0:0:1:0): tagged openings now 20 (da1:bt0:0:1:0): tagged openings now 19 (da1:bt0:0:1:0): tagged openings now 18 (da1:bt0:0:1:0): tagged openings now 17 (da1:bt0:0:1:0): tagged openings now 16 (da1:bt0:0:1:0): tagged openings now 15 The system seems to feel more responsive relative to the AHA1542CF that it used to have. :-) It's only an ISA/VLB 486DX2-66 w/ 32M of ram and needed all the help it could get. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 21 21:27:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA08576 for freebsd-scsi-outgoing; Tue, 21 Apr 1998 21:27:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA08505; Wed, 22 Apr 1998 04:27:41 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id WAA29887; Tue, 21 Apr 1998 22:26:52 -0600 (MDT) Message-Id: <199804220426.WAA29887@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Peter Wemm cc: "Justin T. Gibbs" , gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) In-reply-to: Your message of "Wed, 22 Apr 1998 12:06:48 +0800." <199804220406.MAA01011@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 22:23:03 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Ahh... Yes, this indeed does make a lot of difference. :-) It's running >now "just fine" so far (touch wood) on both a BT545S and 445S (with 16MB >crossover blocked). Yeah! >--- bt_isa.c.save Tue Apr 21 00:59:42 1998 >+++ bt_isa.c Tue Apr 21 15:15:23 1998 >@@ -304,6 +304,8 @@ > > if (addr >= bt->bios_addr > && addr < (bt->bios_addr + BIOS_MAP_SIZE)) >+ return (1); >+ if (addr == 0) > return (1); > return (0); > } I have something similar committed in the CAM Perforce repository. >It hardly seems worth testing for firmware rev 3.35 or >earlier.. (although it would be relatively simple to store an extra flag >in the bt_softc at probe time and simply test it here rather than a >string compare for each filter call.) Filter functions are cheap, so if we really feel it necessary to not bounce those few extra pages, we might as well have a special filter. Of course, when compared to bouncing all pages over 16MB, the difference is so insignificant that I didn't bother when I added this change to Perforce. >da0: 10.0MB/s transfers (10.0MHz, offset 8) >da0: 516MB (1057758 512 byte sectors: 64H 32S/T 516C) >(da1:bt0:0:1:0): tagged openings now 25 >(da1:bt0:0:1:0): tagged openings now 24 >(da1:bt0:0:1:0): tagged openings now 23 >(da1:bt0:0:1:0): tagged openings now 22 >(da1:bt0:0:1:0): tagged openings now 21 >(da1:bt0:0:1:0): tagged openings now 20 >(da1:bt0:0:1:0): tagged openings now 19 >(da1:bt0:0:1:0): tagged openings now 18 >(da1:bt0:0:1:0): tagged openings now 17 >(da1:bt0:0:1:0): tagged openings now 16 >(da1:bt0:0:1:0): tagged openings now 15 This is something I didn't expect to see. The documentation I have seemed to indicated that the queue full condition was handled internally to the cards firmware so we'd never see them to know to lower the queue depth. I wonder if this is the case with newer firmware too. I certainly hope so since it will prevent us from wasting resources on devices that won't benefit. >The system seems to feel more responsive relative to the AHA1542CF that it >used to have. :-) It's only an ISA/VLB 486DX2-66 w/ 32M of ram and needed >all the help it could get. Tagged queuing makes a huge difference. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 22 04:41:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA23500 for freebsd-scsi-outgoing; Wed, 22 Apr 1998 04:41:58 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA23493 for ; Wed, 22 Apr 1998 11:41:54 GMT (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Wed, 22 Apr 1998 7:41:24 -0400 (EDT) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA28609; Wed, 22 Apr 98 07:41:24 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA23543; Wed, 22 Apr 1998 07:40:37 -0400 Message-Id: <19980422074037.A23510@ct.picker.com> Date: Wed, 22 Apr 1998 07:40:37 -0400 From: Randall Hopper To: scsi@FreeBSD.ORG Subject: uk0: extraneous data discarded ? Mail-Followup-To: scsi@freebsd.org References: <19980418131605.A3370@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19980418131605.A3370@ct.picker.com>; from Randall Hopper on Sat, Apr 18, 1998 at 01:16:05PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Trying to get my scanner (Microtek E6) working with -current and SANE. I'd appreciate any tips those with more experience could provide. The device probes up fine as uk0, Sane probes the device correctly as a Microtek ScanMaker E6, but when Sane tries to scan with it, it gives: scanimage: sane_start: Device busy and this appears in /var/log/messages: uk0: extraneous data discarded. uk0: COMMAND FAILED (9 0) @f0551000. What would be a good way to go about attacking this. I'm not a SCSI expert, but willing to probe around. Thanks, Randall Here are the particulars: dmesg: scbus0 target 6 lun 0: < Scanner 600 1.91> type 6 fixed SCSI 3 uk0 at scbus0 target 6 lun 0 uk0: Unknown setenv SANE_DEBUG_MICROTEK 100; scanimage -d microtek:/dev/scanner ... [microtek] sane_get_parameters... [microtek] sane_get_parameters: res_code = 16 (10) [microtek] sane_get_parameters: dots_per_mm: 3.937008 [microtek] sane_get_parameters: units_per_mm: 23.622047 [microtek] sane_get_parameters: lines: 0 [microtek] .wait_ready 3... [microtek] .mode_select_1 3... [microtek] .mode_sense_1... scanimage: sane_start: Device busy <----------------------- [microtek] sane_cancel...[microtek] sane_close... [microtek] sane_exit... [microtek] sane_exit: MICROTEK says goodbye. Tail of SCSIDEBUG output for "scanimage -d microtek:/dev/scanner" (enabled with "scsi -f /dev/uk0 -d 255"): /kernel: uk0(ncr0:6:0): back from sleep /kernel: uk0(ncr0:6:0): scsi_do_ioctl(0xc0605101) /kernel: uk0(ncr0:6:0): user_strategy /kernel: uk0(ncr0:6:0): scsi_cmd /kernel: uk0(ncr0:6:0): get_xs /kernel: uk0(ncr0:6:0): returning /kernel: xs(0xf06fdf00): flg(0x828)sc_link(0xf06fde80)retr(0x0)timo(0xea60)cmd(0xf06fdf58)len(0x6)data(0xf3e75f8a)len(0x24)res(0x0)err(0 x0)bp(0xf0851d00)uk0: command: 19,0,0,0,1e,0-[36 bytes] /kernel: ------------------------------ /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /kernel: 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 4f /kernel: 032: bf ef 75 a3 /kernel: ------------------------------ /kernel: uk0(ncr0:6:0): about to sleep /kernel: uk0: extraneous data discarded. <--------------------- /kernel: uk0: COMMAND FAILED (9 0) @f0551000. <--------------------- /kernel: uk0(ncr0:6:0): scsi_done /kernel: uk0: command: 19,0,0,0,1e,0-[36 bytes] /kernel: ------------------------------ /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /kernel: 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 4f /kernel: 032: bf ef 75 a3 /kernel: ------------------------------ /kernel: uk0(ncr0:6:0): calling user done() /kernel: uk0(ncr0:6:0): user-done /kernel: uk0(ncr0:6:0): timeout <--------------------- /kernel: uk0(ncr0:6:0): returned from user done() /kernel: uk0(ncr0:6:0): free_xs /kernel: uk0(ncr0:6:0): returning to adapter /kernel: uk0(ncr0:6:0): back from sleep /kernel: uk0(ncr0:6:0): ukclose: Closing device I notice that this is the the only occurance of "timeout" in the messages output. Is this significant? Regarding the "extraneous data discarded", I see in pci/ncr.c that this occurs when (cp->xerr_status == XE_EXTRA_DATA), which seems to be set in a script at the top. The comment for the set reference reads: ** The target wants to tranfer too much data ** or in the wrong direction. ** Remember that in extended error. Do I need to bump buffer sizes or timeouts somewhere? Sort of stabbing in the dark on this one, so anything you can suggest or clarify would be appreciated. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 22 10:03:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23243 for freebsd-scsi-outgoing; Wed, 22 Apr 1998 10:03:47 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23026; Wed, 22 Apr 1998 17:02:24 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id TAA26127; Wed, 22 Apr 1998 19:01:58 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id TAA00656; Wed, 22 Apr 1998 19:01:48 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804221701.TAA00656@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: gibbs@FreeBSD.ORG cc: scsi@FreeBSD.ORG Subject: Breakage seen at last! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 19:01:48 +0200 From: Mark Murray Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I came home today to find my p5/SMP/AHC/CAM box locked up solid. The only message on the screen was about a dozen Timedout SCB handled by another timeout ...and it took a hard reset to recover. 10 minutes after the reboot, and the same message appeared at +- 5 sec intervals. No other log message appeared. It took a powerdown to get the machine to boot up and stay up. Does this help debug? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 22 10:30:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA27621 for freebsd-scsi-outgoing; Wed, 22 Apr 1998 10:30:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA27577; Wed, 22 Apr 1998 17:30:37 GMT (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA01974; Wed, 22 Apr 1998 11:30:18 -0600 (MDT) Message-Id: <199804221730.LAA01974@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mark Murray cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Breakage seen at last! In-reply-to: Your message of "Wed, 22 Apr 1998 19:01:48 +0200." <199804221701.TAA00656@greenpeace.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 11:26:29 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi > >I came home today to find my p5/SMP/AHC/CAM box locked up solid. >The only message on the screen was about a dozen > >Timedout SCB handled by another timeout > >...and it took a hard reset to recover. > >10 minutes after the reboot, and the same message appeared at +- 5 sec >intervals. I really think that something in the kernel timeout facility doesn't work under SMP. You're not the first to report this bug, but it is always reported under SMP. I'll review my management of timeouts in the driver again, but I don't expect to find anything. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 22 10:44:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA29684 for freebsd-scsi-outgoing; Wed, 22 Apr 1998 10:44:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA29636; Wed, 22 Apr 1998 17:44:39 GMT (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.8/8.8.7) id TAA26818; Wed, 22 Apr 1998 19:44:16 +0200 (SAT) From: John Hay Message-Id: <199804221744.TAA26818@zibbi.mikom.csir.co.za> Subject: Re: Breakage seen at last! In-Reply-To: <199804221730.LAA01974@pluto.plutotech.com> from "Justin T. Gibbs" at "Apr 22, 98 11:26:29 am" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Wed, 22 Apr 1998 19:44:16 +0200 (SAT) Cc: mark@grondar.za, gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] 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 > >I came home today to find my p5/SMP/AHC/CAM box locked up solid. > >The only message on the screen was about a dozen > > > >Timedout SCB handled by another timeout > > > >...and it took a hard reset to recover. > > > >10 minutes after the reboot, and the same message appeared at +- 5 sec > >intervals. > > I really think that something in the kernel timeout facility doesn't work > under SMP. You're not the first to report this bug, but it is always > reported under SMP. I'll review my management of timeouts in the driver > again, but I don't expect to find anything. Not sure if it is related. I don't have a CAM system but my dual PII system is haveing problems with ntp nowadays. It seems to happen when I do a make release. ----------- Apr 15 03:56:11 beast ntpd[163]: time reset 0.662730 s Apr 16 03:57:32 beast ntpd[163]: time reset 0.505175 s Apr 17 03:53:55 beast ntpd[163]: time reset 0.565190 s Apr 18 03:52:55 beast ntpd[163]: time reset 0.361480 s Apr 19 03:52:13 beast ntpd[163]: time reset 0.446798 s Apr 22 03:50:11 beast ntpd[163]: time reset 0.582187 s ----------- On the 20 and 21 the make release failed because of some problems in the tree. What is interresting is that the times are so close to each other. Make release is started from cron. This did not happen 3 months ago. John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 22 11:37:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11520 for freebsd-scsi-outgoing; Wed, 22 Apr 1998 11:37:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Masters.leader-group.com (masters.leader-group.com [12.10.238.70]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA11487 for ; Wed, 22 Apr 1998 18:37:00 GMT (envelope-from bmccloskey@leader-group.com) Received: from leader-group.com ([172.20.149.128]) by Masters.leader-group.com (Netscape Messaging Server 3.0) with ESMTP id AAA22429; Wed, 22 Apr 1998 12:33:44 -0600 Message-ID: <353E37FD.8C081D4D@leader-group.com> Date: Wed, 22 Apr 1998 12:33:34 -0600 From: "Brian McCloskey" Organization: Leader Group X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: Eivind Eklund CC: scsi@FreeBSD.ORG Subject: Re: Adaptec 7895 On-Board SCSI Controller References: <199804201931.NAA17845@narnia.plutotech.com> <353CD8D2.F29D2111@leader-group.com> <19980421195322.01991@follo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Eivind Eklund wrote: > On Tue, Apr 21, 1998 at 11:35:14AM -0600, Brian McCloskey wrote: > > I don't know if I have done something wrong or not, and I will try > > the -a option at the boot prompt when I try it again, but I > > installed FreeBSD 3.0, and used the fixit floppy with the CAM files > > to install the new kernel. Then when I reboot, the system starts to > > come up, and configures all of the devices and then at the end > > brings up a message like "Reboot of the system in 15 seconds. Press > > any key to abort reboot". I can't remember the exact message, but > > along those lines. > > That's the _end_ of a panic message, where you're told why it > panic()s. Probably a case of "can't mount root", but you'd be > interested in looking at where it tries to mount root from (and which > devices are up - possibly not all, even if it looks like "a lot of > them"). > > Eivind. > That's very interesting, because when I was installing FreeBSD, it would newfs my /var and /usr partitions, but not my root. So then it would come back saying that it was unable to put files in /etc. I had to boot from the fixit floppy and newfs it manualy, and then create the /etc/directory before it would ever put anything on the system. Now that you are mentioning a possible wrong root, I will attempt to force a boot from the correct partition. Thanks, Brian -- _________________________________________________ Brian McCloskey | Leader Group Consultant | 5200 DTC Parkway ph: 303-773-9700 | Suite 500 fax: 303-773-9610 | Englewood, CO 80111 ____________________________|____________________ http://www.leader-group.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 23 17:03:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21485 for freebsd-scsi-outgoing; Thu, 23 Apr 1998 17:03:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from insanus.matematik.su.se (root@insanus.matematik.su.se [130.237.198.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21474 for ; Thu, 23 Apr 1998 17:03:00 -0700 (PDT) (envelope-from tege@matematik.su.se) Received: from sophie.matematik.su.se (root@sophie.matematik.su.se [130.237.198.29]) by insanus.matematik.su.se (8.8.8/8.6.9) with ESMTP id CAA17341 for ; Fri, 24 Apr 1998 02:02:56 +0200 (MET DST) X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+46 8 162000 X-Fax: int+46 8 6126717 X-Url: http://www.matematik.su.se Received: from sophie.matematik.su.se (tege@localhost [127.0.0.1]) by sophie.matematik.su.se (8.8.8/8.6.9) with ESMTP id CAA18826 for ; Fri, 24 Apr 1998 02:02:57 +0200 (MET DST) Message-Id: <199804240002.CAA18826@sophie.matematik.su.se> To: scsi@FreeBSD.ORG Subject: Adaptec 2940U2W Date: Fri, 24 Apr 1998 02:02:56 +0200 From: Torbjorn Granlund Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is Adaptec 2940U2W supported in FreeBSD 2.2.6? If not, is it possible to grab the ahc driver from current and stick it into 2.2.6? Anyone with U2W disks and an Adaptec 2940U2W? Experiences? Torbjorn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 23 17:34:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA25295 for freebsd-scsi-outgoing; Thu, 23 Apr 1998 17:34:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA25290 for ; Thu, 23 Apr 1998 17:34:39 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id SAA06840; Thu, 23 Apr 1998 18:34:29 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199804240034.SAA06840@panzer.plutotech.com> Subject: Re: Adaptec 2940U2W In-Reply-To: <199804240002.CAA18826@sophie.matematik.su.se> from Torbjorn Granlund at "Apr 24, 98 02:02:56 am" To: tege@matematik.su.se (Torbjorn Granlund) Date: Thu, 23 Apr 1998 18:34:29 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] 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 Torbjorn Granlund wrote... > Is Adaptec 2940U2W supported in FreeBSD 2.2.6? If not, is it possible to > grab the ahc driver from current and stick it into 2.2.6? It isn't supported by 2.2.6. And there isn't a driver for -current. The driver is in CAM. See: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/README or ftp://ftp.kdm.org/pub/FreeBSD/cam/README for details on what CAM is, what it does, etc. Porting CAM to the 2.2 branch is a non-trivial exercise. Justin is planning on porting CAM to 2.2-stable, so if you can, I'd suggest waiting on that. If you can't wait, and if you can afford to run -current, you can try the CAM patches on top of current. > Anyone with U2W disks and an Adaptec 2940U2W? Experiences? I haven't heard of anyone who has hooked Ultra 2 LVD disks to a 7890-based controller under CAM yet. You could be the first. :) (Justin has a 2940U2W, which he used to write the driver, but he doesn't have any Ultra 2 disks.) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 23 18:18:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29838 for freebsd-scsi-outgoing; Thu, 23 Apr 1998 18:18:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29811 for ; Thu, 23 Apr 1998 18:17:44 -0700 (PDT) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.8/8.8.5) with SMTP id UAA00373 for ; Thu, 23 Apr 1998 20:16:45 -0400 (EDT) Date: Thu, 23 Apr 1998 20:16:44 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@localhost To: scsi@FreeBSD.ORG Subject: CAM drivers 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 hope this is the right place to post about the cam stuff ... Anyhow, I just went ahead and applied the CAM patches, and booted a CAM kernel. No explosions yet, but some observations here. Like, the instructions to install cam didn't include changing the fstab stuff to use the new sdn disk devices instead of the new dan devices, so I figured that was the reason that the bootup messsages said sd0, sd1, etc. After that, I changed my fstab to use the new devices, rebooted, and whala!, it *still* used the sdn names in boot. Uhh, ok, when getting ready to post this message, I checked my dmesg, where the mountable filesystem stuff showed up as dan, the swap spaces as sdn, and I'm pretty sure there were *no* dan messages in the actual onscreen boot messages. The messages for the swap partitions used the old sdn names both in the dmesg and the onscreen message. Like I said, this was from a fstab that had been edited to use the new dan names only. I occurs to me, since all the discussions of a complete cutover fromt eh old drivers to the new, that I can't understand why there needs to be any new name for the disks at all ... can't the sdn names just be reused, if the new and old stuff is never going to coexist? One last point ... the initial boot prompt still talked about wd0 or sd0. Make world ain't going to change that one .... so folks better get ready for a lot of confused newbie questions, from folks wondering why they have to specify a non-existent disk device. Overall, ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 23 21:35:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA19486 for freebsd-scsi-outgoing; Thu, 23 Apr 1998 21:35:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA19481 for ; Thu, 23 Apr 1998 21:35:17 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id WAA28199; Thu, 23 Apr 1998 22:31:16 -0600 (MDT) Date: Thu, 23 Apr 1998 22:31:16 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804240431.WAA28199@narnia.plutotech.com> To: Chuck Robey cc: scsi@FreeBSD.ORG Subject: Re: CAM drivers Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > I hope this is the right place to post about the cam stuff ... > > Anyhow, I just went ahead and applied the CAM patches, and booted a CAM > kernel. No explosions yet, but some observations here. Like, the > instructions to install cam didn't include changing the fstab stuff to > use the new sdn disk devices instead of the new dan devices, so I > figured that was the reason that the bootup messsages said sd0, sd1, > etc. The major and minor numbers for the da device match those of the sd device. The reason the boot messages occassionally specify "sd" rather than "da" is because of a bunch of tables scattered about in places like the boot code and various bits of the kernel that have this string hard coded. I think I fixed most of these just after the last snapshot was cut, but in the end, all of these tables will have to die when DEVFS comes on the scene. You won't be able to do a simple lookup from major number to device name. > After that, I changed my fstab to use the new devices, rebooted, > and whala!, it *still* used the sdn names in boot. Uhh, ok, when > getting ready to post this message, I checked my dmesg, where the > mountable filesystem stuff showed up as dan, the swap spaces as sdn, and > I'm pretty sure there were *no* dan messages in the actual onscreen boot > messages. You must have gotten something like this, or you wouldn't have booted at all: da0 at ahc0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number 003075630T1G56 da0: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da0: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C) > It occurs to me, since all the discussions of a complete cutover fromt eh > old drivers to the new, that I can't understand why there needs to be > any new name for the disks at all ... can't the sdn names just be > reused, if the new and old stuff is never going to coexist? The new name was chosen, not because it wouldn't conflict with the old name, but because the old name wasn't appropriate. The da driver deals with "direct access devices". In the future, those direct access devices may be attached via ATAPI, not SCSI, and even today, there are several devices that respond to this protocol, but are not disks at all. > One last point ... the initial boot prompt still talked about wd0 or > sd0. Make world ain't going to change that one .... so folks better get > ready for a lot of confused newbie questions, from folks wondering why > they have to specify a non-existent disk device. And the same will be true for booting off of a mylex raid adapter or an IDE cdrom, etc, etc. You can fix this with a make world and installing new boot blocks so that the "da" name shows up if it really bothers you. We should probably ask for the BIOS drive to boot from instead of attempting to map names onto them, but it is rather hard to determine the mapping from BIOS drive to FreeBSD device once you're in the kernel. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 23 23:05:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA28769 for freebsd-scsi-outgoing; Thu, 23 Apr 1998 23:05:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from friley63.res.iastate.edu (friley63.res.iastate.edu [129.186.189.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA28762 for ; Thu, 23 Apr 1998 23:05:25 -0700 (PDT) (envelope-from mystify@friley63.res.iastate.edu) Received: from friley63.res.iastate.edu (loopback [127.0.0.1]) by friley63.res.iastate.edu (8.8.8/8.8.5) with ESMTP id BAA02352 for ; Fri, 24 Apr 1998 01:05:23 -0500 (CDT) Message-Id: <199804240605.BAA02352@friley63.res.iastate.edu> Reply-To: mystify@iastate.edu To: scsi@FreeBSD.ORG Subject: CAM == CAM Ate my Machine (and severly corrupted file systems too) Date: Fri, 24 Apr 1998 01:05:23 -0500 From: Patrick Hartling Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The intention of this message is to warn people of the possibilty of serious disk corruption when using CAM + SMP + ccd. Other factors could be involved, but I've never had anything like this happen to me before in 2 years of running FreeBSD. This morning when I got back from class, I discovered that my machine had apparently gotten hungry and had eaten itself. It had been very stable for 10 days running an SMP kernel with the CAM patches (built April 13, 1998), but then this happened. Unfortunately, I don't know what caused this, but it certainly caused me a lot of stress this morning. My current disk configuration is three UW SCSI disks (two Quantum Viking's and one WD Enterprise) with one Viking and the Enterprise on a BusLogic BT-958 and the other Viking on the onboard Adaptec 2940UW. I have a mirrored ccd across the two Viking disks. Besides that, I'd say that everything concerning partitions/slices is fairly typical. (I also have a Jaz disk and a CD-ROM drive plugged into the BusLogic controller.) At any rate, my /var was completely trashed. fsck core dumped on it repeatedly. /usr was pretty well hosed too. Lots of files (mostly shared libraries) were removed by fsck. This was easy to replace since my /usr/src and /usr/obj partitions were fully intact. 'make install' saved the day here--once I got ld.so and libc.so.3.1 restored. However, the real horror story was the complete loss of my home directory. BUT I have /home on the mirrored ccd, and the second partition in the ccd was fully intact by some miracle. :) The first partition was thoroughly trashed. Everything that was in my base directory ended up in lost+found, so I could have gotten it back if I had spent the time to go through each file and directory and rename everything. Once I found that the second partition was fine, I tried to do: dd if=/dev/rda2s1e of=/dev/rda1s1e bs=64k but it kept saying that rda1s1e was a read-only filesystem. I could be wrong, but that seems kind of odd. This was after going through the appropriate steps to split the mirrored ccd up so that I could get to each partition individually. Using the block device worked fine, and I was able to get the whole ccd back in operation. Since getting everything more or less back to normal, I have crashed my machine again today by accidentally doing: disklabel -r sd4c I'm still not fully used to the da stuff, but now that I have discovered mixing it up can be fatal to stability, I'll remember to be more careful. :) So, unless someone can tell me what mistakes I've made to cause all this, I would recommend that people be extra careful with using the current CAM code (even though I'm really impressed with it overall). Personally, I'm feeling pretty edgy now, but I'll keep on using it and be sure to make frequent backups of important data. -Patrick Patrick L. Hartling | Research Assistant, ICEMT mystify@friley63.res.iastate.edu | SE Lab - 1117 Black Engineering http://www.public.iastate.edu/~oz | http://www.icemt.iastate.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 10:59:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14788 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 10:59:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14780 for ; Fri, 24 Apr 1998 10:59:30 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA02289; Fri, 24 Apr 1998 11:59:27 -0600 (MDT) Message-Id: <199804241759.LAA02289@pluto.plutotech.com> To: Patrick Hartling cc: scsi@FreeBSD.ORG Subject: RE: CAM == CAM Ate my Machine (and severly corrupted file systems too) Date: Fri, 24 Apr 1998 11:55:39 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The intention of this message is to warn people of the possibilty of serious >disk corruption when using CAM + SMP + ccd. Other factors could be involved, >but I've never had anything like this happen to me before in 2 years of >running FreeBSD. It is likely CAM + BT-958... >This morning when I got back from class, I discovered that my machine had >apparently gotten hungry and had eaten itself. It had been very stable for >10 days running an SMP kernel with the CAM patches (built April 13, 1998), >but then this happened. Unfortunately, I don't know what caused this, but >it certainly caused me a lot of stress this morning. Was it wedged or did it panic or was it running normally and when you attempted some operation failed? >My current disk configuration is three UW SCSI disks (two Quantum Viking's >and one WD Enterprise) with one Viking and the Enterprise on a BusLogic >BT-958 and the other Viking on the onboard Adaptec 2940UW. I have a >mirrored ccd across the two Viking disks. Besides that, I'd say that >everything concerning partitions/slices is fairly typical. (I also have a >Jaz disk and a CD-ROM drive plugged into the BusLogic controller.) > >At any rate, my /var was completely trashed. Which disk and controller contains /var. Is it part of your CCD array? >fsck core dumped on it repeatedly. /usr was pretty well hosed too. >Lots of files (mostly shared libraries) were removed by fsck. This was >easy to replace since my /usr/src and /usr/obj partitions were fully intact. >'make install' saved the day here--once I got ld.so and libc.so.3.1 restored. Please be more specific about where these file systems were located. I need to know if the problem resides in the BT driver or somewhere else. >However, the real horror story was the complete loss of my home directory. >BUT I have /home on the mirrored ccd, and the second partition in the ccd was >fully intact by some miracle. :) It was probably on the Adaptec controller - the most well tested of the controller drivers for CAM. >The first partition was thoroughly >trashed. Everything that was in my base directory ended up in lost+found, so >I could have gotten it back if I had spent the time to go through each file >and directory and rename everything. Once I found that the second partition >was fine, I tried to do: > > dd if=/dev/rda2s1e of=/dev/rda1s1e bs=64k > >but it kept saying that rda1s1e was a read-only filesystem. My guess is that this error is coming from dsopen(), but I don't know why. I can't see how this could be a CAM problem. >Since getting everything more or less back to normal, I have crashed my >machine again today by accidentally doing: > > disklabel -r sd4c This should not be able to crash your system. Disklabel should simply open up the device by that name in /dev and, should it exist, it will take it directly to the da driver. My guess is that there was still some latent corruption in '/' that caused a panic. When you are recovering your system or leaving it unattended, please leave the console switched to VTY0 so that console messages can be captured should an error occur. Unless you have a serial console, you will never be able to get to the useful information for fixing problems like this if you are in X. >I'm still not fully used to the da stuff, but now that I have discovered >mixing it up can be fatal to stability, I'll remember to be more careful. :) It shouldn't make a difference. I've booted several times on systems where all /dev entries were called "sdblah". >So, unless someone can tell me what mistakes I've made to cause all this, I >would recommend that people be extra careful with using the current CAM code >(even though I'm really impressed with it overall). A few words about your BT-958. Ensure that you are running good firmware on your card. Leonard Zubkoff has a great page that talks about BT firmware issues with links to known good firmware: http://www.dandelion.com/Linux/BusLogic.html You are also the first person to report using the BT-958 with this driver. There are bound to be "some" problems with it as the driver was written from the ground up and was only tested by my on an older BT-948. Can you send me the dmesg output from your system? Was there any noticeable change performance wise in the system after switching to CAM? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 12:02:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02465 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 12:02:01 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA02419; Fri, 24 Apr 1998 12:01:56 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id PAA27498; Fri, 24 Apr 1998 15:02:01 -0400 (EDT) Date: Fri, 24 Apr 1998 15:02:00 -0400 (EDT) From: The Hermit Hacker To: freebsd-stable@FreeBSD.ORG cc: freebsd-scsi@FreeBSD.ORG Subject: Odd SCSI problem in 2.2-STABLE... 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 Hi... On one of our 2.2-STABLE servers, we get this message if we try to do a 'reboot' on the machine: ahc0 rev 1 int a irq 11 on pci0:11 ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs ahc0: board is not responding (ahc0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x162 SCSISEQ = 0x12 SSTAT0 = 0x4 SSTAT1 = 0x0 (ahc0:0:0): Queueing an Abort SCB ahc0: board is not responding cmd fail (ahc0:0:0): SCB 0x1 timedout while recovery in progress (ahc0:0:0): "unknown unknown ????" type 13 fixed SCSI 0 uk0(ahc0:0:0): Unknown ahc0: board is not responding (ahc0:0:1): SCB 0x2 timedout while recovery in progress We have to physically shut everything down and then turn it all back on again in order to get it to work... Has anyone seen this before? Any way to fix it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 12:11:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04893 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 12:11:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from friley63.res.iastate.edu (friley63.res.iastate.edu [129.186.189.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04842 for ; Fri, 24 Apr 1998 12:11:09 -0700 (PDT) (envelope-from mystify@friley63.res.iastate.edu) Received: from friley63.res.iastate.edu (loopback [127.0.0.1]) by friley63.res.iastate.edu (8.8.8/8.8.5) with ESMTP id OAA04442; Fri, 24 Apr 1998 14:11:00 -0500 (CDT) Message-Id: <199804241911.OAA04442@friley63.res.iastate.edu> To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: Re: CAM == CAM Ate my Machine (and severly corrupted file systems too) In-reply-to: Message from "Justin T. Gibbs" of "Fri, 24 Apr 1998 11:55:39 MDT." <199804241759.LAA02289@pluto.plutotech.com> Date: Fri, 24 Apr 1998 14:11:00 -0500 From: Patrick Hartling Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: } >The intention of this message is to warn people of the possibilty of serious } >disk corruption when using CAM + SMP + ccd. } } It is likely CAM + BT-958... Yes, I'm now quite certain you are correct. I should have been a little more clear in my previous message about which partitions are on which disks and which controllers. Every partition that ended up being corrupted (i.e., /var, /usr and /home) are on the Viking disk that is part of the BT-958 bus. } >This morning when I got back from class, I discovered that my machine had } >apparently gotten hungry and had eaten itself. It had been very stable for } >10 days running an SMP kernel with the CAM patches (built April 13, 1998), } >but then this happened. Unfortunately, I don't know what caused this, but } >it certainly caused me a lot of stress this morning. } } Was it wedged or did it panic or was it running normally and when you } attempted some operation failed? When I got back, it was waiting for me to provide a path to root's shell. fsck could not find the super block for the /var partition. I assume what happened was that the machine panic'd and rebooted while I was gone. I don't know how long it had been in that state, but my roommate informed me that he had heard the disks grinding just a few minutes before I got back. } Which disk and controller contains /var. Is it part of your CCD array? It is not part of the CCD array. } >However, the real horror story was the complete loss of my home directory. } >BUT I have /home on the mirrored ccd, and the second partition in the ccd wa *** s } >fully intact by some miracle. :) } } It was probably on the Adaptec controller - the most well tested of the } controller drivers for CAM. Thankfully! :) If it weren't for that, I'd be one unhappy camper right now. } >Once I found that the second partition } >was fine, I tried to do: } > } > dd if=/dev/rda2s1e of=/dev/rda1s1e bs=64k } > } >but it kept saying that rda1s1e was a read-only filesystem. } } My guess is that this error is coming from dsopen(), but I don't know why. } I can't see how this could be a CAM problem. I don't either. I just noted it because it seemed weird. } >Since getting everything more or less back to normal, I have crashed my } >machine again today by accidentally doing: } > } > disklabel -r sd4c } } This should not be able to crash your system. Disklabel should simply open } up the device by that name in /dev and, should it exist, it will take } it directly to the da driver. My guess is that there was still some latent } corruption in '/' that caused a panic. That's possible. My root partition is on the WD disk that's also part of the BT-958 bus. I hadn't considered that possibility, but I was certainly taken aback when it did cause a crash. } When you are recovering your } system or leaving it unattended, please leave the console switched to } VTY0 so that console messages can be captured should an error occur. } Unless you have a serial console, you will never be able to get to the } useful information for fixing problems like this if you are in X. I will do that in the future. I did the above command remotely just to verify that I had screwed up a disklabel a while ago (which I had) and not as root. } A few words about your BT-958. Ensure that you are running good firmware on } your card. Leonard Zubkoff has a great page that talks about BT firmware } issues with links to known good firmware: } } http://www.dandelion.com/Linux/BusLogic.html I will definitely look into this ASAP. Thank you for the info. } You are also the first person to report using the BT-958 with this driver. } There are bound to be "some" problems with it as the driver was written } from the ground up and was only tested by my on an older BT-948. Can you } send me the dmesg output from your system? Was there any noticeable change } performance wise in the system after switching to CAM? I haven't had a chance to run any kind of benchmarks with CAM vs the old SCSI system. I'll have to do that as soon as I get time because I think it would very interesting to see what kind of performance I'm getting now. I'm happy to report that things do "feel" faster though--especially with Jaz disks. Here's the dmesg output: d: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec00000 Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 fxp0: rev 0x01 int a irq 18 on pci0.6.0 fxp0: Ethernet address 00:a0:c9:14:0d:5f chip1: rev 0x01 on pci0.7.0 chip2: rev 0x01 int d irq 11 on pci0.7.2 ahc0: rev 0x00 int a irq 17 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs bt0: rev 0x08 int a irq 16 on pci0.11.0 bt0: BT-958 FW Rev. 5.05R Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs vga0: rev 0x01 int a irq 17 on pci0.15.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> pcm0 at 0x530 irq 5 drq 1 flags 0xa610 on isa mss_attach 0 at 0x530 irq 5 dma 1:0 flags 0xa610 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: model MouseMan+, device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface APIC_IO: routing 8254 via 8259 on pin 0 ccd0-3: Concatenated disk drivers SMP: AP CPU #1 Launched! bt0: bt_cmd: Timeout waiting for adapter ready, status = 0x0 bt0: btfetchtransinfo - Inquire Setup Info Failed (probe19:bt0:0:4:0): MODE SENSE(06). CDB: 1a 0 a 0 14 0 (probe19:bt0:0:4:0): ILLEGAL REQUEST asc:24,0 (probe19:bt0:0:4:0): Invalid field in CDB da2 at ahc0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI2 device da2: Serial Number 174721630980 da2: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4345MB (8899737 512 byte sectors: 255H 63S/T 553C) da1 at bt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: Serial Number 174721632608 da1: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da1: 4345MB (8899737 512 byte sectors: 255H 63S/T 553C) (da4:bt0:0:4:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da4:bt0:0:4:0): NOT READY asc:3a,0 (da4:bt0:0:4:0): Medium not present da4 at bt0 bus 0 target 4 lun 0 da4: Removable Direct Access SCSI2 device da4: 10.0MB/s transfers (10.0MHz, offset 15) da4: Attempt to query device size, failed cd0 at bt0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: Serial Number \^_ cd0: 10.0MB/s transfers (10.0MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at bt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number WS7000054039 da0: 3.300MB/s transfers , Tagged Queueing Enabled da0: 2077MB (4254819 512 byte sectors: 255H 63S/T 264C) ccd0: mirror/parity forces uniform flag -Patrick Patrick L. Hartling | Research Assistant, ICEMT mystify@friley63.res.iastate.edu | SE Lab - 1117 Black Engineering http://www.public.iastate.edu/~oz | http://www.icemt.iastate.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 12:42:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12143 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 12:42:12 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12006 for ; Fri, 24 Apr 1998 12:41:50 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id NAA07182; Fri, 24 Apr 1998 13:41:44 -0600 (MDT) Message-Id: <199804241941.NAA07182@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Patrick Hartling cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: CAM == CAM Ate my Machine (and severly corrupted file systems too) In-reply-to: Your message of "Fri, 24 Apr 1998 14:11:00 CDT." <199804241911.OAA04442@friley63.res.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Apr 1998 13:37:55 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >} Was it wedged or did it panic or was it running normally and when you >} attempted some operation failed? > >When I got back, it was waiting for me to provide a path to root's shell. To trap this kind of condition again, can you compile your kernel with "option DDB"? This will cause a panic condition to break into the debugger, effectively freezing the panic message and perhaps some useful messages on the screen. >Here's the dmesg output: ... >bt0: bt_cmd: Timeout waiting for adapter ready, status = 0x0 >bt0: btfetchtransinfo - Inquire Setup Info Failed I'm surprised by this. We wait a full second for the adapter to come ready. There is a lot of traffic going on when we do the probe, but still, a second is a long time. As this command failed, the negotiated transfer characteristics for da0 were not reported. Can you try upping the maximum timeout in the bt driver for the adapter to come ready? In sys/dev/buslogice/bt.c:bt_cmd() ~line 1655 in my copy, you should see this: /* * Wait up to 1 sec. for the adapter to become * ready to accept commands. */ timeout = 10000; while (--timeout) { status = bt_inb(bt, STATUS_REG); if ((status & HA_READY) != 0 && (status & CMD_REG_BUSY) == 0) break; DELAY(100); } Change "timeout = 10000" to something like "timeout = 20000". >(probe19:bt0:0:4:0): MODE SENSE(06). CDB: 1a 0 a 0 14 0 >(probe19:bt0:0:4:0): ILLEGAL REQUEST asc:24,0 >(probe19:bt0:0:4:0): Invalid field in CDB This is non-fatal too. Your Jaz doesn't support the control mode page. I'll quite the error messages. >(da4:bt0:0:4:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >(da4:bt0:0:4:0): NOT READY asc:3a,0 >(da4:bt0:0:4:0): Medium not present I thought we already had made this one silent. Hmm. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 13:06:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16721 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 13:06:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16669 for ; Fri, 24 Apr 1998 13:06:10 -0700 (PDT) (envelope-from mdtancsa@sentex.net) Received: (from mdtancsa@localhost) by granite.sentex.net (8.8.6/8.6.9) id QAA12398; Fri, 24 Apr 1998 16:04:00 -0400 (EDT) From: Mike D Tancsa Message-Id: <199804242004.QAA12398@granite.sentex.net> Subject: Re: Odd SCSI problem in 2.2-STABLE... In-Reply-To: from The Hermit Hacker at "Apr 24, 98 03:02:00 pm" To: scrappy@hub.org (The Hermit Hacker) Date: Fri, 24 Apr 1998 16:04:00 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] 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 > > Hi... > > On one of our 2.2-STABLE servers, we get this message if we try to > do a 'reboot' on the machine: On some OLD 2940 cards, we had to turn on Plug and Play SCAM in the card's BIOS... Thats the only thing that leaps to mind. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 13:19:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20601 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 13:19:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20584 for ; Fri, 24 Apr 1998 13:19:40 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id QAA06971; Fri, 24 Apr 1998 16:18:06 -0400 (EDT) Date: Fri, 24 Apr 1998 16:18:05 -0400 (EDT) From: The Hermit Hacker To: Mike D Tancsa cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Odd SCSI problem in 2.2-STABLE... In-Reply-To: <199804242004.QAA12398@granite.sentex.net> 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, 24 Apr 1998, Mike D Tancsa wrote: > > > > Hi... > > > > On one of our 2.2-STABLE servers, we get this message if we try to > > do a 'reboot' on the machine: > > On some OLD 2940 cards, we had to turn on Plug and Play SCAM in the card's > BIOS... Thats the only thing that leaps to mind. Can't hurt to try...I've forwarded it onto the "person on site" :) BTW...I'm just about to (like, this weekend) build a new system, and am planning on putting 3.0SNAP onto it, mainly because I want the CAM drivers that currrently aren't availalbe for 2.2-STABLE...does anyone know of any problems with this plan? Will the current CAM drivers work in 3.0SNAP? Thanks... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 14:00:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29236 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 14:00:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA29124 for ; Fri, 24 Apr 1998 13:59:50 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id WAA28021; Fri, 24 Apr 1998 22:58:58 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id WAA13608; Fri, 24 Apr 1998 22:58:57 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804242058.WAA13608@greenpeace.grondar.za> To: The Hermit Hacker cc: Mike D Tancsa , freebsd-scsi@FreeBSD.ORG Subject: Re: Odd SCSI problem in 2.2-STABLE... Date: Fri, 24 Apr 1998 22:58:50 +0200 From: Mark Murray Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Hermit Hacker wrote: > BTW...I'm just about to (like, this weekend) build a new system, > and am planning on putting 3.0SNAP onto it, mainly because I want the CAM > drivers that currrently aren't availalbe for 2.2-STABLE...does anyone know > of any problems with this plan? Will the current CAM drivers work in > 3.0SNAP? Very well! :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 15:26:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14942 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 15:26:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from friley63.res.iastate.edu (friley63.res.iastate.edu [129.186.189.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14937 for ; Fri, 24 Apr 1998 15:26:33 -0700 (PDT) (envelope-from mystify@friley63.res.iastate.edu) Received: from friley63.res.iastate.edu (loopback [127.0.0.1]) by friley63.res.iastate.edu (8.8.8/8.8.5) with ESMTP id RAA00523; Fri, 24 Apr 1998 17:26:30 -0500 (CDT) Message-Id: <199804242226.RAA00523@friley63.res.iastate.edu> To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: Re: CAM == CAM Ate my Machine (and severly corrupted file systems too) In-reply-to: Message from "Justin T. Gibbs" of "Fri, 24 Apr 1998 13:37:55 MDT." <199804241941.NAA07182@pluto.plutotech.com> Date: Fri, 24 Apr 1998 17:26:30 -0500 From: Patrick Hartling Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: } To trap this kind of condition again, can you compile your kernel with } "option DDB"? This will cause a panic condition to break into the } debugger, effectively freezing the panic message and perhaps some useful } messages on the screen. Done. } >Here's the dmesg output: } } ... } } >bt0: bt_cmd: Timeout waiting for adapter ready, status = 0x0 } >bt0: btfetchtransinfo - Inquire Setup Info Failed } } I'm surprised by this. We wait a full second for the adapter to } come ready. There is a lot of traffic going on when we do the probe, } but still, a second is a long time. As this command failed, the } negotiated transfer characteristics for da0 were not reported. } Can you try upping the maximum timeout in the bt driver for the adapter } to come ready? I bumped it up to 20000 and got the same message. It's currently at 40000 and still giving the same output. :\ Is there something else I could try? -Patrick Patrick L. Hartling | Research Assistant, ICEMT mystify@friley63.res.iastate.edu | SE Lab - 1117 Black Engineering http://www.public.iastate.edu/~oz | http://www.icemt.iastate.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 19:21:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22751 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 19:21:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22736 for ; Fri, 24 Apr 1998 19:21:36 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt3-146.HiWAAY.net [208.147.146.146]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id VAA17720 for ; Fri, 24 Apr 1998 21:21:27 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id VAA27227 for ; Fri, 24 Apr 1998 21:21:25 -0500 (CDT) Message-Id: <199804250221.VAA27227@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG Subject: does CAM do this? From: David Kelly Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Apr 1998 21:21:25 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I deal with a lot of tapes generated on SGI Irix systems, meaning "users who don't pay much attention to what they are doing." So 4mm tapes are usually blocked at 256k and 8mm's are 128k. I've never been able to detect a performance increase and if there is an advantage in getting more data on tape I've not noticed either. Then again I don't bump against the end of tape very often on purpose. The FreeBSD 2.2.6 scsi system doesn't permit blocks larger than 64k. Or have I missed an enhancement? Today I noticed a new message: st0: 262144-byte record too big At least I think its new, but it accurately describes why I couldn't read the tape. Does CAM provide for blocks larger than 64k? If not, could CAM provide for blocks larger than 64k? What are the hardware limitations? I don't think the Adaptec 7880 family is inherently limited to 64k blocks else SGI did something special in the O2 to get around it. How about the Symbios '875? Other things I'd really like to see is the ability to easily determine the tape block size of a tape. I know it can vary on tape, but the size of the first block under the head, or last block is good enough. SGI uses "mt blocksize" to read and set it. And while we're at it would an indication if the tape is compressed. I could probably add some of these things. I have Seagate's DAT manual and have been crawling thru tcopy experimenting with methods of querying the DAT drive for error and retry statistics. We tcopy lots of tapes at work. Used 7,000 8mm tapes last year. Mostly with Solaris. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 20:29:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28592 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 20:29:01 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28585 for ; Fri, 24 Apr 1998 20:28:58 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-118.HiWAAY.net [208.147.148.118]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id WAA03322 for ; Fri, 24 Apr 1998 22:28:55 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id WAA27641 for ; Fri, 24 Apr 1998 22:05:36 -0500 (CDT) Message-Id: <199804250305.WAA27641@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: Odd SCSI problem in 2.2-STABLE... In-reply-to: Message from Mike D Tancsa of "Fri, 24 Apr 1998 16:04:00 EDT." <199804242004.QAA12398@granite.sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Apr 1998 22:05:36 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike D Tancsa writes: > > > > Hi... > > > > On one of our 2.2-STABLE servers, we get this message if we try to > > do a 'reboot' on the machine: > > On some OLD 2940 cards, we had to turn on Plug and Play SCAM in the card's > BIOS... Thats the only thing that leaps to mind. Ditto. My Really Old 2940's (purchased with 1.10 BIOS, fast not ultra) don't have this problem. Don't remember if the now-upgraded 1.16 BIOS even has SCAM. Chip is the aic7870. On newer cards with the aic7860 chip and 1.21 BIOS FreeBSD 2.2 would not reboot. It would cold boot into FreeBSD, just not a reboot. Adaptec's BIOS message would appear claiming to be scanning the SCSI bus. And hang. Dumb old Win95 didn't have that problem. Neither did some version of OS/2. Enabling SCAM cured the problem for FreeBSD. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 21:27:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03301 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 21:27:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03293 for ; Fri, 24 Apr 1998 21:27:19 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA11033; Fri, 24 Apr 1998 21:20:44 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd011031; Sat Apr 25 04:20:41 1998 Message-ID: <35416355.41C67EA6@whistle.com> Date: Fri, 24 Apr 1998 21:15:17 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: David Kelly CC: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? References: <199804250221.VAA27227@nospam.hiwaay.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Kelly wrote: > st0: 262144-byte record too big > > At least I think its new, but it accurately describes why I couldn't > read the tape. Does CAM provide for blocks larger than 64k? If not, > could CAM provide for blocks larger than 64k? > It shouldn't be a new message, however that message came from the DRIVE I think.. some adapters have a limit the 1542 for example cannot DMA more than 64K there was a VM limit of 64K at one time.. I'm not sure if it's been changed.. if so, then you may have hit a new limit with the drive.. (not a definative answer though, I haven't looked at those files for a few years.) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 22:00:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA07190 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 22:00:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (root@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07184 for ; Fri, 24 Apr 1998 22:00:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id VAA27050; Fri, 24 Apr 1998 21:59:37 -0700 Message-ID: <35416DB8.2A27EDEF@feral.com> Date: Fri, 24 Apr 1998 21:59:36 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: David Kelly CC: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? References: <199804250221.VAA27227@nospam.hiwaay.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I believe that the 'record too big' message means that you've got the tape drive in fixed block mode and you attempted to read a record too big for it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 22:58:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12796 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 22:58:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12791 for ; Fri, 24 Apr 1998 22:58:56 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id XAA03963; Fri, 24 Apr 1998 23:55:06 -0600 (MDT) Date: Fri, 24 Apr 1998 23:55:06 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804250555.XAA03963@narnia.plutotech.com> To: David Kelly cc: scsi@FreeBSD.ORG Subject: Re: Odd SCSI problem in 2.2-STABLE... Newsgroups: pluto.freebsd.scsi In-Reply-To: <199804250305.WAA27641@nospam.hiwaay.net> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199804250305.WAA27641@nospam.hiwaay.net> you wrote: > > On newer cards with the aic7860 chip and 1.21 BIOS FreeBSD 2.2 would not > reboot. It would cold boot into FreeBSD, just not a reboot. Adaptec's > BIOS message would appear claiming to be scanning the SCSI bus. And > hang. Dumb old Win95 didn't have that problem. Neither did some version > of OS/2. Enabling SCAM cured the problem for FreeBSD. This problem doesn't exist in the CAM version of the driver. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 23:10:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13854 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 23:10:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13849 for ; Fri, 24 Apr 1998 23:10:51 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id AAA03997; Sat, 25 Apr 1998 00:07:00 -0600 (MDT) Date: Sat, 25 Apr 1998 00:07:00 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804250607.AAA03997@narnia.plutotech.com> To: David Kelly cc: scsi@FreeBSD.ORG Subject: Re: does CAM do this? Newsgroups: pluto.freebsd.scsi In-Reply-To: <199804250221.VAA27227@nospam.hiwaay.net> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199804250221.VAA27227@nospam.hiwaay.net> you wrote: > I deal with a lot of tapes generated on SGI Irix systems, meaning > "users who don't pay much attention to what they are doing." So 4mm > tapes are usually blocked at 256k and 8mm's are 128k. I've never been > able to detect a performance increase and if there is an advantage in > getting more data on tape I've not noticed either. Then again I don't > bump against the end of tape very often on purpose. > > The FreeBSD 2.2.6 scsi system doesn't permit blocks larger than 64k. Or > have I missed an enhancement? Today I noticed a new message: > > st0: 262144-byte record too big > > At least I think its new, but it accurately describes why I couldn't > read the tape. Does CAM provide for blocks larger than 64k? If not, > could CAM provide for blocks larger than 64k? There are two issues here. 1) MAX_BSIZE is 64k. This is the largest a buffer can be in the FreeBSD kernel unless you take advantage of some "modifications" John Dyson did that can allow larger buffers to be constructed. We really need to swith to a "buffer chaining" scheme (which appears to be the solution BSDI chose) to allow larger transactions. 2) Some adapters can only handle a few S/G segments at a time. The 1542 for example can only handle 16, which means the largest, page aligned, transfer possible, assuming all pages are discontiguous, is 64k. The aic7xxx cards have a limit of 255 S/G elements, but the driver currently allocates only 32 to save on space. After all, problem number 1 limits us to 64k anyway. To solve this problem, the bus dma implementation needs to be enhanced to perform smart page coalesing so that the transfer will fit in the S/G space supported by the target controller. I haven't come up with, or found an algorithm I like for doing this, so I haven't implemented it. These problems can be solved, but some discussion about the best approaches to solve them is required. > Other things I'd really like to see is the ability to easily determine > the tape block size of a tape. I know it can vary on tape, but the size > of the first block under the head, or last block is good enough. SGI > uses "mt blocksize" to read and set it. And while we're at it would an > indication if the tape is compressed. I could probably add some of > these things. I have Seagate's DAT manual and have been crawling thru > tcopy experimenting with methods of querying the DAT drive for error > and retry statistics. I'm more than willing to review diffs. 8-) We have an O2 at work, so I can probably sniff how their mt blocksize works for the drives we have here, but I don't believe that a single strategy will work for all drives. I'll have to look at the spec again when I have some time. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 24 23:54:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA16739 for freebsd-scsi-outgoing; Fri, 24 Apr 1998 23:54:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA16734 for ; Fri, 24 Apr 1998 23:54:07 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id BAA07149; Sat, 25 Apr 1998 01:53:28 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199804250653.BAA07149@dyson.iquest.net> Subject: Re: does CAM do this? In-Reply-To: <199804250607.AAA03997@narnia.plutotech.com> from "Justin T. Gibbs" at "Apr 25, 98 00:07:00 am" To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Sat, 25 Apr 1998 01:53:28 -0500 (EST) Cc: dkelly@HiWAAY.net, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] 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 > > There are two issues here. > > 1) MAX_BSIZE is 64k. This is the largest a buffer can be in the > FreeBSD kernel unless you take advantage of some "modifications" > John Dyson did that can allow larger buffers to be constructed. > We really need to swith to a "buffer chaining" scheme (which > appears to be the solution BSDI chose) to allow larger transactions. > The modifications are in the code, and only require that they be enabled. I agree that a buffer chaining scheme is probably more desirable, but right now, in -current, IDE transfers are no longer limited to 64K. The variable is MAXPHYS, and is currently 128K. I would not suggest growing the maximum transfer size to much greater than this without Justin's change though. There is NO additional kernel cost for the SCSI code to support 128K transfer sizes as of today (actually a few months ago.) I don't mind if the current scheme is changed, as long as someone else does it :-). (We don't do the bogus buffer pagemove thing like the original code does, trying to use buffer cache buffers for clustering. We use a scheme, where we have physio buffers that can be any size of KVA, currently fixed due to lazyness to 128K (MAXPHYS). Physio buffers are used for all raw-type (and clustered ) disk I/O.) John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 09:49:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15443 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 09:49:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pcpsj.pfcs.com (qr4xb3AOa6bMgPRDMLau4M3T2NL/8UUj@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15436 for ; Sat, 25 Apr 1998 09:49:41 -0700 (PDT) (envelope-from Harlan.Stenn@pfcs.com) Received: from mumps.pfcs.com [192.52.69.11] (HELO mumps.pfcs.com) by pcpsj.pfcs.com (8.8.8/8.8.8) via ESMTP id ; Sat, 25 Apr 1998 12:49:26 -0400 (EDT) Received: from brown.pfcs.com [192.52.69.44] (HELO brown.pfcs.com) by mumps.pfcs.com (8.8.8/8.8.8) via ESMTP id ; Sat, 25 Apr 1998 09:49:24 -0700 (PDT) Received: from localhost [127.0.0.1] (HELO brown.pfcs.com) by brown.pfcs.com (8.8.8/8.8.8) via ESMTP id ; Sat, 25 Apr 1998 12:49:24 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: David Kelly cc: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? In-Reply-To: David Kelly's (dkelly@HiWAAY.net) message dated Fri, 24 Apr 1998 21:21:25. <199804250221.VAA27227@nospam.hiwaay.net> X-Face: "csXK}xnnsH\h_ce`T#|pM]tG,6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n:c(Cc* $cbtusxDP6T)Hr'k&zrwq0.3&~bAI~YJco[r.mE+K|(q]F=ZNXug:s6tyOk{VTqARy0#axm6BWti9C d Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 12:49:23 -0400 Message-ID: <23416.893522963@brown.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have some (old) code that does tape reading/writing/duplication/ conversion. I haven't been able to use it fully under FreeBSD because for some of these operations I need to *know* (determine) the actual size of the tape blocks, and I haven't figured out how to do this yet. This software can handle arbitrary blocksizes on the tape. I don't *know* how often this really happened, but I know it used to work (for example, I have boot tapes where the first file was in 512-byte blocks, and subsequent files were 262144-byte blocks (or something)). H PS - In case anybody remembers it, I'm talking about the Ansitar package. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 10:09:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17783 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 10:09:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA17774 for ; Sat, 25 Apr 1998 10:09:12 -0700 (PDT) (envelope-from jmz@cabri.obs-besancon.fr) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA09064; Sat, 25 Apr 98 19:12:12 +0200 Date: Sat, 25 Apr 98 19:12:12 +0200 Message-Id: <9804251712.AA09064@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: scsi@FreeBSD.ORG Subject: Data corruption X-Mailer: Emacs Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A strange thing happens on one of my drives. Reading _some_ files never returns the same data, without any error. Here is an exemple: $ ll atlas.ahearn atlas.kurucz -r-------- 1 jmz wheel 3804000 Apr 16 03:48 atlas.ahearn -r-------- 1 jmz wheel 5228000 Apr 16 03:48 atlas.kurucz $ while :; do md5 atlas.ahearn atlas.kurucz; sleep 4; done MD5 (atlas.ahearn) = 4c35d917b173b3040805144f0e3f7f94 MD5 (atlas.kurucz) = 1cb9eb595c876c352233c1aa3d9dc46d MD5 (atlas.ahearn) = 882b0cb1865917317b52844de41fd6d7 MD5 (atlas.kurucz) = 1cb9eb595c876c352233c1aa3d9dc46d MD5 (atlas.ahearn) = 3f46b493fc442cc23efd944637650f01 MD5 (atlas.kurucz) = 1cb9eb595c876c352233c1aa3d9dc46d MD5 (atlas.ahearn) = 62dd2898bee4af947423750991e61b9a MD5 (atlas.kurucz) = 1cb9eb595c876c352233c1aa3d9dc46d MD5 (atlas.ahearn) = e2f09103e47441db67b28bee6ca91b6a MD5 (atlas.kurucz) = 1cb9eb595c876c352233c1aa3d9dc46d Most of the files on the drive can be reliably used, this problem only occurs on a small subset of the files. Is there anything I can do to find what/where is the problem? Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 10:53:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23204 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 10:53:41 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA23182 for ; Sat, 25 Apr 1998 10:53:37 -0700 (PDT) (envelope-from Tor.Egge@idi.ntnu.no) Received: from idi.ntnu.no (tegge@presis.idi.ntnu.no [129.241.111.173]) by pat.idi.ntnu.no (8.8.8/8.8.8) with ESMTP id TAA15326; Sat, 25 Apr 1998 19:53:20 +0200 (MET DST) Message-Id: <199804251753.TAA15326@pat.idi.ntnu.no> To: jmz@cabri.obs-besancon.fr Cc: scsi@FreeBSD.ORG Subject: Re: Data corruption In-Reply-To: Your message of "Sat, 25 Apr 98 19:12:12 +0200" References: <9804251712.AA09064@cabri.obs-besancon.fr> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 25 Apr 1998 19:53:20 +0200 From: Tor Egge Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > A strange thing happens on one of my drives. Reading _some_ files > never returns the same data, without any error. Here is an exemple: Probably bugs in the scsi disk firmware I cannot reliable read files from any of my disks unless I slow down the read operation (dd if=file bs=32). 4GB Seagate Barracuds disks (ST15150N-0017) also have similar problems if the DISC bit is cleared in the caching mode page. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 11:25:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25938 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 11:25:26 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA25930 for ; Sat, 25 Apr 1998 11:25:22 -0700 (PDT) (envelope-from jmz@cabri.obs-besancon.fr) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA09431; Sat, 25 Apr 98 20:28:17 +0200 Date: Sat, 25 Apr 98 20:28:17 +0200 Message-Id: <9804251828.AA09431@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: Tor.Egge@idi.ntnu.no Cc: scsi@FreeBSD.ORG In-Reply-To: <199804251753.TAA15326@pat.idi.ntnu.no> (message from Tor Egge on Sat, 25 Apr 1998 19:53:20 +0200) Subject: Re: Data corruption X-Mailer: Emacs Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> Tor Egge writes: >> A strange thing happens on one of my drives. Reading _some_ files >> never returns the same data, without any error. Here is an exemple: > Probably bugs in the scsi disk firmware But this disk has been running for years (at least 4y). If think I would have noticed this before. > I cannot reliable read files from any of my > disks unless I slow down the read > operation (dd if=file bs=32). mine is :-) Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 12:52:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07598 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 12:52:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07582 for ; Sat, 25 Apr 1998 12:52:09 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id PAA09723; Sat, 25 Apr 1998 15:51:51 -0400 (EDT) Message-Id: <199804251951.PAA09723@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Harlan Stenn cc: David Kelly , freebsd-scsi@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: does CAM do this? References: <23416.893522963@brown.pfcs.com> In-reply-to: Your message of "Sat, 25 Apr 1998 12:49:23 EDT." <23416.893522963@brown.pfcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 15:51:50 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Perhaps I've come in the middle here, but typically you simply issue a read(2) system call with as large a block size as you're willing or able to accomodate. The byte count returned is the size of the tape block which was actually read. This sort of scheme works even if every block within a tape file is a different block size. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 13:00:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08452 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 13:00:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08446 for ; Sat, 25 Apr 1998 13:00:56 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id NAA28239; Sat, 25 Apr 1998 13:00:11 -0700 Date: Sat, 25 Apr 1998 13:00:11 -0700 From: Matthew Jacob Message-Id: <199804252000.NAA28239@feral.com> To: Harlan.Stenn@pfcs.com, louie@TransSys.COM Subject: Re: does CAM do this? Cc: dkelly@HiWAAY.net, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From owner-freebsd-scsi@FreeBSD.ORG Sat Apr 25 12:56:26 1998 > > >Perhaps I've come in the middle here, but typically you simply issue >a read(2) system call with as large a block size as you're willing or >able to accomodate. The byte count returned is the size of the tape >block which was actually read. This sort of scheme works even if every >block within a tape file is a different block size. If, and only if, the tape is in variable block mode. If it's in fixed block mode, and the tape driver hasn't set SILI (Suppress Incorrect Length Indicator) you get an error if the requested byte count doesn't match the tape block size. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 13:22:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10968 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 13:22:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from thelab.hub.org (tc-28.acadiau.ca [131.162.2.128]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10960 for ; Sat, 25 Apr 1998 13:22:49 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.8.8/8.8.2) with SMTP id RAA08540; Sat, 25 Apr 1998 17:22:36 -0300 (ADT) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sat, 25 Apr 1998 17:22:35 -0300 (ADT) From: The Hermit Hacker To: "Justin T. Gibbs" cc: David Kelly , scsi@FreeBSD.ORG Subject: Re: Odd SCSI problem in 2.2-STABLE... In-Reply-To: <199804250555.XAA03963@narnia.plutotech.com> 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, 24 Apr 1998, Justin T. Gibbs wrote: > In article <199804250305.WAA27641@nospam.hiwaay.net> you wrote: > > > > On newer cards with the aic7860 chip and 1.21 BIOS FreeBSD 2.2 would not > > reboot. It would cold boot into FreeBSD, just not a reboot. Adaptec's > > BIOS message would appear claiming to be scanning the SCSI bus. And > > hang. Dumb old Win95 didn't have that problem. Neither did some version > > of OS/2. Enabling SCAM cured the problem for FreeBSD. > > This problem doesn't exist in the CAM version of the driver. Which isn't available for 2.2-STABLE yet...is it? :( Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 13:32:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11591 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 13:32:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11585 for ; Sat, 25 Apr 1998 13:32:11 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id OAA09334; Sat, 25 Apr 1998 14:28:21 -0600 (MDT) Date: Sat, 25 Apr 1998 14:28:21 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804252028.OAA09334@narnia.plutotech.com> To: Matthew Jacob cc: scsi@FreeBSD.ORG Subject: Re: does CAM do this? Newsgroups: pluto.freebsd.scsi In-Reply-To: <199804252000.NAA28239@feral.com> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199804252000.NAA28239@feral.com> you wrote: > If, and only if, the tape is in variable block mode. If it's > in fixed block mode, and the tape driver hasn't set SILI (Suppress > Incorrect Length Indicator) you get an error if the requested > byte count doesn't match the tape block size. xxxxxxxxxxxxx is not a multiple of -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 13:33:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11853 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 13:33:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11832 for ; Sat, 25 Apr 1998 13:33:26 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id NAA28308; Sat, 25 Apr 1998 13:32:57 -0700 Date: Sat, 25 Apr 1998 13:32:57 -0700 From: Matthew Jacob Message-Id: <199804252032.NAA28308@feral.com> To: gibbs@narnia.plutotech.com, mjacob@feral.com Subject: Re: does CAM do this? Cc: scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > xxxxxxxxxxxxx > is not a multiple of picky picky picky... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 13:38:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13150 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 13:38:11 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pcpsj.pfcs.com (C5v2SV9aBQBe1ftGuJZY5IausuvmlqM1@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13141 for ; Sat, 25 Apr 1998 13:38:08 -0700 (PDT) (envelope-from Harlan.Stenn@pfcs.com) Received: from mumps.pfcs.com [192.52.69.11] (HELO mumps.pfcs.com) by pcpsj.pfcs.com (8.8.8/8.8.8) via ESMTP id ; Sat, 25 Apr 1998 16:37:52 -0400 (EDT) Received: from brown.pfcs.com [192.52.69.44] (HELO brown.pfcs.com) by mumps.pfcs.com (8.8.8/8.8.8) via ESMTP id ; Sat, 25 Apr 1998 13:37:51 -0700 (PDT) Received: from localhost [127.0.0.1] (HELO brown.pfcs.com) by brown.pfcs.com (8.8.8/8.8.8) via ESMTP id ; Sat, 25 Apr 1998 16:37:50 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: "Louis A. Mamakos" , freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? In-Reply-To: "Louis A. Mamakos"'s (louie@TransSys.COM) message dated Sat, 25 Apr 1998 15:51:50. <199804251951.PAA09723@whizzo.TransSys.COM> X-Face: "csXK}xnnsH\h_ce`T#|pM]tG,6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n:c(Cc* $cbtusxDP6T)Hr'k&zrwq0.3&~bAI~YJco[r.mE+K|(q]F=ZNXug:s6tyOk{VTqARy0#axm6BWti9C d Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 16:37:50 -0400 Message-ID: <23743.893536670@brown.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Perhaps I've come in the middle here, but typically you simply issue > a read(2) system call with as large a block size as you're willing or > able to accomodate. The byte count returned is the size of the tape > block which was actually read. This sort of scheme works even if every > block within a tape file is a different block size. That works for reading a tape, but not for copying or writing tapes. Sometimes, the tape *must* be written with particular blocksizes for bootloaders or foreign systems. H To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 14:35:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21530 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 14:35:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pcpsj.pfcs.com (FDYreb5VXJmssb9fI2RVedH26Si+mY1t@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21502 for ; Sat, 25 Apr 1998 14:35:05 -0700 (PDT) (envelope-from Harlan.Stenn@pfcs.com) Received: from mumps.pfcs.com [192.52.69.11] (HELO mumps.pfcs.com) by pcpsj.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 17:34:51 -0400 (EDT) Received: from brown.pfcs.com [192.52.69.44] (HELO brown.pfcs.com) by mumps.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 14:34:50 -0700 (PDT) Received: from localhost [127.0.0.1] (HELO brown.pfcs.com) by brown.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 17:34:49 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? In-Reply-To: Harlan Stenn's (Harlan.Stenn@pfcs.com) message dated Sat, 25 Apr 1998 16:37:50. <23743.893536670@brown.pfcs.com> X-Face: "csXK}xnnsH\h_ce`T#|pM]tG,6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n:c(Cc* $cbtusxDP6T)Hr'k&zrwq0.3&~bAI~YJco[r.mE+K|(q]F=ZNXug:s6tyOk{VTqARy0#axm6BWti9C d Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 17:34:49 -0400 Message-ID: <23840.893540089@brown.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was *still* unclear. The issues is not "reading data off a tape". The question is: What is the blocksize of the current tape record? H To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 14:45:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22464 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 14:45:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22459 for ; Sat, 25 Apr 1998 14:45:12 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id OAA28439; Sat, 25 Apr 1998 14:44:47 -0700 Date: Sat, 25 Apr 1998 14:44:47 -0700 From: Matthew Jacob Message-Id: <199804252144.OAA28439@feral.com> To: freebsd-scsi@FreeBSD.ORG, Harlan.Stenn@pfcs.com Subject: Re: does CAM do this? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What is the blocksize of the current tape record? Unless you're tape drive is clairvoyant, you can't know that until you read the record (or attempt to). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 15:02:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25583 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 15:02:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25565 for ; Sat, 25 Apr 1998 15:02:50 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id SAA00591; Sat, 25 Apr 1998 18:02:41 -0400 (EDT) Message-Id: <199804252202.SAA00591@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Matthew Jacob cc: Harlan.Stenn@pfcs.com, dkelly@HiWAAY.net, freebsd-scsi@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: does CAM do this? References: <199804252000.NAA28239@feral.com> In-reply-to: Your message of "Sat, 25 Apr 1998 13:00:11 PDT." <199804252000.NAA28239@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 18:02:41 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If, and only if, the tape is in variable block mode. If it's > in fixed block mode, and the tape driver hasn't set SILI (Suppress > Incorrect Length Indicator) you get an error if the requested > byte count doesn't match the tape block size. Well, sure, but if you don't know what the blocksize is, why would you be using fixed block mode? My impression is that fixed block mode is usually used for devices in which the blocksize is, well, fixed. That is, either the media or drive mechanism don't support arbitrary or variable record sizes. I understand that some QIC tape systems are like this. Other media, such as 9 track tapes, or Exabyte 8mm or DAT 4mm media give you variable sized records. From my personal experience, DAT drives also support fixed block mode, but I'm not really sure why you would use it unless it's a compatiblity hack for software which might presume a (e.g., QIC) fixed blocksize media. In reality, the low-level format on the tape consists of a set of fixed length physical helical swipes, with a directory which points to the location of the logical tape records written to the drive. This is the reason why there's not a significant difference in performance or capacity between writing 512 byte blocks or 20480 byte blocks; the difference is only in the pointers to the logical records recorded on the tape. So, if you have the possibility of variable sized blocks on the tape media, why would use fixed block mode in accessing the drive? louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 15:04:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25963 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 15:04:47 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25915 for ; Sat, 25 Apr 1998 15:04:44 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id PAA28488; Sat, 25 Apr 1998 15:04:09 -0700 Date: Sat, 25 Apr 1998 15:04:09 -0700 From: Matthew Jacob Message-Id: <199804252204.PAA28488@feral.com> To: louie@TransSys.COM, mjacob@feral.com Subject: Re: does CAM do this? Cc: dkelly@HiWAAY.net, freebsd-scsi@FreeBSD.ORG, Harlan.Stenn@pfcs.com Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From louie@whizzo.TransSys.COM Sat Apr 25 15:02:44 1998 >> If, and only if, the tape is in variable block mode. If it's >> in fixed block mode, and the tape driver hasn't set SILI (Suppress >> Incorrect Length Indicator) you get an error if the requested >> byte count doesn't match the tape block size. > >Well, sure, but if you don't know what the blocksize is, why would you >be using fixed block mode? My impression is that fixed block mode is >usually used for devices in which the blocksize is, well, fixed. That is, >either the media or drive mechanism don't support arbitrary or variable >record sizes. I understand that some QIC tape systems are like this. > >Other media, such as 9 track tapes, or Exabyte 8mm or DAT 4mm media >give you variable sized records. From my personal experience, DAT >drives also support fixed block mode, but I'm not really sure why you >would use it unless it's a compatiblity hack for software which might >presume a (e.g., QIC) fixed blocksize media. > >In reality, the low-level format on the tape consists of a set of fixed length >physical helical swipes, with a directory which points to the location of >the logical tape records written to the drive. This is the reason why >there's not a significant difference in performance or capacity between >writing 512 byte blocks or 20480 byte blocks; the difference is only >in the pointers to the logical records recorded on the tape. > >So, if you have the possibility of variable sized blocks on the tape >media, why would use fixed block mode in accessing the drive? Some drives- including Exabytes- can come up in fixed block mode as the default. It's a property of the drive, not the tape. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 15:07:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26786 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 15:07:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26772 for ; Sat, 25 Apr 1998 15:07:45 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id SAA00632; Sat, 25 Apr 1998 18:07:40 -0400 (EDT) Message-Id: <199804252207.SAA00632@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Harlan Stenn cc: freebsd-scsi@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: does CAM do this? References: <23743.893536670@brown.pfcs.com> In-reply-to: Your message of "Sat, 25 Apr 1998 16:37:50 EDT." <23743.893536670@brown.pfcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 18:07:39 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Perhaps I've come in the middle here, but typically you simply issue > > a read(2) system call with as large a block size as you're willing or > > able to accomodate. The byte count returned is the size of the tape > > block which was actually read. This sort of scheme works even if every > > block within a tape file is a different block size. > > That works for reading a tape, but not for copying or writing tapes. > > Sometimes, the tape *must* be written with particular blocksizes for > bootloaders or foreign systems. > Clearly, you only write a block the same size as you read it: int len; char buffer[MAX_BLOCKSIZE_YOU_EXPECT_OR_OS_OR_HARDWARE_CAN_USE]; do { len = read(goes_in_a, buffer, sizeof(buffer)); if (len < 0) { perror("input error"); exit(-1); } if (len == 0) { /* eof */ break; } if (write(goes_out_a, buffer, len) != len) { perror("output error"); exit(-1); } } while (len); If the whole tape handling model has changed significantly from how the computing world has been dealing with them for 20 years, then there may be something else terribly wrong. The SLI big existing in mainframe channel programs long before there was an 8086, and was just just for this reason. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 15:11:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27786 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 15:11:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27726 for ; Sat, 25 Apr 1998 15:10:58 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id SAA00662; Sat, 25 Apr 1998 18:10:54 -0400 (EDT) Message-Id: <199804252210.SAA00662@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Matthew Jacob cc: dkelly@HiWAAY.net, freebsd-scsi@FreeBSD.ORG, Harlan.Stenn@pfcs.com From: "Louis A. Mamakos" Subject: Re: does CAM do this? References: <199804252204.PAA28488@feral.com> In-reply-to: Your message of "Sat, 25 Apr 1998 15:04:09 PDT." <199804252204.PAA28488@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 18:10:53 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Some drives- including Exabytes- can come up in fixed block mode > as the default. It's a property of the drive, not the tape. Er, so you (or more likely the tape driver) puts it into variable length block mode? If it hurts the other way, don't do it that way? louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 15:13:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA28560 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 15:13:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA28529 for ; Sat, 25 Apr 1998 15:13:40 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id PAA28546; Sat, 25 Apr 1998 15:13:09 -0700 Date: Sat, 25 Apr 1998 15:13:09 -0700 From: Matthew Jacob Message-Id: <199804252213.PAA28546@feral.com> To: louie@TransSys.COM, mjacob@feral.com Subject: Re: does CAM do this? Cc: dkelly@HiWAAY.net, freebsd-scsi@FreeBSD.ORG, Harlan.Stenn@pfcs.com Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Some drives- including Exabytes- can come up in fixed block mode >> as the default. It's a property of the drive, not the tape. > >Er, so you (or more likely the tape driver) puts it into variable length block >mode? If it hurts the other way, don't do it that way? Yes. And hunt around for f/w to try and flash into the device or do a mode select with "SAVE PARAMETERS" to force it the way you like. See the mfg's manual. Good luck. Come back with your P cable in hand or around your neck. Don't leave it on the battlefield.....urp... I should really take the weekend off.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 15:24:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01814 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 15:24:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01792 for ; Sat, 25 Apr 1998 15:24:25 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id SAA00716; Sat, 25 Apr 1998 18:24:19 -0400 (EDT) Message-Id: <199804252224.SAA00716@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Matthew Jacob cc: dkelly@HiWAAY.net, freebsd-scsi@FreeBSD.ORG, Harlan.Stenn@pfcs.com From: "Louis A. Mamakos" Subject: Re: does CAM do this? References: <199804252213.PAA28546@feral.com> In-reply-to: Your message of "Sat, 25 Apr 1998 15:13:09 PDT." <199804252213.PAA28546@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 18:24:18 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Yes. And hunt around for f/w to try and flash into the device > or do a mode select with "SAVE PARAMETERS" to force it the > way you like. See the mfg's manual. Good luck. Come back > with your P cable in hand or around your neck. Don't leave > it on the battlefield.....urp... I should really take the > weekend off.. I'm pretty sure that the mt(1) command can do this for you. If not, then a few line C program to do the ioctl() to the st driver. In fact, I believe you can set the default mode on one of the st minor devices that all tape sessions inherit from. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 17:53:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18255 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 17:53:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pcpsj.pfcs.com (tIb+JPOlyI+m/PU271dwUF/903x1qzhH@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18250 for ; Sat, 25 Apr 1998 17:53:28 -0700 (PDT) (envelope-from Harlan.Stenn@pfcs.com) Received: from mumps.pfcs.com [192.52.69.11] (HELO mumps.pfcs.com) by pcpsj.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 20:53:25 -0400 (EDT) Received: from brown.pfcs.com [192.52.69.44] (HELO brown.pfcs.com) by mumps.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 17:41:47 -0700 (PDT) Received: from localhost [127.0.0.1] (HELO brown.pfcs.com) by brown.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 20:41:46 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? In-Reply-To: Matthew Jacob's (mjacob@feral.com) message dated Sat, 25 Apr 1998 14:44:47. <199804252144.OAA28439@feral.com> X-Face: "csXK}xnnsH\h_ce`T#|pM]tG,6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n:c(Cc* $cbtusxDP6T)Hr'k&zrwq0.3&~bAI~YJco[r.mE+K|(q]F=ZNXug:s6tyOk{VTqARy0#axm6BWti9C d Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 20:41:46 -0400 Message-ID: <24055.893551306@brown.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > What is the blocksize of the current tape record? > > Unless you're tape drive is clairvoyant, you can't know that > until you read the record (or attempt to). The problem is that a read() to the (default) tape drive under FreeBSD returns exactly the number of bytes you asked for, so there is no way to determine the actual number of bytes on the tape record. I just don't know enough about this stuff to understand why it worked on so many platforms for so many years. I just know it worked. H To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 18:15:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19645 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 18:15:01 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19631 for ; Sat, 25 Apr 1998 18:14:55 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id VAA01065; Sat, 25 Apr 1998 21:14:33 -0400 (EDT) Message-Id: <199804260114.VAA01065@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Harlan Stenn cc: freebsd-scsi@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: does CAM do this? References: <24055.893551306@brown.pfcs.com> In-reply-to: Your message of "Sat, 25 Apr 1998 20:41:46 EDT." <24055.893551306@brown.pfcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 21:14:32 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > What is the blocksize of the current tape record? > > > > Unless you're tape drive is clairvoyant, you can't know that > > until you read the record (or attempt to). > > The problem is that a read() to the (default) tape drive under FreeBSD > returns exactly the number of bytes you asked for, so there is no way to > determine the actual number of bytes on the tape record. No, it returns no more than you asked for. That why you should do a read() of a record larger than you expect or can support, and it will return the number written in the tape record. > I just don't know enough about this stuff to understand why it worked on so > many platforms for so many years. I just know it worked. This is how it worked.. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 18:34:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA21350 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 18:34:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pcpsj.pfcs.com (ZTx6BVs6AOPMHMLb6cWi8bi1ebBy7sbm@harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA21319 for ; Sat, 25 Apr 1998 18:33:57 -0700 (PDT) (envelope-from Harlan.Stenn@pfcs.com) Received: from mumps.pfcs.com [192.52.69.11] (HELO mumps.pfcs.com) by pcpsj.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 21:33:02 -0400 (EDT) Received: from brown.pfcs.com [192.52.69.44] (HELO brown.pfcs.com) by mumps.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 18:33:01 -0700 (PDT) Received: from localhost [127.0.0.1] (HELO brown.pfcs.com) by brown.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Sat, 25 Apr 1998 21:33:01 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? In-Reply-To: "Louis A. Mamakos"'s (louie@TransSys.COM) message dated Sat, 25 Apr 1998 21:14:32. <199804260114.VAA01065@whizzo.TransSys.COM> X-Face: "csXK}xnnsH\h_ce`T#|pM]tG,6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n:c(Cc* $cbtusxDP6T)Hr'k&zrwq0.3&~bAI~YJco[r.mE+K|(q]F=ZNXug:s6tyOk{VTqARy0#axm6BWti9C d Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 21:33:00 -0400 Message-ID: <15923.893554380@brown.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > What is the blocksize of the current tape record? > > > > > > Unless you're tape drive is clairvoyant, you can't know that > > > until you read the record (or attempt to). > > > > The problem is that a read() to the (default) tape drive under FreeBSD > > returns exactly the number of bytes you asked for, so there is no way to > > determine the actual number of bytes on the tape record. > > No, it returns no more than you asked for. That why you should do a > read() of a record larger than you expect or can support, and it will > return the number written in the tape record. I beg to differ. I agree that the read will return no more than I ask for. However... With the default tape drive configuration (on the drives I've tested), if I have a Large file on the tape blocked at, say, 10k bytes, if I issue a read of "more than 10k but less than the size of the file" I'll get back exactly what I asked for. I cannot tell that the tape was blocked at 10k bytes. H To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:16:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10485 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:16:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA10450 for ; Sat, 25 Apr 1998 21:16:09 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-88.HiWAAY.net [208.147.148.88]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id XAA22258 for ; Sat, 25 Apr 1998 23:16:07 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id SAA03691 for ; Sat, 25 Apr 1998 18:29:23 -0500 (CDT) Message-Id: <199804252329.SAA03691@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: does CAM do this? In-reply-to: Message from Harlan Stenn of "Sat, 25 Apr 1998 16:37:50 EDT." <23743.893536670@brown.pfcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 18:29:23 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Harlan Stenn writes: > > Sometimes, the tape *must* be written with particular blocksizes for > bootloaders or foreign systems. Or if the tape was written from Fortran. :-( Its not uncommon for the first block to be 80 bytes. After that there is usually a pattern of 2 to 5 blocks all of different sizes (1k to 5k), until the pattern repeats. Then some systems slap (3) EOF's on the tape before writing the next tape file. On Solaris systems one has to specify the "Berkeley" option (ie: /dev/rmt/0b) on the tape device to cause these EOF's to be rolled into a single EOF. So far nobody has complained about the tapes we copy for them only having one EOF between tape files. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:16:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10486 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:16:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA10467 for ; Sat, 25 Apr 1998 21:16:10 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-88.HiWAAY.net [208.147.148.88]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id XAA02498 for ; Sat, 25 Apr 1998 23:16:03 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id SAA03718 for ; Sat, 25 Apr 1998 18:46:09 -0500 (CDT) Message-Id: <199804252346.SAA03718@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: does CAM do this? In-reply-to: Message from Matthew Jacob of "Sat, 25 Apr 1998 14:44:47 PDT." <199804252144.OAA28439@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 18:46:09 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > > What is the blocksize of the current tape record? > > Unless you're tape drive is clairvoyant, you can't know that > until you read the record (or attempt to). And that's apparently what the SGI Irix "mt blksize" command does. Additionally it reports the min and max blocksize supported, and the "recommended" blocksize SGI's utilities will use unless instructed otherwise, or they inherit a blocksize from the device. Yes, I've seen a number of tar tapes with 512 byte blocks (they didn't know), and have one source that likes to write 1M blocksize (he thought it would be faster and save space on the tape). Unless I've messed up here, my "ARCHIVE Python 28388-XXX 4.CM" will read a compressed tape with no way of me knowing that it is doing so. While an enhanced "mt status" could query many tape drives and report on current tape position, it would be very nice if there was a way to report if the tape was written using a hardware compression method. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:16:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10571 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:16:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA10543 for ; Sat, 25 Apr 1998 21:16:17 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-88.HiWAAY.net [208.147.148.88]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id XAA32249; Sat, 25 Apr 1998 23:16:10 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id SAA03617; Sat, 25 Apr 1998 18:07:15 -0500 (CDT) Message-Id: <199804252307.SAA03617@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: The Hermit Hacker cc: "Justin T. Gibbs" , David Kelly , scsi@FreeBSD.ORG From: David Kelly Subject: Re: Odd SCSI problem in 2.2-STABLE... In-reply-to: Message from The Hermit Hacker of "Sat, 25 Apr 1998 17:22:35 -0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 18:07:15 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Hermit Hacker writes: > On Fri, 24 Apr 1998, Justin T. Gibbs wrote: > > > In article <199804250305.WAA27641@nospam.hiwaay.net> you wrote: > > > > > > On newer cards with the aic7860 chip and 1.21 BIOS FreeBSD 2.2 would not > > > reboot. It would cold boot into FreeBSD, just not a reboot. Adaptec's > > > BIOS message would appear claiming to be scanning the SCSI bus. And > > > hang. Dumb old Win95 didn't have that problem. Neither did some version > > > of OS/2. Enabling SCAM cured the problem for FreeBSD. > > > > This problem doesn't exist in the CAM version of the driver. > > Which isn't available for 2.2-STABLE yet...is it? :( Something I was imcomplete in describing my problem which was solved by enabling SCAM was that on exit FreeBSD left the 2940 in some state which the 2940 couldn't recover itself from unless SCAM was enabled. IMHO its more of a bug/problem in the Adaptec BIOS code than in FreeBSD. The more I read about CAM the more I suspect I'm going to have to switch to -current for my home playbox. And learn how to extract stable versions of -current using CVS. As it stands, "cd /usr; cvs -q checkout -r RELENG_2_2 src" and "cd /usr/src; cvs -q update -d" are about the extent of my cvs abilities. Just learned to add "-d" to update last week as it wasn't adding newly added directories to my source tree. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:19:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA11242 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:19:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA11227 for ; Sat, 25 Apr 1998 21:19:40 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id WAA19221; Sat, 25 Apr 1998 22:19:35 -0600 (MDT) Message-Id: <199804260419.WAA19221@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: David Kelly cc: The Hermit Hacker , "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: Odd SCSI problem in 2.2-STABLE... In-reply-to: Your message of "Sat, 25 Apr 1998 18:07:15 CDT." <199804252307.SAA03617@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 22:15:47 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Something I was imcomplete in describing my problem which was solved by >enabling SCAM was that on exit FreeBSD left the 2940 in some state which >the 2940 couldn't recover itself from unless SCAM was enabled. IMHO its >more of a bug/problem in the Adaptec BIOS code than in FreeBSD. Yes, I know. I was able to work around the problem by re-initializing the controller's state to something that wouldn't confuse the BIOS at system shutdown. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:25:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA11914 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:25:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA11909 for ; Sat, 25 Apr 1998 21:25:43 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id VAA29111; Sat, 25 Apr 1998 21:25:18 -0700 Date: Sat, 25 Apr 1998 21:25:18 -0700 From: Matthew Jacob Message-Id: <199804260425.VAA29111@feral.com> To: dkelly@hiwaay.net, freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From owner-freebsd-scsi@freebsd.org Sat Apr 25 21:19:26 1998 >Sender: owner-freebsd-scsi@freebsd.org >X-Loop: FreeBSD.org > >Matthew Jacob writes: >> > What is the blocksize of the current tape record? >> >> Unless you're tape drive is clairvoyant, you can't know that >> until you read the record (or attempt to). > >And that's apparently what the SGI Irix "mt blksize" command does. >Additionally it reports the min and max blocksize supported, and the >"recommended" blocksize SGI's utilities will use unless instructed >otherwise, or they inherit a blocksize from the device. Yes, I've seen a >number of tar tapes with 512 byte blocks (they didn't know), and have >one source that likes to write 1M blocksize (he thought it would be >faster and save space on the tape). > No no no no. Block Min/Block max is *not* the same as variable blocksize. It just establishes min/max for *fixed* blocks. >Unless I've messed up here, my "ARCHIVE Python 28388-XXX 4.CM" will >read a compressed tape with no way of me knowing that it is doing so. That's not the same as blocksize. >While an enhanced "mt status" could query many tape drives and report >on current tape position, it would be very nice if there was a way to >report if the tape was written using a hardware compression method. Sometimes you can tell, sometimes not. It depends partly on whether or not the density code reflects compression (getting to be less and less the case). I believe, off the top of my head, there are a couple of other clever ways to determine this, none of which is guaranteed to work on all tape devices. However, considering that the number of distinct SCSi tape devices in the world is probably less than a hundred, you'd think that this could be scoped out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:31:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA12418 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:31:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA12413 for ; Sat, 25 Apr 1998 21:31:54 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id WAA12999; Sat, 25 Apr 1998 22:27:33 -0600 (MDT) Date: Sat, 25 Apr 1998 22:27:33 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804260427.WAA12999@narnia.plutotech.com> To: Harlan Stenn cc: scsi@FreeBSD.ORG Subject: Re: does CAM do this? Newsgroups: pluto.freebsd.scsi In-Reply-To: <15923.893554380@brown.pfcs.com> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <15923.893554380@brown.pfcs.com> you wrote: >> > The problem is that a read() to the (default) tape drive under FreeBSD >> > returns exactly the number of bytes you asked for, so there is no way to >> > determine the actual number of bytes on the tape record. >> >> No, it returns no more than you asked for. That why you should do a >> read() of a record larger than you expect or can support, and it will >> return the number written in the tape record. > > I beg to differ. > > I agree that the read will return no more than I ask for. > > However... > > With the default tape drive configuration (on the drives I've tested), if I > have a Large file on the tape blocked at, say, 10k bytes, if I issue a > read of "more than 10k but less than the size of the file" I'll get back > exactly what I asked for. > > I cannot tell that the tape was blocked at 10k bytes. > > H This is probably because the old st driver does not set the B_ERROR buffer flag on a short read. If you don't set the B_ERROR flag while setting b_error to 0, physio will attempt to fill the user's buffer by attempting additional reads. The CAM driver behaves exactly as you wish. When a short read is encountered, the user is returned a short read. Just be aware, however, that if the device is in fixed block mode, your request must be a multiple of the block size. Should it be a multiple > 1, you will get more than a single block back. The only way to determine the block size in fixed block mode is to perform a smart search for the block size. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:47:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA13678 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:47:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA13673 for ; Sat, 25 Apr 1998 21:47:22 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA02318; Sat, 25 Apr 1998 21:41:54 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd002313; Sun Apr 26 04:41:45 1998 Date: Sat, 25 Apr 1998 21:36:20 -0700 (PDT) From: Julian Elischer To: Harlan Stenn cc: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? In-Reply-To: <15923.893554380@brown.pfcs.com> 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 Sat, 25 Apr 1998, Harlan Stenn wrote: > I beg to differ. > > I agree that the read will return no more than I ask for. > > However... > > With the default tape drive configuration (on the drives I've tested), if I > have a Large file on the tape blocked at, say, 10k bytes, if I issue a > read of "more than 10k but less than the size of the file" I'll get back > exactly what I asked for. > > I cannot tell that the tape was blocked at 10k bytes. the only whay this can be true is if the drive is in FIXED BLOCK MODE. In fixed mode, a 10 K read is written to tape as 10 x 1K blocks (or whatever the blocksize you have selected using mt(1) is. If you then read 16K, you get back 16 x 1k blocks (or whatever the blocksize is) If you set the blocksize (using mt(1) to (say) 10k, and put in a tape with 1k blocks, and try read 10k, then the driver will request a single 10k block from the drive. The drive will respond with "hey are you nuts? I only got 1k block here" The driver will then print out an error message on the console. which will give you SOME idea of what teh record size SHOULD have been (probably the number -(9 x 1k) will appear in the message somewhere.) alternatively you could set the record size to 20 btes and tray read 20 bytes.. a similar thing should occur. the erro message you see on the console should give you a CLUE as to what the (fixed) recod size is.. If your drive were in VARIABLE mode, then each read returns at most ONE record. If there is more data in the record than you tried to read, you get an error. (and a message) if there is less, you get less, and no error. At least that's what used to happen when I wrotethe driver a few years ago so consider this to be "from the horse's mouth, but possibly dated" ok? experiment with mt(1) and dd(1) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 21:57:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA14330 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 21:57:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14325 for ; Sat, 25 Apr 1998 21:57:16 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA02439; Sat, 25 Apr 1998 21:48:34 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd002435; Sun Apr 26 04:48:28 1998 Date: Sat, 25 Apr 1998 21:43:02 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" cc: Harlan Stenn , scsi@FreeBSD.ORG Subject: Re: does CAM do this? In-Reply-To: <199804260427.WAA12999@narnia.plutotech.com> 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 Sat, 25 Apr 1998, Justin T. Gibbs wrote: > > This is probably because the old st driver does not set the B_ERROR > buffer flag on a short read. If you don't set the B_ERROR flag > while setting b_error to 0, physio will attempt to fill the user's > buffer by attempting additional reads. I think the st does this correctly.. if not then someone's broken it because I used to use this all the time when I had SCSI tapes. CAM may well "do this correctly, but st did as well (I can't test it now) I think the reason is because he doesn't understand the difference between fixed and variable block modes. > The CAM driver behaves > exactly as you wish. When a short read is encountered, the user > is returned a short read. Just be aware, however, that if the device > is in fixed block mode, your request must be a multiple of the block > size. Should it be a multiple > 1, you will get more than a single > block back. The only way to determine the block size in fixed block > mode is to perform a smart search for the block size. I may be wrong but I vaguely remeber thet the 'info' field contains valid information in this case which I USED to print out in a meaningful manner in one version of st.c (possibly only the TFS version). julian > -- > Justin : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 25 22:12:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA15288 for freebsd-scsi-outgoing; Sat, 25 Apr 1998 22:12:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (mjacob@[209.54.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA15283 for ; Sat, 25 Apr 1998 22:12:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id WAA29259; Sat, 25 Apr 1998 22:07:12 -0700 Date: Sat, 25 Apr 1998 22:07:12 -0700 From: Matthew Jacob Message-Id: <199804260507.WAA29259@feral.com> To: gibbs@narnia.plutotech.com, julian@whistle.com Subject: Re: does CAM do this? Cc: Harlan.Stenn@pfcs.com, scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I think the reason is because he doesn't understand the difference between >fixed and variable block modes. Exactly. > > >> The CAM driver behaves >> exactly as you wish. When a short read is encountered, the user >> is returned a short read. Just be aware, however, that if the device >> is in fixed block mode, your request must be a multiple of the block >> size. Should it be a multiple > 1, you will get more than a single >> block back. The only way to determine the block size in fixed block >> mode is to perform a smart search for the block size. > >I may be wrong but I vaguely remeber thet the 'info' field contains valid >information in this case which I USED to print out in a meaningful manner >in one version of st.c (possibly only the TFS version). Yes, for SILI errrors, the info field is the residual. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message