[BK PATCH] SCSI -rc1 fixes

[BK PATCH] SCSI -rc1 fixes

[James Bottomley]

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

Re: [BK PATCH] SCSI -rc1 fixes

[Jeff Garzik]

James Bottomley wrote:
> This is my first set of -rc fixes for SCSI.  The patch is available at

thankyou thankyou :)

Re: [BK PATCH] SCSI -rc1 fixes

[James Bottomley]

On Sun, 2004-11-14 at 17:05, Jeff Garzik wrote:
> 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

Re: [BK PATCH] SCSI -rc1 fixes

[Matthias Andree]

James Bottomley <James.Bottomley@SteelEye.com> writes:

> On Sun, 2004-11-14 at 17:05, Jeff Garzik wrote:
>> thankyou thankyou :)
>
> I've only been away for *two* weeks .... that's not a very long time
> compared with a linux kernel -rc cycle ...

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

Re: [BK PATCH] SCSI -rc1 fixes

[James Bottomley]

On Sun, 2004-11-14 at 17:54, Matthias Andree wrote:
> 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?

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

SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups (was: [BK PATCH] SCSI -rc1 fixes)

[Matthias Andree]

James Bottomley <James.Bottomley@SteelEye.com> writes:

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

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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups (was: [BK PATCH] SCSI -rc1 fixes)

[Steffen Winterfeldt]

On Mon, 15 Nov 2004, Matthias Andree wrote:

> James Bottomley <James.Bottomley@SteelEye.com> writes:
> 
> > 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.

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

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

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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups (was: [BK PATCH] SCSI -rc1 fixes)

[Jens Axboe]

On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> On Mon, 15 Nov 2004, Matthias Andree wrote:
> 
> > James Bottomley <James.Bottomley@SteelEye.com> writes:
> > 
> > > 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.
> 
> Sorry for the late response; I'm just back from vacation.
> 
> > 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.
> 
> 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.

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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups (was: [BK PATCH] SCSI -rc1 fixes)

[Steffen Winterfeldt]

On Mon, 22 Nov 2004, Jens Axboe wrote:

> On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> > On Mon, 15 Nov 2004, Matthias Andree wrote:
> > 
> > > James Bottomley <James.Bottomley@SteelEye.com> writes:
> > > 
> > > > 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.
> > 
> > Sorry for the late response; I'm just back from vacation.
> > 
> > > 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.
> > 
> > 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.
> 
> 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).

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


Steffen

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups (was: [BK PATCH] SCSI -rc1 fixes)

[Jens Axboe]

On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> On Mon, 22 Nov 2004, Jens Axboe wrote:
> 
> > On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> > > On Mon, 15 Nov 2004, Matthias Andree wrote:
> > > 
> > > > James Bottomley <James.Bottomley@SteelEye.com> writes:
> > > > 
> > > > > 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.
> > > 
> > > Sorry for the late response; I'm just back from vacation.
> > > 
> > > > 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.
> > > 
> > > 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.
> > 
> > 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).
> 
> Well, it already has. But I don't think this is the problem here.

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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups (was: [BK PATCH] SCSI -rc1 fixes)

[Steffen Winterfeldt]

On Mon, 22 Nov 2004, Jens Axboe wrote:
> On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> > On Mon, 22 Nov 2004, Jens Axboe wrote:
> > > On Mon, Nov 22 2004, Steffen Winterfeldt wrote:

> > > > 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.
> > > 
> > > 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).
> > 
> > Well, it already has. But I don't think this is the problem here.
> 
> It has? Great! It could have been the problem if the data phases are
> interpreted incorrectly.

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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups (was: [BK PATCH] SCSI -rc1 fixes)

[Jens Axboe]

On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> On Mon, 22 Nov 2004, Jens Axboe wrote:
> > On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> > > On Mon, 22 Nov 2004, Jens Axboe wrote:
> > > > On Mon, Nov 22 2004, Steffen Winterfeldt wrote:
> 
> > > > > 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.
> > > > 
> > > > 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).
> > > 
> > > Well, it already has. But I don't think this is the problem here.
> > 
> > It has? Great! It could have been the problem if the data phases are
> > interpreted incorrectly.
> 
> 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.

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

-- 
Jens Axboe

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Matthias Andree]

Steffen Winterfeldt <snwint@suse.de> 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]
> 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.

[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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Steffen Winterfeldt]

On Mon, 22 Nov 2004, Matthias Andree wrote:

> Steffen Winterfeldt <snwint@suse.de> writes:

[...]

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

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.

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

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


Steffen

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Matthew Wilcox]

On Mon, Nov 22, 2004 at 01:02:36PM +0100, Matthias Andree wrote:
> [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]
> 
> I found a minimal way to reproduce the problem:

Aha, this is wonderful.

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

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

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

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.

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

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

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

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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Matthias Andree]

Matthew Wilcox <matthew@wil.cx> writes:

>> I found a minimal way to reproduce the problem:
>
> Aha, this is wonderful.

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.

> *nod*.  The [lspci] 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).

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.

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

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.

>> 2. is it a kernel bug if reading offset #216 (byte-wise) in the config
>>    file in sysfs confuses the hardware?
>
> 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.

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.

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

Right, SYM53C875 and SYM53C860 here.

-- 
Matthias Andree

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Steffen Winterfeldt]

[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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Matthias Andree]

Steffen Winterfeldt schrieb am 2004-11-26:

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

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 open("/sys/devices/pci0000:00/0000:00:0d.0/config", O_RDONLY) = 4
> 22602 read(4, "\0\20\17\0\27\0\20\2&\0\0\1\20 \0\0\1\320\0\0\0\0\200\344"..., 4096) = 256
  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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Steffen Winterfeldt]

On Sat, 27 Nov 2004, Matthias Andree wrote:

> Steffen Winterfeldt schrieb am 2004-11-26:
> 
> > 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:

[...]

> 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

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

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

That warning was introduced after SL 9.1 was finished.


Steffen

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Matthias Andree]

Steffen Winterfeldt <snwint@suse.de> writes:

>> 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
>
> They are from /sbin/raiddetect (same cause as in hwinfo - libsysfs
> usage).

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.

>> The kernel (vanilla 2.6.9) still begs that hwinfo be converted to SG_IO.
>
> That warning was introduced after SL 9.1 was finished.

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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Matthias Andree]

Matthew Wilcox <matthew@wil.cx> writes:

>> 2. is it a kernel bug if reading offset #216 (byte-wise) in the config
>>    file in sysfs confuses the hardware?
>
> 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.

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

-- 
Matthias Andree

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Douglas Gilbert]

Steffen Winterfeldt wrote:
> On Mon, 15 Nov 2004, Matthias Andree wrote:
> 
> 
>>James Bottomley <James.Bottomley@SteelEye.com> writes:
>>
>>
>>>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.
> 
> 
> Sorry for the late response; I'm just back from vacation.
> 
> 
>>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.
> 
> 
> 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,
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

Re: SuSE hwinfo/yast2 still confusing SYM53C8XX, killing tape backups

[Steffen Winterfeldt]

On Mon, 22 Nov 2004, Douglas Gilbert wrote:

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

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


Steffen