Date: Tue, 22 Sep 1998 23:10:20 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: shimon@simon-shapiro.org Cc: scsi@FreeBSD.ORG Subject: Re: DPT boot Message-ID: <199809230510.XAA00733@narnia.plutotech.com> In-Reply-To: <XFMail.980922230648.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <XFMail.980922230648.shimon@simon-shapiro.org> you wrote: > > Eivind Eklund, On 22-Sep-98 you wrote: >> I just tried to boot my box with a CAMified kernel, and found that it >> wouldn't. Everything probed fine, but after the NPX message it just >> hung >> for a long while. After a number of minutes (more than 2, as that was >> what >> I tried first, but less than 17, which was when I got back to the box) >> it >> spit out a message (something like "CCB (0:0:0:0:0) Timed out" - I >> unfortunately didn't write it down). Was Eivind's message originally on the SCSI list? This is the second time I've heard you reference messages that I haven't seen on the list. Strange. > I get similar symptoms, but much shorter timeouts, like fraction of a > second per CCB. Then I get the panic I reported. This is with the latest version of dpt.c in the tree? > since there is no > documentation for the driver layer, I can only guess at what I see; for > each possible drive, there is a CCB. Probably to handle the Inquiry or > some such. For non-existing drives, these indeed should timeout. For non-existing drives, the inquiry should not timeout. It should come back after a `selection timeout' (which is quite different than a command timeout) with a selection timeout error code. This, however, was not where the problem was. >> The CCB message was the only I got - no disk descriptions from either >> controller (though I don't know if I should expect them - this is my >> first CAM experiement). > > I would imagine these should come later, once the CCBs are answered. Yes. They come up after interrupt services are available and probing has been completed. >> Any clues? Anything I should test? (I can hook up a pretty complete >> debugging environment here, including doing remote kernel debugging if >> necessary - at the moment I also have 'scratch' disks I can use for >> testing, >> though not having this controller operational means I my main >> workstation is >> not usable, so I'd prefer to avoid tests that take a long time). > > I assume this controller works on the pre-CAM driver... :-) This problem has nothing to do with either DPT driver. It has to do with multi-lun probing and serial number inquiries. On my PM3224A card, it seems that RAID-1 DPT volumes will not tolerate inquiry requests to luns greater than 0. An inquiry request for a VPD page also hangs the controller. This was under firmware 7BG0. I need to get a 2Mb eeprom before I can test out newer firmware. Since the description of this problem matches my own experience, I can only guess that even the latest firmware still has this bug. I've added quirk entries to the generic SCSI layer to disable multi-lun probing and serial number requests to all DPT RAID volumes (although RAID-5 volumes did not seem to have this problem). If this is not sufficient to address your problem, please let me know. > ``...And Carthage shall fall..'' - Cicero > ``Documentation would have been nice'' - Simon This simply isn't fair Simon. I told you I couldn't provide CAM documentation because of my time constraints, so you asked me to port the DPT driver to CAM. If you are displeased with the results, you should talk to me about ways that this can be addressed instead of posting messages full of inuendo to a public list. -- Justin 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?199809230510.XAA00733>