cvs commit: src/sys/dev/ata ata-all.c ata-all.h ata-chipset.c

[Bruce Evans]

On Fri, 15 Aug 2008, Bernd Walter wrote:

> On Fri, Aug 15, 2008 at 10:55:11AM +0000, Philip Paeps wrote:
>> philip      2008-08-15 10:55:11 UTC
>>
>>   FreeBSD src repository
>>
>>   Modified files:
>>     sys/dev/ata          ata-all.c ata-all.h ata-chipset.c
>>   Log:
>>   SVN rev 181753 on 2008-08-15 10:55:11Z by philip
>>
>>   Introduce a new loader tunable "hw.ata.ata_dma_check_80pin", defaulting to 1.
>>   This can be used to disable the 80pin cable check on systems which forget to
>>   set the bit -- such as certain laptops and Soekris boards.

This should be a sysctl so that it can be set at useful times (after
booting, not before).  Also, the sysctls for setting the mode shouldn't
be subject to the cable check.  Range checking in sysctls is a bug
since it mainly prevents you setting known working values.

> Are those bits per device?
> Because I see the following for a onboard controller:
> [...]
> ACPI APIC Table: <INTEL  DG33BU  >
> [...]
> atapci0: <Marvell 88SX6101 UDMA133 controller> port 0x2018-0x201f,0x2024-0x2027,0x2010-0x2017,0x2020-0x2023,0x2000-0x200f mem 0xe0100000-0xe01001ff irq 17 at device 0.0 on pci2
> atapci0: [ITHREAD]
> ata2: <ATA channel 0> on atapci0
> ata2: [ITHREAD]
> [...]
> ad4: DMA limited to UDMA33, device found non-ATA66 cable
> ad4: 117246MB <Maxtor 6Y120L0 YAR41BW0> at ata2-master UDMA33
> ad5: 156334MB <Maxtor 6Y160P0 YAR41BW0> at ata2-slave UDMA133
> Which is strange, since both drives are on the same cable...

I get this on an oldish VIA motherboard (Gigabyte K8 Triton) which
didn't have the problem until changes in early April 2008.  The bug
seems to be a subtle timing one --
- the bug sometimes didn't show up when I paused ata initialization using
   ddb, but adding long delays at similar places to the debugging pauses
   didn't seem to work
- the changes in early April 2008 are large but don't seem to go near
   either cable checking or timing.

% atapci0 at pci0:15:0:	class=0x01018a card=0x50021458 chip=0x05711106 rev=0x06 hdr=0x00
%     vendor   = 'VIA Technologies Inc'
%     device   = 'VT82xxxx EIDE Controller (All VIA Chipsets)'
%     class    = mass storage
%     subclass = ATA

After downgrading to a new kernel:
Jul 30 23:22:00 besplex kernel: FreeBSD 8.0-CURRENT #545: Tue Jul 29 14:29:22 UTC 2008
% Jul 30 23:22:00 besplex kernel: ad0: DMA limited to UDMA33, device found non-ATA66 cable
% Jul 30 23:22:00 besplex kernel: ad0: 29313MB <IBM DTLA-307030 TX4OA50C> at ata0-master UDMA33
% Jul 30 23:22:00 besplex kernel: ad1: 58644MB <IC35L060AVV207 0 V22OA63A> at ata0-slave UDMA100
% Jul 30 23:22:00 besplex kernel: ad2: DMA limited to UDMA33, device found non-ATA66 cable
% Jul 30 23:22:00 besplex kernel: ad2: 58644MB <IC35L060AVV207 0 V22OA63A> at ata1-master UDMA33
% Jul 30 23:22:00 besplex kernel: acd0: DVDROM <TOSHIBA DVD-ROM SD-M1712/1004> at ata1-slave UDMA33

The cable check always works correctly for ad1 (slave to ad0 master)
but very rarely works correctly for ad0 or ad2 (both masters).

After upgrading to an old kernel:
Aug 13 21:55:52 besplex kernel: FreeBSD 8.0-CURRENT #502: Fri Apr  4 17:09:31 UTC 2008
% Jul 31 00:58:45 besplex kernel: ad0: 29313MB <IBM DTLA-307030 TX4OA50C> at ata0-master UDMA100
% Jul 31 00:58:45 besplex kernel: ad1: 58644MB <IC35L060AVV207 0 V22OA63A> at ata0-slave UDMA100
% Jul 31 00:58:45 besplex kernel: ad2: 58644MB <IC35L060AVV207 0 V22OA63A> at ata1-master UDMA100
% Jul 31 00:58:45 besplex kernel: acd0: DVDROM <TOSHIBA DVD-ROM SD-M1712/1004> at ata1-slave UDMA33

For kernels built up to and including 4 April 2008 17:09:31 UTC, the cable
check always worked correctly for ad0, ad1 and ad2.

Bruce