Re: problems to expect with 2TB volumes
Hello Douglas, thanks for your help, I was just a bit worried when I read the thread. On reviewing that thread, the original poster was jumping to premature conclusions. Justin Gibbs told him there was no such problem (and Justin is well placed to know). Then the final post shows a trace with READ(10) commands failing. They are 32 bit lba read operations that have been the default for about 10 years in the SCSI subsystem. If those fail on that transport it is probably a termination problem. When Justin saw that he probably didn't bother responding again. For a non-scsi protocol expert those scsi card dumps really don't say anything :( Thanks again, Bernd -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Infinite retries reading the partition table
On Thu, 30 Nov 2006, Andrew Morton wrote: That looks like it prevents the IO error. But why was an IO error causing an infinite loop? What piece of code was initiating the retries? Maybe it's related to the infinite domain validation retry loop problem I reported on linux-scsi a few weeks ago ? -- Etienne Vogt ([EMAIL PROTECTED]) Observatoire de Paris-Meudon, France - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote: But how did he get the file descriptor? He opened a device name, which could have been used to get the sysfs file. The device name was probably something like /dev/sg0. This doesn't easily permit one to find the corresponding sysfs filename for the real underlying device, although it can be done with difficulty. (That's why I used the excessively-ornate sysfs pathname in the Bugzilla entry.) It certainly wouldn't be as easy as using an ioctl. It wouldn't be as uniform either. The search through sysfs would have to be different depending on whether the device name was /dev/sr0 or /dev/sg0. Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've tried to get some for some of my older boxes. Most of them nowadays are IDE attachments, which don't have a /dev/sg node. So /dev/sg is really the legacy mode for burning. The correct way to do it today is to use the actual device name ... then you don't have to worry about what the transport is any more. Is the patch below acceptable? Really, no. The parameter you're fishing for is a block parameter, not a SCSI parameter ... it should really be a block ioctl if we have to have an ioctl at all. I could easily enough rewrite the patch to put the ioctl somewhere else (although I'm not quite sure exactly where would be best). But do non-block devices have request queues? What about the points that Doug raised: All CD/DVD burners are block devices, which is the problem set under discussion. On Tue, 5 Dec 2006, Douglas Gilbert wrote: Apart from sensibly yielding the max size in bytes, your patch has the added benefit of allowing non-block devices (e.g. tape, processor and enclosure services) to find out what limit the OS/host has placed on each command's maximum transfer size. They all possess block queues, yes, so we should really allow access to the block ioctls for them. If you manage to get that ioctl in, then ungrateful people will ask for the corresponding set operation as well. To illustrate the /sys mess look at naming of the sysfs approach to this problem. For example: /sys/block/sde/queue/max_sectors_kb - it is not only a block property - sde is an end device and suggests information from that device's Block Limits VPD page, actually it is a limit imposed by the OS and the host used to access that device - what has queue got to do with it? - max_sectors_kb should have units of bytes In addition to all of these points, there remains the peculiar location of the SG_ ioctls. They are implemented it two places in the kernel: block/scsi_ioctl.c and drivers/scsi/sg.c. And the two implementations of e.g. SG_SET_RESERVED_SIZE don't even do the same thing! I have no idea why the block layer even implements SG_SET_RESERVED_SIZE ... I suspect it was some legacy application compatibility problem, so it probably can be eliminated. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 6 Dec 2006, James Bottomley wrote: Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've tried to get some for some of my older boxes. Most of them nowadays are IDE attachments, which don't have a /dev/sg node. So /dev/sg is really the legacy mode for burning. Well, there are still a lot of legacy devices out there. The correct way to do it today is to use the actual device name ... then you don't have to worry about what the transport is any more. I could easily enough rewrite the patch to put the ioctl somewhere else (although I'm not quite sure exactly where would be best). But do non-block devices have request queues? What about the points that Doug raised: All CD/DVD burners are block devices, which is the problem set under discussion. Fair enough. On Tue, 5 Dec 2006, Douglas Gilbert wrote: Apart from sensibly yielding the max size in bytes, your patch has the added benefit of allowing non-block devices (e.g. tape, processor and enclosure services) to find out what limit the OS/host has placed on each command's maximum transfer size. They all possess block queues, yes, so we should really allow access to the block ioctls for them. I have no idea why the block layer even implements SG_SET_RESERVED_SIZE ... I suspect it was some legacy application compatibility problem, so it probably can be eliminated. Let's leave that for a separate patch. It turns out that for block device files we don't need to change anything. The BLKSECTGET ioctl already does almost exactly what we want: int n; if (ioctl(fd, BLKSECTGET, n) == 0) max_transfer_size = n * 512; So only the legacy sg character-device files need attention, which means that only the part of the patch affecting sg.c is necessary. The new SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the block layer -- just as SG_[SG]ET_RESERVED_SIZE should be. How does that sound? Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote: So only the legacy sg character-device files need attention, which means that only the part of the patch affecting sg.c is necessary. The new SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the block layer -- just as SG_[SG]ET_RESERVED_SIZE should be. How does that sound? Actually, I'd just connect sg up to the block ioctl ... it has a block queue and valid parameters, so BLKSECTGET will work for it as well. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote: Well, accept the patch if it works. It's not about work/not work: it's about correctness. And in case that you don't like it, make sure that the _parameter_ is moved to where it belongs: to the low level transport layer. It's not a low level property; it's a property of the generic queue, namely the maximum request size. It exists for devices independent of SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs as well). It is a DMA property, so it is a low level property. The fact that the parameter is held somewhere else does not change this. BTW: I received a positive test result from a user, so the patch really fixes the problems and we should use it. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
James Bottomley [EMAIL PROTECTED] wrote: All CD/DVD burners are block devices, which is the problem set under discussion. Please keep in mind: all CD/DVD burners are SCSI devices. You cannot write or even retrieve special information without SCSI. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
Alan Stern [EMAIL PROTECTED] wrote: It turns out that for block device files we don't need to change anything. The BLKSECTGET ioctl already does almost exactly what we want: int n; if (ioctl(fd, BLKSECTGET, n) == 0) max_transfer_size = n * 512; So only the legacy sg character-device files need attention, which means that only the part of the patch affecting sg.c is necessary. The new SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the block layer -- just as SG_[SG]ET_RESERVED_SIZE should be. How does that sound? libscg needs a unique ioctl that works for all used filedescriptors that may be a target for SG_IO. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote: Please keep in mind: all CD/DVD burners are SCSI devices. This is probably semantics, but nowadays, SCSI means SPI (or parallel SCSI). I think you're trying to say that they're all devices that obey the MMC standard? Which is true, but not really relevant. You cannot write or even retrieve special information without SCSI. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
James Bottomley wrote: On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote: But how did he get the file descriptor? He opened a device name, which could have been used to get the sysfs file. The device name was probably something like /dev/sg0. This doesn't easily permit one to find the corresponding sysfs filename for the real underlying device, although it can be done with difficulty. (That's why I used the excessively-ornate sysfs pathname in the Bugzilla entry.) It certainly wouldn't be as easy as using an ioctl. It wouldn't be as uniform either. The search through sysfs would have to be different depending on whether the device name was /dev/sr0 or /dev/sg0. Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've tried to get some for some of my older boxes. Most of them nowadays are IDE attachments, which don't have a /dev/sg node. So /dev/sg is really the legacy mode for burning. The correct way to do it today is to use the actual device name ... then you don't have to worry about what the transport is any more. All CD and DVD drive these days use SCSI. That is SCSI command sets: MMC and SPC. Very few use the SCSI Parallel Interface (SPI). An increasing number will be using S-ATAPI and they could be seen by the OS via SCSI transports: FC and SAS (+ SATA). Is the patch below acceptable? Really, no. The parameter you're fishing for is a block parameter, not a SCSI parameter ... it should really be a block ioctl if we have to have an ioctl at all. I could easily enough rewrite the patch to put the ioctl somewhere else (although I'm not quite sure exactly where would be best). But do non-block devices have request queues? What about the points that Doug raised: All CD/DVD burners are block devices, which is the problem set under discussion. CD/DVD burners are block device for read operations only. When they are burning they are not block devices in the normal sense. So if this was classic Unix a block device node would be used for reading and a raw device node for writing. Just like I'm wasting keystrokes. On Tue, 5 Dec 2006, Douglas Gilbert wrote: Apart from sensibly yielding the max size in bytes, your patch has the added benefit of allowing non-block devices (e.g. tape, processor and enclosure services) to find out what limit the OS/host has placed on each command's maximum transfer size. They all possess block queues, yes, so we should really allow access to the block ioctls for them. If you manage to get that ioctl in, then ungrateful people will ask for the corresponding set operation as well. To illustrate the /sys mess look at naming of the sysfs approach to this problem. For example: /sys/block/sde/queue/max_sectors_kb - it is not only a block property - sde is an end device and suggests information from that device's Block Limits VPD page, actually it is a limit imposed by the OS and the host used to access that device - what has queue got to do with it? - max_sectors_kb should have units of bytes In addition to all of these points, there remains the peculiar location of the SG_ ioctls. They are implemented it two places in the kernel: block/scsi_ioctl.c and drivers/scsi/sg.c. And the two implementations of e.g. SG_SET_RESERVED_SIZE don't even do the same thing! I have no idea why the block layer even implements SG_SET_RESERVED_SIZE ... I suspect it was some legacy application compatibility problem, so it probably can be eliminated. It was put there to trick cdrecord! Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
James Bottomley wrote: On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote: Please keep in mind: all CD/DVD burners are SCSI devices. This is probably semantics, but nowadays, SCSI means SPI (or parallel SCSI). I think you're trying to say that they're all devices that obey the MMC standard? Which is true, but not really relevant. James, SPI is dead. Get used to it. SCSI has not meant SPI for years. We should be in the business of disabusing people of that idea, not reinforcing it. If you went to www.t10.org and looked at draft documents and the reflector you would be lucky to find any documents or posts about SPI in the last two years. Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote: Please keep in mind: all CD/DVD burners are SCSI devices. This is probably semantics, but nowadays, SCSI means SPI (or parallel SCSI). I think you're trying to say that they're all devices that obey the MMC standard? Which is true, but not really relevant. You cannot write or even retrieve special information without SCSI. I am not sure if you did ever have a look at t10.org. SCSI is a widely used protocol that is supported over many different transports. SPI is as dead as PATA and note that SAS controllers will transparently handle even SATA devices. SCSI supports many more devices than MMC and SCSI runs on many different transports. The SCSI protocol layer has been separated from the transport layer in the early 1990s. Please do not try to make asumptions based on outdated information. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote: SPI is dead. Get used to it. SCSI has not meant SPI for years. We should be in the business of disabusing people of that idea, not reinforcing it. I don't believe I said anything in favour of or against SPI. I think you'll find the whole point of SAM is separating the command set from the transport and interconnect. Saying a device speaks SCSI has no real meaning in that context anymore. It's commonly taken to mean SCSI-2 where the whole things was lumped together and SPI centric. In the SAM context, a modern IDE CD is MMC over an ATAPI or SATAPI transport. An old SCSI CD is MMC over SPI. The thing Alan's having trouble with is MMC over a USB transport. If you went to www.t10.org and looked at draft documents and the reflector you would be lucky to find any documents or posts about SPI in the last two years. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 6 Dec 2006, James Bottomley wrote: On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote: So only the legacy sg character-device files need attention, which means that only the part of the patch affecting sg.c is necessary. The new SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the block layer -- just as SG_[SG]ET_RESERVED_SIZE should be. How does that sound? Actually, I'd just connect sg up to the block ioctl ... it has a block queue and valid parameters, so BLKSECTGET will work for it as well. I'd love to do that -- but blkdev_ioctl() wants inode-i_bdev to be set, and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So it won't work with sg, which uses character device nodes. How about adding BLKSECTGET to the list of commands accepted by sg_ioctl()? Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote: I'd love to do that -- but blkdev_ioctl() wants inode-i_bdev to be set, and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So it won't work with sg, which uses character device nodes. Well, even sg has the queue ... and what we're looking for are the queue parameters. In block/ioctl.c the bdev is just used for getting the queue parameters (mainly via bdev-bd_disk-queue), so I could see if Jens might be amenable to refactoring the queue ioctls so we can get at them simply with a struct request_queue parameter. How about adding BLKSECTGET to the list of commands accepted by sg_ioctl()? That's certainly a possible hack ... although I'd prefer to see the full queue ioctls exposed. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
James Bottomley wrote: On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote: SPI is dead. Get used to it. SCSI has not meant SPI for years. We should be in the business of disabusing people of that idea, not reinforcing it. I don't believe I said anything in favour of or against SPI. James, My objection, and I believe Joerg's objection, is how people would interpret this statement by you: This is probably semantics, but nowadays, SCSI means SPI (or parallel SCSI). One could deduce from that statement, falsely, that the linux SCSI subsystem was the linux SPI subsystem. Hence we should mark it as legacy (and stop libata and the new ATA subsystem from using it). I think you'll find the whole point of SAM is separating the command set from the transport and interconnect. Saying a device speaks SCSI has no real meaning in that context anymore. It's commonly taken to mean SCSI-2 where the whole things was lumped together and SPI centric. SCSI is a storage architecture, a group of command sets and a group of transports. The original SCSI transport, now considered legacy (a horribly non-technical word) is SPI. In the SAM context, a modern IDE CD is MMC over an ATAPI or SATAPI transport. An old SCSI CD is MMC over SPI. The thing Alan's having trouble with is MMC over a USB transport. Agreed. And USB mass storage would probably be the most used SCSI transport nowadays. Folks can and have written their own subsystems for handling USB mass storage but sooner or later they are going to be looking at read capacity, sense buffers and mode pages. That is why the SCSI subsystem continues to be relevant. Doug Gilbert - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] lpfc: add PCI error recovery support
James,
Please review the patch below. Presuming that you lke it,
please forward upstream.
--linas
This patch adds PCI Error recovery support to the
Emulex Lightpulse Fibrechannel (lpfc) SCSI device driver.
Lightly tested at this point, works.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James Smart [EMAIL PROTECTED]
drivers/scsi/lpfc/lpfc_init.c | 91 ++
1 file changed, 91 insertions(+)
Index: linux-2.6.19-git7/drivers/scsi/lpfc/lpfc_init.c
===
--- linux-2.6.19-git7.orig/drivers/scsi/lpfc/lpfc_init.c2006-12-06
13:31:39.0 -0600
+++ linux-2.6.19-git7/drivers/scsi/lpfc/lpfc_init.c 2006-12-06
13:33:49.0 -0600
@@ -517,6 +517,11 @@ lpfc_handle_eratt(struct lpfc_hba * phba
struct lpfc_sli_ring *pring;
uint32_t event_data;
+ /* If the pci channel is offline, ignore possible errors,
+* since we cannot communicate with the pci card anyway. */
+ if (pci_channel_offline(phba-pcidev))
+ return;
+
if (phba-work_hs HS_FFER6) {
/* Re-establishing Link */
lpfc_printf_log(phba, KERN_INFO, LOG_LINK_EVENT,
@@ -1825,6 +1830,85 @@ lpfc_pci_remove_one(struct pci_dev *pdev
pci_set_drvdata(pdev, NULL);
}
+/**
+ * lpfc_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t lpfc_io_error_detected(struct pci_dev *pdev,
+pci_channel_state_t state)
+{
+ if (state == pci_channel_io_perm_failure) {
+ lpfc_pci_remove_one(pdev);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_disable_device(pdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * lpfc_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot.
+ */
+static pci_ers_result_t lpfc_io_slot_reset(struct pci_dev *pdev)
+{
+ struct Scsi_Host *host = pci_get_drvdata(pdev);
+ struct lpfc_hba *phba = (struct lpfc_hba *)host-hostdata;
+ struct lpfc_sli *psli = phba-sli;
+ struct lpfc_sli_ring *pring;
+
+ dev_printk(KERN_INFO, pdev-dev, recovering from a slot reset.\n);
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR lpfc: Cannot re-enable PCI device after
reset.\n);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_set_master(pdev);
+
+ /* Re-establishing Link */
+ spin_lock_irq(phba-host-host_lock);
+ phba-fc_flag |= FC_ESTABLISH_LINK;
+ psli-sli_flag = ~LPFC_SLI2_ACTIVE;
+ spin_unlock_irq(phba-host-host_lock);
+
+ /*
+* There may be I/Os dropped by the firmware.
+* Error iocb (I/O) on txcmplq and let the SCSI layer
+* retry it after re-establishing link.
+*/
+ pring = psli-ring[psli-fcp_ring];
+ lpfc_sli_abort_iocb_ring(phba, pring);
+
+ /* Take device offline; this will perform cleanup */
+ lpfc_offline(phba);
+ lpfc_sli_brdrestart(phba);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * lpfc_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation.
+ */
+static void lpfc_io_resume(struct pci_dev *pdev)
+{
+ struct Scsi_Host *host = pci_get_drvdata(pdev);
+ struct lpfc_hba *phba = (struct lpfc_hba *)host-hostdata;
+
+ lpfc_online(phba);
+ mod_timer(phba-fc_estabtmo, jiffies + HZ * 60);
+}
+
static struct pci_device_id lpfc_id_table[] = {
{PCI_VENDOR_ID_EMULEX, PCI_DEVICE_ID_VIPER,
PCI_ANY_ID, PCI_ANY_ID, },
@@ -1885,11 +1969,18 @@ static struct pci_device_id lpfc_id_tabl
MODULE_DEVICE_TABLE(pci, lpfc_id_table);
+static struct pci_error_handlers lpfc_err_handler = {
+ .error_detected = lpfc_io_error_detected,
+ .slot_reset = lpfc_io_slot_reset,
+ .resume = lpfc_io_resume,
+};
+
static struct pci_driver lpfc_driver = {
.name = LPFC_DRIVER_NAME,
.id_table = lpfc_id_table,
.probe = lpfc_pci_probe_one,
.remove = __devexit_p(lpfc_pci_remove_one),
+ .err_handler = lpfc_err_handler,
};
static int __init
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 6 Dec 2006, James Bottomley wrote: On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote: I'd love to do that -- but blkdev_ioctl() wants inode-i_bdev to be set, and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So it won't work with sg, which uses character device nodes. Well, even sg has the queue ... and what we're looking for are the queue parameters. In block/ioctl.c the bdev is just used for getting the queue parameters (mainly via bdev-bd_disk-queue), That's true for several of the ioctls but not all of them. so I could see if Jens might be amenable to refactoring the queue ioctls so we can get at them simply with a struct request_queue parameter. That would be fine with me. Could you go ahead and ask Jens? How about adding BLKSECTGET to the list of commands accepted by sg_ioctl()? That's certainly a possible hack ... although I'd prefer to see the full queue ioctls exposed. I agree; it's better to keep things in one place rather than to duplicate them. Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
Douglas Gilbert wrote: James Bottomley wrote: On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote: Well, accept the patch if it works. It's not about work/not work: it's about correctness. And in case that you don't like it, make sure that the _parameter_ is moved to where it belongs: to the low level transport layer. It's not a low level property; it's a property of the generic queue, namely the maximum request size. It exists for devices independent of SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs as well). Too much smoke and mirrors. That maximum request size comes from the transport ** and in many cases is a kludge between maximum, optimal and defensive. The block paradigm is wrong for a pass through because it requests transports to guess a maximum, trying to head off errors that the block layer isn't particularly well equipped to handle at run time. On the other hand a pass through gets layered error reporting. So if a host (and/or its LLD driver) doesn't like the size (or shape) of data to be sent/received with a For iscsi, we could negotiate a value like MaxBurstLength which says don't send commands with a payload larger than that size. I would guess other transports have something similar. We have to check or make sure we do not get commands larger than this somewhere. It is nice if some common layer could do this for us. Cards have a scatterlist limits and having them checked before they get to the driver for everyone is nice. I agree using and being limited to SG_ALL is a little strange since it is a odd size and having to recompile your kernel to get up to that limit is a pain in the butt, but that is not a problem with using the block layer. Those are scsi layer variables and I think those values can be changed. Is the main gripe over max sectors? I agree max sectors is odd because we do not know what that value means in some cases for pass through and what that real limit is for many drivers. Because the other values that we check in the block layer to create the scatterlist and request, seem worthwhile to check as early as possible and if we checked them at the driver level for every driver how would the test or return value be different? I think this is the part I do not fully understand when this keeps popping up. Currently the LLD cannot tell you that it cannot handle a command because it was just too darn large any more than the block layer can. One would return -EINVAL or -ENOMEM and the other would return lots of different values because it depends on the driver and none of them tell you that a specific limit was reached. All we really want is the underlying mapping and scatterlist building code but without some checks like max sectors and we want some new error values. I will leave the debate over whether those should be checked to you guys :) I only want to help on getting more info to the user and I do not think we should have duplicated code doing the same thing except one checks max_hw_sectors and the other does not. Oh yeah, but on that note, in the original patches I did not check for values like max sectors. I later changed this to checking for max hw sectors. You could modify the REQ_TYPE_BLOCK_PC checks that I added to not test anything instead of values like max_hw_sectors again (I am just saying it is possible in the code not). For the problem of sending error values that are not useful and leaving the user in the dark we can still use the block layer helpers and not have to add so many checks to the LLDs by modifying them to return BLKERR values that are more descriptive like here: http://kernel.org/git/?p=linux/kernel/git/mnc/linux-2.6-iscsi.git;a=blob;h=c8c20df124e58d04f90e74dea8d7880016f8a5df;hb=multipath;f=include/linux/blkdev.h In that code that I am doing to move the dm hw_handlers to scsi we need to return something more informative than -Exyz, so I added BLKERR values and one day I will convert all the block driver again and convince Jens we need it :) For something like using blk_rq_map_user to map/copy the data, instead of returning -EINVAL when we hit a limit I want to return BLKERR_TOO_MANY_SEGMENTS, BLKERR_TOO_MANY_SECTORS, BLKERR_SEGMENT_TOO_LARGE, etc just like if the LLD was to return a new DID_* error value to tell them the same thing. Alternatively, if we do start not checking values like max sectors and send requests down to the drivers, the block layer mapping functions can be modified to not check certain values and LLDs/scsi-ml can return these BLKERR values all the way up to sg/bsg/scsi_ioctl.c for values that they need to check. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wed, 6 Dec 2006, Mike Christie wrote: Alternatively, if we do start not checking values like max sectors and send requests down to the drivers, the block layer mapping functions can be modified to not check certain values and LLDs/scsi-ml can return these BLKERR values all the way up to sg/bsg/scsi_ioctl.c for values that they need to check. I bet in many cases the LLD depends on the higher layers to filter out transfers that are too large. Duplicating all those tests in all the LLDs seems like a waste. Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
Mike Christie wrote: Douglas Gilbert wrote: James Bottomley wrote: On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote: Well, accept the patch if it works. It's not about work/not work: it's about correctness. And in case that you don't like it, make sure that the _parameter_ is moved to where it belongs: to the low level transport layer. It's not a low level property; it's a property of the generic queue, namely the maximum request size. It exists for devices independent of SCSI (i.e. you'll want it for IDE and weirder transport attachment CDs as well). Too much smoke and mirrors. That maximum request size comes from the transport ** and in many cases is a kludge between maximum, optimal and defensive. The block paradigm is wrong for a pass through because it requests transports to guess a maximum, trying to head off errors that the block layer isn't particularly well equipped to handle at run time. On the other hand a pass through gets layered error reporting. So if a host (and/or its LLD driver) doesn't like the size (or shape) of data to be sent/received with a For iscsi, we could negotiate a value like MaxBurstLength which says don't send commands with a payload larger than that size. I would guess other transports have something similar. We have to check or make sure we do not get commands larger than this somewhere. It is nice if some common layer could do this for us. Cards have a scatterlist limits and having them checked before they get to the driver for everyone is nice. I agree using and being limited to SG_ALL is a little strange since it is a odd size and having to recompile your kernel to get up to that limit is a pain in the butt, but that is not a problem with using the block layer. Those are scsi layer variables and I think those values can be changed. Is the main gripe over max sectors? I agree max sectors is odd because we do not know what that value means in some cases for pass through and what that real limit is for many drivers. Because the other values that we check in the block layer to create the scatterlist and request, seem worthwhile to check as early as possible and if we checked them at the driver level for every driver how would the test or return value be different? I think this is the part I do not fully understand when this keeps popping up. Oh yeah the exception I am thinking about may not be max sectors exactly but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs are supposed to be translating that iscsi limit to max_sectors in which case we are talking about the same thing. For this limit we do not want a FS or pass through request with more data than MaxBurstLength bytes. If it is different than max_hw_sectors, we could add q-max_request_size and check this in the block mapping and request building functions, but the error value would be generic like maybe BLKERR_REQUEST_TOO_LARGE. You would not be able to tell the user that specifically the request was larger than the iscsi MaxBurstLength. I am not sure how this fits into the argument, since there is no guessing with it. The block layer handles this nicely for FS requests by breaking up requests into the correct size. The limit also applies to pass through requests and we can get a error indicating it is too large. The draw back is of course lack of information to the user or upper layer and it seems you guys are arguing where this type check belongs. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wednesday 06 December 2006 16:50, Mike Christie wrote: For iscsi, we could negotiate a value like MaxBurstLength which says don't send commands with a payload larger than that size. I would guess other transports have something similar. We have to check or make sure ... Oh yeah the exception I am thinking about may not be max sectors exactly but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs are supposed to be translating that iscsi limit to max_sectors in which case we are talking about the same thing. For this limit we do not want Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max transfer size, it simply is the amount of data that can be sent without a R2T. If the transfer is larger then you have to wait for the R2T. In practice it ends up controlling the _minimum_ amount of buffer space that needs to be available _before_ the transfer starts, otherwise performace sucks. -- PHB REQ: Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return email and thereafter delete the message. You may not use, copy, disclose or rely on the information contained in this message. Internet e-mail may be susceptible to data corruption, interception and unauthorized amendment for which Gresham does not accept liability. While we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Gresham does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Gresham are neither given nor endorsed by the company or its directors. A list of Gresham's directors is available on our web site: www.gresham-computing.com - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
On Wednesday 06 December 2006 17:42, Jeremy Linton wrote: On Wednesday 06 December 2006 16:50, Mike Christie wrote: For iscsi, we could negotiate a value like MaxBurstLength which says don't send commands with a payload larger than that size. I would guess other transports have something similar. We have to check or make sure ... Oh yeah the exception I am thinking about may not be max sectors exactly but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs are supposed to be translating that iscsi limit to max_sectors in which case we are talking about the same thing. For this limit we do not want Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max transfer size, it simply is the amount of data that can be sent without a R2T. If the transfer is larger then you have to wait for the R2T. In practice it ends up controlling the _minimum_ amount of buffer space that needs to be available _before_ the transfer starts, otherwise performace sucks. Whops, Slight clarification, the MaxBurstLength is the max sent between R2T's what I described above is closer to the FirstBurstLength. What you guys are describing might better be the MaxRecvDataSegmentLength, but not really since that parameter should be hidden within the iSCSI driver. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 7026] CD/DVD burning with USB writer doesn't work
Mike Christie wrote: Jeremy Linton wrote: On Wednesday 06 December 2006 17:42, Jeremy Linton wrote: On Wednesday 06 December 2006 16:50, Mike Christie wrote: For iscsi, we could negotiate a value like MaxBurstLength which says don't send commands with a payload larger than that size. I would guess other transports have something similar. We have to check or make sure ... Oh yeah the exception I am thinking about may not be max sectors exactly but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs are supposed to be translating that iscsi limit to max_sectors in which case we are talking about the same thing. For this limit we do not want Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max transfer size, it simply is the amount of data that can be sent without a R2T. If the transfer is larger then you have to wait for the R2T. In practice it ends up controlling the _minimum_ amount of buffer space that needs to be available _before_ the transfer starts, otherwise performace sucks. Whops, Slight clarification, the MaxBurstLength is the max sent between R2T's what I described above is closer to the FirstBurstLength. What you guys are I should have clarified this would have been a workaround for some bad targets, but I hoped could be more useful for other transports that needed it for valid reasons. The MaxBurstLength length limits what can be transferred in sequence of data-in pdus _or_ like you describe a solicited data out sequence, doesn't it (see section 12.13)? We are more concerned with the data-in sequence here. If we have a READ of 1048576 bytes and a MaxBurstLength=524288 some targets were getting confused and instead of splitting up the transfer into multiple sequences it would assume there could be one sequence. So for those targets the MaxBurstLength becomes the max we can read and targets do fun things like drop connections if we send them something larger. Oh the flip side, targets also end up sending us more than MaxBurstLength bytes between r2ts. The initiator just prints an error and makes sure it does not go out of bounds because this is so common. We have to handle lots of fun bugs in targets. I bet targets do lots of weird things to handle our mess ups too :) And a sequence does not necessarily mean one pdu so MaxRecvDataSegmentLength does not matter in the discussion of max request size here (as long as we are talking about good behaving targets :)). Oh, where this transport level limit vs hw or queue vs software limit might also come in is if we do transport level requests through bsg and that ends up using the block layer. For that, if we wanted to send a nop-out with data we would have to make sure it is less than MaxRecvDataSegmentLength, right? I am not sure how all that will work out. Would that be some queue limit like a q-max_transport_request_size because we are using the queue and requests for transport level requests, or would we only check this at the iscsi level and return some new value to indicate the request was too large because of a transport limit? - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Infinite retries reading the partition table
On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
case MEDIUM_ERROR:
+ if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
+ sshdr.asc == 0x13 || /* AMNF DATA FIELD */
+ sshdr.asc == 0x14) { /* RECORD NOT FOUND */
+ return SUCCESS;
+ }
return NEEDS_RETRY;
If the complaint is true; i.e. infinite retries, this is just a bandaid
not a fix. What it's doing is marking the unrecoverable medium errors
for no retry. However, what we really need to know is why NEEDS_RETRY
isn't terminating after its allotted number of retries. Can we please
have a trace of this?
- if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
+ if (good_bytes
+ scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
return;
What exactly is this supposed to be doing? its result is identical to
the code it's replacing (because of the way scsi_end_request() processes
its second argument), so it can't have any effect on the stated problem.
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Infinite retries reading the partition table
--- James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
case MEDIUM_ERROR:
+ if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
+ sshdr.asc == 0x13 || /* AMNF DATA FIELD */
+ sshdr.asc == 0x14) { /* RECORD NOT FOUND */
+ return SUCCESS;
+ }
return NEEDS_RETRY;
If the complaint is true; i.e. infinite retries, this is just a bandaid
not a fix. What it's doing is marking the unrecoverable medium errors
for no retry. However, what we really need to know is why NEEDS_RETRY
isn't terminating after its allotted number of retries. Can we please
have a trace of this?
NEEDS_RETRY _does_ terminate, after it exhausts the retries. But since
by the ASC value we know that no amount of retries is going to work,
this chunk of the patch resolves it quicker, i.e. eliminates the
NEEDS_RETRY pointless retries (given the SK/ASC combination).
- if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
+ if (good_bytes
+ scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
return;
What exactly is this supposed to be doing? its result is identical to
the code it's replacing (because of the way scsi_end_request() processes
its second argument), so it can't have any effect on the stated problem.
I suppose this is true, but I'd rather it not even go in
scsi_end_request as (cmd, uptodate=1, good_bytes=0, retry=0) and complete
at the bottom as (cmd, uptodate=0, total_xfer, retry=0).
Luben
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] PCI : Move pci_fixup_device and is_enabled
On Wed, Nov 22, 2006 at 11:09:01AM -0700, Grant Grundler wrote:
On Wed, Nov 22, 2006 at 05:06:07PM +0900, Hidetoshi Seto wrote:
--- linux-2.6.19-rc6.orig/drivers/pci/pci.c
+++ linux-2.6.19-rc6/drivers/pci/pci.c
@@ -558,12 +558,18 @@
{
int err;
+ if (dev-is_enabled)
+ return 0;
This is unfortunately going to collide with the previous
patch posted by [EMAIL PROTECTED]:
Subject: [patch 0/2] pci: make pci_{enable,disable}_device() be nested
Grant, you were right. This has changed the logic around this area, and
the pci_enable_device() stuff conflicts with this.
Hidetoshi, I tried to merge things together, but I think I got it wrong,
as the logic is different now. Can you please respin this patch and
resend all of them?
Sorry for the delay,
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] Update Documentation/pci.txt
On Tue, Dec 05, 2006 at 11:26:51PM -0800, Greg KH wrote:
If this looks good, I'll post a diff for gregkh.
This looks very good, thanks for doing this work.
welcome - feels like the most significant contribution I've made
to kernel in a long time.
I do have a few minor comments:
I'll fix up the comments and post a diff in a few days.
Try to answer your questions below.
...
save_state Save a device's state before it is suspended.
There is no such callback. We have suspend, suspend_late,
resume_early, and resume. You might want to update this.
I'll review all the callbacks and verify we aren't missing any too.
Definitely want to update this. I'll add them but ask someone
else whose used those entry points rewrite my crap with a
seperate patch. I don't want to rathole on this patch.
...
driver_data Data private to the driver.
Most drivers don't need to use driver_data field.
Best practice is to use driver_data as an index
into a static list of equivalent device types,
instead of using it as a pointer.
Perhaps mention the PCI_DEVICE() and PCI_DEVICE_CLASS() macros to set
these fields properly?
Yes. Will add that.
Have a table entry {PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID}
PCI_DEVICE(PCI_ANY_ID, PCI_ANY_ID) is a bit smaller :)
ditto.
All fields are passed in as hexadecimal values (no leading 0x).
Users need pass only as many fields as necessary:
ovendor, device, subvendor, and subdevice fields default
to PCI_ANY_ID (),
oclass and classmask fields default to 0
odriver_data defaults to 0UL.
What's with the os here?
Those are supposed to be bullets.
Cute Story: I lost the first blank space on _every_ line when I messed up
my attempt to remove trailing whitespace in vi with :1,$ s/ *//.
I left out the $. :(
I didn't realize the mistake until a few minutes later and had to
hand edit every line to fix it up again. *ouch*
Lesson is to be more careful and save state before making global changes.
Once added, the driver probe routine will be invoked for any unclaimed
PCI devices listed in its (newly updated) pci_ids list.
Device drivers must initialize use_driver_data in the dynids struct
in their pci_driver struct prior to calling pci_register_driver in order
for the driver_data field to get passed to the driver. Otherwise, only a
0 (zero) is passed in that field.
Note that _no one_ uses this field, so it might go away soon...
When it's removed, the patch can remove that paragraph.
This is a seperate issue.
...
o If the driver is not a hotplug driver then use only
__init/__exit and __initdata/__exitdata.
No, don't say this, pci drivers are not hotplug drivers, and since
CONFIG_HOTPLUG is really hard to turn off these days, don't confuse
people with the devinit stuff. Everyone gets it wrong...
Yeah. I'll drop the is not a hotplug driver bullet item.
o Pointers to functions marked as __devexit must be created using
__devexit_p(function_name). That will generate the function
name or NULL if the __devexit function will be discarded.
I really recommend just not using any of these for almost all PCI
drivers, as the space savings just really isn't there...
Ok. fgrep found 321 instances of __devexit_p and thus I think we should
document it's use at a minimum. I'll just add Most PCI drivers don't need
to use __devexit.
thanks for the comments!
Expect the next rev this weekend sometime.
grant
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
lsscsi version 0.19 beta
The last announcement I made to this list about lsscsi was back in March and that was a beta for lsscsi version 0.18 . The change proposed by James Bottomley that prompted the beta has not materialized. So I decided to release version 0.18 without fanfare a week ago and start adding transport information to lsscsi, dubbing it version 0.19 beta. See http://www.torque.net/scsi/lsscsi.html for downloads. The mushrooming of information (and different representations) in /sys has made it possible for lsscsi to provide a lot more information than it has previously. Ironically what storage device identification really needs is not available, namely the logical unit _name_ which, for SCSI devices, is obtained from the device identification VPD page (0x83). As a consolation there is lots of transport information. So this beta adds transport information, both target and initiator (host) for these transports: - FC - SAS I hope to add iSCSI if I can find a way through its maze. Perhaps USB and 1394 are candidates as well, even SPI. In the case of SAS, both the SAS transport layer and the SAS class (i.e. Luben Tuikov's design) representations are supported. The new options are '--transport' (or '-t') and '--list' (or '-L'). Here is an example where disk strings are insufficient: # lsscsi [4:0:0:0]diskATA ST3160812AS D /dev/sda [4:0:1:0]diskSEAGATE ST336754SS 0003 /dev/sdb [4:0:2:0]diskSEAGATE ST336754SS 0003 /dev/sdc [4:0:3:0]diskATA ST380013AS 3.18 /dev/sdd [4:0:4:0]diskSEAGATE ST336754SS 0003 /dev/sde [4:0:5:0]diskSEAGATE ST336754SS 0003 /dev/sdf [5:0:0:0]diskSEAGATE ST336754SS 0003 /dev/sdg [5:0:1:0]diskSEAGATE ST336754SS 0003 /dev/sdh [5:1:0:0]diskSEAGATE ST336754SS 0003 /dev/sdi [5:1:1:0]diskSEAGATE ST336754SS 0003 /dev/sdj How many disks are there? Looking at the transport information: # lsscsi -t [4:0:0:0]disksas:0x0b1d2c035c7e5d4c /dev/sda [4:0:1:0]disksas:0x5000c55208ed /dev/sdb [4:0:2:0]disksas:0x5000c5520a29 /dev/sdc [4:0:3:0]disksas:0x500605b033e1 /dev/sdd [4:0:4:0]disksas:0x5000c55208ee /dev/sde [4:0:5:0]disksas:0x5000c5520a2a /dev/sdf [5:0:0:0]disksas:5000c55208ed/dev/sdg [5:0:1:0]disksas:5000c5520a29/dev/sdh [5:1:0:0]disksas:5000c55208ee/dev/sdi [5:1:1:0]disksas:5000c5520a2a/dev/sdj So everything is SAS attached, including two SATA disks. Something strange is happening with 4:0:0:0 which is directly attached to the host4. From the target SAS addresses it can be seen that /dev/sdc and /dev/sdh are the same port (and because the lun is 0 in both cases, it must be the same lu). There are three other pairs there, reducing what looks like 10 disks to six. The adjacent SAS addresses are dual ports on the same disk, so the actual number of disks is 4. Why are some SAS addresses prefixed with 0x and other not? lsscsi simply prints out what is in /sys ! To fetch further information about the target that contains /dev/sdf using a filter to reduce clutter: # lsscsi --transport --list 4:0:5:0 [4:0:5:0]disksas:0x5000c5520a2a /dev/sdf transport=sas initiator_port_protocols=none initiator_response_timeout=0 I_T_nexus_loss_timeout=1744 phy_identifier=11 ready_led_meaning=0 sas_address=0x5000c5520a2a target_port_protocols=ssp A similar check on the target containing /dev/sdj # lsscsi -t -L 5:1:1 [5:1:1:0]disksas:5000c5520a2a/dev/sdj transport=sas sub_transport=sas_class device_name= dev_type=end device iproto= iresp_timeout=0x linkrate=3,0 Gbps max_linkrate=3,0 Gbps max_pathways=1 min_linkrate=3,0 Gbps pathways=1 ready_led_meaning=0 rl_wlun=0 sas_addr=5000c5520a2a tproto=SSP transport_layer_retries=0 Finally here is a listing of hosts, then a listing of hosts with their initiator identifier (if known) and finally a closer look at host4 (with and without transport specific information): # lsscsi --hosts [0]sata_nv [1]sata_nv [2]sata_nv [3]sata_nv [4]mptsas [5]aic94xx # lsscsi --hosts --transport [0]sata_nv [1]sata_nv [2]sata_nv [3]sata_nv [4]mptsassas:0x500605b6f260 [5]aic94xx sas:5d10002dc000 # lsscsi -H -t --list 4 [4]mptsassas:0x500605b6f260 transport=sas device_type=end device initiator_port_protocols=smp, stp, ssp invalid_dword_count=0 loss_of_dword_sync_count=0 maximum_linkrate=3.0 Gbit maximum_linkrate_hw=3.0 Gbit minimum_linkrate=1.5 Gbit minimum_linkrate_hw=1.5 Gbit negotiated_linkrate=Unknown phy_identifier=0 phy_reset_problem_count=0 running_disparity_error_count=0
Re: lsscsi version 0.19 beta
Douglas Gilbert wrote: So this beta adds transport information, both target and initiator (host) for these transports: - FC - SAS I hope to add iSCSI if I can find a way through its maze. Perhaps USB and 1394 are candidates as well, even SPI. In case you find the ieee1394/sbp2 transport insufficiently integrated, please point it out. I'd try to implement what's missing as spare time permits and as far as it doesn't add excessive baggage. -- Stefan Richter -=-=-==- ==-- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
