[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/55540 (aceride Fails To Downgrade Transfer Mode)
The following reply was made to PR kern/55540; it has been noted by GNATS.
From: Jaromir Dolecek <jaromir.dolecek%gmail.com@localhost>
Cc: jdolecek%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
Subject: Re: kern/55540 (aceride Fails To Downgrade Transfer Mode)
Date: Sun, 9 Aug 2020 11:09:07 +0200
I will look into this once I am back from vacations on Aug 16th
> Le 9 ao=C3=BBt 2020 =C3=A0 07:45, Martin Husemann <martin%duskware.de@localhost> a =C3=
> =EF=BB=BFThe following reply was made to PR kern/55540; it has been noted b=
> From: Martin Husemann <martin%duskware.de@localhost>
> To: Kyra Sable <kyra.sable%mail.ru@localhost>
> Cc: gnats-bugs%netbsd.org@localhost
> Subject: Re: kern/55540 (aceride Fails To Downgrade Transfer Mode)
> Date: Sun, 9 Aug 2020 07:43:02 +0200
>> On Sat, Aug 08, 2020 at 11:20:14PM -0400, Kyra Sable wrote:
>> Scarcely "not relevant any more" given NetBSD's intended target audience.=
> Thanks for hunting this done, but I think you misunderstood the commit log=
> message. We certainly still care for this devices still.
> I have never seen this exact version of the error / downgrade path, and
> I am typing this on a machine that has one:
> aceride0 at pci3 dev 13 function 0: Acer Labs M5229 UDMA IDE Controller (r=
> aceride0: bus-master DMA support present
> aceride0: using PIO transfers above 137GB as workaround for 48bit DMA acce=
ss bug, expect reduced performance
> aceride0: primary channel configured to native-PCI mode
> aceride0: using ivec 1f98 for native-PCI interrupt
> cd0 at atapibus0 drive 0: <JLMS XJ-HD166S, , D3S4> cdrom removable
> cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
> cd0(aceride0:1:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DM=
> and the cd works fine.
> BUT: I have a ATA<->SD card converter on that ATA bus that I use to boot t=
> machine (all "disks" on SATA that firmware does not know about), and I hav=
> to disable UDMA on that, otherwise it will not be able write to the "disk"=
> (but then failure mode looks quite different to what you reported).
> I always assumed this is a bug in the firmware of the SD card converter.
> I will put another (real) ATA disk in this machine and test, and also chec=
> if I have more machines with aceride.
> This might be a driver bug, or a quirk in combination with certain ATA dis=
> and aceride. We need to dig deeper and avoid the original HBA error, or
> recognize the issue and adjust capabilities, so we end up with a working
> setup w/o the error -> degration path.
> P.S.: Jaromir - could this be similar to the cmdide issue we fixed recentl=
Main Index |
Thread Index |