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
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
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 do
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 a
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
> 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 al
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,
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 whe
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 alignm
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
> > > +
> > > @@
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
> > sdev->max
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'r
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 lucky
you have highmem, and ioread16_rep oopses on the virtual address beyond
what ata_p
13 matches
Mail list logo
