On Thu, 08 Mar 2012 14:04:49 +0300 Aleksey Cheusov <cheu...@tut.by> wrote:
> >> I few minutes ago I updated the kernel and modules on my 6.0_BETA > >> to the latest netbsd-6 sources and enabled debugging kernel options. > >> > >> options DEBUG # expensive debugging checks/support > >> makeoptions DEBUG="-g" # compile full symbol table > >> > >> Userlevel was not updated. > >> After login in xdm the system crashed. > >> at /srv/src_netbsd_current/sys/arch/x86/x86/pmap.c:3326 > >> > >> 3326 KASSERT(uvm_page_locked_p(pg)); > >> > >> Stacktrace is below. Any clue? > > > It looks like the same problem as what makes the kernel occasionally panic > > while running tests. It looks like a race condition causing memory > > corrution, > > but this is hard to track down ... > > On my system this crash is reproducible. At least it repeated three > times with xdm login. Does it make sense to send PR? Other cases where I can reproduce a crash or freeze: - Using tmpfs a lot, i.e. cvs co src and xsrc and build a full release on it (using -j4 on a 4 cores amd64). The tmpfs shows 13GB free before I start, so I'm not sure the issue is related to a memory shortage. - Playing a movie from a DVD using a puffs_cd9660, takes a while but eventually crashes Unfortunately, I couldn't get a crash dump (although I do have a dump device configured), so I'm considering connecting an RS232 cable to this MB (it fortunately supports it) and finding again my null modem cable such that I can instead try to get into ddb... Sometimes the system just reboots, but most of the time it remains frozen with the HDD light on until I reset. I'm also unsure if I should file one PR for each case, at least until I get more useful information... -- Matt