From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 16 22:15:50 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 821) id A6BAF1065670; Sun, 16 Sep 2012 22:15:50 +0000 (UTC) Date: Sun, 16 Sep 2012 22:15:50 +0000 From: John To: FreeBSD iSCSI Message-ID: <20120916221550.GA63055@FreeBSD.org> References: <20120915022437.GA90210@FreeBSD.org> <20120915023329.GA55292@nargothrond.kdm.org> <20120915031305.GA97685@FreeBSD.org> <20120915032826.GA63349@nargothrond.kdm.org> <20120915040907.GA5458@FreeBSD.org> <20120915043938.GA71754@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120915043938.GA71754@nargothrond.kdm.org> User-Agent: Mutt/1.4.2.1i Cc: "Kenneth D. Merry" Subject: Re: How to force a reset of a device (disk) in an enclosre slot X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 22:15:50 -0000 ----- Kenneth D. Merry's Original Message ----- > On Sat, Sep 15, 2012 at 04:09:07 +0000, John wrote: > > ----- Kenneth D. Merry's Original Message ----- > > > On Sat, Sep 15, 2012 at 03:13:05 +0000, John wrote: > > > > ----- Kenneth D. Merry's Original Message ----- > > > > > On Sat, Sep 15, 2012 at 02:24:37 +0000, John wrote: > > > > > > Hi Folks, > > > > > > > > > > > > I've been poking around and can't seem to find a way to reset and > > > > > > hopefully acquire access to a disk device in an enclosure. For instance: > > > > > > > > > > > > FreeBSD 9.1-PRERELEASE > > > > > > > > > > > > # camcontrol smpphylist ses4 > > > > > > 37 PHYs: > > > > > > PHY Attached SAS Address > > > > > > 0 0x5000039368233602 (pass105,da98) > > > > > > 1 0x5000039368238e3e (pass106,da99) > > > > > > 2 0x500003936823bca2 (pass107,da100) > > > > > > 3 0x500003936819507e (pass108,da101) > > > > > > 4 0x5000039368197d5a (pass109,da102) > > > > > > 5 0x5000039368197c6e (pass110,da103) > > > > > > 6 0x500003936818770e (pass111,da104) > > > > > > 7 0x5000039368238eba (pass112,da105) > > > > > > 8 0x5000039368232f42 (pass113,da106) > > > > > > 9 0x0000000000000000 > > > > > > 10 0x500003936813c31e > > > > > > 11 0x5000039368233892 (pass114,da107) > > > > > > 12 0x500003936813c2ca (pass115,da108) > > > > > > ... > > > > > > > > > > > > Note, bay/slot 10 has a listed device address. If I were to pull the > > > > > > drive and re-insert it, it would show up (as da390 in this case). > > > > > > The above is after a fresh reboot. Note da106 to da107 skipping > > > > > > slot 10 (slot 9 is empty). > > > > > > > > > > > > The smp utils provide a similar view: > > > > > > > > > > > > # smp_discover /dev/ses4 > > > > > > phy 0:D:attached:[5000039368233602:00 t(SSP)] 6 Gbps > > > > > > phy 1:D:attached:[5000039368238e3e:00 t(SSP)] 6 Gbps > > > > > > phy 2:D:attached:[500003936823bca2:00 t(SSP)] 6 Gbps > > > > > > phy 3:D:attached:[500003936819507e:00 t(SSP)] 6 Gbps > > > > > > phy 4:D:attached:[5000039368197d5a:00 t(SSP)] 6 Gbps > > > > > > phy 5:D:attached:[5000039368197c6e:00 t(SSP)] 6 Gbps > > > > > > phy 6:D:attached:[500003936818770e:00 t(SSP)] 6 Gbps > > > > > > phy 7:D:attached:[5000039368238eba:00 t(SSP)] 6 Gbps > > > > > > phy 8:D:attached:[5000039368232f42:00 t(SSP)] 6 Gbps > > > > > > phy 10:D:attached:[500003936813c31e:00 t(SSP)] 6 Gbps > > > > > > phy 11:D:attached:[5000039368233892:00 t(SSP)] 6 Gbps > > > > > > phy 12:D:attached:[500003936813c2ca:00 t(SSP)] 6 Gbps > > > > > > ... > > > > > > > > > > > > The address of slot 10 matches. There is a disk in the slot - just > > > > > > isn't recognized and attached. > > > > > > > > > > > > Back to the basic question. How can I issue a command to the enclosure > > > > > > to force a re-initialization of the device to recover it without > > > > > > having to physically pull & insert it. Even if the device numbers > > > > > > are not sequential, I need access to the drive... > > > > > > > > > > You can try sending a link reset: > > > > > > > > > > camcontrol smppc ses4 -p 10 -o linkreset > > > > > > > > > > It may or may not work. You can also try disabling the PHY (-o disable) > > > > > and then sending a link reset to re-enable the link. You can also try a > > > > > hard reset (-o hardreset) > > > > > > > > Hi Ken, > > > > > > > > Well, I hadn't tried to actually disable the device. That did bring some > > > > reaction: > > > > > > > > # camcontrol smppc ses4 -p 10 -o disable > > > > # camcontrol smpphylist ses4 > > > > 37 PHYs: > > > > PHY Attached SAS Address > > > > 0 0x5000039368233602 (pass105,da98) > > > > .... > > > > 8 0x5000039368232f42 (pass113,da106) > > > > 9 0x0000000000000000 > > > > 10 0x0000000000000000 > > > > 11 0x5000039368233892 (pass114,da107) > > > > ... > > > > > > > > The device is gone. > > > > > > > > # camcontrol smppc ses4 -p 10 -o hardreset > > > > root@vprzfs01p:/root # camcontrol smpphylist ses4 > > > > 37 PHYs: > > > > PHY Attached SAS Address > > > > 0 0x5000039368233602 (pass105,da98) > > > > .... > > > > 8 0x5000039368232f42 (pass113,da106) > > > > 9 0x0000000000000000 > > > > 10 0x500003936813c31e > > > > 11 0x5000039368233892 (pass114,da107) > > > > ... > > > > > > > > The device is back, but not attached - This msg: > > > > > > > > kernel: mps1: mpssas_alloc_tm freezing simq > > > > kernel: mps1: mpssas_remove_complete on handle 0x0069, IOCStatus= 0x0 > > > > kernel: mps1: mpssas_free_tm releasing simq > > > > kernel: _mapping_add_new_device: failed to add the device with handle 0x0069 to persistent table because there is no free space available - entry 0 > > > > > > That message is harmless, it won't prevent the drive from attaching. > > > > > > > >From a debug statement in the driver: MaxPersistentEntries == 128, but I > > > > have more than 128 devices per LSI card and they normally all show up - > > > > though I do get a bunch of the above messages in dmesg.. > > > > > > You might try turning on some of the debugging in the mps(4) driver and > > > disabling and resetting the link again. > > > > > > Try: > > > > > > sysctl -w dev.mps.0.debug_level=0xf > > > > > > You might get a lot of output, so be prepared to reset it back to 4: > > > > > > sysctl -w dev.mps.0.debug_level=4 > > > > Hi Ken, > > > > I don't see anything obvious. Hopefully you're more familair with the > > code and have better eyes than I do... Here's everything from messages > > after the -o disable. There are some "unknown/unhandled"s showing up. > > Here is where the drive shows up: > > > kernel: mps_intr_locked sc 0xffffff8001353000 writing postindex 243 > > kernel: mps_enqueue_request SMID 653 cm 0xffffff80013ca4a8 ccb 0 > > kernel: mps_intr_locked sc 0xffffff8001353000 starting with replypostindex 243 > > kernel: mps_intr_locked sc 0xffffff8001353000 writing postindex 244 > > kernel: SAS Address from SAS device page0 = 500003936811feae > > kernel: Found device <401,End Device> <6.0Gbps> <0x0078> <4/36> > > kernel: mpssas_rescan_target targetid 255 > > kernel: mpssas_rescan > > kernel: > > kernel: Target id 0xff added > > It finds the device, with target ID 255 (which is a little suspicious) and > queues a rescan, but nothing happens after that. > > You might try doing a manual rescan of that device to see what happens: > > camcontrol rescan X:255:0 > > Where X is the scbus number from camcontrol devlist. > > If that doesn't work, then we need to figure out what the maximum number of > targets supported by the adapter is. To do that, set this in > /boot/loader.conf and reboot: > > hw.mps.debug_level=1 > > That should result in the IOCFacts page getting printed on boot. > > How many drives and other devices are currently attached to that > controller? What controller model is it, and do you have IT or IR > firmware on it? Hi Ken, First to some of your questions. There are 3 LSI cards installed in the box. LSI 2116 - One 16i (not in use) and a pair of 16e. There are 8 d2700 shelves attached to the 16e cards - dual channel. Eight shelves, 25 devices each: 200 disks, dual attached, da0 - da399 for fully populated shelves.. The IOCFacts are included at the end of this email. I think you've seen this diagram before: http://people.freebsd.org/~jwd/zfsnfsserver.jpg I think there is something to your comment about device id 255 being suspicious. After a fresh reboot, it appears that device 255 on both busses is missing. Issuing just the commands: camcontrol rescan 7:255:0 camcontrol rescan 8:255:0 and the drives show up: mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), mps1: scsi_status(good)(0x00), scsi_state( )(0x00) mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), mps1: scsi_status(good)(0x00), scsi_state( )(0x00) mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), mps1: scsi_status(good)(0x00), scsi_state( )(0x00) da390 at mps1 bus 0 scbus7 target 255 lun 0 da390: Fixed Direct Access SCSI-5 device da390: 600.000MB/s transfers da390: Command Queueing enabled da390: 572325MB (1172123568 512 byte sectors: 255H 63S/T 72961C) GEOM_MULTIPATH: da390 added to Z78 mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), mps2: scsi_status(good)(0x00), scsi_state( )(0x00) mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), mps2: scsi_status(good)(0x00), scsi_state( )(0x00) mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), mps2: scsi_status(good)(0x00), scsi_state( )(0x00) da391 at mps2 bus 0 scbus8 target 255 lun 0 da391: Fixed Direct Access SCSI-5 device da391: 600.000MB/s transfers da391: Command Queueing enabled da391: 572325MB (1172123568 512 byte sectors: 255H 63S/T 72961C) GEOM_MULTIPATH: da391 added to Z75 I don't know if the 'scsi data underrun' is important here. A camcontrol smpphylist of the two related shelves. Note, there is no device is bay 9. # camcontrol smpphylist ses4 37 PHYs: PHY Attached SAS Address 0 0x500003936812dd36 (pass105,da98) .... 8 0x500003936810b756 (pass113,da106) 9 0x0000000000000000 10 0x500003936811feae (da390,pass409) ... 24 0x500003936819898a (pass127,da120) # camcontrol smpphylist ses12 37 PHYs: PHY Attached SAS Address 0 0x5000c5003c4f5986 (pass308,da293) .... 8 0x5000c5003c4f5ebe (pass316,da301) 9 0x0000000000000000 10 0x5000c5003c375b86 (da391,pass410) ... 24 0x5000c5003c00cb7a (pass330,da315) On a related note, the pass & da devices are reversed for the two devices found via the rescan. I've been scanning the driver code but don't see an obvious place where device id 255 would be dropped. Please let me know if there is something you'd like me to check. This has been a learning experience. Thanks Ken. Thanks, John 16i card: (Not currenlty in use) mps0: port 0x5000-0x50ff mem 0xfbdf0000-0xfbdf3fff,0xfbd80000-0xfbdbffff irq 52 at device 0.0 on pci24 mps0: Doorbell= 0x12000000 mps0: IOCFacts : MsgVersion: 0x200 HeaderVersion: 0x1900 IOCNumber: 0 IOCExceptions: 0x0 MaxChainDepth: 128 WhoInit: ROM BIOS NumberOfPorts: 1 RequestCredit: 7632 ProductID: 0x2213 IOCCapabilities: 1285c FWVersion= 14-0-0-0 IOCRequestFrameSize: 32 MaxInitiators: 30 MaxTargets: 756 MaxSasExpanders: 224 MaxEnclosures: 224 ProtocolFlags: 3 HighPriorityCredit: 120 MaxReplyDescriptorPostQueueDepth: 65504 ReplyFrameSize: 32 MaxVolumes: 0 MaxDevHandle: 1026 MaxPersistentEntries: 128 mps0: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd mps0: IOCCapabilities: 1285c 1st 16e card: mps1: port 0x7000-0x70ff mem 0xfbff0000-0xfbff3fff,0xfbf80000-0xfbfbffff irq 48 at device 0.0 on pci33 mps1: Doorbell= 0x12000000 mps1: IOCFacts : MsgVersion: 0x200 HeaderVersion: 0x1900 IOCNumber: 0 IOCExceptions: 0x0 MaxChainDepth: 128 WhoInit: ROM BIOS NumberOfPorts: 1 RequestCredit: 32455 ProductID: 0x2213 IOCCapabilities: 1285c FWVersion= 14-0-0-0 IOCRequestFrameSize: 32 MaxInitiators: 32 MaxTargets: 1024 MaxSasExpanders: 128 MaxEnclosures: 129 ProtocolFlags: 3 HighPriorityCredit: 127 MaxReplyDescriptorPostQueueDepth: 65504 ReplyFrameSize: 32 MaxVolumes: 0 MaxDevHandle: 1200 MaxPersistentEntries: 128 mps1: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd mps1: IOCCapabilities: 1285c 2nd 16e card: mps2: port 0x6000-0x60ff mem 0xfbef0000-0xfbef3fff,0xfbe80000-0xfbebffff irq 56 at device 0.0 on pci27 mps2: Doorbell= 0x12000000 mps2: IOCFacts : MsgVersion: 0x200 HeaderVersion: 0x1900 IOCNumber: 0 IOCExceptions: 0x0 MaxChainDepth: 128 WhoInit: ROM BIOS NumberOfPorts: 1 RequestCredit: 32455 ProductID: 0x2213 IOCCapabilities: 1285c FWVersion= 14-0-0-0 IOCRequestFrameSize: 32 MaxInitiators: 32 MaxTargets: 1024 MaxSasExpanders: 128 MaxEnclosures: 129 ProtocolFlags: 3 HighPriorityCredit: 127 MaxReplyDescriptorPostQueueDepth: 65504 ReplyFrameSize: 32 MaxVolumes: 0 MaxDevHandle: 1200 MaxPersistentEntries: 128 mps2: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd mps2: IOCCapabilities: 1285c And here is the entire device listing after running the pair of camcontrol rescan commands. Note, the OS lives on the revodrive. All shelf drives are for data. at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1) at scbus5 target 0 lun 0 (pass2,cd0) at scbus7 target 144 lun 0 (pass3,da0) at scbus7 target 145 lun 0 (pass4,da1) at scbus7 target 146 lun 0 (pass5,da2) at scbus7 target 147 lun 0 (pass6,da3) at scbus7 target 148 lun 0 (pass7,da4) at scbus7 target 149 lun 0 (pass8,da5) at scbus7 target 150 lun 0 (pass9,da6) at scbus7 target 151 lun 0 (pass10,da7) at scbus7 target 152 lun 0 (pass11,da8) at scbus7 target 153 lun 0 (pass12,da9) at scbus7 target 154 lun 0 (pass13,da10) at scbus7 target 155 lun 0 (pass14,da11) at scbus7 target 156 lun 0 (pass15,da12) at scbus7 target 157 lun 0 (pass16,da13) at scbus7 target 158 lun 0 (pass17,da14) at scbus7 target 159 lun 0 (pass18,da15) at scbus7 target 160 lun 0 (pass19,da16) at scbus7 target 161 lun 0 (pass20,da17) at scbus7 target 162 lun 0 (pass21,da18) at scbus7 target 163 lun 0 (pass22,da19) at scbus7 target 164 lun 0 (pass23,da20) at scbus7 target 165 lun 0 (pass24,da21) at scbus7 target 166 lun 0 (pass25,da22) at scbus7 target 167 lun 0 (pass26,da23) at scbus7 target 168 lun 0 (ses0,pass27) at scbus7 target 169 lun 0 (pass28,da24) at scbus7 target 170 lun 0 (pass29,da25) at scbus7 target 171 lun 0 (pass30,da26) at scbus7 target 172 lun 0 (pass31,da27) at scbus7 target 173 lun 0 (pass32,da28) at scbus7 target 174 lun 0 (pass33,da29) at scbus7 target 175 lun 0 (pass34,da30) at scbus7 target 176 lun 0 (pass35,da31) at scbus7 target 177 lun 0 (pass36,da32) at scbus7 target 178 lun 0 (pass37,da33) at scbus7 target 179 lun 0 (pass38,da34) at scbus7 target 180 lun 0 (pass39,da35) at scbus7 target 181 lun 0 (pass40,da36) at scbus7 target 182 lun 0 (pass41,da37) at scbus7 target 183 lun 0 (pass42,da38) at scbus7 target 184 lun 0 (pass43,da39) at scbus7 target 185 lun 0 (pass44,da40) at scbus7 target 186 lun 0 (pass45,da41) at scbus7 target 187 lun 0 (pass46,da42) at scbus7 target 188 lun 0 (pass47,da43) at scbus7 target 189 lun 0 (pass48,da44) at scbus7 target 190 lun 0 (pass49,da45) at scbus7 target 191 lun 0 (pass50,da46) at scbus7 target 192 lun 0 (pass51,da47) at scbus7 target 193 lun 0 (pass52,da48) at scbus7 target 194 lun 0 (ses1,pass53) at scbus7 target 195 lun 0 (pass54,da49) at scbus7 target 196 lun 0 (pass55,da50) at scbus7 target 197 lun 0 (pass56,da51) at scbus7 target 198 lun 0 (pass57,da52) at scbus7 target 199 lun 0 (pass58,da53) at scbus7 target 200 lun 0 (pass59,da54) at scbus7 target 201 lun 0 (pass60,da55) at scbus7 target 202 lun 0 (pass61,da56) at scbus7 target 203 lun 0 (pass62,da57) at scbus7 target 204 lun 0 (pass63,da58) at scbus7 target 205 lun 0 (pass64,da59) at scbus7 target 206 lun 0 (pass65,da60) at scbus7 target 207 lun 0 (pass66,da61) at scbus7 target 208 lun 0 (pass67,da62) at scbus7 target 209 lun 0 (pass68,da63) at scbus7 target 210 lun 0 (pass69,da64) at scbus7 target 211 lun 0 (pass70,da65) at scbus7 target 212 lun 0 (pass71,da66) at scbus7 target 213 lun 0 (pass72,da67) at scbus7 target 214 lun 0 (pass73,da68) at scbus7 target 215 lun 0 (pass74,da69) at scbus7 target 216 lun 0 (pass75,da70) at scbus7 target 217 lun 0 (pass76,da71) at scbus7 target 218 lun 0 (pass77,da72) at scbus7 target 219 lun 0 (ses2,pass78) at scbus7 target 220 lun 0 (pass79,da73) at scbus7 target 221 lun 0 (pass80,da74) at scbus7 target 222 lun 0 (pass81,da75) at scbus7 target 223 lun 0 (pass82,da76) at scbus7 target 224 lun 0 (pass83,da77) at scbus7 target 225 lun 0 (pass84,da78) at scbus7 target 226 lun 0 (pass85,da79) at scbus7 target 227 lun 0 (pass86,da80) at scbus7 target 228 lun 0 (pass87,da81) at scbus7 target 229 lun 0 (pass88,da82) at scbus7 target 230 lun 0 (pass89,da83) at scbus7 target 231 lun 0 (pass90,da84) at scbus7 target 232 lun 0 (pass91,da85) at scbus7 target 233 lun 0 (pass92,da86) at scbus7 target 234 lun 0 (pass93,da87) at scbus7 target 235 lun 0 (pass94,da88) at scbus7 target 236 lun 0 (pass95,da89) at scbus7 target 237 lun 0 (pass96,da90) at scbus7 target 238 lun 0 (pass97,da91) at scbus7 target 239 lun 0 (pass98,da92) at scbus7 target 240 lun 0 (pass99,da93) at scbus7 target 241 lun 0 (pass100,da94) at scbus7 target 242 lun 0 (pass101,da95) at scbus7 target 243 lun 0 (pass102,da96) at scbus7 target 244 lun 0 (pass103,da97) at scbus7 target 245 lun 0 (ses3,pass104) at scbus7 target 246 lun 0 (pass105,da98) at scbus7 target 247 lun 0 (pass106,da99) at scbus7 target 248 lun 0 (pass107,da100) at scbus7 target 249 lun 0 (pass108,da101) at scbus7 target 250 lun 0 (pass109,da102) at scbus7 target 251 lun 0 (pass110,da103) at scbus7 target 252 lun 0 (pass111,da104) at scbus7 target 253 lun 0 (pass112,da105) at scbus7 target 254 lun 0 (pass113,da106) at scbus7 target 255 lun 0 (da390,pass409) at scbus7 target 256 lun 0 (pass114,da107) at scbus7 target 257 lun 0 (pass115,da108) at scbus7 target 258 lun 0 (pass116,da109) at scbus7 target 259 lun 0 (pass117,da110) at scbus7 target 260 lun 0 (pass118,da111) at scbus7 target 261 lun 0 (pass119,da112) at scbus7 target 262 lun 0 (pass120,da113) at scbus7 target 263 lun 0 (pass121,da114) at scbus7 target 264 lun 0 (pass122,da115) at scbus7 target 265 lun 0 (pass123,da116) at scbus7 target 266 lun 0 (pass124,da117) at scbus7 target 267 lun 0 (pass125,da118) at scbus7 target 268 lun 0 (pass126,da119) at scbus7 target 269 lun 0 (pass127,da120) at scbus7 target 270 lun 0 (ses4,pass128) at scbus7 target 271 lun 0 (pass129,da121) at scbus7 target 272 lun 0 (pass130,da122) at scbus7 target 273 lun 0 (pass131,da123) at scbus7 target 274 lun 0 (pass132,da124) at scbus7 target 275 lun 0 (pass133,da125) at scbus7 target 276 lun 0 (pass134,da126) at scbus7 target 277 lun 0 (pass135,da127) at scbus7 target 278 lun 0 (pass136,da128) at scbus7 target 279 lun 0 (pass137,da129) at scbus7 target 280 lun 0 (pass138,da130) at scbus7 target 281 lun 0 (pass139,da131) at scbus7 target 282 lun 0 (pass140,da132) at scbus7 target 283 lun 0 (pass141,da133) at scbus7 target 284 lun 0 (pass142,da134) at scbus7 target 285 lun 0 (pass143,da135) at scbus7 target 286 lun 0 (pass144,da136) at scbus7 target 287 lun 0 (pass145,da137) at scbus7 target 288 lun 0 (pass146,da138) at scbus7 target 289 lun 0 (pass147,da139) at scbus7 target 290 lun 0 (pass148,da140) at scbus7 target 291 lun 0 (pass149,da141) at scbus7 target 292 lun 0 (pass150,da142) at scbus7 target 293 lun 0 (pass151,da143) at scbus7 target 294 lun 0 (pass152,da144) at scbus7 target 295 lun 0 (pass153,da145) at scbus7 target 296 lun 0 (ses5,pass154) at scbus7 target 297 lun 0 (pass155,da146) at scbus7 target 298 lun 0 (pass156,da147) at scbus7 target 299 lun 0 (pass157,da148) at scbus7 target 300 lun 0 (pass158,da149) at scbus7 target 301 lun 0 (pass159,da150) at scbus7 target 302 lun 0 (pass160,da151) at scbus7 target 303 lun 0 (pass161,da152) at scbus7 target 304 lun 0 (pass162,da153) at scbus7 target 305 lun 0 (pass163,da154) at scbus7 target 306 lun 0 (pass164,da155) at scbus7 target 307 lun 0 (pass165,da156) at scbus7 target 308 lun 0 (pass166,da157) at scbus7 target 309 lun 0 (pass167,da158) at scbus7 target 310 lun 0 (pass168,da159) at scbus7 target 311 lun 0 (pass169,da160) at scbus7 target 312 lun 0 (pass170,da161) at scbus7 target 313 lun 0 (pass171,da162) at scbus7 target 314 lun 0 (pass172,da163) at scbus7 target 315 lun 0 (pass173,da164) at scbus7 target 316 lun 0 (pass174,da165) at scbus7 target 317 lun 0 (pass175,da166) at scbus7 target 318 lun 0 (pass176,da167) at scbus7 target 319 lun 0 (pass177,da168) at scbus7 target 320 lun 0 (pass178,da169) at scbus7 target 321 lun 0 (ses6,pass179) at scbus7 target 322 lun 0 (pass180,da170) at scbus7 target 323 lun 0 (pass181,da171) at scbus7 target 324 lun 0 (pass182,da172) at scbus7 target 325 lun 0 (pass183,da173) at scbus7 target 326 lun 0 (pass184,da174) at scbus7 target 327 lun 0 (pass185,da175) at scbus7 target 328 lun 0 (pass186,da176) at scbus7 target 329 lun 0 (pass187,da177) at scbus7 target 330 lun 0 (pass188,da178) at scbus7 target 331 lun 0 (pass189,da179) at scbus7 target 332 lun 0 (pass190,da180) at scbus7 target 333 lun 0 (pass191,da181) at scbus7 target 334 lun 0 (pass192,da182) at scbus7 target 335 lun 0 (pass193,da183) at scbus7 target 336 lun 0 (pass194,da184) at scbus7 target 337 lun 0 (pass195,da185) at scbus7 target 338 lun 0 (pass196,da186) at scbus7 target 339 lun 0 (pass197,da187) at scbus7 target 340 lun 0 (pass198,da188) at scbus7 target 341 lun 0 (pass199,da189) at scbus7 target 342 lun 0 (pass200,da190) at scbus7 target 343 lun 0 (pass201,da191) at scbus7 target 344 lun 0 (pass202,da192) at scbus7 target 345 lun 0 (pass203,da193) at scbus7 target 346 lun 0 (pass204,da194) at scbus7 target 347 lun 0 (ses7,pass205) at scbus8 target 144 lun 0 (pass206,da195) at scbus8 target 145 lun 0 (pass207,da196) at scbus8 target 146 lun 0 (pass208,da197) at scbus8 target 147 lun 0 (pass209,da198) at scbus8 target 148 lun 0 (pass210,da199) at scbus8 target 149 lun 0 (pass211,da200) at scbus8 target 150 lun 0 (pass212,da201) at scbus8 target 151 lun 0 (pass213,da202) at scbus8 target 152 lun 0 (pass214,da203) at scbus8 target 153 lun 0 (pass215,da204) at scbus8 target 154 lun 0 (pass216,da205) at scbus8 target 155 lun 0 (pass217,da206) at scbus8 target 156 lun 0 (pass218,da207) at scbus8 target 157 lun 0 (pass219,da208) at scbus8 target 158 lun 0 (pass220,da209) at scbus8 target 159 lun 0 (pass221,da210) at scbus8 target 160 lun 0 (pass222,da211) at scbus8 target 161 lun 0 (pass223,da212) at scbus8 target 162 lun 0 (pass224,da213) at scbus8 target 163 lun 0 (pass225,da214) at scbus8 target 164 lun 0 (pass226,da215) at scbus8 target 165 lun 0 (pass227,da216) at scbus8 target 166 lun 0 (pass228,da217) at scbus8 target 167 lun 0 (pass229,da218) at scbus8 target 168 lun 0 (ses8,pass230) at scbus8 target 169 lun 0 (pass231,da219) at scbus8 target 170 lun 0 (pass232,da220) at scbus8 target 171 lun 0 (pass233,da221) at scbus8 target 172 lun 0 (pass234,da222) at scbus8 target 173 lun 0 (pass235,da223) at scbus8 target 174 lun 0 (pass236,da224) at scbus8 target 175 lun 0 (pass237,da225) at scbus8 target 176 lun 0 (pass238,da226) at scbus8 target 177 lun 0 (pass239,da227) at scbus8 target 178 lun 0 (pass240,da228) at scbus8 target 179 lun 0 (pass241,da229) at scbus8 target 180 lun 0 (pass242,da230) at scbus8 target 181 lun 0 (pass243,da231) at scbus8 target 182 lun 0 (pass244,da232) at scbus8 target 183 lun 0 (pass245,da233) at scbus8 target 184 lun 0 (pass246,da234) at scbus8 target 185 lun 0 (pass247,da235) at scbus8 target 186 lun 0 (pass248,da236) at scbus8 target 187 lun 0 (pass249,da237) at scbus8 target 188 lun 0 (pass250,da238) at scbus8 target 189 lun 0 (pass251,da239) at scbus8 target 190 lun 0 (pass252,da240) at scbus8 target 191 lun 0 (pass253,da241) at scbus8 target 192 lun 0 (pass254,da242) at scbus8 target 193 lun 0 (pass255,da243) at scbus8 target 194 lun 0 (ses9,pass256) at scbus8 target 195 lun 0 (pass257,da244) at scbus8 target 196 lun 0 (pass258,da245) at scbus8 target 197 lun 0 (pass259,da246) at scbus8 target 198 lun 0 (pass260,da247) at scbus8 target 199 lun 0 (pass261,da248) at scbus8 target 200 lun 0 (pass262,da249) at scbus8 target 201 lun 0 (pass263,da250) at scbus8 target 202 lun 0 (pass264,da251) at scbus8 target 203 lun 0 (pass265,da252) at scbus8 target 204 lun 0 (pass266,da253) at scbus8 target 205 lun 0 (pass267,da254) at scbus8 target 206 lun 0 (pass268,da255) at scbus8 target 207 lun 0 (pass269,da256) at scbus8 target 208 lun 0 (pass270,da257) at scbus8 target 209 lun 0 (pass271,da258) at scbus8 target 210 lun 0 (pass272,da259) at scbus8 target 211 lun 0 (pass273,da260) at scbus8 target 212 lun 0 (pass274,da261) at scbus8 target 213 lun 0 (pass275,da262) at scbus8 target 214 lun 0 (pass276,da263) at scbus8 target 215 lun 0 (pass277,da264) at scbus8 target 216 lun 0 (pass278,da265) at scbus8 target 217 lun 0 (pass279,da266) at scbus8 target 218 lun 0 (pass280,da267) at scbus8 target 219 lun 0 (ses10,pass281) at scbus8 target 220 lun 0 (pass282,da268) at scbus8 target 221 lun 0 (pass283,da269) at scbus8 target 222 lun 0 (pass284,da270) at scbus8 target 223 lun 0 (pass285,da271) at scbus8 target 224 lun 0 (pass286,da272) at scbus8 target 225 lun 0 (pass287,da273) at scbus8 target 226 lun 0 (pass288,da274) at scbus8 target 227 lun 0 (pass289,da275) at scbus8 target 228 lun 0 (pass290,da276) at scbus8 target 229 lun 0 (pass291,da277) at scbus8 target 230 lun 0 (pass292,da278) at scbus8 target 231 lun 0 (pass293,da279) at scbus8 target 232 lun 0 (pass294,da280) at scbus8 target 233 lun 0 (pass295,da281) at scbus8 target 234 lun 0 (pass296,da282) at scbus8 target 235 lun 0 (pass297,da283) at scbus8 target 236 lun 0 (pass298,da284) at scbus8 target 237 lun 0 (pass299,da285) at scbus8 target 238 lun 0 (pass300,da286) at scbus8 target 239 lun 0 (pass301,da287) at scbus8 target 240 lun 0 (pass302,da288) at scbus8 target 241 lun 0 (pass303,da289) at scbus8 target 242 lun 0 (pass304,da290) at scbus8 target 243 lun 0 (pass305,da291) at scbus8 target 244 lun 0 (pass306,da292) at scbus8 target 245 lun 0 (ses11,pass307) at scbus8 target 246 lun 0 (pass308,da293) at scbus8 target 247 lun 0 (pass309,da294) at scbus8 target 248 lun 0 (pass310,da295) at scbus8 target 249 lun 0 (pass311,da296) at scbus8 target 250 lun 0 (pass312,da297) at scbus8 target 251 lun 0 (pass313,da298) at scbus8 target 252 lun 0 (pass314,da299) at scbus8 target 253 lun 0 (pass315,da300) at scbus8 target 254 lun 0 (pass316,da301) at scbus8 target 255 lun 0 (da391,pass410) at scbus8 target 256 lun 0 (pass317,da302) at scbus8 target 257 lun 0 (pass318,da303) at scbus8 target 258 lun 0 (pass319,da304) at scbus8 target 259 lun 0 (pass320,da305) at scbus8 target 260 lun 0 (pass321,da306) at scbus8 target 261 lun 0 (pass322,da307) at scbus8 target 262 lun 0 (pass323,da308) at scbus8 target 263 lun 0 (pass324,da309) at scbus8 target 264 lun 0 (pass325,da310) at scbus8 target 265 lun 0 (pass326,da311) at scbus8 target 266 lun 0 (pass327,da312) at scbus8 target 267 lun 0 (pass328,da313) at scbus8 target 268 lun 0 (pass329,da314) at scbus8 target 269 lun 0 (pass330,da315) at scbus8 target 270 lun 0 (ses12,pass331) at scbus8 target 271 lun 0 (pass332,da316) at scbus8 target 272 lun 0 (pass333,da317) at scbus8 target 273 lun 0 (pass334,da318) at scbus8 target 274 lun 0 (pass335,da319) at scbus8 target 275 lun 0 (pass336,da320) at scbus8 target 276 lun 0 (pass337,da321) at scbus8 target 277 lun 0 (pass338,da322) at scbus8 target 278 lun 0 (pass339,da323) at scbus8 target 279 lun 0 (pass340,da324) at scbus8 target 280 lun 0 (pass341,da325) at scbus8 target 281 lun 0 (pass342,da326) at scbus8 target 282 lun 0 (pass343,da327) at scbus8 target 283 lun 0 (pass344,da328) at scbus8 target 284 lun 0 (pass345,da329) at scbus8 target 285 lun 0 (pass346,da330) at scbus8 target 286 lun 0 (pass347,da331) at scbus8 target 287 lun 0 (pass348,da332) at scbus8 target 288 lun 0 (pass349,da333) at scbus8 target 289 lun 0 (pass350,da334) at scbus8 target 290 lun 0 (pass351,da335) at scbus8 target 291 lun 0 (pass352,da336) at scbus8 target 292 lun 0 (pass353,da337) at scbus8 target 293 lun 0 (pass354,da338) at scbus8 target 294 lun 0 (pass355,da339) at scbus8 target 295 lun 0 (pass356,da340) at scbus8 target 296 lun 0 (ses13,pass357) at scbus8 target 297 lun 0 (pass358,da341) at scbus8 target 298 lun 0 (pass359,da342) at scbus8 target 299 lun 0 (pass360,da343) at scbus8 target 300 lun 0 (pass361,da344) at scbus8 target 301 lun 0 (pass362,da345) at scbus8 target 302 lun 0 (pass363,da346) at scbus8 target 303 lun 0 (pass364,da347) at scbus8 target 304 lun 0 (pass365,da348) at scbus8 target 305 lun 0 (pass366,da349) at scbus8 target 306 lun 0 (pass367,da350) at scbus8 target 307 lun 0 (pass368,da351) at scbus8 target 308 lun 0 (pass369,da352) at scbus8 target 309 lun 0 (pass370,da353) at scbus8 target 310 lun 0 (pass371,da354) at scbus8 target 311 lun 0 (pass372,da355) at scbus8 target 312 lun 0 (pass373,da356) at scbus8 target 313 lun 0 (pass374,da357) at scbus8 target 314 lun 0 (pass375,da358) at scbus8 target 315 lun 0 (pass376,da359) at scbus8 target 316 lun 0 (pass377,da360) at scbus8 target 317 lun 0 (pass378,da361) at scbus8 target 318 lun 0 (pass379,da362) at scbus8 target 319 lun 0 (pass380,da363) at scbus8 target 320 lun 0 (pass381,da364) at scbus8 target 321 lun 0 (ses14,pass382) at scbus8 target 322 lun 0 (pass383,da365) at scbus8 target 323 lun 0 (pass384,da366) at scbus8 target 324 lun 0 (pass385,da367) at scbus8 target 325 lun 0 (pass386,da368) at scbus8 target 326 lun 0 (pass387,da369) at scbus8 target 327 lun 0 (pass388,da370) at scbus8 target 328 lun 0 (pass389,da371) at scbus8 target 329 lun 0 (pass390,da372) at scbus8 target 330 lun 0 (pass391,da373) at scbus8 target 331 lun 0 (pass392,da374) at scbus8 target 332 lun 0 (pass393,da375) at scbus8 target 333 lun 0 (pass394,da376) at scbus8 target 334 lun 0 (pass395,da377) at scbus8 target 335 lun 0 (pass396,da378) at scbus8 target 336 lun 0 (pass397,da379) at scbus8 target 337 lun 0 (pass398,da380) at scbus8 target 338 lun 0 (pass399,da381) at scbus8 target 339 lun 0 (pass400,da382) at scbus8 target 340 lun 0 (pass401,da383) at scbus8 target 341 lun 0 (pass402,da384) at scbus8 target 342 lun 0 (pass403,da385) at scbus8 target 343 lun 0 (pass404,da386) at scbus8 target 344 lun 0 (pass405,da387) at scbus8 target 345 lun 0 (pass406,da388) at scbus8 target 346 lun 0 (pass407,da389) at scbus8 target 347 lun 0 (ses15,pass408) From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 17 08:14:34 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736441065670 for ; Mon, 17 Sep 2012 08:14:34 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03.sare.net (proxypop03.sare.net [194.30.0.207]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6FA8FC15 for ; Mon, 17 Sep 2012 08:14:33 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 5439A9DC631; Mon, 17 Sep 2012 10:07:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20120914164603.GA34637@mikea.ath.cx> Date: Mon, 17 Sep 2012 10:08:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120827203817.GB44988@mikea.ath.cx> <201208281238.48041.jhb@freebsd.org> <20120828210618.GD69985@mikea.ath.cx> <201208290818.20990.jhb@freebsd.org> <20120914164603.GA34637@mikea.ath.cx> To: Mike A X-Mailer: Apple Mail (2.1084) Cc: freebsd-scsi@freebsd.org Subject: Re: Bug Report: IBM x3650M4 (32GB, 2x4-core Xeon E5-2600, IBM ServeRaid M5110e): fails in install with NMI X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 08:14:34 -0000 On Sep 14, 2012, at 6:46 PM, Mike A wrote: > All the stars finally moved to the right places, and I was able to try = booting > from a 9.1 amd64 memstick made from = FreeBSD-9.1-RC1-amd64-memstick.img. That > failed, both without and with boot loader hints.=20 >=20 > I had a movie camera running to catch the console message traffic. The = last > normal messages on the screen have to do with device mfi0. Here is the = last > screenfull:=20 I had a similar issue on a Dell R720 with 9.0-RELEASE. Turns out it was = a problem with the built-in RAID card. Currently there seems to be some sort of overlap or confusion between = the mpt, mps and in your case mfi driver? In my case, the card was assigned the mpt driver on 9.0-RELEASE, only to = crash with a NMI. With 9.1RC, however, the system assigned the mfi driver and it worked. If I recall _correctly_, the mps driver seems to be better for some = disk controllers that were handled by mfi. I would try to compile a system without the mfi driver and see if either mpt or mps = take over and work. It's a long shot, I know,=20 but... Borja. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 17 11:07:15 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 054151065680 for ; Mon, 17 Sep 2012 11:07:15 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E2C0F8FC1E for ; Mon, 17 Sep 2012 11:07:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8HB7E35004567 for ; Mon, 17 Sep 2012 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8HB7EE8004565 for freebsd-scsi@FreeBSD.org; Mon, 17 Sep 2012 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Sep 2012 11:07:14 GMT Message-Id: <201209171107.q8HB7EE8004565@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 11:07:15 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/169976 scsi [cam] [patch] make scsi_da use sysctl values where app o kern/169974 scsi [cam] [patch] add Quirks for SSD that are 4k optimised o kern/169835 scsi [patch] remove some unused variables from scsi_da prob o kern/169801 scsi [cam] [patc] make changes to delete_method in scsi_da o kern/169403 scsi [cam] [patch] CAM layer, I/O starvation, no fairness o kern/165982 scsi [mpt] mpt instability, drive resets, and losses on Fre o kern/165740 scsi [cam] SCSI code must drain callbacks before free o kern/163713 scsi [aic7xxx] [patch] Add Adaptec29329LPE to aic79xx_pci.c o kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o kern/161809 scsi [cam] [patch] set kern.cam.boot_delay via build option o kern/159412 scsi [ciss] 7.3 RELEASE: ciss0 ADAPTER HEARTBEAT FAILED err o kern/157770 scsi [iscsi] [panic] iscsi_initiator panic o kern/154432 scsi [xpt] run_interrupt_driven_hooks: still waiting after o kern/153514 scsi [cam] [panic] CAM related panic o kern/153361 scsi [ciss] Smart Array 5300 boot/detect drive problem o kern/152250 scsi [ciss] [patch] Kernel panic when hw.ciss.expose_hidden o kern/151564 scsi [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 10 o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c s kern/149927 scsi [cam] hard drive not stopped before removing power dur o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/123674 scsi [ahc] ahc driver dumping o kern/123520 scsi [ahd] unable to boot from net while using ahd o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 55 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 17 13:03:18 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A38771065670 for ; Mon, 17 Sep 2012 13:03:18 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [71.252.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 59FCE8FC08 for ; Mon, 17 Sep 2012 13:03:18 +0000 (UTC) Received: from ASSP.nospam (localhost [127.0.0.1]) by tethys.ringofsaturn.com (8.14.5/8.14.5) with ESMTP id q8HD3HUu089625; Mon, 17 Sep 2012 08:03:17 -0500 (CDT) (envelope-from aoyama@peach.ne.jp) X-Assp-Version: 1.9.3.7(1.0.01) on ASSP.nospam X-Assp-Delay: rnejdl@ringofsaturn.com was delayed for 38m 30s; 11 Aug 2012 17:01:06 -0500 X-Assp-Message-Score: 15 (Bad IP History for 69.147.83.53) X-Assp-Envelope-From: owner-freebsd-emulation@freebsd.org To: X-Assp-ID: ASSP.nospam m-34472-14219 X-Assp-Original-Subject: iSCSI LUN extents with VirtualDisk (VDI, VHD, VMDK) for istgt X-Assp-Spam-Reason: rejected by personal blacklist: '*,freebsd-emulation-request@freebsd.org' X-Assp-Message-Totalscore: 15 Received: from mx2.freebsd.org ([69.147.83.53] helo=mx2.freebsd.org) by ASSP.nospam with ESMTP (ASSP 1.9); 11 Aug 2012 17:01:05 -0500 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0C00C15168E; Sat, 11 Aug 2012 21:12:16 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4F3BD1065696; Sat, 11 Aug 2012 21:12:14 +0000 (UTC) (envelope-from owner-freebsd-emulation@freebsd.org) Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A9E4106564A; Sat, 11 Aug 2012 21:12:07 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id BC4A08FC0C; Sat, 11 Aug 2012 21:12:05 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 516D139E11; Sun, 12 Aug 2012 06:12:04 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 37A5039E00; Sun, 12 Aug 2012 06:12:04 +0900 (JST) Message-ID: <9307C6DE2E184FCB88B2CE33CA479EDB@ad.peach.ne.jp> From: "Daisuke Aoyama" MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-emulation@freebsd.org Errors-To: owner-freebsd-emulation@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: iSCSI LUN extents with VirtualDisk (VDI, VHD, VMDK) for istgt X-BeenThere: freebsd-scsi@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 17 Sep 2012 13:03:18 -0000 X-Original-Date: Sun, 12 Aug 2012 06:11:33 +0900 X-List-Received-Date: Mon, 17 Sep 2012 13:03:18 -0000 Hi, I have released istgt-20120811 which supports VirtualBox's VirtualDisk via VBoxDDU.so. If you don't want VBox VD features, you can build it without using --with-vbox. How to build with VBox support: Install VirtualBox 4, and extract the source of same version of it. /usr/local/src/virtualbox/*/include is default location of header. (e.g. /usr/local/src/virtualbox/VirtualBox-4.1.18/include/VBox/vd.h) If you want to extract to other place, you need specify by --with-vbox=PATH. # ./counfigure --with-vbox or # ./counfigure --with-vbox=/home/vboxsrc/VirtualBox-4.1.18/include Required shared libraries are VBoxDDU.so and VBoxRT.so located in /usr/local/lib/virtualbox. You may change this place by --with-vboxlib, but I don't test. Note: FreeBSD platform, configure use the path if exist: /usr/ports/emulators/virtualbox-ose/work /usr/ports/emulators/virtualbox-ose-legacy/work FreeBSD ports version can handle it by VBOXVD option. Both using X11 and starting VBox are unnecessary for istgt. FreeBSD 7.x users can use it with ports/emulators/virtualbox-ose-legacy. Currently it supports read/write only. Other operation such as creation, snapshot, resize are not supported. How to use: Specify with appropriate extension to LUN of LogicalUnit section. It is recommend that you use "Auto" for the size field to prevent creation. The istgt does not support creation of VDs, you need create the VD before starting istgt. example(one of): LUN0 Storage /iscsi/istgt-disk.vdi Auto LUN0 Storage /iscsi/istgt-disk.vhd Auto LUN0 Storage /iscsi/istgt-disk.vmdk Auto How to create Virtual Disk: You can use any size of capacity supported by the VD. But istgt assumes it has fixed 512bytes/block. example(one of): # VBoxManage createhd --filename /iscsi/istgt-disk --size 10240 --format VDI # VBoxManage createhd --filename /iscsi/istgt-disk --size 10240 --format VHD # VBoxManage createhd --filename /iscsi/istgt-disk --size 10240 --format VMDK For more detail written in Japanese: http://shell.peach.ne.jp/aoyama/archives/2088 Regards, Daisuke Aoyama _______________________________________________ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 19 20:07:56 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35C64106564A for ; Wed, 19 Sep 2012 20:07:56 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id 021C08FC0A for ; Wed, 19 Sep 2012 20:07:55 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtp (Exim 4.76) (envelope-from ) id 1TEQYm-00078l-Rl for freebsd-scsi@freebsd.org; Wed, 19 Sep 2012 16:07:48 -0400 Message-ID: <505A2614.2000709@cse.yorku.ca> Date: Wed, 19 Sep 2012 16:07:48 -0400 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.7) Gecko/20120824 Thunderbird/10.0.7 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: I have a Dell R720 and a 24 x 2.5" Dell MD1220 JBOD. I have added dual LSI 9205-8e, each connected to the same MD1220 array. Under FreeBSD 9.0, if I do a "camcontrol devlist" (with every other disk removed), I see: [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Subject: mps target difference between FreeBSD 9 and 9.1 RC X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 20:07:56 -0000 I have a Dell R720 and a 24 x 2.5" Dell MD1220 JBOD. I have added dual LSI 9205-8e, each connected to the same MD1220 array. Under FreeBSD 9.0, if I do a "camcontrol devlist" (with every other disk removed), I see: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 2 lun 0 (pass1,da1) at scbus0 target 4 lun 0 (pass2,da2) at scbus0 target 6 lun 0 (pass3,da3) at scbus0 target 8 lun 0 (pass4,da4) at scbus0 target 10 lun 0 (pass5,da5) at scbus0 target 36 lun 0 (pass6,ses0) at scbus1 target 12 lun 0 (pass7,da6) at scbus1 target 14 lun 0 (pass8,da7) at scbus1 target 16 lun 0 (pass9,da8) at scbus1 target 18 lun 0 (pass10,da9) at scbus1 target 21 lun 0 (pass11,da10) at scbus1 target 22 lun 0 (pass12,da11) at scbus1 target 36 lun 0 (pass13,ses1) at scbus6 target 0 lun 0 (pass14,cd0) ... which is what I would expect. If I do the same thing with any pre-release/RC version of 9.1, I see: at scbus0 target 34 lun 0 (pass0,da0) at scbus0 target 36 lun 0 (pass1,da1) at scbus0 target 38 lun 0 (pass2,da2) at scbus0 target 39 lun 0 (pass3,da3) at scbus0 target 41 lun 0 (pass4,da4) at scbus0 target 43 lun 0 (pass5,da5) at scbus0 target 45 lun 0 (ses0,pass6) at scbus1 target 21 lun 0 (pass7,da6) at scbus1 target 23 lun 0 (pass8,da7) at scbus1 target 24 lun 0 (pass9,da8) at scbus1 target 26 lun 0 (pass10,da9) at scbus1 target 29 lun 0 (pass11,da10) at scbus1 target 31 lun 0 (pass12,da11) at scbus1 target 32 lun 0 (ses1,pass13) at scbus6 target 0 lun 0 (pass14,cd0) In particular, note how the targets are starting at 34. I wonder if someone might explain why? I was considering using /boot/device.hints to hard-code the daX mapping to avoid the use of "labels" for my volumes, but I wouldn't expect the targets to change between the two releases. Thanks for any information that you can provide.. Jason. From owner-freebsd-scsi@FreeBSD.ORG Sat Sep 22 02:10:09 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id A8E85106567C; Sat, 22 Sep 2012 02:10:09 +0000 (UTC) Date: Sat, 22 Sep 2012 02:10:09 +0000 From: John To: FreeBSD-scsi Message-ID: <20120922021009.GA86891@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: camcontrol inquiry xpt0 ? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 02:10:09 -0000 Hi Folks, I'm trying to understand how some code in the mps driver works, specifically sys/dev/mps/mps_sas.c: static void mpssas_action(struct cam_sim *sim, union ccb *ccb) { struct mpssas_softc *sassc; sassc = cam_sim_softc(sim); mps_dprint(sassc->sc, MPS_TRACE, "%s func 0x%x\n", __func__, ccb->ccb_h.func_code); mtx_assert(&sassc->sc->mps_mtx, MA_OWNED); switch (ccb->ccb_h.func_code) { case XPT_PATH_INQ: { In trying to cause the the XPT_PATH_INQ case to execute, I was playing around with the pass driver and xpt: camcontrol inquiry xpt0 and received the following: camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or xpt0 doesn't exist However, pass is in the kernel, and /dev/xpt0 exists: # ls -al /dev/xpt0 crw------- 1 root operator 0, 81 Sep 20 08:05 /dev/xpt0 And for instance: # camcontrol inquiry pass22 pass22: Fixed Direct Access SCSI-5 device pass22: Serial Number 6XR15VLY0000M149G7XX pass22: 600.000MB/s transfers, Command Queueing Enabled I'm trying figure out if the code above setting itself as device id 255 is related to my system not being able to scan the disk device at id 255. Am I doing something wrong? Any ideas? FreeBSD 9.1-PRERELEASE #0: Thanks! John From owner-freebsd-scsi@FreeBSD.ORG Sat Sep 22 02:19:45 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC278106566B for ; Sat, 22 Sep 2012 02:19:45 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE1E8FC19 for ; Sat, 22 Sep 2012 02:19:45 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so9605414pbb.13 for ; Fri, 21 Sep 2012 19:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=P53eBIYtbKjB3YP7tb4t/t8Aafz5n5MwU3oTHiTZevY=; b=JqTJOqeVU1a9kcO/5AWTfdAM4szctImMOteLAkbGZRSPiLNS2o+YdNm1gUFfpXEatY EjTceFgrkomJAInGA+pdEzsny+hUZZ/uCdJ/NuzCQhWj4kALfsheZh4WrBO8Niizt8IA 1KrnHt6HecRiabHMxtFEbIjrf1svuUKmfds22zbp3soQE28dkulzvUXRkrfDSrr6FquJ ppovbtmFhuPc+PgltPBAUMHqFnRYRL4T7pw5g2L5DQGEyhvKGPGpyiNqi9+22ir2mR1A yzKMzZz2HCWywMRT5YAjQFJSmLmWapgVZWn7J4fEt+04JOB1rVd8IqSgDfSAPf4vIEkN FQ4A== Received: by 10.68.234.71 with SMTP id uc7mr9107056pbc.72.1348280385288; Fri, 21 Sep 2012 19:19:45 -0700 (PDT) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id i1sm4972186pay.26.2012.09.21.19.19.43 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 19:19:44 -0700 (PDT) Message-ID: <505D2037.1040107@gmail.com> Date: Fri, 21 Sep 2012 19:19:35 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: mfi link speed? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 02:19:45 -0000 There may be an obvious answer, but how do I determine whether or not SATA III drives are negotiating at full speed on an m1015? When I used the mps firmware for this card, I did indeed see correct link speeds as the da devices attached. I have mfip loaded, but its devices seem to be hardcoded to present with 150MB/s transfers. If it matters, I'm using "real" JBOD with mfisyspd devices. Also, can I tell if disk cache is enabled? Thanks! Matt From owner-freebsd-scsi@FreeBSD.ORG Sat Sep 22 02:49:46 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B77A106564A; Sat, 22 Sep 2012 02:49:46 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 21C778FC08; Sat, 22 Sep 2012 02:49:45 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so5963191vcb.13 for ; Fri, 21 Sep 2012 19:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sIruuyLqI66XqEmQi0KKfZ9dpRG1B2g9pAD8rQIpn6g=; b=ogVnp0bnJKo5Gt6rchTNny7nvxx3yqVnxld5JgnZo+x18tXKaRzkNDSCysu5rVyrE1 Pfa2DERcEvAbiLhPUAh25wzzhH5huFsh0/bPFvGp7O/gYYKvF+0U9a4CJo8Z1n2UAVoM vJ9aXqliHmbJZvDXh1NMes72zVoYMHCHXl27uaXMhygQDuP52O2mcAXC5D5IINnnCcYF ZWMOAWUytdM/rnOi8F5Yc7HPUEPMMwcJueoN/Owqxk8zEUFBPU2akvWqAA0aIObxnxJH 1GXCdUpCBzHwL0DDg0RcP+yH1zGlWSJlVJyijJzSIFQy0hvAi0fK2oc7xTpgKiardqe5 6+gQ== MIME-Version: 1.0 Received: by 10.221.13.202 with SMTP id pn10mr3976811vcb.57.1348282185183; Fri, 21 Sep 2012 19:49:45 -0700 (PDT) Sender: jim.harris@gmail.com Received: by 10.58.249.135 with HTTP; Fri, 21 Sep 2012 19:49:45 -0700 (PDT) In-Reply-To: <20120922021009.GA86891@FreeBSD.org> References: <20120922021009.GA86891@FreeBSD.org> Date: Fri, 21 Sep 2012 19:49:45 -0700 X-Google-Sender-Auth: xIj0m-1dqF6GKBGz_s5iw02R-js Message-ID: From: Jim Harris To: John Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-scsi Subject: Re: camcontrol inquiry xpt0 ? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 02:49:46 -0000 On Fri, Sep 21, 2012 at 7:10 PM, John wrote: > Hi Folks, > > I'm trying to understand how some code in the mps driver works, > specifically sys/dev/mps/mps_sas.c: > > static void > mpssas_action(struct cam_sim *sim, union ccb *ccb) > { > struct mpssas_softc *sassc; > > sassc = cam_sim_softc(sim); > > mps_dprint(sassc->sc, MPS_TRACE, "%s func 0x%x\n", __func__, > ccb->ccb_h.func_code); > mtx_assert(&sassc->sc->mps_mtx, MA_OWNED); > > switch (ccb->ccb_h.func_code) { > case XPT_PATH_INQ: > { > > > In trying to cause the the XPT_PATH_INQ case to execute, I was > playing around with the pass driver and xpt: > > camcontrol inquiry xpt0 > > and received the following: > > camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed > cam_lookup_pass: No such file or directory > cam_lookup_pass: either the pass driver isn't in your kernel > cam_lookup_pass: or xpt0 doesn't exist > > However, pass is in the kernel, and /dev/xpt0 exists: > > # ls -al /dev/xpt0 > crw------- 1 root operator 0, 81 Sep 20 08:05 /dev/xpt0 > > And for instance: > > # camcontrol inquiry pass22 > pass22: Fixed Direct Access SCSI-5 device > pass22: Serial Number 6XR15VLY0000M149G7XX > pass22: 600.000MB/s transfers, Command Queueing Enabled > > > I'm trying figure out if the code above setting itself as > device id 255 is related to my system not being able to scan > the disk device at id 255. > > Am I doing something wrong? Any ideas? The names are similar, but XPT_PATH_INQ isn't actually associated at all with a SCSI INQUIRY command. XPT_PATH_INQ is the first CCB sent to the driver, so that CAM can get the basic characteristics of the SIM to proceed with enumeration. SCSI INQUIRY commands come into the SIM driver through the XPT_SCSI_IO opcode. xpt0 isn't a SCSI device, which is why camcontrol is showing the error messages you're seeing. I think "camcontrol negotiate" is a way to invoke the XPT_PATH_INQ code path after the controller has initialized, but I haven't tried this myself. -Jim The code path you are looking at gets invoked during controller initialization. > FreeBSD 9.1-PRERELEASE #0: > > Thanks! > John > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Sat Sep 22 16:12:11 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97F2E106564A; Sat, 22 Sep 2012 16:12:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 925D78FC12; Sat, 22 Sep 2012 16:12:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07359; Sat, 22 Sep 2012 19:12:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TFSJM-000NSn-Q7; Sat, 22 Sep 2012 19:12:08 +0300 Message-ID: <505DE358.8050304@FreeBSD.org> Date: Sat, 22 Sep 2012 19:12:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: ata_da: allow to force standby mode after idle period X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 16:12:11 -0000 I have a disk that obeys idle/standby timeout only once. The disk goes into standby the first time the timeout expires, but when it is waken up it acts as if no timeout is set. I modeled the following patch after a similar change made to ad(4) by phk a long time ago. I think that patch might be good to have for some, but I won't be insisting on it getting into the tree. commit 8df792704c7181d3448d47b72efd9f77d2e091ff Author: Andriy Gapon Date: Sat Jun 9 13:03:48 2012 +0300 ata_da: allow to force standby mode after idle period ... for disks that do not enter the mode via internal timer diff --git a/sys/cam/ata/ata_da.c b/sys/cam/ata/ata_da.c index 92ed0c6..1c5e2c3 100644 --- a/sys/cam/ata/ata_da.c +++ b/sys/cam/ata/ata_da.c @@ -136,6 +136,7 @@ struct ada_softc { int trim_running; int read_ahead; int write_cache; + int spindown; #ifdef ADA_TEST_FAILURE int force_read_error; int force_write_error; @@ -149,6 +150,7 @@ struct ada_softc { struct sysctl_oid *sysctl_tree; struct callout sendordered_c; struct trim_request trim_req; + struct callout spindown_timer; }; struct ada_quirk_entry { @@ -298,6 +300,7 @@ static timeout_t adasendorderedtag; static void adashutdown(void *arg, int howto); static void adasuspend(void *arg); static void adaresume(void *arg); +static void adadiskspindown(void *); #ifndef ADA_DEFAULT_LEGACY_ALIASES #ifdef ATA_CAM @@ -335,10 +338,16 @@ static void adaresume(void *arg); #define ADA_DEFAULT_WRITE_CACHE 1 #endif +#ifndef ADA_DEFAULT_SPINDOWN +#define ADA_DEFAULT_SPINDOWN 0 +#endif + #define ADA_RA (softc->read_ahead >= 0 ? \ softc->read_ahead : ada_read_ahead) #define ADA_WC (softc->write_cache >= 0 ? \ softc->write_cache : ada_write_cache) +#define ADA_SD (softc->spindown >= 0 ? \ + softc->spindown : ada_spindown) /* * Most platforms map firmware geometry to actual, but some don't. If @@ -356,6 +365,7 @@ static int ada_spindown_shutdown = ADA_DEFAULT_SPINDOWN_SHUTDOWN; static int ada_spindown_suspend = ADA_DEFAULT_SPINDOWN_SUSPEND; static int ada_read_ahead = ADA_DEFAULT_READ_AHEAD; static int ada_write_cache = ADA_DEFAULT_WRITE_CACHE; +static int ada_spindown = ADA_DEFAULT_SPINDOWN; static SYSCTL_NODE(_kern_cam, OID_AUTO, ada, CTLFLAG_RD, 0, "CAM Direct Access Disk driver"); @@ -383,6 +393,9 @@ TUNABLE_INT("kern.cam.ada.read_ahead", &ada_read_ahead); SYSCTL_INT(_kern_cam_ada, OID_AUTO, write_cache, CTLFLAG_RW, &ada_write_cache, 0, "Enable disk write cache"); TUNABLE_INT("kern.cam.ada.write_cache", &ada_write_cache); +SYSCTL_INT(_kern_cam_ada, OID_AUTO, spindown, CTLFLAG_RW, + &ada_spindown, 0, "Forced idle spin-down timeout"); +TUNABLE_INT("kern.cam.ada.spindown", &ada_spindown); /* * ADA_ORDEREDTAG_INTERVAL determines how often, relative @@ -543,6 +556,10 @@ adastrategy(struct bio *bp) } softc = (struct ada_softc *)periph->softc; + if (ADA_SD > 0) + callout_reset(&softc->spindown_timer, ADA_SD * hz, + adadiskspindown, periph); + cam_periph_lock(periph); CAM_DEBUG(periph->path, CAM_DEBUG_TRACE, ("adastrategy(%p)\n", bp)); @@ -709,6 +726,8 @@ adaoninvalidate(struct cam_periph *periph) softc->flags |= ADA_FLAG_PACK_INVALID; + callout_drain(&softc->spindown_timer); + /* * Return all queued I/O with ENXIO. * XXX Handle any transactions queued to the card @@ -731,6 +750,8 @@ adacleanup(struct cam_periph *periph) xpt_print(periph->path, "removing device entry\n"); cam_periph_unlock(periph); + callout_drain(&softc->spindown_timer); + /* * If we can't free the sysctl tree, oh well... */ @@ -889,6 +910,9 @@ adasysctlinit(void *context, int pending) SYSCTL_ADD_INT(&softc->sysctl_ctx, SYSCTL_CHILDREN(softc->sysctl_tree), OID_AUTO, "write_cache", CTLFLAG_RW | CTLFLAG_MPSAFE, &softc->write_cache, 0, "Enable disk write cache."); + SYSCTL_ADD_INT(&softc->sysctl_ctx, SYSCTL_CHILDREN(softc->sysctl_tree), + OID_AUTO, "spindown", CTLFLAG_RW | CTLFLAG_MPSAFE, + &softc->spindown, 0, "Forced idle spin-down timeout."); #ifdef ADA_TEST_FAILURE /* * Add a 'door bell' sysctl which allows one to set it from userland @@ -1029,6 +1053,10 @@ adaregister(struct cam_periph *periph, void *arg) snprintf(announce_buf, sizeof(announce_buf), "kern.cam.ada.%d.write_cache", periph->unit_number); TUNABLE_INT_FETCH(announce_buf, &softc->write_cache); + softc->spindown = -1; + snprintf(announce_buf, sizeof(announce_buf), + "kern.cam.ada.%d.spindown", periph->unit_number); + TUNABLE_INT_FETCH(announce_buf, &softc->spindown); adagetparams(periph, cgd); softc->disk = disk_alloc(); softc->disk->d_devstat = devstat_new_entry(periph->periph_name, @@ -1167,6 +1195,11 @@ adaregister(struct cam_periph *periph, void *arg) } else softc->state = ADA_STATE_NORMAL; + callout_init(&softc->spindown_timer, 1); + if (ADA_SD > 0) + callout_reset(&softc->spindown_timer, ADA_SD * hz, + adadiskspindown, periph); + return(CAM_REQ_CMP); } @@ -1822,6 +1855,53 @@ adaspindown(uint8_t cmd, int flags) } static void +adadiskspindown(void *arg) +{ + union ccb ccb; + struct cam_periph *periph = arg; + struct ada_softc *softc; + + cam_periph_lock(periph); + softc = (struct ada_softc *)periph->softc; + + /* + * We only spin-down the drive if it is capable of it.. + */ + if ((softc->flags & ADA_FLAG_CAN_POWERMGT) == 0) { + cam_periph_unlock(periph); + return; + } + + if (bootverbose) + xpt_print(periph->path, "spin-down\n"); + + xpt_setup_ccb(&ccb.ccb_h, periph->path, CAM_PRIORITY_NORMAL); + ccb.ccb_h.ccb_state = ADA_CCB_DUMP; + cam_fill_ataio(&ccb.ataio, + 1, + adadone, + CAM_DIR_NONE, + 0, + NULL, + 0, + ada_default_timeout*1000); + + ata_28bit_cmd(&ccb.ataio, ATA_STANDBY_IMMEDIATE, 0, 0, 0); + xpt_polled_action(&ccb); + + if ((ccb.ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) + xpt_print(periph->path, "Spin-down disk failed\n"); + + if ((ccb.ccb_h.status & CAM_DEV_QFRZN) != 0) + cam_release_devq(ccb.ccb_h.path, + /*relsim_flags*/0, + /*reduction*/0, + /*timeout*/0, + /*getcount_only*/0); + cam_periph_unlock(periph); +} + +static void adashutdown(void *arg, int howto) { -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Sat Sep 22 17:15:40 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE041065700; Sat, 22 Sep 2012 17:15:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 08F218FC15; Sat, 22 Sep 2012 17:15:38 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA07593; Sat, 22 Sep 2012 20:15:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TFTIn-000NV1-D5; Sat, 22 Sep 2012 20:15:37 +0300 Message-ID: <505DF238.5020203@FreeBSD.org> Date: Sat, 22 Sep 2012 20:15:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: ata_da: set disk::d_ident from serial number X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 17:15:40 -0000 I would like to get the following change into ata_da: commit 19c0fcb7b28c33b34b0b72e19fccb7bb0a195cd8 Author: Andriy Gapon Date: Tue Sep 4 18:36:00 2012 +0300 ata_da: set disk::d_ident from serial number diff --git a/sys/cam/ata/ata_da.c b/sys/cam/ata/ata_da.c index 08c756e..92ed0c6 100644 --- a/sys/cam/ata/ata_da.c +++ b/sys/cam/ata/ata_da.c @@ -1064,6 +1064,8 @@ adaregister(struct cam_periph *periph, void *arg) softc->disk->d_flags |= DISKFLAG_CANDELETE; strlcpy(softc->disk->d_descr, cgd->ident_data.model, MIN(sizeof(softc->disk->d_descr), sizeof(cgd->ident_data.model))); + strlcpy(softc->disk->d_ident, cgd->ident_data.serial, + MIN(sizeof(softc->disk->d_ident), sizeof(cgd->ident_data.serial))); softc->disk->d_hba_vendor = cpi.hba_vendor; softc->disk->d_hba_device = cpi.hba_device; softc->disk->d_hba_subvendor = cpi.hba_subvendor; -- Andriy Gapon