Date: Thu, 10 Aug 2006 16:27:48 +0100 From: Dominic Marks <dom@goodforbusiness.co.uk> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Device conflict 3ware twe and CMedia sound card Message-ID: <44DB5074.7040002@goodforbusiness.co.uk> In-Reply-To: <200608091627.43286.jhb@freebsd.org> References: <44D9B5B4.7010208@goodforbusiness.co.uk> <200608091627.43286.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Wednesday 09 August 2006 06:15, Dominic Marks wrote: >> Hello, >> >> I seem to have a device conflict on my desktop. When attempting to fsck >> a gstripe >> volume attached via the twe card the system becomes 'choppy' and from >> looking >> at systat (when it isn't frozen) the system is receiving about 300k >> interrupts per >> second from the pcm device. If I leave the system in this state for a >> few minutes it >> will do an instant-reset, presumably because it can't cope. >> >> Verbose dmesg: http://goodforbusiness.co.uk/~dom/dmesg.boot >> >> Specific parts: >> >> twe0: <3ware Storage Controller. Driver version 1.50.01.002> port >> 0xdcb0-0xdcbf mem 0xdf000000-0xdf7fffff irq 49 at device 13.0 on pci3 >> twe0: Reserved 0x10 bytes for rid 0x10 type 4 at 0xdcb0 >> ioapic2: routing intpin 1 (PCI IRQ 49) to vector 49 >> twe0: [GIANT-LOCKED] >> twe0: AEN: <soft reset> >> twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 >> twe0: Monitor ME7X 1.01.00.040, PCB Rev5 , Achip 3.20 , Pchip 1.30-66 >> twe0: port 0: WDC WD3200KS-00PFB0 305245MB >> twe0: port 1: WDC WD3200KS-00PFB0 305245MB >> >> pcm0: <CMedia CMI8738> port 0xcc00-0xccff irq 17 at device 13.0 on pci7 >> pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xcc00 >> ioapic0: routing intpin 17 (PCI IRQ 17) to vector 55 >> pcm0: [MPSAFE] >> pcm0: sndbuf_setmap 3e8ee000, 4000; 0xe5408000 -> 3e8ee000 >> pcm0: sndbuf_setmap 3e8ea000, 4000; 0xe540c000 -> 3e8ea000 >> >> I believe I can use device.hints(5) to work around this, but I am unsure >> variable I can >> set in order to resolve this. Does the device 13.0 from dmesg refer to >> the 'drq' ? > > Does this system have an Intel PCI-X host bridge in it? If so, it's > probably due to brain damage in that chip. You might be able to work > around it by making twe0 use the same IRQ as pcm0 by adding the > following hint: I've had a look, I don't exactly know what to look for, but I have several PCI Express to PCI bridges: pcib2@pci1:0:0: class=0x060400 card=0x00000044 chip=0x03298086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = '6700PXH PCI Express-to-PCI Express Bridge A' class = bridge subclass = PCI-PCI pcib3@pci1:0:2: class=0x060400 card=0x00000044 chip=0x032a8086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = '6700PXH PCI Express-to-PCI Express Bridge B' class = bridge subclass = PCI-PCI While looking through the pciconf -vl output I also noticed this error: twe0@pci3:13:0: class=0x010400 card=0x100113c1 chip=0x100113c1 rev=0x01 hdr=0x00 vendor = '3ware Inc.' device = '7000/8000 series ATA-133 Storage Controller' ** class = mass storage subclass = RAID ** This actually a SATA 150 Controller. Not a big deal, but still incorrect. > hint.pci3.13.INTA.irq=17 > > That should make twe0 use IRQ 17. > I doesn't seem to have had the desired effect: > kenv | grep pci3 hint.pci3.13.INTA.irq="17" > grep twe0 /var/run/dmesg.boot twe0: <3ware Storage Controller. [...]> port 0xdcb0-0xdcbf mem 0xdf000000-0xdf7fffff irq 49 at device 13.0 on pci3 Thank you very much John. I'll keep on looking for a solution. Dominic
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44DB5074.7040002>