From: Marcin Wrobel (wrobelma@idea.net.pl)
Date: Thu Aug 22 2002 - 05:12:15 EDT
Thank's everything works now.
----- Original Message -----
From: "Georgette, Danielle" <Danielle.Georgette@det.nsw.edu.au>
To: "'Marcin Wrobel'" <wrobelma@idea.net.pl>
Sent: Thursday, August 22, 2002 11:04 AM
Subject: RE: network problems with Tru64 4.0F
You might try this one for 'no namelist' (from the archives)
/sbin/kloadsrv May not be running. Digital/Compaq says they've seen this
happen under high internet-connection loads.
Restart it with the command:
# /sbin/kloadsrv
/sbin/init.d/autosysconfig does this at boot time.
:) Dan.
-----Original Message-----
From: Marcin Wrobel [mailto:wrobelma@idea.net.pl]
Sent: Thursday, 22 August 2002 5:53 PM
To: Georgette, Danielle
Subject: Re: network problems with Tru64 4.0F
Thanks very much Danielle,
Well, setting the network cards to 100MB won't be a problem. I did'n know
just if ifconfig setting will do to solve this.
As to 'no namelist', this is true that I have patched the system lately, but
after the reboot (twice since then) everything worked fine. Could be that
suddenly system somehow decided to boot from another copy of kernel ? I've
got active kernel in /vmunix, but I also have all backuped kernels left by
patch script: vmunix.PrePatch and vmunix.old I have checked that on both
machines runs the same kernel (both were patched), same size.
I run # sizer -b and it displays vmunix so running kernel is the one
patched ?
Any ideas ?
Thank's for help.
----- Original Message -----
From: "Georgette, Danielle" <Danielle.Georgette@det.nsw.edu.au>
To: "'Marcin Wrobel'" <wrobelma@idea.net.pl>
Sent: Thursday, August 22, 2002 9:25 AM
Subject: RE: network problems with Tru64 4.0F
Marcin,
The 'no namelist' problem often happens when the running kernel is not the
version that was created for the current system, ie a patchkit is loaded and
the new patched kernel isn't copied to /vmunix, so when the system reboots
it will be running from the old kernel with all the new patched files.
Running from /genvmunix can also have this effect.
With the network card: what type is it ? You can set the card to the same
speed and duples parameters as your switch at the firmware prompt so
autonegotiation is disabled and you shouldn't see this problem. The DE600
cards ignore the firmware setting and have to be set in /etc/inet.local as
follows (example is to set ee0 to full duplex 100 speed):
/usr/sbin/ifconfig ee0 down
/usr/sbin/lan_config -i ee0 -a 0 -s 100 -x 1
/usr/sbin/ifconfig ee0 up
Feel free to write back with any more questions and I hope this helps solve
something for you,
Danielle
-----Original Message-----
From: Marcin Wrobel [mailto:wrobelma@idea.net.pl]
Sent: Thursday, 22 August 2002 5:02 PM
To: tru64 MailList
Subject: network problems with Tru64 4.0F
Ok, starting from begining ...
Machines: Two ES40 in ASE cluster
System: Tru64 4.0F
Systems were working fine until i realized that I cannot create an outgoing
connection from server to somewere else e.g. computer in same LAN and LAN's
gateway except second server in the cluster (but this was working over the
other set of net cards connected directly with each other between servers),
even ping wasn't working. From outside everything worked fine and I could
leave it this way but this was an accident to happen so I deciceded to get
on the bottom of this. I saw that the ASE manager which watched over both
servers through one net card connected to LAN, second net card connected
directly to second net card on second server, and over the common SCSI bus,
did not detected any errors. I have tried restarting different net daemons,
and other things but nothing seemed to work. So I decideded reboot is
necessary so I moved ASE services to second machine and booted first one.
After a boot everything was working as it should be but the ASE manager on a
second machine didn't register member down, so my first server was unable to
become again a member of ASE and I couldn't move services from second server
to working first one. Only one solution remained. Shutdown of everything on
second server and it's boot. So I did it, and it worked fine, oracle and all
apps went up and running. Everything works now fine except minimum of two
commands that I know concerning network on second server.
1. netstat - regardless of given parameter it returns one answer: # netstat
-n no namelist # netstat -an no namelist ....
2. arp - regardless of given parameter it returns one answer:
# arp -a
arp: bad namelist
I depend on information returned by netstat a lot so it's lack is making me
havy time. Ifconfig works fine, and all possible connections and protocols
work also fine so it's not critical.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
If anyone has a clue I would appreciate some help a lot.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
And another more simple question, after a reboot I get in /var/adm/messages
info :
Jul 31 13:44:22 osiw1 vmunix: tu0: link up: negotiated 100BaseTX: full
duplex Jul 31 13:44:36 osiw1 vmunix: tu0: link up: negotiated 100BaseTX:
full duplex Jul 31 15:00:14 osiw1 vmunix: tu0: transmit FIFO underflow:
threshold raised
to: 256 bytes
Jul 31 15:00:17 osiw1 vmunix: tu0: link up: negotiated 100BaseTX: full
duplex Aug 1 13:55:35 osiw1 vmunix: tu0: transmit FIFO underflow: threshold
raised
to: 512 bytes
Aug 1 13:55:38 osiw1 vmunix: tu0: link up: negotiated 100BaseTX: full
duplex
It goes in time up to 1024 bytes and after that its desides to bypass FIFO
and works fine without it until next reboot, when it starts all over again.
At each switch is a few seconds of blackout in network availability which
results in many alerts by users and disturbs applications and other
connected to the database systems.
If someone knows how to turn this FIFO of set it at boot time I would also
appreciate a lot.
Thanks for any help,
System / DB Administrator
Marcin Wróbel, Poland.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:50 EDT