panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

#0  doadump (textdump=-2014022336) at pcpu.h:229
#1  0x8033e2d2 in db_fncall (dummy1=value optimized out, 
dummy2=value optimized out,

dummy3=value optimized out, dummy4=value optimized out)
at /usr/src/head/sys/ddb/db_command.c:578
#2  0x8033e074 in db_command (last_cmdp=value optimized out,
cmd_table=value optimized out, dopager=1) at 
/usr/src/head/sys/ddb/db_command.c:449
#3  0x8033dd62 in db_command_loop () at 
/usr/src/head/sys/ddb/db_command.c:502

#4  0x80340690 in db_trap (type=value optimized out, code=0)
at /usr/src/head/sys/ddb/db_main.c:231
#5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized 
out)

at /usr/src/head/sys/kern/subr_kdb.c:654
#6  0x80bfc71a in trap (frame=0xff8487f478a0)
at /usr/src/head/sys/amd64/amd64/trap.c:579
#7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
#8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic, 
msg=value optimized out)

at cpufunc.h:63
#9  0x8088086f in panic (fmt=value optimized out)
at /usr/src/head/sys/kern/kern_shutdown.c:628
#10 0x80adea4a in vm_object_madvise (object=value optimized out,
pindex=value optimized out, end=8952, advise=value optimized out)
at /usr/src/head/sys/vm/vm_object.c:1101
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188, 
start=value optimized out,
end=value optimized out, behav=5) at 
/usr/src/head/sys/vm/vm_map.c:2140
#12 0x80adbd8d in sys_madvise (td=value optimized out, 
uap=value optimized out)

at /usr/src/head/sys/vm/vm_mmap.c:752
#13 0x80bfd3a5 in amd64_syscall (td=0xfe001823, 
traced=0) at subr_syscall.c:135

#14 0x80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329
#15 0x016f3bfa in ?? ()
___
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: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Attilio Rao 
On Tue, Nov 27, 2012 at 11:26 AM, Andre Oppermann an...@freebsd.org wrote:
 FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
 Fri Nov 23 17:00:40 CET 2012
 a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

 #0  doadump (textdump=-2014022336) at pcpu.h:229
 #1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
 dummy2=value optimized out,
 dummy3=value optimized out, dummy4=value optimized out)
 at /usr/src/head/sys/ddb/db_command.c:578
 #2  0x8033e074 in db_command (last_cmdp=value optimized out,
 cmd_table=value optimized out, dopager=1) at
 /usr/src/head/sys/ddb/db_command.c:449
 #3  0x8033dd62 in db_command_loop () at
 /usr/src/head/sys/ddb/db_command.c:502
 #4  0x80340690 in db_trap (type=value optimized out, code=0)
 at /usr/src/head/sys/ddb/db_main.c:231
 #5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized
 out)
 at /usr/src/head/sys/kern/subr_kdb.c:654
 #6  0x80bfc71a in trap (frame=0xff8487f478a0)
 at /usr/src/head/sys/amd64/amd64/trap.c:579
 #7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
 #8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
 msg=value optimized out)
 at cpufunc.h:63
 #9  0x8088086f in panic (fmt=value optimized out)
 at /usr/src/head/sys/kern/kern_shutdown.c:628
 #10 0x80adea4a in vm_object_madvise (object=value optimized out,
 pindex=value optimized out, end=8952, advise=value optimized out)
 at /usr/src/head/sys/vm/vm_object.c:1101

Can you do: frame 10 and then info locals and finally p *m?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
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: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Konstantin Belousov 
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
 FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
 Fri Nov 23 17:00:40 CET 2012
 a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64
 
 #0  doadump (textdump=-2014022336) at pcpu.h:229
 #1  0x8033e2d2 in db_fncall (dummy1=value optimized out, 
 dummy2=value optimized out,
  dummy3=value optimized out, dummy4=value optimized out)
  at /usr/src/head/sys/ddb/db_command.c:578
 #2  0x8033e074 in db_command (last_cmdp=value optimized out,
  cmd_table=value optimized out, dopager=1) at 
 /usr/src/head/sys/ddb/db_command.c:449
 #3  0x8033dd62 in db_command_loop () at 
 /usr/src/head/sys/ddb/db_command.c:502
 #4  0x80340690 in db_trap (type=value optimized out, code=0)
  at /usr/src/head/sys/ddb/db_main.c:231
 #5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized 
 out)
  at /usr/src/head/sys/kern/subr_kdb.c:654
 #6  0x80bfc71a in trap (frame=0xff8487f478a0)
  at /usr/src/head/sys/amd64/amd64/trap.c:579
 #7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
 #8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic, 
 msg=value optimized out)
  at cpufunc.h:63
 #9  0x8088086f in panic (fmt=value optimized out)
  at /usr/src/head/sys/kern/kern_shutdown.c:628
 #10 0x80adea4a in vm_object_madvise (object=value optimized out,
  pindex=value optimized out, end=8952, advise=value optimized out)
  at /usr/src/head/sys/vm/vm_object.c:1101
 #11 0x80ad759a in vm_map_madvise (map=0xfe0018260188, 
 start=value optimized out,
  end=value optimized out, behav=5) at 
 /usr/src/head/sys/vm/vm_map.c:2140
 #12 0x80adbd8d in sys_madvise (td=value optimized out, 
 uap=value optimized out)
  at /usr/src/head/sys/vm/vm_mmap.c:752
 #13 0x80bfd3a5 in amd64_syscall (td=0xfe001823, 
 traced=0) at subr_syscall.c:135
 #14 0x80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329
 #15 0x016f3bfa in ?? ()

I think this is an omission in the check for the object types. BTW, this
pattern already repeats in several places, I thought about adding either
new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
fields to the struct vm_pager to classify the vm objects.

I am curious, what was the process which caused the panic ?

diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
index e19750c..5b8ed23 100644
--- a/sys/vm/vm_object.c
+++ b/sys/vm/vm_object.c
@@ -1060,7 +1060,10 @@ shadowlookup:
(tobject-flags  OBJ_ONEMAPPING) == 0) {
goto unlock_tobject;
}
-   } else if (tobject-type == OBJT_PHYS)
+   } else if (tobject-type == OBJT_PHYS ||
+   tobject-type == OBJT_SG ||
+   tobject-type == OBJT_MGTDEVICE ||
+   tobject-type == OBJT_DEVICE)
goto unlock_tobject;
m = vm_page_lookup(tobject, tpindex);
if (m == NULL  advise == MADV_WILLNEED) {


pgpy32S4OkrPj.pgp
Description: PGP signature

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

On 27.11.2012 16:05, Attilio Rao wrote:

On Tue, Nov 27, 2012 at 11:26 AM, Andre Oppermann an...@freebsd.org wrote:

FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

#0  doadump (textdump=-2014022336) at pcpu.h:229
#1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
dummy2=value optimized out,
 dummy3=value optimized out, dummy4=value optimized out)
 at /usr/src/head/sys/ddb/db_command.c:578
#2  0x8033e074 in db_command (last_cmdp=value optimized out,
 cmd_table=value optimized out, dopager=1) at
/usr/src/head/sys/ddb/db_command.c:449
#3  0x8033dd62 in db_command_loop () at
/usr/src/head/sys/ddb/db_command.c:502
#4  0x80340690 in db_trap (type=value optimized out, code=0)
 at /usr/src/head/sys/ddb/db_main.c:231
#5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized
out)
 at /usr/src/head/sys/kern/subr_kdb.c:654
#6  0x80bfc71a in trap (frame=0xff8487f478a0)
 at /usr/src/head/sys/amd64/amd64/trap.c:579
#7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
#8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
msg=value optimized out)
 at cpufunc.h:63
#9  0x8088086f in panic (fmt=value optimized out)
 at /usr/src/head/sys/kern/kern_shutdown.c:628
#10 0x80adea4a in vm_object_madvise (object=value optimized out,
 pindex=value optimized out, end=8952, advise=value optimized out)
 at /usr/src/head/sys/vm/vm_object.c:1101


Can you do: frame 10 and then info locals and finally p *m?


(kgdb) frame 10
#10 0x80adea4a in vm_object_madvise (object=value optimized out,
pindex=value optimized out, end=8952, advise=value optimized out)
at /usr/src/head/sys/vm/vm_object.c:1101
1101KASSERT((m-flags  PG_FICTITIOUS) == 0,
Current language:  auto; currently minimal
(kgdb) info locals
m = value optimized out
backing_object = value optimized out
tpindex = value optimized out
(kgdb) p *m
Cannot access memory at address 0xa0038
(kgdb)

--
Andre

___
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: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

On 27.11.2012 16:06, Konstantin Belousov wrote:

On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:

FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

#0  doadump (textdump=-2014022336) at pcpu.h:229
#1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
dummy2=value optimized out,
  dummy3=value optimized out, dummy4=value optimized out)
  at /usr/src/head/sys/ddb/db_command.c:578
#2  0x8033e074 in db_command (last_cmdp=value optimized out,
  cmd_table=value optimized out, dopager=1) at
/usr/src/head/sys/ddb/db_command.c:449
#3  0x8033dd62 in db_command_loop () at
/usr/src/head/sys/ddb/db_command.c:502
#4  0x80340690 in db_trap (type=value optimized out, code=0)
  at /usr/src/head/sys/ddb/db_main.c:231
#5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized
out)
  at /usr/src/head/sys/kern/subr_kdb.c:654
#6  0x80bfc71a in trap (frame=0xff8487f478a0)
  at /usr/src/head/sys/amd64/amd64/trap.c:579
#7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
#8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
msg=value optimized out)
  at cpufunc.h:63
#9  0x8088086f in panic (fmt=value optimized out)
  at /usr/src/head/sys/kern/kern_shutdown.c:628
#10 0x80adea4a in vm_object_madvise (object=value optimized out,
  pindex=value optimized out, end=8952, advise=value optimized out)
  at /usr/src/head/sys/vm/vm_object.c:1101
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
start=value optimized out,
  end=value optimized out, behav=5) at
/usr/src/head/sys/vm/vm_map.c:2140
#12 0x80adbd8d in sys_madvise (td=value optimized out,
uap=value optimized out)
  at /usr/src/head/sys/vm/vm_mmap.c:752
#13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
traced=0) at subr_syscall.c:135
#14 0x80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329
#15 0x016f3bfa in ?? ()


I think this is an omission in the check for the object types. BTW, this
pattern already repeats in several places, I thought about adding either
new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
fields to the struct vm_pager to classify the vm objects.

I am curious, what was the process which caused the panic ?


Clang doing a manual kernel build of my work tree with make -j8 kernel.

--
Andre


diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
index e19750c..5b8ed23 100644
--- a/sys/vm/vm_object.c
+++ b/sys/vm/vm_object.c
@@ -1060,7 +1060,10 @@ shadowlookup:
(tobject-flags  OBJ_ONEMAPPING) == 0) {
goto unlock_tobject;
}
-   } else if (tobject-type == OBJT_PHYS)
+   } else if (tobject-type == OBJT_PHYS ||
+   tobject-type == OBJT_SG ||
+   tobject-type == OBJT_MGTDEVICE ||
+   tobject-type == OBJT_DEVICE)
goto unlock_tobject;
m = vm_page_lookup(tobject, tpindex);
if (m == NULL  advise == MADV_WILLNEED) {



___
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: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andriy Gapon 
on 27/11/2012 17:38 Andre Oppermann said the following:
 Clang doing a manual kernel build of my work tree with make -j8 kernel.

This sounds like a process that may have triggered the problem.
But is it the process that made the syscall in the backtrace?
You can check by e.g. going to frame 13 and examining *td and *td-td_proc.

-- 
Andriy Gapon
___
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: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Konstantin Belousov 
On Tue, Nov 27, 2012 at 04:38:12PM +0100, Andre Oppermann wrote:
 On 27.11.2012 16:06, Konstantin Belousov wrote:
  On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
  FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
  Fri Nov 23 17:00:40 CET 2012
  a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64
 
  #0  doadump (textdump=-2014022336) at pcpu.h:229
  #1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
  dummy2=value optimized out,
dummy3=value optimized out, dummy4=value optimized out)
at /usr/src/head/sys/ddb/db_command.c:578
  #2  0x8033e074 in db_command (last_cmdp=value optimized out,
cmd_table=value optimized out, dopager=1) at
  /usr/src/head/sys/ddb/db_command.c:449
  #3  0x8033dd62 in db_command_loop () at
  /usr/src/head/sys/ddb/db_command.c:502
  #4  0x80340690 in db_trap (type=value optimized out, code=0)
at /usr/src/head/sys/ddb/db_main.c:231
  #5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized
  out)
at /usr/src/head/sys/kern/subr_kdb.c:654
  #6  0x80bfc71a in trap (frame=0xff8487f478a0)
at /usr/src/head/sys/amd64/amd64/trap.c:579
  #7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
  #8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
  msg=value optimized out)
at cpufunc.h:63
  #9  0x8088086f in panic (fmt=value optimized out)
at /usr/src/head/sys/kern/kern_shutdown.c:628
  #10 0x80adea4a in vm_object_madvise (object=value optimized out,
pindex=value optimized out, end=8952, advise=value optimized out)
at /usr/src/head/sys/vm/vm_object.c:1101
  #11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
  start=value optimized out,
end=value optimized out, behav=5) at
  /usr/src/head/sys/vm/vm_map.c:2140
  #12 0x80adbd8d in sys_madvise (td=value optimized out,
  uap=value optimized out)
at /usr/src/head/sys/vm/vm_mmap.c:752
  #13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
  traced=0) at subr_syscall.c:135
  #14 0x80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329
  #15 0x016f3bfa in ?? ()
 
  I think this is an omission in the check for the object types. BTW, this
  pattern already repeats in several places, I thought about adding either
  new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
  fields to the struct vm_pager to classify the vm objects.
 
  I am curious, what was the process which caused the panic ?
 
 Clang doing a manual kernel build of my work tree with make -j8 kernel.
You did not answered my question, what was the process that caused the
panic ? As in, could it be X server ?

 
 -- 
 Andre
 
  diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
  index e19750c..5b8ed23 100644
  --- a/sys/vm/vm_object.c
  +++ b/sys/vm/vm_object.c
  @@ -1060,7 +1060,10 @@ shadowlookup:
  (tobject-flags  OBJ_ONEMAPPING) == 0) {
  goto unlock_tobject;
  }
  -   } else if (tobject-type == OBJT_PHYS)
  +   } else if (tobject-type == OBJT_PHYS ||
  +   tobject-type == OBJT_SG ||
  +   tobject-type == OBJT_MGTDEVICE ||
  +   tobject-type == OBJT_DEVICE)
  goto unlock_tobject;
  m = vm_page_lookup(tobject, tpindex);
  if (m == NULL  advise == MADV_WILLNEED) {
 


pgpdXROKB6JlC.pgp
Description: PGP signature

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

On 27.11.2012 16:40, Andriy Gapon wrote:

on 27/11/2012 17:38 Andre Oppermann said the following:

Clang doing a manual kernel build of my work tree with make -j8 kernel.


This sounds like a process that may have triggered the problem.
But is it the process that made the syscall in the backtrace?
You can check by e.g. going to frame 13 and examining *td and *td-td_proc.



(kgdb) frame 13
#13 0x80bfd3a5 in amd64_syscall (td=0xfe001823, traced=0) at 
subr_syscall.c:135
135 error = (sa-callp-sy_call)(td, sa-args);
Current language:  auto; currently minimal
(kgdb) p *td
$1 = {td_lock = 0x812ac180, td_proc = 0xfe0256301950, td_plist = 
{tqe_next = 0x0,
tqe_prev = 0xfe0256301960}, td_runq = {tqe_next = 0x0, tqe_prev = 
0x812ac630},
  td_slpq = {tqe_next = 0x0, tqe_prev = 0xfe00181c6a80}, td_lockq = 
{tqe_next = 0x0,
tqe_prev = 0xff8487efc540}, td_hash = {le_next = 0x0, le_prev = 
0xff80006ffe58},
  td_cpuset = 0xfe0007376dc8, td_sel = 0x0, td_sleepqueue = 
0xfe00181c6a80,
  td_turnstile = 0xfe0018378b40, td_rlqe = 0xfe0018215a00, td_umtxq = 
0xfe0018170580,
  td_tid = 100299, td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill 
= {__bits = {0, 0,
0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xfe00182300b8},
sq_proc = 0xfe0256301950, sq_flags = 1}, td_lend_user_pri = 255 'ÿ', 
td_flags = 4,
  td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_sqqueue = 0, td_wchan = 
0x0, td_wmesg = 0x0,
  td_lastcpu = 0 '\0', td_oncpu = 0 '\0', td_owepreempt = 0 '\0', td_tsqueue = 
255 'ÿ',
  td_locks = 3, td_rw_rlocks = 0, td_lk_slocks = 0, td_stopsched = 1, 
td_blocked = 0x0,
  td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 
0x81429ea0,
  td_intr_nesting_level = 0, td_pinned = 1, td_ucred = 0xfe0018244c00, 
td_estcpu = 0,
  td_slptick = 0, td_blktick = 0, td_swvoltick = 2312563, td_cow = 6, td_ru = 
{ru_utime = {
  tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss 
= 50728,
ru_ixrss = 2858440, ru_idrss = 31280, ru_isrss = 26752, ru_minflt = 7722, 
ru_majflt = 11,
ru_nswap = 0, ru_inblock = 8, ru_oublock = 4, ru_msgsnd = 0, ru_msgrcv = 0, 
ru_nsignals = 0,
ru_nvcsw = 35, ru_nivcsw = 98}, td_rux = {rux_runtime = 0, rux_uticks = 0, 
rux_sticks = 0,
rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, td_incruntime = 
2792408043,
  td_runtime = 2792408043, td_pticks = 0, td_sticks = 7, td_iticks = 0, 
td_uticks = 108,
  td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_generation = 133, 
td_sigstk = {
ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_xsig = 0, td_profil_addr = 0, 
td_profil_ticks = 0,
  td_name = cc, '\0' repeats 17 times, td_fpop = 0x0, td_dbgflags = 0, 
td_dbgksi = {
ksi_link = {tqe_next = 0x0, tqe_prev = 0x0}, ksi_info = {si_signo = 0, 
si_errno = 0,
  si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, 
si_value = {
sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, 
_reason = {_fault = {
  _trapno = 0}, _timer = {_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 
0}, _poll = {
  _band = 0}, __spare__ = {__spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 
0, 0,
ksi_flags = 0, ksi_sigq = 0x0}, td_ng_outbound = 0, td_osd = {osd_nslots = 
0, osd_slots = 0x0,
osd_next = {le_next = 0x0, le_prev = 0x0}}, td_map_def_user = 0x0, 
td_dbg_forked = 0,
  td_vp_reserv = 0, td_sigmask = {__bits = {0, 0, 0, 0}}, td_rqindex = 0 '\0',
  td_base_pri = 175 '¯', td_priority = 175 '¯', td_pri_class = 3 '\003', 
td_user_pri = 175 '¯',
  td_base_user_pri = 175 '¯', td_pcb = 0xff8487f47cc0, td_state = 
TDS_RUNNING, td_retval = {0,
5}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 
0x0,
tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, 
c_flags = 16,
c_cpu = 0}, td_frame = 0xff8487f47c00, td_kstack_obj = 
0xfe0256092570,
  td_kstack = 18446743543414538240, td_kstack_pages = 4, td_critnest = 1, td_md 
= {
md_spinlock_count = 1, md_saved_flags = 582, md_spurflt_addr = 34407014400},
  td_sched = 0xfe0018230458, td_ar = 0x0, td_lprof = {{lh_first = 0x0}, 
{lh_first = 0x0}},
  td_dtrace = 0xfe0248e8c000, td_errno = 0, td_vnet = 0x0, td_vnet_lpush = 
0x0,
  td_intr_frame = 0x0, td_rfppwait_p = 0xfe0248f8a950, td_ma = 0x0, 
td_ma_cnt = 0}
(kgdb) p *td-td_proc
$2 = {p_list = {le_next = 0xfe0248f8a950, le_prev = 0xfe0248eb04a8}, 
p_threads = {
tqh_first = 0xfe001823, tqh_last = 0xfe0018230010}, p_slock = 
{lock_object = {
  lo_name = 0x80e5c3a8 process slock, lo_flags = 720896, lo_data 
= 0,
  lo_witness = 0x0}, mtx_lock = 4}, p_ucred = 0xfe0018244c00, p_fd = 
0xfe001856,
  p_fdtol = 0x0, p_stats = 0xfe0018225a00, p_limit = 0xfe0018468900, 
p_limco = {c_links = {
  sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

On 27.11.2012 16:51, Konstantin Belousov wrote:

On Tue, Nov 27, 2012 at 04:38:12PM +0100, Andre Oppermann wrote:

On 27.11.2012 16:06, Konstantin Belousov wrote:

On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:

FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

#0  doadump (textdump=-2014022336) at pcpu.h:229
#1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
dummy2=value optimized out,
   dummy3=value optimized out, dummy4=value optimized out)
   at /usr/src/head/sys/ddb/db_command.c:578
#2  0x8033e074 in db_command (last_cmdp=value optimized out,
   cmd_table=value optimized out, dopager=1) at
/usr/src/head/sys/ddb/db_command.c:449
#3  0x8033dd62 in db_command_loop () at
/usr/src/head/sys/ddb/db_command.c:502
#4  0x80340690 in db_trap (type=value optimized out, code=0)
   at /usr/src/head/sys/ddb/db_main.c:231
#5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized
out)
   at /usr/src/head/sys/kern/subr_kdb.c:654
#6  0x80bfc71a in trap (frame=0xff8487f478a0)
   at /usr/src/head/sys/amd64/amd64/trap.c:579
#7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
#8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
msg=value optimized out)
   at cpufunc.h:63
#9  0x8088086f in panic (fmt=value optimized out)
   at /usr/src/head/sys/kern/kern_shutdown.c:628
#10 0x80adea4a in vm_object_madvise (object=value optimized out,
   pindex=value optimized out, end=8952, advise=value optimized out)
   at /usr/src/head/sys/vm/vm_object.c:1101
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
start=value optimized out,
   end=value optimized out, behav=5) at
/usr/src/head/sys/vm/vm_map.c:2140
#12 0x80adbd8d in sys_madvise (td=value optimized out,
uap=value optimized out)
   at /usr/src/head/sys/vm/vm_mmap.c:752
#13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
traced=0) at subr_syscall.c:135
#14 0x80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329
#15 0x016f3bfa in ?? ()


I think this is an omission in the check for the object types. BTW, this
pattern already repeats in several places, I thought about adding either
new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
fields to the struct vm_pager to classify the vm objects.

I am curious, what was the process which caused the panic ?


Clang doing a manual kernel build of my work tree with make -j8 kernel.

You did not answered my question, what was the process that caused the
panic ? As in, could it be X server ?


No X on this machine.  Pure ssh login.  See my other reply for *td and 
*td-td_proc
output.

--
Andre

___
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: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Alan Cox 
On 11/27/2012 09:06, Konstantin Belousov wrote:
 On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
 FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
 Fri Nov 23 17:00:40 CET 2012
 a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

 #0  doadump (textdump=-2014022336) at pcpu.h:229
 #1  0x8033e2d2 in db_fncall (dummy1=value optimized out, 
 dummy2=value optimized out,
  dummy3=value optimized out, dummy4=value optimized out)
  at /usr/src/head/sys/ddb/db_command.c:578
 #2  0x8033e074 in db_command (last_cmdp=value optimized out,
  cmd_table=value optimized out, dopager=1) at 
 /usr/src/head/sys/ddb/db_command.c:449
 #3  0x8033dd62 in db_command_loop () at 
 /usr/src/head/sys/ddb/db_command.c:502
 #4  0x80340690 in db_trap (type=value optimized out, code=0)
  at /usr/src/head/sys/ddb/db_main.c:231
 #5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized 
 out)
  at /usr/src/head/sys/kern/subr_kdb.c:654
 #6  0x80bfc71a in trap (frame=0xff8487f478a0)
  at /usr/src/head/sys/amd64/amd64/trap.c:579
 #7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
 #8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic, 
 msg=value optimized out)
  at cpufunc.h:63
 #9  0x8088086f in panic (fmt=value optimized out)
  at /usr/src/head/sys/kern/kern_shutdown.c:628
 #10 0x80adea4a in vm_object_madvise (object=value optimized out,
  pindex=value optimized out, end=8952, advise=value optimized out)
  at /usr/src/head/sys/vm/vm_object.c:1101
 #11 0x80ad759a in vm_map_madvise (map=0xfe0018260188, 
 start=value optimized out,
  end=value optimized out, behav=5) at 
 /usr/src/head/sys/vm/vm_map.c:2140
 #12 0x80adbd8d in sys_madvise (td=value optimized out, 
 uap=value optimized out)
  at /usr/src/head/sys/vm/vm_mmap.c:752
 #13 0x80bfd3a5 in amd64_syscall (td=0xfe001823, 
 traced=0) at subr_syscall.c:135
 #14 0x80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329
 #15 0x016f3bfa in ?? ()
 I think this is an omission in the check for the object types. BTW, this
 pattern already repeats in several places, I thought about adding either
 new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
 fields to the struct vm_pager to classify the vm objects.


A fictitious page should always have a non-zero wire count.  In fact, it
should always be one and never change.  (See vm_page_unwire().)  In
vm_object_madvise(), there is a check against the page's wire count that
precedes the KASSERT().  This check should prevent the KASSERT() from
being reached for the various device-backed object types.  So, something
else has gone wrong here, or rather something has gone wrong elsewhere
that caused the KASSERT() failure here. 

Andre, can we see the contents of the offending struct vm_page and also
the struct vm_object to which the offending page belongs to?  Also, are
you running a kernel with any experimental zero-copy send support?

(Kostik, by the way, I would be happy to see attribute flags added to
the vm object to take the place of the type checks.)


 I am curious, what was the process which caused the panic ?

 diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
 index e19750c..5b8ed23 100644
 --- a/sys/vm/vm_object.c
 +++ b/sys/vm/vm_object.c
 @@ -1060,7 +1060,10 @@ shadowlookup:
   (tobject-flags  OBJ_ONEMAPPING) == 0) {
   goto unlock_tobject;
   }
 - } else if (tobject-type == OBJT_PHYS)
 + } else if (tobject-type == OBJT_PHYS ||
 + tobject-type == OBJT_SG ||
 + tobject-type == OBJT_MGTDEVICE ||
 + tobject-type == OBJT_DEVICE)
   goto unlock_tobject;
   m = vm_page_lookup(tobject, tpindex);
   if (m == NULL  advise == MADV_WILLNEED) {

___
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: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

On 27.11.2012 17:42, Alan Cox wrote:

On 11/27/2012 09:06, Konstantin Belousov wrote:

On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:

FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

#0  doadump (textdump=-2014022336) at pcpu.h:229
#1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
dummy2=value optimized out,
  dummy3=value optimized out, dummy4=value optimized out)
  at /usr/src/head/sys/ddb/db_command.c:578
#2  0x8033e074 in db_command (last_cmdp=value optimized out,
  cmd_table=value optimized out, dopager=1) at
/usr/src/head/sys/ddb/db_command.c:449
#3  0x8033dd62 in db_command_loop () at
/usr/src/head/sys/ddb/db_command.c:502
#4  0x80340690 in db_trap (type=value optimized out, code=0)
  at /usr/src/head/sys/ddb/db_main.c:231
#5  0x808b375e in kdb_trap (type=3, code=0, tf=value optimized
out)
  at /usr/src/head/sys/kern/subr_kdb.c:654
#6  0x80bfc71a in trap (frame=0xff8487f478a0)
  at /usr/src/head/sys/amd64/amd64/trap.c:579
#7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
#8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
msg=value optimized out)
  at cpufunc.h:63
#9  0x8088086f in panic (fmt=value optimized out)
  at /usr/src/head/sys/kern/kern_shutdown.c:628
#10 0x80adea4a in vm_object_madvise (object=value optimized out,
  pindex=value optimized out, end=8952, advise=value optimized out)
  at /usr/src/head/sys/vm/vm_object.c:1101
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
start=value optimized out,
  end=value optimized out, behav=5) at
/usr/src/head/sys/vm/vm_map.c:2140
#12 0x80adbd8d in sys_madvise (td=value optimized out,
uap=value optimized out)
  at /usr/src/head/sys/vm/vm_mmap.c:752
#13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
traced=0) at subr_syscall.c:135
#14 0x80be689b in Xfast_syscall () at /tmp/exception-3nQ6Cf.s:329
#15 0x016f3bfa in ?? ()

I think this is an omission in the check for the object types. BTW, this
pattern already repeats in several places, I thought about adding either
new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
fields to the struct vm_pager to classify the vm objects.



A fictitious page should always have a non-zero wire count.  In fact, it
should always be one and never change.  (See vm_page_unwire().)  In
vm_object_madvise(), there is a check against the page's wire count that
precedes the KASSERT().  This check should prevent the KASSERT() from
being reached for the various device-backed object types.  So, something
else has gone wrong here, or rather something has gone wrong elsewhere
that caused the KASSERT() failure here.

Andre, can we see the contents of the offending struct vm_page and also
the struct vm_object to which the offending page belongs to?  Also, are
you running a kernel with any experimental zero-copy send support?


No experimental zero-copy support, or anything else, just a stock GENERIC 
kernel.

(kgdb) frame 11
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188, start=value 
optimized out,
end=value optimized out, behav=5) at /usr/src/head/sys/vm/vm_map.c:2140
2140vm_object_madvise(current-object.vm_object, 
pstart,
(kgdb) p *map
$1 = {header = {prev = 0xfe025631c438, next = 0xfe0248f119d8, left = 
0x0, right = 0x0,
start = 4096, end = 140737488355328, avail_ssize = 0, adj_free = 0, 
max_free = 0, object = {
  vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0, protection = 0 
'\0',
max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0 '\0', 
wired_count = 0,
next_read = 0, cred = 0x0}, lock = {lock_object = {
  lo_name = 0x80e66905 vm map (user), lo_flags = 36896768, 
lo_data = 0,
  lo_witness = 0xff80006c9700}, sx_lock = 17}, system_mtx = 
{lock_object = {
  lo_name = 0x80e668d7 vm map (system), lo_flags = 21168128, 
lo_data = 0,
  lo_witness = 0xff80006c9500}, mtx_lock = 4}, nentries = 32, size = 
64647168,
  timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags = 0 '\0',
  root = 0xfe02560a6258, pmap = 0xfe00182602b8, busy = 0}
(kgdb) p* map-pmap
$6 = {pm_mtx = {lock_object = {lo_name = 0x80e66934 pmap, lo_flags = 
21168128,
  lo_data = 0, lo_witness = 0xff80006c9900}, mtx_lock = 4}, pm_pml4 = 
0xfe0256458000,
  pm_pvchunk = {tqh_first = 0xfe0256142000, tqh_last = 0xfe025644c008}, 
pm_active = {
__bits = {1}}, pm_stats = {resident_count = 12683, wired_count = 0},
  pm_root = 0xfe041289e040}
(kgdb) p* map-root
$7 = {prev = 0xfe0018ed0708, next = 0xfe02560a6870, left = 
0xfe0018ed0708,
  right = 0xfe02560a6870, start = 34393292800, end = 34431041536, 
avail_ssize = 0,
  adj_free =

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Alan Cox 
On 11/27/2012 12:08, Andre Oppermann wrote:
 On 27.11.2012 17:42, Alan Cox wrote:
 On 11/27/2012 09:06, Konstantin Belousov wrote:
 On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
 FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
 Fri Nov 23 17:00:40 CET 2012
 a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

 #0  doadump (textdump=-2014022336) at pcpu.h:229
 #1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
 dummy2=value optimized out,
   dummy3=value optimized out, dummy4=value optimized out)
   at /usr/src/head/sys/ddb/db_command.c:578
 #2  0x8033e074 in db_command (last_cmdp=value optimized out,
   cmd_table=value optimized out, dopager=1) at
 /usr/src/head/sys/ddb/db_command.c:449
 #3  0x8033dd62 in db_command_loop () at
 /usr/src/head/sys/ddb/db_command.c:502
 #4  0x80340690 in db_trap (type=value optimized out, code=0)
   at /usr/src/head/sys/ddb/db_main.c:231
 #5  0x808b375e in kdb_trap (type=3, code=0, tf=value
 optimized
 out)
   at /usr/src/head/sys/kern/subr_kdb.c:654
 #6  0x80bfc71a in trap (frame=0xff8487f478a0)
   at /usr/src/head/sys/amd64/amd64/trap.c:579
 #7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
 #8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
 msg=value optimized out)
   at cpufunc.h:63
 #9  0x8088086f in panic (fmt=value optimized out)
   at /usr/src/head/sys/kern/kern_shutdown.c:628
 #10 0x80adea4a in vm_object_madvise (object=value
 optimized out,
   pindex=value optimized out, end=8952, advise=value
 optimized out)
   at /usr/src/head/sys/vm/vm_object.c:1101
 #11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
 start=value optimized out,
   end=value optimized out, behav=5) at
 /usr/src/head/sys/vm/vm_map.c:2140
 #12 0x80adbd8d in sys_madvise (td=value optimized out,
 uap=value optimized out)
   at /usr/src/head/sys/vm/vm_mmap.c:752
 #13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
 traced=0) at subr_syscall.c:135
 #14 0x80be689b in Xfast_syscall () at
 /tmp/exception-3nQ6Cf.s:329
 #15 0x016f3bfa in ?? ()
 I think this is an omission in the check for the object types. BTW,
 this
 pattern already repeats in several places, I thought about adding
 either
 new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
 fields to the struct vm_pager to classify the vm objects.


 A fictitious page should always have a non-zero wire count.  In fact, it
 should always be one and never change.  (See vm_page_unwire().)  In
 vm_object_madvise(), there is a check against the page's wire count that
 precedes the KASSERT().  This check should prevent the KASSERT() from
 being reached for the various device-backed object types.  So, something
 else has gone wrong here, or rather something has gone wrong elsewhere
 that caused the KASSERT() failure here.

 Andre, can we see the contents of the offending struct vm_page and also
 the struct vm_object to which the offending page belongs to?  Also, are
 you running a kernel with any experimental zero-copy send support?

 No experimental zero-copy support, or anything else, just a stock
 GENERIC kernel.

 (kgdb) frame 11
 #11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
 start=value optimized out,
 end=value optimized out, behav=5) at
 /usr/src/head/sys/vm/vm_map.c:2140
 2140   
 vm_object_madvise(current-object.vm_object, pstart,
 (kgdb) p *map
 $1 = {header = {prev = 0xfe025631c438, next = 0xfe0248f119d8,
 left = 0x0, right = 0x0,
 start = 4096, end = 140737488355328, avail_ssize = 0, adj_free =
 0, max_free = 0, object = {
   vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0,
 protection = 0 '\0',
 max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0
 '\0', wired_count = 0,
 next_read = 0, cred = 0x0}, lock = {lock_object = {
   lo_name = 0x80e66905 vm map (user), lo_flags =
 36896768, lo_data = 0,
   lo_witness = 0xff80006c9700}, sx_lock = 17}, system_mtx =
 {lock_object = {
   lo_name = 0x80e668d7 vm map (system), lo_flags =
 21168128, lo_data = 0,
   lo_witness = 0xff80006c9500}, mtx_lock = 4}, nentries = 32,
 size = 64647168,
   timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags =
 0 '\0',
   root = 0xfe02560a6258, pmap = 0xfe00182602b8, busy = 0}
 (kgdb) p* map-pmap
 $6 = {pm_mtx = {lock_object = {lo_name = 0x80e66934 pmap,
 lo_flags = 21168128,
   lo_data = 0, lo_witness = 0xff80006c9900}, mtx_lock = 4},
 pm_pml4 = 0xfe0256458000,
   pm_pvchunk = {tqh_first = 0xfe0256142000, tqh_last =
 0xfe025644c008}, pm_active = {
 __bits = {1}}, pm_stats = {resident_count = 12683, wired_count = 0},
   pm_root = 0xfe041289e040}
 (kgdb) p* map-root
 $7 = {prev = 0xfe0018ed0708, next = 0xfe02560a6870, left =

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

On 27.11.2012 19:27, Alan Cox wrote:

On 11/27/2012 12:08, Andre Oppermann wrote:

On 27.11.2012 17:42, Alan Cox wrote:

On 11/27/2012 09:06, Konstantin Belousov wrote:

On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:

FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

#0  doadump (textdump=-2014022336) at pcpu.h:229
#1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
dummy2=value optimized out,
   dummy3=value optimized out, dummy4=value optimized out)
   at /usr/src/head/sys/ddb/db_command.c:578
#2  0x8033e074 in db_command (last_cmdp=value optimized out,
   cmd_table=value optimized out, dopager=1) at
/usr/src/head/sys/ddb/db_command.c:449
#3  0x8033dd62 in db_command_loop () at
/usr/src/head/sys/ddb/db_command.c:502
#4  0x80340690 in db_trap (type=value optimized out, code=0)
   at /usr/src/head/sys/ddb/db_main.c:231
#5  0x808b375e in kdb_trap (type=3, code=0, tf=value
optimized
out)
   at /usr/src/head/sys/kern/subr_kdb.c:654
#6  0x80bfc71a in trap (frame=0xff8487f478a0)
   at /usr/src/head/sys/amd64/amd64/trap.c:579
#7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
#8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
msg=value optimized out)
   at cpufunc.h:63
#9  0x8088086f in panic (fmt=value optimized out)
   at /usr/src/head/sys/kern/kern_shutdown.c:628
#10 0x80adea4a in vm_object_madvise (object=value
optimized out,
   pindex=value optimized out, end=8952, advise=value
optimized out)
   at /usr/src/head/sys/vm/vm_object.c:1101
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
start=value optimized out,
   end=value optimized out, behav=5) at
/usr/src/head/sys/vm/vm_map.c:2140
#12 0x80adbd8d in sys_madvise (td=value optimized out,
uap=value optimized out)
   at /usr/src/head/sys/vm/vm_mmap.c:752
#13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
traced=0) at subr_syscall.c:135
#14 0x80be689b in Xfast_syscall () at
/tmp/exception-3nQ6Cf.s:329
#15 0x016f3bfa in ?? ()

I think this is an omission in the check for the object types. BTW,
this
pattern already repeats in several places, I thought about adding
either
new pager method, like boolean_t vm_pager_is_pageable(), or just a flag
fields to the struct vm_pager to classify the vm objects.



A fictitious page should always have a non-zero wire count.  In fact, it
should always be one and never change.  (See vm_page_unwire().)  In
vm_object_madvise(), there is a check against the page's wire count that
precedes the KASSERT().  This check should prevent the KASSERT() from
being reached for the various device-backed object types.  So, something
else has gone wrong here, or rather something has gone wrong elsewhere
that caused the KASSERT() failure here.

Andre, can we see the contents of the offending struct vm_page and also
the struct vm_object to which the offending page belongs to?  Also, are
you running a kernel with any experimental zero-copy send support?


No experimental zero-copy support, or anything else, just a stock
GENERIC kernel.

(kgdb) frame 11
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
start=value optimized out,
 end=value optimized out, behav=5) at
/usr/src/head/sys/vm/vm_map.c:2140
2140
vm_object_madvise(current-object.vm_object, pstart,
(kgdb) p *map
$1 = {header = {prev = 0xfe025631c438, next = 0xfe0248f119d8,
left = 0x0, right = 0x0,
 start = 4096, end = 140737488355328, avail_ssize = 0, adj_free =
0, max_free = 0, object = {
   vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0,
protection = 0 '\0',
 max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0
'\0', wired_count = 0,
 next_read = 0, cred = 0x0}, lock = {lock_object = {
   lo_name = 0x80e66905 vm map (user), lo_flags =
36896768, lo_data = 0,
   lo_witness = 0xff80006c9700}, sx_lock = 17}, system_mtx =
{lock_object = {
   lo_name = 0x80e668d7 vm map (system), lo_flags =
21168128, lo_data = 0,
   lo_witness = 0xff80006c9500}, mtx_lock = 4}, nentries = 32,
size = 64647168,
   timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags =
0 '\0',
   root = 0xfe02560a6258, pmap = 0xfe00182602b8, busy = 0}
(kgdb) p* map-pmap
$6 = {pm_mtx = {lock_object = {lo_name = 0x80e66934 pmap,
lo_flags = 21168128,
   lo_data = 0, lo_witness = 0xff80006c9900}, mtx_lock = 4},
pm_pml4 = 0xfe0256458000,
   pm_pvchunk = {tqh_first = 0xfe0256142000, tqh_last =
0xfe025644c008}, pm_active = {
 __bits = {1}}, pm_stats = {resident_count = 12683, wired_count = 0},
   pm_root = 0xfe041289e040}
(kgdb) p* map-root
$7 = {prev = 0xfe0018ed0708, next = 0xfe02560a6870, left =
0xfe0018ed0708,
   right = 0xfe02560a6870, start =

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Alan Cox 
On 11/27/2012 12:43, Andre Oppermann wrote:
 On 27.11.2012 19:27, Alan Cox wrote:
 On 11/27/2012 12:08, Andre Oppermann wrote:
 On 27.11.2012 17:42, Alan Cox wrote:
 On 11/27/2012 09:06, Konstantin Belousov wrote:
 On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
 FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
 Fri Nov 23 17:00:40 CET 2012
 a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

 #0  doadump (textdump=-2014022336) at pcpu.h:229
 #1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
 dummy2=value optimized out,
dummy3=value optimized out, dummy4=value optimized out)
at /usr/src/head/sys/ddb/db_command.c:578
 #2  0x8033e074 in db_command (last_cmdp=value optimized
 out,
cmd_table=value optimized out, dopager=1) at
 /usr/src/head/sys/ddb/db_command.c:449
 #3  0x8033dd62 in db_command_loop () at
 /usr/src/head/sys/ddb/db_command.c:502
 #4  0x80340690 in db_trap (type=value optimized out,
 code=0)
at /usr/src/head/sys/ddb/db_main.c:231
 #5  0x808b375e in kdb_trap (type=3, code=0, tf=value
 optimized
 out)
at /usr/src/head/sys/kern/subr_kdb.c:654
 #6  0x80bfc71a in trap (frame=0xff8487f478a0)
at /usr/src/head/sys/amd64/amd64/trap.c:579
 #7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
 #8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
 msg=value optimized out)
at cpufunc.h:63
 #9  0x8088086f in panic (fmt=value optimized out)
at /usr/src/head/sys/kern/kern_shutdown.c:628
 #10 0x80adea4a in vm_object_madvise (object=value
 optimized out,
pindex=value optimized out, end=8952, advise=value
 optimized out)
at /usr/src/head/sys/vm/vm_object.c:1101
 #11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
 start=value optimized out,
end=value optimized out, behav=5) at
 /usr/src/head/sys/vm/vm_map.c:2140
 #12 0x80adbd8d in sys_madvise (td=value optimized out,
 uap=value optimized out)
at /usr/src/head/sys/vm/vm_mmap.c:752
 #13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
 traced=0) at subr_syscall.c:135
 #14 0x80be689b in Xfast_syscall () at
 /tmp/exception-3nQ6Cf.s:329
 #15 0x016f3bfa in ?? ()
 I think this is an omission in the check for the object types. BTW,
 this
 pattern already repeats in several places, I thought about adding
 either
 new pager method, like boolean_t vm_pager_is_pageable(), or just a
 flag
 fields to the struct vm_pager to classify the vm objects.


 A fictitious page should always have a non-zero wire count.  In
 fact, it
 should always be one and never change.  (See vm_page_unwire().)  In
 vm_object_madvise(), there is a check against the page's wire count
 that
 precedes the KASSERT().  This check should prevent the KASSERT() from
 being reached for the various device-backed object types.  So,
 something
 else has gone wrong here, or rather something has gone wrong elsewhere
 that caused the KASSERT() failure here.

 Andre, can we see the contents of the offending struct vm_page and
 also
 the struct vm_object to which the offending page belongs to?  Also,
 are
 you running a kernel with any experimental zero-copy send support?

 No experimental zero-copy support, or anything else, just a stock
 GENERIC kernel.

 (kgdb) frame 11
 #11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
 start=value optimized out,
  end=value optimized out, behav=5) at
 /usr/src/head/sys/vm/vm_map.c:2140
 2140
 vm_object_madvise(current-object.vm_object, pstart,
 (kgdb) p *map
 $1 = {header = {prev = 0xfe025631c438, next = 0xfe0248f119d8,
 left = 0x0, right = 0x0,
  start = 4096, end = 140737488355328, avail_ssize = 0, adj_free =
 0, max_free = 0, object = {
vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0,
 protection = 0 '\0',
  max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0
 '\0', wired_count = 0,
  next_read = 0, cred = 0x0}, lock = {lock_object = {
lo_name = 0x80e66905 vm map (user), lo_flags =
 36896768, lo_data = 0,
lo_witness = 0xff80006c9700}, sx_lock = 17}, system_mtx =
 {lock_object = {
lo_name = 0x80e668d7 vm map (system), lo_flags =
 21168128, lo_data = 0,
lo_witness = 0xff80006c9500}, mtx_lock = 4}, nentries = 32,
 size = 64647168,
timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags =
 0 '\0',
root = 0xfe02560a6258, pmap = 0xfe00182602b8, busy = 0}
 (kgdb) p* map-pmap
 $6 = {pm_mtx = {lock_object = {lo_name = 0x80e66934 pmap,
 lo_flags = 21168128,
lo_data = 0, lo_witness = 0xff80006c9900}, mtx_lock = 4},
 pm_pml4 = 0xfe0256458000,
pm_pvchunk = {tqh_first = 0xfe0256142000, tqh_last =
 0xfe025644c008}, pm_active = {
  __bits = {1}}, pm_stats = {resident_count = 12683, wired_count
 = 0},
pm_root = 0xfe041289e040}

Re: panic: vm_object_madvise: page 0xfffffe0413c58630 is fictitious

2012-11-27 Thread Andre Oppermann 

On 27.11.2012 20:16, Alan Cox wrote:

On 11/27/2012 12:43, Andre Oppermann wrote:

On 27.11.2012 19:27, Alan Cox wrote:

On 11/27/2012 12:08, Andre Oppermann wrote:

On 27.11.2012 17:42, Alan Cox wrote:

On 11/27/2012 09:06, Konstantin Belousov wrote:

On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:

FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC  amd64

#0  doadump (textdump=-2014022336) at pcpu.h:229
#1  0x8033e2d2 in db_fncall (dummy1=value optimized out,
dummy2=value optimized out,
dummy3=value optimized out, dummy4=value optimized out)
at /usr/src/head/sys/ddb/db_command.c:578
#2  0x8033e074 in db_command (last_cmdp=value optimized
out,
cmd_table=value optimized out, dopager=1) at
/usr/src/head/sys/ddb/db_command.c:449
#3  0x8033dd62 in db_command_loop () at
/usr/src/head/sys/ddb/db_command.c:502
#4  0x80340690 in db_trap (type=value optimized out,
code=0)
at /usr/src/head/sys/ddb/db_main.c:231
#5  0x808b375e in kdb_trap (type=3, code=0, tf=value
optimized
out)
at /usr/src/head/sys/kern/subr_kdb.c:654
#6  0x80bfc71a in trap (frame=0xff8487f478a0)
at /usr/src/head/sys/amd64/amd64/trap.c:579
#7  0x80be65b2 in calltrap () at /tmp/exception-3nQ6Cf.s:179
#8  0x808b2f5e in kdb_enter (why=0x80e5e23b panic,
msg=value optimized out)
at cpufunc.h:63
#9  0x8088086f in panic (fmt=value optimized out)
at /usr/src/head/sys/kern/kern_shutdown.c:628
#10 0x80adea4a in vm_object_madvise (object=value
optimized out,
pindex=value optimized out, end=8952, advise=value
optimized out)
at /usr/src/head/sys/vm/vm_object.c:1101
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
start=value optimized out,
end=value optimized out, behav=5) at
/usr/src/head/sys/vm/vm_map.c:2140
#12 0x80adbd8d in sys_madvise (td=value optimized out,
uap=value optimized out)
at /usr/src/head/sys/vm/vm_mmap.c:752
#13 0x80bfd3a5 in amd64_syscall (td=0xfe001823,
traced=0) at subr_syscall.c:135
#14 0x80be689b in Xfast_syscall () at
/tmp/exception-3nQ6Cf.s:329
#15 0x016f3bfa in ?? ()

I think this is an omission in the check for the object types. BTW,
this
pattern already repeats in several places, I thought about adding
either
new pager method, like boolean_t vm_pager_is_pageable(), or just a
flag
fields to the struct vm_pager to classify the vm objects.



A fictitious page should always have a non-zero wire count.  In
fact, it
should always be one and never change.  (See vm_page_unwire().)  In
vm_object_madvise(), there is a check against the page's wire count
that
precedes the KASSERT().  This check should prevent the KASSERT() from
being reached for the various device-backed object types.  So,
something
else has gone wrong here, or rather something has gone wrong elsewhere
that caused the KASSERT() failure here.

Andre, can we see the contents of the offending struct vm_page and
also
the struct vm_object to which the offending page belongs to?  Also,
are
you running a kernel with any experimental zero-copy send support?


No experimental zero-copy support, or anything else, just a stock
GENERIC kernel.

(kgdb) frame 11
#11 0x80ad759a in vm_map_madvise (map=0xfe0018260188,
start=value optimized out,
  end=value optimized out, behav=5) at
/usr/src/head/sys/vm/vm_map.c:2140
2140
vm_object_madvise(current-object.vm_object, pstart,
(kgdb) p *map
$1 = {header = {prev = 0xfe025631c438, next = 0xfe0248f119d8,
left = 0x0, right = 0x0,
  start = 4096, end = 140737488355328, avail_ssize = 0, adj_free =
0, max_free = 0, object = {
vm_object = 0x0, sub_map = 0x0}, offset = 0, eflags = 0,
protection = 0 '\0',
  max_protection = 0 '\0', inheritance = 0 '\0', read_ahead = 0
'\0', wired_count = 0,
  next_read = 0, cred = 0x0}, lock = {lock_object = {
lo_name = 0x80e66905 vm map (user), lo_flags =
36896768, lo_data = 0,
lo_witness = 0xff80006c9700}, sx_lock = 17}, system_mtx =
{lock_object = {
lo_name = 0x80e668d7 vm map (system), lo_flags =
21168128, lo_data = 0,
lo_witness = 0xff80006c9500}, mtx_lock = 4}, nentries = 32,
size = 64647168,
timestamp = 52, needs_wakeup = 0 '\0', system_map = 0 '\0', flags =
0 '\0',
root = 0xfe02560a6258, pmap = 0xfe00182602b8, busy = 0}
(kgdb) p* map-pmap
$6 = {pm_mtx = {lock_object = {lo_name = 0x80e66934 pmap,
lo_flags = 21168128,
lo_data = 0, lo_witness = 0xff80006c9900}, mtx_lock = 4},
pm_pml4 = 0xfe0256458000,
pm_pvchunk = {tqh_first = 0xfe0256142000, tqh_last =
0xfe025644c008}, pm_active = {
  __bits = {1}}, pm_stats = {resident_count = 12683, wired_count
= 0},
pm_root = 0xfe041289e040}
(kgdb) p* map-root
$7 = {prev =