Re: PANIC 0X0000000E on SCO OpenServer 5.0.5

I have the same problem in my database server. I have installed INFORMIX IDS 7.30X and INFORMIX 4GL 7.20X I have a database server, one local aplication server and one remote aplication server (It is connected with routers). All of servers use SCO 5.0.5 Enterprise version. furthermore now I installed the SLS 0SS605A patch, but the problem continues. Thanks for yours comments Ruben In article <3A5DBE36.DDA166F3@strhold.it>, fred@strhold.it wrote: > Hello ! > > I'd like to hear the opinions from the group about the > following problem. > > HW details : > > Intel PII 300Mhz with 64MB RAM > HD EIDE 4.3GB > Adaptec 2940AU SCSI Controller + Tandberg TAPE > Realtec RTC 8029 PCI Ethernet controller > > SW details : > > SCO OS 5.0.5 + RS505A + OSS497C + OSS471F > SCO MorningStar PPP 2.1.3 > Squid + Fetchmail from Skunkware 98 > > This machine is connected to the 'Net by making > use of a 56k serial modem; the connection is > powered by MSTPPP in order to serve a Windows > based LAN. As you can see, we're presently > using Squid as proxy server and fetchmail to > gather email messages from a remote server. > > This machine worked pretty well until last week; > in fact we had it on our labs to test the new > connection (it was previously connected to a > Specialix JetStream device via a phone line > while now it connects to a local provider) and > we kept it running for hours without apparent > problems. As soon as we returned it to the > customer, it started panicing. > > I have to say that we did not change anything > related to the kernel; in fact we've only > changed the MorningStar configuration in order > to dial a different number and added the above > PD software (Squid + Fetchmail). > > The problem is thatnow the above machine panics from 3 > to 4 times a day; by saving the dump stored on swap > I've complete info about what the kernel was doing > before panicing. > > The first thing I've noticed is that the CS:EIP > registers are always set at the same value, as > follows : > > cs 0x00000158 eip 0xF00CF2D6 > > Today the machine paniced 3 times in a row and I've > been able to check that cs and eip values are > always set to the above ones. > > Also, something makes me think about the > Realtec adapter; in fact every kernel > stack trace begins with the following > piece of info : > > [Panic # 1 ] > > Kernel Stack before Trap: > STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS > e00006e8 e0000730 r3ehwput (0,0xfcf0a740,0xfcf0a740,0) > e0000738 e0000754 r3edata (0xfce28e7c,0xfcf0a740,net0cardinfo) > e000075c e0000768 r3euwput > (0xfce28e7c,0xfcf0a740,0xfcf0a740,net0sapinfo+0x68) > > [Panic # 2 ] > > Kernel Stack before Trap: > STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS > e0000bd8 e0000c20 r3ehwput (0,0xfcf0b7a8,0,r3edevice) > e0000c28 e0000c38 r3edequeue (0xfce28e7c,ivect,r3edevice,0x5ea) > e0000c40 e0000c5c r3estrtout (0,ivect,0,0xb) > > [Panic # 3 ] > > Kernel Stack before Trap: > STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS > e000078c e00007d4 r3ehwput (0,0xfcf0a470,0xfcf0a470,0) > e00007dc e00007f8 r3edata (0xfce28e7c,0xfcf0a470,net0cardinfo) > e0000800 e000080c r3euwput > (0xfce28e7c,0xfcf0a470,0xfcf0a470,net0sapinfo+0x68) > > As far as I can tell, routines starting with "r3" relates to > the Realtec driver; since Realtec has been slammered more than > once here in the group I'm under the impression that something > is definitely wrong with the card itself. > > To add confusion and mistery to this problem I have to say > that a couple of days ago this machine ran for a whole day > without problems (please keep in mind that this machine is > never powered off) while in the last 2 days it paniced > 5 times. > > Please keep in mind that this machine is under > control of a UPS device which should be able to filter > voltage spikes and things like that. > > Also, this machine mainly panics while connected to the > Internet (as far as I've been told, it never crashed during > the night or while operating off-line but I'm not quite sure > about that) so I could think about network related problems > (bad/malformed packets, HW problems and so on). > > I've just asked the person in charge of this machine to > replace RAM just to be sure but I'm not sure it's a memory > related problem. I'm more inclined to ask him to replace the > NIC with another brand/model given the trace being > produced but I'm wide opened to suggestions. > > Best, > Roberto > -- > --------------------------------------------------------------------- > Roberto Zini email : fred@strhold.it > Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY) > --------------------------------------------------------------------- > "Has anybody around here seen an aircraft carrier?" > (Pete "Maverick" Mitchell - Top Gun) > -- INFORMIX Sent via Deja.com http://www.deja.com/

Ruben Dutan wrote: > > I have the same problem in my database server. > > I have installed INFORMIX IDS 7.30X and INFORMIX 4GL 7.20X > I have a database server, one local aplication server > and one remote aplication server (It is connected with routers). > > All of servers use SCO 5.0.5 Enterprise version. > furthermore now I installed the SLS 0SS605A patch, but the problem > continues. > > Thanks for yours comments > Ruben > > In article <3A5DBE36.DDA166F3@strhold.it>, > fred@strhold.it wrote: > > Hello ! > > > > I'd like to hear the opinions from the group about the > > following problem. > > > > HW details : > > > > Intel PII 300Mhz with 64MB RAM > > HD EIDE 4.3GB > > Adaptec 2940AU SCSI Controller + Tandberg TAPE > > Realtec RTC 8029 PCI Ethernet controller > > > > SW details : > > > > SCO OS 5.0.5 + RS505A + OSS497C + OSS471F > > SCO MorningStar PPP 2.1.3 > > Squid + Fetchmail from Skunkware 98 > > > > This machine is connected to the 'Net by making > > use of a 56k serial modem; the connection is > > powered by MSTPPP in order to serve a Windows > > based LAN. As you can see, we're presently > > using Squid as proxy server and fetchmail to > > gather email messages from a remote server. > > > > This machine worked pretty well until last week; > > in fact we had it on our labs to test the new > > connection (it was previously connected to a > > Specialix JetStream device via a phone line > > while now it connects to a local provider) and > > we kept it running for hours without apparent > > problems. As soon as we returned it to the > > customer, it started panicing. > > > > I have to say that we did not change anything > > related to the kernel; in fact we've only > > changed the MorningStar configuration in order > > to dial a different number and added the above > > PD software (Squid + Fetchmail). > > > > The problem is thatnow the above machine panics from 3 > > to 4 times a day; by saving the dump stored on swap > > I've complete info about what the kernel was doing > > before panicing. > > > > The first thing I've noticed is that the CS:EIP > > registers are always set at the same value, as > > follows : > > > > cs 0x00000158 eip 0xF00CF2D6 > > > > Today the machine paniced 3 times in a row and I've > > been able to check that cs and eip values are > > always set to the above ones. > > > > Also, something makes me think about the > > Realtec adapter; in fact every kernel > > stack trace begins with the following > > piece of info : > > > > [Panic # 1 ] > > > > Kernel Stack before Trap: > > STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS > > e00006e8 e0000730 r3ehwput (0,0xfcf0a740,0xfcf0a740,0) > > e0000738 e0000754 r3edata (0xfce28e7c,0xfcf0a740,net0cardinfo) > > e000075c e0000768 r3euwput > > (0xfce28e7c,0xfcf0a740,0xfcf0a740,net0sapinfo+0x68) > > > > [Panic # 2 ] > > > > Kernel Stack before Trap: > > STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS > > e0000bd8 e0000c20 r3ehwput (0,0xfcf0b7a8,0,r3edevice) > > e0000c28 e0000c38 r3edequeue (0xfce28e7c,ivect,r3edevice,0x5ea) > > e0000c40 e0000c5c r3estrtout (0,ivect,0,0xb) > > > > [Panic # 3 ] > > > > Kernel Stack before Trap: > > STKADDR FRAMEPTR FUNCTION POSSIBLE ARGUMENTS > > e000078c e00007d4 r3ehwput (0,0xfcf0a470,0xfcf0a470,0) > > e00007dc e00007f8 r3edata (0xfce28e7c,0xfcf0a470,net0cardinfo) > > e0000800 e000080c r3euwput > > (0xfce28e7c,0xfcf0a470,0xfcf0a470,net0sapinfo+0x68) > > > > As far as I can tell, routines starting with "r3" relates to > > the Realtec driver; since Realtec has been slammered more than > > once here in the group I'm under the impression that something > > is definitely wrong with the card itself. > > > > To add confusion and mistery to this problem I have to say > > that a couple of days ago this machine ran for a whole day > > without problems (please keep in mind that this machine is > > never powered off) while in the last 2 days it paniced > > 5 times. > > > > Please keep in mind that this machine is under > > control of a UPS device which should be able to filter > > voltage spikes and things like that. > > > > Also, this machine mainly panics while connected to the > > Internet (as far as I've been told, it never crashed during > > the night or while operating off-line but I'm not quite sure > > about that) so I could think about network related problems > > (bad/malformed packets, HW problems and so on). > > > > I've just asked the person in charge of this machine to > > replace RAM just to be sure but I'm not sure it's a memory > > related problem. I'm more inclined to ask him to replace the > > NIC with another brand/model given the trace being > > produced but I'm wide opened to suggestions. > > > > Best, > > Roberto > > -- > > --------------------------------------------------------------------- > > Roberto Zini email : fred@strhold.it > > Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY) > > --------------------------------------------------------------------- > > "Has anybody around here seen an aircraft carrier?" > > (Pete "Maverick" Mitchell - Top Gun) > > > > -- > INFORMIX > > Sent via Deja.com > http://www.deja.com/ Since you had moved the machine to your offices, and then back to the clients I would strongly suspect something like a board or DIMM card has popped partially out. It may be as simple as re-seating all the daughter boards AND reconnecting all the cables. I often suspect the *internal* power supply in cases like yours. And the machine (PII 300 Mhz) appears to be old enough that a dusty environment may have started shorting it out at random moments. -- --------------------------------------------- Pat Welch, UBB Computer Services SCO Authorized Reseller Unix/Hardware/BB Sales & Support (209) 745-1401 Fax: (209) 745-5640 Nationwide pager: (800) 608-7122 E-mail: patubb@inreach.com ----------------------------------------------

Ruben Dutan wrote: > > I have the same problem in my database server. > > I have installed INFORMIX IDS 7.30X and INFORMIX 4GL 7.20X > I have a database server, one local aplication server > and one remote aplication server (It is connected with routers). > > All of servers use SCO 5.0.5 Enterprise version. > furthermore now I installed the SLS 0SS605A patch, but the problem > continues. > > Thanks for yours comments > Ruben > [snip] Ruben, are you actually able to save the memory dump to a file and inspecting it ? I've had to manually modify the /etc/dumpsave script in order to accomplish this since the original file does not allow you to do that; it shouldn't be difficult to make these changes but should you have problems, please let me know and I'll send the modified file to you. [Hint : check out http://www.sco.com/cgi-bin/ssl_reference?105619] Once you have the memory dump stored on a file, run the following command : crash -d <your_dump_file> -w /tmp/report.txt At the prompt (">"), issue the following commands : > panic > trace > stack > user > proc > u -f > quit Next take a look at the /tmp/report.txt file and see if you can find something which repeats all over the PANICs; as an example, I've been able to find that the CS:EIP registers were always set to the same value and that the "kernel stack before trap" always started with a reference to a Realtek driver routine. Hope this helps ! Best, Roberto -- --------------------------------------------------------------------- Roberto Zini email : fred@strhold.it Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY) --------------------------------------------------------------------- "Has anybody around here seen an aircraft carrier?" (Pete "Maverick" Mitchell - Top Gun)