[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