Date: Mon, 12 Apr 1999 10:00:47 -0700 (PWT) From: Matthew Jacob <mjacob@feral.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Doug Rabson <dfr@nlsystems.com>, freebsd-scsi@freebsd.org Subject: Re: umm- ISP adapter feedback... Message-ID: <Pine.LNX.4.04.9904120952460.23829-100000@feral-gw> In-Reply-To: <14098.8921.665186.7704@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> Matthew Jacob writes:
> >
> >
> > One of you, I forgot whom, had the new XP1000 to play with- it had a new
> > rev 'C' ISP1040 in it- I updated the driver to treat it like a ISP1040B
> > and I'd like to know if it's been working okay.
>
> That would be me. If you mean rev 1.17 of isp.c, its been working so
> well that I hadn't noticed that you'd changed anything ;-)
Well that's a good sign!
>
> > Secondly- I upped the queue limits again to 256- that used to give Doug's
> > system agita. Let me know if it breaks again. The limit's going higher
> > later- the 1080/1240 can take up to 1024 entries (I've done the 1080
> > support and the 1240 support is almost done and is in partial test at a
> > place in England). I've also committed to using the FAST POST feature
> > (commands that complete okay don't get a response updated in the response
> > queue- instead the command handle is posted to mailbox registers and an
> > async event interrupt is posted).
>
> I'm not sure what rev you did this with, but on a Miata (DPW500au)
> with:
>
> Qlogic ISP Driver, FreeBSD CAM Version 0.99, Core Version 1.7
> isp0: <Qlogic ISP 1020/1040 PCI SCSI Adapter> rev 0x05 int a irq 3 on pci1.4.0
> isp0: using I/O space register mapping
> isp0: Ultra Mode Capable
> isp0: Board Revision 1040B, loaded F/W Revision 7.55
> isp0: Last F/W revision was 5.54
> isp0: invalid NVRAM header
>
> I saw pages of these errors on console:
> isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 34 (next 35)
> isp0: rqs_flags=2isp0: internal queues full
> isp0: unknown return 1
> isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 35 (next 36)
> isp0: rqs_flags=2isp0: internal queues full
> isp0: unknown return 1
> isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 36 (next 37)
> isp0: rqs_flags=2isp0: internal queues full
> isp0: unknown return 1
Ah! Ah! Ah! Ah! I *just* fixed this with the work I was doing on Geoff's
system (the ISP 1240). I'll clean up and commit at least some of the
changes today! This was a request getting punted right back out from the
request queue to the response queue by the chip w/o even trying to run the
command- I have to synthesize a QUEUE FULL condition. This only is
happening in the case of cards with unreadable NVRAM where I then set the
default queue limit to 128 (and then now run over that).
(I can only do so much testing on my own! Thank you!)
>
> I've just built a fresh kernel & put it on that machine & rebooted to
> see if anything changed, but it hasn't been up terribly long...
>
A quick fix for this is to change the line around 3789 from
sdp->isp_max_queue_depth = 128;
to
sdp->isp_max_queue_depth = MAXISPREQUEST;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9904120952460.23829-100000>