Description of problem: Fedora 8 will not install or boot if HPT 366 UDMA 66 controller enabled. It fails to load the driver during install and hangs at UDEV during normal boot. Version-Release number of selected component (if applicable): 2.6.24.3-50 How reproducible: Simple... Attempt to install Fedora 8 on a motherboard containing a HPT 366 controller. Steps to Reproduce: 1. Place the Fedora 8 DVD into the drive 2. Boot the system and start the install 3. Note the hang when loading the HPT 366 driver Alternate Steps: 1. Disable the HPT 366 controller in the BIOS 2. Place the Fedora 8 DVD into the drive 3. Boot the system and run the install 4. Apply kernel updates 5. Reboot 6. Enable the HPT 366 controller 7. Watch the system hang at UDEV Actual results: System hangs. Expected results: System should boot and be usable. Additional info: This was found on an A-BIT BE6-II motherboard running a PIII 733.
If you boot with init=/bin/sh and then do "/sbin/modprobe pata_hpt366 &' what gets logged to the console ? The HPT366 is known to work (indeed I have one in the test set I use for checking kernels) so it would be useful to know things like what messages are displayed and what devices are connected to the HPT366 channels ?
Hi Alan, Thanks for digging into this problem. I'm pretty familiar with GNU/Linux as a whole but not an experienced kernel person. If you have additional tests that you want run, just let me know. I tried setting init=/bin/sh as you suggested. There was no output on the command line. The system would hang at this point. When changing the boot command to include init=/bin/sh I also took out the quiet flag. The output from the modprobe became: ACPI: PCI INterrupt Link [LNKC] enabled at IRG 10 ACPI: PCI Interrupt 0000:00:13.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 scsi3 : pata_hpt366 scsi4 : pata_hpt366 ata3: PATA max UDMA/66 cmd 0xd800 ctl 0xdc00 bmdmaa 0x3000 irq 10 ata4: DUMMY ata3.00: ATA-5: IC35L040AVVA07-0, VA2OA52A, max UDMA/100 ata3.00: 80418240 sectors, multi 0: LBA ata3.00: limited to UDMA/33 due to 40 wire cable ata3.00: configured for UDMA/33 scsi 3:0:0:0: Direct Access ATA IC35L040AVVA07-0 VA2O PQ: 0 ANSI: 5 sd 3:0:0:0: [sdb] 80418240 512-byte hardware sectors (41174 MB) sd 3:0:0:0: [sdb] Write Protect is off sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:0:0: [sdb] 80418240 512 byte hardware sectors (41174 MB) sd 3:0:0:0: [sdb] Write Protect is off sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: At this point, the system is hung. Caps lock/num lock will not update the keyboard, screen is unresponsive to key presses. ctrl-alt-del will not reboot, etc. The drive that is attached to the HPT366 is an IBM Deskstar 40 GB model. It's the only device on the HPT366 controller and should be on the first channel. Previously this system had Fedora 6 and Centos 4 and the HPT366 worked fine. It was the boot drive. When I ran into the hanging problem, I changed the install to go to the 3ware 6804. It is currently configured as a RAID 0 array with 3 500 GB Seagate drives attached... Could there be a conflict between the two? The 3ware card was in it before as well, so I'm leaning to that not being the problem.
Just a little more info... I booted Fedora 6 off the HPT366 controller with the latest available 'yum update' kernel, 2.6.22.14-72 and it works fine... Fedora 8 still fails to get past loading the driver module when trying to install or boot. Hardware configuration was the same in both cases.
Another update... I've tried the Fedora 9 beta live CD. It hangs as well during the boot process. The messages displayed on screen, just before the system hanfs are: atag: DUMMY modprobe used greatest stack depth: 2132 bytes left modprobe used greatest stack depth: 1728 bytes left Driver 'sd' needs updating - please use bus_type methods sd 2:0:0:0: [sda] 80418240 512-byte hardware sectors (41174 MB) sd 2:0:0:0: [sda] Write Protects is off sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sda] 80418240 512-byte hardware sectors (41174 MB) sd 2:0:0:0: [sda] Write Protects is off sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda:Marking TSC unstable due to: TSC halts in idle. Time: acpi_pm clocksource has been installed ISO 9660 Extensions: Microsoft Joliet Level 3 Unable to load NLS charset utf8 Unable to load NLS charset utf8 ISO 9660 Extensions: RRIP_1991A mount used greatest stack depth: 1544 bytes left squashfs: version 3.3 (2007/10/31) Phillip Lougher device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised: dm-devel
Very odd - its the same hang in both cases I think - when it tries to read a block from the disk it all blows up. What does booting with libata.dma=0 do ?
This seems to have fixed the problem. In the HPT366 boot screen, it lists the drive mode as UDMA4. So, DMA should be supported. I can not be certain at this point, but I believe DMA was turned on via hdparm and the drive worked. Does this help target where the problem lies? Has something changed in the later kernels that is causing the issue? Thanks for all your help!
Just as an update... this fixed the problem for the installation. It ran over night and had completed when I came back in to work. I've tried putting the same libata.dma=0 at the end of the GRUB command line during normal boot up and it keeps getting ignored: Unknown boot option `libata.dma=0': ignoring This was added to the end of the kernel line by editing it when GRUB appears. It was placed right after quiet rhgb and quiet options. (which is where it is supposed to go according to the Kernel Common Problems page on fedoraproject.org.
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
I am having this exact same problem with my Abit BP6 motherboard. I recently installed Fedora 10, where the last time I had installed was Fedora 6. No change in hardware configuration. I tried Fedora 9, 8 and 7 disks too and they (for sure the 9 and 8) disks also experience locking up during the boot of the install discs. I get the exact same message on the console as the above Comment #2. To complete the install I had to add blacklist=pata_hpt366 in order to be able to even boot the install disc. The install was successful but of course I can't see the Highpoint bus. Once booted, if I try to lsmod pata_hpt366, it doesn't complete although the system is usable in other windows/consoles, for about 30 seconds before it hangs hard. There are two 250GB Western Digital drives on the Highpoint bus, in a RAID 1 configuration, that was working fine for several years under Fedora 6. From the comments above, I looked for a way to disable DMA in the Highpoint BIOS or from grub, but haven't found one yet. I am pretty experienced with hardware and Linux/Unix so feel free to ask detailed questions or for additional testing, if I can help further.
Ok first one to test is the boot option libata.dma=0, that will turn all ATA DMA off so it will gronk along very slowly but this will confirm if the problem is DMA related (My guess is that this is the case). Second test is to boot with "noapic" Third is to boot with "irqpoll" Assuming that is the problem and you've got a nice reliable reproducable test case then there is hope. The 2nd/3rd tests are just for IRQ routing problems and I expect they will make no difference. Does any other device share the IRQ used by the HPT366 ? Alan
Hi Alan, Thanks for these ideas. However, according to Comment #7 above, libata.dma=0 is not a valid boot option? Or is that somehow in error? Either way, I will try them all tonight but just checking. Thanks! Eric
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.
Just for anyone searching - the fix that is believed to cure this went upstream yesterday into 2.6.29rc
Can we at least change the Fedora version on this bug to 10? Since it is known to occur in 10 and not fixed (yet to be confirmed)? Thanks for the heads-up this possible fix though! I didn't have time to try those ideas above I went ahead and slapped in a PATA PCI card and brought the drives back online from there. However, when and if I do add more drives to this server, I'll try the HPT366 bus again and see if it works after I get up to 2.6.29c. Thank you.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.