[parisc-linux] New scsi driver for 53c700 and 53c710 committed

[parisc-linux] New scsi driver for 53c700 and 53c710 committed

[Richard Hirst]

Hi,
  I've just added a new scsi driver for 53c700 and 53c710 chips to cvs.
This driver was written by James Bottomley for MCA machines, and has
been enhanced to support parisc as well.  It is intended that the
previous driver, sim700.c, will be removed once we are happy with
the new one.  The new one is 53c700.* plus lasi700.*.  I have left
the old driver in the source for the time being, but have commented out
its config question in drivers/scsi/Config.in. The CONFIG_ flag has
changed from CONFIG_SCSI_LASI to CONFIG_SCSI_LASI700.
You should certainly do at least a 'make oldconfig' once you pick up
these changes.

The main improvements in this driver are sync transfers (where the scsi
chip allows it) and tagged commands.  Also disconenct/reselect works
properly, so there is no longer any need to boot with sim700=nodisc:0xff
(or similar).

James and I have tested the driver on 712, 715/50, 715/75, B180, and
C360.  I have tested C360 with 32 and 64 bit kernels.

Please test this new drvier with your hardware and report back, if
I don't hear anything bad, the old driver will be removed.

Thanks,
  Richard

Re: [parisc-linux] New scsi driver for 53c700 and 53c710 committed

[Daniel Engstrom]

Hi, Richard.

On 2001.10.09 00:09 Richard Hirst wrote:
>   I've just added a new scsi driver for 53c700 and 53c710 chips to cvs.

I have some problems with this driver on my 715-50/old installed from the 
0.92 cd.

If I boot multi-user the boot process will stop/hang somewhere between the
"ENtering run level 2" message and "Starting cron"-message. The cont-message
is pretty late in the boot process, infact it is the last message to be printed
before the getty's are supposed to be lanuched.

On the next reboot fsck will consider the filesystem broken enought to put me
in single user mode.

If I boot single-user I can get to the prompt and do some reading and writing 
to the disk,  but if I do some heavy disk I/O (like running bonnie or e2fsck 
on a dirty file system), the system will lock-up.

The lockup I experience is not complete, the box still replies to pings and
anything I type at the (serial) console gets echoed, but I get nowhere with
ctrl-C or wha-tever. 

The old driver still works even with the never kernels.

/Daniel

-- 

Re: [parisc-linux] New scsi driver for 53c700 and 53c710 committed

[Richard Hirst]

On Sat, Oct 13, 2001 at 11:32:16PM +0200, Daniel Engstrom wrote:
> 
> Hi, Richard.
> 
> On 2001.10.09 00:09 Richard Hirst wrote:
> >   I've just added a new scsi driver for 53c700 and 53c710 chips to cvs.
> 
> I have some problems with this driver on my 715-50/old installed from the 
> 0.92 cd.

We've had one problem report so far that was fixed by adding a scsi
terminator.  The new driver runs fast sync scsi transfers, while the
old one ran slower async.  Poorly terminated scsi busses are much more
likely to fail with the new driver.  James Bottomley posted a patch to
disable sync transfers a few days ago, could you try that and see if
it helps?  Also let us know what you system has by way of scsi termination.

Thanks,
  Richard

Re: [parisc-linux] New scsi driver for 53c700 and 53c710 committed

[Daniel Engstrom]

> > I have some problems with this driver on my 715-50/old installed from the 
> > 0.92 cd.
> 
> We've had one problem report so far that was fixed by adding a scsi
> terminator. 
Well I have terminators at both ends, the external one is an active terminator 
and the internal on is the original HP part. 
I also tried to remov the external CD from the bus to day but it had no effect.

> The new driver runs fast sync scsi transfers, while the old one ran slower
> async. 
The 715 i have have a vanilla 53c700 chip and as far as I can tell this chip 
supports only async transfers. The driver will not enable sync tranfers unless 
you have at least a 53c700-66 device.

> Poorly terminated scsi busses are much more likely to fail with the new driver.  
> James Bottomley posted a patch to disable sync transfers a few days ago, 
> could you try that and see if it helps?  
This patch will only disable sync transfers if you have a 53c710, I changed it to
disable sync tranfsers regardless of the chip in question. It did not make things 
any  better, though (as one would expect considering the capabilities of my chip). 

> Also let us know what you system has by way of scsi termination.
See above. I have two 3G Quantum drives on the bus and until today I had a dual speed
Toshiba CDROM in an external enclosure.

I have enabled debugging in the 53c700 driver, whith this debugging the driver seems 
to stay alive longer that without debuging. Infact it has yet to lockup after running 
bonnie for 18 minutes (I booted an nfs root and mounted the scsi disk maunaly). I guess
the debuging printk's removed the lockup. I just rebooted in to the nfs root with a new 
kernel where the only change is the removal of the debug output, and this kernel dies after
a while (~10min) running bonnie. Please advise. :)

/Daniel

-- 

Re: [parisc-linux] New scsi driver for 53c700 and 53c710 committed

[Richard Hirst]

On Wed, Oct 17, 2001 at 12:08:33AM +0200, Daniel Engstrom wrote:
> 
> > > I have some problems with this driver on my 715-50/old installed from the 
> > > 0.92 cd.
> > 
> > We've had one problem report so far that was fixed by adding a scsi
> > terminator. 
> Well I have terminators at both ends, the external one is an active terminator 
> and the internal on is the original HP part. 
> I also tried to remov the external CD from the bus to day but it had no effect.
> 
> > The new driver runs fast sync scsi transfers, while the old one ran slower
> > async. 
> The 715 i have have a vanilla 53c700 chip and as far as I can tell this chip 
> supports only async transfers. The driver will not enable sync tranfers unless 
> you have at least a 53c700-66 device.

Yes, I think you are right there.

> > Also let us know what you system has by way of scsi termination.
> See above. I have two 3G Quantum drives on the bus and until today I had a dual speed
> Toshiba CDROM in an external enclosure.
> 
> I have enabled debugging in the 53c700 driver, whith this debugging the driver seems 
> to stay alive longer that without debuging. Infact it has yet to lockup after running 
> bonnie for 18 minutes (I booted an nfs root and mounted the scsi disk maunaly). I guess
> the debuging printk's removed the lockup. I just rebooted in to the nfs root with a new 
> kernel where the only change is the removal of the debug output, and this kernel dies after
> a while (~10min) running bonnie. Please advise. :)

I don't think 18 mins with no lockup against 10 mins with lockup is
conclusive really, given that the debugging will have slowed things
down considerably.  How long have you run bonnie for with the old
driver?  I'd like to see that run for say 1 hour without lockups
before we assumed the new driver was causing a problem.

When it fails, I'd expect the scsi layer to time out any active
commands and retry.  Is there any evidence of it doing that, or
is there no console output at all?

Richard

Re: [parisc-linux] New scsi driver for 53c700 and 53c710 committed

[James Bottomley]

This one looks like it might be the second new feature of the driver: tag 
command queuing.

Could you post the boot messages of the failure case (or at least the device 
identifications and whether the driver has enabled TCQ [message like scsi1: 
(5:0) Enabling Tag Command Queuing)].

Thanks,

James

Re: [parisc-linux] New scsi driver for 53c700 and 53c710 committed

[Daniel Engstrom]

On 2001.10.17 16:19 James Bottomley wrote:
> This one looks like it might be the second new feature of the driver: tag 
> command queuing.
> 
> Could you post the boot messages of the failure case (or at least the device 
> identifications and whether the driver has enabled TCQ [message like scsi1: 
> (5:0) Enabling Tag Command Queuing)].
They do, see below.

/Daniel

SCSI subsystem driver Revision: 1.00
53c700: consistent memory allocation failed
53c700: Version 2.6 By James.Bottomley@HansenPartnership.com
scsi0: 53c700 rev 0 
scsi0 : LASI SCSI 53c700
  Vendor: QUANTUM   Model: FIREBALL_TM3200S  Rev: 300X
  Type:   Direct-Access                      ANSI SCSI revision: 02
  Vendor: QUANTUM   Model: FIREBALL ST3.2S   Rev: 0F0C
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 5, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0
scsi0: (5:0) Enabling Tag Command Queuing
SCSI device sda: 6281856 512-byte hdwr sectors (3216 MB)
Partition check:
 sda: sda1 sda2 sda3 sda4
scsi0: (6:0) Enabling Tag Command Queuing
SCSI device sdb: 6328861 512-byte hdwr sectors (3240 MB)
 sdb: unknown partition table
-- 

Re: [parisc-linux] New scsi driver for 53c700 and 53c710 committed

[Daniel Engstrom]

On 2001.10.17 11:56 Richard Hirst wrote:
 
> I don't think 18 mins with no lockup against 10 mins with lockup is
> conclusive really, given that the debugging will have slowed things
> down considerably. 
 
Yes, you have a point. But I want to mention that after the bonnie-runI
also ran a e2fsck on my root filesystem while it was dirty and it finnished
which it had never done with the new driver w/o the debug-output.

> How long have you run bonnie for with the old
> driver?  I'd like to see that run for say 1 hour without lockups
> before we assumed the new driver was causing a problem.
I have done three runs in a row with 100Mb data, I dont know how long this takes, 
but say almost an hour.

> When it fails, I'd expect the scsi layer to time out any active
> commands and retry.  Is there any evidence of it doing that, or
> is there no console output at all?
No output at all. Interrupts still work; the box answers pings and echoes the 
console input, but nothing else works.


/Daniel
--