On Tue, 2007-01-09 at 14:35 +0900, Hisashi Hifumi wrote:
> - spin_unlock_irq(&ha->hardware_lock);
> + if (in_irq())
> + spin_unlock(&ha->hardware_lock);
> + else
> + spin_unlock_irq(&ha->hardware_lock);
> +
Really, no!
If the function can be called w
Hi.
The function qla2x00_ramp_up_queue_depth() can be called in IRQ context.
So spin_unlock_irq in qla2x00_ramp_up_queue_depth() is not appropriate.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
--- linux-2.6.20-rc4.org/drivers/scsi/qla2xxx/qla_isr.c 2006-11-30
06:57:37.000
On Monday, January 08, 2007 3:25 PM, James Bottomley wrote:
> Right, I sort of suspected something like this. BUSY/QUEUE_FULL
> handling was a bit iffy in 2.4; but it was sorted out in the 2003/4
> timeframe. Nowadays, I think you want to translate the
> MPI_SCSI_STATUS_BUSY directly to SAM_STA
Hi,
Minor typo ...
In my first iteration of patches (that got merged), the
BLIST_ATTACH_PQ3 actually had the value 0x80, but that
got changed later to avoid conflicts. This piece must have
been overlooked.
You could obviously do something like %x and then add the
bitflags, but that looks over
Justin wrote:
> Success! Here you are
Can you send the dmesg, boot.log, or messages from /var/log ?
It appears you've sent me lspci output instead.
Eric.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Success! Here you are:
00:00.0 0600: 1106:3189 (rev 80)
Subsystem: 1458:5000
Flags: bus master, 66MHz, medium devsel, latency 8
Memory at d000 (32-bit, prefetchable) [size=128M]
Capabilities: [80] AGP version 3.5
Capabilities: [c0] Power Management versio
Alan Stern wrote:
> Both scsi_device and scsi_target include a scsi_level field, and the
> SCSI core makes a half-hearted effort to keep the values equal.
> Ultimately this effort may be doomed, since as far as I know there is
> no reason why all LUNs in a target must report the same "ANSI-approved
On Mon, 2007-01-08 at 15:03 -0700, Moore, Eric wrote:
> In the 03.02.19, we add added the current logic for the following
> reason:
>
> "When a target device responds with BUSY status, the MPT driver was
> sending DID_OK to the
> SCSI mid layer, which caused the IO to be retried indefinitely betw
On Saturday, January 06, 2007 8:31 AM, James Bottomley wrote:
>
> DID_BUS_BUSY causes an immediate retry, but it does debit the retry
> count, so it shouldn't cause "infinite retries" ... if it
> does, there's
> something else wrong here.
>
> I should also point out that the MPI_SCSI_STATUS_BU
On Mon, Jan 08, 2007 at 10:16:15AM -0600, James Bottomley wrote:
> On Sun, 2007-01-07 at 17:10 -0500, Douglas Gilbert wrote:
> > Seems I'm not the only one sending posts to the
> > [EMAIL PROTECTED] bit bucket.
> >
> > Could the maintainer of lsml either:
> > - get rid of [EMAIL PROTECTED]
> >
On Mon, Jan 08 2007, Alan Stern wrote:
> On Wed, 6 Dec 2006, James Bottomley wrote:
>
> > On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> > > I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set,
> > > and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue()
On Mon, 2007-01-08 at 11:19 -0500, Alan Stern wrote:
> Back in December you wrote a patch to expose the queue ioctls, and sent it
> (off-list) to Jens Axboe and to me. Jens spproved it, but then it
> disappeared and was never applied. Unfortunately I have lost my copy of
> it.
>
> If you still h
On Sunday, January 07, 2007 11:07 AM, Justin Rosander wrote:
> Hi Eric,
> I tried recompiling the kernel per your instructions, but I got a
> failure here:
> CC [M] drivers/message/fusion/mptbase.o
> drivers/message/fusion/mptbase.c: In function 'mpt_resume':
> drivers/me
On Wed, 6 Dec 2006, James Bottomley wrote:
> On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
> > I'd love to do that -- but blkdev_ioctl() wants inode->i_bdev to be set,
> > and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So
> > it won't work with sg, which uses char
Both scsi_device and scsi_target include a scsi_level field, and the
SCSI core makes a half-hearted effort to keep the values equal.
Ultimately this effort may be doomed, since as far as I know there is
no reason why all LUNs in a target must report the same "ANSI-approved
version" number. But for
On Sun, 2007-01-07 at 17:10 -0500, Douglas Gilbert wrote:
> Seems I'm not the only one sending posts to the
> [EMAIL PROTECTED] bit bucket.
>
> Could the maintainer of lsml either:
> - get rid of [EMAIL PROTECTED]
> - or forward posts in there to lsml
>
> That bright idea might save the maint
This patch (as833) fixes the "SCSI revision" output for
/proc/scsi/scsi. If the scsi_level value is 0 (UNKNOWN), we want it
to show up as "0", not "".
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/scsi/scsi_proc.c
==
On Sun, 2007-01-07 at 17:16 -0500, Douglas Gilbert wrote:
> Followed by this misdirected ** post from Eric Moore
> which you and I also received:
OK ... I missed the ack for this on linux-scsi ... I'll add it.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the
Hi Sumant,
Thanks for the quick response! I don't believe we're having any issues
with the mask - we're just trying to debug some issues we're
having with some controllers with 2.6.17.13, and that's the only
real semantic difference (other than crashdump mode) between
RHEL 4 kernels and 2.6.17.13
Further to the announcement 1 month ago (shown below),
there is another lsscsi-0.19 beta at:
http://www.torque.net/sg [News section].
It provides target (and sometimes host) transport
information for:
- IEEE1394 (sbp)
- FC
- ISCSI
- SAS (two representations)
- SPI
It has tested with lk 2
20 matches
Mail list logo
