To followup to myself, I think I have this pinned down... In line 403 of /sys/kern/vfs_cache.c, ncpp is somehow becoming 0. I believe that the trap is in ncp = LIST_FIRST(ncpp); -- LIST_FIRST(x) expands to ((x)->lh_first). That ends up being a dereference of NULL, which causes the trap and panic. As to how ncpp ends up being null, that's a good question, given it's the variable in the for loop at line 402. cache_zap() can't really have a side effect, since ncpp is a stack variable. I am going to try rewriting the outer for() loop as for(i=nchash ; i>=0 ; i--) and the initialization of the inner loop as ncp = LIST_FIRST(&(nchashtbl[i])) just in case cache_zap() causes the value of nchashtbl to change (just how the hell THAT would happen is way beyond me). Nick Sayer wrote: > (crossposting to -current in case it's not VMware related) > > I have a serial console running on the machine, so now I can tell the > difference between > a panic and a hang. :-) > > With that said, I now have a complete dump from one of these trap panics. > Here is a > stack trace: > > #0 0xc0152d28 in boot () > #1 0xc01530ac in poweroff_wait () > #2 0xc02571f9 in trap_fatal () > #3 0xc0256ed7 in trap_pfault () > #4 0xc0256a9a in trap () > #5 0xc0177da0 in cache_purgevfs () > #6 0xc017e6f1 in dounmount () > #7 0xc017e681 in unmount () > #8 0xc0257437 in syscall () > #9 0xc024b946 in Xint0x80_syscall () > #10 0x8057585 in ?? () > [etc] > > The machine is running amd, and my home directory is amd mounted. That is > the only > conceivable reason I can think why an 'unmount' would be in progress. > > Sure enough, ps aux on the core shows: > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 841 97.7 0.0 1100 0 ?? R 31Dec69 0:00.00 (amd) > nsayer 699 8.5 0.0 59480 0 #C1 R 31Dec69 4:46.96 (vmware) > root 2 0.0 0.0 0 0 ?? RL 31Dec69 0:03.56 > (pagedaemon) > root 3 0.0 0.0 0 0 ?? DL 31Dec69 0:00.42 (vmdaemon) > root 4 0.0 0.0 0 0 ?? RL 31Dec69 0:00.00 (bufdaemon) > > root 5 0.0 0.0 0 0 ?? RL 31Dec69 0:02.17 (syncer) > [...] > > Does anyone recognize this? What other information can I get that would be > of use? > > "Vladimir N. Silyaev" wrote: > > > > My machine here at the office gets these a _lot_ whenever I'm running > > > vmware: > > [skipped] > > > > >This machine also seems to hang a lot, but it could be that the hangs > > >are just these happening behind X so I can't see them. > > As you wrote below, you are have another box. So just try to use > > serial console (that will be provide a possibility to always > > see a panic message), also will be a right thing to compile kernel > > with DDB, that will provide some more information. > > > > > They always happen with amd as the current process. They frequently > > > happen when > > >vmware is running. They never happen at other times. > > The FreeBSD vmmon has a 'historical' bug - it's clear 'GS' register. > > But I was never encounter problem with them. And more I was > > so impressed by the fact that I was never encountered any vmware(vmmon) > > related problem. > > > > -- > > Vladimir Silyaev > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-emulation" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-emulation" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
