Hello,
I already replied to your problem, but perhaps I have been unclear:
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: phase change 2-6
> 6@002ffe45 resid=5.
The driver reports that the SCSI device did switch from COMMAND PHASE to
MESSAGE OUT phase, for a 6 bytes command, after having accepted the 1rst
byte of the command.
Such a behaviour does not look like a possible behaviour to me, since
there is no reason the driver asked the device for a MESSAGE OUT phase (by
asserting SATN) during a command phase. The chip asserts SATN when it
detects a parity error during an INPUT phase and COMMAND phase is an
_OUTPUT_ phase.
On the other hand, there is no valuable reason for the device to switch to
another phase after having read 1 byte of command, unless it is just
seeing wrong signals (control signal or data) on the SCSI BUS.
This let me think that:
- Either the firmware of your SCSI device does not change SCSI control
signals in an orderly manner (some bug in the firmware).
- Or you BUS path is broken.
- Or some SCSI hardware on your system is broken (tranceiver, etc ...).
If it is the BUS path that is broken, then it may be that some control
signal has problems. The SATN signal is candidate, both not only this
one.
My recommendation is to check the SCSI BUS path and all the connections to
devices (connectors too). Giving a try with another cable, may help too.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: unexpected disconnect
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: COMMAND FAILED (8a
> ff) @c3fe7000.
The UNEXPECTED disconnection is very probably the consequence of the
previous problem.
You also may want to give a try with latest sym driver 1.5c:
ftp:/ftp.tux.org/pub/roudier/drivers/README-drivers-linux
-------------------------------------------------
SYM53C8XX and NCR53C8XX drivers for Linux updates
-------------------------------------------------
Last modified on June 6 1999.
This README file originates from the following URL:
ftp://ftp.tux.org/pub/roudier/README-drivers-linux
The tree 'ftp://ftp.tux.org/pub/roudier/' is maintained by:
"G�rard Roudier" [EMAIL PROTECTED]
Here is a brief description of the files available at this location:
1. Incremental patches for common kernel versions:
./drivers/linux/sym53c8xx/
README
<files of the pattern patch-53c8xx-vvv-sss-kkk.gz>
The README file is here to help you.
2. Latest driver version diffs against the latest kernels we have had time
to have a look at.
./drivers/linux/experimental/
patch-53c8xx-1.5c-2.0.36.gz
patch-53c8xx-1.5c-2.0.37-pre12.gz
patch-53c8xx-1.5c-2.2.5.gz
patch-53c8xx-1.5c-2.2.9.gz (for 2.2.9 up to 2.3.3 kernels)
3. Driver versions assumed stable.
./drivers/linux/stable/
patch-53c8xx-1.4-2.0.36.gz
patch-53c8xx-1.4-2.0.36-pristine.gz
patch-53c8xx-1.3f-2.2.5.gz
patch-53c8xx-1.3f-2.2.7.gz (for 2.2.7 up to 2.2.9 kernels)
Regards,
G�rard.
On Sat, 12 Jun 1999, DMW wrote:
> Hi everyone --
>
> I had posted a problem a week ago or so about a new Tekram DC 310 scsi
> controller (uses the sym53c810 chip) that I'm trying to get working.
> Well, I think I've gotten a little further, but I'm still unsuccessful
> at getting everything working.
>
> The situation is, I have a Pentium-based Redhat 6 system, with a fresh
> 2.3.5 kernel. I just re-built the kernel with support (not modular) for
> the sym53c8xx and ncr53c8xx. The only scsi device I have is a Umax
> scanner...it has ID 1. The controller is ID 0. Sound simple enough?
>
> Still, I get some errors during the boot process that I can't decipher.
> Take a look:
>
> Jun 11 20:18:19 localhost kernel: sym53c8xx: at PCI bus 0, device 12,
> function 0
> Jun 11 20:18:19 localhost kernel: sym53c8xx: setting
> PCI_COMMAND_PARITY...(fix-up)
> Jun 11 20:18:19 localhost kernel: sym53c8xx: 53c810a detected with
> Symbios NVRAM
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: rev=0x23,
> base=0xdf800000, io_port=0xd000, irq=4
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: Symbios format NVRAM, ID
> 0, Fast-10, Parity Checking
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: initial
> SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 03/ce/a0/01/00/00
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: final
> SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 03/ce/a0/00/08/00
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: resetting, command
> processing suspended for 2 seconds
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: restart (scsi reset).
> Jun 11 20:18:19 localhost kernel: ncr53c8xx: at PCI bus 0, device 12,
> function 0
> Jun 11 20:18:19 localhost kernel: ncr53c8xx: IO region 0xd000 to 0xd07f
> is in use
> Jun 11 20:18:19 localhost kernel: scsi0 : sym53c8xx - version 1.3c
> Jun 11 20:18:19 localhost kernel: scsi : 1 host.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: command processing
> resumed
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: phase change 2-6
> 6@002ffe45 resid=5.
> Jun 11 20:18:19 localhost atd: atd startup succeeded
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: unexpected disconnect
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: COMMAND FAILED (8a
> ff) @c3fe7000.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: phase change 2-6
> 6@002ffe45 resid=5.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: unexpected disconnect
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: COMMAND FAILED (8a
> ff) @c3fe7000.
> Jun 11 20:18:19 localhost kernel: scsi0 channel 0 : resetting for second
> half of retries.
> Jun 11 20:18:19 localhost kernel: SCSI bus is being reset for host 0
> channel 0.
> Jun 11 20:18:19 localhost kernel: sym53c8xx_reset: pid=1 reset_flags=1
> serial_number=0 serial_number_at_timeout=0
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: resetting, command
> processing suspended for 2 seconds
> Jun 11 20:18:19 localhost kernel: scsi0: device driver called
> scsi_done() for a syncronous reset.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: restart (scsi reset).
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: command processing
> resumed
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: phase change 2-6
> 6@002ffe45 resid=5.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: unexpected disconnect
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: COMMAND FAILED (8a
> ff) @c3fe7000.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: phase change 2-6
> 6@002ffe45 resid=5.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: unexpected disconnect
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: COMMAND FAILED (8a
> ff) @c3fe7000.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: phase change 2-6
> 6@002ffe45 resid=5.
> Jun 11 20:18:19 localhost kernel: sym53c810a-0: unexpected disconnect
> Jun 11 20:18:19 localhost kernel: sym53c810a-0-<1,0>: COMMAND FAILED (8a
> ff) @c3fe7000.
> Jun 11 20:18:19 localhost kernel: scsi : detected
> total.
>
>
> I don't know if these messages are good, bad, or just ugly. I do know
> that when I do a "cat /proc/scsi/scsi" I get a "Attached devices:
> none". I guess that means it can't see the scanner. I do have the
> scanner powered up before booting.
>
> Like I said, the only scsi devices are the scanner, which I know is
> terminated, and the host adapter. So what could the problem be?
>
> Please help! Getting desparate and growing old.
>
> derek
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
