Date: Mon, 21 Aug 2006 15:27:43 +0200 From: "Patrick M. Hausen" <hausen@punkt.de> To: Matt Dawson <matt@chronos.org.uk> Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: ATA problems again ... general problem of ICH7 or ATA? Message-ID: <20060821132743.GC45736@hugo10.ka.punkt.de> In-Reply-To: <200608211414.16731.matt@chronos.org.uk> References: <20060821120052.0B25816A526@hub.freebsd.org> <200608211414.16731.matt@chronos.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060821132743.GC45736>