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
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
s
may lead to scsi_request_fn() being called recursively without giving the
low level driver a chance to unjam the device.
This patch applies to 2.6.24. Please include it in the stable updates as
well.
Signed-off-by: Elias Oltmanns <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_l
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 th
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] and in my case it is indeed
the shock protection mechanism that triggers the lockups. However, some
rather
had a set of generic
commands like eject and flush in mind when implementing this request
type. He also suggested to make disk parking a command of this type.
Perhaps, you can point me in the right direction make scsi midlayer
and the ata subsystem aware of REQ_TYPE_LINUX_BLOCK commands.
>
Hi there,
in 2.6.19 the request type REQ_TYPE_LINUX_BLOCK has been introduced.
This is meant for generic block layer commands to the lower level
drivers. I'd like to use this mechanism for a generic queue freezing
and disk parking facility. The idea is to issue a command like
REQ_LB_OP_PROTECT to
7 matches
Mail list logo
