Re: Tmpfs panic in -current
On (27/06/2012 13:29), Kevin Lo wrote: Kevin Lo wrote: Konstantin Belousov wrote: On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: Konstantin Belousov wrote: On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: I've observed a panic in recent -current several times but I only have a picture of the backtrace: http://people.freebsd.org/~kevlo/panic_tmpfs.jpg Does this look at all familiar to anyone? Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address in your kernel ? Sure. The screenshot looks strange. The instruction on which the kernel trapped is int 0x28 which should not appear in the compiled code. Kevin, do you have fuse modules loaded? It looks much like memmory corruption issue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
On 四, 2012-06-28 at 10:09 +0300, Gleb Kurtsou wrote: On (27/06/2012 13:29), Kevin Lo wrote: Kevin Lo wrote: Konstantin Belousov wrote: On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote: Konstantin Belousov wrote: On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: I've observed a panic in recent -current several times but I only have a picture of the backtrace: http://people.freebsd.org/~kevlo/panic_tmpfs.jpg Does this look at all familiar to anyone? Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address in your kernel ? Sure. The screenshot looks strange. The instruction on which the kernel trapped is int 0x28 which should not appear in the compiled code. Kevin, do you have fuse modules loaded? It looks much like memmory corruption issue. No, I don't have that module loaded. # kldstat Id Refs AddressSize Name 1 14 0xc040 bab9e8 kernel 21 0xc0fac000 1d58 msdosfs_iconv.ko 32 0xc0fae000 67a8 libiconv.ko 41 0xc728e000 9000 tmpfs.ko 51 0xc789b000 4000 uhid.ko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
Kevin Lo wrote:
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627
address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel
trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid ==
VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx,
NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is
zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
I triggered the KASSERT on a different machine in the last hour.
It is not 'the' KASSERT, it is something different.
Are you sure that you do not have some systematic build issues on your
machines ? Although I do not think that tmpfs is 'ready for production use'
for arbitrary low value of this statement, there is no steady flow of
similar reports from other users. This makes me somewhat suspicious that
either you might have inconsistent build issues, or unrelated memory
corruption problems.
panic: Assertion (vp) !=NULL (vp)-v_data != NULL failed at
@/fs/tmpfs/tmpfs.h:527
The bad news is my coworker rebooted that machine after panic :-(
Kevin
pgpNw7ZYZRW88.pgp
Description: PGP signature
Re: Tmpfs panic in -current
Konstantin Belousov wrote:
On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
Kevin Lo wrote:
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627
address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel
trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0
||
1001 m-busy != 0) {
1002 vm_page_sleep(m,
tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid ==
VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx,
NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is
zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
I triggered the KASSERT on a different machine in the last hour.
It is not 'the' KASSERT, it is something different.
Are you sure that you do not have some systematic build issues on your
machines ? Although I do not think that tmpfs is 'ready for production use'
for arbitrary low value of this statement, there is no steady flow of
similar reports from other users. This makes me somewhat suspicious that
either you might have inconsistent build issues, or unrelated memory
corruption problems.
As I mentioned, I'm running -CURRENT on a number of systems.
I haven't seen tmpfs panics on machines running FreeBSD 9.
Kevin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is zero,
so I do not understand why the asserted block was executed at all.
pgpcAmL5mkan1.pgp
Description: PGP signature
Re: Tmpfs panic in -current
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, NULL,
NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
Kevin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
Kevin Lo wrote:
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627
address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel
trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx,
NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
I triggered the KASSERT on a different machine in the last hour.
panic: Assertion (vp) !=NULL (vp)-v_data != NULL failed at
@/fs/tmpfs/tmpfs.h:527
The bad news is my coworker rebooted that machine after panic :-(
Kevin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: I've observed a panic in recent -current several times but I only have a picture of the backtrace: http://people.freebsd.org/~kevlo/panic_tmpfs.jpg Does this look at all familiar to anyone? Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address in your kernel ? The screenshot looks strange. The instruction on which the kernel trapped is int 0x28 which should not appear in the compiled code. pgp3Si8Kma4hb.pgp Description: PGP signature
Re: Tmpfs panic in -current
Hello Kevin, May you rebuild your kernel with some options that will make the dump of the crash easier to send to people? Try to follow these steps: 1) Configure KERNEL with the folowing options: options KDB options GDB options DDB 2) Configure rc.conf: dumpdev=/dev/ad0s1b #Your swap slice. dumpdir=/var/crash #By default. crashinfo_enable=YES crashinfo_program=/usr/sbin/crashinfo 3) When the FreeBSD crash, it won't rebut, but will be stop on a gdb prompt. 3.1) gdb continue 3.2) gdb dump 4) kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 5) kgdb backtrace 6) kgdb up 4 7) kgdb up 6 -- Up to line number 4. 7 -- Up to the next line. Best Regards, - Araujo 2012/6/25 Konstantin Belousov kostik...@gmail.com On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote: I've observed a panic in recent -current several times but I only have a picture of the backtrace: http://people.freebsd.org/~kevlo/panic_tmpfs.jpg Does this look at all familiar to anyone? Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address in your kernel ? The screenshot looks strange. The instruction on which the kernel trapped is int 0x28 which should not appear in the compiled code. -- Marcelo Araujo ara...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU
LL)) {
Thanks!
Kevin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Tmpfs panic in -current
I've observed a panic in recent -current several times but I only have a picture of the backtrace: http://people.freebsd.org/~kevlo/panic_tmpfs.jpg Does this look at all familiar to anyone? Kevin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
