Subject: Powertec scsi-II with a quantum harddisk

From: Jan Magnussen <[email-masked]>
Date: Sat, 07 Nov 1998 16:28:25 +0100

I have been trying to get the Powertec drivers working with my Quantum
Fireball ST4.3S harddisk, but when I boot the kernel with ptec support
compiled in, then the kernel goes into a "loop", when the scsi-driver is
initialising, saying something like "scsi-bus reset detected" over and over
again. Exact messages can be provided if nessecary.

I think that Quantum harddisks are generally a problem for the ptec card, as
the newer versions of the driver for Riscos crashes completely if a Quantum
og Iomega device is present on the bus. The RiscBSD version of the driver
should be working flawlessly.

Regards,
-- 
Jan Magnussen
http://www.control.auc.dk/~janm
Fidonet 2:234/181.8
dawn chorus(n): Nature's way of telling the programmer to go to sleep.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Stefan Voss <[email-masked]>
Date: Sun, 08 Nov 1998 09:26:04 +0100

> again. Exact messages can be provided if nessecary.

Try to compile a kernel where ptec support is compiled as module and use
"term=0" as insmod parameter. This works for me.

> [snip]

Regards,
   Stefan
   
-- 
Stefan Voss
([email-masked])

Slam a revolving door today!
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Jan Magnussen <[email-masked]>
Date: Mon, 09 Nov 1998 04:00:04 +0100

In message <[email-masked]>

> "term=0" as insmod parameter. This works for me.

hmmm. Same result. The driver works if I disconnect the Quantum drive, but I
have to use this disc, so removing it is not an option.

Regards,
-- 
Jan Magnussen
http://www.control.auc.dk/~janm
Fidonet 2:234/181.8
"640K ought to be enough for anybody." - Bill Gates, 1981

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 9 Nov 1998 22:59:11 +0000 (GMT)

> have to use this disc, so removing it is not an option.

What exactly is this Quantum drive (model number, s/w revision etc).  RISC OS
*devices line will do.

I could (soonish) try my Quantum Fireball 1GB on the PTEC, but I think it'll
be ok.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Jan Magnussen <[email-masked]>
Date: Wed, 11 Nov 1998 02:41:20 +0100

In message <[email-masked]>

> What exactly is this Quantum drive (model number, s/w revision etc).  RISC OS

Device Type              Capacity    Vendor   Product          Rev  Level
3      Direct Access        4 GBytes QUANTUM  FIREBALL ST4.3S  0F0C SCSI-2

> I could (soonish) try my Quantum Fireball 1GB on the PTEC, but I think it'll

Actually. I have been talking to Alsystems, and they say, that it is a
general problem with all Quantum disks, which they are currently looking into
it. They also claim that Iomega SCSI devices have the same problem.

Regards,
-- 
Jan Magnussen
http://www.control.auc.dk/~janm
Fidonet 2:234/181.8
2 + 2 = 5 for extremely large values of 2.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 11 Nov 1998 21:35:47 +0000 (GMT)

> it. They also claim that Iomega SCSI devices have the same problem.

I've just tried my Quantum drive on the PTEC SCSI card, and it seems to work
fine:

  Vendor: QUANTUM   Model: FIREBALL1080S     Rev: 1Q09
  Type:   Direct-Access                      ANSI SCSI revision: 02

I therefore will require the exact messages that the SCSI driver issues.
Would it be possible for you to do some debugging?  I can let you know
exactly what to do.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Jan Magnussen <[email-masked]>
Date: Sat, 14 Nov 1998 21:33:01 +0100

In message <[email-masked]>

>   Type:   Direct-Access                      ANSI SCSI revision: 02

Hmmm. Strange !!??!!

> I therefore will require the exact messages that the SCSI driver issues.

OK. Here is exactly what the SCSI driver issues. There MAY be small errors,
as it is all written onto paper, and then written here.

scsi0.H: bus reset detected
scsi0 : Powertec SCSI at Port 800D1000 irq 33 dma 3 v0.0.2 scsi NCR53C9x terminators on
scsi : 1 host.
scsi0.3: bus phase MESG IN after command?
scsi : aborting command due to timeout : pid 3, scsi 0, channel 0, id 3, lun 0 Request Sense 00 00 00 10 00
FAS216: CTCL=00 CTCM=00 CMD=00 STAT=07 INST=00 IS=89 CFIS=20 CNTL1=07 CNTL2=48 CNTL3=B8 CTCH=00
FAS216_Info=
  { magic_Start=441296BD host=C2776018 SCput=C2775018 origSCput=00000000
    scsi={ io_port=800D1C00 io_shift=4 irq=21 cfg={ 7 48 B8 0 }
           type=c38a0c058 phase=3 reconnected={ target=3 lun=0 tag=0 }
           SCp={ ptr=c27860a0 this_residual=10 buffer=00000000 buffers_residual=0 }
      msgs async_stp=8 disconnectable=0 aborting=0 }
    stats={ queues=5 removes=5 fins=4 reads=0 writes=0 miscs=5
            disconnects=1 aborts=1 resets=1 }
    ifcfg={ clockrate=28 select_timeout=FF asyncperiod=C8 sync_max_depth=73 }
    busyluns[0]=0 dev[0]={ disconnect_ok=1 stp=8 sof=0 sync_state=0 }
    busyluns[1]=0 dev[1]={ disconnect_ok=1 stp=8 sof=0 sync_state=0 }
    busyluns[2]=0 dev[2]={ disconnect_ok=1 stp=8 sof=0 sync_state=0 }
    busyluns[3]=1 dev[3]={ disconnect_ok=1 stp=4 sof=7 sync_state=2 }
    busyluns[4]=0 dev[4]={ disconnect_ok=1 stp=8 sof=0 sync_state=0 }
    busyluns[5]=0 dev[5]={ disconnect_ok=1 stp=8 sof=0 sync_state=0 }
    busyluns[6]=0 dev[6]={ disconnect_ok=1 stp=8 sof=0 sync_state=0 }
    busyluns[7]=0 dev[7]={ disconnect_ok=1 stp=8 sof=0 sync_state=0 }
    dma={ transfer_type=0 setup=c389c148 pseudo=00000000 stop=c389c254 }
    internal_done=0 magic_end=441296BD }
scsi0: fas216_abort: command executing
SCSI host 0 abort (pid 3) timed out - resetting
SCSI bus is being reset for host 0 channel 0
SCSI IRQ trail: 82:C9:10:8 87:89:10:3 80:c0:80:3 8C:51:18:1 87:81:10:A 87:81:08:8 82:C9:10:8 87:89:10:3
FAS216: CTCL=00 CTCM=00 CMD=00 STAT=07 INST=00 IS=89 CFIS=20 CNTL1=07 CNTL2=48 CNTL3=B8 CTCH=00

Then the last 5 lines are repeating in an infinite loop.

The values host and SCput vary every time the module is loaded.

> Would it be possible for you to do some debugging?  I can let you know

OK. Just say what to do.

Regards,