Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Apr 2006 12:43:30 -0600
From:      Scott Long <scottl@samsco.org>
To:        John Baldwin <jhb@freebsd.org>
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:  <443AA752.3070304@samsco.org>
In-Reply-To: <200604101401.12479.jhb@freebsd.org>
References:  <20060215102749.D58480@brain.cc.rsu.ru> <20060328201134.S763@brain.cc.rsu.ru> <20060406223724.S1099@wolf.os.rsu.ru> <200604101401.12479.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> 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.
> 

Well, the work around is to not mask the APIC and instead let the driver 
handle masking or ACKing the interrupt =-)  It sucks that there are
undocumented gotchas like this in the PC platform, but it is important
to acknowledge them.

Scott





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