Daniel van Eeden wrote:
So we're sure it's not the hardware.
Now something strange, almost the same happend some days ago on my
workstation.
I had two scsi disks attached to it. Then something strange happened
(disk seemed to be very busy). I couldn't get any information from it.
after a reboot I found out that te partiontable was damaged.
My workstation is an x86 based system with a Adaptec 2940 scsi
controller. The failing disk was a 20G seagate with scsi-id 12. (the
other disk has scsi-id 10)
I didn't check the drive yet, but I suspect it to be ok. (smartclt also
told me so)
Could be the same problem?
Are all disks attached to the same scsi channel?
Which kernels are those systems using? which filesystems?
(I'm using 2.4.19 with ext3)
Hm.. I was using 2.4.19-sun4u-smp with ext3 too when the partition table
got messed up. I was writing a partition table to another disk, when the
scsi subsystem stopped responding. My drive became unbootable, but by
booting from CD I mounted it and took a look at the tables.
The partition table spanned from block 0 to the last block, with just
one partition. Mounting the drive, however, revealed that it was a 50MB
partition (my /boot).
But, on my second attempt, my root is ext2 for now, while I try to
mirror it over to an ext3 filesystem. That one also hung, I'll check if
it is the "live target 0 not responding" this time too, or if it has
moved to the ext3 disks.
And yes, all disks are attached to the same chain, my disk was a 4.2GB
Sun Seagate drive. The symptoms I've encountered so far has been that
the system stops responding, and the load slowly increases all the time.
I've only got a ss4-110. Can I simulate the problem with that one?
Checking my "Black Bible" here, you can have two drives in it. That
should be enough to do some testing. Not sure which scsi chipset that
one uses, though.
There are more common things between the u2 and e3000...there both 64
bit, isn't it?
Maybe the kernel, libc or any other software with similair versions?
Very true. The E3000 I have has got UltraSPARC I and the U2 at work has
UltraSPARC II, both fully 64bit. But since a similar thing happened to
your x86 machine, it doesn't seem likely that it has got to do with
32/64-bit.
Daniel van Eeden
//Andreas
