https://bugzilla.novell.com/show_bug.cgi?id=338315
User rob.opensuse.linux@googlemail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=338315#c5
Robert Davies changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|NORESPONSE |
--- Comment #5 from Robert Davies 2008-12-09 09:46:28 MST ---
Recently Tejun submitted a kernel patch to turn off UDMA and DMA in ATA
adapters for CD-ROMs on HPT366 controllers. So he ought to have a clue why I
as sysadmin wanted to do hdparm tweaks.
Whilst it is true, that it's nice when drivers do things correctly, that
doesn't allow the sysadmin to account for particular problems in a
configuration.
An original ATA/IDE developer was Andre Hedrik and he had a BP6 board, with the
HPT366 controller. The board permitted Dual Celeron's overclocked to 100Mhz
FSB, so were very desirable (and cheap) compared to the PII offerings at that
time.
So the DVD/CD-ROM having DMA turned off (even if it was on the host controller)
was a stability fix for this board.
Similarly for disks on the HPT366, stability appeared to be improved by using
udma3 not udma4, and an hdparm -X tweak was used there.
When disks are accessed via libata through the pata_ drivers, hdparm(8) appears
to lie, and much of it not work.
There are a number of libata/pata_* issues, and I note the article
http://lwn.net/Articles/198344/ at lwn.net, the feedbacks discuss another
reason or two for wanting hdparm access.
This is really an upstream kernel hackers problem, with how to permit low level
configuration commands like hdparm(8) into the I/O architecture.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
