unsubscribe linux-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
unsubscribe linux-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
How 'bout a comment in scsh_host.h indicating that the pointer will be NULL
unless
initialized by the driver?
"Protect shared block queue tag" is unique to stex. Perhaps have no comment on
the variable declaration in scsi_host.h and explain why you use it in stex.
Mike
Ed Lin wrote:
> The
How 'bout a comment in scsh_host.h indicating that the pointer will be NULL
unless
initialized by the driver?
Protect shared block queue tag is unique to stex. Perhaps have no comment on
the variable declaration in scsi_host.h and explain why you use it in stex.
Mike
Ed Lin wrote:
The block
Hi Andrew,
Thanks again for finding the fix to the problem I reported.
Can you tell me when I might expect this fix to show up in
2.6.20-rc?
Thanks,
Mike
Andrew Morton wrote:
> On Thu, 11 Jan 2007 13:21:57 -0600
> Michael Reed <[EMAIL PROTECTED]> wrote:
>
>> Testing on m
Hi Andrew,
Thanks again for finding the fix to the problem I reported.
Can you tell me when I might expect this fix to show up in
2.6.20-rc?
Thanks,
Mike
Andrew Morton wrote:
On Thu, 11 Jan 2007 13:21:57 -0600
Michael Reed [EMAIL PROTECTED] wrote:
Testing on my ia64 system reveals
Andrew Morton wrote:
> On Thu, 11 Jan 2007 13:21:57 -0600
> Michael Reed <[EMAIL PROTECTED]> wrote:
>
>> Testing on my ia64 system reveals that this patch introduces a
>> data integrity error for direct i/o to a block device. Device
>> errors which resul
Testing on my ia64 system reveals that this patch introduces a
data integrity error for direct i/o to a block device. Device
errors which result in i/o failure do not propagate to the
process issuing direct i/o to the device.
This can be reproduced by doing writes to a fibre channel block
device
Testing on my ia64 system reveals that this patch introduces a
data integrity error for direct i/o to a block device. Device
errors which result in i/o failure do not propagate to the
process issuing direct i/o to the device.
This can be reproduced by doing writes to a fibre channel block
device
Andrew Morton wrote:
On Thu, 11 Jan 2007 13:21:57 -0600
Michael Reed [EMAIL PROTECTED] wrote:
Testing on my ia64 system reveals that this patch introduces a
data integrity error for direct i/o to a block device. Device
errors which result in i/o failure do not propagate to the
process
to dead device
(huge numbers of these occur)
I tried the same test using O_FSYNC instead of O_DIRECT and the write error
following the portdisable propagated to the test and it exited with an EIO.
Mike
Michael Reed wrote:
> Testing using 2.6.20-rc3-git4 I observed that my direct i/o t
Peter Staubach wrote:
> Hua Zhong wrote:
>> Hi,
>>
>> A while ago there was a discussion about supporting direct-io on tmpfs.
>>
>> Here is a simple patch that does it.
>>
>> 1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored
>>if this flag is set (suggestions on a
Peter Staubach wrote:
Hua Zhong wrote:
Hi,
A while ago there was a discussion about supporting direct-io on tmpfs.
Here is a simple patch that does it.
1. A new fs flag FS_RAM_BASED is added and the O_DIRECT flag is ignored
if this flag is set (suggestions on a better name?)
2.
to dead device
(huge numbers of these occur)
I tried the same test using O_FSYNC instead of O_DIRECT and the write error
following the portdisable propagated to the test and it exited with an EIO.
Mike
Michael Reed wrote:
Testing using 2.6.20-rc3-git4 I observed that my direct i/o test
Luben Tuikov wrote:
...snip...
> This statement in scsi_io_completion() causes the infinite retry loop:
>if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> return;
The code in 2.6.19 is "result==0", not "!!result", which is logically
the same as "result!=0". Did you
Luben Tuikov wrote:
...snip...
This statement in scsi_io_completion() causes the infinite retry loop:
if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
return;
The code in 2.6.19 is result==0, not !!result, which is logically
the same as result!=0. Did you mean to
Hello,
I have a Contemporary Controls PCI20 card and am trying to use the latest
arcnet drivers under Mandrake 8.0 with a 2.4.4 kernel.
I do the following:
insmod arcnet
insmod arc-rawmode
insmod com20020
which all load just fine. However, when I do:
insmod com20020-pci
I get the
Hello,
I have a Contemporary Controls PCI20 card and am trying to use the latest
arcnet drivers under Mandrake 8.0 with a 2.4.4 kernel.
I do the following:
insmod arcnet
insmod arc-rawmode
insmod com20020
which all load just fine. However, when I do:
insmod com20020-pci
I get the
18 matches
Mail list logo
