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.
% [EMAIL PROTECTED]: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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
