Distribution: Gentoo 2004.0 Hardware Environment: x86, AMD Athlon 1500+, VIA KT333. Software Environment: Kernel 2.6.5, gcc 3.3.2, glibc 2.3.2 Problem Description: Computer Steps to reproduce: Insert HighPoint Rocket 1540 and connect at least one disk. Boot from on-board controller. Load hpt366.ko Computer hangs hard. Ctrl-Alt-Del and numlock dead. Nothing written to syslog. If no disk is connected to the controller, the driver loads correctly. If no disk is connected to the controller during boot (so that the on- board BIOS doesn't detect the disk) but the disk is connected before loading the driver, the driver also loads correctly. (but the driver doesn't seem to autotune the transfer mode, and I get drive_cmd: status=0x58 { DriveReady SeekComplete DataRequest } status error: status=0x58 { DriveReady SeekComplete DataRequest } errors, but that is as far as I can tell a separate issue) Additional information: I have also tried to use various versions of HPTs 'open source' drivers under both 2.4.2x and 2.6.x and the same thing happens. If a disk is connected, it hangs but if no disk is connected during POST/BOOT the driver loads correctly. Please note that the card is a HighPoint Rocket 1540, not a RocketRAID 1540. It looks like the two cards have identical chips, but the PCB layout is different and the Rocket 1540 can not use the RocketRAID firmware (hangs while probing disks).
*** Bug 4300 has been marked as a duplicate of this bug. ***
I assmue that 2.6.12-rc5 is still exhibiting this bug?
Workaround for Kernel 2.6.10: append="hdX=noprobe" This requires you to boot from some other media, and use the "open source" driver supplied by Highpoint (http://www.highpoint-tech.com/BIOS%20+%20Driver/r1540/Linux/r1540-openbuild-v1.0.tgz) to create a fake SCSI module that can be loaded to mount the hard drive(s). Unfortunately, this driver is not actually open source at all, as it contains hptprot.o and hptprot-x86_64.o with some wrapper source that tries to hook in with the Linux SCSI subsystem. Apparently this driver no longer works with Kernel 2.6.12!
Will watch this, although it might've been fixed...
Has anyone tested this controller with recent kernels and can confirm the problem still exists? Thanks.
(In reply to comment #5) > Has anyone tested this controller with recent kernels and can confirm the > problem still exists? I'm afraid yes -- there has been alike report, see the bug #8851...
Lars (and others with this controller) - can you please test 2.6.25 kernel ? there have been quite some changes to this driver in the meantime.
via direct conversation: >On 4/30/08, bugme-daemon@bugzilla.kernel.org ><bugme-daemon@bugzilla.kernel.org> wrote: >> http://bugzilla.kernel.org/show_bug.cgi?id=2555 > >I have not have any problems with this bug and I think it was >resolved in 2.6.13. See the last comment on >http://bugzilla.kernel.org/show_bug.cgi?id=4300 > >Btw., I boot up linux and then modprobe with 4 HDD connected, >which workes great (I have not tested with the kernel yet). > >Best regards, >Flemming Richter so, since #4300 is closed, i think we can close this one, too - ok ?
On Wed, Apr 30, 2008 at 11:32 PM, <bugme-daemon@bugzilla.kernel.org> wrote: > so, since #4300 is closed, i think we can close this one, too - ok ? Yes, thank you. If someone still has a problem, it can always be reopened. So I think you can close this. I should have done it, and I am not sure why I never did.
OK, thanks guys. Closing the bug.