Re: Is 5.0.7 ready for production?

From: Mike Brown (mike_at_tkg.ca)
Date: 09/06/03 

Date: Sat, 06 Sep 2003 21:02:46 GMT

Bela Lubkin wrote:
>
> Mike Brown wrote:
>
> > Also if you are updating an 'older' Compaq ProLiant that requires the
> > EFS548 version it generates the following error on 5.0.7:
> >
> > i386ld: Symbol pci-debug in
>
> "pci_debug", actually. Which shows that you're typing this rather than
> cut-and-paste or redirecting to a file, tsk.
>

Actually worse then that, it was from memory.

> > /var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/cpqw/Driver.o
> > is multiply defined.
> >
> > first defined in
> > /var/opt/K/SCO/link/1.1.1Hw/etc/conf/pack.d/pci/Driver.o
> > ERROR: Can not link-edit unix
> >
> >
> > Obviously the EFS install fails and you don't get the required drivers.
> > HP/Compaq is not showing any updated EFS although I did report this
> > March 12th. Normally by now I would have updated a portion of my client
> > base and would have something to report. The problem now is that we
> > do not want to be supporting two versions of O/S, so have left most
> > people on 5.0.6.
>
> You can fix the above problem by patching the variable name in
> pci/Driver.o to remove the conflict. The variable is internal to
> pci/Driver.o, so its name can be changed without a matching change
> elsewhere. The variable in Compaq's driver is internal to it. We just
> have to resolve the name collision:
>
> # cd /etc/conf/pack.d/pci
> # cp -p Driver.o Driver.o.orig
> # strings -a -o Driver.o | grep -i debug
> 18790 pci_debug
> # bs=1 count=9 oseek=18790 of=Driver.o
> 9+0 records in
> 9+0 records out
> # strings -a -o Driver.o | grep -i debug
> 18790 pci_Debug
> # cd /etc/conf/cf.d
> # ./link_unix
>

I will try this on Sunday, noting the posts from JPR.

.
> > I am testing Progress 9.1b on 5.0.7, with a ProLiant ML530G3. So far
> > the system has locked up about 6 times with the database running, no
> > panic dumps as the system is completely locked. The server runs fine
> > for days without Progress running, locks up in a few hours after
> > the database is started. No idea why yet.
>
> Is this without database activity?? Doesn't the Compaq watchdog stuff
> kick in and reboot the system? (Not that that would be much better, but
> it's odd to actually _hang_ a system with a watchdog in it...)

>
> >Bela<

Spent six hours on that server last night and this morning. I linked in
the scodb, but after a lockup there is no keyboard input accepted ( not
even CAPS-LOCK or NUM-LOCK toggle the leds ). Yes, the Compaq watchdog
does kick in and reboot the server if I wait. After a reboot I can get
Progress to start up, but if a wait a while the machine locks instantly
when the database goes to start. With a bit more debugging I think
there may be a relationship between a consumption of streams resources
as reported in "netstat -m" under "streams memory in use" ( SMiU ) and
the system locking up. With just a root login on tty01 running netstat
and a graphic login on tty02 all is well. If I fire up mozilla, let
it bring up the sco home page, then watch the SMiU it slowly
climbs up. Looks like it will go from ~180k to 4MB in 11 minutes.
Starting Progress at that point, or even using Mozilla to go to more
web pages instantly locks the system. I repeated the test 3 times.

If I just bring up Progress ( no graphical login ) the consumption is much
slower, maybe 2k per minute. The server had frozen up and the Compaq
watchdog rebooted it during the week, after 35.5 hours. As far as I can
tell there was very little database use, the Progress server was just brought
and left running.

The HW is a ProLiant ML530, single 2.4Ghz Xeon with hyperthreading off,
1536MB of ram, and a 6400 raid controller. The NIC is a Broadcom with
driver version 6.0.129 embedded on the system board. I installed an
Intel PRO100 card to replace the BCME, which I disabled in the bios
and in netconfig. There was no change in symptoms, or speed of the
consumption of SMiU.

The SW is 5.0.7 with OSS656B and EFS5.60a ( which is current ).
I updated the system to osr507mp1 and retested, but no change.

I can ftp or rcp without any problem, copied 8GB to the machine without
any apparent residual increase in SMiU, but after running mozilla for
a few minutes the next attempt at copying data piped through a rcmd
froze the system.

The machine is not in production at all, it is just for compatibilty
testing at this point. Any ideas?
  

-- 
Michael Brown
The Kingsway Group

Relevant Pages

  • Re: Access Databases & IIS 6.0
    ... PID to Application Pool." ... You don't need to reboot the server. ... I administer a Windows Server 2003 running IIS 6. ... Unable to establish connection to database. ...
    (microsoft.public.inetserver.iis.security)
  • All coreutils binaries segfault, requiring complete reinstall of linux
    ... After creating a new database with Progress DB 9.1D09, ... This last server was FC3, and had run "yum update" a few days ago, so can ... And interestingly, not ALL binaries in /bin segfault - vi, rpm, ...
    (Fedora)
  • Re: data set fill causes app hang
    ... well this app is a file importer, so it will load huge data sets into the ... process them then push them back to the database server... ... > info back and update a progress bar. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: I have a database on a network drive that I use for archiving purposes, but when the server is r
    ... server service and the startup parameters of the instance. ... cases the database always come up suspect after a reboot. ...
    (comp.databases.ms-sqlserver)
  • Re: system reboot
    ... Active Directory is essentially a database, and like most databases, it has index and journaling for recovery in the event of an unexpected shutdown. ... So keep an eye on your event logs to look for corruption...and you should determine *why* the server rebooted on its own. ... Even if windows chose to reboot, it would've cleaned up after itself, so it sounds as though the problem is in a lower layer than the OS. ...
    (microsoft.public.windows.server.sbs)