Date: Tue, 22 Sep 1998 23:06:48 -0400 (EDT) From: Simon Shapiro <shimon@simon-shapiro.org> To: Eivind Eklund <eivind@yes.no> Cc: scsi@FreeBSD.ORG Subject: RE: DPT boot Message-ID: <XFMail.980922230648.shimon@simon-shapiro.org> In-Reply-To: <19980923003214.35208@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
I get similar symptoms, but much shorter timeouts, like fraction of a
second per CCB. Then I get the panic I reported. 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.
> This is with the following DPT controller:
> dpt0: <DPT Caching SCSI RAID Controller> rev 0x02 int a irq 10 on
> pci0.11.0
> dpt0: DPT type 3, model PM3224W firmware 07H1, Protocol 0
> on port d810 with Write-Back cache. LED = 0000 0000
> dpt0: Enabled Options:
> dpt0: waiting for scsi devices to settle
> scbus0 at dpt0 bus 0
> ... and an Adaptec 2940:
> ahc0: <Adaptec 2940 Ultra SCSI host adapter> rev 0x00 int a irq 9 on
> pci0.13.0
> ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs
> ahc0: waiting for scsi devices to settle
> scbus1 at ahc0 bus 0
>
> 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.
> 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... :-)
> Oh, and while this was happening, the DPT kept a steady light #3 (as
> counted
> from the connector-less end of the DPT).
On a 3224 it is bus transfer from adapter, or adapter reset (depends on how
you look at it, and assuming first LED is 1). If it is a transfer LED,
then the DMA engine is stuck. If it is a reset, that means the controller
was reset and never released. In either case I would suspect the
initialization code does not work correctly. I have some work-work
emergencies to handle right now, but will start debugging this driver any
day soon.
``...And Carthage shall fall..'' - Cicero
``Documentation would have been nice'' - Simon
Sincerely Yours, Shimon@Simon-Shapiro.ORG
770.265.7340
Simon Shapiro
Unwritten code has no bugs and executes at twice the speed of mouth
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.980922230648.shimon>