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

[Jens Axboe <axboe@suse.de>]

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