On Apr 7, 2012 2:38 PM, "Matt Thyer" <matt.th...@gmail.com> wrote: > > On 7 April 2012 14:31, Matt Thyer <matt.th...@gmail.com> wrote: >> Since moving the SATA 3 disk to the onboard Intel SATA 2 controller I'm no longer having that disk evicted from the raidz2 pool with write errors and I thought that the high interrupt rate issue had also been solved but it's back again. >> >> This is on 8-STABLE at revision 230921 (before the new driver hit 8-STABLE). >> >> So now I need to go back to trying to determine what the cause is. >> > vmstat -i has shown that the issue was on irq 16. > > Unfortunately there seems to be a lot of things on irq 16: > > $ dmesg | grep "irq 16" > > pcib1: <PCI-PCI bridge> irq 16 at device 1.0 on pci0 > mps0: <LSI SAS2008> port 0xee00-0xeeff mem 0xfbdfc000-0xfbdfffff,0xfbd80000-0xfbdbffff irq 16 at device 0.0 on pci1 > vgapci0: <VGA-compatible display> port 0xff00-0xff07 mem 0xfb400000-0xfb7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > uhci0: <UHCI (generic) USB controller> port 0xfe00-0xfe1f irq 16 at device 26.0 on pci0 > pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0 > pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0 > atapci0: <JMicron JMB368 UDMA133 controller> port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f irq 16 at device 0.0 on pci3 > > Any idea how to isolate which bit of hardware could be triggering the interrupts ? > > Unfortunately the only device I could remove would be the SuperMicro AOC-USAS2-L8i (so yes I could eliminate that). > > My biggest problem right now is not knowing how to trigger the issue. > > At this stage I'm going to upgrade to 9-STABLE and see if it returns.
The problem does not occur with 9-STABLE. Who knows what the problem was ? USB maybe ? _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
