Re: isp panic with 64-bit card

[Staffan Thomén <duck%shangtai.net@localhost>]

On Sat, Dec 27, 2014 at 10:57:11PM +0000, Christos Zoulas wrote:
> In article <20141227095728.GA583%knightrider.shangtai.net@localhost>,
> Staffan Thomén  <duck%shangtai.net@localhost> wrote:
> >Hi, I have an AlphaPC164 that has two scsi boards, an isp1020 and an isp1080, my
> >system boots off a disk on the 1020 and the 1080 is hooked up to an external
> >disk array of some 12 disks.
> >
> >The 1080 is a 64-bit card, and works fine in a 32-bit pci slot. If I plug it
> >into a 64-bit slot it works for a little while (I can boot up, read from and
> >write to disks) and after a few minutes the kernel panics with:
> >
> >isp1: Not RESPONSE in RESPONSE Queue (type 0x2) @ idx 25 (next 26) nlooked 1
> >isp1: Request Queue Entry:                                                  
> >isp1: 0x00000000: 02 01 00 00 00 fc ff ff 06 00 00 00 00 00 00 00
> >isp1: 0x00000010: 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00
> >isp1: 0x00000020: cc 01 43 00 00 fc ff ff 30 9a 25 00 00 fc ff ff
> >isp1: 0x00000030: b8 38 cc 00 00 fc ff ff 06 00 00 00 00 00 00 00
> >panic: kernel diagnostic assertion "(l->l_pflag & LP_INTR) == 0" failed:
> >file "/data/tmp/src/sys/kern/kern_synch.c", line 187 
> >spopped in pid 0.5 (system) at  netbsd:cpu_Debugger+0x14:       or      zero,s6
> >
> >Is this just that the card isn't designed to operate on a slow bus in 64-bit
> >mode or a kernel mistake?
> >
> >I'd love the increased bandwidth, but this is obviously not a high profile
> >target... :-)
> 
> It is a programming error. Something is attempting to sleep from an interrupt.
> Can you post a stack trace?

Unfortunately no, this machine is in "production" use and I'd rather not bother
my users more. It has recently started to reset itself for no apparent reason--
thus I had the opportunity to shuffle the cards around a bit--with no error
message on the console, just straight back into POST.

Doing the magic motions of re-seating everything has fixed this in the past, so
this is what I've tried now. We'll see if I have an opportunity to get a stack
trace.

Is there anything else I could do if such an opportunity presents itself?

Staffan

-- 
Staffan Thomén - ADB3 455F 10D5 86D1 78D6  048D 11BB D66E 7C7E 2EF8