Re: proc_name in sysfs
On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote: > Hello, > > > We are using HBAs modules names from "proc_name" interface in sysfs: > /sys/class/scsi_host/hostX/proc_name. > > But with new Emulex drivers (8.0.21 and +), proc_name is reporting > (previous drivers were reporting "lpfc"). > => In the driver code, .proc_name field from scsi_host_template structure > is no more initialized. > James Smart told us that the "removal" of .proc_name field (not really > removed, but no more initialized) was part of the /proc interfaces removal > (suggested by scsi-linux feedback). > > So: > 1/ now, what is the aim of proc_name interface (reporting "") in > sysfs ? > 2/ now, how can we get the adapter module name from sysfs ? > > => I'm just thinking that .proc_name field has to be kept initialized > and/or something has to be changed to replace the confusing "proc" prefix. The real problem is that someone decided to export the proc_name in sysfs. It's supposed to be only procfs-specific but someone violated that rule. Not sure how to proceed forward with 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: proc_name in sysfs
On Thu, Apr 07, 2005 at 08:35:16AM +0200, Frederic TEMPORELLI wrote: > Hi, > > > Sorry, no such "driver" directory in /sys/class/scsi_host/hostX/ Doug answered that. > >>Why do you need it? If you answer the above you might get better/other suggestions. -- Patrick Mansfield - 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: proc_name in sysfs
On Thu, Apr 07, 2005 at 11:06:03AM +1000, Douglas Gilbert wrote: > Patrick Mansfield wrote: > >On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote: > > > > > >>2/ now, how can we get the adapter module name from sysfs ? > > > > > >Why do you need it? > Patrick, > lsscsi currently uses proc_name so it needs to be > changed to use the above logic (if LLDs are going > to stop populating proc_name). Oops, I didn't notice, I had assumed it was using the sysfs layout. Yes, seems like it should use the sysfs driver info, proc_name is rather useless in sysfs context. > It has been suggested that I extend lsscsi to show > transport info (as seen from the HBA) found in the > various *_transport directories in sysfs. As an option that sounds nice. > Also I have been thinking about ways to list less > tha all scsi devices. For example: "lsscsi 1:0:3:0" > to look at one device and "lsscsi 1:-" for all scsi > devices hanging off host1. I'm not sure whether > "lsscsi /dev/sda" is a good idea. Any suggestions? Sounds good, but maybe not (directly) for /dev. udevinfo can supply that, it has a /dev to /sys mapping: [elm3b79 patman]$ udevinfo -q path -n /udev/mydisk-sdag /block/sdm -- Patrick Mansfield - 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: iomapping a big endian area
On Monday, April 4, 2005 7:25 am, James Bottomley wrote: > On Mon, 2005-04-04 at 15:16 +0100, Christoph Hellwig wrote: > > The IOC4 device that provides IDE, serial ports and external interrupts > > on Altix systems has a big endian register layour, and the PCI-X bridge > > in those Altix systems can do the swapping if a special bit is set. > > > > In older kernels that bit was set from the driver through a special API, > > but it seems the firmware does that automatically now. > > We already have some unusual code in drivers to support other altix > design ... features ... do you regard this as something that's likely to > be replicated on other platforms, or is it more in the category of a one > off mistake that can be corrected in firmware? The whole line of altix pci bridges can do byteswapping, so it's more than just one product that could benefit (however slightly). Not sure about other bridges though. Jesse - 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: [SCSI] Driver Broken in 2.6.x (attemp 2)
Hi, Just wamted to ask if anyone has some will into it, or if this driver shoudl be removed from the kernel as broken. -- pozdrawiam |"Help me master, I felt the burning twilight behind [EMAIL PROTECTED]|those gates of stell..." --Perihelion, Prophecy Sequence - 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] drivers/scsi/sg.c: fix problems when sg_remove is called before sg_release
This is my first attempt at submitting a patch, so I hope I'm not making any
mistakes...
This patch fixes two problems I came across in sg, both of which occur when
sg_remove is called on a disk which hasn't yet been sg_release'd:
1. I got the following Oops in sg_remove:
--
Unable to handle kernel paging request at virtual address e0a58020
printing eip:
e0a7ceba
*pde = 1c245c8b
Oops: [#1]
SMP
CPU:3
EIP:0060:[]Tainted: G U
EFLAGS: 00210246 (2.6.5-7.139-bigsmp )
EIP is at sg_remove+0xba/0x240 [sg]
eax: dfee0500 ebx: ecx: dfeefa50 edx: dfee05a8
esi: edi: c7beb000 ebp: e0a58000 esp: daf4bec0
ds: 007b es: 007b ss: 0068
Process bash (pid: 27436, threadinfo=daf4a000 task=dbcd3350)
Stack: c10c1840 00d0 0001 0152 00200246 df844000
e0a84d08
df844240 e0857ec0 e0857f24 c0263dff e0857f0c df844240 df9d3028
df9d3000
fffa c0263e78 df844000 e08449be df9d3000 df844000
fffa
Call Trace:
[] class_device_del+0x5f/0xd0
[] class_device_unregister+0x8/0x10
[] scsi_remove_device+0x3e/0xc0 [scsi_mod]
[] proc_scsi_write+0x269/0x2a0 [scsi_mod]
[] vfs_write+0xc6/0x160
[] do_mmap2+0xdd/0x170
[] sys_write+0x91/0xf0
[] sysenter_past_esp+0x52/0x71
Code: 8b 45 20 e8 ce 2a 70 df c7 45 20 00 00 00 00 8b 45 1c e8 ef
--
It looks like sg_remove needs to hold the sg_dev_arr_lock a little longer.
After sg_remove dropped the lock, sg_release/sg_remove_sfp came along and
freed the sdp... and then sg_remove tried to do cdev_del(sdp->cdev). I made
a change to get what we need from the sdp while holding the lock, and it
fixed the problem for me.
2. Scsi_device references are never released: after sg_remove sets the
detached flag, sg_release won't call scsi_device_put. But someone needs to
release the reference obtained in sg_open. A change also needs to be made in
sg_remove_sfp to call scsi_device_put if freeing sdp--since sg_release
wouldn't be able to do it in that case. I verified (by sticking a printk in
scsi_device_dev_release) that the scsi_device wasn't freed in this case,
without my change in place.
To provoke these, I used a few 'dd if=/dev/sg2 of=/dev/null' commands to
hold the device open. I then did 'echo "scsi remove-single-device 1 0 0 0" >
/proc/scsi/scsi' to trigger the sg_remove.
This patch is against 2.6.12-rc2, though I actually found/fixed the problems
in 2.6.5-7.139 (SLES9 SP1).
Do these look okay?
Nate Dailey
Stratus Technologies
Signed-off-by: Nate Dailey <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2/drivers/scsi/sg.c.orig 2005-04-06
14:17:51.0 -0400
+++ linux-2.6.12-rc2/drivers/scsi/sg.c 2005-04-06 15:25:08.0 -0400
@@ -318,9 +318,7 @@ sg_release(struct inode *inode, struct f
SCSI_LOG_TIMEOUT(3, printk("sg_release: %s\n",
sdp->disk->disk_name));
sg_fasync(-1, filp, 0); /* remove filp from async notification list
*/
if (0 == sg_remove_sfp(sdp, sfp)) { /* Returns 1 when sdp gone
*/
- if (!sdp->detached) {
- scsi_device_put(sdp->device);
- }
+ scsi_device_put(sdp->device);
sdp->exclude = 0;
wake_up_interruptible(&sdp->o_excl_wait);
}
@@ -1574,19 +1572,28 @@ sg_remove(struct class_device *cl_dev)
sg_nr_dev--;
break;
}
- write_unlock_irqrestore(&sg_dev_arr_lock, iflags);
if (sdp) {
+ struct cdev *tmp_cdev;
+ struct gendisk *tmp_disk;
+ int free_sdp = 0;
+
+ tmp_cdev = sdp->cdev;
+ sdp->cdev = NULL;
+ tmp_disk = sdp->disk;
+ sdp->disk = NULL;
+ if (NULL == sdp->headfp) free_sdp = 1;
+ write_unlock_irqrestore(&sg_dev_arr_lock, iflags);
+
sysfs_remove_link(&scsidp->sdev_gendev.kobj, "generic");
class_simple_device_remove(MKDEV(SCSI_GENERIC_MAJOR, k));
- cdev_del(sdp->cdev);
- sdp->cdev = NULL;
+ cdev_del(tmp_cdev);
devfs_remove("%s/generic", scsidp->devfs_name);
- put_disk(sdp->disk);
- sdp->disk = NULL;
- if (NULL == sdp->headfp)
+ put_disk(tmp_disk);
+ if (free_sdp)
kfree((char *) sdp);
}
+ else write_unlock_irqrestore(&sg_dev_arr_lock, iflags);
if (delay)
msleep(10); /* dirty detach so delay device destruction
*/
@@ -2550,6 +2557,7 @@ sg_remove_sfp(Sg_device * sdp, Sg_fd * s
}
if (k < maxd)
sg_dev_arr[k] = NULL;
+ scsi_device_put(sdp->device);
kfree((char *) sdp);
res = 1;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More m
Increasing MAX_SECTORS in blkdev.h
Hi, I wanted to increase the number of sectors that could be requested/Written per SCSI READ(10)/WRITE command , and varying MAX_SECTORS in blkdev.h helped me to do it. However I could not request more than 256 sectors and could not write more than 1024 inspite of changing MAX_SECTORS to higher numbers. Why is that? There is probably some other variable that should be varied. Please let me know. I am working on the UNH iSCSI initiator driver , and am on kernel 2.4.29 . Sai __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs - 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] aacraid 2.6: Address sparse warnings
This patch addresses the sparse -Wbitwise warnings that Christoph wanted
me to eliminate. This mostly consisted of making data structure
elements of hardware associated structures the __le* equivalent.
Although there were a couple places where there was mixing of cpu and le
variable math. These changes have been tested on both an x86 and ppc
machine running bonnie++.
Signed-off-by: Mark Haverkamp <[EMAIL PROTECTED]>
= drivers/scsi/aacraid/aachba.c 1.35 vs edited =
--- 1.35/drivers/scsi/aacraid/aachba.c 2005-03-30 09:40:26 -08:00
+++ edited/drivers/scsi/aacraid/aachba.c2005-04-04 11:25:30 -07:00
@@ -562,7 +562,7 @@
inqstrcpy ("V1.0", str->prl);
}
-void set_sense(u8 *sense_buf, u8 sense_key, u8 sense_code,
+static void set_sense(u8 *sense_buf, u8 sense_key, u8 sense_code,
u8 a_sense_code, u8 incorrect_length,
u8 bit_pointer, u16 field_pointer,
u32 residue)
@@ -813,7 +813,7 @@
aac_io_done(scsicmd);
}
-int aac_read(struct scsi_cmnd * scsicmd, int cid)
+static int aac_read(struct scsi_cmnd * scsicmd, int cid)
{
u32 lba;
u32 count;
@@ -1893,7 +1893,9 @@
}
/* hba wants the size to be exact */
if(byte_count > scsicmd->request_bufflen){
- psg->sg[i-1].count -= (byte_count -
scsicmd->request_bufflen);
+ u32 temp = le32_to_cpu(psg->sg[i-1].count) -
+ (byte_count - scsicmd->request_bufflen);
+ psg->sg[i-1].count = cpu_to_le32(temp);
byte_count = scsicmd->request_bufflen;
}
/* Check for command underflow */
@@ -1922,7 +1924,7 @@
{
struct aac_dev *dev;
unsigned long byte_count = 0;
- u64 le_addr;
+ u64 addr;
dev = (struct aac_dev *)scsicmd->device->host->hostdata;
// Get rid of old data
@@ -1943,16 +1945,18 @@
byte_count = 0;
for (i = 0; i < sg_count; i++) {
- le_addr = cpu_to_le64(sg_dma_address(sg));
- psg->sg[i].addr[1] = (u32)(le_addr>>32);
- psg->sg[i].addr[0] = (u32)(le_addr & 0x);
+ addr = sg_dma_address(sg);
+ psg->sg[i].addr[0] = cpu_to_le32(addr & 0x);
+ psg->sg[i].addr[1] = cpu_to_le32(addr>>32);
psg->sg[i].count = cpu_to_le32(sg_dma_len(sg));
byte_count += sg_dma_len(sg);
sg++;
}
/* hba wants the size to be exact */
if(byte_count > scsicmd->request_bufflen){
- psg->sg[i-1].count -= (byte_count -
scsicmd->request_bufflen);
+ u32 temp = le32_to_cpu(psg->sg[i-1].count) -
+ (byte_count - scsicmd->request_bufflen);
+ psg->sg[i-1].count = cpu_to_le32(temp);
byte_count = scsicmd->request_bufflen;
}
/* Check for command underflow */
@@ -1962,15 +1966,14 @@
}
}
else if(scsicmd->request_bufflen) {
- dma_addr_t addr;
+ u64 addr;
addr = pci_map_single(dev->pdev,
scsicmd->request_buffer,
scsicmd->request_bufflen,
scsicmd->sc_data_direction);
psg->count = cpu_to_le32(1);
- le_addr = cpu_to_le64(addr);
- psg->sg[0].addr[1] = (u32)(le_addr>>32);
- psg->sg[0].addr[0] = (u32)(le_addr & 0x);
+ psg->sg[0].addr[0] = cpu_to_le32(addr & 0x);
+ psg->sg[0].addr[1] = cpu_to_le32(addr >> 32);
psg->sg[0].count = cpu_to_le32(scsicmd->request_bufflen);
scsicmd->SCp.dma_handle = addr;
byte_count = scsicmd->request_bufflen;
= drivers/scsi/aacraid/aacraid.h 1.30 vs edited =
--- 1.30/drivers/scsi/aacraid/aacraid.h 2005-03-29 09:31:47 -08:00
+++ edited/drivers/scsi/aacraid/aacraid.h 2005-04-04 11:17:51 -07:00
@@ -15,6 +15,8 @@
#define AAC_MAX_HOSTPHYSMEMPAGES (0xf)
+#define LE32_ALL_ONES ((__force __le32)0x)
+
/*
* These macros convert from physical channels to virtual channels
*/
@@ -89,11 +91,21 @@
* on 64 bit systems not all cards support the 64 bit version
*/
struct sgentry {
+ __le32 addr; /* 32-bit address. */
+ __le32 count; /* Length. */
+};
+
+struct user_sgentry {
u32 addr; /* 32-bit address. */
u32 count; /* Length. */
};
struct sgentry64 {
+ __le32 addr[2];/* 64-bit addr. 2 pieces for data alignment */
+ __le32 count; /* Length. */
+};
+
+struct user_sgentry64 {
u32 addr[2];
Re: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, Apr 07 2005, James Bottomley wrote: > On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote: > > I think Christophs point is that why add sdev_lock as a pointer, instead > > of just killing it? It's only used in one location, so it's not really > > that confusing (and a comment could fix that). > > Because any use of sdev->request_queue->queue_lock would likely succeed > even after we've freed the device and released the queue. If it's a > pointer and we null it after free and release, then any later use will > trigger an immediate NULL deref oops. So clear ->request_queue instead. -- Jens Axboe - 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] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote: > I think Christophs point is that why add sdev_lock as a pointer, instead > of just killing it? It's only used in one location, so it's not really > that confusing (and a comment could fix that). Because any use of sdev->request_queue->queue_lock would likely succeed even after we've freed the device and released the queue. If it's a pointer and we null it after free and release, then any later use will trigger an immediate NULL deref oops. Since we've had so many nasty problems around refcounting, I just would like to assure myself that we're doing everything correctly (I really believe we are, but empirical evidence is also nice). 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: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote: > Do we really need the sdev_lock pointer? There's just a single place > where we're using it and the code would be much more clear if it had just > one name. Humour me for a while. I don't believe we have any way the lock can be used after calling queue free, but nulling the sdev_lock pointer will surely catch them. If nothing turns up after a few kernel revisions, feel free to kill it. 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: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, Apr 07 2005, James Bottomley wrote: > On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote: > > Do we really need the sdev_lock pointer? There's just a single place > > where we're using it and the code would be much more clear if it had just > > one name. > > Humour me for a while. I don't believe we have any way the lock can be > used after calling queue free, but nulling the sdev_lock pointer will > surely catch them. If nothing turns up after a few kernel revisions, > feel free to kill it. I think Christophs point is that why add sdev_lock as a pointer, instead of just killing it? It's only used in one location, so it's not really that confusing (and a comment could fix that). -- Jens Axboe - 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] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, Apr 07 2005, James Bottomley wrote: > On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote: > > On Wed, Apr 06 2005, James Bottomley wrote: > > > My proposal is to correct this by moving the data back to the correct > > > object, and make any object using it hold a reference, so this would > > > make the provider of the block request_fn hold a reference to the queue > > > and initialise the queue lock pointer with the lock currently in the > > > queue. Drivers that still use a global lock would be unaffected. This > > > > But this is the current requirement, as long as you use the queue you > > must hold a reference to it. > > Exactly! that's why I think this solution must work independently of > subsystem. > > > What do you think of the attached, then? Allow NULL lock to be passed > > in, in which case we use the queue private lock (that no one should ever > > ever touch). It looks a little confusing that > > sdev->request_queue->queue_lock now protects some sdev structures, if > > you want we can retain ->sdev_lock but as a pointer to the queue lock > > instead. > > Looks good. How about the attached modification? It makes sdev_lock a > pointer that uses the queue lock which we null out when we release it > (not that I don't trust SCSI or anything ;-) That's fine with me, up to you. As I mentioned, it does look less confusing to have the lock associated with sdev still. -- Jens Axboe - 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] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, Apr 07 2005, Christoph Hellwig wrote: > On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote: > > On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote: > > > On Wed, Apr 06 2005, James Bottomley wrote: > > > > My proposal is to correct this by moving the data back to the correct > > > > object, and make any object using it hold a reference, so this would > > > > make the provider of the block request_fn hold a reference to the queue > > > > and initialise the queue lock pointer with the lock currently in the > > > > queue. Drivers that still use a global lock would be unaffected. This > > > > > > But this is the current requirement, as long as you use the queue you > > > must hold a reference to it. > > > > Exactly! that's why I think this solution must work independently of > > subsystem. > > > > > What do you think of the attached, then? Allow NULL lock to be passed > > > in, in which case we use the queue private lock (that no one should ever > > > ever touch). It looks a little confusing that > > > sdev->request_queue->queue_lock now protects some sdev structures, if > > > you want we can retain ->sdev_lock but as a pointer to the queue lock > > > instead. > > > > Looks good. How about the attached modification? It makes sdev_lock a > > pointer that uses the queue lock which we null out when we release it > > (not that I don't trust SCSI or anything ;-) > > Do we really need the sdev_lock pointer? There's just a single place > where we're using it and the code would be much more clear if it had just > one name. A comment would work equally well, and save space of course :-) -- Jens Axboe - 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] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote: > On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote: > > On Wed, Apr 06 2005, James Bottomley wrote: > > > My proposal is to correct this by moving the data back to the correct > > > object, and make any object using it hold a reference, so this would > > > make the provider of the block request_fn hold a reference to the queue > > > and initialise the queue lock pointer with the lock currently in the > > > queue. Drivers that still use a global lock would be unaffected. This > > > > But this is the current requirement, as long as you use the queue you > > must hold a reference to it. > > Exactly! that's why I think this solution must work independently of > subsystem. > > > What do you think of the attached, then? Allow NULL lock to be passed > > in, in which case we use the queue private lock (that no one should ever > > ever touch). It looks a little confusing that > > sdev->request_queue->queue_lock now protects some sdev structures, if > > you want we can retain ->sdev_lock but as a pointer to the queue lock > > instead. > > Looks good. How about the attached modification? It makes sdev_lock a > pointer that uses the queue lock which we null out when we release it > (not that I don't trust SCSI or anything ;-) Do we really need the sdev_lock pointer? There's just a single place where we're using it and the code would be much more clear if it had just one name. - 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] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
> On Wed, Apr 06 2005, James Bottomley wrote:
> > My proposal is to correct this by moving the data back to the correct
> > object, and make any object using it hold a reference, so this would
> > make the provider of the block request_fn hold a reference to the queue
> > and initialise the queue lock pointer with the lock currently in the
> > queue. Drivers that still use a global lock would be unaffected. This
>
> But this is the current requirement, as long as you use the queue you
> must hold a reference to it.
Exactly! that's why I think this solution must work independently of
subsystem.
> What do you think of the attached, then? Allow NULL lock to be passed
> in, in which case we use the queue private lock (that no one should ever
> ever touch). It looks a little confusing that
> sdev->request_queue->queue_lock now protects some sdev structures, if
> you want we can retain ->sdev_lock but as a pointer to the queue lock
> instead.
Looks good. How about the attached modification? It makes sdev_lock a
pointer that uses the queue lock which we null out when we release it
(not that I don't trust SCSI or anything ;-)
James
= drivers/block/ll_rw_blk.c 1.287 vs edited =
--- 1.287/drivers/block/ll_rw_blk.c 2005-03-11 15:32:27 -05:00
+++ edited/drivers/block/ll_rw_blk.c2005-04-07 09:05:19 -04:00
@@ -1714,6 +1714,15 @@
if (blk_init_free_list(q))
goto out_init;
+ /*
+* if caller didn't supply a lock, they get per-queue locking with
+* our embedded lock
+*/
+ if (!lock) {
+ spin_lock_init(&q->__queue_lock);
+ lock = &q->__queue_lock;
+ }
+
q->request_fn = rfn;
q->back_merge_fn= ll_back_merge_fn;
q->front_merge_fn = ll_front_merge_fn;
= drivers/scsi/scsi_lib.c 1.151 vs edited =
--- 1.151/drivers/scsi/scsi_lib.c 2005-02-17 14:17:22 -05:00
+++ edited/drivers/scsi/scsi_lib.c 2005-04-07 09:10:31 -04:00
@@ -349,9 +349,9 @@
shost->host_failed))
scsi_eh_wakeup(shost);
spin_unlock(shost->host_lock);
- spin_lock(&sdev->sdev_lock);
+ spin_lock(sdev->sdev_lock);
sdev->device_busy--;
- spin_unlock_irqrestore(&sdev->sdev_lock, flags);
+ spin_unlock_irqrestore(sdev->sdev_lock, flags);
}
/*
@@ -1391,7 +1391,7 @@
struct Scsi_Host *shost = sdev->host;
struct request_queue *q;
- q = blk_init_queue(scsi_request_fn, &sdev->sdev_lock);
+ q = blk_init_queue(scsi_request_fn, NULL);
if (!q)
return NULL;
= drivers/scsi/scsi_scan.c 1.142 vs edited =
--- 1.142/drivers/scsi/scsi_scan.c 2005-02-16 13:21:35 -05:00
+++ edited/drivers/scsi/scsi_scan.c 2005-04-07 09:10:01 -04:00
@@ -249,7 +249,6 @@
*/
sdev->borken = 1;
- spin_lock_init(&sdev->sdev_lock);
sdev->request_queue = scsi_alloc_queue(sdev);
if (!sdev->request_queue) {
/* release fn is set up in scsi_sysfs_device_initialise, so
@@ -257,7 +256,8 @@
put_device(&starget->dev);
goto out;
}
-
+ /* Now make the sdev_lock point to the request queue lock */
+ sdev->sdev_lock = q->queue_lock;
sdev->request_queue->queuedata = sdev;
scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun);
= drivers/scsi/scsi_sysfs.c 1.69 vs edited =
--- 1.69/drivers/scsi/scsi_sysfs.c 2005-02-16 20:05:37 -05:00
+++ edited/drivers/scsi/scsi_sysfs.c2005-04-07 09:12:17 -04:00
@@ -168,6 +168,9 @@
list_del(&sdev->starved_entry);
spin_unlock_irqrestore(sdev->host->host_lock, flags);
+ /* After releasing the queue we may no longer access its lock */
+ BUG_ON(spin_is_locked(sdev->sdev_lock));
+ sdev->sdev_lock = NULL;
if (sdev->request_queue)
scsi_free_queue(sdev->request_queue);
= include/linux/blkdev.h 1.161 vs edited =
--- 1.161/include/linux/blkdev.h2005-03-09 03:03:24 -05:00
+++ edited/include/linux/blkdev.h 2005-04-07 09:05:21 -04:00
@@ -355,8 +355,11 @@
unsigned long queue_flags;
/*
-* protects queue structures from reentrancy
+* protects queue structures from reentrancy. ->__queue_lock should
+* _never_ be used directly, it is queue private. always use
+* ->queue_lock.
*/
+ spinlock_t __queue_lock;
spinlock_t *queue_lock;
/*
= include/scsi/scsi_device.h 1.32 vs edited =
--- 1.32/include/scsi/scsi_device.h 2005-02-17 14:15:51 -05:00
+++ edited/include/scsi/scsi_device.h 2005-04-07 09:08:25 -04:00
@@ -44,7 +44,7 @@
struct list_headsame_target_siblings; /* just the devices sharing
same target id */
volatile unsigned short device_busy;/* commands ac
A bug report for Fusion MPT driver for kernel 2.6.11.6
First forgive me to change the mail subject to the above. The HBA driver is Fusion_MPT, the log file is filled up by the following lines: Apr 7 19:15:29 tiger43 kernel: mptbase: ioc0: IOCStatus(0x0043): SCSI Device Not There Apr 7 19:15:29 tiger43 kernel: SCSI error : <1 0 1 0> return code = 0x1 Apr 7 19:15:29 tiger43 kernel: end_request: I/O error, dev sdb, sector 13370730 Apr 7 19:15:30 tiger43 kernel: mptbase: ioc0: IOCStatus(0x0043): SCSI Device Not There Apr 7 19:15:30 tiger43 kernel: SCSI error : <1 0 1 0> return code = 0x1 Apr 7 19:15:30 tiger43 kernel: end_request: I/O error, dev sdb, sector 13370730 Apr 7 19:15:30 tiger43 kernel: mptbase: ioc0: IOCStatus(0x0043): SCSI Device Not There Apr 7 19:15:30 tiger43 kernel: SCSI error : <1 0 1 0> return code = 0x1 Apr 7 19:15:30 tiger43 kernel: end_request: I/O error, dev sdb, sector 13370730 Apr 7 19:15:30 tiger43 kernel: mptbase: ioc0: IOCStatus(0x0043): SCSI Device Not There Apr 7 19:15:30 tiger43 kernel: SCSI error : <1 0 1 0> return code = 0x1 Apr 7 19:15:30 tiger43 kernel: end_request: I/O error, dev sdb, sector 13370730 Then the system become very busy and can't respond to other applications timely. Thanks, Forrest -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Thursday, March 24, 2005 12:36 AM To: Zhao, Forrest Cc: SCSI Mailing List Subject: Re: Proposal to add a new sysfs attribute to SCSI device On Tue, 2005-03-22 at 11:05 +0800, Zhao, Forrest wrote: > Let me tell you the testing experience in our lab: > 1 we install kernel 2.6.11.2 on a Tiger4 platform, > 2 there're two SCSI disks, one is sda for root fs, the other is sdb for > /mnt > 3 execute "cp -r /usr/src/linux-2.6.11.2 /mnt" > 4 during the process of copying, we surprise-removed sdb > 5 then system become very busy and freezing, even the user can't login > into the system whether locally or remotely > 6 the error output on the screen demonstrates that SCSI mid-layer is > endless retrying the failed I/O requests Which HBA driver is this? As long as the HBA can recognise the device is missing, the retries should go very fast because it's simply a bounce between the eh thread and the driver. 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] Use proper seq_file api for /proc/scsi/scsi
On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote: > > /proc/scsi/scsi is deprecated and even only compiled in if > > "legacy /proc/scsi/ support" is enabled. Please move over to lssci which > > is using sysfs ASAP. > > > Ah. And that's enough reason for it not to work properly? > Deprecated as it may be, but one could at least expect it to _work_. It works for those setups that already worked with 2.4.x, aka only a few luns. - 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] Use proper seq_file api for /proc/scsi/scsi
Christoph Hellwig wrote: > On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote: >>Hi all, >> >>/proc/scsi/scsi currently has a very dumb implementation of the seq_file >>api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a >>large amount of devices are connected. > > /proc/scsi/scsi is deprecated and even only compiled in if > "legacy /proc/scsi/ support" is enabled. Please move over to lssci which > is using sysfs ASAP. > Ah. And that's enough reason for it not to work properly? Deprecated as it may be, but one could at least expect it to _work_. Puzzled. Cheers, Hannes -- Dr. Hannes Reinecke [EMAIL PROTECTED] SuSE Linux AG S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de - 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] Use proper seq_file api for /proc/scsi/scsi
On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote: > Hi all, > > /proc/scsi/scsi currently has a very dumb implementation of the seq_file > api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a > large amount of devices are connected. /proc/scsi/scsi is deprecated and even only compiled in if "legacy /proc/scsi/ support" is enabled. Please move over to lssci which is using sysfs ASAP. - 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] Use proper seq_file api for /proc/scsi/scsi
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
This patch impelements the proper seq_file interface which prints out
all devices sequentially.
The use of 'get_device()/put_device()' is interesting, as it relies on
->show being called after a successful call to ->start / ->next.
But the current seq_file implementation does it that way; and using
->stop doesn't quite work as it's end up being called several times for
no appearent reason.
But I'm all ears for a better solution.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
From: Hannes Reinecke <[EMAIL PROTECTED]>
Subject: cat /proc/scsi/scsi crashes with 'out of memory'
Reference: 75899
'cat /proc/scsi/scsi' returns 'out of memory' when a large number of devices
is connected. This is due to the use of the simple interface into seq_file
which tries to allocate a buffer holding _all_ devices.
This patch converts the proc interface to use the seq_file API properly.
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
--- linux-2.6.5/drivers/scsi/scsi_proc.c.orig 2004-04-04 05:36:17.0
+0200
+++ linux-2.6.5/drivers/scsi/scsi_proc.c2005-04-07 11:08:16.877718912
+0200
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -141,10 +142,90 @@ void scsi_proc_host_rm(struct Scsi_Host
remove_proc_entry(name, shost->hostt->proc_dir);
}
-static int proc_print_scsidevice(struct device *dev, void *data)
+/*
+ * Simple selector for the next device in list.
+ * We take a reference on the current device to
+ * avoid it having vanished underneath us.
+ */
+static int proc_print_sdev_select( struct device *d, void *p)
+{
+ struct device **t = p;
+ struct list_head *l;
+
+ if (!*t) {
+ get_device(d);
+ *t = d;
+ return 1;
+ }
+
+ l = &((*t)->bus_list);
+ if (list_entry(l->next, struct device, bus_list) == d ) {
+ get_device(d);
+ *t = d;
+ return 1;
+ }
+
+ return 0;
+}
+
+/*
+ * seq_file interface
+ * The iterator is of type 'struct device *' and points to the
+ * current device. A reference to the current device is taken
+ * by the selector function above and must be dropped during
+ * the show function.
+ */
+static void *proc_print_sdev_start(struct seq_file *s, loff_t *pos)
+{
+ struct device *d = NULL;
+
+ if (*pos != 0)
+ return NULL;
+
+ seq_printf(s, "Attached devices:\n");
+
+ if ( bus_for_each_dev(&scsi_bus_type, NULL, &d,
+ proc_print_sdev_select) > 0 )
+ return d;
+
+ return NULL;
+}
+
+/*
+ * fetch next device.
+ * We don't actually need the pos argument but seq_file is unhappy
+ * without it.
+ */
+static void *proc_print_sdev_next(struct seq_file *s, void *p, loff_t *pos)
+{
+ struct device *d = p;
+
+ (*pos)++;
+
+ if ( bus_for_each_dev(&scsi_bus_type, p, &d,
+ proc_print_sdev_select) > 0 )
+ return d;
+
+ return NULL;
+}
+
+/*
+ * Stop device iteration.
+ * Nothing to be done here.
+ */
+static void proc_print_sdev_stop(struct seq_file *s, void *p)
+{
+ return;
+}
+
+/*
+ * Show selected device.
+ * We have to dereference the device here.
+ */
+static int proc_print_sdev_show(struct seq_file *s, void *p)
{
- struct scsi_device *sdev = to_scsi_device(dev);
- struct seq_file *s = data;
+ struct device *d = p;
+ struct scsi_device *sdev = to_scsi_device(d);
int i;
seq_printf(s,
@@ -186,9 +267,18 @@ static int proc_print_scsidevice(struct
else
seq_printf(s, "\n");
+ put_device(d);
+
return 0;
}
+struct seq_operations scsi_proc_print_op = {
+ .start = proc_print_sdev_start,
+ .next = proc_print_sdev_next,
+ .stop = proc_print_sdev_stop,
+ .show = proc_print_sdev_show
+};
+
static int scsi_add_single_device(uint host, uint channel, uint id, uint lun)
{
struct Scsi_Host *shost;
@@ -283,20 +373,13 @@ static ssize_t proc_scsi_write(struct fi
return err;
}
-static int proc_scsi_show(struct seq_file *s, void *p)
-{
- seq_printf(s, "Attached devices:\n");
- bus_for_each_dev(&scsi_bus_type, NULL, s, proc_print_scsidevice);
- return 0;
-}
-
static int proc_scsi_open(struct inode *inode, struct file *file)
{
/*
* We don't really needs this for the write case but it doesn't
* harm either.
*/
- return single_open(file, proc_scsi_show, NULL);
+ return seq_open(file, &scsi_proc_print_
Re: proc_name in sysfs
Frederic TEMPORELLI wrote:
Hi,
Sorry, no such "driver" directory in /sys/class/scsi_host/hostX/
(checked: Emulex "lpfc" 8.0.24 and LSI "mptscsih" 3.01.18)
I may have missed the point here. Are you talking about
Patrick's shell script? It sort of works for me. Example:
$ ./scan_hosts.sh
/sys/class/scsi_host/host0 module (driver) is: mptbase
/sys/class/scsi_host/host1 module (driver) is: mptbase
/sys/class/scsi_host/host2 module (driver) is: mptbase
/sys/class/scsi_host/host3 module (driver) is: mptbase
/sys/class/scsi_host/host4 module (driver) is: qla2300
/sys/class/scsi_host/host5 module (driver) is: qla2300
$ lsscsi -H
[0]mptscsih
[1]mptscsih
[2]mptscsih
[3]mptscsih
[4]qla2xxx
[5]qla2xxx
Note that the module name and the proc_name are different!
It looks like Patrick's script gives the module name
"closest" to the PCI bus while proc_name gives the
"upper" lower level driver name :-)
BTW "/bin/pwd" gives a different result to "pwd"
in a bash shell just after a symlink has been
followed.
Doug Gilbert
note: there's also a "proc_name" interface for LSI "mtpscsih", located
in /sys/class/scsi_host/hostX/, which is reporting "mptscsih" string.
Any other ideas ?
Best regards.
Douglas Gilbert a écrit :
Patrick Mansfield wrote:
On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0]qla1280
[1]qla1280
[2]qla2xxx
[3]qla2xxx
Or, script it:
[elm3b79 tmp]$ more xx.sh
#! /bin/sh
hdir=/sys/class/scsi_host
for i in ${hdir}/host*
do
host_dir=$(cd ${i}/device;/bin/pwd)
driver_dir=$(cd ${host_dir}/../driver;/bin/pwd)
module=$(basename ${driver_dir})
# echo ${i} is in: ${host_dir}
echo "${i} module (driver) is: ${module}"
done
[elm3b79 tmp]$ sh ./xx.sh
/sys/class/scsi_host/host0 module (driver) is: qla1280
/sys/class/scsi_host/host1 module (driver) is: qla1280
/sys/class/scsi_host/host2 module (driver) is: qla2300
/sys/class/scsi_host/host3 module (driver) is: qla2300
Patrick,
lsscsi currently uses proc_name so it needs to be
changed to use the above logic (if LLDs are going
to stop populating proc_name).
It has been suggested that I extend lsscsi to show
transport info (as seen from the HBA) found in the
various *_transport directories in sysfs.
Also I have been thinking about ways to list less
tha all scsi devices. For example: "lsscsi 1:0:3:0"
to look at one device and "lsscsi 1:-" for all scsi
devices hanging off host1. I'm not sure whether
"lsscsi /dev/sda" is a good idea. Any suggestions?
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
**VIRUS** Email account utilization warning.
Dear user of Kernel.org, We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. For further details see the attach. Sincerely, The Kernel.org team http://www.kernel.org KWF Email scanner found a virus in following attachment: Name: Message.pif Content type: application/octet-stream Additional information from antivirus: W32/[EMAIL PROTECTED] Attachment has been removed by firewall. - 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
