lkml.org 
[lkml]   [1996]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What to do (fwd)

On Sat, 7 Sep 1996, D. Chiodo wrote:

> Date: Sat, 7 Sep 1996 21:52:50 -0400 (EDT)
> From: "D. Chiodo" <djc@hal.microwave.com>
> To: Linus Torvalds <torvalds@cs.Helsinki.FI>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: What to do (fwd)
>
> On Sat, 7 Sep 1996, Linus Torvalds wrote:
>
> > Date: Sat, 7 Sep 1996 23:31:57 +0300 (EET DST)
> > From: Linus Torvalds <torvalds@cs.Helsinki.FI>
> > To: "D. Chiodo" <djc@hal.microwave.com>
> > Cc: linux-kernel@vger.rutgers.edu
> > Subject: Re: What to do (fwd)
> >
> >
> >
> > On Thu, 5 Sep 1996, D. Chiodo wrote:
> > >
> > > I had posted this previously, but no one had any comments/advice/fixes.. I
> > > suspect it was becuase I buried the data at the bottom..
> > >
> > > Trace: 120a97 <close_fp+33/84>
> > > Trace: 1150e6 <do_exit+116/1f0>
> > > Trace: 2855e40
> > > Trace: 1151c0 <sys_exit>
> > > Trace: 1151ce <sys_exit+e/10>
> > > Trace: 283f41b
> > > Trace: 2855e40
> > > Trace: 10fae8 <do_page_fault>
> > > Trace: 10a63d <error_code+3d/50>
> > > Trace: 10a429 <lcall7+49/50>
> >
> > Looks like you're using the iBCS2 module.. Are you sure the module
> > matches the kernel? If you have kerneld, make sure it isn't loading an
> > old iBCS2 module by mistake or something like that..
> >
> > Linus
>
> First, Thank you very much for your quick reply (Not to mention thanks for
> the alternative to using MickeySoft and Apple O/S's -I work for an ISP
> that uses Linux for its primary servers..)
>
> Yes. I grabbed the latest ibcs, and done a fresh compile.
>
> (And not using kerneld, I have a direct call to insmod in my rc files)
>
> Oops (not the kernel type tho)- Just went to check my version of ibcs, and
> it seems the "latest" version I grabbed was two years old.. I have one
> with:
>
> Thu Jun 6 17:21:00 GMT/BST 1996
>
> as the header in Changelog that I was using previously, that I still got
> the errors with.. I will recompile/reload that one just to be sure though
>
> (Cant test it until Monday at work - it only manifests itself when
> installing/running WP, and I am remote via 28K at the moment)
>
> What _is_ the latest version of iBCS? (And is there an "iBCS" and an
> "iBCS2", the latter of which is newer?)
>
>

Ok.. I reinstalled the Jun 6 iBCS, and I still get the same errors.

Here is a play by play of everything leading up to this:

I had a 1.3.100 system, with everything running fine, including WP/SCO.. I
had a 400MB root fs, and another 400MB drive on a dummy mount point with
stuff like usr/src and usr/local symlinked to subdirs from it..

The second drive crashed hard.. I got a 1Gig, and rebuilt a new system,
starting with Slackware 3.0 (Kernel 1.2.13), and upgrading to
2.0.10/12/etc now 18

I still had a copy of WP on the old drive, so I tried to use it from
there.. It runs, but when it starts I got an odd message about "Unable to
start a new process", and when it exits, it doesn't release the "licences"
(license server on same machine), and I get "Segmentation Fault"...

*** IMPORTANT *** ::: IF I mount the old root file system, and chroot to
its mount point, and run WP from there, (using TCP/IP to get to the local
X server) it runs _PERFECTLY!_ I don't get the message, it releases the
licenses, doesn't GP.. ** Same iBCS, same kernel ** .. This obviously
cannot be a permanent solution.. I need it to work right..

I beleive it cannot be the kernel that is causing this (although it may be
aggravating the symptoms)..

I have PORED over the old filesystem, comparing it with the new, looking
for anything that might be affecting this.. I have concentrated on the
libraries, but as far as I can tell nothing is missing from the new
system.. All library versions seem to be the same.. I've looked over /dev
for anything that might be missing.. I don't know what else to look at..

How can I find out what is causing this and how to fix it?

I ALSO tried reinstalling WP from scratch on the new system.. It
installed, but while it was installing, a billion GP's scrolled up the
console.. And not just from the WP programs, but common things like "ln"
and "rm"... However, when it was done, the resulting install wouldnt run
at all..

I am completely confused on this..

Kernel is 1.0.18.. libc 5.3.12 and 4.7.6
(Note: although the symlink is there from libc.so.5 -> libc.so.5.3.12,
ldconfig -v doesn't show it.. But the OLD system was like this too)

I don't know what other information would help..

Here is the output from the insmod of iBCS..

hal:/lib/modules/2.0.18/misc# insmod -v iBCS
Section 1: (.text) at 0x400b9010
Section 2: (.rel.text) at 0x8054638
Section 3: (.rodata) at 0x400cb634
Section 4: (.rel.rodata) at 0x8059260
Section 5: (.data) at 0x400cf358
Section 6: (.rel.data) at 0x8059328
Section 7: (.bss) at 0x400d29c8
Section 9: (.comment) at 0x400d26f8
Section 10: (.shstrtab) at 0x805c898
Section 11: (.symtab) at 0x805c900
Section 12: (.strtab) at 0x805f5c0
textseg = 0x400b9008
bss_size = 24
last byte = 0x400d29e0
module size = 104920
versioned kernel: yes
versioned module: yes
ELF kernel
ELF module

Here is the GP from when xwp exits:

general protection: 0000
CPU: 0
EIP: 0010:[<0012c808>]
EFLAGS: 00010286
eax: f000ef6f ebx: 01216414 ecx: 00000000 edx: 0024fb4c
esi: 00000000 edi: f000ef6f ebp: 0119a810 esp: 0122cf10
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process xwp (pid: 183, process nr: 51, stackpage=0122c000)
Stack: 00000025 0012094b 01216414 00000000 00000025 00000005 00000001 00115082
00000000 00000001 00860001 02855e18 0011515c 0011516a 00000000 0283f423
00000000 08058560 0086549c bfffead8 bfffeae4 00214000 0196a000 0196a065
Call Trace: [<0012094b>] [<00115082>] [<02855e18>] [<0011515c>]
[<0011516a>] [<0283f423>] [<02855e18>]
[<0010fb20>] [<0010a62d>] [<0010a419>]
Code: 8b 50 48 85 d2 74 22 f6 42 1c 01 74 0f 53 83 c0 48 50 e8 15

And the ksymoops translation:

>>EIP: 12c808 <locks_remove_locks+c/38>
Trace: 12094b <close_fp+37/5c>
Trace: 115082 <do_exit+112/1ec>
Trace: 2855e18
Trace: 11515c <sys_exit>
Trace: 11516a <sys_exit+e/10>
Trace: 283f423
Trace: 2855e18
Trace: 10fb20 <do_page_fault>
Trace: 10a62d <error_code+3d/50>
Trace: 10a419 <lcall7+49/50>

Code: 12c808 <locks_remove_locks+c/38> movl 0x48(%eax),%edx
Code: 12c80b <locks_remove_locks+f/38> testl %edx,%edx
Code: 12c80d <locks_remove_locks+11/38> je 12c831 <locks_remove_locks+35/38>
Code: 12c80f <locks_remove_locks+13/38> testb $0x1,0x1c(%edx)
Code: 12c813 <locks_remove_locks+17/38> je 12c824 <locks_remove_locks+28/38>
Code: 12c815 <locks_remove_locks+19/38> pushl %ebx
Code: 12c816 <locks_remove_locks+1a/38> addl $0x48,%eax
Code: 12c819 <locks_remove_locks+1d/38> pushl %eax
Code: 12c81a <locks_remove_locks+1e/38> call 9090002c <_EIP+9090002c>
Code: 12c81f <locks_remove_locks+23/38> nop




\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.047 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site