SATA disk is in PATA mode with kernel 2.6.20-16-generic (piix claiming SATA controller on some U100/ICH4/ICH5/ICH6/ICH7 Intel chipsets)

Reported by klmonz on 2007-05-26
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
linux-source-2.6.20 (Ubuntu)

Bug Description

Binary package hint: linux-image-2.6.20-16-generic

linux-image-2.6.20-15-generic worked fine with following system:
feisty, xfs root fs (all in one) on SATA disk on an intel ICH5 SATA controller (I965 chipset)

after upgrading to linux-image-2.6.20-16-generic, the SATA disk is no more under control of ata_piix, which is not loaded anymore,
SATA disk becomes /dev/hdc (/dev/hda being the DVD drive) instead of /dev/sda as with 2.6.20-15

the SATA disk being under control of piix does not pose a real problem (rumor has it this was intented by kernel devs to resolve a lot of other troubles),
but on some ICH4/ICH5/ICH6/ICH7 controllers IRQ problems rise (see comments below), rendering systems unusable

with kernel boot parameter "irqpoll", some systems seem to work

Jean Dumont (jean-dumont) wrote :

I have exactly the same problem

First a message about irq 16 being disabled and having to try to boot with the "irqpool" option
Then messages about hde losing it's interrupt and it just stay there forever

angelolailo (angelolailo) wrote :


Adept-notifier show me a new kernel update, I thought it was for security or so...

i686 with 2.6.20-15 working, sda1 <-ntfs sda2 <-fat32 sdb1(swap), sdb2 , sdb3, sdb4(root) <-ext ALL IDE DEVICES, but called /dev/sdxy
After upgrading to 2.6.20-16, Grub menu entries about sda1(windowsXP), sdb2, sdb3, (Guadalinex, based on ubuntu) disaperar, but not about sdb4: 2.6.20-[12/15/16]: changed UUID
In Grub menu.lst:

title Ubuntu, kernel 2.6.20-16-generic (recovery mode)
root (hd1,3)
kernel /boot/vmlinuz-2.6.20-16-generic root=UUID=70b3941b-8bc6-47bf-96a0-68c6c7cab909 ro single
initrd /boot/initrd.img-2.6.20-16-generic

title Ubuntu, kernel 2.6.20-15-generic
root (hd1,3)
kernel /boot/vmlinuz-2.6.20-15-generic root=UUID=70b3941b-8bc6-47bf-96a0-68c6c7cab909 ro quiet splash
initrd /boot/initrd.img-2.6.20-15-generic

In Grub menu.lst~:

title Ubuntu, kernel 2.6.20-15-generic (recovery mode)
root (hd1,3)
kernel /boot/vmlinuz-2.6.20-15-generic root=UUID=41aa5966-7515-4be4-b056-a65f5ac9686c ro single
initrd /boot/initrd.img-2.6.20-15-generic

I mean, UUID changed.

Trying to start new 2.6.20-15 or 2.6.20-16:

Starting up...
Loading, please wait...
          Checkboot= rootarg cat /proc/cmdline
          or missing modules, devices: cat /proc/modules ls /dev
ALERT! /dev/disk/by-uuid/70b3941b-8bc6-47bf-96a0-68c6c7cab909 does not exist. Dr
opping to a shell!

BusyBox blah blah blah

/dev/sdxy doesn't exist and /dev/hdxy appears for the first time on my kubuntu filesystem.

Recovered old entries in menu.lst, 2.6.20-15 works again, some multi-claimed inodes but fixed with fsck.

should i change UUID at Grub menu.lst 2.6.20-16 entrie?

Hopping being helpful, and sorry for my poor english.

klmonz (klaus-monz) wrote :

hello angelolaio,

first, I think you experience the same problem when upgrading to 2.6.20-16, your SATA disks seem to work in IDE compatibility mode (meaning, they are under the reign of the IDE driver instead of the SATA driver). That's why they show up as hdxy and not as sdxy.

Concerning your changed UUID, this is strange; I would not expect disk UUIDs to change unless you re-created (deleted and newly defined) your filesystem(s). If this is not the case, your grub menu.lst entries should point to the same root UUIDs. So you could give it a try and change the UUID of the 2.6.20-16 entry to match the one for the 2.6.20-15 - but I would expect your system won't run stable then (if it will boot at all, this will depend on your SATA controller and -settings). If it works, I think performance will be poor.

Concerning your disappeard menu.lst entries, to have them survive future updates, you have to place them outside of the region marked
a LOT of lines...
this is documented within menu.lst around the ### BEGIN AUTOMAGIC ..... line
If those lines are missing in your menu.lst, I cannot tell wether this is a Guadalinex issue, I don't know this distribution.
I will send you my ubuntu 7.04 grub menu.lst by email.

angelolailo (angelolailo) wrote :

Thx for response :)
No SATA drivers: it was surprising for me to find all my IDEs as sdxy first time i installed festy
Hahaha, no recreated filesystem: i dont know how... but adept_manager could be guilty.
Let's gonna change UUID at 2.6.20-16 and I'll tell u my adventure about it.

Thx for this a-bit-more learned.
Make me know anything I can do for u: reports, log, dmesg |tail...

Jean Dumont (jean-dumont) wrote :

First of all I'm not a kernel developper nor have I any kind of experience in kernel developement so maybe what i will write is total crap

in drivers/ata/ata_piix.c I have (lines 210-215) 2.6.20-16

         /* NOTE: The following PCI ids must be kept in sync with the
         * list in drivers/pci/quirks.c.

        /* 82801EB (ICH5) */
        { PCI_VINTEL(PCI_DEVICE_ID_INTEL_82801EB_1), ich5_sata }, (that's my driver according to lspci)
so I went and had a look at drivers/pci/quirks.c and found nothing but
 PCI_VINTEL(PCI_DEVICE_ID_INTEL_82801EB_0 (at lines 447, 1096 and 1102)

So the comment in pata_iix.c said to keep it in sync but this does not seem to be the case.

The corresponding lines in version 2.6.20-15 od drivers/ata/ata_piix.c are totally different


angelolailo (angelolailo) wrote :

Sorry for spaming.
No SATA devices in my computer, but sdxy until 2.6.20-16.

Rocko (rockorequin) wrote :

I can confirm that the IDE-SCSI emulation is also broken in 2.6.20-16 on my laptop.

My main (IDE) drive now mounts as /dev/hda instead of /dev/sda, and the CD mounts as /dev/hdc instead of /dev/scd0.

This is a pain, because it looks like cds aren't mounting until you change the fstab file to correct the link (and obviously you can't specify a generic UUID for the cdrom).

angelolailo (angelolailo) wrote :

...and after changed UUID:
- there is not /dev/sda: sdxy changed to hdxy (as ought to be,as used to be after festy) ALL IDE ATA devices
- All looks working correct by now: no error

angelolailo (angelolailo) wrote :

Sorry for spaming.
...as used to be BEFORE festy...

taj (othertaj) wrote :

Same here with HP nx6110 laptop. Cannot boot from 2.6.20-16, with 2.6.20-15 I can boot.
Problems started after upgrade from Dapper via Edgy to Feisty. hdX was changed in UUID and I got swap space assigned twice as well (see https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96715)

The cause of the problems may be an incomplete change to UUID in parts of the system, or, as it seems, an update that (like Dapper) assumes that the system has hdX assigned to IDE drives.

mark_s (msabath) wrote :

Hi all,

I have the same problem. Two weeks ago I installed 7.04 and all worked fine. Until yesterday. I upgraded to kernel 2.6.20-16. The system won't boot. With 2.6.20-15 it boots.

Same here... My south bridge is:

00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)

I attach also my menu.lst from grub and my fstab. They are all in UUID form so there is not an excursion i think... It's definitely a critical bug...

I think it is still be able to boot (till the point it lost interrupt ), at least, because my system is on an IDE disk...

# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=c22a0f7d-a949-4723-85ab-43b7d099213c / ext3 defaults,errors=remount-ro 0 1
# /dev/sda3
UUID=0456-3B23 /media/sda3 vfat defaults,utf8,umask=007,gid=46 0 1
# /dev/sdb1
UUID=068C41CE8C41B947 /media/sdb1 ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sdb2
UUID=145C8A5B5C8A380E /media/sdb2 ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sdc1
UUID=F880FF9280FF559A /media/sdc1 ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sda2
UUID=5db56b1d-c206-4566-8738-879d4f30732c none swap sw 0 0
/dev/scd0 /media/cdrom0 auto user,noauto 0 0
/dev/scd1 /media/cdrom1 auto user,noauto 0 0

/dev/sda1 and
/dev/sda3 are IDE disks....

They detected like this when i install feisty... When i had edgy they were detected as

/dev/hda1 and
/dev/dda3 ....

PS sorry for the double comment....

taj (othertaj) wrote :

For me, the following solved this particular problem (swap space assigned twice bug still exists):

:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.20-16-generic
W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .
W: mdadm: no arrays defined in configuration file.
W: mdadm: falling back to emergency procedure in initramfs.

Because I do not have raid, I am not too worried about the mdadm messages, although I find them confusing.

taj (othertaj) wrote :

I got into the system, booting in 2.6.20-16, by pressing ctrl-alt-F1after the system stopped.
There I got the following message:

Could not stat the resume device file
Please type in the filename to try again or press ENTER
to boot the system

(I pressed enter)

To update for all kernels type
sudo update-initramfs -u -k all

The unofficial survey going on here: http://ubuntuforums.org/showthread.php?t=456662&page=20 starting post#195 might yeld some clues...

.. and it would seem there's a lot of folks with Intel ICH4 and ICH5 there.

Sitsofe Wheeler (sitsofe) wrote :

Let's move this into the confirmed state...

Changed in linux-source-2.6.20:
status: Unconfirmed → Confirmed
Sitsofe Wheeler (sitsofe) wrote :

Moving back to unconfirmed because I don't have the power to follow https://wiki.ubuntu.com/KernelTeamBugPolicies#head-802e1d04d7147a6db9be018e76874dc55f9d6afa ...

Changed in linux-source-2.6.20:
status: Confirmed → Unconfirmed
Sitsofe Wheeler (sitsofe) wrote :

This could also be seen as a more focussed version of Bug #117314 ...

José Tomás Atria (jtatria) wrote :

it definitely is a more focused version of that one. But i still see two problmes here (coul'd be that i don't know enough, i am total noob in regards to kernel workings), one related to the resume images not being found, and another related to the disks missing their IRQ calls.

Am i wrong or are these two different issues?

@LarsBjerregaard: looks like you are right. i'm not at my box to right now to produce a lspci output, but i can confirm that my box has an ICH5 intel south bridge, on an ASUS p4p800.

Sitsofe Wheeler (sitsofe) wrote :

Hmm. The question "broken resume problem" begs another question - how was the resume partition referenced in /etc/fstab and /etc/initramfs-tools/conf.d/resume ? Was it with a uuid or was it with the /dev/sd?? syntax? If it was the later then I would not expect it to work with a change such as this and the question becomes who or what set it to /dev/sd?? and why.

The IRQ timeouts could be due to bugs in the intel PATA drivers on new machines (that might not have been seen because they were using intel SATA drivers up until now). The next question is "Does _everyone_ who has an Intel SATA board get these IRQ timeouts or is it some subset (and if it's a subset what's common between them)?".

Sitsofe Wheeler (sitsofe) wrote :

After more thinking I think this could have grub consequences too:
does not use uuids.

José Tomás Atria (jtatria) wrote :

Sitsofe Wheeler :
from what i see in my setup, /etc/initramfs-tools/conf.d/resume references a resume image by UUID. Fstab has only UUID references, and i do NOT have the issue with resume images, at least not in that flavor. The boot log says something about resume, but then produces the IRQ timeouts.

That leaves two options:

1.- it is the same problem, but the symptoms differ: if you have UUID references, the isue manifests itself as an IRQ timeout. If you have /dev/ references, the issue manifests itself as a resume image not found.

2.- They are two difernt beasts, one related to a bug in the SATA/PATA controller, other related to obsolete /dev/ references produced by the change in behaviour in disk recognition.

Purely speculating here, though, i don't know a thing about how resume images are created, referenced or loaded, or why a reference problem could be related to a driver issur, but my guess is that 2 is more correct, at least form what i've see in my box, and form the fact that if you have the "resume not found" problem, you still seem to be able to boot, wich is not my case: my box hangs dead in those IRQ timeouts when i try to boot with no "press enter to boot" for me.

LarsBjerregaard :
I have produced my lspci output and it is now posted in the survey as post #305. i'm bukharin in the ubuntu forums.

José Tomás Atria (jtatria) wrote :

oh, and about the grub consequences:

i don't think they are a problem, as grub uses a completely different way of referencing disks, (hd0,0) and the like... as far as i know, grub does not make any difference betwen hd* or sd*, and i would think that if those references got messed up, it would be impossible to pass beyond grub stage1. I think no one has had that problem, everything seems to be related to the kernel load process, grub work just fine, independently of how the kernel chooses to call its drives, and of course, independently of how it chooses to communicate with them, as it gets its disk information form the BIOS, long before the kernel exists.

As a matter of fact... what are the references in /boot/grub/device.map for? grub does not need them, right? who reads those?

Sitsofe Wheeler (sitsofe) wrote :

Re: two issues
I think you're right. It's possible to have the resume issue and not the IRQ issue. If you have both then I assume the resume issue will mask the IRQ issue until its resolved? My thinking is the resume issue only manfiests itself if your resume partition is referenced using the non uuid syntax or if the swap partition being used for suspend is "reformatted" using mkswap (in which case it gets a new uuid).

I believe /boot/grub/device.map is used to try and work out what order the BIOS sets disks up in and how they relate to the Linuxes idea of disks (so a mapping is made between grub's hd() syntax (which at boot time is dependent on the BIOS) and linuxes hda/sda syntax). It will only impact you if you are reinstalling the grub bootloader (i.e. redoing the MBR). A kernel update will not do that but upgrading to the next version of Ubuntu might...

In other news, I have just tested this on a machine with ICH7 controller and the ata_piix is loaded correctly and used in 2.6.20-16.

klmonz (klaus-monz) wrote :

@Gorgonzola & Sitsofe Wheeler:

concerning the resume images I would guess there is a /dev reference in fstab, too.

regarding grub, to my experience the device.map is only used when installing grub onto a drive (by grub shell or by "grub-install")

I did the update-initramfs already before opening this thread, but it (obviously ;-) didn't help me.

Sitsofe Wheeler (sitsofe) wrote :

OK I managed to find a machine with a ICH5 controller inside it
( 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
  00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) )
and I see that ata_piix is disasbled in 2.6.20-16. I see the incorrect cdrom references in /etc/fstab (which I think might be worth spinning off into a bug of their own) but I *don't* any IRQ timeouts or IRQs being disabled. I'd be curious to know if the folks suffering IRQ issues can check (no need to install it yet) whether there is a later BIOS for their motherboard...

David Portwood (dzportwood) wrote :

When the kernel updated, grub/fstab entries should have been updated to reflect the changes from hdX to sdX. There have been reports of users with modified (custom) grub and fstab not being changed to reflect the changes. This is still related to the recent overhaul of pata kernel drivers.

unfortunately, I'm already at the latest level supplied for my board
(gigabyte ga-8i848p-g level F5).

do you know wether disabling ata_piix was done intentionally with the
2.6.20-16 kernel package?

Sitsofe Wheeler schrieb:
> OK I managed to find a machine with a ICH5 controller inside it
> ( 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
> 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) )
> and I see that ata_piix is disasbled in 2.6.20-16. I see the incorrect cdrom references in /etc/fstab (which I think might be worth spinning off into a bug of their own) but I *don't* any IRQ timeouts or IRQs being disabled. I'd be curious to know if the folks suffering IRQ issues can check (no need to install it yet) whether there is a later BIOS for their motherboard...

erstellt & versendet mit freier software

José Tomás Atria (jtatria) wrote :

just to summarize:

I have an ICH5 chipset.
All my references are made through UUID's, not /dev (this includes
/etc/initramfs-tools/conf.d/resume, /etc/fstab and
I do not see any problems with resume images.
I get IRQ timeouts on my devices.

SItsofe reports that with an updated ICH5 controller, the IRQ's no
longer appear (even using dev references?). I have to see if i can
confirm this with a BIOS update.

I would generalize form the above that
1.- 'IRQ' and 'resume not found' are two different things,
2.- 'IRQ' affects only ICH4 and ICH5 chipsets with older BIOS'es, wich
are *quite* common, ICH7 and ICH5 with new BIOS'es work fine.
3.- resume images are a problem with references not being updated
after the kernel update. Since this is not *critical* for the kernel
boot process, you can still boot by disregarding the resume and doing
a clean boot ("press enter to boot")... right?

Unless i lost some piece of the puzzle around here...

ps: i repeat, i have 0 experiencie with kernel things, this is just my
take on the matter, i could be totally lost here.

José Tomás Atria (jtatria) wrote :

oh, Gorgonzola == José Tomás Atria.


There's no need to talk about the "missing" resume partition problem in this bug any longer. That issue needs to be spun off into a new bug of its own (and ideally a link to that bug posted within this one). This deals with 1. and 3.

I don't think the change in 2.6.20-16 affects ICH7 controllers - unlike the ICH5 the ICH7 I tested was still using ata_piix in 2.6.20-16 (i.e. ata_piix is only disabled for the ICH4/ICH5). Do we have any ICH6 sda -> hda "switchers"?

We need to find out what the link is between IRQ timeout sufferers. Are they only ICH5 owners? If so is there something else which links these suffers together but excludes others ICH5 owners? My BIOS idea was only speculation. Perhaps cat /proc/interrupts will show that the disk controller is being shared with another device?

Finally, Bug #117413 looks like a good focal point for discussing the /dev/sda problem for *only* CDROM drives (perhaps the /dev/cdrom symlinks should be used instead since CD drives don't have UUIDs)?

Asus MB P4P800-X with chipset Intel 865PE, Intel ICH5.
System HardDisk SATA Model Number: Maxtor 6B200M0 Firmware Revision: BANC1BY0.

with kernel 2.6.20-16-generic I had to use irqpoll option to boot and the sata HD is seen as /dev/hdg.

with kernel 2.6.20-15-generic no problem at all, the PC was working perfectly well and the sata HD was seen correctly as /dev/sda.

attached dmesg lsmod lspci -vvnn (2.6.20-16 and 2.6.20-15)

Sitsofe Wheeler (sitsofe) wrote :

Interesting. On -15 your USB and IDE controller are sharing IRQ 18 without issue. On -16 they are sharing IRQ 16 and there's an issue. Can you include a
cat /proc/interrupts for both -15 and -16?

 Sitsofe Wheeler

Hi, I've searched/cross checked the forum and at least 2 people with ICH6 chipset state they DONOT have issues with the kernel.

One a dell410 is almost identical to my nc6120

This may be a red herring as if I hadn't done some previous messing with suspend and scattered /dev/sda1's around multiple config files I wouldn't have noticed anything (except ghost CDrom) .

So probably a none messed around non upgraded feisty install without sata drives does not show any problems on ICH6 even though under the hood its gone native.

It makes no odds to me but a note in the changelog if they are going to change us all back to libata might be nice in the next update.

I don't know what to have as my default options /dev/sda1 or /dev/hda1 talk about moving goal posts ;-)

Sitsofe Wheeler (sitsofe) wrote :

Go with UUIDs where you have the choice. It means if the drives get shuffled (e.g. you add a new primary drive and move an existing drive to another port or you put the drive in a new machine) then things will (theoretically) still work.

Sitsofe Wheeler (sitsofe) wrote :

(PS: Andrew: Thanks for searching the forrm)

yes i use uuid for my root drives

but not for my swap as fairly simple manipulation changes the uuid whereas unless you change the driver ( ;-) ) the physical drive/partitiion will remain constant.

I got bit for about 3 hours trying to figure out why suspend wouldn't work and it was because i'd run mkswap, since then I go physical drives.

mongo (mongio) wrote :

Sitsofe Wheeler:

Asus MB P4P800-X with chipset Intel 865PE, Intel ICH5

I did a cat /proc/interrupts for both -15 and -16, please look at the attached file.


klmonz (klaus-monz) on 2007-05-31
description: updated
description: updated
klmonz (klaus-monz) on 2007-05-31
description: updated

I think klmonz in the appended bug-description at the top, hits the nail on the head.

Reading through the extensive thread in http://ubuntuforums.org/showthread.php?t=456662, it seems obvious, that Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419458 describes the core problem with disks, which is the same as *this* bug.

This is FIXED in Debian! I'm sorry, but I have to say that I find it disheartening, that bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116996 is still unconfirmed+undecided, bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117447 is unconfirmed+undecided, and bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117314 is unconfirmed, though recognized as status high.

Please devs! You are probably overburdened, that's understood. BUT.... this bug is wrecking the systems of a hell of a lot of users, and if far worse than the X-oops update you released some time ago. This one is GRAVE, as the Debian bug correctly states. Please please... fix this. Thank you.

Sitsofe Wheeler (sitsofe) wrote :

I believe that Debian bug is not this issue. There is no cycling of which driver is loaded in 2.6.20-16-generic with an ICH5 (it's always piix), so this is not that issue.

Sitsofe. I believe that is incorrect. If you read (the 40 pages) in http://ubuntuforums.org/showthread.php?t=456662 a lot of the descriptions matches the Debian bug, also for ICH5. I'm fairly certain that it is at the heart of the problem.

Cycling between piix and ata_piix should not be happening. Previously, in 2.6.20-15.27 ata_piix was used, in 2.6.20-16.28 piix should alwayds be being used. It is this driver which is causing problems for some hardware.

Changed in linux-source-2.6.20:
assignee: nobody → phillip-lougher
status: Unconfirmed → In Progress
importance: Undecided → High

I'm with lars and philiip on this... the debian bug shows erratic
behaviour in regards to wich driver wins over the IRQ race. in this
version, we only seem to have a (wrong) consistent winner...

That does not deny the fact that there is a race going on between the
two drivers for IRQ 16, wich is at the core of the problem.

I must say that i had higher hopes for the ubuntu support chain...
it's been five days or so and we haven't moved an inch through the
regular process, although it was clear form the start that it was
reproduceable and critical. I thought debian and ubuntu were more
alike in this respect, now i see that ubuntu has some catching up to
do :)

ps: incidentally, one would think that a bug with erratic behaviour is
much harder to diagnose... kudos to the debian devs on that one!

I to have to concur with Phillip and Sitsofe

here is my lsmod output for libata (ICH6)

libata 125720 1 ata_generic
scsi_mod 142348 3 sr_mod,sbp2,libata

note a distinct lack of ata_piix

so no cyclic argument ata_piix just doesn't get a look in

Though I think we may be seeing the results of a 'fix' for the Debian issue.

It is not so much the Driver with an issue (its not loaded) but the hardware detection (who gets to drive what)

having now read bug 117314

ignore the last 2 lines in my previous comments

mongo (mongio) wrote :

Sitsofe Wheeler:

Asus MB P4P800-X with chipset Intel 865PE, Intel ICH5

Disabling SATA at bios level and running ubuntu from PATA HD makes 2.6.20-16-generic working as good as 2.6.20-15-generic, it boot smooth without irqpoll option and has no performance losses.

Sitsofe Wheeler (sitsofe) wrote :

Do you have a definitive list of chipsets which have been reverted to PATA by the 2.6.20-16 change?

Sitsofe Wheeler (sitsofe) wrote :

OK just got through testing an ICH6 and...
.. it's still using ata_piix in 2.6.20-16.

lspci -vvv information:
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) (prog-if 8a [Master SecP PriP])
        Subsystem: Micro-Star International Co., Ltd. Unknown device 7058
lspci -vvvn
00:1f.1 0101: 8086:266f (rev 03) (prog-if 8a [Master SecP PriP])
        Subsystem: 1462:7058


yet mine doesn't
00:1f.1 0101: 8086:266f (rev 03) (prog-if 8a [Master SecP PriP])
        Subsystem: 103c:099c

libata 125720 1 ata_generic

guess only the kernel devs can answer this one

Why some ich6 are using ata_piix and others ata_generic.....it makes no sense

same chip same variant different subsystem different driver ???????

and for completeness

same machine in 2.6.20-15
libata 125720 2 ata_piix,ata_generic

unixnewbie (darfsten) wrote :

Don't know if this will help this bug or not but I am a ubuntuforums member and have been trying to keep spirits high and try to console those who feel that Ubuntu has really screwed up here, sad to say that I don't have much of an arguement when something as large as this occurs.

Anway, back to the subject at hand, all my SATA drives are still being handled by SCSI emulation (i think that's what it means when you see SATA devices show up with the /dev/sdXY device id) Here is my output from lspci -vvv for my IDE controllers.
00:0f.0 IDE interface: VIA Technologies, Inc. VT8237A SATA 2-Port Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO])
        Subsystem: ASRock Incorporation Unknown device 0591
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin B routed to IRQ 21
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07) (prog-if 8a [Master SecP PriP])
        Subsystem: ASRock Incorporation K7VT2/K7VT6 motherboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
(NOTE: I am not sure why the second IDE controller doesn't have a line for the Interupt but it doesn't)

This is a ASRock 775dual-VSTA motherboard. And this is what shows for libata under lsmod:
libata 125720 2 sata_via,ata_generic

So this chipset does NOT have this problem, I hope this info is helpful.

Sitsofe Wheeler (sitsofe) wrote :

SATA disks appear with the /dev/s??? syntax because it was convinient to reuse some of the same SCSI machinery to present an interface to the disk to programs (see http://kerneltrap.org/node/5549 for details). It's not really emulation rather it's just naming. Rumour has it in a future kernel PATA devices will use this same libata interface that SATA disks use now and at that point they will turn into /dev/s??? nodes too.

Your particular SATA interface is VIA based so it would not be impacted by this 2.6.20-16 change (which I believe affects some unknown subset of Intel ICH[456] interfaces). Thanks for tending the forums - I do check by that thread from time to time but there's a lot to read so I only actively follow the links to posts that Lars suggests.

I would be interested to hear from ICH6 owners who have the same device renaming as Andrew and _especially_ interested to see the
lspci -vvv
lspci -vvvn
cat /proc/interupts (for 2.6.20-15)
cat /proc/interupts (for 2.6.20-16)
for Intel ICH[456] users who have IRQ problems that weren't present in 2.6.20-15.

mark_s (msabath) wrote :

I use a ASUS P4P800 latest BIOS (1021.006)
Ubuntu 7.04 I installed two weeks ago
With 2.6.20-15 all works fine with 2.6.20-16 the system stops. See attached screenshot.

Output under 2.6.20-15:

libata 125720 2 ata_piix,ata_generic
scsi_mod 142348 4 sg,sr_mod,sd_mod,libata

lspci -vvv:
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)

sda is IDE hdd
sdb and sdc are SATA drives

# /dev/sda4
UUID=2e377e54-c424-4774-84fe-1bf63a128ac1 / ext3 defaults,errors=remount-ro 0 1
# /dev/sdc1
UUID=351d0cc7-a1cc-4cd5-afb9-302dfe74bdc6 /home ext3 defaults 0 2
# /dev/sda1
UUID=120C57590C5736C7 /media/sda1 ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sdb1
UUID=EC6E92476E920A8A /media/sdb1 ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/sdb2
UUID=e2c5c385-a1d4-4351-b8ec-76ff73cba854 /sdb2 ext3 defaults 0 2
# /dev/sda3
UUID=7c24c035-4bad-4982-8c74-a4839d1a8a48 /tmp ext3 defaults 0 2
# /dev/sda2
UUID=669c199f-47dd-4177-a733-b0a19ef6e5dc none swap sw 0 0

the screenshoot says, that the system tries to resume from the swap Partition.
I don't know enough to comment this.

That problem may depend on what the root= is set to in your /boot/grub/menu.lst file...

mark_s (msabath) wrote :

Sitsofe Wheeler:
Here is are the entries of my menu.lst:

title Ubuntu, kernel 2.6.20-16-generic
root (hd0,3)
kernel /boot/vmlinuz-2.6.20-16-generic root=UUID=2e377e54-c424-4774-84fe-1bf63a128ac1 ro quiet splash locale=de_DE
initrd /boot/initrd.img-2.6.20-16-generic

title Ubuntu, kernel 2.6.20-15-generic
root (hd0,3)
kernel /boot/vmlinuz-2.6.20-15-generic root=UUID=2e377e54-c424-4774-84fe-1bf63a128ac1 ro quiet splash locale=de_DE
initrd /boot/initrd.img-2.6.20-15-generic

mark_s (msabath) wrote :

I forgot:
here is my /boot/grub/device.map

(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc

Sitsofe Wheeler (sitsofe) wrote :

OK scratch that idea. Does booting 2.6.20-16-generic with the irqpoll parameter make any difference?

could also try noresume

just noticed according to boot screen shot swap is on disk 3 partition 2

you have tmp on the 3rd partition and root on the fourth

this doesn't seem to match your grub ???

mark_s (msabath) wrote :

Thank you for the help

I changed

kernel /boot/vmlinuz-2.6.20-16-generic root=UUID=2e377e54-c424-4774-84fe-1bf63a128ac1 ro quiet splash locale=de_DE


kernel /boot/vmlinuz-2.6.20-16-generic root=UUID=2e377e54-c424-4774-84fe-1bf63a128ac1 ro quiet splash locale=de_DE irqpoll

and now the system boots "normal" (a bit slow)

my ide drive was under 2.6.20-15 sda and now it is hda

the sata drive sdb is now hde
the sata drieve sdc is now hdg

is it going to stay this way that sata drives are now hdX or will it be sdX again after the next update???

Why was it changed at all??

general workaround for the problem:
in my BIOS I can map SATA ports to the IDE ports, an I think this should work on other boards, too.
with this change , my system works fine with 2.6.20-16;

concerning performance, in a simple dd read test no difference can be seen.

anyway, this has other impacts:
1) you loose one IDE port and therefore two potential drive attachment slots;
2) I dual boot windows xp on this machine (shame on me), and I don't really want to face the troubles this could bear (means I didn't try too boot xp in this drive config)

concerning ubuntu stability, I have to stress that I'm very disappointed.
the 2.6.20-16 kernel update was shipped as a security update, if I remember right; under the hood changes of driver assignments to disk controllers came in -
who dares to change such fundamental things in a stable release?

Maybe we have a communication problem here and things weren't intentionally changed; in this case a little more verbosity from ubuntu kernel devs would be helpful.

Personally, considerung stability, I regret switching my desktop system from debian stable to ubuntu 7.04.
At the moment I feel I'd better switched to debian unstable....


thanks a lot, I did the same and now I can access my sata drive at under without irqpoll and with no performances loss. I love ubuntu, it makes me able to promote linux among my friends, I hope this serious bug fixed soon, this distribution has got a good reputation and it is a pity upsetting so many user. Thanks to all mantainers and volunteers

PS attached cat /proc/interrupts of the new config

Sitsofe Wheeler (sitsofe) wrote :

I just want to check something. Are the drives that are being renamed connected to the motherboard using PATA or SATA cables?

Interestingly your newest /proc/interrupts shows that the IDE controller is no longer sharing an interrupt with the USB controller...
On another note, could you clean up the description of this bug a bit?

Sitsofe Wheeler (sitsofe) wrote :

The "/proc/interrupts" part of the previous comment should have been aimed at mongo.

mongo (mongio) wrote :

Sitsofe Wheeler:

the sata drive pata emulated is connected to the motherboard using SATA cable

as mongo replied, you don't have to change cabling, unless the IDE port
you are mapping the SATA drive to already has a drive (cable) attached -
in this case you would have to remove it.

bug description: do you mean the headline or my first entry?
pls advise which part you'd like go get changed, no prob for me

I'm thinking the most of the stuff under the ----- can go. Mentionting ata_piix and piix and using lspci to find your IDE chipset may be useful though.

cleaned bug description,
moved the lines into here in case somebody is searching for the commands

in the debian bug record a simple verification can be found
1) find pci device codes for IDE and SATA controllers with
lspci -nn
part of the output on my machine:
00:1f.1 IDE interface [0101]: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller [8086:24db] (rev 02)
00:1f.2 IDE interface [0101]: Intel Corporation 82801EB (ICH5) SATA Controller [8086:24d1] (rev 02)

2) search for SATA device codes in modules.pcimap for both kernels:
on my machine:
kernel 2.6.20-16:
klaus@dagobert:/lib/modules/2.6.20-16-generic$ grep "24d1" modules.pcimap
piix 0x00008086 0x000024d1 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
ata_piix 0x00008086 0x000024d1 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0

kernel 2.6.20-15
klaus@dagobert:/lib/modules/2.6.20-15-generic$ grep "24d1" modules.pcimap
ata_piix 0x00008086 0x000024d1 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0

description: updated


didnt think of that with my ICH6

lspci -nn

00:1f.1 IDE interface [0101]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller [8086:266f] (rev 03)

root@sidney:/lib/modules/2.6.20-15-generic# grep "266f" modules.pcimap
ata_piix 0x00008086 0x0000266f 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0

root@sidney:/lib/modules/2.6.20-16-generic# grep "266f" modules.pcimap
piix 0x00008086 0x0000266f 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0

So that pretty much confirms that there are some ICH6 affected to.

klmonz (klaus-monz) wrote :


you picked the wrong controller to confirm this bug - this is the same
with my ICH5 when i grep for the IDE controller id (in 2.6.20-15
ata_piix is claiming the IDE controller, but in 2.6.20-16 piix is doing);

you have to look for the line in "lspci -nn" output with the string
"SATA controller"
with the id statet there, it would be interesting to see your
modules.pcimap differences both kernels.

if with 2.6.20-16, the id gets claimed by BOTH sata_piix and piix, the
situation is as described in this bug.
if not, it would confirm that your ICH6 controller is not affected.

klmonz :

My laptop has a distinct lack of Sata drives .

My point was the Great rename bug is the same for my Pata controler...

under kernel 15 my IDE was controlled via ata_piix and therefore /dev/sdxx

under kernel 16 my IDE is controlled via piix and therefore /dev/hdxx

Yet Sitsofe who also tested a ICH6 chipset MB didn't get drive renaming..so I assume his modules.pcimap output would still show ata_piix assigned for his chipset id.

I agree that for me its not such an issue my Pata drive is still working fine yet for Ubuntu's supposed target audience .. their screwed.

my response was to the original title of your bug '(ata_piix disabled for ich4/5), where we had some discussion whether ICH6 variants were also afflicted.

I don't want to be in the situation where everyone is switched back except me ;-)

klmonz :

I just realized you still think this is related to the debian Bug.

This is incorrect

A subset if Intel core host controllers was deliberately switched over by the kernel devs in an attempt to fix some CD rom issues , in the process hanging everone else out to dry.

there is some discussion going on why this was done under the pretext of a security fix. https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116996/comments/44

klmonz (klaus-monz) wrote :


Your argument is correct, though I read comment 44, I didn't take it too
serious, I have to admit.
And I didn't take too much care (if any) about bug #117314 since it
describes the same situation.

In a previous comment I complained about too little verbosity of ubuntu
kernel devs;
apparently, they gave a comment in #117314 (Philip Lougher).

I can understand that kernel devs are too busy to comment every bug
record, but I did expect they would comment on the first report filed on
a particular bug, and not onto a later one (which I do regard as being
at least interesting);

Anyway, that's the story why I didn't get the information that switching
from ata_piix to piix was done intentionally.
However, I asked about this expicitly in comment 32 and again in comment
65 of my own report (#116996), but nobody answered.

I will correct my bug description and add a link to 117314 in the
description, but only later since I have no time at the moment.

thank you for bringing me up to date :)

I have an ICH5 chip and my hard drives run off SATA and DVD+RWs on IDE

I could not boot with 2.6.20-16 (the kernel would hang on the first step [find boot media or something])

After adding the irqpoll option to the kernel and disabling SATA to IDE emulation in BIOS (ie enabling SATA RAID but not actually RAIDing the drives) my system boots.

I use UUIDs for the hard drives and the system will boot with the drives as sdax and sdbx with the ata_piix driver.

I believe the problem is to do with the BIOS emulating the SATA controller as IDE 3 and 4, and possibly the order in which the kernel polls for devices.

I hope this helps.

Sitsofe Wheeler (sitsofe) wrote :

Thanks for your diligent clarification.

I've taken the pcimap investigation a bit further and drawn up a list of IDE controller ID differences between -15 and -16 pcimap:

Switched from ata_piix to piix
2411 Intel 82801AA IDE
2421 Intel 82801AB IDE
244a 82801BAM IDE U100
244b 82801BA IDE U100
248a 82801CAM IDE U100
248b 82801CA Ultra ATA Storage Controller
24ca 82801DBM (ICH4-M) IDE Controller
24cb 82801DB (ICH4) IDE Controller
24db 82801EB/ER (ICH5/ICH5R) IDE Controller
245b 82801E IDE U100
25a2 6300ESB PATA Storage Controller
266f 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller
27df 82801G (ICH7 Family) IDE Controller
269e 631xESB/632xESB IDE Controller

New piix IDs:
24c1 82801DBL (ICH4-L) IDE Controller
24d1 82801EB (ICH5) SATA Controller
2850 Mobile IDE Controller

NOTE: There's an ICH7 and some ICH3 (although they are not called ICH3 in lspci) chipsets affected! This explains bugs like Bug #117876 .

I do think phsyco_ant may be on to something. The BIOS often lets these chipsets offer various IDE emulation modes where you can select between AHCI/PATA/SATA operation. It could be the controller ID changes depending on which one these is selected further complicating matters.

Could you clean up that description a bit more?

klmonz (klaus-monz) on 2007-06-07
description: updated
mongo (mongio) wrote :

Sitsofe Wheeler:

Asus MB P4P800-X with chipset Intel 865PE, Intel ICH5

ALL IS WORKING FINE and back to normality AFTER THE LATEST KERNEL IMAGE UPDATE, device naming OK, no need of irqpoll, no need to use compatible mode :

# Linux kernel version: 2.6.20-16-generic
# Thu Jun 7 18:16:52 2007
CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.20-16.29-generic"

BELOW THE cat /proc/interrupts

  0: 1263067 0 IO-APIC-edge timer
  1: 2 0 IO-APIC-edge i8042
  6: 5 0 IO-APIC-edge floppy
  8: 3 0 IO-APIC-edge rtc
  9: 1 0 IO-APIC-fasteoi acpi
 12: 4 0 IO-APIC-edge i8042
 14: 0 0 IO-APIC-edge libata
 15: 110434 0 IO-APIC-edge libata
 16: 0 0 IO-APIC-fasteoi eth1
 17: 440852 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb4, nvidia
 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
 19: 78783 0 IO-APIC-fasteoi uhci_hcd:usb3, libata
 20: 36 0 IO-APIC-fasteoi ehci_hcd:usb5
 21: 587 0 IO-APIC-fasteoi Intel ICH5
NMI: 0 0
LOC: 1262916 1262959
ERR: 0
MIS: 0

Thanks to everybody

mongo (mongio) wrote :

Sitsofe Wheeler:

Asus MB P4P800-X with chipset Intel 865PE, Intel ICH5

I cannot detect any problem, but into dmesg I've found the following line:
   12.393335] scsi2 : ata_piix
[ 12.556584] ATA: abnormal status 0x7F on port 0x0001eff7

I've attached dmesg output


I too have been fighting through my primary system upgrade which involves
 ICH, big SATA, >32GB NTFS. I evaluated and gave up on:
  o Gentoo/portage
  o FC4,6/yum (bad DVD from ...)
have selected Ubuntu 7.04 / apt-get, which does works great on my x86-64 laptop.

Ubuntu was booting until I tried to move to a new kernel (mainly to evaluate VMware
or win4lin or wine ) since win2k won't boot from /dev/sda2). Booting from my old
system on /dev/hda I can see the NTFS contents on either linux or win2k. The only
windows app I care about anymore is Quicken & TurboTax.

linux- doesn't work either after a few reboots, make menuconfig to get
a libata.ko module installed.

How/where can I get apt-get to roll back to 2.6.20-15-generic ?
(I do have the orginal grub selection but no kernel source) or
where can I ftp the linux-source-2.6.20-15-generic ?

Would be really nice to have a bunch of working .config.ECS848P-version & files
for other tested MBs around for download....the /boot/config.orginal files, with most
all the modules turned on takes forever to build


When will it be "safe" to turn on the NTFS WRITE module in an image release?

Sitsofe Wheeler (sitsofe) wrote :

The NTFS safety question is completely unrelated to this bug report. Your best bet is to ask the NTFS developers ( http://www.linux-ntfs.org/ ) directly and indicate tell them which drivers you are asking about.

Your earlier comment touches more than one issue so I'm not going to try and answer it. You may find it useful to use one of the other support methods described on http://www.ubuntu.com/support/communitysupport ...

Rob Watson (r-watson) wrote :

I see there has been no progress on this, apparently, since June. Brilliant.

With the imminent release of Gutsy Gibbon, perhaps it doesn't matter.

Can anyone confirm whether this bug will also be present in Gutsy's kernel, or has it been fixed there?

Alfredo Matas (amatas) wrote :

Fixed for me in Feisty and Gutsy Beta.


Nick B (nick-b) wrote :


I've had my eye on this thread for a while. Can't decide whether my [very annoying, and varied] problem is the same.

I have an 64 bit version of Ubuntu Feisty with 2.6.20-16 (previously), IIRC on a self-made desktop machine with a Core2 duo, and recent nvidia graphcis card. It has three SATA disks, cos I had such a nightmare getting a RAID-1 array to be bootable on SATA (strange UDEV problems, I decided) that I gave up and boot off an older SATA disk.

I also got / am getting IRQ #16 disabled problems, randomly - sometimes after 10mins, sometimes 2 hours. A kernel message would appear, then pretty much everything would die, although some non-network processes could live (eg mpd)

But because of the strange problems I upgraded to Gutsy kernel hoping that would sort this out (it did, a tiny bit), now giving me a system based on:

Linux 2.6.22-14-generic #1 SMP Wed Oct 10 05:28:36 GMT 2007 x86_64 GNU/Linux

The symptoms have changed with this kernel - now the machine lives on after the IRQ dies, but is very VERY slow over network (a LAN ping takes about 200-900ms!) presumably because eth0 is, well I don't know really. Furthermore, the DVD-drive goes mad, light flashing and some weird messages in dmesg (see attached).

Also, about one in three boots fail with /dev/md0 failing to mount and emergency shells and so on. Normally another reboot will magically fix this but not always

Any ideas? I'm no linux expert, and this is driving me mad. The prospect of using it as even a home server is ruined by all this.. Many thanks in advance..

Hi everyone,

This bug was opened a while ago but there hasn't been any recent activity. We're just curious if this is still an issue with the the Hardy Heron 8.04 Alpha series which is currently under development and contains an updated version of the kernel. It would be helpful if you could test the latest Hardy Alpha release: http://www.ubuntu.com/testing . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. Thanks.

Changed in linux-source-2.6.20:
status: In Progress → Incomplete


just downloaded HH 8.04 alpha 6 and booted my machine from LiveCD (ICH5, gigabyte ga-8i848p-g level F5 as described above), actually running it when typing this.

Issue resolved on my ICH5 machine.

Thank you all.

Hi klmonz,

Thanks for testing and the update. I'm glad to hear things are working for you. Since you are the original bug reporter I'm going to go ahead and mark this "Fix Released" against the Hardy kernel. Against 2.6.20 this will be closed. For anyone else still experiencing issues against the latest Hardy release, please open a new bug report. Thanks.

Changed in linux:
status: New → Fix Released
Changed in linux-source-2.6.20:
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers