My system is an Athlon64 3000+ running on a Via KT800 board. Distro is
Ubuntu 5.04, running the Ubuntu AMD64-k8 2.6.11 kernel. However, I've
seen this problem with several other distros and various kernels, so it
seems to be a kernel issue.
Disk Setup:
/dev/sda is a 200GB Maxtor SATA drive containing /boot,/, and swap
/dev/hda is a DVD-ROM/CD-RW driver (IDE)
/dev/hdc is a 160GB Maxtor IDE drive containing ThatOtherOS(TM)
The SATA drive works superbly, in UDMA133 mode. No complaints there.
However, it appears that the generic IDE driver grabs the IDE drives
before the Via driver can get them. This prevents me from using DMA on
those drivers, so, for instance, ripping CDs is really painful. I can
rip at about 2x on a good day, versus 40x+ ripping in Exact Audio Copy
under XP.
You can find the relevant portion of my dmesg (and hdparm) at
http://cg2.org/dmesg.txt
Any assistance would be very much appreciated.
Tyler Eaves wrote:
> However, it appears that the generic IDE driver grabs the IDE drives
> before the Via driver can get them. This prevents me from using DMA on
> those drivers, so, for instance, ripping CDs is really painful. I can
> rip at about 2x on a good day, versus 40x+ ripping in Exact Audio Copy
> under XP.
Disable CONFIG_IDE_GENERIC and CONFIG_BLK_DEV_GENERIC in .config ?
Jeff
>Disk Setup:
>
>/dev/sda is a 200GB Maxtor SATA drive containing /boot,/, and swap
>/dev/hda is a DVD-ROM/CD-RW driver (IDE)
>/dev/hdc is a 160GB Maxtor IDE drive containing ThatOtherOS(TM)
>
>The SATA drive works superbly, in UDMA133 mode. No complaints there.
>However, it appears that the generic IDE driver grabs the IDE drives
>before the Via driver can get them. This prevents me from using DMA on
>those drivers, so, for instance, ripping CDs is really painful. I can
>rip at about 2x on a good day, versus 40x+ ripping in Exact Audio Copy
>under XP.
>
>You can find the relevant portion of my dmesg (and hdparm) at
>http://cg2.org/dmesg.txt
>
>Any assistance would be very much appreciated.
Do you have .config handy? Make shure you've got
CONFIG_BLK_DEV_IDEDMA_PCI
enabled there. In most cases you should be able to control DMA with
generic
driver.
Another thing to double check is that DMA is on in your BIOS.
Aleks.
>
>-
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, 26 May 2005, Tyler Eaves wrote:
> My system is an Athlon64 3000+ running on a Via KT800 board. Distro is
> Ubuntu 5.04, running the Ubuntu AMD64-k8 2.6.11 kernel. However, I've
> seen this problem with several other distros and various kernels, so it
> seems to be a kernel issue.
>
> Disk Setup:
>
> /dev/sda is a 200GB Maxtor SATA drive containing /boot,/, and swap
> /dev/hda is a DVD-ROM/CD-RW driver (IDE)
> /dev/hdc is a 160GB Maxtor IDE drive containing ThatOtherOS(TM)
>
> The SATA drive works superbly, in UDMA133 mode. No complaints there.
> However, it appears that the generic IDE driver grabs the IDE drives
> before the Via driver can get them. This prevents me from using DMA on
> those drivers, so, for instance, ripping CDs is really painful. I can
> rip at about 2x on a good day, versus 40x+ ripping in Exact Audio Copy
> under XP.
Art Perry writes:
See the man page for the utility hdparm.
The VIA driver should know how to apply the UDA modes to the chipset, as
long as the drives do also support the modes.
If the kernel did not auto configure the chipset to this mode, simply tell
it to with the hdparm utility.
Hope this helps.
>
> You can find the relevant portion of my dmesg (and hdparm) at
> http://cg2.org/dmesg.txt
>
> Any assistance would be very much appreciated.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Arthur Perry
Linux Systems/Software Architect, 7+ yrs
Tech Mktng Task Force
non-disclosed corporate association
Disclaimer:
"The contents of this email do not necessarily reflect
the views of my non-disclosed corporate association" ;)