Bug 249469

Correction, here's what happens when I try to mount the disk:

# mount /mnt/F
Failed to access '/dev/sdc1': The file or directory does not exist

This works when rebooting with the old kernel.

Kernel 2.6.22.1-33.fc7 unfortunately did not fix the problem.

Sorry, kernel 2.6.22.1-41.fc7 didn't do it either. Could you please try one more
time? :)

I have almost the same problem here. I have motherboard ASUS M2N-X and a SANSUNG
HD160HJ SATA II HD. This combination works pretty fine with 2.6.21-1.3228.fc7
kernel version when the IDE configuration on BIOS is SATA mode or AHCI mode.
With newer versions during boot I see the following messages if BIOS setting is
AHCI mode:
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
and it tries to limit link speed to 1.5Gbps and after to UDMA7 as reported for
Ian Kent (Bug 249383). As I have only this HD on my system the sad end is a
kernel panic since no partition can be found and mounted. However, it works fine
in SATA mode. I'm using the last BIOS version for this motherboard (0701). I
can't attach dmesg with this problem and the photos Ian Kent has posted could be
mine, except my problem is on ata1. But I'm attaching lspci and lsmod. I'm not
sure if another problem I have noted in kernels newer than 2.6.21-1.3228.fc7 is
related to the SATA one but I think it worths to be reported here. It's more
easy to see if on grub you use the "quiet" parameter:
PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
PCI: Not using MMCONFIG.
I can workaround this problem with "pci-nommconf" parameter but I'm not so sure
it is so harmless as I have read elsewhere on Internet.

Created attachment 160491 [details]
lspci -vv

Created attachment 160492 [details]
lsmod

I have just found the following on Google and I think it can be useful
(http://www.gossamer-threads.com/lists/linux/kernel/801552):
Re: IRQ Delivery Problem for MCP65 Remove Highlighting  [In reply to]
--- Bartlomiej Zolnierkiewicz <bzolnier[at]gmail.com> wrote:

> > --- Craig Block <chblock3[at]yahoo.com> wrote:

> > I'm having trouble getting Linux to see any hard drives on an ASUS M2N-X
> > motherboard with an MCP65 (nForce 520) chipset. When the kernel probes the
> > AHCI controllers, it hangs for a minute or so on each one and returns the
> > following;
> >
> > ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
>
> I googled for some more info about similar issues and found very similar
> problem being discussed on Gentoo forum:
>
> The important part is here:
>
> "when I disabled Message Signaled Interrupts (MSI and MSI-X) under "Bus
> Options" in the kernel, the problem magically went away (disabling MSI)"
>
> which indicates IRQ routing problems (as suspected from dmesg output and also
> stated by Tejun). Have you already tried disabling MSI IRQs with "pci=nomsi"
> (not "nomsi") or even completely disabling CONFIG_PCI_MSI support?

Thanks a ton, building the kernel with PCI_MSI not set did the trick.
Attempting to disable MSI using pci=nomsi at the boot prompt did not eliminate
the problem. I had to build the kernel without MSI support. There's a few
interesting differences in the dmesg output with "PCI_MSI=y" and PCI_MSI not
set;

With PCI_MSI not set;

ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x00000000 bmdma 0x00000000 irq 5
ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x00000000 bmdma 0x00000000 irq 5
ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x00000000 bmdma 0x00000000 irq 5
ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x00000000 bmdma 0x00000000 irq 5

With PCI_MSI=y;

ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x00000000 bmdma 0x00000000 irq 219
ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x00000000 bmdma 0x00000000 irq 219
ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x00000000 bmdma 0x00000000 irq 219
ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x00000000 bmdma 0x00000000 irq 219

Also, there's a spurous interrupt message that appears with PCI_MSI=y;

spurious 8259A interrupt: IRQ7.

I attached the two dmesg instances for reference.

- Craig 

(In reply to comment #7)
> With PCI_MSI=y;
> 
> ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x00000000 bmdma 0x00000000 irq 219
> ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x00000000 bmdma 0x00000000 irq 219
> ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x00000000 bmdma 0x00000000 irq 219
> ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x00000000 bmdma 0x00000000 irq 219

And with "pci=nomsi it's the same, right?)

Hi Chuck. I'm a bit ashamed because since the reference said it did not work I
have not tried. But... I should!
Well, at least for me, good news. It just works pretty fine now. I'm using both
pci=nomsi and pci=nommconf parameters and answering your question using the
newest x86_64 kernel version, that is, 2.6.22.1-41.fc7 with no more problems.
Thanks! I hope this parameter can also help the other guys. I have some doubts:
Are these issues kernel bugs or a BIOS bugs just exposed by the new kernel version?
I have noted no performance and stability penalties on my system up to now after
adding those pci parameters. Are they harmless?
I will create an attachment with my current dmesg output, just in case it could
be useful for you.

Created attachment 160572 [details]
dmesg

pci=nomsi is safe, very few systems need it, mainly 10 gigabit ethernet and
infiniband machines. And it was already disabling mmconfig because the
config region wasn't reserved.

Looks like we need to start doing quirks for broken msi.

Hi guys, sorry I haven't been able to reply before. I was in the USA last week
but now I've finally been able to try your suggestions. So I found out that what
I had to do was to edit my /boot/grub/menu.lst file and add "pci=nomsi" and
"pci=nommconf" in the end of the "kernel" line.

So I first tried just using the first setting, then both settings and last I
tried just using the last setting. None of that helped at all unfortunately.
I'll attach a photo of the boot up screen to make it clear.

So now I had to go back to kernel 2.6.21-1.3228 again. I really hope I won't be
stuck with it forever...

Created attachment 161292 [details]
Photo of my boot up screen

Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel? If you are, I will
re-assign this bug to the relevant maintainer who may be able to shed more light
on the issue.

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris

Hi Christopher,

Thanks for your reply! Yes I am still having problems. I have tried every new 
kernel that came as a package through yum update since after 2.6.21-1.3228.fc7 
and neither of them have worked with my 3rd harddrive. Only 2.6.21-1.3228.fc7 
(and earlier) works so that's what I've kept using.

Please let me know if you have any suggestions!

(In reply to comment #15)
> Hi Christopher,
> 
> Thanks for your reply! Yes I am still having problems. I have tried every new 
> kernel that came as a package through yum update since after 2.6.21-1.3228.fc7 
> and neither of them have worked with my 3rd harddrive. Only 2.6.21-1.3228.fc7 
> (and earlier) works so that's what I've kept using.
> 
> Please let me know if you have any suggestions!
> 

Can you try the Fedora 8 Test 2 live CD and see if that works? That would let us
know if this is fixed in the upcoming 2.6.23 kernel.

I've added the SATA blocker bug as per the wiki triage instructions and
re-assigned to the relevant maintainer. If this is still an issue with the
latest live cd then I'll add the kernel blocker bug.

Stefan, you can get F8 T2 live cd from:

http://mirrors.fedoraproject.org/publiclist/Fedora/7.91/

Cheers
Chris

Hi Christopher,
As I said before my problems were solved by adding "pci=nomsi" parameter on
GRUB. But I have tried to remove the parameter on every kernel release with no
success. That is the problem seems to remain but is "fixed" by the parameter.
The same is true to "pci=nommconf" parameter. I will try to download F8 T2 and
test it.

Hi all, I have just downloaded F8 T2 (x86_64) and I have got the same results.
As I have just one HD my system only boots with "pci=nomsi" appended to kernel
line on GRUB. As before, "pci=nommconf" is not required to boot but it avoids a
boring message about a bug:
PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
PCI: Not using MMCONFIG 
I guess a feature was enabled on recent kernels (original F7 was OK) that
unmasked a problem with my motherboard. Just to remember I am using an ASUS
M2N-X with the latest BIOS version with an AMD Athlon X2 4200+, 2 GB 667 memory
and a Samsung HD160HJ as hard disk. On BIOS setup AHCI mode is enabled for SATA.

Heya,

Well I'm sorry to hear Marcos is still having problems but I am happy to report 
that the Fedora 8 Test 2 Live CD (32-bit) worked for me! So it seems the 
problem I had have been fixed in kernel 2.6.23-0.164.rc5-fc8!

One other note. It seems my SATA problem is connected to my 400 GB Hitachi 
Deskstar 7K400 SATA harddrive:

http://www.hitachigst.com/hdd/support/7k400/7k400.htm

That's what I had on SATA port 3 that I got the errors on. When I moved it to 
port 2 the problem moved to port 2 with it while another harddrive worked fine 
on port 3. I also put it on port 4 and the problem moved with it to that port. 
I tried using another SATA cable but it didn't help.
Well anyway I am looking forward to the final release of Fedora 8 now :)

Hi all,
Well, I guess my problem and Stefan's one have similar symptoms but different
causes. My problem is corrected with pci=nomsi parameter and Stefan's isn't. On
the other side Kernel 2.6.23 works for him but not to me. As he has said he used
the 32-bit version, I decided to download F8 T2 32-bit and try again.
No changes. My system works very well with that blessed parameter but just with
that one. I'm curious: who is the culprit:my BIOS, Kernel 2.6.22 and above or
the interaction between each other? 

I would(In reply to comment #21)
> Hi all,
> Well, I guess my problem and Stefan's one have similar symptoms but different
> causes. My problem is corrected with pci=nomsi parameter and Stefan's isn't. On
> the other side Kernel 2.6.23 works for him but not to me. As he has said he used
> the 32-bit version, I decided to download F8 T2 32-bit and try again.
> No changes. My system works very well with that blessed parameter but just with
> that one. I'm curious: who is the culprit:my BIOS, Kernel 2.6.22 and above or
> the interaction between each other? 

I'm no expert but I would say that your board is telling fibs - its reporting
itself as MSI-capable but in fact is not matching the spec or not handling the
interrupts correctly. Which is why turning it off works for you. Maybe.

I'm seeing the same/a similar problem; everything works fine with
kernel-2.6.21-1.3194.fc7, but all the 2.6.22 (up to and including
kernel-2.6.22.7-85.fc7) have "issues" finding my second SATA drive (which holds
my Fedora installation...)

booting 2.6.22.7-85.fc7
with quiet, pci=nomsi,nommconf
   > ata1.00: failed to set xfermode (err_mask=0x40)
   > ata1:    COMRESET failed (errnot=-16)
   > [repeat ad nauseum]

with quiet pci=nomsi,nommconf nohz=off
   > ata1.00: failed to set xfermode (err_mask=0x40)
   > ata1:    COMRESET failed (errnot=-16)
   > [repeat ad nauseum]

with quiet, pci=nomsi,nommconf,noacpi
   > pci 0000:00:01.0 Error Creating sysfsbridge symlink, continuing...
   > pci 0000:00:1c.0 Error Creating sysfsbridge symlink, continuing...
   > pci 0000:00:1c.1 Error Creating sysfsbridge symlink, continuing...

and $ /sbin/lsmod | egrep -i ata
ata_piix               18757  0 
libata                115417  2 ata_piix,ahci
scsi_mod              137549  4 sr_mod,sg,libata,sd_mod

   > pci 0000:00:1e.0 Error Creating sysfsbridge symlink, continuing...
   [...]

Under 2.6.21-1.3194.fc7, I have:
00:01.0 PCI bridge: Intel Corporation 82925X/XE PCI Express Root Port (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 2 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)

Please let me know what additional information I can provide to help fix this bug...

Sorry... cut-and-paste-error in comment #23... should read:

[...]
with quiet, pci=nomsi,nommconf,noacpi
   > pci 0000:00:01.0 Error Creating sysfsbridge symlink, continuing...
   > pci 0000:00:1c.0 Error Creating sysfsbridge symlink, continuing...
   > pci 0000:00:1c.1 Error Creating sysfsbridge symlink, continuing...
   > pci 0000:00:1e.0 Error Creating sysfsbridge symlink, continuing...
   [...]

Under 2.6.21-1.3194.fc7, I have:
00:01.0 PCI bridge: Intel Corporation 82925X/XE PCI Express Root Port (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation
82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 00:1e.0 PCI
bridge: Intel Corporation 82801 PCI Bridge (rev d3)

and $ /sbin/lsmod | egrep -i ata
ata_piix               18757  0 
libata                115417  2 ata_piix,ahci
scsi_mod              137549  4 sr_mod,sg,libata,sd_mod

[...]

Hi Peter,

You seem to have the same problem like me indeed! You can check if the Fedora 8 
Test 2 Live CD works for you too. In that case I guess we both have to wait for 
Fedora 8.
I get the exact same output from your lsmod command like you do. What 
motherboard do you have? I have an Asus P5GD1. Also I'm curious, what's your 
harddrive model and size?

(In reply to comment #25)

Hi Stefan,

> [...] You can check if the Fedora 8 Test 2 Live CD works for you too.

I'll give it a shot (next week)...

> What motherboard do you have?

Not sure (it's a Dell, so whatever they put in there...), I'll have to open up
the box (next week).

> Also I'm curious, what's your harddrive model and size?

ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133
ata3.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133

which is the same "400 GB Hitachi Deskstar 7K400 SATA harddrive" you have
(comment #20).  Coincidence?

Hi Peter,

Coincidence I think not! I Googled for "HDS724040KLSA80 linux" and I was pretty 
soon hyperlinked away to a parallel universe to ours, called the Mandriva 
Bugzilla!

http://qa.mandriva.com/show_bug.cgi?id=32076

Our exact same problem is logged there and apparently it's solved in their 
kernel 2.6.22.9-desktop-1mdv. I yum updated to the kernel 2.6.22.9-91.fc7 today 
but unfortunately the problem is still the same there. Aren't those two kernels 
equivalent? Or did they implement a custom patch that we didn't get yet? They 
talk about a BROKEN_HPA patch in that other bugzilla... Maybe Chuck or 
Christopher knows anything about that?

Hi folks,
I think the following patch:

DB33_libata_broken_hpa_horkage.patch

is what is under discussion and may resolve your issue. Part of that patch adds
the following devices which have HPA issues:

+	/* devices which puke on READ_NATIVE_MAX */
+	{ "HDS724040KLSA80",	"KFAOA20N",	ATA_HORKAGE_BROKEN_HPA, },
+	{ "WDC WD3200JD-00KLB0", "WD-WCAMR1130137", ATA_HORKAGE_BROKEN_HPA },
+	{ "WDC WD2500JD-00HBB0", "WD-WMAL71490727", ATA_HORKAGE_BROKEN_HPA },
+	{ "MAXTOR 6L080L4",	"A93.0500",	ATA_HORKAGE_BROKEN_HPA },

I've kicked off a build in Koji with this patch in. Please could you test and
post back with comments.

http://koji.fedoraproject.org/koji/taskinfo?taskID=178762

Cheers
Chris

Created attachment 211481 [details]
HPA patch from mandriva cooker kernel

http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=16c55b038033d8f6f7601996dfae44399666d9ab

Hi Chris,

Thanks for going through the trouble of doing this but unfortunately it did't 
help, I still get the same error message. Well actually on the first reboot I 
got "Buffer I/O error on device sdc, logical block 0" but it was the same with 
the ordinary 2.6.22.9-91.fc7 and on second reboot it was also back to "failed 
to set xfermode" and "COMRESET failed".

I guess I'll have to wait for Fedora 8...

(In reply to comment #29)
> Created an attachment (id=211481) [edit]
> HPA patch from mandriva cooker kernel
> 
>
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=16c55b038033d8f6f7601996dfae44399666d9ab

This [kernel-2.6.22.9-91.bz249469.fc7] did not work for me...  It seemed like
the boot sequence did (maybe, possibly) recognize the drive, but still got hung
up on something, with no useful messages.  It may be that the
ATA_HORKAGE_BROKEN_HPA patch is part of a larger patch-set, and the whole
package is needed to make it fly?  (Just guessing here).

On a brighter note, from Fedora-Live-7.91 I *am* able to mount the drive...

Hi Chris,
Thanks for your dedication but your patch haven't changed anything for me too. I
keep having to use pci-nomsi in order to boot.

Marcos - Okay, thanks for testing anyway folks.

Peter - yes you might be right. Worth a shot anyway. Good to know 7.91 works.

Whilst waiting for F8 Test 3 to arrive, an interim live cd build is available at:

http://torrent.fedoraproject.org/torrents//rawhide-i386-Live-20070925.torrent

which you might want to try.

Just in case anyone is keeping score... kernel-2.6.23.1-10.fc7 did not fix the
problem for me.

It didn't fix the problem for me either. I thought it did because when I 
installed it and rebooted to it then it worked (tried once). But when I cold 
start my computer it doesn't work (tried 4 times).
The countdown to Fedora 8 has begun. I hope it will work from cold start or I 
will have to start looking at Mandriva.

Great news, I installed kernel 2.6.23.1-21.fc7 yesterday and it works!! It
really works!! I can cold start my computer and there is zero problem with my
harddrive, amazing! Chuck must have done something to fix it so thanks a lot
Chuck!! You are my hero.

I am downloading Fedora 8 as we speak. I'll let you know if that works too or not.
Peter you should let us know if it works for you as well.

(In reply to comment #36)

No love here.  I have two of the offending ("HDS724040KLSA80") drives, and F7 is
on the second one; from a quick glance at the boot messages, it seems like the
first drive got picked up, but the second one not.

Oh noes!! Today I installed Fedora 8 and unfortunately the harddrive problem
appears again with the supplied 2.6.23.1-42.fc8! I just updated to
2.6.23.1-49.fc8 now as well and that one is broken too :(
Please help me Obi-Chuck Ebbert, you are my only hope. And Peter's too I expect.

I tried F8 live cd and F8 installer dvd, and on both I get the error after
uncompressing Linux...
ata3: COMRESET failed (errno=768)

My hardware:
Mother Asus p4s800d-x
Intel Pentium 4 3.0Ghz
Memory 1024MB
AMIBIOS 08.00.09  10/20/04
Hard Disk: serial ata 111 GB
DVD-RW ide

It's curious, because F8 dvd and F8 live works fine with my other cheap computers.

With F7 live cd, it starts until automount and then an error ata1: failed to
recover some devices...
If I start F7 live cd from RAM, it starts with no problem but I have no mouse or
keyboard, so the only thing left to do is press the reset button.

One more comment.
On F7 live cd, after starting and running in RAM, I found that I can plug an usb
mouse and shutdown the system with it. 
I suppose that if I plug an usb keyboard, it will work too.
But I need it to work with the dvd and hard disk.

(In reply to comment #39)
> 
> My hardware:
> Mother Asus p4s800d-x
> Intel Pentium 4 3.0Ghz
> Memory 1024MB
> AMIBIOS 08.00.09  10/20/04
> Hard Disk: serial ata 111 GB
> DVD-RW ide
> 

This is a bug in the SiS SATA driver. Will be fixed in the next F8 kernel (after
2.6.23.1-49)

Hi all, for me pci=nommconf is no more necessary after upgrading to F8. I'm not
sure if that's true for the stock version but 2.6.23.1-49 is OK. I have tried
with others motherboards from ASUS including M2N-MX, M2N-E, M2NPV-VM (mine is
M2N-X) and they don't need pci=nomsi. The problem seems related to NVIDIA®
nForce™ 520™ MCP. I upgraded my bios from 0701 to 0806. It's beta but until now
seems very stable. Unfortunately it does not fix the problem. I will report
again after final  bios version 

Marcos so you are saying that F8 fixed the problem but you are hoping that a 
newer bios will fix the problem with all other versions then? Well it's good to 
hear your problem seems to be solved.

Kernel 2.6.23.1-49.fc8 is still broken for me with my harddrive but I've 
noticed that very sporadically it works. If it happens to work it seems that I 
first get the "failed to set xfermode" error two times and then it succeeds. 
But mostly it fails. Rebooting over and over again doesn't seem to help it 
succeed, it's all random.

Sorry, I was not as clear as I intended: pci=mmconf is no more needed but
pci=nomsi is. I have listed the other motherboards just to show that my problem
is restricted to NVIDIA® nForce™ 520™ MCP, since all of them are manufaturated
by ASUS with NVIDIA chipsets for AMD processors and work fine with their
respective nForce versions with F7 and F8.

Just in case someone is keeping score: the problem persists for me up to and
including kernel 2.6.23.15-80.fc7...  I'm "somewhat" nervous about upgrading to
F8 since I'm not sure the system would boot...

(In reply to comment #45)
> Just in case someone is keeping score: the problem persists for me up to and
> including kernel 2.6.23.15-80.fc7...  I'm "somewhat" nervous about upgrading to
> F8 since I'm not sure the system would boot...

Yes, I did an install of F8 and still had to add the "pci=nomsi"
to get the install to work.

I've had some disk corruption as well but I'm not sure it's
related.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Well, I have just installed Fedora 9 and "pci=nomsi" is no more necessary. Now
Fedora 9 sees my SATA HD as expected. I'm sure that's not the correct place to
talk about Fedora 9. But perhaps this little bit is useful. After a clean boot,
Fedora 9 reports there is a kernel problem and offers to notify kernel
developers. Due to this message, I checked dmesg and found this:
------------[ cut here ]------------
WARNING: at drivers/ata/ahci.c:645 ahci_enable_ahci+0x2b/0x2d [ahci]() (Not tainted)
Modules linked in: ahci(+) libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd
ohci_hcd ehci_hcd
Pid: 451, comm: modprobe Not tainted 2.6.25.3-18.fc9.x86_64 #1

Call Trace:
 [<ffffffff81034665>] warn_on_slowpath+0x60/0x91
 [<ffffffff81201011>] ? pci_conf1_read+0xbb/0xc9
 [<ffffffff8120231e>] ? raw_pci_read+0x1a/0x32
 [<ffffffff811adfdf>] ? devres_find+0x8a/0xa7
 [<ffffffff81135028>] ? pcim_iomap_release+0x0/0x3a
 [<ffffffff880a7506>] :ahci:ahci_enable_ahci+0x2b/0x2d
 [<ffffffff880a8686>] :ahci:ahci_init_one+0x18a/0x930
 [<ffffffff810ee84c>] ? sysfs_addrm_finish+0x20/0x205
 [<ffffffff810ee3ce>] ? sysfs_find_dirent+0x1c/0x31
 [<ffffffff8112cb9f>] ? ida_get_new_above+0xf4/0x1a5
 [<ffffffff810ee1f0>] ? sysfs_ilookup_test+0x0/0x14
 [<ffffffff8102afb5>] ? task_rq_lock+0x3d/0x73
 [<ffffffff8113d599>] pci_device_probe+0xc7/0x11e
 [<ffffffff811aba99>] driver_probe_device+0xc0/0x16e
 [<ffffffff811abbda>] __driver_attach+0x93/0xd3
 [<ffffffff811abb47>] ? __driver_attach+0x0/0xd3
 [<ffffffff811ab2b6>] bus_for_each_dev+0x4f/0x89
 [<ffffffff8112d476>] ? kobject_get+0x1a/0x22
 [<ffffffff811ab8e4>] driver_attach+0x1c/0x1e
 [<ffffffff811aab2d>] bus_add_driver+0xb7/0x200
 [<ffffffff811abda3>] driver_register+0x5e/0xde
 [<ffffffff8113d810>] __pci_register_driver+0x53/0x8b
 [<ffffffff880b101e>] :ahci:ahci_init+0x1e/0x20
 [<ffffffff81057747>] sys_init_module+0x193f/0x1a87
 [<ffffffff810a4db8>] ? do_sync_read+0xe7/0x12d
 [<ffffffff810a57fd>] ? vfs_read+0xab/0x154
 [<ffffffff8100bedb>] system_call_after_swapgs+0x7b/0x80

---[ end trace 61a475b3a53e5918 ]---
Up too now it looks just an information since my computer seems to work with no
problem. Using "pci=nomsi" makes no difference.

This new kernel version ( 2.6.25.9-76.fc9.x86_64) cleaned up the trace I
reported above.

based on comment #49 it appears this bug is fixed.  Okay to close?

OKTOCLOSE -- Since I upgraded to F9 (from F7), and changed a BIOS setting(*) my
problem, with the HDS724040KLSA80-KFAOA20N drives, is gone.

(*) From some auto-detect RAID mode to PATA/SATA combo mode, if memory serves;
if someone really cares about the details I can reboot and check next time I'm
in the same room as that machine...

I am still running Fedora 8 and it still works very randomly.
Peter does that mean the disks are now running in IDE mode? That wouldn´t mean
the bug is fixed...
I´ll let you know how it works when I get to install Fedora 9.

Stefan, this is from dmesg:

ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133
ata1.00: 781422768 sectors, multi 8: LBA48 
ata1.00: configured for UDMA/133

I'll go in an reboot later today and look at the BIOS details (and see what
other modes boot / don't boot).

That looks like IDE mode to me but I´m not sure?
Yes it would be cool if you could check what works :)
Thanks!

OK, I've rebooted with the latest and greatest kernel (2.6.25.9-76.fc9.i686)

There are 4 BIOS modes

(1) RAID Autodetect / AHCI
(2) RAID Autodetect / ATA
(3) RAID on
(4) SATA/PATA Combination

It's a non-raid system, and (1) and (2) give:
Hand-copied off the screen (some lines missing, especially repeated ones...)
  qc timeout (cmd 0xef)
  failed to set xfermode (err_mask=0x4)
  failed to recover some devices, retrying in 5 secs
  SATA link up 1.5Gbps SStatus 113 SControl 300
  COMRESET Failed (errno=-16)
  limiting SATA link speed to 1.5Gbps
  limiting SATA link speed to UDMA/133:PIO3
  (SStatus 113 SControl 310)
  ...
  ...
  Booting has failed.

Hand-copied off the screen (some lines missing, especially repeated ones...)

(3) N/A

(4) Works:
ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133
ata1.00: 781422768 sectors, multi 8: LBA48 
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      HDS724040KLSA80  KFAO PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 781422768 512-byte hardware sectors (400088 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
sd 0:0:0:0: [sda] 781422768 512-byte hardware sectors (400088 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO
or FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk

I'm sure this makes sense to someone?

Thanks Peter that´s interesting. Unfortunately I only have two BIOS options:
AHCI and IDE mode. I don´t want to run all my harddrives in legacy IDE mode, all
of them should work properly in SATA mode like under another operating system
from Redmond. I think the bug should remain open.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.