Re: SCSI descriptor sense changes, testing needed
This has been committed to head, and the plan is to get it into stable/9 in time for 9.0. Please let me know if you run into any problems with the changes. Thanks, Ken On Fri, Sep 30, 2011 at 23:19:14 -0600, Kenneth D. Merry wrote: > > I have attached a new version of the patches, with a number of changes. > > One issue that has cropped up is that the previous sense code and my new > descriptor sense changes never paid any attention to the actual length of > the sense data returned by the controller. > > I have changed all of the error recovery code and sense printing code to > honor the sense data length in the CAM CCB. > > One other problem related to that is that many controller drivers don't set > the sense residual field in struct ccb_scsiio properly, or don't set it at > all. This patch includes changes to the isp, mps, mpt, umass, and ciss > drivers to set the sense_resid field properly. > > There are lots of other drivers in the system, however, that haven't been > audited, and may or may not set the sense residual correctly. > > I also fixed an issue reported by Fabian Keil that showed up with the ahci > driver. In reverting a change I have in my local tree to switch to a 2 > byte length field in the SCSI inquiry CDB, I accidently shortened the CDB > to 5 bytes. Oops. > > I'd really appreciate more feedback; Fabian is the only person to report > testing the previous patch. > > Thanks, > > Ken > > On Thu, Sep 22, 2011 at 13:33:05 -0600, Kenneth D. Merry wrote: > > > > I have attached a set of patches against head that implement SCSI > > descriptor sense support for CAM. > > > > Descriptor sense is a new sense (SCSI error) format introduced in the SPC-3 > > spec in 2006. FreeBSD doesn't currently support it. > > > > Seagate's new 3TB SAS drives come with descriptor sense enabled by default, > > and it's possible that other newer drives do as well. Because all the > > sense key, additional sense code, and additional sense code qualifier > > fields are in different places, the CAM error recovery code will not do the > > right thing when it gets descriptor sense. > > > > These patches do bump up the size of struct scsi_sense_data, and so I have > > incremented CAM_VERSION as well. I have discussed this with re@, and it > > looks like we'll be putting the changes in before 9.0, so it ships with > > support for newer SCSI devices. > > > > A number of things have changed in these patches, but in particular, it > > would be good to test the following: > > > > - The sa(4) (SCSI tape) driver. The residual handling code, which looks > >at the sense data, has changed. > > - The Playstation 3 CDROM driver. > > - Firewire target mode. > > - umass devices with the NO_INQUIRY_EVPD quirk. > > > > Also, please let me know if you see any anomalies with the sense printing > > code. In the common cases the output should look identical to the old > > code, but in some cases it will be a little different. e.g.: > > > > # camcontrol inquiry da40 -v > > pass47: Fixed Direct Access SCSI-6 device > > pass47: Serial Number 9XK0GAJ7S125XDNU > > pass47: 300.000MB/s transfers, Command Queueing Enabled > > > > (Seagate 3TB drive) > > > > # camcontrol modepage da40 -m 10 |grep D_SENSE > > D_SENSE: 1 > > > > (Descriptor sense is enabled) > > > > # camcontrol modepage da40 -m 15 -v > > (pass47:mps1:0:47:0): MODE SENSE(6). CDB: 1a 0 4f 0 ff 0 > > (pass47:mps1:0:47:0): CAM status: SCSI Status Error > > (pass47:mps1:0:47:0): SCSI status: Check Condition > > (pass47:mps1:0:47:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field > > in CDB) > > (pass47:mps1:0:47:0): Field Replaceable Unit: 1 > > (pass47:mps1:0:47:0): Command byte 2 bit 5 is invalid > > (pass47:mps1:0:47:0): Descriptor 0x80: 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 > > camcontrol: error sending mode sense command > > > > (The FRU and Sense Key Specific entries are on separate lines, and a > > vendor-specific sense descriptor is printed out in hex format.) > > > > Anyway, I'd appreciate any testing and feedback on these changes. As I > > said, they will probably be in 9.0, so if there are any issues it would be > > better to find them now. :) > > > > Thanks, > > > > Ken > > -- > > Kenneth Merry > > k...@freebsd.org > -- > Kenneth Merry > k...@freebsd.org -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI descriptor sense changes, testing needed
"Kenneth D. Merry" wrote: > On Tue, Sep 27, 2011 at 21:46:03 +0200, Fabian Keil wrote: > > "Kenneth D. Merry" wrote: > > > > > On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote: > > > > "Kenneth D. Merry" wrote: > > > > > > > > > I have attached a set of patches against head that implement SCSI > > > > > descriptor sense support for CAM. > > > > > > > > > Anyway, I'd appreciate any testing and feedback on these changes. As > > > > > I > > > > > said, they will probably be in 9.0, so if there are any issues it > > > > > would > > > > > be better to find them now. :) > > > > > > > > I've been using the patch on a ThinkPad R500 since yesterday and > > > > just reverted it today again to get my kernel closer to HEAD before > > > > looking into some (probably unrelated) panics. > > > > > > > > I didn't notice it while using the patch, but it looks like the > > > > kernel wasn't able to pick up cd0 anymore: > > > > > > Hmm. I don't think any of the changes would have caused this, but > > > evidently something did... > > > > > > Let's see if we can debug it... > > > > > > I have attached a patch to add some debugging output, and I see at least > > > one interesting thing in the logs below. > > > > > > Can you re-apply the descriptor sense patch, and then try the attached > > > debugging patch as well? > > > > Sure. > > I believe this is fixed with my latest set of patches. Can you try them > and let me know? The device is indeed properly picked up now: Oct 3 12:09:26 r500 kernel: ahcich0: AHCI reset... Oct 3 12:09:26 r500 kernel: ahcich0: SATA connect time=900us status=0113 Oct 3 12:09:26 r500 kernel: ahcich0: AHCI reset: device found Oct 3 12:09:26 r500 kernel: ahcich1: AHCI reset... Oct 3 12:09:26 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Oct 3 12:09:26 r500 kernel: ahcich1: AHCI reset: device found Oct 3 12:09:26 r500 kernel: ugen0.1: at usbus0 Oct 3 12:09:26 r500 kernel: uhub0: on usbus0 Oct 3 12:09:26 r500 kernel: ugen1.1: at usbus1 Oct 3 12:09:26 r500 kernel: uhub1: on usbus1 Oct 3 12:09:26 r500 kernel: ugen2.1: at usbus2 Oct 3 12:09:26 r500 kernel: uhub2: on usbus2 Oct 3 12:09:26 r500 kernel: ugen3.1: at usbus3 Oct 3 12:09:26 r500 kernel: uhub3: on usbus3 Oct 3 12:09:26 r500 kernel: ugen4.1: at usbus4 Oct 3 12:09:26 r500 kernel: uhub4: on usbus4 Oct 3 12:09:26 r500 kernel: ugen5.1: at usbus5 Oct 3 12:09:26 r500 kernel: uhub5: on usbus5 Oct 3 12:09:26 r500 kernel: ugen6.1: at usbus6 Oct 3 12:09:26 r500 kernel: uhub6: on usbus6 Oct 3 12:09:26 r500 kernel: ugen7.1: at usbus7 Oct 3 12:09:26 r500 kernel: uhub7: on usbus7 Oct 3 12:09:26 r500 kernel: battery0: battery initialization start Oct 3 12:09:26 r500 kernel: acpi_acad0: acline initialization start Oct 3 12:09:26 r500 kernel: battery0: battery initialization done, tried 1 times Oct 3 12:09:26 r500 kernel: acpi_acad0: On Line Oct 3 12:09:26 r500 kernel: acpi_acad0: acline initialization done, tried 1 times Oct 3 12:09:26 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Oct 3 12:09:26 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: Oct 3 12:09:26 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Oct 3 12:09:26 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Oct 3 12:09:26 r500 kernel: GEOM: new disk ada0 Oct 3 12:09:26 r500 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Oct 3 12:09:26 r500 kernel: ada0: ATA-8 SATA 1.x device Oct 3 12:09:26 r500 kernel: ada0: Serial Number 090509FB2F32LLEY6D8A Oct 3 12:09:26 r500 kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) Oct 3 12:09:26 r500 kernel: ada0: Command Queueing enabled Oct 3 12:09:26 r500 kernel: ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) Oct 3 12:09:26 r500 kernel: ada0: Previously was known as ad4 Oct 3 12:09:26 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 Oct 3 12:09:26 r500 kernel: pass0: ATA-8 SATA 1.x device Oct 3 12:09:26 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A Oct 3 12:09:26 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) Oct 3 12:09:26 r500 kernel: pass0: Command Queueing enabled Oct 3 12:09:26 r500 kernel: pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 Oct 3 12:09:26 r500 kernel: pass1: Removable CD-ROM SCSI-0 device Oct 3 12:09:26 r500 kernel: pass1: Serial Number M2R96NC0647 Oct 3 12:09:26 r500 kernel: pass1: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condition Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) Oct 3 12:09:26 r500
Re: SCSI descriptor sense changes, testing needed
On Tue, Sep 27, 2011 at 21:46:03 +0200, Fabian Keil wrote: > "Kenneth D. Merry" wrote: > > > On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote: > > > "Kenneth D. Merry" wrote: > > > > > > > I have attached a set of patches against head that implement SCSI > > > > descriptor sense support for CAM. > > > > > > > Anyway, I'd appreciate any testing and feedback on these changes. As I > > > > said, they will probably be in 9.0, so if there are any issues it would > > > > be better to find them now. :) > > > > > > I've been using the patch on a ThinkPad R500 since yesterday and > > > just reverted it today again to get my kernel closer to HEAD before > > > looking into some (probably unrelated) panics. > > > > > > I didn't notice it while using the patch, but it looks like the > > > kernel wasn't able to pick up cd0 anymore: > > > > Hmm. I don't think any of the changes would have caused this, but > > evidently something did... > > > > Let's see if we can debug it... > > > > I have attached a patch to add some debugging output, and I see at least > > one interesting thing in the logs below. > > > > Can you re-apply the descriptor sense patch, and then try the attached > > debugging patch as well? > > Sure. I believe this is fixed with my latest set of patches. Can you try them and let me know? Thanks, Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCSI descriptor sense changes, testing needed
"Kenneth D. Merry" wrote: > On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote: > > "Kenneth D. Merry" wrote: > > > > > I have attached a set of patches against head that implement SCSI > > > descriptor sense support for CAM. > > > > > Anyway, I'd appreciate any testing and feedback on these changes. As I > > > said, they will probably be in 9.0, so if there are any issues it would > > > be better to find them now. :) > > > > I've been using the patch on a ThinkPad R500 since yesterday and > > just reverted it today again to get my kernel closer to HEAD before > > looking into some (probably unrelated) panics. > > > > I didn't notice it while using the patch, but it looks like the > > kernel wasn't able to pick up cd0 anymore: > > Hmm. I don't think any of the changes would have caused this, but > evidently something did... > > Let's see if we can debug it... > > I have attached a patch to add some debugging output, and I see at least > one interesting thing in the logs below. > > Can you re-apply the descriptor sense patch, and then try the attached > debugging patch as well? Sure. Sep 27 20:39:24 r500 kernel: ahcich0: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich0: SATA connect time=900us status=0113 Sep 27 20:39:24 r500 kernel: ahcich0: AHCI reset: device found Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: battery0: battery initialization start Sep 27 20:39:24 r500 kernel: ugen0.1: at usbus0 Sep 27 20:39:24 r500 kernel: uhub0: on usbus0 Sep 27 20:39:24 r500 kernel: ugen1.1: at usbus1 Sep 27 20:39:24 r500 kernel: uhub1: on usbus1 Sep 27 20:39:24 r500 kernel: ugen2.1: at usbus2 Sep 27 20:39:24 r500 kernel: uhub2: on usbus2 Sep 27 20:39:24 r500 kernel: ugen3.1: at usbus3 Sep 27 20:39:24 r500 kernel: uhub3: on usbus3 Sep 27 20:39:24 r500 kernel: ugen4.1: at usbus4 Sep 27 20:39:24 r500 kernel: uhub4: on usbus4 Sep 27 20:39:24 r500 kernel: ugen5.1: at usbus5 Sep 27 20:39:24 r500 kernel: uhub5: on usbus5 Sep 27 20:39:24 r500 kernel: ugen6.1: at usbus6 Sep 27 20:39:24 r500 kernel: uhub6: on usbus6 Sep 27 20:39:24 r500 kernel: ugen7.1: at usbus7 Sep 27 20:39:24 r500 kernel: uhub7: on usbus7 Sep 27 20:39:24 r500 kernel: acpi_acad0: acline initialization start Sep 27 20:39:24 r500 kernel: battery0: battery initialization done, tried 1 times Sep 27 20:39:24 r500 kernel: acpi_acad0: On Line Sep 27 20:39:24 r500 kernel: acpi_acad0: acline initialization done, tried 1 times Sep 27 20:39:24 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 27 20:39:24 r500 kernel: ahci_end_transaction: got AHCI_ERR_INVALID! Sep 27 20:39:24 r500 kernel: ahci_end_transaction: op 12 dxfer_len 36 sense_len 18 sense_resid 0 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 24 0 0 Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB request was invalid Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 27 20:39:24 r500 kernel: ahci_end_transaction: got AHCI_ERR_INVALID! Sep 27 20:39:24 r500 kernel: ahci_end_transaction: op 12 dxfer_len 36 sense_len 18 sense_resid 0 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 24 0 0 Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB request was invalid Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 27 20:39:24 r500 kernel: ahci_end_transaction: got AHCI_ERR_INVALID! Sep 27 20:39:24 r500 kernel: ahci_end_transaction: op 12 dxfer_len 36 sense_len 18 sense_resid 0 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 24 0 0 Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB request was invalid Sep 27 20:39:24 r500 kernel: uhub0: 2 ports with 2 removable, self powered Sep 27 20:39:24 r500 kernel: uhub1: 2 ports with 2 removable, self powered Sep 27 20:39:24 r50
Re: SCSI descriptor sense changes, testing needed
On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote: > "Kenneth D. Merry" wrote: > > > I have attached a set of patches against head that implement SCSI > > descriptor sense support for CAM. > > > Anyway, I'd appreciate any testing and feedback on these changes. As I > > said, they will probably be in 9.0, so if there are any issues it would > > be better to find them now. :) > > I've been using the patch on a ThinkPad R500 since yesterday and > just reverted it today again to get my kernel closer to HEAD before > looking into some (probably unrelated) panics. > > I didn't notice it while using the patch, but it looks like the > kernel wasn't able to pick up cd0 anymore: Hmm. I don't think any of the changes would have caused this, but evidently something did... Let's see if we can debug it... I have attached a patch to add some debugging output, and I see at least one interesting thing in the logs below. Can you re-apply the descriptor sense patch, and then try the attached debugging patch as well? > fk@r500 ~ $grep -h "new dis" /var/log/messages /var/log/messages.[123] | sort > Sep 21 23:40:23 r500 kernel: GEOM: new disk da0 > Sep 21 23:40:30 r500 kernel: GEOM: new disk da1 > Sep 21 23:45:21 r500 kernel: GEOM: new disk ada0 > Sep 21 23:45:21 r500 kernel: GEOM: new disk cd0 > Sep 21 23:45:21 r500 kernel: GEOM: new disk da0 > Sep 21 23:45:21 r500 kernel: GEOM: new disk da1 > Sep 21 23:52:44 r500 kernel: GEOM: new disk ada0 > Sep 21 23:52:44 r500 kernel: GEOM: new disk cd0 > Sep 21 23:53:14 r500 kernel: GEOM: new disk da0 > Sep 21 23:56:23 r500 kernel: GEOM: new disk da1 > Sep 22 21:14:17 r500 kernel: GEOM: new disk ada0 > Sep 22 21:14:17 r500 kernel: GEOM: new disk cd0 > Sep 22 22:10:20 r500 kernel: GEOM: new disk da0 > [patch applied] > Sep 22 23:29:45 r500 kernel: GEOM: new disk da0 > Sep 23 14:38:31 r500 kernel: GEOM: new disk ada0 > Sep 23 17:19:40 r500 kernel: GEOM: new disk da0 > Sep 23 19:20:21 r500 kernel: GEOM: new disk da0 > Sep 23 19:20:42 r500 kernel: GEOM: new disk da1 > Sep 23 22:58:56 r500 kernel: GEOM: new disk da0 > Sep 24 09:31:02 r500 kernel: GEOM: new disk ada0 > Sep 24 14:17:22 r500 kernel: GEOM: new disk da0 > Sep 24 14:44:03 r500 kernel: GEOM: new disk ada0 > Sep 24 14:44:03 r500 kernel: GEOM: new disk da0 > Sep 24 14:53:30 r500 kernel: GEOM: new disk ada0 > Sep 24 15:03:24 r500 kernel: GEOM: new disk da0 > Sep 24 15:06:03 r500 kernel: GEOM: new disk da0 > Sep 24 15:13:57 r500 kernel: GEOM: new disk ada0 > Sep 24 15:14:16 r500 kernel: GEOM: new disk da0 > Sep 24 15:27:11 r500 kernel: GEOM: new disk ada0 > Sep 24 15:28:05 r500 kernel: GEOM: new disk da0 > Sep 24 15:32:10 r500 kernel: GEOM: new disk ada0 > Sep 24 15:32:10 r500 kernel: GEOM: new disk da0 > Sep 24 15:38:16 r500 kernel: GEOM: new disk ada0 > Sep 24 15:38:16 r500 kernel: GEOM: new disk da0 > Sep 24 15:43:33 r500 kernel: GEOM: new disk ada0 > Sep 24 15:43:33 r500 kernel: GEOM: new disk da0 > Sep 24 15:49:30 r500 kernel: GEOM: new disk ada0 > [patch reverted] > Sep 24 19:32:51 r500 kernel: GEOM: new disk ada0 > Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 > Sep 24 19:32:51 r500 kernel: GEOM: new disk da0 > Sep 24 19:38:07 r500 kernel: GEOM: new disk ada0 > Sep 24 19:38:07 r500 kernel: GEOM: new disk cd0 > > Without the patch I'm used to getting the following kernel > messages when booting (without a disc in cd0): > > Sep 24 19:32:51 r500 kernel: ahcich0: AHCI reset: device ready after 100ms > Sep 24 19:32:51 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: > Sep 24 19:32:51 r500 kernel: ahcich1: AHCI reset: device ready after 100ms > Sep 24 19:32:51 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 > Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 > Sep 24 19:32:51 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > Sep 24 19:32:51 r500 kernel: pass0: ATA-8 > SATA 1.x device > Sep 24 19:32:51 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A > Sep 24 19:32:51 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, > PIO 8192bytes) > Sep 24 19:32:51 r500 kernel: pass0: Command Queueing enabled > Sep 24 19:32:51 r500 kernel: pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > Sep 24 19:32:51 r500 kernel: pass1: Removable > CD-ROM SCSI-0 device > Sep 24 19:32:51 r500 kernel: pass1: Serial Number M2R96NC0647 > Sep 24 19:32:51 r500 kernel: pass1: 150.000MB/s transfers (SATA 1.x, UDMA6, > ATAPI 12bytes, PIO 8192bytes) > Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error > Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 0 > 0 0 0 0 0 0 0 > Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status > Error > Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condition > Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: UNIT ATTENTION > asc:29,0 (Power on, reset, or bus device reset occurred) > Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Retrying command (per sense > data) > Sep 24 19:
Re: SCSI descriptor sense changes, testing needed
"Kenneth D. Merry" wrote: > I have attached a set of patches against head that implement SCSI > descriptor sense support for CAM. > Anyway, I'd appreciate any testing and feedback on these changes. As I > said, they will probably be in 9.0, so if there are any issues it would > be better to find them now. :) I've been using the patch on a ThinkPad R500 since yesterday and just reverted it today again to get my kernel closer to HEAD before looking into some (probably unrelated) panics. I didn't notice it while using the patch, but it looks like the kernel wasn't able to pick up cd0 anymore: fk@r500 ~ $grep -h "new dis" /var/log/messages /var/log/messages.[123] | sort Sep 21 23:40:23 r500 kernel: GEOM: new disk da0 Sep 21 23:40:30 r500 kernel: GEOM: new disk da1 Sep 21 23:45:21 r500 kernel: GEOM: new disk ada0 Sep 21 23:45:21 r500 kernel: GEOM: new disk cd0 Sep 21 23:45:21 r500 kernel: GEOM: new disk da0 Sep 21 23:45:21 r500 kernel: GEOM: new disk da1 Sep 21 23:52:44 r500 kernel: GEOM: new disk ada0 Sep 21 23:52:44 r500 kernel: GEOM: new disk cd0 Sep 21 23:53:14 r500 kernel: GEOM: new disk da0 Sep 21 23:56:23 r500 kernel: GEOM: new disk da1 Sep 22 21:14:17 r500 kernel: GEOM: new disk ada0 Sep 22 21:14:17 r500 kernel: GEOM: new disk cd0 Sep 22 22:10:20 r500 kernel: GEOM: new disk da0 [patch applied] Sep 22 23:29:45 r500 kernel: GEOM: new disk da0 Sep 23 14:38:31 r500 kernel: GEOM: new disk ada0 Sep 23 17:19:40 r500 kernel: GEOM: new disk da0 Sep 23 19:20:21 r500 kernel: GEOM: new disk da0 Sep 23 19:20:42 r500 kernel: GEOM: new disk da1 Sep 23 22:58:56 r500 kernel: GEOM: new disk da0 Sep 24 09:31:02 r500 kernel: GEOM: new disk ada0 Sep 24 14:17:22 r500 kernel: GEOM: new disk da0 Sep 24 14:44:03 r500 kernel: GEOM: new disk ada0 Sep 24 14:44:03 r500 kernel: GEOM: new disk da0 Sep 24 14:53:30 r500 kernel: GEOM: new disk ada0 Sep 24 15:03:24 r500 kernel: GEOM: new disk da0 Sep 24 15:06:03 r500 kernel: GEOM: new disk da0 Sep 24 15:13:57 r500 kernel: GEOM: new disk ada0 Sep 24 15:14:16 r500 kernel: GEOM: new disk da0 Sep 24 15:27:11 r500 kernel: GEOM: new disk ada0 Sep 24 15:28:05 r500 kernel: GEOM: new disk da0 Sep 24 15:32:10 r500 kernel: GEOM: new disk ada0 Sep 24 15:32:10 r500 kernel: GEOM: new disk da0 Sep 24 15:38:16 r500 kernel: GEOM: new disk ada0 Sep 24 15:38:16 r500 kernel: GEOM: new disk da0 Sep 24 15:43:33 r500 kernel: GEOM: new disk ada0 Sep 24 15:43:33 r500 kernel: GEOM: new disk da0 Sep 24 15:49:30 r500 kernel: GEOM: new disk ada0 [patch reverted] Sep 24 19:32:51 r500 kernel: GEOM: new disk ada0 Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 Sep 24 19:32:51 r500 kernel: GEOM: new disk da0 Sep 24 19:38:07 r500 kernel: GEOM: new disk ada0 Sep 24 19:38:07 r500 kernel: GEOM: new disk cd0 Without the patch I'm used to getting the following kernel messages when booting (without a disc in cd0): Sep 24 19:32:51 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Sep 24 19:32:51 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: Sep 24 19:32:51 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 24 19:32:51 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 Sep 24 19:32:51 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 Sep 24 19:32:51 r500 kernel: pass0: ATA-8 SATA 1.x device Sep 24 19:32:51 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A Sep 24 19:32:51 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) Sep 24 19:32:51 r500 kernel: pass0: Command Queueing enabled Sep 24 19:32:51 r500 kernel: pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 Sep 24 19:32:51 r500 kernel: pass1: Removable CD-ROM SCSI-0 device Sep 24 19:32:51 r500 kernel: pass1: Serial Number M2R96NC0647 Sep 24 19:32:51 r500 kernel: pass1: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condition Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Retrying command (per sense data) Sep 24 19:32:51 r500 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Sep 24 19:32:51 r500 kernel: ada0: ATA-8 SATA 1.x device Sep 24 19:32:51 r500 kernel: ada0: Serial Number 090509FB2F32LLEY6D8A Sep 24 19:32:51 r500 kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) Sep 24 19:32:51 r500 kernel: ada0: Command Queueing enabled Sep 24 19:32:51 r500 kernel: ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) Sep 24 19:32:51 r500 kernel: ada0: Previously was known as ad4 Sep 24 19:32:51 r500 kernel: SMP: AP CPU #1 Launched! Sep 24 19:32:51 r500 kernel: cpu1
Re: SCSI descriptor sense changes, testing needed
On Thu, Sep 22, 2011 at 01:33:05PM -0600, Kenneth D. Merry wrote: > > I have attached a set of patches against head that implement SCSI > descriptor sense support for CAM. > > Descriptor sense is a new sense (SCSI error) format introduced in the SPC-3 > spec in 2006. FreeBSD doesn't currently support it. > > Seagate's new 3TB SAS drives come with descriptor sense enabled by default, > and it's possible that other newer drives do as well. Because all the > sense key, additional sense code, and additional sense code qualifier > fields are in different places, the CAM error recovery code will not do the > right thing when it gets descriptor sense. > > These patches do bump up the size of struct scsi_sense_data, and so I have > incremented CAM_VERSION as well. I have discussed this with re@, and it > looks like we'll be putting the changes in before 9.0, so it ships with > support for newer SCSI devices. Hi Ken, as far as I understand this also requires consumers of scsi_sense_data and SSD_FULL_SIZE etc in userland to be recompiled. So while you are at breaking the API and ABI of CAM anyway, could you please take the opportunity to change CAM_XPT_PATH_ID and CAM_BUS_WILDCARD to not use the same value so incorrect uses will fail? Currently, there seems to be a lot of confusion when to use which one, including camcontrol(8) just encoding this as -1: /* * We don't want to rescan or reset the xpt bus. * See above. */ if ((int)bus_result->path_id == -1) continue; Moreover, AFAICT CAM_XPT_PATH_ID corresponds to what the ANSI CAM Draft refers to as "XPT Path ID" and specifies a value of 0xff for. Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
