panic in loop during upgrade

M

mururoa

Hello,

I try to update from 10.0 to 10.1 a FreeBSD vmware VM but it panics during reboot.
Just after :

Code: 
freebsd-update upgrade -r 10.1-RELEASE
freebsd-update install
shutdown -r now

So I tried to restore the VM and start the upgrade process again and same result.

I don't even know where to look in order to fix that.

Here is the message :

Code: 
32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat
Creating and/or trimming log files.
Starting syslogd.
savecore: reboot after panic: page fault
Jan 23 10:48:19 ccbioappl05 savecore: reboot after panic: page fault
savecore: writing core to /var/crash/vmcore.2


Fatal trap 12: page fault while in kernel mode

and reboots in loop.
 
Last edited by a moderator:
mururoa said:
I don't even know where to look in order to fix that.

Here is the message :

Code: 
32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat
Creating and/or trimming log files.
Starting syslogd.
savecore: reboot after panic: page fault
Jan 23 10:48:19 ccbioappl05 savecore: reboot after panic: page fault
savecore: writing core to /var/crash/vmcore.2


Fatal trap 12: page fault while in kernel mode

and reboots in loop.
Click to expand...
Trap 12's can often be a hardware problem (as I'm sure someone will be along to point out shortly). However, if they happen in the same place repeatedly (as yours is), it is a software bug or a configuration problem. Since yours started happening due to the upgrade, I think you have incompatible components installed (some from 10.0, some from 10.1).

Given that you got as far as savecore(8) in the startup process, it is probably recoverable if we can find out what is causing it. You should get some sort of backtrace from the crash which will give us an idea of where it is happening and what the best way to recover is.

Also, when you said you "tried to restore the VM", did you restore the entire VM (normally something.vmdk) or via some other process? I would not expect the problem to persist if the entire VM was returned to the pre-problem state. Or are you saying it started happening again once you restarted freebsd-update(8)?
 
Terry_Kennedy said:
Also, when you said you "tried to restore the VM", did you restore the entire VM (normally something.vmdk) or via some other process? I would not expect the problem to persist if the entire VM was returned to the pre-problem state. Or are you saying it started happening again once you restarted freebsd-update(8)?
Click to expand...
When I said restore I mean complete restore to the state before beginning the upgrade (restored with VDP from the day before the upgrade), i.e. before freebsd-update fetch. And for now the VM is functioning OK in 10.0.
I will post backtrace later from work. And I will detail what was installed on that particular VM since it's the only one causing problem out of ~10 that were upgraded to 10.1. In fact it's the last FreeBSD 10.0 I still have.
 
Last edited by a moderator:
So, nothing much is installed on that VM :
- nginx (useless, will be removed)
- zabbix agent
- tentakel

I also had an unused ZFS pool that I removed also.

He is a portion of core.txt. Tell me which section would be informative.
Code: 
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address  = 0x0
fault code  = supervisor read data, page not present
instruction pointer  = 0x20:0xffffffff80d22bf6
stack pointer  = 0x28:0xfffffe01200d63c0
frame pointer  = 0x28:0xfffffe01200d6420
code segment  = base 0x0, limit 0xfffff, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags  = interrupt enabled, resume, IOPL = 0
current process  = 5 (trim test)
trap number  = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0xffffffff80963000 at kdb_backtrace+0x60
#1 0xffffffff80928125 at panic+0x155
#2 0xffffffff80d24f1f at trap_fatal+0x38f
#3 0xffffffff80d25238 at trap_pfault+0x308
#4 0xffffffff80d2489a at trap+0x47a
#5 0xffffffff80d0a782 at calltrap+0x8
#6 0xffffffff81983a9c at dmu_write_uio_dnode+0xcc
#7 0xffffffff819839ab at dmu_write_uio_dbuf+0x3b
#8 0xffffffff81a155b2 at zfs_freebsd_write+0x5e2
#9 0xffffffff80e428f5 at VOP_WRITE_APV+0x145
#10 0xffffffff809d73b9 at vn_rdwr+0x299
#11 0xffffffff819d1e55 at vdev_file_io_start+0x165
#12 0xffffffff819ef676 at zio_vdev_io_start+0x326
#13 0xffffffff819ec382 at zio_execute+0x162
#14 0xffffffff81a1fe9e at trim_map_commit+0x2ae
#15 0xffffffff81a1fce7 at trim_map_commit+0xf7
#16 0xffffffff81a1fa32 at trim_thread+0xf2
#17 0xffffffff808f8b6a at fork_exit+0x9a
Uptime: 16s
Dumping 245 out of 4069 MB:..7%..14%..27%..33%..46%..53%..66%..72%..85%..92%

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
219  pcpu.h: No such file or directory.
  in pcpu.h
(kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:219
#1  0xffffffff80927da2 in kern_reboot (howto=260)
  at /usr/src/sys/kern/kern_shutdown.c:452
#2  0xffffffff80928164 in panic (fmt=<value optimized out>)
  at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff80d24f1f in trap_fatal (frame=<value optimized out>,
  eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:865
#4  0xffffffff80d25238 in trap_pfault (frame=0xfffffe01200d6310,
 
That was it !
I still dont manage how you guessed that ...
Since I dont need anymore the file-backed zpool I removed it and then no more upgrade problems.
Thanks for your help.
 
You must log in or register to reply here.
Back
Top