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: 0bb67f181834044db6e9b15c7d
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
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
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/
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/
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-pendi
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 wa
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. Actual
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 in
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 accesso
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 p
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()
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 t
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 c
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 list
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_SEG
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 no
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 hi
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
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
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 s
- 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, command
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 scsi-ml
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,
> > > >
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
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 84ac86ca8c6787f9efff
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
On Sat, Feb 09, 2008 at 01:50:20PM +, 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
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 extra
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
the
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 @@ ahc_linux_pci_res
37 matches
Mail list logo
