Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 249469
Summary: | [msi, mmconf] Kernel 2.6.22.1-27.fc7 sata drive fails to mount | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stefan Orbilt <stefan> | ||||||||||||
Component: | kernel | Assignee: | Jeff Garzik <jgarzik> | ||||||||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
Severity: | high | Docs Contact: | |||||||||||||
Priority: | low | ||||||||||||||
Version: | 8 | CC: | blomgren.peter, cebbert, chris.brown, davej, ikent, peterm, poelstra, stuart | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | i686 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2009-01-09 04:49:00 UTC | Type: | --- | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Bug Depends On: | |||||||||||||||
Bug Blocks: | 172490 | ||||||||||||||
Attachments: |
|
Description
Stefan Orbilt
2007-07-24 20:51:56 UTC
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. |