[6154] in linux-scsi channel archive
Re: Q: aha152x and 7502 CDR
daemon@ATHENA.MIT.EDU (Henrik Johansson)
Tue Mar 23 02:35:45 1999
Date: Tue, 23 Mar 1999 08:18:45 -0100 (GMT+1)
From: Henrik Johansson <henrik@lcdata.se>
To: Nathan Hand <nathanh@wookie.chirp.com.au>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.96.990322235612.7550A-100000@wookie.chirp.com.au>
Hi again Nathan.
I just had a thought. I've also seen this kind of problem
arise when a certan resource-conflict is present, namley
when two cards explicity requests the same IRQ.
These two forementioned devices may coexist in this way
until the traffic on the bus becomes intensive, which
casuses the kernel to hang. For example using the dd-command
to send bits-streams intensivly over the bus.
This is probably not the case here, but never the less.. :_)
Make sure You havn't got any PNP-cards lying unused in the
system; these malicious cards don't show up, but still
occupies some resources.
Good luck,
Henrik J.
On Tue, 23 Mar 1999, Nathan Hand wrote:
>
> I've posted recent messages regarding problems with a 7502 causing the
> aha152x driver to kernel panic (while reading via dd). I'm now looking
> at the code generating the panic. The segment is as follows.
>
>
> case P_CMD: /* command phase */
>
> ...
>
> SETPORT(SIMODE0, 0);
> SETPORT(SIMODE1, ENPHASEMIS|ENREQINIT|ENBUSFREE);
>
> /* wait for data latch to become ready or a phase change */
> while(TESTLO(DMASTAT, INTSTAT))
> barrier();
>
> for(i=0; i<CURRENT_SC->cmd_len && TESTLO(SSTAT1, PHASEMIS); i++) {
> SETPORT(SCSIDAT, CURRENT_SC->cmnd[i]);
>
> make_acklow(shpnt);
> getphase(shpnt);
> }
>
> if(i<CURRENT_SC->cmd_len && TESTHI(SSTAT1, PHASEMIS))
> aha152x_panic(shpnt, "target left COMMAND");
>
>
> As I understand this code, an interrupt for PHASEMIS is set and a busy
> loop writes the cmd_len command bytes to a data port. For my command I
> believe I have 6 command bytes, because cmnd=(Read (6) 00 02 91 08 00)
> is in the current_SC section of the kernel panic dump. If any of these
> command bytes result in the PHASEMIS going HIGH, something broke.
>
> Now the read arguments appears to have been "00 02 91 08 00", and this
> has been verified by multiple kernel panics (they can be produced very
> consistently). My question is, is the PHASEMIS being brought high by a
> device on the SCSI bus, or by the card itself? In other words, would I
> get the same fault with a different card, or is this 1505 specific?
>
> Is it even correct to kernel panic if PHASEMIS goes high during a cmnd
> write? I would have thought that though it indicates a failure, surely
> it's not so bad that the system should hang. I don't see similar panic
> code for any of the other SCSI controller drivers.
>
> As I've said in previous posts, I don't think this is a termination or
> hardware problem. The same gear works great in Windows 95, though I am
> aware this isn't proof positive of OK gear, but I've gone over it with
> a fine toothed comb, changing cables and the like.
>
> I have subscribed myself to the linux-scsi mailing list and received a
> confirmation email, but I'm not seeing any traffic. Please CC: replies
> directly to me in addition to the mailing list, thank you.
>
> --
> Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
> Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
