scsi problem on a scorpio (715)
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
Hi,
On Thu, 8 Jan 2004, Riccardo wrote:
[snip]
Quoted 2 lines
A lot of different HD's (even HP spare parts) freeze up the kernel during mkfs.
[snip]
Quoted 4 lines
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
Quoted 2 lines · Steve Bromwich
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.
Quoted 3 lines
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
Quoted 4 lines · Steve Bromwich
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.
Quoted 5 lines
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
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 5 lines · Carlos O'Donell
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
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).
Quoted 4 lines · Grant Grundler
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...
Quoted 10 lines
Quoted 3 lines
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)