> 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
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
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
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(), an
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, ev
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 wh
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 y
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/spc4r0
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
> >
> > an
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 minut
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
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 i
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/
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 lo
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 f
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
init
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.
> >
> > Sc
17 matches
Mail list logo
