From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041008 Firefox/0.10.1 Description of problem: The system hangs while detecting/setting up a disk drive on the HPT372A IDE controler at boot up time. The problem doesn't show if no IDE device is attached to that controler. Also the problem doesn't occur with kernel-2.6.5-1.358. I narrowed down the problem to a recent patch by Alan Cox (see attached patch). Reverting the patch and recompiling the kernel fixes the problem. I have reproduced the problem with FC1 where the patch was already present. That could explain bugs #104817 and #110720 Version-Release number of selected component (if applicable): kernel-2.6.8-1.521 How reproducible: Always Steps to Reproduce: 1. Install FC2 on machine with HPT372A 2. Update to the most recent kernel errata (2.6.8-1.521) 3. Reboot and watch system hang Additional info:
Created attachment 105124 [details] Patchlet to revert in order to fix problem
Please supply the boot log so I can take a look at it
PS: if you are building new kernels if you can build one that prints the RID/DID that would be useful so I can check if we are misdetecting one of the HPT372 variants that isnt -N
Created attachment 106405 [details] dmesg from booting 2.6.8.1 here's the boot log I get when I boot 2.6.8.1 without any IDE device attached to the controller. I added a printk to display RID and DID.
If I attach a disk drive, the kernel crashes right after displaying the following lines (I'm copying this from reading the screen): HPT372A: chipset revision 2 did=5 rid=2 hpt: HPT372N detected, using 372N timing. FREQ: 96 PLL: 41 HPT372A: 100% native mode on irq 11 hpt: no known IDE timings, disabling DMA. hpt: no known IDE timings, disabling DMA. hde: HDS724040KLAT80, ATA DISK drive Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 02256cb9 I used kernel 2.6.9-1.667 for i686 here. The call trace is: 02256f9b 02269344 0226bb03 02269388 0226bb4d 022584ee 023bd917 023bd948 023bd88b 023bd8d4 023a8717 02100477 0210043e 021041d9
I had another go at tracking down this problem. The problem occurs in "pci_bus_clock_list" in "hpt366.c" because "chipset_table" is NULL. The reason for this originates in "init_hpt37x". For some reason the card I've got falls through the PLL adjustement without calling "pci_set_drvdata". I tried to have the code fallback to 33Mhz PCI clock (somehow as I don't understand most of the code) and I got my system to boot again with a such patched 2.6.9-1.681_FC3 kernel. Is there anything else I could try to help find a real solution to this problem?
Created attachment 108044 [details] Patch used to boot 2.6.9-1.681_FC3
The PLL tuning code has several flaws in it. I've been rewriting it but while it now tunes the PLL I broke something else. Its on my todo list after the more urgent stuff.
Is it possible to have access to this new broken code and/or any type of documentation? I have a few machines waiting to be installed and am willing to spend some time on this. Also, would you like to have one of the cards I'm using shipped to you?
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.
The bug is still there with the latest kernel from FC3 updates (2.6.11-1.14_FC3) and FC4 test1. If you can't fix it quickly, it would be nice if at least the crash was removed by disabling that IDE controller under the incriminating conditions.
The only documentation I'm aware of is NDA although there is a highpoint vendor driver for 2.4 that is at least as good as any documentation I've seen if not far better.
Mass update of -test bugs to update version to fc4. (Please retest on final release, and report results if you have not already done so). Thanks.
[This comment has been added as a mass update for all FC4 kernel bugs. If you have migrated this bug from an FC3 bug today, ignore this comment.] Please retest your problem with todays 2.6.12-1.1398_FC4 update. If your problem involved being unable to boot, or some hardware not being detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE* installing any kernel updates. If in doubt, you can recreate this file using.. mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak mv /etc/modprobe.conf /etc/modprobe.conf.bak kudzu Thank you.
Created attachment 116867 [details] Patch to fall back when dpll setup fails This patch will let info->speed to be set for 372N even if we are going to use the pll setup. This value will only get used if the pll setup fails. I've been using this patch on a few computers for months with success.
I have a very similar problem with a HPT 374 SATA card that uses this driver, but the 7/18/05 patch didn't fix my problem. The kernel hangs with no visible errors after displaying the drives attached to the card. If there are no drives attached, it boots normally.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Closing per previous comment.