New scsi driver for 53c700 and 53c710 committed

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

Hi, Richard.

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

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

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 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.

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).

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

Yes, I think you are right there.

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

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

They do, see below.

/Daniel

SCSI subsystem driver Revision: 1.00
53c700: consistent memory allocation failed 53c700: Version 2.6 By [email protected]
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

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.

I have done three runs in a row with 100Mb data, I dont know how long this takes, but say almost an hour.

No output at all. Interrupts still work; the box answers pings and echoes the console input, but nothing else works.

/Daniel