On Fri, Apr 4, 2008 at 9:14 AM, Brett Dikeman <brett@xxxxxxxxxx> wrote: > > There is a known issue with arrays in the "read-auto" state and "mdadm > > --monitor". The attached patch addresses this. > > Ah- I forgot that, yes, mdadm monitor was running. I was *wondering* what > mdadm process was hanging around to segfault- duh! :-) > > > > > What is more concerning is the usb-storage hangs. Do you have logs > > from when it hung? > > Nope- absolutely nothing useful from dmesg or /var/log/messages. The > array simply grinds to a halt. I think it might be the USB bridge, since > this morning I woke up to find the same drive as previously mentioned, > with its access light on continuously (didn't happen the first time.) It > did get further along in the sync- 66.7%, very roughly twice as far as the > first time. > > /proc/mdstat keeps getting updated during all this; the (obviously > averaged) rebuild rate average drops steadily. > > I don't have any info handy on the USB device, but it's an older > SATA<->USB/eSATA AMS Venus (expensive but otherwise nice case. Has a > silent 80mm fan in it that doesn't move much hair, but does keep drives > cooler.) It dates back to when manufacturers were still making "L" > "eSATA" ports (grr.) The other USB bridge is a Vantec multi-interface > bare adapter. That one seemed fine. > > Ask away with things you'd like me to try- I'll get more info this > evening, and I might try picking up a second one of the Vantec interfaces > if I can (they're cheap- and have proven endlessly useful.) > Unfortunately, my intended destination for this array uses Adaptec 1205SA > PCI cards, which idiotically don't support drives over 500GB and hang > during their POST :( > The output from sysrq-w after the hang might shed some light. I have copied linux-usb [1] in case they recognize the devices you mentioned. -- Dan [1]: original report http://marc.info/?l=linux-raid&m=120728545823965&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html