NetBSD Problem Report #32816

From martin@aprisoft.de  Mon Feb 13 09:31:02 2006
Return-Path: <martin@aprisoft.de>
Received: from mail.duskware.de (mail.duskware.de [213.146.108.170])
	by narn.netbsd.org (Postfix) with ESMTP id C8C6363B8AD
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 13 Feb 2006 09:30:56 +0000 (UTC)
Message-Id: <200602130930.k1D9UrRN000986@martins.aprisoft.de>
Date: Mon, 13 Feb 2006 10:30:53 +0100 (CET)
From: Martin Husemann <martin@aprisoft.de>
Reply-To: martin@aprisoft.de
To: gnats-bugs@netbsd.org
Subject: amd64 can not load lkms
X-Send-Pr-Version: 3.95

>Number:         32816
>Category:       port-amd64
>Synopsis:       amd64 can not load lkms
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-amd64-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 13 09:35:00 +0000 2006
>Closed-Date:    Sun May 17 18:27:59 +0000 2009
>Last-Modified:  Sun May 17 18:27:59 +0000 2009
>Originator:     Martin Husemann
>Release:        NetBSD 3.99.15
>Organization:
>Environment:
System: NetBSD martins.aprisoft.de 3.99.15 NetBSD 3.99.15 (MARTINS) #0: Sat Feb 11 00:33:04 CET 2006 martin@martins.aprisoft.de:/usr/src/sys/arch/amd64/compile/MARTINS amd64
Architecture: x86_64
Machine: amd64
>Description:

I'm trying to get the nvidia nforce ethernet lkm working on amd64. It does
not load, crashes the kernel instead.

On investigation I found that I can not load *any* lkm.

I get a failed assertion: end < VM_MAX_KERNEL_ADDRESS
in uvm/uvm_km.c:479

with the backtrace:
uvm_km_check_empty()
uvm_map()
uvm_km_alloc()
lkmioctl()


(this is a DEBUG, DIAGNOSTIC, LOCKDEBUG kernel, and yes, I do know that the
pf.o would not have worked anyway in this kernel)
>How-To-Repeat:

On amd64 do: modload /usr/lkm/pf.o

>Fix:
n/a

>Release-Note:

>Audit-Trail:
From: Frank van der Linden <fvdl@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: port-amd64/32816: amd64 can not load lkms
Date: Mon, 13 Feb 2006 11:58:41 +0100

 On Mon, Feb 13, 2006 at 09:35:00AM +0000, Martin Husemann wrote:
 > I'm trying to get the nvidia nforce ethernet lkm working on amd64. It does
 > not load, crashes the kernel instead.
 > 
 > On investigation I found that I can not load *any* lkm.
 > 
 > I get a failed assertion: end < VM_MAX_KERNEL_ADDRESS
 > in uvm/uvm_km.c:479
 > 
 > with the backtrace:
 > uvm_km_check_empty()
 > uvm_map()
 > uvm_km_alloc()
 > lkmioctl()
 > 
 > 
 > (this is a DEBUG, DIAGNOSTIC, LOCKDEBUG kernel, and yes, I do know that the
 > pf.o would not have worked anyway in this kernel)

 The vm_map that LKM space is allocated from is lkm_map. This is usually
 the same as kernel_map, but on a few architectures it is different.
 On amd64 it is different, since the LKM code needs to be in proximity
 to the kernel code, to make the branches/jumps fit.

 end < VM_MAX_KERNEL_ADDRESS is *not* true for lkm_map space.

 The problem is that VM_MAP_IS_KERNEL, which the check is conditional
 on, is coded as: (vm_map_pmap(map) == pmap_kernel(). This is true
 for lkm_map as well, so things go wrong.

 I can't think of an easy fix right away, but it should not be
 too hard.

 - Frank

From: Matthias Drochner <M.Drochner@fz-juelich.de>
To: Frank van der Linden <fvdl@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: port-amd64/32816: amd64 can not load lkms 
Date: Mon, 13 Feb 2006 12:02:36 +0100

 Fwiw, it seems that I had some limited insight into that problem
 a while ago:
 http://mail-index.NetBSD.org/port-amd64/2004/08/10/0001.html
 Don't know how much of this is still valid (or has ever been).

 best regards
 Matthias


From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: RE: port-amd64/32816
Date: Thu, 27 Nov 2008 06:48:28 -0800 (PST)

 As reported oncurrent-users, here's another instance of this bug, with a 
 different back-trace.  In this case, kernel was apparently trying to 
 unmap a module.

 ---------- Forwarded message ----------
 Date: Wed, 26 Nov 2008 19:45:41 -0800 (PST)
 From: Paul Goyette <paul@whooppee.com>
 To: current-users@netbsd.org
 Subject: Module problem on amd64

 I've built a amd64 kernel without any file systems or compat code in the kernel 
 itself;  all of those options lines are commented out in the config file.

 I've installed the new kernel and the 5.99.03/modules and the new /boot (from 
 /usr/mdec/boot).

 Shortly after booting, while the various /etc/rc.d/ stuff is still going on, 
 the system panics.  Unfortunately, it seems to happen just as soon as xdm takes 
 over the console/display.

 So, I rebooted in single-user mode, and of course I needed to run fsck on my 
 root partition.  During the fsck, I got the following panic:

 panic: kernel diagnostic assertion "end <= VM_MAX_KERNEL_ADDRESS" failed: file 
 "/build/netbsd-local/src/sys/uvm/uvm_km.c", line 473
 fatal breakpoint trap in supervisor mode
 trap type 1 code 0 rip ffffffff80151565 cs 8 rflags 246 cr2 f0cbc9 cpl 0 rsp 
 ffff80004bedaa90
 Stopped in pid 0.8 (system) at netbsd:breakpoint+0x5:   leave
 0x1

 A backtrace produces

 breakpoint()+0x5
 panic()+0x260
 __kernassert()+0x2d
 uvm_km_pgremove_intrsafe()+0x198
 uvm_km_free()+0xb5
 kobj_unload()+0x58
 module_do_unload()+0xcd
 module_thread()+0xe9

 The config file and dmesg output available on request.

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/32816 CVS commit: src/sys/uvm
Date: Mon,  1 Dec 2008 10:54:57 +0000 (UTC)

 Module Name:	src
 Committed By:	ad
 Date:		Mon Dec  1 10:54:57 UTC 2008

 Modified Files:
 	src/sys/uvm: uvm_km.c uvm_km.h uvm_map.c

 Log Message:
 PR port-amd64/32816 amd64 can not load lkms

 Change some assertions to partially allow for VM_MAP_IS_KERNEL(map) where
 map is outside the range of kernel_map.


 To generate a diff of this commit:
 cvs rdiff -r1.101 -r1.102 src/sys/uvm/uvm_km.c
 cvs rdiff -r1.17 -r1.18 src/sys/uvm/uvm_km.h
 cvs rdiff -r1.263 -r1.264 src/sys/uvm/uvm_map.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->analyzed
State-Changed-By: ad@NetBSD.org
State-Changed-When: Mon, 01 Dec 2008 10:57:31 +0000
State-Changed-Why:
this is fixed in -current, needs a pullup


State-Changed-From-To: analyzed->pending-pullups
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Sun, 19 Apr 2009 02:18:59 +0000
State-Changed-Why:
pullup are submitted


From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: port-amd64/32816: amd64 can not load lkms
Date: Sun, 19 Apr 2009 12:18:17 +1000

 FYI:

 i tested andrew's fix for this on netbsd-5 and have submitted pullups.

 there's another problem with /dev/ksyms not working properly for modload
 (really ld(1)) that is workaroundable with -A /netbsd.


 .mrg.

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, martin@aprisoft.de
Subject: Re: port-amd64/32816: amd64 can not load lkms
Date: Sun, 19 Apr 2009 08:24:28 +0000

 On Sun, Apr 19, 2009 at 02:20:03AM +0000, matthew green wrote:

 > From: matthew green <mrg@eterna.com.au>
 > To: gnats-bugs@netbsd.org
 > Cc: netbsd-bugs@netbsd.org
 > Subject: Re: port-amd64/32816: amd64 can not load lkms
 > Date: Sun, 19 Apr 2009 12:18:17 +1000
 > 
 >  FYI:
 >  
 >  i tested andrew's fix for this on netbsd-5 and have submitted pullups.

 IIRC amd64 was loading lkms into the ISA I/O hole and so corrupting shadowed
 ROM images, video memory, etc.

 >  there's another problem with /dev/ksyms not working properly for modload
 >  (really ld(1)) that is workaroundable with -A /netbsd.

 I have a patch to disable /dev/ksyms usage in modload. It doesn't really
 matter for the LKMs that we ship.

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, martin@aprisoft.de
Subject: re: port-amd64/32816: amd64 can not load lkms
Date: Sun, 19 Apr 2009 20:08:24 +1000


     > From: matthew green <mrg@eterna.com.au>
     > To: gnats-bugs@netbsd.org
     > Cc: netbsd-bugs@netbsd.org
     > Subject: Re: port-amd64/32816: amd64 can not load lkms
     > Date: Sun, 19 Apr 2009 12:18:17 +1000
     > 
     >  FYI:
     >  
     >  i tested andrew's fix for this on netbsd-5 and have submitted pullups.

     IIRC amd64 was loading lkms into the ISA I/O hole and so corrupting shadowed
     ROM images, video memory, etc.

 DEV       0  -1/161 ffffffff80e24000 00b4 ffffffff80e4c820   2 pf

 this doesn't seem anywhere near ISA or VGA memory?

     >  there's another problem with /dev/ksyms not working properly for modload
     >  (really ld(1)) that is workaroundable with -A /netbsd.

     I have a patch to disable /dev/ksyms usage in modload. It doesn't really
     matter for the LKMs that we ship.

 i thought this used to work.

 i haven't gotten around to testing a netbsd-4 system to see what
 happens there yet though.


 .mrg.

From: Andrew Doran <ad@netbsd.org>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@NetBSD.org, port-amd64-maintainer@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@aprisoft.de
Subject: Re: port-amd64/32816: amd64 can not load lkms
Date: Mon, 20 Apr 2009 08:38:10 +0000

 On Sun, Apr 19, 2009 at 08:08:24PM +1000, matthew green wrote:

 >     > From: matthew green <mrg@eterna.com.au>
 >     > To: gnats-bugs@netbsd.org
 >     > Cc: netbsd-bugs@netbsd.org
 >     > Subject: Re: port-amd64/32816: amd64 can not load lkms
 >     > Date: Sun, 19 Apr 2009 12:18:17 +1000
 >     > 
 >     >  FYI:
 >     >  
 >     >  i tested andrew's fix for this on netbsd-5 and have submitted pullups.
 >     
 >     IIRC amd64 was loading lkms into the ISA I/O hole and so corrupting shadowed
 >     ROM images, video memory, etc.
 > 
 > DEV       0  -1/161 ffffffff80e24000 00b4 ffffffff80e4c820   2 pf
 > 
 > this doesn't seem anywhere near ISA or VGA memory?

 I misremembered. It loaded modules at atdevbase, blatting the ISA hole in
 the process.

 >     >  there's another problem with /dev/ksyms not working properly for modload
 >     >  (really ld(1)) that is workaroundable with -A /netbsd.
 >     
 >     I have a patch to disable /dev/ksyms usage in modload. It doesn't really
 >     matter for the LKMs that we ship.
 > 
 > i thought this used to work.

 By luck I guess.

State-Changed-From-To: pending-pullups->closed
State-Changed-By: snj@NetBSD.org
State-Changed-When: Sun, 17 May 2009 18:27:59 +0000
State-Changed-Why:
This has been pulled up and is part of 5.0.


>Unformatted:

Home	PR Database Search