IDE0 and IDE1 taken over by SATA in Gutsy

Bug #157909 reported by MSchadone on 2007-10-27
16
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned
Gutsy
Undecided
Unassigned
Hardy
Low
Unassigned
linux-source-2.6.22 (Ubuntu)
Unknown
Unassigned
Gutsy
Wishlist
Unassigned
Hardy
Unknown
Unassigned

Bug Description

This problem seems to mirror "#120145 Gutsy tribe1 server install doesn't detect IDE CD-ROM drive" from what was described. Unfortunately, I am using Ubuntu GG 7.10 (uname -a : Linux odin 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux) and not Tribe.

This issue arises from loading my SATA card and drives before my on-board IDE bus and drives. I have a fujitsu hard drive as my primary master, a cd-rom as my primary slave, a cd-writer as secondary master and a dvd-rom as the secondary slave. On the HighPoint card (1640), I have a 160 GB Seagate and 3 250 GB Seagates in RAID5 array. There is no problem loading everything appropriately since 6.06. Perhaps modules are getting loaded out of order? An excerpt of dmesg is below.

[ 47.748370] HPT374: chipset revision 7
[ 47.748385] HPT374: DPLL base: 48 MHz, f_CNT: 141, assuming 33 MHz PCI
[ 47.752344] HPT374: using 50 MHz DPLL clock
[ 47.752451] HPT374: 100% native mode on irq 5
[ 47.752465] ide2: BM-DMA at 0xb400-0xb407, BIOS settings: hde:DMA, hdf:pio
[ 47.752489] ide3: BM-DMA at 0xb408-0xb40f, BIOS settings: hdg:DMA, hdh:pio
[ 47.752550] ACPI: PCI Interrupt 0000:00:0b.1[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
[ 47.752565] HPT374: no clock data saved by BIOS
[ 47.879651] HPT374: DPLL base: 48 MHz, f_CNT: 122, assuming 33 MHz PCI
[ 47.883561] HPT374: using 50 MHz DPLL clock
[ 47.883674] ide0: BM-DMA at 0xc800-0xc807, BIOS settings: hda:DMA, hdb:pio
[ 47.883693] ide1: BM-DMA at 0xc808-0xc80f, BIOS settings: hdc:DMA, hdd:pio
[ 47.883709] Probing IDE interface ide2...
[...]
[ 48.178862] hde: ST3160211AS, ATA DISK drive
[...]
[ 5.716000] hde: selected mode 0x45
[ 5.716000] ide2 at 0xa400-0xa407,0xa802 on irq 5
[ 5.716000] Probing IDE interface ide3...
[ 6.004000] hdg: ST3250620AS, ATA DISK drive
[ 6.676000] hdg: selected mode 0x45
[ 6.676000] ide3 at 0xac00-0xac07,0xb002 on irq 5
[ 6.676000] Probing IDE interface ide0...
[ 6.964000] hda: ST3250620AS, ATA DISK drive
[ 7.636000] hda: selected mode 0x45
[ 7.636000] ide0 at 0xb800-0xb807,0xbc02 on irq 5
[ 7.636000] Probing IDE interface ide1...
[ 7.924000] hdc: ST3250620AS, ATA DISK drive
[ 8.596000] hdc: selected mode 0x45
[ 8.596000] ide1 at 0xc000-0xc007,0xc402 on irq 5
[ 8.596000] VP_IDE: IDE controller at PCI slot 0000:00:11.1
[...]
[ 8.596000] VP_IDE: chipset revision 6
[ 8.596000] VP_IDE: not 100% native mode: will probe irqs later
[ 8.596000] VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci0000:00:11.1
[ 8.596000] VP_IDE: too many IDE interfaces, no room in table
[ 8.596000] VP_IDE: too many IDE interfaces, no room in table
[ 8.596000] VP_IDE: neither IDE port enabled (BIOS)
[...]
[ 8.620000] SCSI subsystem initialized
[ 8.640000] hde: max request size: 512KiB
[ 8.644000] libata version 2.21 loaded.
[ 8.688000] hde: 312581808 sectors (160041 MB) w/2048KiB Cache, CHS=19457/255/63, UDMA(100)
[...]
[ 8.716000] hde: cache flushes supported
[ 8.716000] hde: hde1 hde2 < hde5 >
[ 8.764000] hdg: max request size: 512KiB
[ 8.804000] hdg: 488397168 sectors (250059 MB) w/16384KiB Cache, CHS=30401/255/63, UDMA(100)
[...]
[ 8.828000] hdg: cache flushes supported
[ 8.828000] hdg: hdg1
[ 8.844000] hda: max request size: 512KiB
[ 8.884000] hda: 488397168 sectors (250059 MB) w/16384KiB Cache, CHS=30401/255/63, UDMA(100)
[ 8.908000] hda: cache flushes supported
[ 8.908000] hda: hda1
[ 8.924000] hdc: max request size: 512KiB
[...]
[ 8.968000] hdc: 488397168 sectors (250059 MB) w/16384KiB Cache, CHS=30401/255/63, UDMA(100)
[ 8.992000] hdc: cache flushes supported
[ 8.992000] hdc: hdc1

If there's anything else that you might need, please do not hesitate.

Thanks.

MSchadone (mike-schadone) wrote :

Ahh... to be more clear, my system's drives should resemble:

/dev/hda - Fujitsu HDD
/dev/hdb - Generic CD-ROM
/dev/hdc - HP CD-Writer
/dev/hdd - MSI DVD-ROM
/dev/hde - Seagate 160GB HDD
/dev/hdg - Seagate 250GB HDD (RAID5 Member)
/dev/hdi - Seagate 250GB HDD (RAID5 Member)
/dev/hdk - Seagate 250GB HDD (RAID5 Member)

Instead, it is actually (with no access to Fujitsu or optical drives):

/dev/hde - Seagate 160GB HDD
/dev/hdg - Seagate 250GB HDD (RAID5 Member)
/dev/hda - Seagate 250GB HDD (RAID5 Member)
/dev/hdc - Seagate 250GB HDD (RAID5 Member)

I should also point out that the IDE controllers are indeed active in BIOS and all of the missing drives show up in the device info screen on preboot. I have attached dmesg and lspci.

Thanks.

MSchadone (mike-schadone) wrote :
Aaron C. de Bruyn (darkpixel2k) wrote :

I have the same issue, and it appears that the kernel config file for 2.6.22-14-generic has a line CONFIG_IDE_MAX_HWIFS=4.
I've never made a kernel package the ubuntu/debian way, but I'm going to try to do this today--as it causes several of the drives in my RAID6 array to not be detected...

Aaron C. de Bruyn (darkpixel2k) wrote :

Reading through the kernel docs, the CONFIG_IDE_MAX_HWIFS=4 seems to be the problem. I upped it to the max of 10 and am recompiling the 2.6.22-14-generic kernel. Once I have a working package and kernel, I'll test it on my server (should be a few more hours) and report back.

If it fixes it, we'll have to plead to the ubuntu kernel packagers to up this setting to the max.

Aaron C. de Bruyn (darkpixel2k) wrote :

That fixed it.
Unfortunately it broke all my restricted modules ;)

MSchadone (mike-schadone) wrote :

That presumably would allow me to load my IDE drives, but I would think that they would be hdi - hjl instead of hda - hdd. Would work, but is a dirty solution. I would prefer it if the kernel loaded things in the order needed.

Please let me know how you make out with the restricted drivers. This might be a solution that I could use for the interim.

MSchadone (mike-schadone) wrote :

This bug is not resolved in 2.6.22, but an upgrade to 2.6.23 and a quick edit of the kernel config allows this problem to be worked out. I followed the following tutorial regarding the kernel upgrade:

[url]http://ubuntuforums.org/showthread.php?t=311158[/url]

And, right before compiling the kernel, I used "xconfig" to change the following:

[code]
CONFIG_IDE_MAX_HWIFS=4
[/code]
to
[code]
CONFIG_IDE_MAX_HWIFS=10
[/code]
though a value of 8 probably would have sufficed.

Now, I have access to every drive on my system and each optical drive (hdb-hdd) mounts automatically when I insert a CD or DVD. And, my RAID is fully functional. I will remain subscribed to this thread in case anyone wants further information.

Thanks for your help, Aaron.

Aaron C. de Bruyn (darkpixel2k) wrote :

I'm assuming this bug gets assigned to the ubuntu-kernel-team since we found the solution and it would require repackaging the ubuntu kernel.

Changed in linux-source-2.6.22:
assignee: nobody → ubuntu-kernel-team
status: New → Confirmed
MSchadone (mike-schadone) wrote :

Assumedly, so. This is definitely a kernel packaging issue. I think a good fix would be to dynamically affix the value to CONFIG_IDE_MAX_HWIFS depending on the devices found (i.e., on-board = 4, PCI card = 4, etc. for a running total of 8 supported slots in my case). Or, they could just figure out a better way that I can't come up with at the moment.

Cheers.

Changed in linux-source-2.6.22:
assignee: ubuntu-kernel-team → timg-tpi
importance: Undecided → High
milestone: none → gutsy-updates
status: Confirmed → Triaged
assignee: nobody → timg-tpi
importance: Undecided → High
milestone: none → gutsy-updates
status: New → Triaged

I'll ditto on this one. I have a 4 port HPT card, and the standard 2 onboard IDE interfaces, and all I can see are the internals and 2 of the ports on the HPT card. This is particularly problematic in the server kernel, where you would expect to encounter a larger proportion of users with lots of disks...

   --Matt

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
Ben Collins (ben-collins) wrote :

Phillip, please see about fixing this in Gutsy for next upload, and in Hardy for 2.6.24 tree. Thanks

Changed in linux-source-2.6.22:
assignee: timg-tpi → phillip-lougher
status: Triaged → In Progress
Changed in linux:
assignee: ubuntu-kernel-team → phillip-lougher
status: Triaged → In Progress
Tim Gardner (timg-tpi) wrote :

Increasing CONFIG_IDE_MAX_HWIFS seems reasonable. The extra space consumed is minimal. scc_init_one is called once for each unique PCI ID/SUBVENDOR ID pair. Each successful probe consumes one slot in the scc_ports[] table. PPC has some MAX_HWIFS unique to specific embedded platform, but they override in source the more general CONFIG_IDE_MAX_HWIFS. I'll update this to 8 for Hardy.

Tim Gardner (timg-tpi) wrote :

This change does not satisfy the SRU policy.

Changed in linux:
assignee: phillip-lougher → timg-tpi
milestone: none → hardy-alpha-2
status: In Progress → Fix Committed
Changed in linux-source-2.6.22:
assignee: timg-tpi → nobody
importance: High → Wishlist
milestone: gutsy-updates → none
status: Triaged → Won't Fix
assignee: phillip-lougher → timg-tpi
importance: High → Unknown
milestone: gutsy-updates → none
status: In Progress → Won't Fix
assignee: timg-tpi → nobody
Changed in linux:
assignee: timg-tpi → ubuntu-kernel-team
importance: Medium → Low

Tim, correct me if I'm wrong, but when you say "This change does not satisfy the SRU policy" are you actually saying that this fix won't make it into gutsy?

If that is the case, I upgraded from feisty to gutsy and it broke my machine. I think that decision should be reconsidered.

MSchadone (mike-schadone) wrote :

I honestly do not believe that any particular static CONFIG_IDE_MAX_HWIFS is reasonable if SATA drives are found before on-board IDE (or, even perhaps, e-IDE cards). I feel the best way for this to be handled is to take inventory of the hardware when the kernel is being installed, leaving the option for the administrator to increase that number if he/she feels that a drive or two or twenty might be added later. Any single digit number would be seriously lacking in this case.

Also, is this issue only affecting systems with older SATA controllers? IDE should show up as hdxx, whereas SATA should show up as sdxx (and, mine do not). If that's the case, I think a simple patch would be effective until the older SATA controllers are all but extinct.

Just some thoughts...

I would beg to differ with the statement that this does not meet the SRU criteria. In particular, this seems to be a "Bugs which represent severe regressions from the previous release of Ubuntu". Previous versions supported these configurations, while with gutsy the follow is the case:

* the configurations impacted are common (how many SATA ports come on modern motherboards? 6? 8?)
* the impact of fixing the situation is minimal (very slight increase in the size of a small table)
* the systems impacted are ones specifically being targeted by Ubuntu (desktops and small to mid-sized servers).

In effect, gutsy has taken something that "just worked" and "just broke" it.

Do we even know why the setting was changed?

I second to that, and I would like to add that the result is a not a
minor inconvenience, but an unbootable system.

IMHO "System becomes unbootable" qualifies as excellent example of
"Bugs which represent severe regressions from the previous release of
Ubuntu"

>
> Do we even know why the setting was changed?
>
To my knowledge, I could very well be wrong, it is a new parameter.

Matt Mossholder wrote:
> I would beg to differ with the statement that this does not meet the SRU
> criteria. In particular, this seems to be a "Bugs which represent severe
> regressions from the previous release of Ubuntu". Previous versions
> supported these configurations, while with gutsy the follow is the case:
>
> * the configurations impacted are common (how many SATA ports come on modern motherboards? 6? 8?)
> * the impact of fixing the situation is minimal (very slight increase in the size of a small table)
> * the systems impacted are ones specifically being targeted by Ubuntu (desktops and small to mid-sized servers).
>
> In effect, gutsy has taken something that "just worked" and "just broke"
> it.
>
> Do we even know why the setting was changed?
>

Henrik Nilsen Omma (henrik) wrote :

I would agree that this should be considered for a Gutsy SRU. https://wiki.ubuntu.com/KernelUpdates list a non-booting system as critical bug fix that is permitted: "... These are bugs that keep users from reliably using their systems, or prevent booting at all. ...".

Or, are there possible negative implications of this change that I don't see?

Changed in linux-source-2.6.22:
status: Won't Fix → Triaged
Henrik Nilsen Omma (henrik) wrote :

Gutsy is 'linux-source-2.6.22', not 'linux'

Changed in linux:
status: New → Invalid

Re the comment about motherboards and interfaces, I just purchased a new board supports 12 SATA connections onboard. It also supports 2 IDE connections. I'm building a mid-range storage server for my home office. Eventually I'll have enough in the budget to toss a RAID card in instead of doing softraid. This could complicate things more due to the fact that a lot of SATA RAID controllers I run into present the array as an IDE drive.

When I did my initial testing on this bug, I noticed the 'make menuconfig' section of the kernel would only allow me to specify a maximum of 9.

On one hand, it's probably unheard of to find a system that supports 9 IDE drives (requiring 4+ IDE interfaces on the board), but on the other hand, it's not unheard of to find RAID cards exposing themselves as IDE drives which could give you a huge number of IDE drives for the system.

wateenellende (fpbeekhof) wrote :

Even disregarding SATA at all: IDE interfaces and drives are still being
used, produced, and sold, and, IMHO, it should be supported.

A gutsy system is unbootable when an extra IDE controller in addition to
the IDE controllers on the main board is installed, which is quite
likely for anyone having >4 IDE drives. That may be rare, but
sufficiently common to affect a significant number of systems.

Aaron C. de Bruyn wrote:
> Re the comment about motherboards and interfaces, I just purchased a new
> board supports 12 SATA connections onboard. It also supports 2 IDE
> connections. I'm building a mid-range storage server for my home
> office. Eventually I'll have enough in the budget to toss a RAID card
> in instead of doing softraid. This could complicate things more due to
> the fact that a lot of SATA RAID controllers I run into present the
> array as an IDE drive.
>
> When I did my initial testing on this bug, I noticed the 'make
> menuconfig' section of the kernel would only allow me to specify a
> maximum of 9.
>
> On one hand, it's probably unheard of to find a system that supports 9
> IDE drives (requiring 4+ IDE interfaces on the board), but on the other
> hand, it's not unheard of to find RAID cards exposing themselves as IDE
> drives which could give you a huge number of IDE drives for the system.
>

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.24-2.4

---------------
linux (2.6.24-2.4) hardy; urgency=low

  [Alessio Igor Bogani]

  * rt: First import for Hardy

  [Amit Kucheria]

  * LPIA: Fix FTBFS for hda
  * LPIA: Trim configs including disabling stock DRM

  [Tim Gardner]

  * SAUCE: Increase CONFIG_IDE_MAX_HWIFS to 8 (from 4)
    - LP: #157909
    Then reverted since it causes an ABI bump. Will pick it up
    again when next the ABI changes.
  * Expose apm for applications.

 -- Tim Gardner <email address hidden> Wed, 19 Dec 2007 13:17:31 -0700

Changed in linux:
status: Fix Committed → Fix Released

I'm bringing this bug up in ubuntu-devel-discuss to try and get some questions answered.

florian (florianroulet) wrote :

Hi,

I'm having this bug on my PC.
I'm under 7.10.
I just tried 8.04 alpha2, with live CD, and this bug still appears, i can not see my drives connected on my HPT374.
Will this be resolved on the release only ? Or should i install 8.04 to see the correction ? (I'm aware this is an alpha)
thanks

Ben, can this get changed from wishlist to something...more urgent?
This is affecting three of my systems. They flat-out won't boot.

The only way I get them to boot is to recompile my own custom kernel...but seeing as I have no clue about recompiling the restricted modules, X is slow as a dog and the resolution sucks.

This looks bad for clients who want to be able to do some basic administration from the GUI.

Works for me in Hardy beta.
It's too bad that my only two recourses are upgrading to an unfinished beta release or recompiling the kernel myself.

It's nice to know that serious regressions get marked as 'wishlist'.
I wish Microsoft treated their clients this way--it would sure go a long way towards solving bug 1.

After pleading (because this bug totally b0rked working systems) to make this something higher than 'wishlist', it's still sitting here almost a year later.

At this point it doesn't look like the developers are going to fix this in Gutsy since they have more pressing issues (Hardy and Intrepid).

It's fixed in Hardy.

Why don't we just close this bug since it's going nowhere?

wateenellende (fpbeekhof) wrote :

Aaron C. de Bruyn wrote:
> After pleading (because this bug totally b0rked working systems) to make
> this something higher than 'wishlist', it's still sitting here almost a
> year later.
>
> At this point it doesn't look like the developers are going to fix this
> in Gutsy since they have more pressing issues (Hardy and Intrepid).
>
> It's fixed in Hardy.
>
> Why don't we just close this bug since it's going nowhere?
>

People affected by this bug have excellent chances of having similar
experiences with Intrepid, most likely if you have a HPT473, although it
hasn't been 100% proven that this driver is the cause.

Hence I would like to ask your attention / effort for the following bug:
https://bugs.launchpad.net/bugs/256316
which actually refers to a bug in kernel bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=11328

In short, the Intrepid kernels have switched to libata. On my system,
data read with this kernel is *corrupted*. Your filesystem will look
broken. If you try to "fix" your filesystem, you will be writing to it -
and corrupt the data on the disk.

If you can afford it, please help. Make sure your filesystems ok
(fsck'ed) with the Hardy kernel. Then install the latest Intrepid kernel
on your system, reboot, (mount your filesystems on HPT47x READ-ONLY!!!) and:
a) do some heavy I/O or and monitor your syslog
b) do "fsck -fn /dev/sdX" for your device.
Note that your former /dev/hdX will now be an /dev/sdX!

If anything bad happens, please report your findings. I haven't observed
any problems with devices attached to other controllers than a HPT473,
but you might want to check them too. If you have problems, please
mention the type of controller, specify your filesystem too.

If Intrepid ships with special data-corruption powers, quite a lot of
people will be in deep shit. We don't need that again. Please help.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Since the Gutsy Gibbon 7.10 release has reached it's end of life, I'm closing the Gutsy nomination here. http://www.ubuntu.com/news/ubuntu-7.10-eol

Changed in linux-source-2.6.22 (Ubuntu Gutsy):
status: Triaged → Won't Fix
Fail2Ban (failtoban) on 2010-02-20
tags: added: kernel-bug
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.