On Sat, Feb 28, 2009 at 7:08 PM, Justin Piszcz [off-list ref] wrote:

On Sat, 28 Feb 2009, Brad wrote:

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html