[parisc-linux] scsi problem on a scorpio (715)

[parisc-linux] scsi problem on a scorpio (715)

[Riccardo]

Hello,

I had a lot of problems using linux on that box (I'm using gentoo,
2.4.23 series)

The problems manifest themselves in the following ways:

A lot of different HD's (even HP spare parts) freeze up the kernel
during mkfs.
I got the box then worning with a luck of getting two disk formatted.
The stability was not very high. Sometimes it compiled for 50 hours, but
sometimes when the disk grinded more... freeze.
Guy Martin suggested me to change the TAG default value in the NCR
53x700 driver from 16 to 8 since that is what HP used. I didn't get a
big improvment. I still have one of the inriminated disks. Issuing
several mkfs (usually the second) freezes the kernel.

Today during emerge sync the system freezed. I rebooted and the computer
zasn't responding to ssh or ping. When I hooked up a monitor I got a
hole load of errors clearly related to scsi.

I toke a picture of the monitor.

http://dev.gentoo.org/~gmsoft/pics/scsi-failure.jpg


-Ric

Re: [parisc-linux] scsi problem on a scorpio (715)

[Steve Bromwich]

Hi,

On Thu, 8 Jan 2004, Riccardo wrote:

[snip]
> A lot of different HD's (even HP spare parts) freeze up the kernel
> during mkfs.
[snip]
> Guy Martin suggested me to change the TAG default value in the NCR
> 53x700 driver from 16 to 8 since that is what HP used. I didn't get a
> big improvment. I still have one of the inriminated disks. Issuing
> several mkfs (usually the second) freezes the kernel.

I had a similar problem and fixed it by setting tags to 8 (my problem
drive is a Quantum Fireball). Grant Grundler mentioned that "as of 5 years
ago, HP-UX default was 8 for servers and 2 for workstations"; as the 715
is a workstation it might be worth trying setting tags to 2 and seeing
what happens?

What drives have you tried, out of curiosity?

Cheers, Steve

Re: [parisc-linux] scsi problem on a scorpio (715)

[Grant Grundler]

On Wed, Jan 07, 2004 at 10:30:30PM -0400, Steve Bromwich wrote:
> Grant Grundler mentioned that "as of 5 years
> ago, HP-UX default was 8 for servers and 2 for workstations";

The drives shipped with workstations had "Write Cache Enable" (aka WCE)
turned on by default.  Not good if you really care about your data.
But Tag queue depth of 2 works great because the drive will immediately
report "success" until it's on-board cache was full.

>  as the 715
> is a workstation it might be worth trying setting tags to 2 and seeing
> what happens?

Unless performance is more important than strict correctness, I still
reccommend tag queue depth of 8 and disable "Write Cache" setting.
Reducing queue depth further typically only limits performance.

I suspect something else is wrong in Riccardo's case. But it wouldn't
hurt disable queue tags completely and see if that is at least stable.

root@debian:~# sginfo -c /dev/sda

Data from Caching Page
----------------------
Write Cache                        0
Read Cache                         1
Prefetch units                     0
Demand Read Retention Priority     0
Demand Write Retention Priority    0
Disable Pre-fetch Transfer Length  65535
Minimum Pre-fetch                  0
Maximum Pre-fetch                  65535
Maximum Pre-fetch Ceiling          65535

hth,
grant

Re: [parisc-linux] scsi problem on a scorpio (715)

[Carlos O'Donell]

> On Wed, Jan 07, 2004 at 10:30:30PM -0400, Steve Bromwich wrote:
> Unless performance is more important than strict correctness, I still
> reccommend tag queue depth of 8 and disable "Write Cache" setting.
> Reducing queue depth further typically only limits performance.

My entire cluster was made up of scorpio boxes 715/50's, and I *never*
had them run stably with anything but a tag queue depth of 1.

Grant, I'm pretty sure me and you had this exact conversation like 2
years ago :)

c.

Re: [parisc-linux] scsi problem on a scorpio (715)

[John David Anglin]

> My entire cluster was made up of scorpio boxes 715/50's, and I *never*
> had them run stably with anything but a tag queue depth of 1.
> 
> Grant, I'm pretty sure me and you had this exact conversation like 2
> years ago :)

Also, remember the issues that I had under HP-UX 10.20 with some Seagate
Elite drives.  I believe that I had to set the depth to 1 for these
drives to get the system to run reliably.  Tagged queuing is broken
on most old drives.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] scsi problem on a scorpio (715)

[Grant Grundler]

On Wed, Jan 07, 2004 at 11:14:06PM -0500, Carlos O'Donell wrote:
> My entire cluster was made up of scorpio boxes 715/50's, and I *never*
> had them run stably with anything but a tag queue depth of 1.
> 
> Grant, I'm pretty sure me and you had this exact conversation like 2
> years ago :)

Dude! you *are* good.

Search for "scsi queue tags 715/50" yielded:
http://lists.parisc-linux.org/pipermail/parisc-linux/2002-February/015465.html

grant

Re: [parisc-linux] scsi problem on a scorpio (715)

[Riccardo]

Help! The machine just doesn't come up anymore! After the screengrap I
posted the kernel dies with a panic...

This time I hooked up a monitor during the whole startup and I notice
some details:
- both eth0 and scsi0 drivers complain about not being able to allcoate
"consistent memory" is this ok? doesn't sound nice.
- there is always a printout saying "kernel bug found in slab.c" with
also a line number which at the moment I can't read (hooked up
themonitor to another computer to be able to write this mail).

Grant Grundler wrote:
 
> The drives shipped with workstations had "Write Cache Enable" (aka WCE)
> turned on by default.  Not good if you really care about your data.
> But Tag queue depth of 2 works great because the drive will immediately
> report "success" until it's on-board cache was full.
I'm currently not using HP drives but two disk drives that worked fine
in a sun workstation and a macintosh, IIRC. Both worked fine with
NetBSD, OpenBSD and some other os's.

I really did a sort of razzia dismantling half of my server and
workstations when I first tried installing linux to get some working
drives. I remember trying out several IBM DFHSS and similar drives of
the 1, 2 GB size. 
The original HP 525MB scsi drives (rebranded Quantum ProDriveLPS 525S)
gave problems too. I have one of those unused and this is the one I used
to test the kernel again.

Currently the machine has a Seagate ST566 (palo and user home as well as
scratch) and a IBM DORS 2GB disk with root. They both are reported as
scsi-2...

 
> >  as the 715
> > is a workstation it might be worth trying setting tags to 2 and seeing
> > what happens?
> 
> Unless performance is more important than strict correctness, I still
> reccommend tag queue depth of 8 and disable "Write Cache" setting.
> Reducing queue depth further typically only limits performance.
> 
> I suspect something else is wrong in Riccardo's case. But it wouldn't
> hurt disable queue tags completely and see if that is at least stable.
Indeed, since I'm not using HP drives. I looked at the jumpers of the HP
relabeled disk and I found none regarding caching.
But does tag queueing affect the controller the disks or both? Either
all my disks are bugged or...

A later post in this thread mentions that setting tag to 0 is not a good
idea and that 2 or 4 would be a resonable value.


I already have quite poor scsi performance. running hdparm -tT yields me
about 8-10 MB buffer but only about 1.5MB/sec non-buffer read! I'd
expect more something around the 4-5Mb/sec range...

-Ric

PS. I hope someone has a suggestion for revitalizing my scorpio. Hooking
up an external CD to get the gentoo live-cd and then reinstalling is a
nuisance
PPS: right now root partition is raiser, so at least I don't loose data
when the sytem freezes and the genoo portage tree doesn't fill up my
disk with small files. SOmeone suggested Raiser being not stable,
howewer since the freeze happens already at MKFS (ext2/ext3 too) and
also did happen on a previous install some weeks ago with ext2 file
system (on a different, HP branded disk!) I think it is unrelated. The
scsi driver sees the problem (or something else affects the scsi driver,
some cache flushing for example)