Re: panic running include/t_paths
On Tue, 5 May 2015, Manuel Bouyer wrote:
It seems that when sysmonopen() is called, it might need to autoload the
module that handles the specific sub-comopnent (envsys, power, or wdog). But
if the autoload failed, the code blindly proceeded to call the
sub-component's open routine anyway (indirectly through the sysmon_opvec
table). Since autoload had failed, the opvec entry was never loaded and we
jumped off into never-never land. :)
this is likely to be the problem. Xen kernels are not MODULAR.
Hmmm. I might have to re-insert the various xxx_init() calls back into
kern/init_main.c for the non-MODULAR systems.
BTW, why do we have a completely separate /stand/{amd64,i386}-xen
directory structure to hold the xen modules, if xen kernels are not
capable of loading them?
:)
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
-
Re: panic running include/t_paths
On Tue, May 05, 2015 at 04:39:26PM +0800, Paul Goyette wrote:
On Tue, 5 May 2015, Manuel Bouyer wrote:
It seems that when sysmonopen() is called, it might need to autoload the
module that handles the specific sub-comopnent (envsys, power, or wdog). But
if the autoload failed, the code blindly proceeded to call the
sub-component's open routine anyway (indirectly through the sysmon_opvec
table). Since autoload had failed, the opvec entry was never loaded and we
jumped off into never-never land. :)
this is likely to be the problem. Xen kernels are not MODULAR.
Hmmm. I might have to re-insert the various xxx_init() calls back into
kern/init_main.c for the non-MODULAR systems.
Yes, please keep non-MODULAR systems working.
BTW, why do we have a completely separate /stand/{amd64,i386}-xen directory
structure to hold the xen modules, if xen kernels are not capable of loading
them?
No idea, I didn't add these directories
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: panic running include/t_paths
On Mon, 4 May 2015, Manuel Bouyer wrote: Hello, since a few days, anita Xen tests of HEAD panics on include/t_paths: include/t_paths (42/618): 1 test cases paths: uvm_fault(0xc15ef0dc, 0, 1) - 0xe fatal page fault in supervisor mode trap type 6 code 0 eip c03ab50a cs 9 eflags 10246 cr2 0 ilevel 0 esp 4300 curlwp 0xc17d1a80 pid 24550 lid 1 lowest kstack 0xcdb582c0 panic: trap cpu0: Begin traceback... vpanic(c04f0421,cdb5ac58,cdb5acdc,c03d4c06,c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246) at netbsd:vpanic+0x11a panic(c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246,0,0,4300,cdb5ace8) at netbsd:panic+0x18 trap() at netbsd:trap+0xbe6 --- trap (number 6) --- sysmonopen(4300,0,1,2000,c17d1a80,0,c11e8e50,c11f18f0,43,c0d8a780) at netbsd:sysmonopen+0x8a spec_open(cdb5adb8,cdb5aea4,cdb5aecc,c04b9874,c11f18f0,1,c0d8a780,c104c000,cdb5ae80,c04522c5) at netbsd:spec_open+0x1ec VOP_OPEN(c11f18f0,1,c0d8a780,c0d8fcc0,cdb5ae08,c0d8a780,c0596f80,cdb5ae18,c023626d,c1766d00) at netbsd:VOP_OPEN+0x32 vn_open(cdb5aea4,1,160,cdb5aeb8,c0edc1c0,c1755200,3,0,c1879200,c1075400) at netbsd:vn_open+0x1f5 do_open(c17d1a80,0,c1879200,0,8049362,cdb5af38,0,c1879200,c17d1a80,cdb5afa8) at netbsd:do_open+0xc0 do_sys_openat(0,8049362,cdb5af38,c057fbcc,cdb5af9c,c03aade3,c17d1a80,cdb5af68,cdb5af60,c159881c) at netbsd:do_sys_openat+0x6f sys_open(c17d1a80,cdb5af68,cdb5af60,c159881c,cdb5afa0,c0586964,cdb5af68,0,0,8049362) at netbsd:sys_open+0x2c syscall() at netbsd:syscall+0x83 --- syscall (number 5) --- bb683b07: cpu0: End traceback... This showed up between -04-23 09:30 UTC and 2015-04-24 13:10 UTC The sysmonopen() in the stack trace could point to sysmon; could the recent work on sysmon be the cause of this ? Quite likely. Let me see if I can figure out what it happening, and how the xen test environment differs from the qemu environment. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | -
Re: panic running include/t_paths
On Mon, 4 May 2015, Manuel Bouyer wrote:
Hello,
since a few days, anita Xen tests of HEAD panics on
include/t_paths:
include/t_paths (42/618): 1 test cases
paths: uvm_fault(0xc15ef0dc, 0, 1) - 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c03ab50a cs 9 eflags 10246 cr2 0 ilevel 0 esp 4300
curlwp 0xc17d1a80 pid 24550 lid 1 lowest kstack 0xcdb582c0
panic: trap
snip
OK, I think I found this one!
It seems that when sysmonopen() is called, it might need to autoload the
module that handles the specific sub-comopnent (envsys, power, or wdog).
But if the autoload failed, the code blindly proceeded to call the
sub-component's open routine anyway (indirectly through the sysmon_opvec
table). Since autoload had failed, the opvec entry was never loaded and
we jumped off into never-never land. :)
I've fixed the code to just return the error code ENODEV if autoload
fails.
The include/t_paths test will likely still fail, since it won't be able
to open /dev/{sysmon,power,wdog} paths. But at least it shouldn't panic
any more.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
-
