https://bugzilla.novell.com/show_bug.cgi?id=474879
Summary: Cannot make use of HighPoint RocketRAID 133
(HPT372A/372N, V2.35) controller
Classification: openSUSE
Product: openSUSE 11.1
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.1
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Kernel
AssignedTo: bnc-team-screening@forge.provo.novell.com
ReportedBy: DOlsson@WEB.de
QAContact: qa@suse.de
Found By: ---
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.6)
Gecko/2009012700 SUSE/3.0.6-0.1 Firefox/3.0.6
When booting up the Rescue system from the openSUSE 11.1 GM x86_64 DVD
(downloaded version), it is not possible to make use of my HighPoint RocketRAID
133 (HPT372A/372N, V2.35) controller.
On this controller, I have these discs attached:
Channel #0, master: <disc attached> Channel #1, master: <disc
attached>
Channel #0, slave: <none> Channel #1, slave: <disc
attached>
Reading from and writing to disc on #0m works nicely.
Reading from disc on #1m also works nicely, but writing to this disc results in
driver crash, followed by a detachment of the disc from the controller!
Reproducible: Always
Steps to Reproduce:
I have done the following (for details for each of the tests done, see the
following comment entries):
- Booting up from the DVD as normal.
- Doing a "fsck -fn 1" => always results in OK.
- Doing a "fsck -f 1" => always results in OK.
- Doing a "fsck -fn 1" => always results in OK.
- Doing a "fsck -f 1" => always results in drive crash, except for
once (see below).
Actual Results:
When accessing the disc for writing attached to channel #1m, the driver crashes
with a kernel message that no one cares for IRQ 19.
Expected Results:
That the "fsck" checks even on channel #1m runs without causing driver crashes.
A common observation for all the driver crashes are that in "boot.msg", you can
observe that the drive first attaches itself to IRQ 19 and shortly there after
detaches itself from it again, and somewhat later the "pata_hpt3x2n" driver not
long also registeres its interest in IRQ 19, but also annouces that it is
handling the controller including the discs.
This is very strang and odd, I find! :-)
It also looks as if the three HighPoint drivers really
cannot agree upon which one of them that is taking care of the HighPoint
controller, in that they are strangly intervened in their attachment to IRQ 19.
When the driver has crashed, while the kernel has detected that no one feels
responsible for IRQ 19, the disc used will be detached from the controller (and
thus no longer available/cannot be seen any more).
Another strange thing is that the order in which the discs
appear, changes "wildly" during the testing with "brokenmodules".
Why, any specific reasons for this?
Finally, when trying to do a "reboot" after the driver has crashed, it is no
longer possible to perform an actual reboot of the PC -- "reboot" does its
normal work of shutting down everything, but the last part, where it should
cause the rebooting of the system, "reboot" just hangs -- only choice is to
push the reset button to get the PC to reboot.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
