Date: Wed, 23 Sep 1998 11:02:27 -0400 (EDT) From: Simon Shapiro <shimon@simon-shapiro.org> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: scsi@FreeBSD.ORG Subject: Re: DPT boot Message-ID: <XFMail.980923110227.shimon@simon-shapiro.org> In-Reply-To: <199809230510.XAA00733@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Justin T. Gibbs, On 23-Sep-98 you wrote: > 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 belive it was on current, not scsi. There is no conspiracy here :-) > > 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? Nope, one that is three days old. > > 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. Ah... We are learning as we go... > >> 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. I have to chech the driver. The DPT will not do anything (IRT to sending completions) until you clear the interrupt that was queued. Further, it will accept (on most boards) up to 64 commands, but will respond to exactly one and then wait. If I understand you correctly, we may have a situation where the DPT generates an interrupt on the first completed command. Since iti is not served, none of the others is served. then they timeout. > >> 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. I will. I'll test again today or tomorrow. > > ``...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. Apologies submitted. There was no innuendo intended. I am a bit frustrated, yes. but we can continue the discussion in private. It was wrong of me to make it public. I am sorry. Simon 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?XFMail.980923110227.shimon>