Patrick M. Hausen wrote:
Hello!
On Mon, Aug 21, 2006 at 02:14:16PM +0100, Matt Dawson wrote:
FWIW, the problem takes *far* longer to rear its head when the SATA controller
has a PCI INT and IRQ to itself. Put a NIC onto a shared slot (a very Bad
Thing [TM] as the BIOS simply maps the INT to a single IRQ and both devices
end up sharing it. Now tranfer a large file over the network and watch the
ensuing hilarity) and it happens at least every couple of days. Now, with the
slot shared with the SATA controller empty, I have six days uptime since the
last event, which means I'm probably due one any time now.
FWIW - here's the setup of my systems that have not shown the
problem so far:
Device IRQ
------ ---
em0 16
em1 17
uhci0 23
uhci1 19
uhci2 18
uhci3 16
ehci0 23
fxp0 16
atapci1 19 This is the SATA300 controller
Is there a method to force the controller to share its IRQ with,
say, em0 for testing?
You can use device.hints(5) to do this.
I have the following in mine to force a RAID card and Sound card to
share IRQ 17.
You need to modify it to suit your environment.
hw.pci3.13.INTA.irq="17"
The `13' value is the device number, you can find this in dmesg, same
for pciN.
HTH,
Dominic
Regards,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
