Date: Mon, 21 Aug 2006 14:40:17 +0100 From: Dominic Marks <dom@goodforbusiness.co.uk> To: "Patrick M. Hausen" <hausen@punkt.de>, freebsd-stable@freebsd.org Subject: Re: ATA problems again ... general problem of ICH7 or ATA? Message-ID: <44E9B7C1.9010708@goodforbusiness.co.uk> In-Reply-To: <20060821132743.GC45736@hugo10.ka.punkt.de> References: <20060821120052.0B25816A526@hub.freebsd.org> <200608211414.16731.matt@chronos.org.uk> <20060821132743.GC45736@hugo10.ka.punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44E9B7C1.9010708>