IDE0 and IDE1 taken over by SATA in Gutsy

Bug #157909 reported by MSchadone
16
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Low
Unassigned
Gutsy
Invalid
Undecided
Unassigned
Hardy
Fix Released
Low
Unassigned
linux-source-2.6.22 (Ubuntu)
Won't Fix
Unknown
Unassigned
Gutsy
Won't Fix
Wishlist
Unassigned
Hardy
Won't Fix
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.

Revision history for this message
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.

Revision history for this message
MSchadone (mike-schadone) wrote :
Revision history for this message
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...

Revision history for this message
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.

Revision history for this message
Aaron C. de Bruyn (darkpixel2k) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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
Revision history for this message
Matt Mossholder (matt-mossholder) wrote :

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
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
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
Revision history for this message
Aaron C. de Bruyn (darkpixel2k) wrote :

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.

Revision history for this message
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...

Revision history for this message
Matt Mossholder (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?

Revision history for this message
wateenellende (fpbeekhof) wrote : Re: [Bug 157909] Re: IDE0 and IDE1 taken over by SATA in Gutsy

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?
>

Revision history for this message
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
Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

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

Changed in linux:
status: New → Invalid
Revision history for this message
Aaron C. de Bruyn (darkpixel2k) 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.

Revision history for this message
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.
>

Revision history for this message
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
Revision history for this message
Aaron C. de Bruyn (darkpixel2k) wrote :

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

Revision history for this message
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

Revision history for this message
Aaron C. de Bruyn (darkpixel2k) wrote :

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.

Revision history for this message
Aaron C. de Bruyn (darkpixel2k) wrote :

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.

Revision history for this message
Aaron C. de Bruyn (darkpixel2k) 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?

Revision history for this message
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.

Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

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.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

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)
tags: added: kernel-bug
To post a comment you must log in.
This report contains Public information  
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.