On Mon, Dec 11 2006, FUJITA Tomonori wrote:
This patch fixes bio leaks in SG_IO.
http://marc.theaimsgroup.com/?l=linux-kernelm=116570666807983w=2
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Perhaps it was a mistake to remove the bio argument. I'll apply your
patch, and contemplate if
The code does this:
unsigned char sense[SCSI_SENSE_BUFFERSIZE];
...
scsi_normalize_sense(sense, sizeof(*sense), sshdr)
however the sizeof will return 1 not 96 which means the sense data will
have no valid ASC/ASCQ values. Fix by putting the correct sense size.
The only affected case for this
Hi,
as per request by Geert Uytterhoeven: the patch below avoids a warning in
blk_queue_max_hw_segments(), caused by a SCSI host adapter using SG_NONE.
Please apply.
The second item concerns a warning given for each SCSI target scanned on
the Falcon, where sg_tablesize is set to SG_NONE (aka
On Mon, 2006-12-11 at 17:09 +0100, Michael Schmitz wrote:
Hi,
as per request by Geert Uytterhoeven: the patch below avoids a warning in
blk_queue_max_hw_segments(), caused by a SCSI host adapter using SG_NONE.
Please apply.
Actually, isn't the correct fix to change SG_NONE to 1?
We're
FUJITA Tomonori wrote:
This patch fixes bio leaks in SG_IO.
http://marc.theaimsgroup.com/?l=linux-kernelm=116570666807983w=2
Tomo, when you ported and converted the patches there was another user
of blk_rq_map_user in the ide code. Did you get that path?
-
To unsubscribe from this list:
Mike Christie wrote:
FUJITA Tomonori wrote:
This patch fixes bio leaks in SG_IO.
http://marc.theaimsgroup.com/?l=linux-kernelm=116570666807983w=2
Tomo, when you ported and converted the patches there was another user
of blk_rq_map_user in the ide code. Did you get that path?
Ignore that.
as per request by Geert Uytterhoeven: the patch below avoids a warning in
blk_queue_max_hw_segments(), caused by a SCSI host adapter using SG_NONE.
Please apply.
Actually, isn't the correct fix to change SG_NONE to 1?
We're deprecating the non-sg paths, however use_sg == 1 is equivalent
On Mon, 2006-12-11 at 18:18 +0100, Michael Schmitz wrote:
Actually, isn't the correct fix to change SG_NONE to 1?
We're deprecating the non-sg paths, however use_sg == 1 is equivalent to
use_sg==0, you just set it up differently.
I don't know how it's handled in the current code. The
Due to a firmware mismatch between a host and target (names withheld to
protect the innocent?), the LLDD was returning DID_RESET for every
i/o command. This patch modifies the scsi layer to take into account
when the command which received DID_RESET was issued and eventually
give up on it instead
On Mon, 2006-12-11 at 14:10 -0800, Andrew Morton wrote:
pktcdvd: writer pktcdvd0 mapped to sr0
[ cut here ]
kernel BUG at drivers/scsi/scsi_lib.c:1118!
invalid opcode: [#1]
Modules linked in: pktcdvd snd_seq_oss snd_seq_midi_event snd_seq bonding
Matthew Wilcox wrote:
Some of the drivers (AHCI was mentioned to me as a culprit) take a long
time to discover all the devices attached to them. Even for ones which
are relatively quick, if you put a lot of them in a machine, it will
take a long time in aggregate. This can be fixed by adding
Matthew Wilcox wrote:
Some of the drivers (AHCI was mentioned to me as a culprit) take a long
time to discover all the devices attached to them. Even for ones which
are relatively quick, if you put a lot of them in a machine, it will
take a long time in aggregate. This can be fixed by adding
When I converted the origianl patch, I left unnecessary
blk_queue_bounce in SG_IO.
---
[PATCH] remove unnecessary blk_queue_bounce in SG_IO
This patch removes blk_queue_bounce in SG_IO since the blk functions
handle it.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: Mike
I have the same or a similar issue running 2.6.17 SMP x86_64 - the
megaraid_sas driver hangs waiting for commands and then the filesystem
unmounts, leaving the machine in an unusable state until there is a hard
reboot (the machine is responsive but any access, shell or otherwise, is
I am still seeing this and we have between 2 and 5 failures per week
(across almost 20 machines). I am seeing it on ext3 (we migrated all of
the machines from XFS) and with ReadAhead disabled.
You mention a firmware update but I don't see any new PERC 5 firmware
packages on Dell's site...
Hi Brett!
Thanks for the response, hopefully we can gather enough data points to
help solve the problem.
The new PERC 5/i integrated firmware dated 11/21/2006 is at:
On Mon, Dec 11, 2006 at 11:18:17AM -0500, Jeff Garzik wrote:
ACK. I tried to apply the patch, but git-applymbox choked on every
single file modified. Quite possibly, its due to a whitespace cleanup
in Alan territory.
If you would either (a) wait several hours for libata-dev.git#upstream
On Mon, Dec 11, 2006 at 10:02:40PM -0700, Matthew Wilcox wrote:
On Mon, Dec 11, 2006 at 11:18:17AM -0500, Jeff Garzik wrote:
ACK. I tried to apply the patch, but git-applymbox choked on every
single file modified. Quite possibly, its due to a whitespace cleanup
in Alan territory.
Darrick J. Wong wrote:
The Quantum GoVault SATAPI removable disk device returns ATA_ERR in
response to a REPORT LUNS packet. If this happens to an ATAPI device
that is attached to a SAS controller (this is the case with sas_ata),
the device does not load because SCSI won't touch a SCSI device
James Bottomley wrote:
On Mon, 2006-12-11 at 11:24 -0500, Jeff Garzik wrote:
Darrick J. Wong wrote:
The Quantum GoVault SATAPI removable disk device returns ATA_ERR in
response to a REPORT LUNS packet. If this happens to an ATAPI device
that is attached to a SAS controller (this is the case
20 matches
Mail list logo
