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

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.