On Sat, Feb 28, 2009 at 7:08 PM, Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx> wrote: > > On Sat, 28 Feb 2009, Brad wrote: > >> Hi. I'd like to revisit a problem I put to the mailing list on the >> 27th July 2008. >> >> My linux system hangs if I have a lengthy recovery of a raid-1 >> device going on at the same time as any significant network >> traffic. >> ... > > I have the same mobo: > > Handle 0x0001, DMI type 1, 27 bytes > System Information > Manufacturer: Gigabyte Technology Co., Ltd. > Product Name: P35-DS4 How did you get that information, please? Another linux command for me to learn?! :-) > Have a RAID1 and RAID5, I do not use the jmicron SATA ports, only the intel > ones and add-on pci-e cards, never had any problems with the raid volumes. > The NIC is sort of flaky though [in linux], I recommend using an intel > pci-e 1gbps card. I've had another problem with the Realtek network driver ... under network load it seemed to miss interrupts and/or pass them to the IDE driver, which would print out errors about unexpected/unknown interrupts. I had to take IDE out of my kernel. I *think* my current hanging problem was even worse when the pata_jmicron driver module - which I need to use the ATA DVD drive connected to one of the JMicron's IDE ports - shared the same interrupt as the Realtek driver. I couldn't find a way to change interrupts (can one do that at will with the Linux kernel?) so my backup script unloads the pata_jmicron module before it attaches the third backup disk to the md1 array. But it still hangs if there's any significant network traffic. Maybe, even though I've gotten rid of anything using the same IRQ as the Realtek - IDE or pata_jmicron - the NIC driver is still flubbing interrupts and that's confusing the kernel? Thanks for the advice Justin. Maybe the solution is to abandon use of the Realtek NIC (a pity to 'waste' what's freely available on the motherboard, though, in a way). Brad -- 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
