IDE0 and IDE1 taken over by SATA in Gutsy

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.

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

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.

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

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.

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.

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.

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.

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

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

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.

This change does not satisfy the SRU policy.

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.

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

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?

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

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.

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

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

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

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?

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