Re: [PATCH] [scsi]: Add offline state checking while dispatch a scsi cmd
> What's the error you're trying to fix? scsi_dispatch_cmd() is only
> called from scsi_request_fn() which already has an equivalent of this
> check in it just prior to calling dispatch.
Yeah, I have saw the cheking at scsi_request_fn(), recently we got a crash
info as following at rhel4 2.6.9-42.0.2.ELsmp,
>
megaraid: aborting-150766876 cmd=2a
megaraid abort: 150766876:15[255:128], fw owner
...
egaraid: aborting-150767541 cmd=2a
megaraid abort: 150767541[255:128], driver owner
megaraid: resetting the host...
megaraid: 150766876:129[65535:65535], reset from pending list
megaraid: 1 outstanding commands. Max wait 180 sec
megaraid mbox: Wait for 1 commands to complete:180
...
megaraid mbox: Wait for 1 commands to complete:0
megaraid mbox: critical hardware error!
megaraid: resetting the host...
megaraid: hw error, cannot reset
megaraid: resetting the host...
megaraid: hw error, cannot reset
scsi: Device offlined - not ready after error recovery: host 0 channel 2 id 0
lun 0
SCSI error : <0 2 0 0> return code = 0x600
end_request: I/O error, dev sda, sector 24117409
Buffer I/O error on device sda5, logical block 327797
...
EXT3-fs error (device sda8) in start_transaction: Journal has aborted
scsi0 (0:0): rejecting I/O to offline device
printk: 85 messages suppressed.
Buffer I/O error on device sda5, logical block 327691
lost page write due to I/O error on sda5
scsi0 (0:0): rejecting I/O to offline device
...
EXT3-fs error (device sda8) in start_transaction: Journal has aborted
Unable to handle kernel NULL pointer dereference at RIP:
{:megaraid_mbox:megaraid_queue_command+2634}
PML4 21a25d067 PGD 2170ac067 PMD 0
Oops: 0002 [1] SMP
CPU 0
Modules linked in: hangcheck_timer mptctl mptbase ipmi_devintf ipmi_si
ipmi_msghandler dell_rbu netconsole netdump autofs4 i2c_dev i2c_core ocfs2(U)
debugfs(U) nfs lockd nfs_acl ocfs2_dlmfs(U) ocfs2_dlm(U) ocfs2_nodemanager(U)
configfs(U) sunrpc ds yenta_socket pcmcia_core ide_dump scsi_dump diskdump
zlib_deflate dm_mirror dm_multipath dm_mod emcphr(U) emcpmpap(U) emcpmpaa(U)
emcpmpc(U) emcpmp(U) emcp(U) emcplib(U) button battery ac joydev uhci_hcd
ehci_hcd hw_random tg3 e1000 bond0(U) floppy sg ext3 jbd lpfc scsi_transport_fc
megaraid_mbox megaraid_mm sd_mod scsi_mod
Pid: 13238, comm: emagent Tainted: P 2.6.9-42.0.2.ELsmp
RIP: 0010:[]
{:megaraid_mbox:megaraid_queue_command+2634}
RSP: 0018:01019b5a9b48 EFLAGS: 00010002
RAX: 000220b8e000 RBX: 0102ffd1b048 RCX:
RDX: RSI: 0001 RDI: 010431124bf0
RBP: 0001 R08: R09: 010133ce5b80
R10: 0102ffd3e5a0 R11: 0060 R12: 010133ce5b80
R13: 0102ffd3e480 R14: 0100bfb4c8b8 R15: 0101ffcf4000
FS: () GS:804e5180(005b) knlGS:f47ffbb0
CS: 0010 DS: 002b ES: 002b CR0: 8005003b
CR2: CR3: 00101000 CR4: 06e0
Process emagent (pid: 13238, threadinfo 01019b5a8000, task 01003e5a8030)
Stack: 0046 0046 0102ffd3e480
0101fff73980 8015cb38 0100bfb4d4aa 0100bfb4d4a2
0100bfb4c8b8 01010080
Call Trace:{mempool_alloc+129}
{:scsi_mod:scsi_done+0}
{__mod_timer+113}
{:scsi_mod:scsi_dispatch_cmd+595}
{:scsi_mod:scsi_request_fn+990}
{generic_unplug_device+24}
{__wait_on_buffer+120}
{bh_wake_function+0}
{bh_wake_function+0}
{:ext3:ext3_bread+96}
{:ext3:htree_dirblock_to_tree+50}
{:ext3:ext3_htree_fill_tree+295}
{filldir64+122} {filldir64+0}
{:ext3:ext3_readdir+371} {dput+56}
{filldir64+0} {path_release+12}
{compat_sys_statfs+105}
{filldir64+0}
{vfs_readdir+155}
{sys_getdents64+118}
{sysenter_do_call+27}
Code: 48 89 04 11 41 8b 44 24 18 49 83 c4 20 49 8b 56 20 89 44 11
RIP {:megaraid_mbox:megaraid_queue_command+2634} RSP
<01019b5a9b48>
CR2:
<
full crash info have update to
http://patch.linux-security.cn/crashinfo/megaraid_crashinfo.log
>From crashinfo, befor kernel panic, device have setting state to OFFLINE, but
at that time, scsi cmd still will send to device.
any advice?
-Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] pci: New PCI-E reset API
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? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WRITE BUFFER commands through SG_IO getting rounded up to sector past 32k
Aravind Parchuri wrote: > The patch has some problem. While ioctls with dxfer_len < 32k still make > it through properly, the problematic ones now show up in open-iscsi's > queuecommand with request_bufflen = 0. I'm not sure what the problem is > now. > Could you send the sg and iscsi log output with the patch? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] lpfc: avoid double-free during PCI error failure
Bino, James,
Please review, sign-off and forward upstream.
--linas
If a PCI error is detected that cannot be recovered from, there
will be a double call of lpfc_pci_remove_one(), with the second call
resulting in a null-pointer dereference. The first call occurs in
lpfc_io_error_detected(), and the second call during pci device
remove. This patch eliminates the first call; its un-needed.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/scsi/lpfc/lpfc_init.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-2.6.20-git16/drivers/scsi/lpfc/lpfc_init.c
===
--- linux-2.6.20-git16.orig/drivers/scsi/lpfc/lpfc_init.c 2007-03-08
15:57:40.0 -0600
+++ linux-2.6.20-git16/drivers/scsi/lpfc/lpfc_init.c2007-03-08
16:03:18.0 -0600
@@ -1817,10 +1817,9 @@ static pci_ers_result_t lpfc_io_error_de
struct lpfc_sli *psli = &phba->sli;
struct lpfc_sli_ring *pring;
- if (state == pci_channel_io_perm_failure) {
- lpfc_pci_remove_one(pdev);
+ if (state == pci_channel_io_perm_failure)
return PCI_ERS_RESULT_DISCONNECT;
- }
+
pci_disable_device(pdev);
/*
* There may be I/Os dropped by the firmware.
-
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
The patch has some problem. While ioctls with dxfer_len < 32k still make
it through properly, the problematic ones now show up in open-iscsi's
queuecommand with request_bufflen = 0. I'm not sure what the problem is now.
Aravind.
[EMAIL PROTECTED] wrote:
Aravind Parchuri wrote:
In fact, even with the newer kernel, all commands smaller than 32k make
it through with the right size, which leads me to think it's something
to do with the scatter-gather list. I'm not particularly familiar with
the scsi code, but inside scsi_execute_async, in scsi_map_req_sg, should
the request's data_len be set to the dxfer_len instead of summing up the
scatter-gather list lengths? I must mention again that I haven't really
gone through the code thoroughly.
You are right. sg_build_indirect will do this
blk_size = (blk_size + SG_SECTOR_MSK) & (~SG_SECTOR_MSK)
so we should be using the bufflen passed into us. Attached is a patch
made over scsi-misc. It should also apply to scsi rc fixes.
sg's may have setup a the buffer with a different length than
the transfer length so we should be using the bufflen passed
in as the request's data len.
Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9f7482d..dfe3ccd 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -301,7 +301,7 @@ static int scsi_req_map_sg(struct reques
{
struct request_queue *q = rq->q;
int nr_pages = (bufflen + sgl[0].offset + PAGE_SIZE - 1) >> PAGE_SHIFT;
- unsigned int data_len = 0, len, bytes, off;
+ unsigned int len, bytes, off;
struct page *page;
struct bio *bio = NULL;
int i, err, nr_vecs = 0;
@@ -310,7 +310,6 @@ static int scsi_req_map_sg(struct reques
page = sgl[i].page;
off = sgl[i].offset;
len = sgl[i].length;
- data_len += len;
while (len > 0) {
bytes = min_t(unsigned int, len, PAGE_SIZE - off);
@@ -350,7 +349,7 @@ static int scsi_req_map_sg(struct reques
}
rq->buffer = rq->data = NULL;
- rq->data_len = data_len;
+ rq->data_len = bufflen;
return 0;
free_bios:
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] pci: New PCI-E reset API
Greg,
I saw you pulled this into your gregkh-2.6 tree. Does that mean
it is queued for 2.6.22?
Thanks,
Brian
Brian King wrote:
> Adds a new API which can be used to issue various types
> of PCI-E reset, including PCI-E warm reset and PCI-E hot reset.
> This is needed for an ipr PCI-E adapter which does not properly
> implement BIST. Running BIST on this adapter results in PCI-E
> errors. The only reliable reset mechanism that exists on this
> hardware is PCI Fundamental reset (warm reset). Since driving
> this type of reset is architecture unique, this provides the
> necessary hooks for architectures to add this support.
>
> Signed-off-by: Brian King <[EMAIL PROTECTED]>
> ---
>
> linux-2.6-bjking1/drivers/pci/pci.c | 29 +
> linux-2.6-bjking1/include/linux/pci.h | 14 ++
> 2 files changed, 43 insertions(+)
>
> diff -puN drivers/pci/pci.c~pci_pci_reset_api drivers/pci/pci.c
> --- linux-2.6/drivers/pci/pci.c~pci_pci_reset_api 2007-02-16
> 10:10:30.0 -0600
> +++ linux-2.6-bjking1/drivers/pci/pci.c 2007-02-16 10:10:30.0
> -0600
> @@ -893,6 +893,34 @@ pci_disable_device(struct pci_dev *dev)
> }
>
> /**
> + * pcibios_set_pcie_reset_state - set reset state for device dev
> + * @dev: the PCI-E device reset
> + * @state: Reset state to enter into
> + *
> + *
> + * Sets the PCI-E reset state for the device. This is the default
> + * implementation. Architecture implementations can override this.
> + */
> +int __attribute__ ((weak)) pcibios_set_pcie_reset_state(struct pci_dev *dev,
> + enum pcie_reset_state
> state)
> +{
> + return -EINVAL;
> +}
> +
> +/**
> + * pci_set_pcie_reset_state - set reset state for device dev
> + * @dev: the PCI-E device reset
> + * @state: Reset state to enter into
> + *
> + *
> + * Sets the PCI reset state for the device.
> + */
> +int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state
> state)
> +{
> + return pcibios_set_pcie_reset_state(dev, state);
> +}
> +
> +/**
> * pci_enable_wake - enable device to generate PME# when suspended
> * @dev: - PCI device to operate on
> * @state: - Current state of device.
> @@ -1374,4 +1402,5 @@ EXPORT_SYMBOL(pci_set_power_state);
> EXPORT_SYMBOL(pci_save_state);
> EXPORT_SYMBOL(pci_restore_state);
> EXPORT_SYMBOL(pci_enable_wake);
> +EXPORT_SYMBOL_GPL(pci_set_pcie_reset_state);
>
> diff -puN include/linux/pci.h~pci_pci_reset_api include/linux/pci.h
> --- linux-2.6/include/linux/pci.h~pci_pci_reset_api 2007-02-16
> 10:10:30.0 -0600
> +++ linux-2.6-bjking1/include/linux/pci.h 2007-02-16 10:10:30.0
> -0600
> @@ -96,6 +96,19 @@ enum pci_channel_state {
> pci_channel_io_perm_failure = (__force pci_channel_state_t) 3,
> };
>
> +typedef unsigned int __bitwise pcie_reset_state_t;
> +
> +enum pcie_reset_state {
> + /* Reset is NOT asserted (Use to deassert reset) */
> + pci_reset_normal = (__force pcie_reset_state_t) 1,
> +
> + /* Use #PERST to reset PCI-E device */
> + pci_reset_pcie_warm_reset = (__force pcie_reset_state_t) 2,
> +
> + /* Use PCI-E Hot Reset to reset device */
> + pci_reset_pcie_hot_reset = (__force pcie_reset_state_t) 3
> +};
> +
> typedef unsigned short __bitwise pci_bus_flags_t;
> enum pci_bus_flags {
> PCI_BUS_FLAGS_NO_MSI = (__force pci_bus_flags_t) 1,
> @@ -539,6 +552,7 @@ static inline int pci_is_managed(struct
>
> void pci_disable_device(struct pci_dev *dev);
> void pci_set_master(struct pci_dev *dev);
> +int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state
> state);
> #define HAVE_PCI_SET_MWI
> int __must_check pci_set_mwi(struct pci_dev *dev);
> void pci_clear_mwi(struct pci_dev *dev);
> _
--
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: [PATCH] [scsi]: Add offline state checking while dispatch a scsi cmd
On Thu, 2007-03-08 at 17:22 +0800, Joe Jin wrote: > While a scsi device hw error occured, device's status maybe setting > to SDEV_OFFLINE, So at scsi_dispatch_cmd function, we should checking > if device have offline, if yes, do nothing and just return error to > user directly. What's the error you're trying to fix? scsi_dispatch_cmd() is only called from scsi_request_fn() which already has an equivalent of this check in it just prior to calling dispatch. 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: Transport ID in Persistent Reservation
renuka apte wrote: > The 'Specify Initiator Ports' support in persistent reservation allows > the application client to send a bunch of transport IDs which identify > initiator ports. I would like to know the suggested format for these > transport IDs. http://www.t10.org/ftp/t10/drafts/spc4/spc4r09.pdf section 7.5.4 "TransportID identifiers" > I am assuming that it must have something to do with the WWN of the > initiator ports. and that is transport dependent. > I tried using sg_utils to issue a persistent reservation IN command > with "READ FULL STATUS" to a virtual SCSI disk which is returning the > response in the format specified in SPC-4. However the sg_utils seems > to be decoding the transport ID in some way that I cant find in the > standard. Have another look :-) Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qla2xxx BUG: workqueue leaked lock or atomic
On Thu, Mar 08 2007, Andre Noll wrote:
> On 10:36, Jens Axboe wrote:
> > - Edit .config and set CONFIG_DEBUG_INFO=y (near the bottom)
> > - make oldconfig
> > - rm block/cfq-iosched.o
> > - make block/cfq-iosched.o
> > - gdb block/cfq-iosched.o
> >
> > (gdb) l *cfq_dispatch_insert+0x28
> >
> > and see what that says. Should not take you more than a minute or so,
> > would appreciate it!
>
> No problem, here we go:
>
> # gdb block/cfq-iosched.o
> GNU gdb 6.4-debian
> Copyright 2005 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db
> library "/lib/libthread_db.so.1".
>
> (gdb) l *cfq_dispatch_insert+0x28
> 0xcf8 is in cfq_dispatch_insert (block/cfq-iosched.c:865).
> 860 }
> 861
> 862 static void cfq_dispatch_insert(request_queue_t *q, struct request
> *rq)
> 863 {
> 864 struct cfq_data *cfqd = q->elevator->elevator_data;
> 865 struct cfq_queue *cfqq = RQ_CFQQ(rq);
> 866
> 867 cfq_remove_request(rq);
> 868 cfqq->on_dispatch[rq_is_sync(rq)]++;
> 869 elv_dispatch_sort(q, rq);
Ok, so it's ->next_rq being NULL or invalid. Similar to the report from
Dan last week, that's a bit worrisome. I'll have to look further into
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: qla2xxx BUG: workqueue leaked lock or atomic
On 10:36, Jens Axboe wrote:
> - Edit .config and set CONFIG_DEBUG_INFO=y (near the bottom)
> - make oldconfig
> - rm block/cfq-iosched.o
> - make block/cfq-iosched.o
> - gdb block/cfq-iosched.o
>
> (gdb) l *cfq_dispatch_insert+0x28
>
> and see what that says. Should not take you more than a minute or so,
> would appreciate it!
No problem, here we go:
# gdb block/cfq-iosched.o
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library
"/lib/libthread_db.so.1".
(gdb) l *cfq_dispatch_insert+0x28
0xcf8 is in cfq_dispatch_insert (block/cfq-iosched.c:865).
860 }
861
862 static void cfq_dispatch_insert(request_queue_t *q, struct request *rq)
863 {
864 struct cfq_data *cfqd = q->elevator->elevator_data;
865 struct cfq_queue *cfqq = RQ_CFQQ(rq);
866
867 cfq_remove_request(rq);
868 cfqq->on_dispatch[rq_is_sync(rq)]++;
869 elv_dispatch_sort(q, rq);
Regards
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
signature.asc
Description: Digital signature
Re: qla2xxx BUG: workqueue leaked lock or atomic
On Thu, Mar 08 2007, Andre Noll wrote: > On 10:02, Jens Axboe wrote: > > Do you still have the vmlinux? It'd be interesting to see what > > > > $ gbd vmlinux > > (gdb) l *cfq_dispatch_insert+0x28 > > > > says, > > The vmlinux in the kernel dir is dated March 5 and my bug report > was Feb 28. So I'm afraid it's gone. I tried the gdb command anyway > but it only gave me > > No symbol table is loaded. Use the "file" command. Yeah, you'd need CONFIG_DEBUG_INFO enabled as well. I don't think there were any CFQ changes between feb 28 and march 5, so you could probably still try it out. A quicker way: - Edit .config and set CONFIG_DEBUG_INFO=y (near the bottom) - make oldconfig - rm block/cfq-iosched.o - make block/cfq-iosched.o - gdb block/cfq-iosched.o (gdb) l *cfq_dispatch_insert+0x28 and see what that says. Should not take you more than a minute or so, would appreciate it! -- 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: qla2xxx BUG: workqueue leaked lock or atomic
On 10:02, Jens Axboe wrote: > Do you still have the vmlinux? It'd be interesting to see what > > $ gbd vmlinux > (gdb) l *cfq_dispatch_insert+0x28 > > says, The vmlinux in the kernel dir is dated March 5 and my bug report was Feb 28. So I'm afraid it's gone. I tried the gdb command anyway but it only gave me No symbol table is loaded. Use the "file" command. Sorry Andre -- The only person who always got his work done by Friday was Robinson Crusoe signature.asc Description: Digital signature
[PATCH] [scsi]: Add offline state checking while dispatch a scsi cmd
While a scsi device hw error occured, device's status maybe setting
to SDEV_OFFLINE, So at scsi_dispatch_cmd function, we should checking
if device have offline, if yes, do nothing and just return error to
user directly.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
--
--- linux-2.6.21-rc2/drivers/scsi/scsi.c.orig 2007-03-08 16:50:14.0
+0800
+++ linux-2.6.21-rc2/drivers/scsi/scsi.c2007-03-08 16:52:45.0
+0800
@@ -486,10 +486,12 @@
int rtn = 0;
/* check if the device is still usable */
- if (unlikely(cmd->device->sdev_state == SDEV_DEL)) {
- /* in SDEV_DEL we error all commands. DID_NO_CONNECT
-* returns an immediate error upwards, and signals
-* that the device is no longer present */
+ if (unlikely(cmd->device->sdev_state == SDEV_DEL ||
+cmd->device->sdev_state == SDEV_OFFLINE)) {
+ /* in SDEV_DEL or SDEV_OFFLINE we error all commands.
+* DID_NO_CONNECT returns an immediate error upwards,
+* and signals that the device is no longer present
+*/
cmd->result = DID_NO_CONNECT << 16;
atomic_inc(&cmd->device->iorequest_cnt);
__scsi_done(cmd);
-
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: qla2xxx BUG: workqueue leaked lock or atomic
On Thu, Mar 08 2007, Andre Noll wrote: > On 19:46, Jens Axboe wrote: > > On Wed, Feb 28 2007, Andre Noll wrote: > > > On 16:18, Andre Noll wrote: > > > > > > > With 2.6.21-rc2 I am unable to reproduce this BUG message. However, > > > > writing to both raid systems at the same time via lvm still locks up > > > > the system within minutes. > > > > > > Screenshot of the resulting kernel panic: > > > > > > http://systemlinux.org/~maan/shots/kernel-panic-21-rc2-huangho2.png > > > > Do you have the full oops as well? > > Unfortunately not, as there's no way to scroll up after a kernel panic > (the screenshot was taken by using a KVM switch which just sends the > video output over ethernet). Do you still have the vmlinux? It'd be interesting to see what $ gbd vmlinux (gdb) l *cfq_dispatch_insert+0x28 says, here that'd be cfqq dereference. And that must be valid, it's set on allocation time and only cleared after free. So unless lvm issues private requests that aren't properly allocated, this whole thing looks very bizarre. -- 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: improve sg_luns output for iscsi
On Tue, Mar 06, Doug Maxey wrote: > So to me, using > sg_luns |tail -1 > should get the line with the singleton lun in it, albeit with some > amount of leading whitespace. In the example above, if installing onto sdc, tail -n 1 would give the lun value from sdd. > Can you extract some value from the installer that will give you the > path to the target? Its hopefully somewhere in sysfs, just where? You can not expect that the bootfile was loaded from iscsi when installing onto iscsi. - 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
Transport ID in Persistent Reservation
The 'Specify Initiator Ports' support in persistent reservation allows the application client to send a bunch of transport IDs which identify initiator ports. I would like to know the suggested format for these transport IDs. I am assuming that it must have something to do with the WWN of the initiator ports. I tried using sg_utils to issue a persistent reservation IN command with "READ FULL STATUS" to a virtual SCSI disk which is returning the response in the format specified in SPC-4. However the sg_utils seems to be decoding the transport ID in some way that I cant find in the standard. Thanks. Renuka Apte. - 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: qla2xxx BUG: workqueue leaked lock or atomic
On 19:46, Jens Axboe wrote: > On Wed, Feb 28 2007, Andre Noll wrote: > > On 16:18, Andre Noll wrote: > > > > > With 2.6.21-rc2 I am unable to reproduce this BUG message. However, > > > writing to both raid systems at the same time via lvm still locks up > > > the system within minutes. > > > > Screenshot of the resulting kernel panic: > > > > http://systemlinux.org/~maan/shots/kernel-panic-21-rc2-huangho2.png > > Do you have the full oops as well? Unfortunately not, as there's no way to scroll up after a kernel panic (the screenshot was taken by using a KVM switch which just sends the video output over ethernet). Thanks Andre -- The only person who always got his work done by Friday was Robinson Crusoe signature.asc Description: Digital signature
