From owner-freebsd-scsi Sat Jun 17 1:52:38 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from niagara.shiojiri.ne.jp (niagara.shiojiri.ne.jp [203.141.192.49]) by hub.freebsd.org (Postfix) with ESMTP id C0EFF37B79D for ; Sat, 17 Jun 2000 01:52:28 -0700 (PDT) (envelope-from stake@po.shiojiri.ne.jp) Received: from localhost (ppp030.shiojiri.ne.jp [203.141.192.158]) by niagara.shiojiri.ne.jp (8.9.3/3.7W-:0052516) with ESMTP id RAA04028; Sat, 17 Jun 2000 17:51:44 +0900 (JST) To: ken@kdm.org Cc: stake@po.shiojiri.ne.jp, thomas.graichen@innominate.de, tech@ioiscsi.com, scsi@FreeBSD.ORG Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE In-Reply-To: <20000615000840.A39913@panzer.kdm.org> References: <20000614225332T.stake@po.shiojiri.ne.jp> <20000615000840.A39913@panzer.kdm.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Jun_17_17:43:53_2000_809)--" Content-Transfer-Encoding: 7bit Message-Id: <20000617174358N.stake@po.shiojiri.ne.jp> Date: Sat, 17 Jun 2000 17:43:58 +0900 From: Takefumi SAYO X-Dispatcher: imput version 20000228(IM140) Lines: 374 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----Next_Part(Sat_Jun_17_17:43:53_2000_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Kenneth D. Merry" Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE Date: Thu, 15 Jun 2000 00:08:40 -0600 > On Wed, Jun 14, 2000 at 22:53:32 +0900, Takefumi SAYO wrote: > > From: "Kenneth D. Merry" > > Subject: Re: Initio INIC-941 PCI SCSI driver for FreeBSD 4.0-RELEASE > > Date: Tue, 13 Jun 2000 10:46:23 -0600 > > > > > On Tue, Jun 13, 2000 at 08:49:48 +0200, Thomas Graichen wrote: > > > > On Sun, 11 Jun 2000, Takefumi SAYO wrote: > > > > > and > > > > > > > > > > (cd0:iha0:0:6:0): got CAM status 0xb > > > > > (cd0:iha0:0:6:0): fatal error, failed to attach to device > > > > > (cd0:iha0:0:6:0): lost device > > > > > (cd0:iha0:0:6:0): removing device entry > > > > > > > > > > if no media presents in the removable device. > > > > > > > > > > Could you fix this if you have time? Because I don't know > > > > > anything about SCSI and CAM. :-( > > > > > > > > > i don't know much more either :-) ... but i think you may ask this > > > > on the scsi list (i'll cc this mail to it too) - maybe someone > > > > there might help > > > > > > Status 0xb is a command timeout. It means the drive didn't respond to the > > > READ CAPACITY command within 20 seconds. > > > > When I used 'cdrecord' on FreeBSD 3.4-RELEASE with IOI's driver, > > cdrecord said ... timeout or something like that, and I could not > > burn CD-R. But on 2.2.8-RELEASE, there was no problem, I think. > > Okay, that's good to know -- it likely worked at one point. > > > > What kind of CDROM drive are you using? > > > > a SCSI-2 CD-R drive producted by Matsushita. > > kernel says the followings when booting. > > > > cd0 at iha0 bus 0 target 6 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 20.000MB/s transfers (20.000MHz, offset 15) > > cd0: cd present [328831 x 2048 byte records] > > > > (As I mentioned in the report to Graichen, 'got CAM status 0xb' is > > not displayed if media is present in drive.) > > Seems like a normal drive, I guess. Here's one thing you can try. In > sys/cam/scsi/scsi_cd.c, in the cdstart() function, in the CD_STATE_PROBE > case, you'll find the following function call: > > scsi_read_capacity(csio, > /*retries*/1, > cddone, > MSG_SIMPLE_Q_TAG, > rcap, > SSD_FULL_SIZE, > /*timeout*/20000); > > The default timeout is 20 seconds. Try increasing that value to say 300 > seconds (i.e. 300000 milliseconds). > > See if your drive reports a reasonable status then. > > If it does, try decreasing the timeout until you find the place where it > fails. > > Some drives take a long time to return a read capacity command when there > is no media present. Until now, 20 seconds has been long enough to catch > most of them, but it may be that the timeout is too short for your drive. > > If we can find a timeout that'll do the trick, and it isn't too long, we > may be able to increase the default timeout in the driver. > > If you'd like a slightly faster way to test this out, without recompiling > your kernel, you can try this: > > camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > > That will issue a SCSI READ CAPACITY command to pass0, with a timeout of > 300 seconds. > > If there is no media in the drive, and the command hasn't timed out, you > should get SCSI sense information like this: > > # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > camcontrol: error sending command > (pass2:ahc1:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (pass2:ahc1:0:4:0): NOT READY asc:3a,0 > (pass2:ahc1:0:4:0): Medium not present I got different result. It still says CAM status is 0xb. # camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" camcontrol: error sending command CAM status is 0xb > If there is media in the drive, you should get output like this: > > # camcontrol cmd cd0 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > 187384 2048 # camcontrol cmd pass0 -v -t 300 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 331334 2048 > If the command times out, you should get some sort of CAM status back that > would indicate a timeout (probably 0xb). > > Anyway, you can start with say 300 seconds, and then decrease the timeout > gradually until you get a failure with a timeout instead of SCSI sense > information. After trying to increase timeout value, I found the following things. (by turning on CAM_DEBUG and putting many printfs into driver source...) * Other SCSI errors (like parity error, buffer overrun, etc.) are mapped to CAM_CMD_TIMEOUT in i91u_done() in i91u.c. * 'got CAM status 0xb' does *NOT* mean timeout, but results from direction mismatch in tul_next_state() in i91utmp.c. * I don't know what direction is and why mismatch ocurrs, but kernel gets no CAM error if direction check is commented out. (bypassing direction check may cause another problem...) Is this right behavior of driver? cd0 at iha0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Further investigation is beyond my skill, so I send what I changed from 'iha-991210.tar.gz' with this mail for SCSI hackers who can fix this problem correctly and newbusify driver. (Please see attached diff and Graichen's web page http://www.innominate.org/~tgr/ for iha-991210.tar.gz) Ofcourse I can test the driver with Initio INIC-941 PCI SCSI adapter and Matsushita CD-R CW-7502. # I also desire that IOI developers work on it as user support. ;-) -- ----Next_Part(Sat_Jun_17_17:43:53_2000_809)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: iha-991210-20000617.diff Content-Disposition: attachment; filename="iha-991210-20000617.diff" diff -rN iha-991210/a100.c iha-20000617/a100.c 33c33 < #include --- > /* #include */ 46c46 < #include --- > /* #include */ 100c100 < #ifdef 0 --- > #if 0 113c113 < #ifdef 0 --- > #if 0 139c139 < #ifdef 0 --- > #if 0 154c154 < #ifdef 0 --- > #if 0 180c180,184 < DATA_SET (pcidevice_set,a100_device); --- > #ifdef COMPAT_PCI_DRIVER > COMPAT_PCI_DRIVER(ihb, a100_device); > #else > DATA_SET (pcidevice_set, a100_device); > #endif /* COMPAT_PCI_DRIVER */ 267c271 < #ifdef 0 --- > #if 0 502c506 < #ifdef 0 --- > #if 0 1012a1017,1058 > } else if (pScb->SCB_HaStat == HOST_DO_DU) { > > /* > ** Data overrun(underrun) > */ > ccb->ccb_h.status = CAM_DATA_RUN_ERR; > > } else if (pScb->SCB_HaStat == HOST_BUS_FREE) { > > /* > ** Bus free > */ > ccb->ccb_h.status = CAM_UNEXP_BUSFREE; > > } else if (pScb->SCB_HaStat == HOST_BAD_PHAS) { > > /* > ** Bad phase > */ > ccb->ccb_h.status = CAM_SEQUENCE_FAIL; > > } else if (pScb->SCB_HaStat == HOST_INV_CMD) { > > /* > ** Invalid command > */ > ccb->ccb_h.status = CAM_REQ_INVALID; > > } else if (pScb->SCB_HaStat == HOST_SCSI_RST) { > > /* > ** SCSI bus reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; > > } else if (pScb->SCB_HaStat == HOST_DEV_RST) { > > /* > ** SCSI device reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; /* XXX right? */ > 1053c1099 < #ifdef 0 --- > #if 0 1617c1663 < #ifdef 0 --- > #if 0 diff -rN iha-991210/i91u.c iha-20000617/i91u.c 30c30 < #ifdef KERNEL --- > #ifdef _KERNEL 39c39 < #endif /* KERNEL */ --- > #endif /* _KERNEL */ 45c45 < #include --- > /* #include */ 83c83 < #ifdef KERNEL --- > #ifdef _KERNEL 100c100 < #endif /* KERNEL */ --- > #endif /* _KERNEL */ 114a115,117 > #ifdef COMPAT_PCI_DRIVER > COMPAT_PCI_DRIVER(iha, i91u_device); > #else 116c119 < --- > #endif /* COMPAT_PCI_DRIVER */ 211a215,256 > } else if (pScb->SCB_HaStat == HOST_DO_DU) { > > /* > ** Data overrun(underrun) > */ > ccb->ccb_h.status = CAM_DATA_RUN_ERR; > > } else if (pScb->SCB_HaStat == HOST_BUS_FREE) { > > /* > ** Bus free > */ > ccb->ccb_h.status = CAM_UNEXP_BUSFREE; > > } else if (pScb->SCB_HaStat == HOST_BAD_PHAS) { > > /* > ** Bad phase > */ > ccb->ccb_h.status = CAM_SEQUENCE_FAIL; > > } else if (pScb->SCB_HaStat == HOST_INV_CMD) { > > /* > ** Invalid command > */ > ccb->ccb_h.status = CAM_REQ_INVALID; > > } else if (pScb->SCB_HaStat == HOST_SCSI_RST) { > > /* > ** SCSI bus reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; > > } else if (pScb->SCB_HaStat == HOST_DEV_RST) { > > /* > ** SCSI device reset > */ > ccb->ccb_h.status = CAM_SCSI_BUS_RESET; /* XXX right? */ > 354a400 > 683a730,731 > /* XXX commented out. This line causes > XXX "resource_list_alloc: resource entry is busy" 688c736 < --- > */ 815,818d862 < < < < diff -rN iha-991210/i91utmp.c iha-20000617/i91utmp.c 1562c1562,1566 < pScb->SCB_HaStat = HOST_DO_DU; --- > > /* XXX commented out to avoid CAM error */ > /* XXX when booting with NO media in CD-ROM. */ > /* XXX Is this right? */ > /* pScb->SCB_HaStat = HOST_DO_DU; */ 1736d1739 < 1981d1983 < diff -rN iha-991210/iha-sys_conf_files.diff iha-20000617/iha-sys_conf_files.diff 1,11c1,13 < --- /sys/conf/files.orig Sat Sep 11 17:46:07 1999 < +++ /sys/conf/files Fri Dec 10 08:04:07 1999 < @@ -95,6 +95,8 @@ < dev/ccd/ccd.c optional ccd device-driver < dev/isp/isp_freebsd.c optional isp device-driver < dev/isp/isp.c optional isp device-driver < +dev/iha/a100.c optional iha device-driver < +dev/iha/i91u.c optional iha device-driver < #dev/dpt/dpt_control.c optional dpt device-driver < dev/dpt/dpt_scsi.c optional dpt device-driver < dev/en/midway.c optional en device-driver --- > *** /sys/conf/files.orig Thu Mar 9 01:17:06 2000 > --- /sys/conf/files Sun Jun 11 00:16:15 2000 > *************** > *** 172,177 **** > --- 172,179 ---- > dev/ida/ida_disk.c optional ida > dev/ida/ida_eisa.c optional ida eisa > dev/ida/ida_pci.c optional ida pci > + dev/iha/i91u.c optional iha > + dev/iha/a100.c optional ihb > dev/isp/isp_freebsd.c optional isp > dev/isp/isp.c optional isp > dev/isp/isp_target.c optional isp ----Next_Part(Sat_Jun_17_17:43:53_2000_809)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message