Bug 97414 - Lack of warning when IDE controller not recognized
Lack of warning when IDE controller not recognized
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: distribution (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-14 18:50 EDT by Eli
Modified: 2014-03-16 22:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-02 13:54:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eli 2003-06-14 18:50:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

Description of problem:
When the hardware IDE controller isn't recognized by the kernel, the DMA isn't
enabled, causing the disk operations to be slow, with a severe impact on system
response during heavy disk traffic.

Since the user isn't aware of this, he or she doesn't know that the system's
performance is way lower than possible, and may not take the necessary action (a
kernel upgrade).

A clear comment is needed during the installation process, encouraging the
system's maintainer to check for upgrades, explaining what to expect until the
IDE controller is recognized.

Specifically, this occured with a 2.4.18-3 kernel on the 845PE chipset's
built-in IDE controller, which is readily recognized with the 2.4.21 kernel.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Installing RH7.3 on a motherboard based upon the 845PE chipset.   

Additional info:
Comment 1 Michael Fulbright 2003-06-16 11:26:10 EDT
I am not aware of a generic mechanism to tell if an IDE controller if being used
in a non-optimal way. Do you happen to know of a kernel interface to determine
this information?
Comment 2 Eli 2003-06-16 11:45:35 EDT
This is the the relevant part from /var/log/messages when booting kernel
2.4.18-3. We can clearly see that PCI_IDE didn't recognize the IDE controller,
which was the reason it didn't enable DMA either. (hdparm -d 1 is simply refused
too, if attempted).

May 19 10:02:02 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
May 19 10:02:02 localhost kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
May 19 10:02:02 localhost kernel: PCI_IDE: unknown IDE controller on PCI bus 00
device f9, VID=8086, DID=24cb
May 19 10:02:02 localhost kernel: PCI: Device 00:1f.1 not available because of
resource collisions
May 19 10:02:02 localhost kernel: PCI_IDE: (ide_setup_pci_device:) Could not
enable device.
May 19 10:02:02 localhost kernel: hda: WDC WD800JB-00CRA1, ATA DISK drive
May 19 10:02:02 localhost kernel: hdc: SONY CD-RW CRX220E1, ATAPI CD/DVD-ROM drive
May 19 10:02:02 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
May 19 10:02:02 localhost kernel: ide1 at 0x170-0x177,0x376 on irq 15
May 19 10:02:02 localhost kernel: hda: 156301488 sectors (80026 MB) w/8192KiB
Cache, CHS=9729/255/63
May 19 10:02:02 localhost kernel: ide-floppy driver 0.99.newide
May 19 10:02:02 localhost kernel: Partition check:
May 19 10:02:02 localhost kernel:  hda: hda1 hda2 hda3

And this is the same segment after upgrading the kernel to 2.4.21:

Jun 15 13:18:31 localhost kernel: Uniform Multi-Platform E-IDE driver Revision:
7.00beta4-2.4
Jun 15 13:18:31 localhost kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Jun 15 13:18:31 localhost kernel: ICH4: IDE controller at PCI slot 00:1f.1
Jun 15 13:18:31 localhost kernel: PCI: Enabling device 00:1f.1 (0005 -> 0007)
Jun 15 13:18:31 localhost kernel: PCI: Found IRQ 9 for device 00:1f.1
Jun 15 13:18:31 localhost rpc.statd[926]: unable to register (statd, 1, udp).
Jun 15 13:18:31 localhost kernel: PCI: Sharing IRQ 9 with 00:1d.2
Jun 15 13:18:31 localhost kernel: PCI: Sharing IRQ 9 with 02:05.0
Jun 15 13:18:31 localhost kernel: PCI: Sharing IRQ 9 with 02:02.0
Jun 15 13:18:31 localhost kernel: ICH4: chipset revision 2
Jun 15 13:18:31 localhost kernel: ICH4: not 100%% native mode: will probe irqs later
Jun 15 13:18:31 localhost kernel:     ide0: BM-DMA at 0xffa0-0xffa7, BIOS
settings: hda:DMA, hdb:pio
Jun 15 13:18:31 localhost kernel:     ide1: BM-DMA at 0xffa8-0xffaf, BIOS
settings: hdc:DMA, hdd:pio
Jun 15 13:18:31 localhost kernel: hda: WDC WD800JB-00CRA1, ATA DISK drive
Jun 15 13:18:31 localhost kernel: blk: queue c02deda0, I/O limit 4095Mb (mask
0xffffffff)
Jun 15 13:18:31 localhost kernel: hdc: SONY CD-RW CRX220E1, ATAPI CD/DVD-ROM drive
Jun 15 13:18:31 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jun 15 13:18:31 localhost kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jun 15 13:18:31 localhost kernel: hda: attached ide-disk driver.
Jun 15 13:18:31 localhost kernel: hda: host protected area => 1
Jun 15 13:18:31 localhost kernel: hda: 156301488 sectors (80026 MB) w/8192KiB
Cache, CHS=9729/255/63, UDMA(100)
Jun 15 13:18:31 localhost kernel: ide-floppy driver 0.99.newide
Jun 15 13:18:31 localhost kernel: Partition check:
Jun 15 13:18:31 localhost kernel:  hda: hda1 hda2 hda3
Comment 3 Eli 2003-06-16 11:55:51 EDT
Besides, 

hdparm -d /dev/hda

tells me if DMA is enabled or not. It's quite reasonable to assume that if a
hard disk above, say, 1 GB hasn't DMA enabled, something is wrong.

Enough to alert the intaller or maintainer that it's something worth checking.

hdparm -Tt /dev/hda could also be used to check how fast the drive goes.

This issue may be generalized further: Users should be encouraged to benchmark
their systems, and compare the results against some internet site.

It's bad when a system works poorly, but it's much worse when the user doesn't
know it can be improved.
Comment 4 Michael Fulbright 2003-06-19 14:41:06 EDT
Thank you for the proposal we will take it into consideration. With serial ATA
support also on the horizon it may be useful to have a way to warn of common
situations where driver support is not robust yet.
Comment 5 Jeremy Katz 2003-06-19 18:01:21 EDT
It's already mentioned in the kernel messages and you should always update to
the latest errata after doing an installation.  Grepping kernel messages is not
a good way to programatically determine chipset support.
Comment 6 Eli 2003-06-19 18:14:21 EDT
The kernel messages were posted only to show what kind of problem we're facing,
not as a suggestion of how to solve it. Indeed, grepping the kernel messages is
no real solution.

While updating is in general recommended, a large part of Linux users will not
update their systems if they appear to work properly. This is especially true
with intermediate-level users, who use their Linux machine as a workstation.

Leaving the situation as is may have a very negative effect in Linux'
reputation, and Red Hat in particular. A slow disk for no apparent reason is a
severe issue for a serious operating system. A clear, explicit warning, which
will reach any novice's attention is an absolute minimum.
Comment 7 Jeremy Katz 2003-06-19 18:56:53 EDT
I disagree, but if its going to be done anywhere, the installer is entirely the
wrong place to do it.
Comment 8 Bill Nottingham 2005-03-02 13:54:23 EST
Closing bugs on older, no longer maintained, releases. Apologies for
lack of response.

I don't think this is behavior we're currently planning to add.

Note You need to log in before you can comment on or make changes to this bug.