Added linux-scsi to the cc.
On Tue, 2008-01-22 at 17:11 +, Hugh Dickins wrote:
2.6.24-rc8-mm1 is corrupting. smartd does some sg_ioctl into its stack,
and depending on how its stack randomization worked out, this is liable
to end up writing into the adjacent physical page too. If you're
On Tue, 22 Jan 2008, James Bottomley wrote:
--- 2.6.24-rc8-mm1/drivers/ata/libata-scsi.c2008-01-17
16:49:47.0 +
+++ linux/drivers/ata/libata-scsi.c 2008-01-22 15:45:40.0 +
@@ -826,7 +826,7 @@ static void ata_scsi_sdev_config(struct
On Tue, 2008-01-22 at 18:36 +, Hugh Dickins wrote:
On Tue, 22 Jan 2008, James Bottomley wrote:
--- 2.6.24-rc8-mm1/drivers/ata/libata-scsi.c 2008-01-17
16:49:47.0 +
+++ linux/drivers/ata/libata-scsi.c 2008-01-22 15:45:40.0
+
@@ -826,7 +826,7
On Tue, 22 Jan 2008, James Bottomley wrote:
Actually, I don't think it's a smaller I/O issue. The SMART protocol
specifically mandates that the transfers for SMART READ DATA and SMART
READ LOG shall be 512 bytes). However, the pio transfer routine does
seem to be assuming sector alignment
James Bottomley wrote:
Actually, I don't think it's a smaller I/O issue. The SMART protocol
specifically mandates that the transfers for SMART READ DATA and SMART
READ LOG shall be 512 bytes). However, the pio transfer routine does
seem to be assuming sector alignment as well, which will be
On Tue, 2008-01-22 at 20:20 +, Hugh Dickins wrote:
On Tue, 22 Jan 2008, James Bottomley wrote:
Actually, I don't think it's a smaller I/O issue. The SMART protocol
specifically mandates that the transfers for SMART READ DATA and SMART
READ LOG shall be 512 bytes). However, the pio
However, I'd like to see if we can track the problem through the SG_IO
direct path ... how many adjacent page bytes are corrupt? Just a few or
a large number (I'm wondering if it's an off by one or off by alignment
type bug)?
Which ATA controller is involved - in theory ATA DMA is byte
On Tue, 22 Jan 2008, Alan Cox wrote:
However, I'd like to see if we can track the problem through the SG_IO
direct path ... how many adjacent page bytes are corrupt? Just a few or
a large number (I'm wondering if it's an off by one or off by alignment
type bug)?
We moved away from that
On Tue, 22 Jan 2008, James Bottomley wrote:
libsas looks to be OK because it specifically kmallocs a 512 byte buffer
which should (for off slab data) be 512 byte aligned.
I don't remember the various SLAB and SLOB and SLUB rules offhand:
I'm not sure it's safe to rely on such alignment on all
On Tue, 2008-01-22 at 15:32 -0500, Jeff Garzik wrote:
James Bottomley wrote:
Actually, I don't think it's a smaller I/O issue. The SMART protocol
specifically mandates that the transfers for SMART READ DATA and SMART
READ LOG shall be 512 bytes). However, the pio transfer routine does
On Tue, 2008-01-22 at 22:59 +, Hugh Dickins wrote:
On Tue, 22 Jan 2008, James Bottomley wrote:
libsas looks to be OK because it specifically kmallocs a 512 byte buffer
which should (for off slab data) be 512 byte aligned.
I don't remember the various SLAB and SLOB and SLUB rules
On Tue, 2008-01-22 at 22:59 +, Hugh Dickins wrote:
On Tue, 22 Jan 2008, James Bottomley wrote:
libsas looks to be OK because it specifically kmallocs a 512 byte buffer
which should (for off slab data) be 512 byte aligned.
I don't remember the various SLAB and SLOB and SLUB rules
12 matches
Mail list logo
