SCSI -rc1 fixes

This is my first set of -rc fixes for SCSI. The patch is available at

bk://linux-scsi.bkbits.net/scsi-for-linus-2.6

The short changelog is:

Adam J. Richter:
o dmx3191d.c lacked MODULE_DEVICE_TABLE()

Alan Stern:
o SCSI core: Fix refcounting error

Andrew Vasquez:
o SCSI: fix `risc_code_addr01' multiple definition

James Bottomley:
o make osst compile again after st structure changes

Jan Dittmer:
o aic7xxx remove warnings

Jens Axboe:
o fix SCSI bounce limit

Kai Mäkisara:
o SCSI tape: remove remaining typedefs

Matthew Wilcox:
o sym2 2.1.18m

Maximilian Attems:
o scsi/scsi_lib: replace schedule_timeout() with
o scsi/53c700: replace schedule_timeout() with

Randy Dunlap:
o qla1280: driver_setup not __initdata

Sergey S. Kostyliov:
o Add megaraid PCI IDs

And the diffstat

 Documentation/scsi/sym53c8xx_2.txt    |  360 +++++++++++-------------------
 drivers/scsi/53c700.c                 |    2 
 drivers/scsi/aic7xxx/aic7xxx_osm.c    |    4 
 drivers/scsi/dmx3191d.c               |    1 
 drivers/scsi/megaraid/megaraid_mbox.c |    6 
 drivers/scsi/osst.c                   |   55 ++--
 drivers/scsi/osst.h                   |    4 
 drivers/scsi/qla1280.c                |    2 
 drivers/scsi/qlogicfc_asm.c           |   10 
 drivers/scsi/scsi_lib.c               |   18 -
 drivers/scsi/scsi_scan.c              |    3 
 drivers/scsi/scsi_sysfs.c             |    2 
 drivers/scsi/st.c                     |  221 +++++++++---------
 drivers/scsi/st.h                     |   20 -
 drivers/scsi/sym53c8xx_2/sym53c8xx.h  |   47 ----
 drivers/scsi/sym53c8xx_2/sym_defs.h   |  100 ++++----
 drivers/scsi/sym53c8xx_2/sym_glue.c   |  396 +++++++++++++---------------------
 drivers/scsi/sym53c8xx_2/sym_glue.h   |    3 
 drivers/scsi/sym53c8xx_2/sym_hipd.c   |  100 +++-----
 drivers/scsi/sym53c8xx_2/sym_misc.c   |    4 
 20 files changed, 569 insertions(+), 789 deletions(-)

James

thankyou thankyou :)

I've only been away for *two* weeks .... that's not a very long time compared with a linux kernel -rc cycle ...

James

With like 2,400 change sets since v2.6.9...

Still wondering about SuSE's hwscan issue. Has someone managed to figure if it uses some ioctl that chokes the sym2 driver or if it hacks the hardware?

Matthias Andree

Well, I think we're stuck on that one. SUSE doesn't seem willing to debug hwscan enough to give a coherent description of the problem or a non hwscan test case and no-one else wants to take hwscan apart to find out exactly what it is doing.

James

I'm CC:ing Steffen Winterfeldt of hwinfo fame, in the hopes that he might know his child is doing (if not, he might want to look), and I've taken linux-kernel from the Cc: list.

He's listed as author and packager of this insufficiently documented piece of s...ymbios adaptor confusion.

Steffen, SuSE's hwinfo package throws parity errors on SYM53C8xx hardware. Same issue with all kernels SuSE shipped for 9.1 including the current 2.6.5-7.111 kernel as well as vanilla 2.6.9. hwinfo-8.62-0.2. hotplugctl-0.08-256 - yet another undocumented piece of who-knows-what-its-good-for.

Common trouble introduced by running yast2 or hwinfo is SCSI parity error, phase mismatch, bus reset and sometimes the machine going out to lunch for 2 minutes. It is unclear whether hwinfo probes the hardware directly, confusing the sym53c8xx, or uses some SCSI ioctl that confuses the adaptor. Please help finding _this_ out and if it's hwinfo hacking PCI registers directly, don't do that on ncr/sym/lsi53c8xx and 53c1010 chips.

Some hotplug event on SuSE 9.1 is apparently sufficient to throw the whole backup over - Tandberg SLR2 and SLR4 drives, although rock solid otherwise, strongly dislike bus resets, request sense and the st driver propagates an error. Amanda doesn't like that and aborts the dump...

The logs below look as though inserting the floppy driver caused my tape backup to go failing THIS TIME. Running yast2 while a backup is running is fatal for the backup, this isn't related to the floppy driver.

I will help debug this if needed, but need directions. If you need some hardware, get a Tekram DC-390U or DC-390F or DC-310U and some devices that make some noise after a bus reset.

Tandberg SLR6/SLR24 make a horrible noise as part of their reset self test %-)

Log excerpt below, I stripped the timestamps, everything happens within 7 seconds, Vanilla 2.6.9 kernel. Blank lines inserted to make the interesting parts stand out.

...
kernel: sr0: scsi-1 drive
kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0
kernel: inserting floppy driver for 2.6.9
kernel: Floppy drive(s): fd0 is 1.44M
kernel: FDC 0 is a post-1991 82077

/sbin/hotplug[23123]: add block
/sbin/hotplug[23129]: add block
/sbin/hotplug[23130]: add platform
/sbin/hotplug[23123]: LOGPID=23123 OLDPWD=/ DEVPATH=/block/sr0 PATH=/sbin:/usr/sbin:/bin:/usr/bin ACTION=add PWD=/etc/hotplug SHLVL=1 HOME=/ SEQNUM=516 _=/usr/bin/env /sbin/hotplug[23129]: LOGPID=23129 OLDPWD=/ DEVPATH=/block/fd0 PATH=/sbin:/usr/sbin:/bin:/usr/bin ACTION=add PWD=/etc/hotplug SHLVL=1 HOME=/ SEQNUM=517 _=/usr/bin/env /sbin/hotplug[23130]: LOGPID=23130 OLDPWD=/ DEVPATH=/devices/platform/floppy0 PATH=/sbin:/usr/sbin:/bin:/usr/bin ACTION=add PWD=/etc/hotplug SHLVL=1 HOME=/ SEQNUM=518 _=/usr/bin/env /etc/hotplug/block.agent[23129]: try 1 while waiting for /block/fd0's bus_id
/etc/hotplug/block.agent[23123]: 0:0:2:0: page 0 not available.
/etc/hotplug/block.agent[23123]: line P: /block/sr0
/etc/hotplug/block.agent[23123]: line N: sr0
/etc/hotplug/block.agent[23123]: ncookie sr0
/etc/hotplug/block.agent[23123]: line M: 0640
/etc/hotplug/block.agent[23123]: line S: by-path/pci-0000:00:0d.0-scsi-0:0:2:0
/etc/hotplug/block.agent[23123]: scookie by-path/pci-0000:00:0d.0-scsi-0:0:2:0
/etc/hotplug/block.agent[23123]: line O: root
/etc/hotplug/block.agent[23123]: line G: disk
/etc/hotplug/block.agent[23123]: line
/etc/hotplug/block.agent[23123]: new block device /block/sr0
/etc/hotplug/block.agent[23129]: try 2 while waiting for /block/fd0's bus_id
/etc/hotplug/block.agent[23129]: try 3 while waiting for /block/fd0's bus_id
/etc/hotplug/block.agent[23129]: try 4 while waiting for /block/fd0's bus_id

kernel: sym0: SCSI parity error detected: SCR1=3 DBC=50000000 SBCL=0
kernel: sym0: SCSI phase error fixup: CCB already dequeued.
kernel: sym0: SCSI BUS reset detected.
kernel: sym0: SCSI BUS has been reset.
kernel: st0: Error 80000 (sugg. bt 0x0, driver bt 0x0, host bt 0x8).

/etc/hotplug/block.agent[23129]: try 5 while waiting for /block/fd0's bus_id
/etc/hotplug/block.agent[23129]: line P: /block/fd0
/etc/hotplug/block.agent[23129]: line N: fd0
/etc/hotplug/block.agent[23129]: ncookie fd0
/etc/hotplug/block.agent[23129]: line M: 0660
/etc/hotplug/block.agent[23129]: line S:
/etc/hotplug/block.agent[23129]: line O: root
/etc/hotplug/block.agent[23129]: line G: disk
/etc/hotplug/block.agent[23129]: line
/etc/hotplug/block.agent[23129]: new block device /block/fd0
/sbin/hotplug[23130]: no runnable /etc/hotplug/platform.agent is installed
kernel: program hwscan is using a deprecated SCSI ioctl, please convert it to SG_IO
/sbin/hotplug[23234]: add scsi_generic
/sbin/hotplug[23234]: LOGPID=23234 OLDPWD=/ DEVPATH=/class/scsi_generic/sg0 PATH=/sbin:/usr/sbin:/bin:/usr/bin ACTION=add PWD=/etc/hotplug SHLVL=1 HOME=/ SEQNUM=519 _=/usr/bin/env
kernel: Attached scsi generic sg0 at scsi0, channel 0, id 1, lun 0, type 0
/sbin/hotplug[23243]: add scsi_generic
kernel: Attached scsi generic sg1 at scsi0, channel 0, id 2, lun 0, type 5
/sbin/hotplug[23251]: add scsi_generic
/sbin/hotplug[23251]: LOGPID=23251 OLDPWD=/ DEVPATH=/class/scsi_generic/sg2 PATH=/sbin:/usr/sbin:/bin:/usr/bin ACTION=add PWD=/etc/hotplug SHLVL=1 HOME=/ SEQNUM=521 _=/usr/bin/env
kernel: Attached scsi generic sg2 at scsi0, channel 0, id 6, lun 0, type 1
/sbin/hotplug[23260]: add scsi_generic
/sbin/hotplug[23260]: LOGPID=23260 OLDPWD=/ DEVPATH=/class/scsi_generic/sg3 PATH=/sbin:/usr/sbin:/bin:/usr/bin ACTION=add PWD=/etc/hotplug SHLVL=1 HOME=/ SEQNUM=522 _=/usr/bin/env

kernel: st0: Error with sense data: Current st0: sense key Unit Attention
kernel: Additional sense: Power on, reset, or bus device reset occurred
kernel: st0: Error on write filemark.

Boom, it's dead.

Matthias Andree

Sorry for the late response; I'm just back from vacation.

hwinfo is just a normal program and doesn't do any special tricks on hardware. In particular, it issues an scsi inquiry command to get the serial number, but that's about all.

If running just hwinfo breaks things for you, you might try running it through strace and look at the files it accesses. Maybe that gives some hint to narrow things down.

Steffen

hwinfo needs to be updated to use SG_IO, there are too many things that can go wrong with SCSI_IOCTL_SEND_COMMAND (it's far too easy to confuse the device or adapter).

Jens Axboe

Well, it already has. But I don't think this is the problem here.

Steffen

It has? Great! It could have been the problem if the data phases are interpreted incorrectly.

The other possible problem is that the command issued could be incorrect. Steffan, care to paste the build of the sg_io_hdr_t here?

Jens Axboe

You got me wrong. It has in SL 9.2 but this is about SL 9.1, if I understand correctly.

Anyway, to see whether this really matters, run

hwprobe=+scsi.noserial hwinfo

and see if it makes a difference. Or try hwinfo from SL 9.2.

Steffen

I'd rather see the latter. Can you post a link where it can be reached publically?

Jens Axboe

Steffen Winterfeldt <[email protected]> writes:

[Context: SuSE's hwscan --pci and lspci -xxx trigger SCSI parity errors on reading /sys/devices/pci*/*/config of sym53c8xx devices, possibly including phase fixup, a non-working abort loop of up to 2 minutes that ends in a SCSI bus reset that fixes it, details below]

[dropping Andrew and Linus from the Cc:, adding Matthew Wilcox instead I
think if it's a kernel issue, this can be propagated by the SCSI or SYM53C8XX maintainers]

I found a minimal way to reproduce the problem:

(adjust bus and device no. as appropriate, try: /sbin/lspci | grep 53c8):

cd /sys/devices/pci0000:00/0000:00:0d.0
dd if=config bs=1 count=1 of=/dev/null skip=216

hwscan or lspci -xxx reads all of the config file (256 bytes) which includes this byte, lspci without -xxx reads selectively the first 68 bytes in several stages and avoids this (except lspci -xxx which also triggers the parity error as it reads the whole 256 bytes).

So it looks as though the byte at offset 216 in /sys/devices/pci0000:00/0000:00:0d.0/config was "poisonous" for reading somehow. I haven't dared to write there.

I wonder if hwscan should (and needs to) read the whole config space or can go along with less, as lspci does.

Questions:

1. is it necessary that hwscan reads the whole configuration space?

2. is it a kernel bug if reading offset #216 (byte-wise) in the config file in sysfs confuses the hardware?

3. both?

Matthias Andree

[...]

No, it isn't.

Just checked and it looks like though hwinfo itself is careful to read just the first 64 bytes + capability list, some libsysfs call reads the config completely.

I'll look at it closer.

It's IMO a hardware problem. We've seen this in past (with symbios cards, IIRC).

Steffen

Aha, this is wonderful.

*nod*. The manpage does warn about this:

-xxx Show hexadecimal dump of whole PCI configuration space. Avail-
able only for root as several PCI devices crash when you try to read undefined portions of the config space (this behaviour probably doesn't violate the PCI standard, but it's at least very stupid).

I can reproduce this on my sym53c810:

sym0: SCSI parity error detected: SCR1=132 DBC=50000000 SBCL=0
sym0: SCSI parity error detected: SCR1=3 DBC=50000000 SBCL=0 sym0:1:0:M_REJECT received (0:8).

Aha. Now I see this note in the 810a docs:

The lower 128 bytes hold configuration data while the upper 128 bytes hold the LSI53C810A operating registers, which are described in Chapter 5, "Operating Registers." The operating registers can be accessed by SCRIPTS or the host processor.

So you're actually reading the SBDL (SCSI Bus Data Lines) register. I guess it shouldn't surprise us too much that this causes parity errors when we read that:

The signal status is not latched and is a true representation of exactly what is on the data bus at the time the register is read. This register is used when receiving data using programmed I/O. This register can also be used for diagnostic testing or in low level mode.

No. hwscan should use libpci rather than accessing the pci space itself.

No, but it does seem to me that we could do better. Unfortunately, the obvious thing to do (set the file size to less than 256 bytes) isn't really possible in sysfs. But we could use the 'undocumented feature' in drivers/pci/pci-sysfs.c:pci_read_config() of setting the pci_dev's cfg_size to 128 bytes. This would prevent even root from reading more than 128 bytes. That'd be OK -- there's no *PCI* data in this range, even on the latest 1010/1030 controllers. The operating registers are exposed in the 0x80-0xFF range only up to the 875; the 876 and later return only 0 in that range.

"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Indeed, this has annoyed me for around half a year. How did I know you'd like to see the triggering element? :-)

I'm relieved we know the cause now and can go fixing, and SuSE will be relieved to know that the vanilla kernel is part of the problem.

Right. I was checking for other way to trigger the parity error.

In 2.6.9, I'm getting a short read (only 64 bytes) if I try to read the .../config file as the user, but the full file as root.

Makes sense if we're stealing a data byte.

BTW, is it correct that the driver/hardware can go into an ABORT/ABORT timed-out loop like this (I stripped hostname and date)? This is still Linux-2.6.9, where only the bus reset gets this straight again?

12:35:30 sym0: SCSI parity error detected: SCR1=132 DBC=50000000 SBCL=0 12:36:03 sym0:1:0: ABORT operation started.
12:36:08 sym0:1:0: ABORT operation timed-out.
12:36:08 sym0:1:0: ABORT operation started.
12:36:13 sym0:1:0: ABORT operation timed-out.
12:36:13 sym0:1:0: ABORT operation started.
12:36:18 sym0:1:0: ABORT operation timed-out.
12:36:18 sym0:1:0: ABORT operation started.
12:36:23 sym0:1:0: ABORT operation timed-out.
12:36:23 sym0:1:0: DEVICE RESET operation started.
12:36:28 sym0:1:0: DEVICE RESET operation timed-out. 12:36:28 sym0:1:0: BUS RESET operation started.
12:36:28 sym0: SCSI BUS reset detected.
12:36:28 sym0: SCSI BUS has been reset.
12:36:28 sym0:1:0: BUS RESET operation complete.

Let me know if you have a patch. I'm not usually enthusiastic about getting the latest and greatest fixes now, but I'm really eager to try this.

Right, SYM53C875 and SYM53C860 here.

Matthias Andree

[hwinfo/hwscan reading 256 bytes of pci config space]

It was indeed libsysfs reading the config space accidentally when one (well, I) wouldn't expect it to do this.

If you want to try the fixed hwinfo package (hwinfo-8.70), it's here:

ftp://ftp.suse.com/pub/people/snwint/9.1/hwinfo/

Steffen

Steffen Winterfeldt schrieb am 2004-11-26:

Thanks.

We may need updated *udev* packages, too (at least for SuSE Linux 9.1).

The hwinfo-8.70-0.2 update alone doesn't appear to help, I still see parity errors and still see 256-byte reads from /sys/devices/pci0000:00/0000:00:0d.0/config (my SYM53C875's config space), strace below

I also see that libsysfs is in the "udev-021-36" RPM on my system and also on SuSE 9.2:

$ rpm -qf /usr/sbin/hwscan
hwinfo-8.70-0.2
$ ldd /usr/sbin/hwscan | awk '{print $3}' | xargs -tn1 rpm -qf
...(glibc, linker, gate and tls stripped)...
rpm -qf /usr/lib/libhd.so.8 
hwinfo-8.70-0.2
rpm -qf /lib/libsysfs.so.1 
udev-021-36

The kernel (vanilla 2.6.9) still begs that hwinfo be converted to SG_IO.

strace extract, relevant line marked with >

22602 lstat("/sys/bus/pci/drivers/sata_via/0000:00:0d.0", 0xbfffe85c) = -1 ENOENT (No such file or directory) 22602 lstat("/sys/bus/pci/drivers/serial/0000:00:0d.0", 0xbfffe85c) = -1 ENOENT (No such file or directory) 22602 lstat("/sys/bus/pci/drivers/sym53c8xx/0000:00:0d.0", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 22602 lstat("/sys/devices/pci0000:00/0000:00:0d.0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 22602 open("/sys/devices/pci0000:00/0000:00:0d.0", O_RDONLY|O_DIRECTORY) = 3
22602 getdents(3, /* 13 entries */, 4020) = 268
22602 lstat("/sys/devices/pci0000:00/0000:00:0d.0/host0", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 22602 lstat("/sys/devices/pci0000:00/0000:00:0d.0/config", {st_mode=S_IFREG|0644, st_size=256, ...}) = 0 22602 stat("/sys/devices/pci0000:00/0000:00:0d.0/config", {st_mode=S_IFREG|0644, st_size=256, ...}) = 0

22602 close(4) = 0

Full strace available upon request, expect around 60 kB bzip2ed or 2.5 MB uncompressed.

$ /sbin/lspci -s 0000:00:0d.0
0000:00:0d.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26)

Matthias Andree

[...]

They are from /sbin/raiddetect (same cause as in hwinfo - libsysfs usage).

That warning was introduced after SL 9.1 was finished.

Steffen

And also in the udev package... will we see an updated udev package for SL 9.1 and 9.2, perhaps as Driver or Vendor Update, so it can help at first install already? These SYM53C8XX adaptors are quite popular.

Yes indeed, but SG_IO has been around for ages - but as you'd written the SL 9.2 version had already been converted, this might be a good time to fix it for 9.1, too. The package needs to be patched anyways.

Matthias Andree

Have you had a look at this already? If not, how would I go about inplementing this?

Matthias Andree

Steffen,
I recently noticed that VPD page 0x80 (unit serial number) can be tricky to decode accurately. The reason is that many "SCSI" devices ignore the EVPD bit and return a standard INQUIRY response. Previously I simply checked that byte 1 (origin 0) of the response of a valid VPD page was its code, in this case: 0x80 .

The problem is that byte 1 of a standard INQUIRY response for a device with removable media is also 0x80 . So now I also retrieve the "supported VPD pages" page (0x0) and make sure it is well formed and indicates that VPD page 0x80 is supported.

In VPD pages 0x0 and 0x80 byte 2 of the reponse should be 0x0. Byte 2 in a standard INQUIRY response is only zero when the device claims no compliance with any SCSI standard. So that is another possible sanity check.

Doug Gilbert

Thanks for the hint, Doug, I'll give it a try.

Steffen