Boot hangs on ips0: resetting adapter, this may take up to 5 minutes

[John Baldwin]

On Friday 21 April 2006 10:28, Oleg Sharoiko wrote:
> 
> On Mon, 10 Apr 2006, John Baldwin wrote:
> 
> JB>Well, the vectors is the wrong thing to mess with as vector's are IDT
> JB>entries.
> 
> Yes, I'm aware of this. The only reason I touched vectors was to 
> further debug the problem.
> 
> JB>One thing you can do w/o hacking the code is to reroute ips0 to IRQ 16.
> JB>Find the dmesg line for ips0, it should say something like:
> JB>
> JB>ips0 <...> ... at device 4.0 on pci2
> JB>
> JB>These numbers (4 from '4.0' and 2 from 'pci2') are the slot and bus
> JB>for ips0.  We'll assume INTA is being used as single function cards
> JB>using INTA.  Then, set a tunable like so in the loader to force ips0 to
> JB>use IRQ 16:
> JB>
> JB>'set hw.pci2.4.INTA.irq=16'
> 
> John, it works! Thank you! Thank you very much! That's great. Now I've 
> got those boxes up and running. I had to specify IRQ 16 for all 
> devices on pci3 and pci4, actually 2 and 1 devices accordingly. I 
> guess I should expect some performance degradation? Will it have sence 
> enabling device polling for bge which is also on IRQ 16?

I'm not sure if you will see a performance degradation or not.  On the
one hand, you no longer have interrupt aliasing, but on the other hand
you are now sharing the interrupt among several devices.

> Just for information: I've also tried 64bit version of windows server 
> and it looks that somehow windows uses correct IRQs. Though I'm not 
> sure if it displays correct information on device properties page in 
> device manager.

Windows doesn't mask interrupts in the APIC.  Instead, a Windows ISR is
required to shut the hardware up and defer any complicated work to a
separate DPC routine which is sort of like a per-cpu taskqueue, but
more like a per-cpu AST.

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