ALPHA getting tomuch time at startup

[Pieter 't Hart]

thanks for the feedback
your info is inconsistant.

with the last post and the hwmgr output i conclude your production server has 3 disks
7: connection pci1slot7
13: scsi_adapter itpsa0
14: scsi_bus scsi0
69: disk bus-0-targ-0-lun-0 dsk0
76: disk bus-0-targ-1-lun-0 dsk5
77: disk bus-0-targ-2-lun-0 dsk6
9: connection pci1slot8

while your testserver only has one disk ?
7: connection pci1slot7
11: scsi_adapter itpsa0
12: scsi_bus scsi0
69: disk bus-0-targ-0-lun-0 dsk0
9: connection pci1slot9

so the hardware is different.

your info :
/usr and /var are directories and not mount points.
and :
# df -k
Filesystem 1024-blocks Used Available Capacity Mounted on
root_domain#root 123604088 83445432 39601128 68% /
/proc 0 0 0 100% /proc
usr_domain#usr 3169360 2232686 867640 73% /usr
usr_domain#var 3169360 45202 867640 5% /var
shows you do use mountpoints.

could you please give the correct info about the test-system compared to the production-system?

[Rashid Ashraf]

Hi

Sorry for it.

Yes, My live system has three HDD while test has only One. Also the location of Optical Network Card is different in both.

About the file system configration, I sent the output of "df -k" from the test system. It has /var and /usr as mount points. I just confused it with my another server.

Regards

RMA

[Ivan Ferreira]

What I can see is SCSI messages with Hard error detected for HWID=75 COMPAQ SDT-10000 (Tape drive).

Mar 18 15:21:21 test vmunix: MEDIUM ERROR - Nonrecoverable medium error
Mar 26 12:04:00 test vmunix: Alpha boot: available memory from 0x226c000 to 0x3ff52000

As you can see in those messages, at 15:21 you had the last "MEDIUM ERROR", after that, at Mar 26 12:04, the "Alpha boot:" message.

So, what I would try first is to remove the SCSI tape, or check it's cabling and termination.

[Rashid Ashraf]

Hi

Thanks for the reply.
During the boot time, there is no visible activity on tape drive. After boot, Tape drive works fine and I took backup yesterday on two data tapes.
It seems doing some media recovery during the startup. Harddisk lights remain on most of the time while system bootsup.

Regards and thanks

RMA

[Pieter 't Hart]

to determine what's wrong during the boot process yo do have to reboot!.

from all the posts till now you can't determine if it's a hardware or software problem.
Software is most likely. this can be confirmed by first doing a minimal startup.
like boot into single-user mode!
folowed by step-by step activating the startup.
It could be a wrong setting of a parameter in the sysconfigtab wich frustrates the system.

So again i advice the boot to single user mode. if this also takes unreasonably long abort this startup and try to boot genvmunix (in single user mode). to detect if something went wrong with the running kernel
you can also boot from unix-cd to exclude you have another problem not related to the bootdisk.

As your first post asked about logfiles other than the messages file.
I mentioned "sysman event_viewer" as a tool to read info from different logfiles.
i mentioned the /var/adm/syslog.dated/*/* logfiles and the binary errorlog.
have you tried these options?
the binary errorlog is read with "uerf -R |more" or "dia -R|more" if you have decevent installed

[Sri_10]

Obviously, bootstrap taking very long time to load /vmunix. Does this affect /vmunix alone or does it affect /genvmunix boot too ? ( Try: >>> boot -fi genvmunix )

When the system is up and running check how much fragmented /vmunix file or the root_domain is ?

For file (/vmunix), check:

# showfile -x /vmunix

Id Vol PgSz Pages XtntType Segs SegSz I/O Perf File
a8a.8027 1 16 2557 simple ** ** async 100% vmunix

extentMap: 1
pageOff pageCnt vol volBlock blockCnt
0 2557 1 1334592 40912
extentCnt: 1

If extentCnt is more than say 5, say you have to consider fragmentation of the file and the domain being an issue.

To check fragmentation of the root_domain, do:

# defragment -nv root_domain
defragment: Gathering data for domain 'root_domain'
Current domain data:
Extents: 714
Files w/extents: 713
Avg exts per file w/exts: 1.00
Aggregate I/O perf: 100%
Free space fragments: 195
<100K <1M <10M >10M
Free space: 0% 5% 15% 80%
Fragments: 41 102 38 14

If avg exts per file with exts is much more than 2.0, time to consider defragmenting the root_domain.

Most importantly, if you or somebody could check if REALLY large AdvFS root_domain (in your case, you indicated / is close to 120+ GB! ). May be too large a domain is hurting the boot-up speed., though have I haven't checked .. just wanted to pass this thought ..

Thanks
Sri