Apologies for the OT post, but I need some help here and I haven't got any in the Solaris newsgroup. People here seem to be a knowledgeable bunch and willing to answer questions, so I thought I'd try.
I have a Sun Ultra 2 workstation running Solaris 9. I just bought a 36 GB SCSI disk and mounted it in an external case. The guy I bought the disk from warranted it as being perfect and free from grown defects. The external case works fine, the bus isn't too long and it's correctly terminated. But when I ran "format" it found 22 grown defects on the disk. I've heard a few people criticise Sun's "format" utility, but no one seems to have a pre-compiled altenative. The question is should I worry and send the disk back, or not?
Also, I have a second question. Sometimes when I click Actions > Logout in GNOME it doesn't work. Nothing happens. Any idea what might be causing this?
Regarding the SCSI disk. How do you format it? Can you run dd on it to see if you get input/output errors if you try to read all cylinders?
Regarding gnome logout problem, did you try to tail -f /var/log/messages or some other system log to see if there are any errors? Do you have a X session log? On my linux machine I have a file Xorg.0.log with my X session stderr output. Maybe that would help.
I'm using Solaris 9. I formatted the disk using Sun's "format" utility which comes with Solaris 9. I might be able to use "dd" in a script to max out the disk and see if I get any errors. But I am kind of annoyed as I really wanted a trouble-free disk!
I'll have a look for a X session log. Do you know which directory it's kept in?
SCSI is marketed as "error free". The way they actually do that is by having a collection of "replacement" blocks on the disk. So when the format application is run, the defective block is replaced by (mapped to) one of the replacement blocks.
22 bad blocks is quite reasonable. The replacement area has several hundred available.
That's OK, the only guy who will bitch can safely be ignored.
The disk is crap. Any new bad sectors after it is brand new, are a sign of impending disk failure.
I think Solaris10 will run on an Ultra2, and you can download that right from Sun for free. That may have some fixes that you don't have applied. Either way, go download the current patch cluster & get that applied.
Feel free to email me if you want, I probably have a 36GB drive that would fit, far as that goes.
Well, he doesn't really need to do that, I think a sufrace analysis from within format would to the trick. One pass, maybe 2, if it's clean that'll show, if it's crap it'll show there too.
Ah, you're right, that does fit the scenerio well. OK, I retract my "your disk is crap" statement but would advise a couple passes of surface analysis from within the format command. I think it's "analyze" after you select the drive from within format.
Verbum sap. The 36 GB disk has 75 million sectors, and about 1% are set aside for spares; one or two dozen is no big deal.
And, remember that the format utility probably doesn't allow retry of bad-read events, so the 'bad' blocks might actually work fine in normal use (if the sector gets bad parity/ECC check, the disk will spin a few more times to try again; the format utility presumably turns off that 'hidden' correction step).
Historically, a lot of disk format utilities reported bad blocks. Then the continuing complaints from customers 'is there something bad about my disk, should I send it back?' took hold, and the format utilities started correcting bad blocks and only reporting if the spares were not sufficient in number. Nowadays, you have to select 'expert' settings and twist the format software's little virtual arm to get it to do a complete scan (in Macintosh parlance, 'zero all data' was the only way to do this with Drive Setup).
The 'bad blocks found' message is informative only, use the disk.
Thanks for all the suggestions. This isn't the factory defect list; the Solaris "format" utility clearly distinguishes between "primary" and "grown" defects, and this disk has 22 grown defects. Funny thing is, before I ran "format" I looked at the grown defect list and found none. Then I formatted and analysed the disk, and the list grew to 22 defects. So either the disk is going bad, or the format utility is doing something wrong. I've heard people criticise the format utility, so I thought I'd ask here, but I'm inclined to send the disk back for a refund.
Agreed- get any important data off the disk right away. If the Solaris install is important, use flarcreate to get an image off onto some other machine so you can bring the image back once you get a new disk in.
Solaris 10 actually runs pretty well on a 2x300 Ultra 2. Apparently the ecyclers have a hard time getting rid of Ultra 60's, so a 2x450 box should end up relatively cheap these days.
If Gnome is acting up, check your network config- dns, /etc/netmasks, etc..
Indeed. I was holding out on replacing the Ultra 2, though. It does what I need. The only problems I've had are with a few of the latest Blastwave packages. Gimp 2.0 is WAY slower than Gimp 1.2. I wish they wouldn't bloat things! Is a dual 450 MHz Ultra 60 much faster than a dual 300 MHz Ultra 2? My Ultra 2 has 1280 MB RAM, so it's close to being the best Ultra 2 you can get. But I wouldn't mind upgrading the Ultra 2 to dual 400 MHz processors if anyone has any they want to sell, or know of a source at a fair price.
That's weird. I haven't changed /etc/netmasks recently. Why would it screw up Gnome?
The dual 450 is definitely faster, not sure to what extent the PCI/UPA is helping over the sbus, but ssh & nfs, etc all benefit from the faster processors. The U2 does handle I/O throughput better than even a 440mhz U10, the desktop remains lots more responsive. I recently put together a 2x360 U60 and its also snappier than the U2. A U2 definitely handles the Java desktop lots better than a Creator 3d 440mhz U10- impressively so.
I've had the occasional problem with DNS when /etc/netmasks wasn't quite right, though mostly when booting. Rights issues in /tmp & /var/tmp can also cause trouble. Gnome is a pain to troubleshoot though.
I use Patch Check Advanced to keep up the updates, Update Manager is darn near unusable on these slower Sun machines.
Hmm ... this sounds more like one appropriate to comp.sys.sun.hardware than in a software (Solaris) newsgroup.
O.K. The external SCSI connector on that is 68-pin SE Single-ended) SCSI. I've got a couple of them in service at the moment, including the one at which I am typing this.
Perhaps the disk label was reset to factory settings, and the grown defects have occurred over time. I would try running "format" a second time (or actually, just the "diskcheck" sub-menu, which can do either destructive or non-destructive (to data) testing -- and since you don't have anything on the disk yet, I would suggest the destructive, as it is a more thorough test. If it grows more bad blocks, send it back.
As for the external housing for the disk -- let's narrow things down a bit:
1) Is it wide or narrow SCSI?
2) What format is the disk? 50-pin SCSI, 68-pin fast wide SE (Single-ended) SCSI, 68-pin HVD (High Voltage Differential), 68-pin LVD (Low Voltage Differential), or 80-pin SCA (SCSI, ID select pins, and power all in a single connector)?
Normally, a LVD interface can drive a SE device, or vice versa, but if you mix SE and LVD on the same bus, everything will have to run in SE mode. The only LVD thing which I know which won't run on an SE interface is the Exabyte 430 tape jukebox and its associated Mammoth 2 tapes. (For that, I had to get a Sun Ultra-60 (quite similar to an Ultra to, except for having PCI bus instead of sBus, so you can get host adaptor cards for the LVD SCSI devices at need.)
3) Who made the housing? If it is Sun, and is either 68-pin or SCA, then the housing (a UniPack -- or MultiPack if 6 or 12 drive bays) should do termination automatically. If it is by some other maker, you probably will need an external terminator. And the 68-pin terminators come in three basic flavors: SE, HVD, and LVD. some of the more expensive terminators can switch modes. Others can't, and the wrong one will probably introduce just enough errors to give you the grown bad block list.
4) What brand of disk is it? If it is the SCA by Seagate, one which is reaching its end-of-life will return a device identifier (to probe-scsi-all and other tests including the format selector) which has the 'T' replaced with an 'X'. Here is an example:
SEAGATE-SX150176LC-BA0F
this one happens to be a 50GB drive which I am playing with on the Ultra-60 to see how long it will keep working. Obviously, I am using it for non-critical tasks. The system will complain every time it is booted and the disk is mounted, but since mine shows no growing defect list, it still seems to be good, and is only based on total hours of operation.
On this one -- I really have no idea. I don't use Gnome on my Solaris 10 systems. I'm sticking with CDE for that, because Gnome just uses too much in the way of CPU assets.
It may simply be that it needs to gather enough virtual memory to run the logout function. Or it may think that there is something critical running which needs to be shut down cleanly first.
If CDE ever goes away totally, I'll move back to something like tvwm or something similar -- even if I have to chase down the sources and compile it myself. :-) I *really* miss some of the features of the one which preceded CDE -- OpenWindows.
You have what I can offer above.
Now to see what others suggested before I could get to this.
There is a UPA slot in the Ultra-2 -- for sBus format framebuffers, but with a different connector from the normal sBus slots.
Well -- I don't have a 300 MHz Ultra-2 running at present, but here is a comparison (using an ancient dhrystone benchmark) between the dual 400 MHz CPU Ultra-2 and the dual 450 MHz CPU Ultra-60, plus a final test compiled for 64-bit code instead of the 32-bit code which is the default.
./dryr Dhrystone time for 5000000 passes = 6 This machine benchmarks at 770416 dhrystones/second ./drynr Dhrystone time for 5000000 passes = 6 This machine benchmarks at 772797 dhrystones/second ============================================================ Ultra-60 -- dual 450 MHZ CPUs
./drynr Dhrystone time for 5000000 passes = 5 This machine benchmarks at 862068 dhrystones/second ./dryr Dhrystone time for 5000000 passes = 5 This machine benchmarks at 875656 dhrystones/second ============================================================ Ultra-60 -- dual 450 MHZ CPUs -- 64-bit code
./drynr Dhrystone time for 5000000 passes = 5 This machine benchmarks at 860585 dhrystones/second ./dryr Dhrystone time for 5000000 passes = 5 This machine benchmarks at 863557 dhrystones/second ============================================================
I see that the 64-bit code actually slows the system down a little -- since the old benchmark was written for 32-bit and 16-bit machines.
I've got timing information all the way back to my first unix box -- an 8 MHz MC68000 based v7 unix -- the Cosmos CMS-16/UNX, though I have had to adjust the limits in the dhrystone a few times to keep the run times long enough to get a meaningful time reading. :-) The modern desktop machines really leave the old high-end mainframes in the dust.
Each run is with explicit register statements and without. It used to make a lot more of a difference.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.