Bug 17422

On Thu, Mar 16, 2000 at 07:06:03PM -0800, larse@isi.edu wrote:
> 
> >Number:         17422
> >Category:       kern
> >Synopsis:       4.0-STABLE: top: nlist failed
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    freebsd-bugs
> >State:          open
> >Quarter:        
> >Keywords:       
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Thu Mar 16 19:10:01 PST 2000
> >Closed-Date:
> >Last-Modified:
> >Originator:     Lars Eggert
> >Release:        4.0-STABLE
> >Organization:
> >Environment:
> FreeBSD hbo.isi.edu 4.0-STABLE FreeBSD 4.0-STABLE #16: Thu Mar 16 16:13:45 PST 2000     root@hbo.isi.edu:/usr/src/sys/compile/PRECISION  i386
> 
> >Description:
> Got 4.0-STABLE from cvsup, made world and recompiled/installed kernel.
> 
> hbo# top
> top: nlist failed
> 
> I tried remaking/installing top and libkvm, no change.
> 
> I have also seen this under 4.0-RELEASE before moving to -STABLE,
> but thought it was a quirk because I had not yet compiled a custom
> kernel.
> >How-To-Repeat:
> see above
> >Fix:
> 
Could you please try the following patch?


-- 
Ruslan Ermilov		Sysadmin and DBA of the
ru@ucb.crimea.ua	United Commercial Bank,
ru@FreeBSD.org		FreeBSD committer,
+380.652.247.647	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

  ruslan> Could you please try the following patch?

Ruslan, I *do* use loader (I get the "BTX loader" output when
booting). However, the patch you sent does make top work for my
configuration, too - so I'm happy.

Thanks,
Lars
________________________________________________________________________
Lars Eggert <larse@isi.edu>               Information Sciences Institute
http://www.isi.edu/~larse/             University of Southern California

The patches by Bruce worked for me too...

Comment 4 ru 2000-05-05 09:58:28 UTC

Responsible Changed
From-To: freebsd-bugs->bde

Attempt to make Bruce commit his own patches :) 

ru@FreeBSD.ORG wrote:
> Synopsis: 4.0-STABLE: top: nlist failed
> 
> Responsible-Changed-From-To: freebsd-bugs->bde
> Responsible-Changed-By: ru
> Responsible-Changed-When: Fri May 5 01:58:28 PDT 2000
> Responsible-Changed-Why: 
> Attempt to make Bruce commit his own patches :)

The patch is a workaround, it's not a correct fix.  It assumes an ELF
kernel for starters.

Cheers,
-Peter

Comment 6 ru 2000-05-06 08:07:19 UTC

On Fri, May 05, 2000 at 11:30:02AM -0700, Peter Wemm wrote:
> ru@FreeBSD.ORG wrote:
> > Synopsis: 4.0-STABLE: top: nlist failed
> > 
> > Responsible-Changed-From-To: freebsd-bugs->bde
> > Responsible-Changed-By: ru
> > Responsible-Changed-When: Fri May 5 01:58:28 PDT 2000
> > Responsible-Changed-Why: 
> > Attempt to make Bruce commit his own patches :)
> 
> The patch is a workaround, it's not a correct fix.  It assumes an ELF
> kernel for starters.
> 
Because you were the person who made libkvm(3) use kldsym(2) to lookup
symbol values without kvm_mkdb, maybe it is more correct if you take
this PR?

-- 
Ruslan Ermilov		Sysadmin and DBA of the
ru@ucb.crimea.ua	United Commercial Bank,
ru@FreeBSD.org		FreeBSD committer,
+380.652.247.647	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

> 
> >Description:
> Got 4.0-STABLE from cvsup, made world and recompiled/installed kernel.
> 
> hbo# top
> top: nlist failed
> 
> I tried remaking/installing top and libkvm, no change.
> 
> I have also seen this under 4.0-RELEASE before moving to -STABLE,
> but thought it was a quirk because I had not yet compiled a custom
> kernel.
> >How-To-Repeat:
> see above
> >Fix:
> 
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 

I'm seeing the same thing on an SMP box here at work. I'm willing to let
someone poke around on it if need be.

-- Kevin

For recent versions of FreeBSD (specifically: 4.1-STABLE #1:
Sat Aug 19 22:37:56 CEST 2000), the patch doesn't work anymore
due to the line numbers having changed too much. The
locore.s-patch isn't necessary anymore; a machdep.c-patch that
works is:

*** machdep.c.orig      Sat Aug  5 00:31:06 2000
--- machdep.c   Fri Aug 11 17:36:05 2000
***************
*** 1802,1807 ****
--- 1802,1821 ----
        if (bootinfo.bi_modulep) {
                preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE;
                preload_bootstrap_relocate(KERNBASE);
+       } else {
+               static u_int32_t oldmoduledata[] = {
+                       1, sizeof("kernel"), 0, 0,
+                       2, sizeof("elf kernel"), 0, 0, 0,
+                       0x8004, 4, 0,
+                       0x8003, 4, 0,
+                       0, 0,
+               };
+
+               preload_metadata = (caddr_t)&oldmoduledata[0];
+               strcpy((char *)&oldmoduledata[2], "kernel");
+               strcpy((char *)&oldmoduledata[6], "elf kernel");
+               oldmoduledata[11] = roundup2(bootinfo.bi_esymtab, 4);
+               oldmoduledata[14] = bootinfo.bi_symtab;
        }
        if (bootinfo.bi_envp)
                kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;

-----BEGIN PGP SIGNED MESSAGE-----

Hi!

I have the same problem on a diskless system using etherboot to
load the kernel using tftp.

>*** machdep.c.orig      Sat Aug  5 00:31:06 2000
>--- machdep.c   Fri Aug 11 17:36:05 2000
>***************
>*** 1802,1807 ****
>--- 1802,1821 ----
>	if (bootinfo.bi_modulep) {
>		preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE;
>		preload_bootstrap_relocate(KERNBASE);
>+       } else {
>+               static u_int32_t oldmoduledata[] = {
>+                       1, sizeof("kernel"), 0, 0,
>+                       2, sizeof("elf kernel"), 0, 0, 0,
>+                       0x8004, 4, 0,
>+                       0x8003, 4, 0,
>+                       0, 0,
>+               };
>+
>+               preload_metadata = (caddr_t)&oldmoduledata[0];
>+               strcpy((char *)&oldmoduledata[2], "kernel");
>+               strcpy((char *)&oldmoduledata[6], "elf kernel");
>+               oldmoduledata[11] = roundup2(bootinfo.bi_esymtab, 4);
>+               oldmoduledata[14] = bootinfo.bi_symtab;
>	}
>	if (bootinfo.bi_envp)
>	kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;

I tried this patch on FreeBSD 4.2-BETA, but the kernel panic()ed. :-(
Unfortunately, I was not able to see the messages on the screen,
because the system (and its screen) is located in a distance of about
20Km. Someone mailed me part of the panic message:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code               = supervisor read, page not present

73, Mario
--
Mario Klebsch						mario@klebsch.de
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB  1483 30CE 9FB2 A047 9CE0
 Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5  8B98 9464 53FF 9382 F518


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: VyT6KBPB5A4raLEQxcWGtUAhTVkCPNNL

iQA/AwUBOiamhzDOn7KgR5zgEQK5FQCeJgOluuKSQqVPb5rRYQECC+rq608An2+A
Q1DEm6v7AEOFukAD4PsWl6yL
=zS/h
-----END PGP SIGNATURE-----

I found that the patch I've been using wouldn't work anymore
because the source changed too much. I modified it; without
actually knowing how it works, admittedly, so I can't be sure
it's still good. The system appears to work just fine, however,
so I can still do without /boot/loader.

Could someone who knows machdep.c matters please review the thing and
close this very old PR? I've been using versions of this patch ever
since, and it always worked. Currently I'm using 4.4-Stable.


--- sys/i386/i386/machdep.c.orig        Thu Sep 20 23:08:01 2001
+++ sys/i386/i386/machdep.c     Thu Sep 20 23:11:12 2001
@@ -1823,7 +1823,19 @@
                preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE;
                preload_bootstrap_relocate(KERNBASE);
        } else {
-               metadata_missing = 1;
+              static u_int32_t oldmoduledata[] = {
+                      1, sizeof("kernel"), 0, 0,
+                      2, sizeof("elf kernel"), 0, 0, 0,
+                      0x8004, 4, 0,
+                      0x8003, 4, 0,
+                      0, 0,
+              };
+
+              preload_metadata = (caddr_t)&oldmoduledata[0];
+              strcpy((char *)&oldmoduledata[2], "kernel");
+              strcpy((char *)&oldmoduledata[6], "elf kernel");
+              oldmoduledata[11] = roundup2(bootinfo.bi_esymtab, 4);
+              oldmoduledata[14] = bootinfo.bi_symtab;
        }
        if (bootinfo.bi_envp)
                kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;

Hi,

as far as I'm concerned (as originator), this PR can be closed. It 
turned out to be faulty hardware, if I remember correctly.

However, people are discussing a related but separate issue in the 
followups, and I'm not sure whether that has been addressed (since it 
wasn't the original problem I opened the PR about.)

Lars
-- 
Lars Eggert <larse@isi.edu>           USC Information Sciences Institute

Just for curiosity, what is the status of this PR? I'm using 4.9-RELEASE 
and am still getting this error. "pstat" also gives "undefined symbol: 
_numvnodes"; I don't know if that would be something to do with it or no.

Thanks!

-Felipe Gasper
Urbana, IL  USA

On Tue, 3 Feb 2004, Felipe Gasper wrote:

>  Just for curiosity, what is the status of this PR? I'm using 4.9-RELEASE
>  and am still getting this error. "pstat" also gives "undefined symbol:
>  _numvnodes"; I don't know if that would be something to do with it or no.

The bug is still present in RELENG_4: the system must be booted with
/boot/loader to get these symbols.

The bug is almost moot in -current.  Most statistics utilities including
pstat use sysctl() instead of nlist()+kvm_read() to read kernel data in
the live kernel case, so they don't need kldsym() to return these symbols.
The symbols are missing mainly for kernel debugging using ddb, but using
DDB_NOKLDSYM is a better workaround for that and other bugs in loading
symbols at boot time.

My patch in the PR followup should be harmless but there is a report
of it causing panics.  It caused panics in -current because initialization
of the bootinfo was broken by gcc putting zero data in the bss; this
resulted in the symbol table info in bootinfo being all-0 and passing
the 0's up to kern_linker.c using the fake module didn't work.  The
initialization has been fixed in -current and in
RELENG_4-compiled-by-gcc-3.3, but other ways of passing null symbol
info might cause problems.  boot2 always passes non-null symbol info.
This used to be for ddb, but became essential for kernel symbols.

Bruce

Comment 14 Remko Lodder 2006-12-30 16:34:45 UTC

State Changed
From-To: open->feedback

Hello is this still a problem with freebsd 6.x? 

Comment 15 Remko Lodder 2006-12-30 16:34:45 UTC

Responsible Changed
From-To: bde->remko

grab the pr

Comment 16 Remko Lodder 2006-12-30 16:37:54 UTC

State Changed
From-To: feedback->closed

the submitters email address does no longer exist, since i never seen 
this on releng_5 and beyond i will assume this got fixed, please correct 
me if am wrong.