jgarzik and max-sectors: out of memory

jgarzik and max-sectors: out of memory

[Jeff Garzik]

ATA_MAX_SECTORS is 200, rather than than 256 like it should be.  I seem 
to recall that this was due to libata being incomplete in some area, but 
I've tried in vain for a year to remember where the alleged 
incompleteness was, to no avail.  So, my brain is out of memory :)

Further -- someone with a long ATA memory correct me -- I think that we 
can increase ATA_MAX_PRD beyond 256.  Most DMA engines should just keep 
chugging along, provided that we continue to respect the 64k IDE DMA 
boundaries.

So, I propose that we rename ATA_MAX_SECTORS to ATA_LBA28_SECTORS, and 
change its value to 256, and see what happens.  People have reported 
that that worked for them, so let's subject it to a wide test.  If 
people are extremely paranoid, we could increase it to 255, and then in 
the next kernel version, bump it from 255 to 256.

Then we can look at increasing ATA_MAX_PRD, if that's feasible for PATA 
hardware.

	Jeff

Re: jgarzik and max-sectors: out of memory

[Mark Lord]

Jeff Garzik wrote:
..
> Further -- someone with a long ATA memory correct me -- I think that we 
> can increase ATA_MAX_PRD beyond 256.  Most DMA engines should just keep 
> chugging along, provided that we continue to respect the 64k IDE DMA 
> boundaries.

MAX_PRD used to be equal to MAX_SECTORS, as that's the worst case scenario.
The only real gotcha I remember from the original IDE driver,
was that some (very few) controllers were buggy with handing
of a sector_count of zero (256), so setting the limit to a slightly
lower value prevented that from ever being a problem.

That was in the days before the block layer could limit the segment count.

I don't remember which chipsets had the bug; TRM290 was one,
but that never really worked well anyway, and nobody other than
myself seemed to have one of those cards.  Mmm.. Possibly the
Pacific Digital ADMA-100 here as well.. I can look that one up
if I can find the old box full of cards/docs..

Cheers

Re: jgarzik and max-sectors: out of memory

[Jeff Garzik]

Mark Lord wrote:
> Jeff Garzik wrote:
> ..
>> Further -- someone with a long ATA memory correct me -- I think that 
>> we can increase ATA_MAX_PRD beyond 256.  Most DMA engines should just 
>> keep chugging along, provided that we continue to respect the 64k IDE 
>> DMA boundaries.
> 
> MAX_PRD used to be equal to MAX_SECTORS, as that's the worst case scenario.

Not for lba48, which has a larger max-sectors but is still clamped to 
the same 256 PRD entries...


> The only real gotcha I remember from the original IDE driver,
> was that some (very few) controllers were buggy with handing
> of a sector_count of zero (256), so setting the limit to a slightly
> lower value prevented that from ever being a problem.

Yeah, a couple of Alan's PATA drivers are fixed at 255.


> That was in the days before the block layer could limit the segment count.

Ahhhhh, useful to know.

	Jeff

Re: jgarzik and max-sectors: out of memory

[Jens Axboe]

On Saturday 27 May 2006 21:37, Jeff Garzik wrote:
> ATA_MAX_SECTORS is 200, rather than than 256 like it should be.  I seem
> to recall that this was due to libata being incomplete in some area, but
> I've tried in vain for a year to remember where the alleged
> incompleteness was, to no avail.  So, my brain is out of memory :)
>
> Further -- someone with a long ATA memory correct me -- I think that we
> can increase ATA_MAX_PRD beyond 256.  Most DMA engines should just keep
> chugging along, provided that we continue to respect the 64k IDE DMA
> boundaries.

The PRD count is much less of a problem.

> So, I propose that we rename ATA_MAX_SECTORS to ATA_LBA28_SECTORS, and
> change its value to 256, and see what happens.  People have reported
> that that worked for them, so let's subject it to a wide test.  If
> people are extremely paranoid, we could increase it to 255, and then in
> the next kernel version, bump it from 255 to 256.
>
> Then we can look at increasing ATA_MAX_PRD, if that's feasible for PATA
> hardware.

Yep lets please do that, I don't think libata ever had any problems with 256 
sectors other than perhaps a worry that it would break "something" :-)

Jens

Re: jgarzik and max-sectors: out of memory

[Jeff Garzik]

Jens Axboe wrote:
> Yep lets please do that, I don't think libata ever had any problems with 256 
> sectors other than perhaps a worry that it would break "something" :-)

There were definite bugs in the past with 256 (versus <= 255) sectors...

	Jeff

Re: jgarzik and max-sectors: out of memory

[Jens Axboe]

On Tue, May 30 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >Yep lets please do that, I don't think libata ever had any problems with 
> >256 sectors other than perhaps a worry that it would break "something" :-)
> 
> There were definite bugs in the past with 256 (versus <= 255) sectors...

Hardware or software? IIRC, the hardware ones were largely an urban
legend.

-- 
Jens Axboe

Re: jgarzik and max-sectors: out of memory

[Jeff Garzik]

On Tue, May 30, 2006 at 10:36:29AM +0200, Jens Axboe wrote:
> On Tue, May 30 2006, Jeff Garzik wrote:
> > Jens Axboe wrote:
> > >Yep lets please do that, I don't think libata ever had any problems with 
> > >256 sectors other than perhaps a worry that it would break "something" :-)
> > 
> > There were definite bugs in the past with 256 (versus <= 255) sectors...
> 
> Hardware or software? IIRC, the hardware ones were largely an urban
> legend.

Software.

Alan is submitting a couple PATA drivers limited to 255 though...

	Jeff

	

Re: jgarzik and max-sectors: out of memory

[Jens Axboe]

On Tue, May 30 2006, Jeff Garzik wrote:
> On Tue, May 30, 2006 at 10:36:29AM +0200, Jens Axboe wrote:
> > On Tue, May 30 2006, Jeff Garzik wrote:
> > > Jens Axboe wrote:
> > > >Yep lets please do that, I don't think libata ever had any problems with 
> > > >256 sectors other than perhaps a worry that it would break "something" :-)
> > > 
> > > There were definite bugs in the past with 256 (versus <= 255) sectors...
> > 
> > Hardware or software? IIRC, the hardware ones were largely an urban
> > legend.
> 
> Software.
> 
> Alan is submitting a couple PATA drivers limited to 255 though...

And I'm sure some are even lower than that. Of course libata should be
be imposing anything on the driver, the logic that drivers/ide uses for
this is actually pretty sane:

        if (device_lba28)
                max_hw_sectors = 256;
        if (device_lba48)
                max_hw_sectors = 65536;
        if (max_sectors > more_than_controller_supports)
                max_sectors = more_than_controller_supports;

or something close to that.

-- 
Jens Axboe

Re: jgarzik and max-sectors: out of memory

[Jeff Garzik]

On Tue, May 30, 2006 at 11:10:02AM +0200, Jens Axboe wrote:
> And I'm sure some are even lower than that. Of course libata should be
> be imposing anything on the driver, the logic that drivers/ide uses for
> this is actually pretty sane:
> 
>         if (device_lba28)
>                 max_hw_sectors = 256;
>         if (device_lba48)
>                 max_hw_sectors = 65536;
>         if (max_sectors > more_than_controller_supports)
>                 max_sectors = more_than_controller_supports;
> 
> or something close to that.

libata has always done this, modulo the ATA_MAX_SECTORS issue.

	Jeff

Re: jgarzik and max-sectors: out of memory

[Jens Axboe]

On Tue, May 30 2006, Jeff Garzik wrote:
> On Tue, May 30, 2006 at 11:10:02AM +0200, Jens Axboe wrote:
> > And I'm sure some are even lower than that. Of course libata should be
> > be imposing anything on the driver, the logic that drivers/ide uses for
> > this is actually pretty sane:
> > 
> >         if (device_lba28)
> >                 max_hw_sectors = 256;
> >         if (device_lba48)
> >                 max_hw_sectors = 65536;
> >         if (max_sectors > more_than_controller_supports)
> >                 max_sectors = more_than_controller_supports;
> > 
> > or something close to that.
> 
> libata has always done this, modulo the ATA_MAX_SECTORS issue.

I thought so, but then I don't understand your last mail - there's no
problem with 255 sector drivers, then.

-- 
Jens Axboe