Re: VIMAGE + kldload wlan + kldload wtap panic
I added VNET_DEBUG and noticed this warning (original scan_task code): CURVNET_SET() recursion in sosend() line 1350, prev in kern_kldload() 0xfe0002202c40 - 0xfe0002202c40 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 sosend() at sosend+0xbd clnt_vc_call() at clnt_vc_call+0x3e6 clnt_reconnect_call() at clnt_reconnect_call+0xf5 newnfs_request() at newnfs_request+0x9fb nfscl_request() at nfscl_request+0x72 nfsrpc_lookup() at nfsrpc_lookup+0x1be nfs_lookup() at nfs_lookup+0x297 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95 lookup() at lookup+0x3b8 namei() at namei+0x484 vn_open_cred() at vn_open_cred+0x1e2 link_elf_load_file() at link_elf_load_file+0xb3 linker_load_module() at linker_load_module+0x794 kern_kldload() at kern_kldload+0x145 sys_kldload() at sys_kldload+0x84 amd64_syscall() at amd64_syscall+0x39e Xfast_syscall() at Xfast_syscall+0xf7 On Tue, Mar 6, 2012 at 7:01 PM, Adrian Chadd adrian.ch...@gmail.com wrote: Hi, What do we need to do to get VNET working in net80211 and the network drivers? Adrian On 6 March 2012 07:33, Marko Zec z...@fer.hr wrote: On Tuesday 06 March 2012 10:53:18 Monthadar Al Jaberi wrote: On Tue, Mar 6, 2012 at 12:52 AM, Marko Zec z...@fer.hr wrote: On Monday 05 March 2012 22:14:45 Monthadar Al Jaberi wrote: Hi, I am a very happy VIMAGE user. But lately I have been having problems using it, and its too complicated for me to dig in so I hope you can help me (and help Adrian too). I am using FreeBSD Current with a kernel config without wlan module and wireless devices attach kernel config. uname -a shows: FreeBSD acke 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Mar 5 20:02:38 CET 2012 root@acke:/usr/obj/usr/src/sys/VNET_without_wlan amd64 I run the following commands: cd /usr/sys/module/wlan make load cd /usr/sys/modules/wtap make load then: /usr/src/ools/tools/wtap/wtap/wtap c 0 ifconfig wlan create wlandev wtap0 wlanmode mesh wlandebug -i wlan0 hwmp+mesh+output+input+inact ifconfig wlan0 meshid mymesh ifconfig wlan0 inet 192.168.2.1 and freebsd panics with: Mon Mar 5 21:17:46 CET 2012 Mar 5 21:59:23 acke login: ROOT LOGIN (root) ON ttyv0 Using visibility wtap plugin... Loaded wtap wireless simulator wtap0: ieee80211_radiotap_attach: no tx channel, radiotap 0x0wtap0: ieee80211_radiotap_attach: no rx channel, radiotap 0x0wlan0: Ethernet address: 00:98:9a:98:96:97 wlan0: ieee80211_start: ignore queue, in SCAN state wlan0: [00:98:9a:98:96:97] ieee80211_alloc_node: inact_reload 2 Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex wtap0_com_lock (wtap0_com_lock) r = 0 (0xff8002395018) locked @ /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1937 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2c witness_warn() at witness_warn+0x2c4 trap() at trap+0x2fe calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x80885d0c, rsp = 0xff80003e9a00, rbp = 0xff80003e9a20 --- rt_dispatch() at rt_dispatch+0x2c rt_ieee80211msg() at rt_ieee80211msg+0x7f scan_task() at scan_task+0x4cd taskqueue_run_locked() at taskqueue_run_locked+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x3e It may be that scan_task() calls further down into the network stack without setting curvnet first. I added CURVNET_SET(TD_TO_VNET(curthread))/CURVNET_RESTORE() in scan_task but it didnt help scan_task() is called from a taskqueue trampoline which doesn't have a valid TD_TO_VNET(curthread) context, so what you attempted to do can't work. You need to set curvnet context to the one to which the network interface (or a packet) you're working with belongs to. Perhaps you could use (struct ieee80211_scan_state *) ss-ss_vap-iv_ifp-if_curvnet in scan_task() to set curvnet, but having no clue on how the 80211 code works, I might be wrong... And maybe you could consider rebuilding your kernel with options VNET_DEBUG turned on - that should more verbosely point to the problem at hand, while not introducing too big a performance penalty at runtime. Good luck, Marko -- Monthadar Al Jaberi ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VIMAGE + kldload wlan + kldload wtap panic
On Tue, Mar 6, 2012 at 9:57 PM, Marko Zec z...@fer.hr wrote:
On Tuesday 06 March 2012 21:29:32 Monthadar Al Jaberi wrote:
On Tue, Mar 6, 2012 at 9:22 PM, Marko Zec z...@fer.hr wrote:
On Tuesday 06 March 2012 21:13:00 Monthadar Al Jaberi wrote:
I am confused so whats the difference between having wlan in kernel
config or not? Cuase that seems the reason why we panic... linker
problems?
Its not impossible.
Have you tried to do CURVNET_SET(ss-ss_vap-iv_ifp-if_vnet) on entry to
scan_task() as I suggested earlier in this thread?
this is the code I added:
diff --git a/sys/net80211/ieee80211_scan.c b/sys/net80211/ieee80211_scan.c
index 5c1e3d9..bd20653 100644
--- a/sys/net80211/ieee80211_scan.c
+++ b/sys/net80211/ieee80211_scan.c
@@ -850,6 +850,7 @@ scan_task(void *arg, int pending)
int scandone = 0;
IEEE80211_LOCK(ic);
+ CURVNET_SET((struct ieee80211_scan_state *)
ss-ss_vap-iv_ifp-if_curvnet);
^^^
You couldn't have ever compiled this, so you must be booting an old kernel.
Whats wrong with this line, I am running new kernel remember I compile
wlan afterward and kldload it
it seems to compile fine if I type wrong names inside CURVNET_SET hmm...
I cant copy/paste db output from VBox butI am attaching two pictures.
Pls. make sure you have actually rebuilt and rebooted a new kernel, an let us
know the outcome.
Thanks
Marko
if (vap == NULL || (ic-ic_flags IEEE80211_F_SCAN) == 0 ||
(SCAN_PRIVATE(ss)-ss_iflags ISCAN_ABORT)) {
/* Cancelled before we started */
@@ -1004,6 +1005,7 @@ scan_task(void *arg, int pending)
ss-ss_ops-scan_restart(ss, vap); /* XXX? */
ieee80211_runtask(ic, SCAN_PRIVATE(ss)-ss_scan_task);
IEEE80211_UNLOCK(ic);
+ CURVNET_RESTORE();
return;
}
@@ -1043,6 +1045,7 @@ done:
SCAN_PRIVATE(ss)-ss_iflags = ~(ISCAN_CANCEL|ISCAN_ABORT);
ss-ss_flags = ~(IEEE80211_SCAN_ONCE | IEEE80211_SCAN_PICK1ST);
IEEE80211_UNLOCK(ic);
+ CURVNET_RESTORE();
#undef ISCAN_REP
}
same panic...
Cheers,
Marko
On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd adrian.ch...@gmail.com
wrote:
Hi,
The trouble here is that net80211 has quite a few other contexts that
things are called from:
* driver taskqueue;
* net80211 taskqueue;
* driver callouts;
* net80211 callouts;
* ioctls via net80211.
That's in parallel with frame tx/rx and device ioctls.
I don't personally have the time to go through net80211 and driver(s)
at the moment to figure out what's going on. Since ath(4) does a bunch
of frame processing in taskqueue context (and I'm trying to eliminate
frame processing in _callout_ context, ew..) things can potentially
get a bit hairy.
Adrian
On 6 March 2012 11:59, Marko Zec z...@fer.hr wrote:
On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote:
I added VNET_DEBUG and noticed this warning (original scan_task
code):
CURVNET_SET() recursion in sosend() line 1350, prev in
kern_kldload() 0xfe0002202c40 - 0xfe0002202c40
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
sosend() at sosend+0xbd
clnt_vc_call() at clnt_vc_call+0x3e6
clnt_reconnect_call() at clnt_reconnect_call+0xf5
newnfs_request() at newnfs_request+0x9fb
nfscl_request() at nfscl_request+0x72
nfsrpc_lookup() at nfsrpc_lookup+0x1be
nfs_lookup() at nfs_lookup+0x297
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95
lookup() at lookup+0x3b8
namei() at namei+0x484
vn_open_cred() at vn_open_cred+0x1e2
link_elf_load_file() at link_elf_load_file+0xb3
linker_load_module() at linker_load_module+0x794
kern_kldload() at kern_kldload+0x145
sys_kldload() at sys_kldload+0x84
amd64_syscall() at amd64_syscall+0x39e
Xfast_syscall() at Xfast_syscall+0xf7
You can safely ignore those. Recursing on curvnet is harmless, but
in certain cases can't be avoided.
When injecting new CURVNET_SET() / CURVNET_RESTORE() points in the
existing code, those warnings are here to help us becoming aware that
we are setting curvnet in a function which was invoked with an
already valid curvnet context.
Marko
--
Monthadar Al Jaberi
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
On Wed, Feb 2, 2011 at 8:06 PM, Julian Elischer jul...@freebsd.org wrote:
On 2/2/11 10:05 AM, Monthadar Al Jaberi wrote:
I just tried something that seems to work, but please dont hit me ^^;;;
in wtap_ioctl I assigned curthread-td_vnet myself to point to a VNET
(saved it when the module first loaded) (I have not created any jails
yet)... and it works... I didnt put any CURVNET macros...
td-td_vnet is exactly what the CURVNET_SET macro sets.
You should use the Macros because we may change the place where we store it.
The vnet for the current thread is picked up from several places depending
on the context,
and it is cleared again when it is not needed. the V_xxx usages in the code
end up being
in effect expanded to curthread-td_vnet.xxx, where each 'xxx' is sort of
like an element in a structure
but not quite.
Now, theoretically we could just leave it set all the time but then it would
be nearly impossible
to find places where we should have changed it, but forgot and just got the
existing one.
if you want to find the correct place to go, then look at the vnet of the
calling process
which should be in the process cred. or just use vnet0.
Can I check it from user space?
I don't understand why you saw a CRED_TO_VNET of 0
I was under the impression that every process/thread in the system would be
on vnet0
in a vimage kernel.
This is how my printf looks like:
struct thread *td = curthread;
struct vnet *v = TD_TO_VNET(td);
struct ucred *cred = CRED_TO_VNET(td-ucred);
struct vnet *td_vnet = td-td_vnet;
printf(td=%p, td-td_vnet=%p, td-td_ucred=%p, TD_TO_VNET=%p,
CRED_TO_VNET=%p\n, td, td_vnet, td-td_ucred, v, cred);
I made a fast search in /usr/src for td_vnet and found it was
assigned only in
int fork1(td, flags, pages, procp):
#ifdef VIMAGE
td2-td_vnet = NULL;
td2-td_vnet_lpush = NULL;
#endif
Maybe something wrong with how I declare my wtap_ioctl:
static struct cdevsw wtap_cdevsw = {
.d_version =D_VERSION,
.d_flags = 0,
.d_ioctl = wtap_ioctl,
.d_name = wtapctl,
};
...
make_dev(wtap_cdevsw,0,UID_ROOT,GID_WHEEL,0600,(const char *)wtapctl);
your stored vnet idea is ok as well, but may go strange if you load the
driver from a vnet jail
and then remove the jail.
Ok, will document it in the code for now
my assumption is that if ath drivers dont use VNET I shouldnt :P
What is wrong with this hack?
br,
P.S. I have printed porting to vnet text to have it always at hand,
but its a bit hard for me... doing my best.
On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischerjul...@freebsd.org
wrote:
On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote:
On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote:
Hi,
Thanx makes more sense, but I have noticed something weired if you can
shade some light on.
I added printfs one when the module is first loaded (static int
event_handler(module_t module, int event, void *arg)):
curthread=0xc3f95870
curthread-td_vnet=0xc3170e00
curthread-td_ucred=0xc3185d00
TD_TO_VNET=0
CRED_TO_VNET=0
Try to load it from laoder on boot; I think that should work as we are
setting the curvent for the kernel startup.
The problem you are seeing is a bug in the current implementation that
you cannot add any physical network interface after the kernel started.
This applies to cardbus/usb/... as well as any kind of ethernet
interface, so a kldload igb should yield it as well.
The fix for that is easy and hard at the same time:
A) either touch all drivers
B) or touch all cloned interfaces and change 3 common lines.
or try to make cloners aware of vimages.
Solution B) is sitting in perforce with the entire stuff that it depends
on and was started with CH=179022,179255 but not limited to that if you
want to have a peek.
What you certainly can do locally to your driver for now is to make a
change like this:
+#ifdef VIMAGE
+ CURVNET_SET(vnet0);
+#endif
ifp = if_alloc(IFT_ETHER);
+#ifdef VIMAGE
+ CURVNET_RESTORE();
+#endif
you don't really need the #ifdef except for readability as CURVNET_XXX
ar
enot defined for !vnet
It's the type A) kind of change from above that will break eventually
in the future.
/bz
--
//Monthadar Al Jaberi
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
I just tried something that seems to work, but please dont hit me ^^;;; in wtap_ioctl I assigned curthread-td_vnet myself to point to a VNET (saved it when the module first loaded) (I have not created any jails yet)... and it works... I didnt put any CURVNET macros... my assumption is that if ath drivers dont use VNET I shouldnt :P What is wrong with this hack? br, P.S. I have printed porting to vnet text to have it always at hand, but its a bit hard for me... doing my best. On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischer jul...@freebsd.org wrote: On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote: On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: Hi, Thanx makes more sense, but I have noticed something weired if you can shade some light on. I added printfs one when the module is first loaded (static int event_handler(module_t module, int event, void *arg)): curthread=0xc3f95870 curthread-td_vnet=0xc3170e00 curthread-td_ucred=0xc3185d00 TD_TO_VNET=0 CRED_TO_VNET=0 Try to load it from laoder on boot; I think that should work as we are setting the curvent for the kernel startup. The problem you are seeing is a bug in the current implementation that you cannot add any physical network interface after the kernel started. This applies to cardbus/usb/... as well as any kind of ethernet interface, so a kldload igb should yield it as well. The fix for that is easy and hard at the same time: A) either touch all drivers B) or touch all cloned interfaces and change 3 common lines. or try to make cloners aware of vimages. Solution B) is sitting in perforce with the entire stuff that it depends on and was started with CH=179022,179255 but not limited to that if you want to have a peek. What you certainly can do locally to your driver for now is to make a change like this: +#ifdef VIMAGE + CURVNET_SET(vnet0); +#endif ifp = if_alloc(IFT_ETHER); +#ifdef VIMAGE + CURVNET_RESTORE(); +#endif you don't really need the #ifdef except for readability as CURVNET_XXX ar enot defined for !vnet It's the type A) kind of change from above that will break eventually in the future. /bz -- //Monthadar Al Jaberi ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
Hi, I hope I am on the write place, second try... I have written a module that loads fake wifi devices (wtap?) and distributes packets between them. For now I use route command to route packets between them from upper layers (TCP,...). I want to take it to next step and create jails with VNET. I started reading Julian Elischer's Vimage: what is it? and he says that if I am writing hardware drivers I dont need to make any changes when I enable VIMAGE option on the kernel, because each one will have their own stack. I can give a more detailed explanation on how my module works. But for now I get a panic when calling if_alloc() when using option VIMAGE. Thank you, My setup: FreeBSD Current 201010 guest on VirtualBox on Ubuntu 10.04. Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0fc8284) locked @ /usr/src/sys/net/if.c:414 KDB: stack backtrace: db_trace_self_wrapper(c0cf3cdb,1,0,0,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(19e,1,,c0f9b194,c2fc9a1c,...) at kdb_backtrace+0x2a _witness_debugger(c0cf6408,c2fc9a30,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe trap(c2fc9abc) at trap+0x195 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0970999, esp = 0xc2fc9afc, ebp = 0xc2fc9b1c --- ifindex_alloc_locked(c0d003cf,c2fc9b36,19e,19e,c15ab714,...) at ifindex_alloc_locked+0x19 if_alloc(47,c4085a16,3,c0de9614,c32aa780,...) at if_alloc+0x85 wtap_attach(c31a7800,c40857c0,0,4,0,...) at wtap_attach+0x29 new_wtap(c32aa780,0,c2fc9bf0,c083ac9b,c3cbb200,...) at new_wtap+0x9b wtap_ioctl(c3cbb200,80045701,c31edaa0,1,c3f90b40,...) at wtap_ioctl+0x36 devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at devfs_ioctl_f+0x10b kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20d ioctl(c3f90b40,c2fc9cec,c2fc9d28,c0cf5783,0,...) at ioctl+0x134 syscallenter(c3f90b40,c2fc9ce4,c2fc9ce4,0,0,...) at syscallenter+0x263 syscall(c2fc9d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28181203, esp = 0xbfbfec3c, ebp = 0xbfbfec58 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0970999 stack pointer = 0x28:0xc2fc9afc frame pointer = 0x28:0xc2fc9b1c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1203 (ioctl) panic: from debugger cpuid = 0 Uptime: 21s Physical memory: 495 MB Dumping 55 MB: 40 24 8 -- //Monthadar Al Jaberi ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
On Tue, Feb 1, 2011 at 6:25 PM, Julian Elischer jul...@freebsd.org wrote: On 2/1/11 8:40 AM, Monthadar Al Jaberi wrote: Hi, I hope I am on the write place, second try... I have written a module that loads fake wifi devices (wtap?) and distributes packets between them. For now I use route command to route packets between them from upper layers (TCP,...). I want to take it to next step and create jails with VNET. I started reading Julian Elischer's Vimage: what is it? and he says that if I am writing hardware drivers I dont need to make any changes when I enable VIMAGE option on the kernel, because each one will have their own stack. I can give a more detailed explanation on how my module works. But for now I get a panic when calling if_alloc() when using option VIMAGE. Thank you, while this was true to some extent it i snot 100% true now. during allocation we now try to have separate interface indexes per vimage which means that the setup routines do need to know the current vnet. so I cant call if_alloc directly? it looks like wtap_ioctl or wtap_attach should have the following: (copied from the tun driver) this should not be needed from real hardware based drivers as far as I can tell. CURVNET_SET(CRED_TO_VNET(cred)); /* find any existing device, or allocate new unit number */ i = clone_create(tunclones, tun_cdevsw, u, dev, 0); [blah] if_clone_create(name, namelen, NULL); CURVNET_RESTORE(); My wtap is based on ath driver code (if_ath.c) which should look like a real device right? if_ath.c is not using VNET, as far as I can tell Currently my module creates a couple of wtaps, which I then create a corresponding wlan. These wtaps are interconnected together, so no out world yet... so I dont have struct cdev *dev Basic idea is my module have a main queue (simulating air) and each wtap have a rx_task which sends packets up to higher layers, plus callout timer for generation beacons... I will try to use CURVET_SET(...) tomo My setup: FreeBSD Current 201010 guest on VirtualBox on Ubuntu 10.04. Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0fc8284) locked @ /usr/src/sys/net/if.c:414 KDB: stack backtrace: db_trace_self_wrapper(c0cf3cdb,1,0,0,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(19e,1,,c0f9b194,c2fc9a1c,...) at kdb_backtrace+0x2a _witness_debugger(c0cf6408,c2fc9a30,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe trap(c2fc9abc) at trap+0x195 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0970999, esp = 0xc2fc9afc, ebp = 0xc2fc9b1c --- ifindex_alloc_locked(c0d003cf,c2fc9b36,19e,19e,c15ab714,...) at ifindex_alloc_locked+0x19 if_alloc(47,c4085a16,3,c0de9614,c32aa780,...) at if_alloc+0x85 wtap_attach(c31a7800,c40857c0,0,4,0,...) at wtap_attach+0x29 new_wtap(c32aa780,0,c2fc9bf0,c083ac9b,c3cbb200,...) at new_wtap+0x9b wtap_ioctl(c3cbb200,80045701,c31edaa0,1,c3f90b40,...) at wtap_ioctl+0x36 devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at devfs_ioctl_f+0x10b kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20d ioctl(c3f90b40,c2fc9cec,c2fc9d28,c0cf5783,0,...) at ioctl+0x134 syscallenter(c3f90b40,c2fc9ce4,c2fc9ce4,0,0,...) at syscallenter+0x263 syscall(c2fc9d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28181203, esp = 0xbfbfec3c, ebp = 0xbfbfec58 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0970999 stack pointer = 0x28:0xc2fc9afc frame pointer = 0x28:0xc2fc9b1c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1203 (ioctl) panic: from debugger cpuid = 0 Uptime: 21s Physical memory: 495 MB Dumping 55 MB: 40 24 8 -- //Monthadar Al Jaberi ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
loading ng_ether results in symbol ifnet undefined on mips
Hi, I am running FreeBSD Current 201010 on RouterStation Pro (mips CPU). I recompiled the kernel with the following options: options VIMAGE device epair options NULLFS but when I try to load ng_ether I get this error: link_elf_obj: symbol ifnet undefined linker_load_file: Unsupported file type kldload: can't load ng_ether: Exec format error I can load netgraph, ng_eiface and ng_bridge fine. When I recompile kernel back to normal I can load ng_ether. I tried this on VBox image, and it loads ng_ether just fine with or without VIMAGE. any help is appreciated! br, -- //Monthadar Al Jaberi ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
