headers
Siebert, Aaron | 1 Oct 2003 01:21

Mylex DAC960

Managers, I have a AS4100 with a Raid controller identified as a MYLEX
DAC960 when doing a show dev from SRM. I am trying to get specific
information about the exact model of this controller. I believe it is
one of 3 types, KZPAC, KZPCC or KZPSC. 

1. How can I tell exactly which controller this is?
2. Can I configure the controller raid set/jbod by running using run
bios drv0 or do I need an rcu?
3. How can I get disk information (size) of the disks installed?

Thanks

Aaron Siebert
Nagrastar IT Systems Engineer 
303-706-5492 fax 303-706-5719
Aaron.Siebert <at> NagraStar.com
Permalink | Reply | 0 comments |
headers
Dušek Martin | 1 Oct 2003 09:55
Picon

samba 3.0.0 on Tru64 5.1A wanted

Hi managers,

has anybody seen a working samba 3.0.0 on Tru64 5.1A?

With regards,

Martin Dusek
martin.dusek <at> pregis.cz
Permalink | Reply | 0 comments |
headers
Wolfgang.Rupp | 1 Oct 2003 15:40

AdvFS / backup boot problem


Problem: failing dsk0 in a DS10, Tru64 5.1A.

I labeled a new disk with disklabel -wr -t advfs, set
the partitions, and restored the vdump savesets to the
correct partitons on the new disk. Then I disconnected
the old disk, set the new disks SCSI ID and booted.

The system starts to boot, but after "junmping to
bootstrap code" it hangs with "root partition block
size must be 8192, can't open osf_boot"

What did I do wrong?

Wolfgang Rupp
Network Administrator

MM Packaging Europe GmbH
Floragasse 7
A-1040 Wien
Tel: +43 1 50257 238
Fax: +43 1 50257 260
Permalink | Reply | 0 comments |
headers
Brown, Tim | 1 Oct 2003 16:02

Telnet timeout

I have a user who's telnet session is timing after about 15 minutes when
idle. They are able to reconnect but still the timeout occurs.

I looked in daemon.log and found the following entries;

telnetd: ttloop: peer died: not owner

The server is running V5.1B, pk2. 

Is there a timeout value that I am able to increase for telnet sessions?

Thanks,

Tim
Permalink | Reply | 0 comments |
headers
Sreedharan, Anil | 1 Oct 2003 17:46

gcc 3.3.1 build problems

Greetings,

I am having trouble building gcc 3.3.1 on ev6.7 proc running tru64 5.1a, the build process seems to bail out
towards the end linking, 

**********partial erro log**********
ng  -DHAVE_CONFIG_H  -o cc1 \
        c-parse.o c-lang.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o
c-aux-info.o c-common.o c-format.o c-semantics.o c-objc-common.o libcpp.a  main.o libbackend.a
./intl/libintl.a  -liconv  ../libiberty/libiberty.a
libiconv
libiconv_open
libiconv_close
collect2: ld returned 1 exit status
make[2]: *** [cc1] Error 1
************************************

Should i try compiling --with-gnu-as or --with-gnu-ld, If someone had the same issues, I would be grateful
to hear about workarounds/fixes

Anil S
Permalink | Reply | 0 comments |
headers
Siebert, Aaron | 1 Oct 2003 17:56

SUMMARY: Mylex DAC960

Thanks to everyone who responded with answers. 
Fred Kempen
Blair Phillips
Nikola Milutinovic
Pat Obrien
Mohamed Ahmed
Michael Deacy

Here is a summary.
The MYLEX DAC960 identified in the firmware is a KZPAC-xx. It requires a
diskette with configuration utility, which is in a box named
StorageWorks. The diskette is "RAID configuration utility for Alpha".
Put it in, go to SRM console (halt the system) and then go to AlphaBIOS
(type "al"). Choose "Run utility from a diskette" and type one of these:
"swxcrmgr" (older models) or "ra200rcu" (newer models). (quote Nikola M)

The size of the disks and information will be available in the
configuration utility. Other information provided was some more specific
information about logical disk size limitations of those series of
controllers. They are limited to a 32GB size limitation. The limitations
is for raid sets as well as jbods. 

Thanks again to everyone. 

-----Original Message-----
From: Siebert, Aaron 
Sent: Tuesday, September 30, 2003 5:22 PM
To: tru64-unix-managers <at> ornl.gov
Subject: Mylex DAC960
(Continue reading)

Permalink | Reply | 0 comments |
headers
milazzo | 1 Oct 2003 18:27
Picon

system panic with message "Processor Machine Check"


Hi,

Last night an ES40 system went down with this _panic_string :
0xfffffc0000655560 = "Processor Machine Check"
Looking in the "/var/adm/crash/crash-data.x" I saw the output below ...
It seems to be a problem with one of the CPU but after rebooting the server,
all went right without trouble ...
To my mind, it should be a problem with a corrupted memory but how can I
debug the EV6.8AL (21264B) error codes ?

Thanks in advance !

Jérôme

Machine Check Processor Fatal Abort
Machine check code = 0x100000098
        Ibox Status                             = 0000000000000000
        Dcache Status                           = 0000000000000000
        Cbox Address                            = 0000000001cb90c0
        Fill Syndrome 1                         = 0000000000000000
        Fill Syndrome 0                         = 0000000000000000
        Cbox Status                             = 0000000000000001
        EV6 captured status of Bcache mode      = 0000000000000000
        EV6 Exception Address                   = fffffc00002aae90
        EV6 Interrupt Enablement and Current Processor mode =
0000007ee0000000
        EV6 Interrupt Summary Register          = 0000000000000000
        EV6 TBmiss or Fault status              = 0000000000000280
        EV6 PAL Base Address                    = 0000000000018000
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cohen.Jessica | 1 Oct 2003 19:57
Picon
Favicon

Summary: Changes to mv in upgrade from 5.1 to 5.1b?


Thank you to Tim Cutts and Alan Rollow for their replies.

Tim was able to duplicate this bug on his own machines testing between 5.1
and 5.1A; 5.1A also shows the same "quirk".

As far as whether this was an intentional change on HP's part or a bug, I'll
have to e-mail and ask when I have the time I guess.  Meanwhile we are
changing the affected scripts to use "mv -f" instead of mv.

-----Original Message-----
From: Cohen, Jessica: DGRB 
Sent: Tuesday, September 30, 2003 11:35 AM
To: tru64-unix-managers <at> ornl.gov
Subject: Changes to mv in upgrade from 5.1 to 5.1b?

We just upgraded both an ES40 and a GS60 from 5.1 to 5.1b.

Some of our scripts are now failing with the "mv" command with an error I
can replicate on the command line.

This is an example of our directory:

drwxrwx---   2 user1   agroup   8192 Sep 30 10:42 .
drwxr-xr-x  27 user1   agroup   8192 Sep 30 10:32 ..
-rw-r--r--   1 user2   	agroup   744 Sep 30 10:34 afile
-rw-r--r--   1 user2   	agroup   222 Sep 30 10:35 bfile
-rw-r--r--   1 user1   	agroup   966 Sep 30 10:35 cfile

We have a script that belongs to "user2" which writes "afile" to the shared
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cohen, Andy | 1 Oct 2003 20:19
Favicon

SUMMARY: problem with a disk

SUMMARY
========

Basically it was a bad disk.  I did receive, as always, a lot of helpful
information.

>From Alan Rollow:

	Use scu(8) to see what is on the SCSI bus; "show edt".  If
	the device shows up at all, set the "nexus" to be that address
	and send the device a Test Unit Ready, the scu(8) command "tur".
	That should offer some clue what the problem is.

	If the device doesn't show up in the edt listing, you need
	to verify it is actually still on the bus.  I don't think
	the edt list needs for a device to do more than answer an
	Inquiry command, which doesn't take much.  For a Test Unit
	Ready to work, the drive needs to reasonably functional.

	Physically trace the bus and see how many drives are
	there.  My recollection of the AlphaServer 800 is
	that can't hold as many disks as you have, so some
	of these disks are probably in external enclosures
	on add-on SCSI adapters.  See if the suspect disk
	is present in the expected location.  If so, reseat
	it if hot swappable and rescan the bus (scan edt).

	If possible feel and listen closely to see if it is
	spinning.  This can be hard, but if you can shutdown
	the system you can use scu(8) to stop all the other
(Continue reading)

Permalink | Reply | 0 comments |
headers
Browett, Darren | 2 Oct 2003 00:54
Picon

TruCluster 5.1b/HSG80 Unit Offsets

Hi managers

I am putting together a test cluster, and I am having a problem adding a
device.

On the hsg80 the unit offsets are 20 and 120 for the cluster members.
The unit is named  D101.  
When I  do a hwmgr -scan scsi then -show scsi/-view dev the device does
not show up.

Is this a problem with my offsets ??  I was under the impression (with
tru64 V5.x) that I would see all devices
above the assigned unit offsets.

Thank You

Darren

------------------------------------------------------------------------
--------------------------------------------------
Darren Browett P.Eng 						This
message was transmitted
Data Administrator		 				using
100% recycled electrons 
Information and Communication Technology
City of Coquitlam 
P:(604)927 - 3614 
E:dbrowett <at> coquitlam.ca 
------------------------------------------------------------------------
---------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane