Disabling PIO / LBA48 on large drives , Blade 150

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling PIO / LBA48 on large drives , Blade 150

Bill Johnstone
Hello,

I'm trying to put a Blade 150 to use.  I installed two 160 GB UDMA
drives to replace the 40 GB Seagate drive the machine shipped with.
Unfortunately, the Blade 150 uses the ALI (Acer) M5229 series ATA controller
chip, which (at least for the revs on these Suns) can't do DMA simultaneously
with LBA48 addressing.

In src/sys/dev/pci/pciide.c the acer_dma_init function
seems to handle this by checking to see if the LBA48 flag is turned on, and if
so, returning EINVAL , resulting in PIO transfers only for the disk.  I would
much rather use DMA with some loss of capacity than use PIO, particularly with
the disks I have (it wouldn't be much capacity lost).


See also the thread
at: http://marc.info/?l=freebsd-current&m=112404856418435&w=2


(Q1): Is there
a way to tell the wd or pciide drivers to not use LBA48 even if the drive
supports it?  Looking through the sources, I don't think there is, but I
thought I'd ask to be sure.

(Q2): Assuming there is not a provided way to
turn off LBA48, in terms of booted disk geometry for the disklabels and
filesystems, will the only difference be the number of available cylinders
between LBA48 and "regular" (28-bit) LBA?

Elucidating:
-Suppose I install 4.9
or 5.0 off the bootable install CD with the default LBA48/PIO support, and
make sure that all slices fall below the 128 GiB boundary.  I think disklabel
says that slices need to be on cylinder boundaries, so I would just make sure
to stop allocating slices when I reached the last cylinder fully contained at
or below 128 GiB.
-After that, I then boot the system off disk, patch
src/sys/dev/ata/wd.c to turn off LBA48, build a new kernel, and boot using the
new kernel.
-Then will all the slices and filesystems I created earlier be
accessible just the same, without any errors?


Would there be any translation
differences other than the number of cylinders that would cause issues?  Would
there be any kind of free space tracking in the partition table that would
need to be addressed?


(Q3): Also, is there an easy way to make sure the
controller is being set to use DMA at all?  I'm not an expert in the IDE / ATA
drivers, but it looks like once the controller and device are known to be
capable of DMA, the determination is made on a specific transfer-by-transfer
basis as to whether DMA or PIO get used?  I base this on _wdc_ata_bio_start in
src/sys/dev/ata/ata_wdc.c .  So for the Blade 150, when acer_dma_init is
eventually called from within
_wdc_ata_bio_start , the LBA48-based decision
to return EINVAL results
in a "silent" downgrade to PIO mode, on a
per-transfer basis.  Is my
understanding correct?

If so it doesn't appear
like there's a straightforward way to make sure that generally speaking,
transfers are or are not using DMA, but again I'd like to ask you experts.
Thank you very much.

Reply | Threaded
Open this post in threaded view
|

Re: Disabling PIO / LBA48 on large drives , Blade 150

Nick Holland
On 09/19/11 13:47, Bill Johnstone wrote:

> Hello,
>
> I'm trying to put a Blade 150 to use.  I installed two 160 GB UDMA
> drives to replace the 40 GB Seagate drive the machine shipped with.
> Unfortunately, the Blade 150 uses the ALI (Acer) M5229 series ATA controller
> chip, which (at least for the revs on these Suns) can't do DMA simultaneously
> with LBA48 addressing.
>
> In src/sys/dev/pci/pciide.c the acer_dma_init function
> seems to handle this by checking to see if the LBA48 flag is turned on, and if
> so, returning EINVAL , resulting in PIO transfers only for the disk.  I would
> much rather use DMA with some loss of capacity than use PIO, particularly with
> the disks I have (it wouldn't be much capacity lost).

what if I told you you didn't have to lose disk or UDMA disk performance?

>
> See also the thread
> at: http://marc.info/?l=freebsd-current&m=112404856418435&w=2
>
> (Q1): Is there
> a way to tell the wd or pciide drivers to not use LBA48 even if the drive
> supports it?  Looking through the sources, I don't think there is, but I
> thought I'd ask to be sure.

too much like work.

>
> (Q2): Assuming there is not a provided way to
> turn off LBA48, in terms of booted disk geometry for the disklabels and
> filesystems, will the only difference be the number of available cylinders
> between LBA48 and "regular" (28-bit) LBA?
>
> Elucidating:
> -Suppose I install 4.9
> or 5.0 off the bootable install CD with the default LBA48/PIO support, and
> make sure that all slices fall below the 128 GiB boundary.  I think disklabel
> says that slices need to be on cylinder boundaries, so I would just make sure
> to stop allocating slices when I reached the last cylinder fully contained at
> or below 128 GiB.
> -After that, I then boot the system off disk, patch
> src/sys/dev/ata/wd.c to turn off LBA48, build a new kernel, and boot using the
> new kernel.
> -Then will all the slices and filesystems I created earlier be
> accessible just the same, without any errors?

I do believe so.  I've done a lot of wackier stuff with OpenBSD and disks,
and things Just Work.

But...too much like work again.

>
> Would there be any translation
> differences other than the number of cylinders that would cause issues?  Would
> there be any kind of free space tracking in the partition table that would
> need to be addressed?
>
>
> (Q3): Also, is there an easy way to make sure the
> controller is being set to use DMA at all?  I'm not an expert in the IDE / ATA
> drivers, but it looks like once the controller and device are known to be
> capable of DMA, the determination is made on a specific transfer-by-transfer
> basis as to whether DMA or PIO get used?  I base this on _wdc_ata_bio_start in
> src/sys/dev/ata/ata_wdc.c .  So for the Blade 150, when acer_dma_init is
> eventually called from within
> _wdc_ata_bio_start , the LBA48-based decision
> to return EINVAL results
> in a "silent" downgrade to PIO mode, on a
> per-transfer basis.  Is my
> understanding correct?

dmesg says all.  Here is a snippet from my Blade100:

pciide0 at pci0 dev 13 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc3: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using ivec 0x7cc for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <ST320414A>
wd0: 16-sector PIO, LBA, 19092MB, 39102336 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <COMPAQ, DVD-ROM GD-2000, 0056> ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
...
pciide1 at pci1 dev 1 function 0 "VIA VT6421 SATA" rev 0x50: DMA
pciide1: using ivec 0x7ca for native-PCI interrupt
wd1 at pciide1 channel 0 drive 0: <SAMSUNG HD154UI>
wd1: 16-sector PIO, LBA48, 1430799MB, 2930277168 sectors
wd1(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 2

it says what the device will do.  Not entirely sure why my CDROM
is only good for DMA mode 2 and the SATA drive/SATA interface
will only do UDMA2...but more than sufficient for my use, and
beats PIO.

> If so it doesn't appear
> like there's a straightforward way to make sure that generally speaking,
> transfers are or are not using DMA, but again I'd like to ask you experts.
> Thank you very much.

See the commit message for pciide.c:
  Changes since revision 1.321: +15 -1 lines

  Revision 0xc4 and earlier of the Acer Labs M5229 UDMA IDE controller
  can't do DMA for LBA48 commands.  Work around this issue by
  (silently) falling back to PIO for LBA48 commands.  Access to the
  tail end of large disks will be much slower, but at least it works.

  From NetBSD (Takeshi Nakayama).

  ok jsg@, krw@, deraadt@

how's that for the best of all worlds (all things considering)?
Have ALL your disk, and have all the available performance, too!
Put your frequently used stuff in the 0-128G space, and your
less-used stuff in the 128G+ space.  No recompiling, no kernel
hacking, no jumpers on disks.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Disabling PIO / LBA48 on large drives , Blade 150

Mark Kettenis
In reply to this post by Bill Johnstone
> Date: Mon, 19 Sep 2011 10:47:30 -0700 (PDT)
> From: Bill Johnstone <[hidden email]>
>
> Hello,
>
> I'm trying to put a Blade 150 to use.  I installed two 160 GB UDMA
> drives to replace the 40 GB Seagate drive the machine shipped with.
> Unfortunately, the Blade 150 uses the ALI (Acer) M5229 series ATA controller
> chip, which (at least for the revs on these Suns) can't do DMA simultaneously
> with LBA48 addressing.
>
> In src/sys/dev/pci/pciide.c the acer_dma_init function
> seems to handle this by checking to see if the LBA48 flag is turned on, and if
> so, returning EINVAL , resulting in PIO transfers only for the disk.  I would
> much rather use DMA with some loss of capacity than use PIO, particularly with
> the disks I have (it wouldn't be much capacity lost).

In wd(4), we only actually use the LBA48 flag for requests that
actually need it (see __wdstart()).  So reads and writes from/to the
start of the disk will use the LBA flag and use DMA just fine.

So just make sure you keep the end of your disks empty and things
should just work fine.

Reply | Threaded
Open this post in threaded view
|

Re: Disabling PIO / LBA48 on large drives , Blade 150

Bill Johnstone
In reply to this post by Nick Holland
Thank you so much for your reply.


----- Original Message -----
> From: Nick
Holland <[hidden email]>
> Sent: Monday, September 19, 2011 8:13
PM
> Subject: Re: Disabling PIO / LBA48 on large drives , Blade 150

> See the
commit message for pciide.c:
>   Changes since revision 1.321: +15 -1 lines
>
>   Revision 0xc4 and earlier of the Acer Labs M5229 UDMA IDE controller
>  
can't do DMA for LBA48 commands.  Work around this issue by
>   (silently)
falling back to PIO for LBA48 commands.  Access to the
>   tail end of large
disks will be much slower, but at least it works.

You know, I feel silly.  I
went to the effort of grabbing the 4.9 kernel sources and trying to read
through them to figure out how the whole LBA48 on Acer M5229 situation was
getting handled, etc.  Admittedly a little dangerous, not having done disk I/O
drivers for anything other than DOS, and that too a while back.  I was looking
for a more "obvious" comment like the one in FreeBSD's ATA code, and not
finding it, I wasn't as rigorous as I should have been in trying to understand
what the code was actually doing.

After seeing the commit message via cvsweb
and actually looking at __wdstart(), I now see what's going on.

> how's that
for the best of all worlds (all things considering)?
> Have ALL your disk, and
have all the available performance, too!
> Put your frequently used stuff in
the 0-128G space, and your
> less-used stuff in the 128G+ space.  No
recompiling, no kernel
> hacking, no jumpers on disks.

Yeah, I think that's
called having your cake and eating it too :) (again, all things considered).
Thanks once again for saving me from needlessly wasting my time, wringing my
hands, and all other forms of unnecessary effort and energy by pointing this
out.

Best regards.

Reply | Threaded
Open this post in threaded view
|

Re: Disabling PIO / LBA48 on large drives , Blade 150

Bill Johnstone
In reply to this post by Mark Kettenis
----- Original Message -----

> From: Mark Kettenis <[hidden email]>
> Sent: Tuesday, September 20, 2011 4:57 AM
> Subject: Re: Disabling PIO /
LBA48 on large drives , Blade 150

> In wd(4), we only actually use the LBA48
flag for requests that
> actually need it (see __wdstart()).  So reads and
writes from/to the
> start of the disk will use the LBA flag and use DMA just
fine.
>
> So just make sure you keep the end of your disks empty and things
>
should just work fine.

Thank you for pointing this out.  After seeing Nick
Holland's message, I looked at your commit for rev 1.322 of pciide.c and then
wondered what I was missing since I had already been looking at the 4.9
sources.  A closer inspection of the code revealed exactly what you said here.
Thanks for the changes in the driver and also for your message here.

May I
suggest a note in the pciide(4) manpage mentioning that PIO is only used by
default on the M5229 for transfers above 128 GiB?  It could go in the "BUGS"
section where the quirks of other controllers are also discussed.  I would be
happy to write such a note up and provide a diff if you'd like.

Best
regards.