Re: qla2xxx BUG: workqueue leaked lock or atomic
On 12:05, Mingming Cao wrote: BTW: Are ext3 filesystem sizes greater than 8T now officially supported? I think so, but I don't know how much 16TB testing developers and distros are doing - perhaps the linux-ext4 denizens can tell us? - IBM has done some testing (dbench, fsstress, fsx, tiobench, iozone etc) on 10TB ext3, I think RedHat and BULL have done similar test on 8TB ext3 too. Thanks. I'm asking because some days ago I tried to create a 10T ext3 filesytem on a linear software raid over two hardware raids, and it failed horribly. mke2fs from e2fsprogs-1.39 refused to create such a large filesystem but did it with -F, and I could mount it afterwards. But writing data immediately produced zillions of errors and only power-cycling the box helped. We're now using a 7.9T filesystem on the same hardware. That seems to work fine on 2.6.21-rc2, so I think this is an ext3 problem. I cannot completely rule out other reasons though as the underlying qla2xxx driver also had some problems on earlier kernels. We'd much rather have a 10T filesystem if possible. So if you have time to look into the issue I would be willing to recreate the 10T filesystem and send details. Regards Andre -- The only person who always got his work done by Friday was Robinson Crusoe signature.asc Description: Digital signature
Re: [PATCH 1/3] pci: New PCI-E reset API
Greg KH wrote: On Thu, Mar 08, 2007 at 02:44:26PM -0600, Brian King wrote: Greg, I saw you pulled this into your gregkh-2.6 tree. Does that mean it is queued for 2.6.22? Yes it is. Is that a problem? No problem at all. Thanks, Brian -- Brian King eServer Storage I/O IBM Linux Technology Center - 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: [stable] [patch 29/29] bug in gdth.c crashing machine
On Wed, Mar 07, 2007 at 07:50:14PM -0500, James Bottomley wrote:
On Wed, 2007-03-07 at 11:16 -0800, Andrew Morton wrote:
Achim did reply: http://lkml.org/lkml/2007/2/23/138
Ah ... OK; sorry, I'm parochial ... if it didn't appear on linux-scsi,
you can usually assume I haven't seen it.
So we don't know what the patch does, but it should be merged into
-stable
(and mainline, heaven forfend)
Well ... I would, except what this patch does is to initialise the
command sg_ranz field (for both 64 bit and 32 bit commands). If you
look in the code just below the patch application at the
if (scp-use_sg) {
...
} else if (scp-request_bufflen) {
...
}
You'll find a line setting these parameters in each of the cases of the
if statement. So the bug appears to be that there's a missing else
clause to this if, which would initialise the zero transfer commands.
Is that a correct analysis?
Well, as no one has really responded to this thread about what the patch
really does, and it's not in even James's tree yet, I've dropped it from
-stable.
If James does send it to Linus, I'll be glad to reconsider it at that
time.
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 ] mptsas: Fix oops for insmod during kexec
Hello,
This patch is to fix an oops on insmod for mptsas during kexec.
This applies to 2.6.21-rc3.
Signed-off-by: Judith Lebzelter [EMAIL PROTECTED]
---
Index: linux-2.6.21-rc3/drivers/message/fusion/mptsas.c
===
--- linux-2.6.21-rc3.orig/drivers/message/fusion/mptsas.c
+++ linux-2.6.21-rc3/drivers/message/fusion/mptsas.c
@@ -815,7 +815,7 @@ mptsas_taskmgmt_complete(MPT_ADAPTER *io
static int
mptsas_ioc_reset(MPT_ADAPTER *ioc, int reset_phase)
{
- MPT_SCSI_HOST *hd = (MPT_SCSI_HOST *)ioc-sh-hostdata;
+ MPT_SCSI_HOST *hd;
struct mptsas_target_reset_event *target_reset_list, *n;
int rc;
@@ -827,7 +827,10 @@ mptsas_ioc_reset(MPT_ADAPTER *ioc, int r
if (reset_phase != MPT_IOC_POST_RESET)
goto out;
- if (!hd || !hd-ioc)
+ if (!ioc-sh || !ioc-sh-hostdata)
+ goto out;
+ hd = (MPT_SCSI_HOST *)ioc-sh-hostdata;
+ if (!hd-ioc)
goto out;
if (list_empty(hd-target_reset_list))
-
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 ] mptsas: Fix oops for insmod during kexec
On Fri, Mar 09, 2007 at 01:07:44PM -0800, Judith Lebzelter wrote:
Hello,
This patch is to fix an oops on insmod for mptsas during kexec.
This applies to 2.6.21-rc3.
Signed-off-by: Judith Lebzelter [EMAIL PROTECTED]
---
Index: linux-2.6.21-rc3/drivers/message/fusion/mptsas.c
===
--- linux-2.6.21-rc3.orig/drivers/message/fusion/mptsas.c
+++ linux-2.6.21-rc3/drivers/message/fusion/mptsas.c
@@ -815,7 +815,7 @@ mptsas_taskmgmt_complete(MPT_ADAPTER *io
static int
mptsas_ioc_reset(MPT_ADAPTER *ioc, int reset_phase)
{
- MPT_SCSI_HOST *hd = (MPT_SCSI_HOST *)ioc-sh-hostdata;
+ MPT_SCSI_HOST *hd;
struct mptsas_target_reset_event *target_reset_list, *n;
int rc;
@@ -827,7 +827,10 @@ mptsas_ioc_reset(MPT_ADAPTER *ioc, int r
if (reset_phase != MPT_IOC_POST_RESET)
goto out;
- if (!hd || !hd-ioc)
+ if (!ioc-sh || !ioc-sh-hostdata)
+ goto out;
+ hd = (MPT_SCSI_HOST *)ioc-sh-hostdata;
+ if (!hd-ioc)
This needs a much better explanation. Please show the codepath
leading to 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 ] mptsas: Fix oops for insmod during kexec
On Friday, March 09, 2007 2:23 PM, Christoph Hellwig wrote: This needs a much better explanation. Please show the codepath leading to this. I was working with Judith on this patch earlier this week, so this is approved by LSI,,, ACK. This fix's an oops during driver load time. mptsas_probe calls mpt_attach(over in mptbase.c). Inside that call, we read some manufacturing config pages to setup some defaults. While reading the config pages, the firmware doesn't complete the reply in time, and we have a timeout. The timeout results in hardreset handler being called. The hardreset handler calls all the fusion upper layer driver reset callback handlers. The mptsas_ioc_reset function is the callback handler in mptsas.c. So where I'm getting to, is mptsas_ioc_reset is getting called before scsi_host_alloc is called, and the pointer ioc-sh is NULL.,,, as well as the hostdata. - 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: WRITE BUFFER commands through SG_IO getting rounded up to sector past 32k
My log messages were getting all mixed up, so I cleaned up my little test to send just one command at a time. It actually looks like the mid layer passes the command through to open-iscsi with the right size the first time, but then it sends a second command with request_bufflen = 0. I can verify that the command completed on the target just like the regular ones did, so there should be no reason for a retry of any sort. Here's the log for a 32896 byte command: Mar 9 11:27:43 ITX000c292c3c8d kernel: sg_open: dev=0, flags=0x802 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_add_sfp: sfp=0xcbadc000 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_reserve: req_size=32768 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32768, blk_size=32768 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_add_sfp: bufflen=32768, k_use_sg=1 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_ioctl: sg0, cmd=0x2285 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_common_write: scsi opcode=0x3b, cmd_size=10 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_start_req: dxfer_len=32896 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32896, blk_size=33280 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_write_xfer: num_xfer=32896, iovec_count=0, k_use_sg=2 Mar 8 11:27:43 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 32896 transfersize 32896 Mar 8 11:27:43 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 0 transfersize 0 Mar 8 11:27:44 ITX000c292c3c8d last message repeated 289 times Mar 8 11:27:44 ITX000c292c3c8d kernel: sg_release: sg0 Mar 8 11:27:44 ITX000c292c3c8d kernel: sg_fasync: sg0, mode=0 Mar 8 11:27:44 ITX000c292c3c8d kernel: sg_remove_sfp: worrisome, 1 writes pending Mar 8 11:27:44 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 0 transfersize 0 Mar 8 11:27:57 ITX000c292c3c8d last message repeated 3197 times Mar 8 11:27:57 ITX000c292c3c8d kernel: SysRq : Changing Loglevel Mar 8 11:27:57 ITX000c292c3c8d kernel: Loglevel set to 0 Mar 8 11:27:57 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 0 transfersize 0 For comparison, here's a 30 kB command: Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_open: dev=0, flags=0x802 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_add_sfp: sfp=0xcb826000 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_build_reserve: req_size=32768 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32768, blk_size=32768 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_add_sfp: bufflen=32768, k_use_sg=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_ioctl: sg0, cmd=0x2285 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_common_write: scsi opcode=0x3b, cmd_size=10 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_start_req: dxfer_len=30848 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_link_reserve: size=30848 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_write_xfer: num_xfer=30848, iovec_count=0, k_use_sg=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 30848 transfersize 30848 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_cmd_done: sg0, pack_id=0, res=0x0 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_finish_rem_req: res_used=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_unlink_reserve: req-k_use_sg=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_release: sg0 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_fasync: sg0, mode=0 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_remove_scat: k_use_sg=1 Here's a 33 kB command, which also goes through fine: Mar 8 12:21:53 ITX000c292c3c8d kernel: Kernel logging (proc) stopped. Mar 8 12:21:53 ITX000c292c3c8d kernel: Kernel log daemon terminating. Mar 8 12:21:54 ITX000c292c3c8d exiting on signal 15 Mar 8 12:21:54 ITX000c292c3c8d syslogd 1.4.1: restart. Mar 8 12:21:55 ITX000c292c3c8d kernel: klogd 1.4.1, log source = /proc/kmsg started. Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_open: dev=0, flags=0x802 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_add_sfp: sfp=0xcb9ef000 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_build_reserve: req_size=32768 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32768, blk_size=32768 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_add_sfp: bufflen=32768, k_use_sg=1 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_ioctl: sg0, cmd=0x2285 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_common_write: scsi opcode=0x3b, cmd_size=10 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_start_req: dxfer_len=33792 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=33792, blk_size=33792 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_write_xfer: num_xfer=33792, iovec_count=0, k_use_sg=2 Mar 8 12:22:43 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 33792 transfersize 33792 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_cmd_done: sg0, pack_id=0, res=0x0 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_finish_rem_req: res_used=0 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_remove_scat:
Re: WRITE BUFFER commands through SG_IO getting rounded up to sector past 32k
FYI, commenting out the sector roundup in sg_build_indirect ( blk_size = (blk_size + SG_SECTOR_MSK) (~SG_SECTOR_MSK); ) made everything work fine with my test and open-iscsi in general. I'm sure there's a glaringly obvious reason for that roundup (one that I'm unaware of), so I presume this isn't an acceptable solution, Aravind. [EMAIL PROTECTED] wrote: My log messages were getting all mixed up, so I cleaned up my little test to send just one command at a time. It actually looks like the mid layer passes the command through to open-iscsi with the right size the first time, but then it sends a second command with request_bufflen = 0. I can verify that the command completed on the target just like the regular ones did, so there should be no reason for a retry of any sort. Here's the log for a 32896 byte command: Mar 9 11:27:43 ITX000c292c3c8d kernel: sg_open: dev=0, flags=0x802 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_add_sfp: sfp=0xcbadc000 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_reserve: req_size=32768 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32768, blk_size=32768 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_add_sfp: bufflen=32768, k_use_sg=1 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_ioctl: sg0, cmd=0x2285 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_common_write: scsi opcode=0x3b, cmd_size=10 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_start_req: dxfer_len=32896 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32896, blk_size=33280 Mar 8 11:27:43 ITX000c292c3c8d kernel: sg_write_xfer: num_xfer=32896, iovec_count=0, k_use_sg=2 Mar 8 11:27:43 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 32896 transfersize 32896 Mar 8 11:27:43 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 0 transfersize 0 Mar 8 11:27:44 ITX000c292c3c8d last message repeated 289 times Mar 8 11:27:44 ITX000c292c3c8d kernel: sg_release: sg0 Mar 8 11:27:44 ITX000c292c3c8d kernel: sg_fasync: sg0, mode=0 Mar 8 11:27:44 ITX000c292c3c8d kernel: sg_remove_sfp: worrisome, 1 writes pending Mar 8 11:27:44 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 0 transfersize 0 Mar 8 11:27:57 ITX000c292c3c8d last message repeated 3197 times Mar 8 11:27:57 ITX000c292c3c8d kernel: SysRq : Changing Loglevel Mar 8 11:27:57 ITX000c292c3c8d kernel: Loglevel set to 0 Mar 8 11:27:57 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 0 transfersize 0 For comparison, here's a 30 kB command: Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_open: dev=0, flags=0x802 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_add_sfp: sfp=0xcb826000 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_build_reserve: req_size=32768 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32768, blk_size=32768 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_add_sfp: bufflen=32768, k_use_sg=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_ioctl: sg0, cmd=0x2285 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_common_write: scsi opcode=0x3b, cmd_size=10 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_start_req: dxfer_len=30848 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_link_reserve: size=30848 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_write_xfer: num_xfer=30848, iovec_count=0, k_use_sg=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: iscsi_queuecommand: opcode 3b request_bufflen 30848 transfersize 30848 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_cmd_done: sg0, pack_id=0, res=0x0 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_finish_rem_req: res_used=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_unlink_reserve: req-k_use_sg=1 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_release: sg0 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_fasync: sg0, mode=0 Mar 8 11:24:20 ITX000c292c3c8d kernel: sg_remove_scat: k_use_sg=1 Here's a 33 kB command, which also goes through fine: Mar 8 12:21:53 ITX000c292c3c8d kernel: Kernel logging (proc) stopped. Mar 8 12:21:53 ITX000c292c3c8d kernel: Kernel log daemon terminating. Mar 8 12:21:54 ITX000c292c3c8d exiting on signal 15 Mar 8 12:21:54 ITX000c292c3c8d syslogd 1.4.1: restart. Mar 8 12:21:55 ITX000c292c3c8d kernel: klogd 1.4.1, log source = /proc/kmsg started. Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_open: dev=0, flags=0x802 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_add_sfp: sfp=0xcb9ef000 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_build_reserve: req_size=32768 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=32768, blk_size=32768 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_add_sfp: bufflen=32768, k_use_sg=1 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_ioctl: sg0, cmd=0x2285 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_common_write: scsi opcode=0x3b, cmd_size=10 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_start_req: dxfer_len=33792 Mar 8 12:22:43 ITX000c292c3c8d kernel: sg_build_indirect: buff_size=33792, blk_size=33792 Mar 8 12:22:43 ITX000c292c3c8d kernel:
