On vr, 2008-02-08 at 09:33 +0100, Geert Uytterhoeven wrote:
On Fri, 8 Feb 2008, Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0bb67f181834044db6e9b15c7d5cc3cce0489bfd
Commit:
James Bottomley [EMAIL PROTECTED] wrote:
On Sat, 2008-02-09 at 22:59 +0100, Elias Oltmanns wrote:
Hi there,
I'm experiencing system lockups with 2.6.24 which I believe to be
related to scsi error handling. Actually, I have patched the mainline
kernel with a disk shock protection patch [1]
On Sat, Feb 09 2008 at 2:04 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
Commit 30b0c37b27485a9cb897bfe3824f6f517b8c80d6 causes the following
compile error:
-- snip --
...
CC drivers/scsi/arm/fas216.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c: In
Currently, scsi_dev_queue_ready() and scsi_host_queue_ready() decrease the
device_blocked or host_blocked counter respectively *before* they determine
the right return value. If the device can't accept a request for some
reason and max_host_blocked or max_device_blocked has been set to 1, this
may
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
On Sat, Feb 09 2008 at 2:04 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
Commit 30b0c37b27485a9cb897bfe3824f6f517b8c80d6 causes the following
compile error:
-- snip --
...
CC drivers/scsi/arm/fas216.o
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
On Sat, Feb 09 2008 at 2:04 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
Commit 30b0c37b27485a9cb897bfe3824f6f517b8c80d6 causes the following
compile error:
-- snip --
...
CC drivers/scsi/arm/fas216.o
On Sun, 2008-02-10 at 13:58 +, Russell King wrote:
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
It's in mainline 84ac86ca8c6787f9efff28bc04b1b65fe0a5c310
[SCSI] arm: convert to accessors and !use_sg cleanup
Thanks for checking. This patch was in scsi-pending tree
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
It's in mainline 84ac86ca8c6787f9efff28bc04b1b65fe0a5c310
[SCSI] arm: convert to accessors and !use_sg cleanup
Thanks for checking. This patch was in scsi-pending tree since forever, And
we were unable
to get a responsive
On Sun, Feb 10 2008 at 15:58 +0200, Russell King [EMAIL PROTECTED] wrote:
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
It's in mainline 84ac86ca8c6787f9efff28bc04b1b65fe0a5c310
[SCSI] arm: convert to accessors and !use_sg cleanup
Thanks for checking. This patch was in
On Sun, 2008-02-10 at 13:54 +0100, Elias Oltmanns wrote:
James Bottomley [EMAIL PROTECTED] wrote:
On Sat, 2008-02-09 at 22:59 +0100, Elias Oltmanns wrote:
Hi there,
I'm experiencing system lockups with 2.6.24 which I believe to be
related to scsi error handling. Actually, I have
On Sun, Feb 10, 2008 at 02:38:46PM +0100, Bartlomiej Zolnierkiewicz wrote:
The OOPS is most likely (again) my fault - I was rushing out to push out
the fix and memset() line didn't get converted.
The new patch works fine for me.
I prepared the new patch, documented it and started looking into
On Sun, Feb 10 2008 at 16:20 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Sun, 2008-02-10 at 13:58 +, Russell King wrote:
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
It's in mainline 84ac86ca8c6787f9efff28bc04b1b65fe0a5c310
[SCSI] arm: convert to accessors and
On Sun, Feb 10 2008 at 16:43 +0200, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Feb 10, 2008 at 02:38:46PM +0100, Bartlomiej Zolnierkiewicz wrote:
The OOPS is most likely (again) my fault - I was rushing out to push out
the fix and memset() line didn't get converted.
The new patch
James Bottomley [EMAIL PROTECTED] wrote:
On Sun, 2008-02-10 at 13:54 +0100, Elias Oltmanns wrote:
[...]
Consider this: The -request_fn() of a single queue device is called
which in turn calls scsi_dispatch_cmd(). Assume that the device is
either in SDEV_BLOCK state or -queuecommand() returns
On Thu, 2008-01-17 at 18:51 +0200, Boaz Harrosh wrote:
All below drivers are not sg-chain ready do to incomplete software.
Once fixed they can move back to SG_ALL. For now they are stuck on
SCSI_MAX_SG_SEGMENTS.
Affected drivers/files:
drivers/scsi/aha152x.c
This seems to
On Sun, 2008-02-10 at 16:29 +0100, Elias Oltmanns wrote:
James Bottomley [EMAIL PROTECTED] wrote:
On Sun, 2008-02-10 at 13:54 +0100, Elias Oltmanns wrote:
[...]
Consider this: The -request_fn() of a single queue device is called
which in turn calls scsi_dispatch_cmd(). Assume that the
James Bottomley [EMAIL PROTECTED] wrote:
On Sun, 2008-02-10 at 16:29 +0100, Elias Oltmanns wrote:
James Bottomley [EMAIL PROTECTED] wrote:
[...]
No. We have a fix for this, it's called setting device_max_blocked to 2
or greater. All your patch does is make this seem to be the case, plus
On Sun, 2008-02-10 at 18:08 +0200, Boaz Harrosh wrote:
My patches *do not* attempt to fix the sg_chaining support. They only
make all the drivers that use SG_ALL to use SCSI_MAX_SG_SEGMENTS.
One by One, and not globally as your suggestion.
Yes, I know ... but it does need fixing for the listed
On Sun, Feb 10 2008 at 17:42 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Thu, 2008-01-17 at 18:51 +0200, Boaz Harrosh wrote:
All below drivers are not sg-chain ready do to incomplete software.
Once fixed they can move back to SG_ALL. For now they are stuck on
SCSI_MAX_SG_SEGMENTS.
On Sun, Feb 10 2008 at 18:16 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Sun, 2008-02-10 at 18:08 +0200, Boaz Harrosh wrote:
My patches *do not* attempt to fix the sg_chaining support. They only
make all the drivers that use SG_ALL to use SCSI_MAX_SG_SEGMENTS.
One by One, and not
On Sun, 2008-02-10 at 18:36 +0200, Boaz Harrosh wrote:
2. Those drivers that have been using SG_ALL correctly and were converted
to support sg-chaining are not penalized because of bad/old drivers
I don't see they're penalised this way either ... they just have to set
a higher value
Hello,
Eric Moore is on vacation, adding some CCs and TOs.
-- Forwarded message --
Date: Sun, 10 Feb 2008 18:25:39 +0100 (CET)
From: Krzysztof Oledzki [EMAIL PROTECTED]
To: Maximilian Wilhelm [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Kernel Panic in
On Friday 08 February 2008 04:33:29 pm Stefan Richter wrote:
fw-sbp2 is unable to reconnect while performing __scsi_add_device
because there is only a single workqueue thread context available for
both at the moment. This should be fixed eventually.
An actual failure of __scsi_add_device is
Add support for variable-length, extended, and vendor specific
CDBs to scsi-ml. It is now possible for initiators and ULD's
to issue these types of commands. LLDs need not change much.
All they need is to raise the .max_cmd_len to the longest command
they support (see iscsi patches).
- clean-up
- add varlen_cdb and varlen_cdb_len to hold a large user cdb
if needed. They start as empty. Allocation of buffer must
be done by user and held until request execution is done.
- Since there can be either a fix_length command up to 16 bytes
or a variable_length, larger then 16 bytes,
Submitted is a patchset for adding support for variable-length, extended,
and vendor specific CDBs. It should now cover the entire range of the
SCSI standard. (and/or any other use of command packets in block devices)
They are based on scsi-misc.
Difference from last time, is at struct request.
- struct scsi_cmnd had a 16 bytes command buffer of its own.
This is an unnecessary duplication and copy of request's
cmd. It is probably left overs from the time that scsi_cmnd
could function without a request attached. So clean that up.
- Once above is done, few places, apart from
On Tue, 5 Feb 2008, Kai Makisara wrote:
On Mon, 4 Feb 2008, James Bottomley wrote:
On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote:
(Added Bart to CC)
hello borislav,
...
This does still
On Sun, Feb 10, 2008 at 08:20:24AM -0600, James Bottomley wrote:
On Sun, 2008-02-10 at 13:58 +, Russell King wrote:
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
It's in mainline 84ac86ca8c6787f9efff28bc04b1b65fe0a5c310
[SCSI] arm: convert to accessors and !use_sg
On Sun, 2008-02-10 at 22:02 +, Russell King wrote:
On Sun, Feb 10, 2008 at 08:20:24AM -0600, James Bottomley wrote:
On Sun, 2008-02-10 at 13:58 +, Russell King wrote:
On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
It's in mainline
Alan Cox wrote:
On Fri, 08 Feb 2008 20:32:54 -0500
Douglas Gilbert [EMAIL PROTECTED] wrote:
Alan Cox wrote:
The word illegal has a precise dictionary meaning of prohibited by
law.
Also contrary to or forbidden by official rules, regulations, etc.
The OED I have here doesn't seem to think
On Sunday 10 February 2008 08:28:38 pm James Bottomley wrote:
On Sat, 2008-02-09 at 15:15 -0800, Yinghai Lu wrote:
[PATCH] scsi: ses fix mem leaking when fail to add intf
fix leaking with scomp leaking when failing.
also remove one extra space.
There are still a few extraneous code
I tried to send few patches on last friday, out of which only one
reached the list I resent the rest two and again only on reached the list
Again I have resent the third patch two times, but they are still to reach
the list. I am using mutt as E-mail client. I am sending this E-mail also from
please check it...
---
From: Yinghai Lu [EMAIL PROTECTED]
[SCSI] ses: fix memory leaks
fix leaking with scomp leaking when failing. Also free page10 on
driver removal and remove one extra space.
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
On Sat, 2008-02-09 at 15:15 -0800, Yinghai Lu wrote:
[PATCH] scsi: ses fix mem leaking when fail to add intf
fix leaking with scomp leaking when failing.
also remove one extra space.
There are still a few extraneous code moves in this one. This is about
the correct minimal set, isn't it?
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
index dd6e21d..65e194f 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
@@ -301,7 +301,7 @@
36 matches
Mail list logo
