Re: [PATCH 0/2] fusion SAS support
On Fri, Aug 26, 2005 at 05:15:11PM -0600, Moore, Eric Dean wrote:
I apologize its taking so long to review the patches you sent last
week, but I have been swamped working issues for many different customers.
I only began looking at your patches last night. Here are some comments:
+ ioc-sas_ports[i] = sas_port_add(ioc-sh, i, attrs);
+ if (IS_ERR(ioc-sas_ports[i])) {
+ error = PTR_ERR(ioc-sas_ports[i]);
+ goto out_free_ports;
+ }
This code is only attaching ports for the direct ports. I have
a LSI SAS1064 - 4 ports - so it only reports four ports.
I see:
/sys/class/sas_port/port-4:0
/sys/class/sas_port/port-4:1
/sys/class/sas_port/port-4:2
/sys/class/sas_port/port-4:3
In my configuration I have SASx12 sitting on the 3rd port.
Expander support is not there in your version of the driver.
Yes, as noted in the transport class announcement this doesn't
deal with expanders yet at all.
How do you propose to report the expanders 12 ports that is attached to
/sys/class/sas_port/port-4:3 ?? Will I see all the 12 ports added
to /sys/class/sas_port/ or should these ports be inside
/sys/class/sas_port/port-4:3 ?? Such as
/sys/class/sas_port/port-4:3/port-12:0
/sys/class/sas_port/port-4:3/port-12:1
/sys/class/sas_port/port-4:3/port-12:2
/sys/class/sas_port/port-4:3/port-12:3
If so, then the sas_transport code needs to change.
In the /sys/class/ hierachy they will have to be flat due to the
way the generic class_device code works. No it's still open whether
we will have a flat hierachy of class_devices or whether we'll attach
extender ports to the struct device of the parent port. I'll prefer
the former because it keeps the hierachy simpler and mirrors what is
done in FibreChannel, James prefers the latter. I'll probably prototype
both.
+ if (*phy_counter = ioc-num_sas_ports) {
+ sas_add_target(ioc-sas_ports[pg0-PhysicalPort],
+ ioc-sas_attached[pg0-PhysicalPort],
+ pg0-Bus, pg0-TargetID)
My expander has 7 devices attached. There is 5 SATA and 2 SAS devices.
From the function mptsas_probe_attached_device - this will
call Sas Device Page 0, this containing all the devices seen in
the domain. The function sas_add_target() will be called
for all seven devices, to include the SMP expander; e.g. 8 times.
During the time it called sas_add_target() 8 times, its sending the same
ioc-sas_ports and ioc-sas_attached data pointers because all 8
devices are at pg0-PhysicalPort=3. Thus how will setup the
12 ports for expander? The information regarding
these 12 ports can be obtained via Sas Expander Page 1.
I guess we can add this to the function mptsas_probe_phy() so ports for
direct attached and expanders are reported? What do you think, or
did you have another idea bout this? I'm not sure about how
calling sas_port_add() 4 times for the HBA, and 12 times
for the exander, how that would be populating the tree. I guess you want
to wait till you recieve the expander to comment on this?
I think getting the NDA and docs is more important. What I really
want to do is to call scsi_scan_target for every sas device that's a scsi
target, so that we can support multi-lun devices easily and coherently with
other SCSI transports. Now I need to figure out how to properly get
information out of the Fusion firmware to only report attached sas devices,
not individual luns, and I need to make sure different sas devices never
get the same target id, so scsi_scan_device does the right thing. This
could mean I need to the work I suggested to Luben in a previous mail to
make -id meaningless for SAS and similar transports, or a scsi midlayer
to fusion target id mapping.
Additional comments:
Loading the driver as modules - will not work because its missing
EXPORT_SYMBOL(mptbase_sas_persist_operation) in mptbase.c
ok.
We have Integrated RAID support for SAS - thus in my code(3.02.55) I have
broken out the RAID related parameters from typedef _ScsiCfgData
into another structure called _RaidCfgData - I would suggest
picking up these changes.
The changes have conflict with James' RAID and DV changes, so I only want
to merge them over after James' chanhes are in.
Hot plug support - how is this going to be done. Take a look
at mptscsih_hot_plug_worker_thread, that I sent in 3.02.55.
We'll probably have a workqueue for it in the transport class, but hotplug
support isn't on the top of my TODO list, so it'll have to wait a little.
-
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
correct deregistration from scsi_transport_fc
Hi, What is the correct sequence to register and deregister host/rport/scsi_devices at the scsi stack? ZFCP's sequence is like follows: scsi_add_host fc_remote_port_add (if port succesfully configured/opened in/by zfcp) scsi_add_device (if unit successfully configured/opened in/by zfcp) If a zfcp-adapter is set offline I do the following to get rid of the entries within /sys/class/fc_*: fc_remote_port_delete (for each rport registered for this adapter) fc_remove_host scsi_remove_host Setting zfcp adapters offline it happens that the entries target0:0:0 for the old host_id 0 are still present in /sys/class/fc_transport. The symlink device points to a non-existent directory ../../../devices/css0/0.0.000f/0.0.50d3/host0/rport-0:0-0/target0:0:0 of the removed host. I observed the same behaviour when trying to delete the SCSI device using its delete attribute before removing the host. Furthermore I put some printk into the release function for the SCSI device (scsi_device_dev_release in scsi_scan.c) but this funtion is never called -- neither if the delete attribute was used nor when the host was completely removed. Is there a problem with proper deregistration of kobjects for SCSI devices in the SCSI subsystem if fc_transport is used? Or is this obvious memory leak caused by a wrong usage of the scsi_transport_fc interface? Any thoughts about this problem? Regards, Andreas - 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: correct deregistration from scsi_transport_fc
On Mon, Aug 29, 2005 at 10:38:17AM +0200, Andreas Herrmann wrote: Hi, What is the correct sequence to register and deregister host/rport/scsi_devices at the scsi stack? ZFCP's sequence is like follows: scsi_add_host fc_remote_port_add (if port succesfully configured/opened in/by zfcp) scsi_add_device (if unit successfully configured/opened in/by zfcp) Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. If a zfcp-adapter is set offline I do the following to get rid of the entries within /sys/class/fc_*: fc_remote_port_delete (for each rport registered for this adapter) fc_remove_host scsi_remove_host fc_remove_host removes all rports for you. - 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: correct deregistration from scsi_transport_fc
On 29.08.2005 10:48 Christoph Hellwig [EMAIL PROTECTED] worte: Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? Or is it mere a recommendation not to stick to scsi_add_device but to use the automatic LUN scanning provided with fc_transport code? fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. Regards, Andreas - 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: correct deregistration from scsi_transport_fc
On Mon, Aug 29, 2005 at 12:02:15PM +0200, Andreas Herrmann wrote: On 29.08.2005 10:48 Christoph Hellwig [EMAIL PROTECTED] worte: Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? It works by accident, but I will veto any updates you're going to send for this broken behaviour. fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. That's intentional. See the discussion during development of the FC transport class. I don't like that behaviour but it's a compromise we agreed on. - 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: correct deregistration from scsi_transport_fc
There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. We know. We fixed it with the latest machine generation and corresponding HBA (IBM System z9). The solution is N_Port Identifier Virtualization (NPIV, see recent FC standard documents), i.e. a SAN identity for each virtual HBA. However, there will be older machines with older HBA's around for some time. We will have to cater for those as well. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. Correct. But there is another problem inherent in this setup. Without NPIV, we can't share access to the same LUN, e.g. LUN 0, through virtual HBAs hosted by the same physical HBA, in order to avoid several issues as to SCSI compliance (sense data delivery, reserve/release, abort task set, mode pages changes, etc.). That is why, we require manual setup of LUNs to be accessed through sysfs, so far. It is desirable to go with REPORT LUNs for NPIV-capable virtual HBAs, while keeping some compatability code in zfcp for non-NPIV virtal HBAs. Martin Peschke |-+ | | Christoph Hellwig| | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | .kernel.org | | || | || | | 29/08/2005 13:03 | | || |-+ ---| | | | To: Andreas Herrmann/Germany/[EMAIL PROTECTED] | | cc: Christoph Hellwig [EMAIL PROTECTED], James Bottomley [EMAIL PROTECTED], Linux SCSI| |linux-scsi@vger.kernel.org, [EMAIL PROTECTED] | | Subject: Re: correct deregistration from scsi_transport_fc | | | ---| On Mon, Aug 29, 2005 at 12:02:15PM +0200, Andreas Herrmann wrote: On 29.08.2005 10:48 Christoph Hellwig [EMAIL PROTECTED] worte: Never use scsi_add_device with the fc_transport code. fc_remote_port_add will do a proper lun scan if the added rport is a scsi target. Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? It works by accident, but I will veto any updates you're going to send for this broken behaviour. fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. That's intentional. See
scsi_prep_fn/scsi_request_fn may fail to put scsi_cmnds
I ran into a problem where scsi_device_cancel encounters scsi_cmnds that
have request pointers that point to freed memory. In one case, the
command was in SCSI_STATE_FINISHED/SCSI_OWNER_HIGHLEVEL; in another it
was SCSI_STATE_UNUSED/SCSI_OWNER_NOBODY. This is where it happens:
1155 list_for_each_entry(scmd, sdev-cmd_list, list) {
1156 if (scmd-request scmd-request-rq_status !=
RQ_INACTIVE) {
This was on a kernel built with the following options:
[*] Kernel debugging
[*] Magic SysRq key
[*] Debug memory allocations
[*] Spinlock debugging
[*] Sleep-inside-spinlock checking
[*] Highmem debugging
[*] Compile the kernel with debug info
[*] Compile the kernel with frame pointers
[*] Check for stack overflows
[ ] Kprobes
[*] Stack utilization instrumentation
[*] Page alloc debugging
[ ] Collect scheduler statistics (NEW)
Doing hba hot remove with disk stress.
This happened on a 2.6.9 kernel (RHEL4), but the involved code looks the
same to me in later kernels.
As best I can tell, there are two problems:
1. In some cases where scsi_prep_fn returns BLKPREP_KILL, it doesn't
take into account the fact that the request may already be associated
with a scsi_command... as would be the case if the request had been
requeued (so it had already been thru scsi_prep_fn before). In this
case, scsi_put_command needs to get called on those commands to remove
them from the device's cmd_list. Otherwise, the BLKPREP_KILL return will
cause the request to get freed, and the command is left hanging out on
the cmd_list where scsi_device_cancel finds it. This is the
SCSI_STATE_FINISHED/SCSI_OWNER_HIGHLEVEL case.
2. scsi_request_fn also has a problem... after calling elv_next_request,
it does a check on !scsi_device_online(sdev). Under this case, if the
device isn't online the request gets freed... but scsi_put_command
doesn't get called on the command that scsi_prep_fn had attached to the
request. Again, the scsi_cmnd is left on the device's cmd_list. This is
the SCSI_STATE_UNUSED/SCSI_OWNER_NOBODY case.
I put together a patch (at the bottom of this email) which seems to fix
the problem. I'm not suggesting that this is the best possible way to
fix it... my patch calls a routine from scsi_prep_fn when BLKPREP_KILL
is about to be returned, and this routine duplicates the logic already
contained in scsi_prep_fn to detect if the request is associated with a
command. I'd rather have the fix worked into the prep_fn somehow. But I
felt a bit nervous re-arranging too much of this code (didn't want to
cause more problems than I'm fixing), and I didn't see a straightforward
way to do it. So I'm wondering if anyone on this list might have any
suggestions for a better way to fix this?
Thanks!
Nate Dailey
Stratus Technologies
here's the patch...
Signed-off-by: Nate Dailey [EMAIL PROTECTED]
--- scsi_lib.c.orig 2005-08-26 15:35:08.0 -0400
+++ scsi_lib.c 2005-08-26 15:31:10.0 -0400
@@ -969,6 +969,31 @@ static int scsi_issue_flush_fn(request_q
return -EOPNOTSUPP;
}
+/* If a scsi_cmnd has already been attached to this request, call
+ scsi_put_command on it. This attempts to duplicate the logic below
+ for deciding if a command has been attached (I'd like a less
+ repetitious way to do this). */
+static void scsi_prep_fn_kill (struct request *req)
+{
+ struct scsi_cmnd *cmd = NULL;
+
+ if (req-flags REQ_SPECIAL)
+ {
+ struct scsi_request *sreq = req-special;
+
+ if (sreq-sr_magic != SCSI_REQ_MAGIC)
+ cmd = req-special;
+ }
+ else if (req-flags (REQ_CMD | REQ_BLOCK_PC))
+ {
+ if (req-special)
+ cmd = req-special;
+ }
+
+ if (cmd)
+ scsi_put_command(cmd);
+}
+
static int scsi_prep_fn(struct request_queue *q, struct request *req)
{
struct scsi_device *sdev = q-queuedata;
@@ -983,6 +1008,7 @@ static int scsi_prep_fn(struct request_q
if (unlikely(!scsi_device_online(sdev))) {
printk(KERN_ERR scsi%d (%d:%d): rejecting I/O to
offline device\n,
sdev-host-host_no, sdev-id, sdev-lun);
+ scsi_prep_fn_kill (req);
return BLKPREP_KILL;
}
if (unlikely(sdev-sdev_state != SDEV_RUNNING)) {
@@ -993,6 +1019,7 @@ static int scsi_prep_fn(struct request_q
* at all allowed down */
printk(KERN_ERR scsi%d (%d:%d): rejecting I/O
to dead device\n,
sdev-host-host_no, sdev-id,
sdev-lun);
+ scsi_prep_fn_kill (req);
return BLKPREP_KILL;
}
/* OK, we only allow special commands (i.e. not
@@ -1029,6 +1056,7 @@ static int scsi_prep_fn(struct request_q
printk(KERN_ERR scsi%d (%d:%d): rejecting I/O
to device being removed\n,
sdev-host-host_no,
Re: [RFC] SCSI EH document
On 08/29/05 05:14, Tejun Heo wrote:
Both all the list-heads need to be cleared, otherwise there may be list
corruption next time the element is added to the list_head.
scmd-eh_entry is never used as list head. It's always used as list
entry. So, technically, it needs not be cleared, I think. No? The
problem we had was w/ shost-eh_cmd_q not being cleared.
In your strategy routine:
...
spin_lock_irqsave(shost-host_lock, flags);
list_splice_init(shost-eh_cmd_q, error_q);
spin_unlock_irqrestore(shost-host_lock, flags);
...
loop {
...
list_del_init(cmd-eh_entry);
...
}
A good policy to follow is:
1. Never leave prev/next pointing somewhere where
- you don't belong, or
- where you don't know existance is in place.
2. Someone (memory release?) may do:
if (!list_empty(cmd-eh_entry))
Refuse to free the memory.
Which is often the case to check if the object belongs to
a list. (You shouldn't have to do this but case pointed only for
illustrational purposes.)
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
ips init / kdump
This patch, applied to ips version 7.12.02 in the 2.6.13 kernel, fixes an
initialization bug found with kdump.
If I/O is active on the adapter, and an unexpected interrupt is pending
during initialization, the driver blows it's brains out. Since the driver
didn't initiate the I/O, the data in it's internal tables will contain NULL
pointers.
When this condition is detected, a flush cache and reset is performed.
The flush cache allows any pending lazy writes that the adapter is
processing to complete ( a must have for a RAID adapter ) and the reset
puts the adapter back into a known, good state.
Signed-off-by: Jack Hammer [EMAIL PROTECTED]
--- a/drivers/scsi/ips.cMon Aug 8 12:22:19 2005
+++ b/drivers/scsi/ips.cMon Aug 8 12:22:08 2005
@@ -358,6 +358,9 @@
static int ips_init_phase1(struct pci_dev *pci_dev, int *indexPtr);
static int ips_register_scsi(int index);
+static int ips_poll_for_flush_complete(ips_ha_t * ha);
+static void ips_flush_and_reset(ips_ha_t *ha);
+
/*
* global variables
*/
@@ -4807,6 +4810,9 @@
uint32_t bits;
METHOD_TRACE(ips_is_init_morpheus, 1);
+
+ if (ips_isintr_morpheus(ha))
+ ips_flush_and_reset(ha);
post = readl(ha-mem_ptr + IPS_REG_I960_MSG0);
bits = readl(ha-mem_ptr + IPS_REG_I2O_HIR);
@@ -4818,6 +4824,93 @@
else
return (1);
}
+
+//
+/* */
+/* Routine Name: ips_flush_and_reset*/
+/* */
+/* Routine Description: */
+/* */
+/* Perform cleanup ( FLUSH and RESET ) when the adapter is in an unknown */
+/* state ( was trying to INIT and an interrupt was already pending ) ... */
+/* */
+//
+static void
+ips_flush_and_reset(ips_ha_t *ha)
+{
+ ips_scb_t *scb;
+ int ret;
+ int time;
+ int done;
+ dma_addr_t command_dma;
+
+ /* Create a usuable SCB */
+ scb = pci_alloc_consistent(ha-pcidev, sizeof(ips_scb_t), command_dma);
+ if (scb) {
+ memset(scb, 0, sizeof(ips_scb_t));
+ ips_init_scb(ha, scb);
+ scb-scb_busaddr = command_dma;
+
+ scb-timeout = ips_cmd_timeout;
+ scb-cdb[0] = IPS_CMD_FLUSH;
+
+ scb-cmd.flush_cache.op_code = IPS_CMD_FLUSH;
+ scb-cmd.flush_cache.command_id = IPS_MAX_CMDS; /* Use an ID that
would otherwise not exist */
+ scb-cmd.flush_cache.state = IPS_NORM_STATE;
+ scb-cmd.flush_cache.reserved = 0;
+ scb-cmd.flush_cache.reserved2 = 0;
+ scb-cmd.flush_cache.reserved3 = 0;
+ scb-cmd.flush_cache.reserved4 = 0;
+
+ ret = ips_send_cmd(ha, scb); /* Send the Flush
Command */
+
+ if (ret == IPS_SUCCESS) {
+ time = 60 * IPS_ONE_SEC; /* Max Wait time
is 60 seconds */
+ done = 0;
+
+ while ((time 0) (!done)) {
+ done = ips_poll_for_flush_complete(ha);
+ /* This may look evil, but it's only done during extremely
rare start-up conditions ! */
+ udelay(1000);
+ time--;
+ }
+}
+ }
+
+ /* Now RESET and INIT the adapter */
+ (*ha-func.reset) (ha);
+
+ pci_free_consistent(ha-pcidev, sizeof(ips_scb_t), scb, command_dma);
+ return;
+}
+
+//
+/* */
+/* Routine Name: ips_poll_for_flush_complete*/
+/* */
+/* Routine Description: */
+/* */
+/* Poll for the Flush Command issued by ips_flush_and_reset() to complete */
+/* All other responses are just taken off the queue and ignored */
+/* */
+//
+static int
+ips_poll_for_flush_complete(ips_ha_t * ha)
+{
+ IPS_STATUS cstatus;
+
+ while (TRUE) {
+ cstatus.value = (*ha-func.statupd) (ha);
+
+ if (cstatus.value == 0x) /* If No Interrupt to process
*/
+ break;
+
+
Re: [PATCH] Allow both megaraid drivers to be built
On Mon, Aug 29, 2005 at 03:50:19PM +0100, Daniel Drake wrote: ifdef on other drivers is bogus, please remove the pci ids completely from the old driver. It'd probably be a good idea to rename it to megaraid_legacy aswell. I've also asked the LSI Engineers whether they could help identifying what code could be remove when only supporting the two oldes chips but haven't gotten a reply yet. I hope they'll be able to answer when they're less busy. - 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: Some interesting results in the aic7xxx slowdown problem
On Thu, 2005-08-25 at 16:09 +0530, Suparna Bhattacharya wrote: On Fri, Aug 19, 2005 at 09:22:45AM -0400, James Bottomley wrote: On Fri, 2005-08-19 at 15:24 +0530, Suparna Bhattacharya wrote: sda: Well, this line is identifying the root cause. It says that the partition code came up with no partitions for this device. Do any of your other devices come up with paritions? (as in could this be a simple device node transposition issue?) Yes, it looks like that. The ordering now seems to be id 9, 10, ... 14, 0, 1, 2, instead of the default of id 0, 1, 2 ... Did you expect a change in probe ordering ? When I switch back to the old AIC driver the ordering goes back to default. Er, boggle! I know of no change to the new driver that could affect the target scanning order (this is target, not lun, right?). Target scan should be handled sequentially in the mid-layer (scsi_scan.c) in a for loop that runs from 0 to 15 (well shost-max_id). There is a reverse_order flag, could that be set somehow? 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: correct deregistration from scsi_transport_fc
On 29.08.2005 13:03 Christoph Hellwig [EMAIL PROTECTED] wrote: Won't work for all zSeries FC host adapters because they are virtualized and you can have several virtual adapters using the same WWPN/WWNN. Using LUN masking and zoning it is not possible to configure the SAN such that one virtual adapter sees just that LUNs that are supposed to be used by it. There is a tool to write an access control table to the adapter. This ACT specifies which virtual adapter can access which ports and FCP LUNs ... That's totally broken. most FC sans have zoning and access control, but this is by no way a feature of the HBA. Your feature is totally broken, different from other FC setups and must go away. Of course, also in my opinion this is not the optimal way to virtualize adapters. But that is how the hardware works. I cannot change this. zfcp just can exploit the hardware as is. And therefor zfcp needs for compatibility reasons the scsi_add_device interface. A REPORT LUNs scan from adapter X of port Y might report thousands of LUNs that I don't like to use with adapter X because they are for another virtual adapter. So what? That's the same as for every FC SAN, and it is nessecary to support proper managment applications. The main point is that we do not want that all LUNs that are reported by REPORT LUNS are configured for the virtual adapter. I think Martin Peschke gave you further information about this. BTW, are there any proper management applications for Linux (all architectures, based on which interface)? Thats the reason why I like to stick to manual configuration (triggered from zfcp) of scsi_devices. Hence zfcp has not enabled a proper lun scan when fc_remote_port_add is called. slave_alloc will fail for scsi_devices not added by zfcp itself. (BTW, new FC cards that are already announced will provide a feature called NPort Id Virtualization. With this feature each virtual adapter will have its own WWPN. This will allow zfcp to use the lun scan during fc_remote_port_add.) Do you mean, that scsi_add_device is not supposed to work with fc_transport code anymore? It works by accident, but I will veto any updates you're going to send for this broken behaviour. So scsi_add_device will soon be mentioned in Documentation/feature-removal-schedule.txt? What is the rationale of proscribing usage of scsi_add_device() when scsi_transport_fc is used? fc_remove_host removes all rports for you. Ok, works. But it still fails to remove the scsi target representation of that rport. That's intentional. See the discussion during development of the FC transport class. I don't like that behaviour but it's a compromise we agreed on. Where is the function to remove the scsi target representation of an rport? You did not agree on having memory leaks in the kernel, did you? Regards, Andreas - 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 3/16] qla2xxx: Correct ISP24xx soft-reset handling.
On Fri, 26 Aug 2005, James Bottomley wrote:
On Fri, 2005-08-26 at 19:08 -0700, Andrew Vasquez wrote:
WRT_REG_DWORD(reg-ctrl_status,
CSRX_ISP_SOFT_RESET|CSRX_DMA_SHUTDOWN|MWB_4096_BYTES);
- RD_REG_DWORD(reg-ctrl_status);
+ /*
+* It is necessary to delay here since the card doesn't respond
+* to PCI reads during a reset. On some architectures this will
+* result in an MCA.
+ */
+ udelay(100);
Removing the read introduces a potential write posting bug, doesn't?
Possibly, but that has been the case all software drivers have had to
contend with after an ISP soft-reset:
...
/* Reset ISP chip. */
WRT_REG_WORD(reg-ctrl_status, CSR_ISP_SOFT_RESET);
/* Wait for RISC to recover from reset. */
if (IS_QLA2100(ha) || IS_QLA2200(ha) || IS_QLA2300(ha)) {
/*
* It is necessary to for a delay here since the
* card doesn't respond to PCI reads during a
* reset. On some architectures this will
* result in an MCA.
*/
udelay(20);
...
During the soft-reset, the ISP cannot respond to the MMIO read until
completion. On several platforms, the subsequent readl() without the
delay would cause machine checks.
Unfortunately, this has been a risk we've come to accept. We're still
evaluating the possibility of using a config-space read as a means of
flushing any posted writes -- since the RISC state-machines can handle
the request while resetting. I'll ping the hardware folks again, but
in the interim, the udelay() will need to be present.
--
Andrew Vasquez
-
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] minimal SAS transport class
On Fri, Aug 26, 2005 at 03:24:06PM -0400, Jeff Garzik wrote: Luben Tuikov wrote: Even simpler: the transport layer, calls SCSI Core, saying: Hey here is a pointer to struct scsi_domain_device. If you want, you an send REPORT LUNS and other things to it. For the SG_IO ioctl, /dev/sg and request_queue usage, SCSI core must map an address (currently HCIL) into a scsi_domain_device pointer. These upper layer kernel elements rely on this SCSI address, and rely on the fact that SCSI core can route from a block device straight to a SCSI LLD, using nothing more than this SCSI address. What's a scsi_domain_device? Anyway, we don't need any HCIL tuple for all of the above. SG_IO is done on a blockdevice node, /dev/sg is done on a chardevice node. Each of them are attached to a request_queue that's known at the time their -probe routine is setup - no need for HCIL here _at all_. There's actually only few userland interfaces that use HCIL addressing: the scanning through /sys/.../scan (or the old /proc/scsi/scsi variant), using WWNs for FC and SAS here would be much nicer, but there's a huge backwards-compatiblity issue - we'll probably have to support the old variant forever. Besides that there's probably only SCSI_IOCTL_GET_IDLUN, which is superceeded by sysfs but probably still has tons of users in hardware probing, managment utilities and all kinds of userland. - 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] minimal SAS transport class
On 08/29/05 13:11, Christoph Hellwig wrote: On Fri, Aug 26, 2005 at 03:24:06PM -0400, Jeff Garzik wrote: Luben Tuikov wrote: Even simpler: the transport layer, calls SCSI Core, saying: Hey here is a pointer to struct scsi_domain_device. If you want, you an send REPORT LUNS and other things to it. For the SG_IO ioctl, /dev/sg and request_queue usage, SCSI core must map an address (currently HCIL) into a scsi_domain_device pointer. These upper layer kernel elements rely on this SCSI address, and rely on the fact that SCSI core can route from a block device straight to a SCSI LLD, using nothing more than this SCSI address. What's a scsi_domain_device? Anyway, we don't need any HCIL tuple for all of the above. SG_IO is done on a blockdevice node, /dev/sg is done on a chardevice node. Each of them are attached to a request_queue that's known at the time their -probe routine is setup - no need for HCIL here _at all_. There's actually only few userland interfaces that use HCIL addressing: the scanning through /sys/.../scan (or the old /proc/scsi/scsi variant), using WWNs for FC and SAS here would be much nicer, but there's WWNs *must not* be visible _at_all_ to anyone above the SAS layer, in the kernel. That is, the transport addressing method *must not* be visible to SCSI Core or anyone above it, in the kernel. Else you'll end up with another HCIL... (if you get the irony). a huge backwards-compatiblity issue - we'll probably have to support the old variant forever. Besides that there's probably only SCSI_IOCTL_GET_IDLUN, If there's no userspace dependency, the kernel can do anything it wants. Since HCIL is SCSI Core crud, let SCSI Core invent HCIL tuples and support them. Luben which is superceeded by sysfs but probably still has tons of users in hardware probing, managment utilities and all kinds of userland. - 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: fibre channel/multipath questions
I think you can setup dm-multipath based on WWNs, so the device numbers don't matter. Cc'ed the dm-devel list to verify my assumption. - 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] Allow both megaraid drivers to be built
Christoph Hellwig wrote: ifdef on other drivers is bogus, please remove the pci ids completely from the old driver. It'd probably be a good idea to rename it to megaraid_legacy aswell. I've also asked the LSI Engineers whether they could help identifying what code could be remove when only supporting the two oldes chips but haven't gotten a reply yet. I hope they'll be able to answer when they're less busy. Thanks for the feedback. Here's a new patch. Rename megaraid to megaraid_legacy, changing the filenames, sysfs name, module name, and the messages printed out via printk. I have left the procfs name as megaraid as presumably userspace tools rely on this. Remove hardware ID's from megaraid_legacy which overlap with the newgen megaraid drivers. Allow megaraid_legacy to be built alongside the newgen driver. Signed-off-by: Daniel Drake [EMAIL PROTECTED] As the patch is large (300K) I am not including it in this mail. You can get it here: http://dev.gentoo.org/~dsd/megaraid_legacy.patch Thanks, Daniel - 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] minimal SAS transport class
On Mon, Aug 29, 2005 at 01:20:50PM -0400, Luben Tuikov wrote: What's a scsi_domain_device? Anyway, we don't need any HCIL tuple for all of the above. SG_IO is done on a blockdevice node, /dev/sg is done on a chardevice node. Each of them are attached to a request_queue that's known at the time their -probe routine is setup - no need for HCIL here _at all_. There's actually only few userland interfaces that use HCIL addressing: the scanning through /sys/.../scan (or the old /proc/scsi/scsi variant), using WWNs for FC and SAS here would be much nicer, but there's WWNs *must not* be visible _at_all_ to anyone above the SAS layer, in the kernel. That is, the transport addressing method *must not* be visible to SCSI Core or anyone above it, in the kernel. Please read the sentence again. I said accept them in the scan attribute, that does _NOT_ mean adding knowledge to the scsi layer. In fact if you through the linux-scsi archives about the problems those attributes had with the FC transport class I suggested moving the parsing of these attributes into the transport class, which would be the preferred method to implement this. - 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] minimal SAS transport class
On 08/29/05 13:16, Christoph Hellwig wrote: No need to do silly renaming, but yes, moving creating of scsi_target I'd do the silly renaming. I'd also create struct scsi_domain_device, and do scsi_register_domain_device(). You know, clean slate... structures to the transport does make sense. It's kinda implicit There is *nothing* implicit in a Software Project Specification! Everything must be completely explicit. in the todo list I posted. I also don't really see the point of the embedded kobject. You will, once I post my code. Think, - Hotplugging. - More than one owner from above. That is, on a transport you can have a diverse set of devices. What if queuecommand() was *not* the only way to send a task to the device? ;-) We actually already have a list in the scsi_target that chains of the scsi_device, .devices in scsi_target and .same_target_siblings in scsi_device. We just need to use it everywhere. Yes, I've seen all this. And I'm sorry to say, but it is *UGLY AS HELL!* As I said: before implementing an object by a structure in a software project one has to ask themselves what that object is? How will it play with the rest of the objects existsing or to be designed? What are the dependencies and what is the dependency graph? Etc. First it starts with a white sheet of paper, pencil on one side and a spec on the other. Yes. that's what I ment with my item (3) (sorry, I hate all this techno-babble, simple language is much easier to understand normally) Ok, sorry, it's that software specificaion tehcno-babble thing talking through me again. 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] minimal SAS transport class
On Mon, 2005-08-29 at 18:16 +0100, Christoph Hellwig wrote: No need to do silly renaming, but yes, moving creating of scsi_target structures to the transport does make sense. It's kinda implicit in the todo list I posted. I also don't really see the point of the embedded kobject. You might want to dust off the Mike Christie patch that did this. The one that eventually went in the tree was James Smarts to stop FC drivers oopsing on remove/add lun. There already is an embedded kobject in the scsi_target structure (it's in struct device) and that's what we use to make it visible in the sysfs tree. 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: [PATCH] minimal SAS transport class
On 08/29/05 13:31, Luben Tuikov wrote: On 08/29/05 13:16, Christoph Hellwig wrote: No need to do silly renaming, but yes, moving creating of scsi_target I'd do the silly renaming. I'd also create struct scsi_domain_device, and do scsi_register_domain_device(). You know, clean slate... structures to the transport does make sense. It's kinda implicit There is *nothing* implicit in a Software Project Specification! Everything must be completely explicit. in the todo list I posted. I also don't really see the point of the embedded kobject. You will, once I post my code. Think, - Hotplugging. - More than one owner from above. That is, on a transport you can have a diverse set of devices. What if queuecommand() was *not* the only way to send a task to the device? ;-) Forgot to mention one more thing, which I'm sure you're aware of: *If* the kobject hierarchy is set right, then kobject_get() gets this object and _all_ objects which are parents of this object. And kobject_put() puts all objects which are parent of this object, including calling the release method of each.(*) You'll need this to support hotplugging on the fly... Luben (*) Thus if your sysfs tree is built as the physical world looks(**), you lock the object(s) when you use them, so that if any intervening object is removed and you get an event notification for it, you know what to do... ;-) (**) Which the transport class doesn't give you, since it was never _designed_ for that purpose... unless of course you slice-it-and-dice-it pretty well. ;-) We actually already have a list in the scsi_target that chains of the scsi_device, .devices in scsi_target and .same_target_siblings in scsi_device. We just need to use it everywhere. Yes, I've seen all this. And I'm sorry to say, but it is *UGLY AS HELL!* As I said: before implementing an object by a structure in a software project one has to ask themselves what that object is? How will it play with the rest of the objects existsing or to be designed? What are the dependencies and what is the dependency graph? Etc. First it starts with a white sheet of paper, pencil on one side and a spec on the other. Yes. that's what I ment with my item (3) (sorry, I hate all this techno-babble, simple language is much easier to understand normally) Ok, sorry, it's that software specificaion tehcno-babble thing talking through me again. 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 - 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
Possible bug in qla2xxx rev. 8.00.02
Hi,
I have a controller with a firmware bug that mishandles
underrun situations for inquiry commands. It correctly
sets the FCP_RESID_UNDER flag however it miscalculates
the FCP_RESID count. The 7.05.00 Qlogic driver for 2.4.x
kernels thinks frame(s) were lost and retries the command
20 times with no success:
if (!(scsi_status SS_RESIDUAL_UNDER)) {
ha-dropped_frame_error_cnt++;
CMD_RESULT(cp) = DID_BUS_BUSY
16;
DEBUG2(printk(KERN_INFO
scsi(%ld): Dropped
frame(s) detected (%x
of %x
bytes)...retrying
command.\n,
ha-host_no,
resid,
CMD_XFRLEN(cp));)
break;
}
Just wondering why the 8.00.02 driver for 2.6.x kernels did not
detect this transport error ? Latest Emulex and LSI drivers did
not detect this either ???
Thanks,
Frank
-
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 0/2] fusion SAS support
On Monday, August 29, 2005 2:01 AM, Christoph Hellwig wrote:
The expander with one crossover cable has been shipped to you
this morning. The crossover should be connected to phy0 on the expander.
/sys/class/sas_port/port-4:3/port-12:0
/sys/class/sas_port/port-4:3/port-12:1
/sys/class/sas_port/port-4:3/port-12:2
/sys/class/sas_port/port-4:3/port-12:3
If so, then the sas_transport code needs to change.
In the /sys/class/ hierachy they will have to be flat due to the
way the generic class_device code works. No it's still open whether
we will have a flat hierachy of class_devices or whether we'll attach
extender ports to the struct device of the parent port. I'll prefer
the former because it keeps the hierachy simpler and mirrors what is
done in FibreChannel, James prefers the latter. I'll
probably prototype
both.
Does flat means all sas hbas and expanders would reside in
/sys/class/sas_port ??
How would one figure out the topology parent-child relationship
between hbas-expanders? I think with large topologies having everything
on the same level will be very messy.
I think getting the NDA and docs is more important.
That is on the way being worked. Hopefully very soon.
I have the spec sitting here next to me.
Ask if you have doubts on anything, and I will explain.
What I really
want to do is to call scsi_scan_target for every sas device
that's a scsi
target, so that we can support multi-lun devices easily and
coherently with
other SCSI transports. Now I need to figure out how to properly get
information out of the Fusion firmware to only report
attached sas devices,
not individual luns, and I need to make sure different sas
devices never
get the same target id, so scsi_scan_device does the right
thing. This
could mean I need to the work I suggested to Luben in a
previous mail to
make -id meaningless for SAS and similar transports, or a
scsi midlayer
to fusion target id mapping.
I will explain - in this loop below in your sas patch:
+ if (*phy_counter = ioc-num_sas_ports) {
+ sas_add_target(ioc-sas_ports[pg0-PhysicalPort],
+ ioc-sas_attached[pg0-PhysicalPort],
+ pg0-Bus, pg0-TargetID);
+ } else
add this check below - before calling sas_add_target,
so you will get the unique scans for each valid scsi target.
The SMP devices and phys entries for the direct hba phys will be ignored:
if (le32_to_cpu(sasDevicePg0-DeviceInfo)
(MPI_SAS_DEVICE_INFO_SSP_TARGET |
MPI_SAS_DEVICE_INFO_STP_TARGET |
MPI_SAS_DEVICE_INFO_SATA_DEVICE )) {
Also - I suggest maintaining a link list of devices in
the driver when sas_add_target is called.
This having the sas address, and respective HCTL mapping, and
other properties. Something similar to the function called
mpt_sas_get_info() in the 3.02.55 driver.
Thus if you decide to make -id meaningless for SAS(Lubens thread),
the scsi core could merely send sas address, or maybe an object, or handle,
or what ever you decide.
Thus the driver could map back to the created object/handle when
sas_add_target occured.
Then for queue command, it can take the object/handle, then translate
to internal bus/target mapping so SCSI_IO request can be sent to
the firmware as its is today.
Hot plug support - how is this going to be done. Take a look
at mptscsih_hot_plug_worker_thread, that I sent in 3.02.55.
We'll probably have a workqueue for it in the transport
class, but hotplug
support isn't on the top of my TODO list, so it'll have to
wait a little.
What ever you decide. Just to let you know the sas firmware send
device_added and device_not_responding events, so we know when
when devices come and go. We also have events for raid volumes
being added and removed on the fly, and the corresponding hidden phys disk
coming and going as well. The current hotplug workqueue in the driver is
handling
raid and non-raid events for devices coming and going.
Something for you to consider when you get around to looking at hot plug.
Eric Moore
-
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: Oops on scsi_remove_target
Andrew Morton wrote: James Bottomley [EMAIL PROTECTED] wrote: [c01042ac] die+0xfa/0x19c [c0115200] do_page_fault+0x239/0x6ee [c0103ad7] error_code+0x4f/0x54 [c0193aaa] sysfs_remove_link+0x1b/0x1d [c0227691] class_device_del+0x8e/0xed This is known and reported and the fix is here: http://marc.theaimsgroup.com/?l=linux-scsim=112398346008284 Andrew, Greg, could we do something about getting this fix in. It's in sysfs, so I can't really push it. Well it may not be right, but it looks fine as a fix-for-2.6.13-coz-gregs-on-vacation. Could you send me the diff? I'll add it to today's batch-of-patches-to-send-to-linus-after-having-worked-out-wtf-git-has-done-this-time. So I guess this missed the boat, since I just hit the same oops on 2.6.13. Steve - 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: Megaraid and Dell PERC 4 controllers
FYI - Resending due to failure on previous sending. -Original Message- From: Ju, Seokmann Sent: Friday, August 26, 2005 11:00 AM To: 'Jonathan Fischer' Cc: Kolli, Neela Syam Subject: RE: Megaraid and Dell PERC 4 controllers Hi Jonathan, On Tuesday, August 23, 2005 4:52 PM, Jonathan Fischer wrote: I think next up I'm trying writethru mode, instead of write back, but has anyone seen anything like this, or have any insight they might offer? I'm quickly getting to the point of being stumped. Can you please specify detail system configuration? (memory size, # of cpus) And, what kind of load are you putting on the system when it locks up. Also, I assuem that the system doesn't have any monitoring applications running for those PERC controllers. Please confirm this. From the message, the controller takes more than 3 minutes to return certain I/O requests and it leads system to lock up. Thank you. Seokmann -Original Message- From: Jonathan Fischer [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 4:52 PM To: linux-scsi@vger.kernel.org Subject: Megaraid and Dell PERC 4 controllers I apologize if this is the wrong list to ask this kind of question on; I've posted on Dell's PowerEdge list and Red Hat's lists as well, but I figure the people here might know better what to try for this problem. I have 2 Dell PowerEdge 2850's, one with a PERC 4e/DC raid controller, and the other with a PERC 4e/Di. On both of these systems, I can reliably cause the controllers to lock up under heavy load. This is using a fully up-to-date Red Hat 4 EL (non x86_64) installation on both computers. The controllers use the megaraid_mbox driver. During a period of high load, the controller suddenly seems to stop responding to the driver, causing the driver to go into a waiting loop for it. It waits 3 minutes for the controller to respond, which it never does, and then takes the controller offline, pretty much yanking the filesystem out from underneath the OS. Some things keep running alright, so (working with Red Hat's support) I got the thing set up to netdump to another server to see if we could figure out what was going wrong. The kernel never actually crashes, so netdump doesn't produce a vmcore to look through, but syslog keeps spouting out information, so I've got that. Every time this lockup occurs, the log file looks like this: megaraid: aborting-29762 cmd=2a c=2 t=0 l=0 megaraid abort: 29762:21[255:128], fw owner megaraid: aborting-29763 cmd=2a c=2 t=0 l=0 megaraid abort: 29763:39[255:128], fw owner megaraid: aborting-29764 cmd=2a c=2 t=0 l=0 megaraid abort: 29764:16[255:128], fw owner megaraid: aborting-29768 cmd=2a c=2 t=0 l=0 megaraid abort: 29768:53[255:128], fw owner This part repeats 64 times, then... megaraid: aborting-29831 cmd=2a c=2 t=0 l=0 megaraid abort: 29831:8[255:128], fw owner megaraid: resetting the host... megaraid: 64 outstanding commands. Max wait 180 sec megaraid mbox: Wait for 64 commands to complete:180 megaraid mbox: Wait for 64 commands to complete:175 megaraid mbox counts down to 0, and then... megaraid mbox: critical hardware error! megaraid: resetting the host... megaraid: hw error, cannot reset megaraid: resetting the host... megaraid: hw error, cannot reset SCSI error : 0 2 0 0 return code = 0x600 end_request: I/O error, dev sda, sector 242938701 Buffer I/O error on device dm-4, logical block 9893952 lost page write due to I/O error on dm-4 scsi0 (0:0): rejecting I/O to offline device The commands that the driver are waiting for are always the same, except for the sequence number (the number right after aborting- and abort: ). And there are always 64 commands backed up that the driver is waiting for. Both machines in question pass memtest86 and Dell's diagnostic sets, and since the failure is identical in both I don't believe it's bad hardware. We've got the latest BIOS, RAID firmware, and backplane firmware on the machines. I've also tried: - the RHEL 4 Update 2 Beta kernel (at Red Hat's suggestion) - RHEL 4 x86_64 - RHEL 3 x86_64 - Fedora Core 4 x86 - disabling Patrol Read in the RAID bios - disabling read-ahead in the RAID bios - changing the writeback cache flush to every 2 seconds, instead of the default 4 I think next up I'm trying writethru mode, instead of write back, but has anyone seen anything like this, or have any insight they might offer? I'm quickly getting to the point of being stumped. Jonathan Fischer Operating Systems Analyst - CSU San Marcos [EMAIL PROTECTED] - 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 - To
Re: [RFC] SCSI EH document
Tejun Heo wrote: Hi, Jeff. Jeff Garzik wrote: Tejun Heo wrote: Both all the list-heads need to be cleared, otherwise there may be list corruption next time the element is added to the list_head. scmd-eh_entry is never used as list head. It's always used as list entry. So, technically, it needs not be cleared, I think. No? The problem we had was w/ shost-eh_cmd_q not being cleared. Every node is a list_head. You want all pointers for all nodes pointing to something useful, even if they are not actively present on a list, so that they may be easily and corrected added to a list at a later time. Read list_del_init() for example. Jeff Okay... to make things clearer. A struct list_head can have two roles. list head : other list_head gets added to it list entry : gets added to other list_head When a struct list_head acts as list head, it always needs to be in clean (pointing to valid things) state before being used. When a struct list_head acts as list entry, its current content doesn't matter. AFAICS, scmd-eh_entry is currently not used as list head in any place, neither do we use list_empty() test on it to determine whether or not it's on a list. The original code does clear scmd-eh_entry all the time and I am very okay with that. I just wanted to make sure that I didn't miss something regarding scmd-eh_entry's usage. If I'm missing such a usage, can you please point out? I'm mainly talking at a higher level. While it strictly doesn't matter in this instance, in general its a bad idea to clear a list using a list = (null) operation. Its a good way to leak references, leak memory, etc. In this specific case it seems to be OK. Jeff - 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 scsi-misc 2/2] megaraid_sas: LSI Logic MegaRAID SAS RAID D river
Looks pretty good to me. Small issues I've identified: - what do you need the hba_count attribute for? This should be implementable in userspace pretty easily by iterating of all devices of the scsi_host class that are attached to the driver - the -queuecommand cleanup patch I sent you a awhile ago doesn't seem to be applied - there's quite a lot of slightly odd formating, it would be nice if you could run the code through scripts/Lindent. If you could sent out an unmangled patch (even as attachment or on LSI's ftp side) I'd like to take another, closer look. - 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] zfcp: add rports to enable scsi_add_device to work again
On 27.08.2005 19:38 James Bottomley [EMAIL PROTECTED] wrote: this patch fixes a severe problem with 2.6.13-rc7. Due to recent SCSI changes it is not possible to add any LUNs to the zfcp device driver anymore. With registration of remote ports this is fixed. Please integrate the patch in the 2.6.13 kernel or if it is already too late for this release then please integrate it in 2.6.13.1 Thanks a lot. Well, OK, but your usage isn't quite optimal. The fibre channel transport class retains a list of ports per host, so your maintenance of an identical list in zfcp_adapter duplicates this. I know what you mean. It would be better to store all private zfcp data at dd_data in fc_rport. Unfortunately it won't fit to zfcp's current behaviour. The rport depends on a specific host_id. Even the name of the rport in sys/class/fc_remote_port inherits this id. This means if the host is deregistered and registered again the old rport structure is useless because new host_ids are assigned. Or do I miss something here? The zfcp_port structure is thought to be persistent if once configured by the user, i.e. even if the host is deregistered and registered again the port structure is kept. I am not sure at the moment how this can be solved with the current fc_transport. I think it would have been better to use the WWPN of an rport as the name in sys/class/fc_remote_port. This would be a start to keep rport structures independent of the host_id. (Why should the transport depend on OS assigned ids anyway? The transport has already unique identifiers like WWPNs.) However, we can put this in for now and worry about removing all of the fc transport class duplication from zfcp later. James In any case attributes provided by an rport should be removed from the zfcp_port structure. This is what I will do next. Regards, Andreas - 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 scsi-misc 1/2] megaraid_sas: LSI Logic MegaRAID SAS RAID D river
On Thu, Aug 25, 2005 at 05:38:24PM -0400, Bagalkote, Sreenivas wrote: Hello All, After a couple of false starts early on, I am re-submitting the MegaRAID's SAS based RAID driver for your review. Your mailer seems to wrap lines and eat whitespaces.. - 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: 2.6: how do I this in sysfs?
On Mon, Aug 29, 2005 at 12:24:18PM -0500, Miller, Mike (OS Dev) wrote: This is after my minimal sas transport class, please also read the thread about it on linux-scsi In the referenced code for using sysfs, there only appear to be methods for reading attributes. How about if we want to cause a command to get written out to the hardware? Do we do something like this? /* get a semaphore keep everyone else out while we're working, and hope like hell that all the other processes are playing nice and using the semaphore too, or else we're hosed. */ get_some_kind_of_semaphore(); try flock() on the /sys/blah/blah/ directory. That should keep userspace happy. I think it only takes a small sysfs patch to make this work (or it might work today, don't remember, sorry...) Or look into using configfs instead. 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
[PATCH] fix compiler warning in aic7770
Fix compiler warning in drivers/scsi/aic7xxx/aic7770.c :
drivers/scsi/aic7xxx/aic7770.c:129: warning: unused variable `l'
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/scsi/aic7xxx/aic7770.c |1 -
1 files changed, 1 deletion(-)
--- linux-2.6.13-orig/drivers/scsi/aic7xxx/aic7770.c2005-08-29
01:41:01.0 +0200
+++ linux-2.6.13/drivers/scsi/aic7xxx/aic7770.c 2005-08-30 01:08:22.0
+0200
@@ -126,7 +126,6 @@ aic7770_find_device(uint32_t id)
int
aic7770_config(struct ahc_softc *ahc, struct aic7770_identity *entry, u_int io)
{
- u_long l;
int error;
int have_seeprom;
u_int hostconf;
-
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: 2.6: how do I this in sysfs?
On Mon, 29 Aug 2005 12:24:18 -0500, Miller, Mike (OS Dev) [EMAIL PROTECTED] wrote: This is after my minimal sas transport class, please also read the thread about it on linux-scsi In the referenced code for using sysfs, there only appear to be methods for reading attributes. How about if we want to cause a command to get written out to the hardware? Do we do something like this? /* get a semaphore keep everyone else out while we're working, and hope like hell that all the other processes are playing nice and using the semaphore too, or else we're hosed. */ [...] release_some_kind_of_semaphore(); I'm not suggesting that the above is a good idea. I don't have a good idea about how to do this. Take a look at hwmon drivers, it is nowhere near so bad as you think. 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
