Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Apr 2006 14:01:10 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Oleg Sharoiko <os@rsu.ru>
Cc:        freebsd-scsi@freebsd.org, Andrey Beresovsky <and@rsu.ru>
Subject:   Re: Boot hangs on ips0: resetting adapter, this may take up to 5 minutes
Message-ID:  <200604101401.12479.jhb@freebsd.org>
In-Reply-To: <20060406223724.S1099@wolf.os.rsu.ru>
References:  <20060215102749.D58480@brain.cc.rsu.ru> <20060328201134.S763@brain.cc.rsu.ru> <20060406223724.S1099@wolf.os.rsu.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 06 April 2006 15:07, Oleg Sharoiko wrote:
> Hi, that's me again.
> 
> John, I've got more information on my problem:
> 
> It looks like the mis-routed interrupt is the one from ips. In my kernel 
> ips is on vector 49 and bge is on vector 60. I've added 
> 
> 	if (vector == 60)
> 		vector = 49;
> 
> to sys/amd64/amd64/local_apic.c and I have no more interrupt storm until 
> bge really generates interrupt. Am I right with my conclusion about ips 
> interrupt being mis-directed to bge?

Well, the vectors is the wrong thing to mess with as vector's are IDT
entries.

> There's also another interesting point: it looks like ips triggers 
> interrupt on both vectors (49 and 60 - irq 28 and irq 16). Why do I think 
> so?

This happens in several machines with Intel server chipsets due to a bug
in the PXH host bridges with no real workaround.

> 1. ips works fine even when there's no bge in kernel (I suppose irq 16 is 
> not activated in this case). I suppose this should mean that interrupts 
> are properly delivered to ips driver.
> 
> 2. I've added debug printf to bge_intr and in single mode when preemption 
> is disabled I see exact the same number of interrupts delivered to ips 
> (checked counters with showintrcnt) and to bge (incorrectly delivered - 
> bge is not in UP state and bge registers say "no interrupt"). 
> 
> This seems really strange to me, how can this be possible? Is there any 
> way to fix this?

One thing you can do w/o hacking the code is to reroute ips0 to IRQ 16.
Find the dmesg line for ips0, it should say something like:

ips0 <...> ... at device 4.0 on pci2

These numbers (4 from '4.0' and 2 from 'pci2') are the slot and bus
for ips0.  We'll assume INTA is being used as single function cards
using INTA.  Then, set a tunable like so in the loader to force ips0 to
use IRQ 16:

'set hw.pci2.4.INTA.irq=16'

This may not work for 6.0 but should work for 6.1 and later.

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604101401.12479.jhb>