Bug 439791 - [pata_hpt366] HPT366 driver causes failure to boot
[pata_hpt366] HPT366 driver causes failure to boot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Martuccelli
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-31 09:19 EDT by Todd Littlefield
Modified: 2009-12-18 01:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:06:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Todd Littlefield 2008-03-31 09:19:36 EDT
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.
Comment 1 Alan Cox 2008-03-31 19:21:06 EDT
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 ?

Comment 2 Todd Littlefield 2008-04-01 09:09:24 EDT
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.
Comment 3 Todd Littlefield 2008-04-03 20:16:16 EDT
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.
Comment 4 Todd Littlefield 2008-04-15 10:04:51 EDT
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@redhat.com
Comment 5 Alan Cox 2008-05-14 07:18:58 EDT
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 ?
Comment 6 Todd Littlefield 2008-05-14 16:15:20 EDT
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!
Comment 7 Todd Littlefield 2008-05-16 16:29:44 EDT
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.
Comment 8 Bug Zapper 2008-11-26 05:19:18 EST
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
Comment 9 Eric D. Hendrickson 2008-12-13 17:52:47 EST
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.
Comment 10 Alan Cox 2008-12-15 11:45:12 EST
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
Comment 11 Eric D. Hendrickson 2008-12-16 12:10:51 EST
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
Comment 12 Bug Zapper 2009-01-09 01:17:30 EST
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.
Comment 13 Alan Cox 2009-01-09 07:34:06 EST
Just for anyone searching - the fix that is believed to cure this went upstream yesterday into 2.6.29rc
Comment 14 Eric D. Hendrickson 2009-01-09 14:21:36 EST
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.
Comment 16 Bug Zapper 2009-11-18 05:11:16 EST
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
Comment 17 Bug Zapper 2009-12-18 01:06:11 EST
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.

Note You need to log in before you can comment on or make changes to this bug.