[Bug 13046] Kernel lockup when stressing s/w raid on Promise TX2plus SATA cards
bugzilla-daemon at bugzilla.ubuntu.com
bugzilla-daemon at bugzilla.ubuntu.com
Sat Jul 30 12:16:11 UTC 2005
Please do not reply to this email. You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=13046
Ubuntu | linux
hvy4-idbo at dea.spamcon.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |UNCONFIRMED
------- Additional Comments From hvy4-idbo at dea.spamcon.org 2005-07-30 13:16 UTC -------
OK, I've just done a whole load of testing.
Conclusions:
1) Putting the most up-to-date Promise BIOS on the cards makes no difference.
2) All the cards, cables and drives work fine as long as you only have two cards in the machine.
3) Drives on the 3rd and 4th cards are not seen by the Promise BIOS. (One exception seems to be when an
earlier card has no drives connected - a card with no drives doesn't seem "to count")
4) Linux always spots all the drives. But drives on 3rd and 4th cards cannot be hammered hard (such as by
hitting the raid array with dd) or the log starts getting the timeout errors as described earlier. After a
while the machine locks solid.
5) The errors and locking do not "follow" any specific hardware. It just seems to affect whichever are the
drives connected to 3rd and 4th cards.
6) I now, officially, hate Promise. :-)
If there is any chance that upstream (kernel? sata_promise? libata?) can fix this, then I'm open to
suggestions on how to proceed. If this is a limitation of Promise cards (albeit an undocumented one!) then I
guess we just accept that this is one of those things and close this bug.
Regards
Ian
P.S. During all of this fiddling mdadm worked very well. No damage to any data, and it always built the
arrays sensibly if enough drives were connected.
--
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
More information about the kernel-bugs
mailing list