[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] Fibre Channel related crash



Hi,

Thanx to all of you for the responses.  To be honest I don't know much
about all of this of fibre channel and device mapper thing.  How are
they related? I'm not even sure if they are the same or not.

I'm dealing with this because we have installed an Oracle database for a
mission critical web app here in my company and we have always been
using Linux and Fedora in particular, but this is the first time I have
to deal with this kind of hardware.

Could you point me to some place where I can learn about all this stuff
for someone with good experience with linux but zero experience with
this subject.

I have been reading the archives of this mailing list but the knowledge
needed to understand some of the threads is not of my level.

Thanx again for your help,


-William


El jue, 23-06-2005 a las 09:52 -0400, Philip R Auld escribió:
> Hi,
> 
> Rumor has it that on Wed, Jun 22, 2005 at 10:28:32AM -0700 Patrick Mansfield said:
> > You should really run with a stock kernel before reporting problems to
> > these lists.
> > 
> > cc-ing linux-scsi, maybe someone there will give you more info about the
> > HSV110.
> 
> The HSV110 is and active/passive array. You're probably accessing a LU 
> that is not on the controller your talking to. Sending it a start would
> work, but, of course, then you can't access it through the other
> controller...
> 
> I think the multipath tools and device mapper will know how to handle
> this device.
> 
> Cheers,
> 
> Phil
> > 
> > On Tue, Jun 21, 2005 at 08:49:44AM -0500, William Alberto Lovaton Tovar wrote:
> > 
> > > Jun 20 13:35:01 dnccor50 kernel:   Vendor: COMPAQ    Model: HSV110 (C)COMPAQ  Rev: 2001
> > > Jun 20 13:35:01 dnccor50 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
> > > Jun 20 13:35:01 dnccor50 kernel: qla2300 0000:07:03.0: scsi(0:0:1:2): Enabled tagged queuing, queue depth 32.
> > > Jun 20 13:35:01 dnccor50 kernel: SCSI device sdb: 167772160 512-byte hdwr sectors (85899 MB)
> > > Jun 20 13:35:01 dnccor50 kernel: sdb: asking for cache data failed
> > > Jun 20 13:35:01 dnccor50 kernel: sdb: assuming drive cache: write through
> > > Jun 20 13:35:01 dnccor50 kernel: SCSI device sdb: 167772160 512-byte hdwr sectors (85899 MB)
> > > Jun 20 13:35:01 dnccor50 kernel: sdb: asking for cache data failed
> > > Jun 20 13:35:01 dnccor50 kernel: sdb: assuming drive cache: write through
> > > Jun 20 13:35:01 dnccor50 kernel:  sdb:<6>Device sdb not ready.
> > > Jun 20 13:35:01 dnccor50 kernel: end_request: I/O error, dev sdb, sector 0
> > 
> > It isn't a fibre channel crash.
> > 
> > The device is (obviously) not ready. Usually, sd during probe spins up the
> > device, but the HSV110 is special cased, so we don't spin it up (send a
> > START STOP command), and it just keeps telling us it is still not ready.
> > 
> > Since it's a disk array, I don't know what a START / spinup means for it,
> > or why it is not ready. I would guess it has some sort of failure and is
> > waiting for you to fix it :)
> > 
> > You should check the device: verify its settings, check for failures,
> > and/or reset it; or maybe send it a START UNIT to the device.
> > 
> > You can try to dynamically modify the scsi_devinfo/bflags so it sends the
> > START STOP during probe: 
> > 
> > change the devinfo list (won't be reset to the original until you reload
> > scsi_mod), I don't know if I have this exactly right:
> > 
> > 	echo "COMPAQ   :HSV110 (C)COMPAQ:0x0" > /proc/scsi/device_info
> > 
> > remove and re-scan for the device
> > 
> > 	echo 1 > /sys/block/sd/device/delete
> > 	echo "0 1 2" > /sys/class/scsi_host/host0/scan
> > 
> > And see what happens ... you should see some "spinning up disk ..."
> > messages.
> > 
> > -- Patrick Mansfield
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to majordomo vger kernel org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]