Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Cy Schubert]

In message 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Warner Losh]

On Sun, Jan 28, 2018 at 7:38 PM, Cy Schubert 
wrote:

> In message <2effa324-c428-6135-371b-acb00c803...@freebsd.org>, Allan
> Jude write
> s:
> > On 2018-01-28 16:28, Warner Losh wrote:
> > > On Sun, Jan 28, 2018 at 2:22 PM, thomas masper <
> thomas.mas...@gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >> similar panic happen to me when extracting a pendrive from laptop USB
> port
> > >> (I tried 3 different pendrive).
> > >> No issue if I reboot or shutdown. I don't know if those two issues are
> > >> related.
> > >>
> > >
> > > Do you have a reproducible test case? Ideally, it would be 'insert and
> > > remove usb thumb drive' but maybe there's more steps between insert and
> > > removal.
> > >
> > > Warner
> > >
> > >
> > >
> > >> panic: Releasing 6 with cnt = -559038242
>
> Converting this to hex we get DEADC0DE.


vm/uma_dbg.c:static const uint32_t uma_junk = 0xdeadc0de;

Use after free it is then...

Warner


> > >>
> > >> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
> > >> Copyright (C) 2017 Free Software Foundation, Inc.
> > >> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.
> > >> html
> > >>>
> > >> This is free software: you are free to change and redistribute it.
> > >> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > >> and "show warranty" for details.
> > >> This GDB was configured as "x86_64-portbld-freebsd12.0".
> > >> Type "show configuration" for configuration details.
> > >> For bug reporting instructions, please see:
> > >> .
> > >> Find the GDB manual and other documentation resources online at:
> > >> .
> > >> For help, type "help".
> > >> Type "apropos word" to search for commands related to "word"...
> > >> Reading symbols from /boot/kernel/kernel...Reading symbols from
> > >> /usr/lib/debug//boot/kernel/kernel.debug...done.
> > >> done.
> > >>
> > >> Unread portion of the kernel message buffer:
> > >> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
> > >> da0:   s/n 30E47C20 detached
> > >> (da0:umass-sim0:0:0:0): Periph destroyed
> > >> panic: Releasing 6 with cnt = -559038242
> > >> cpuid = 0
> > >> time = 1517158352
> > >> KDB: stack backtrace:
> > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > >> 0xfe00593838c0
> > >> vpanic() at vpanic+0x18d/frame 0xfe0059383920
> > >> panic() at panic+0x43/frame 0xfe0059383980
> > >> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
> > >> g_disk_providergone() at g_disk_providergone+0x25/frame
> 0xfe00593839d0
> > >> g_destroy_provider() at g_destroy_provider+0xae/frame
> 0xfe00593839f0
> > >> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
> > >> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
> > >> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
> > >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
> > >> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > >> KDB: enter: panic
> > >>
> > >> __curthread () at ./machine/pcpu.h:229
> > >> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
> > >> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
> > >> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
> > >> #2  0x8040a08b in db_dump (dummy=,
> > >> dummy2=, dummy3=, dummy4=)
> > >> at /usr/src/sys/ddb/db_command.c:574
> > >> #3  0x80409e59 in db_command (last_cmdp=,
> > >> cmd_table=, dopager=)
> > >> at /usr/src/sys/ddb/db_command.c:481
> > >> #4  0x80409bd4 in db_command_loop ()
> > >> at /usr/src/sys/ddb/db_command.c:534
> > >> #5  0x8040cdff in db_trap (type=,
> code= > >> out>)
> > >> at /usr/src/sys/ddb/db_main.c:250
> > >> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf= > >> out>)
> > >> at /usr/src/sys/kern/subr_kdb.c:697
> > >> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
> > >> at /usr/src/sys/amd64/amd64/trap.c:547
> > >> #8  
> > >> #9  kdb_enter (why=0x811f101e "panic", msg=)
> > >> at /usr/src/sys/kern/subr_kdb.c:479
> > >> #10 0x80ac8d3a in vpanic (fmt=,
> > >> ap=0xfe0059383960)
> > >> at /usr/src/sys/kern/kern_shutdown.c:800
> > >> #11 0x80ac8dc3 in panic (
> > >> fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\
> > >> 377")
> > >> at /usr/src/sys/kern/kern_shutdown.c:738
> > >> #12 0x80368bb2 in da_periph_release (periph=,
> > >> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
> > >> #13 dadiskgonecb (dp=) at
> > >> /usr/src/sys/cam/scsi/scsi_da.c:1904
> > >> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
> > >> at /usr/src/sys/geom/geom_disk.c:783
> > >> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
> > >> at /usr/src/sys/geom/geom_subr.c:746
> > >> #16 0x80a15e17 in g_wither_washer ()
> > >> at 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Allan Jude]

On 2018-01-28 21:29, Warner Losh wrote:
> 
> I've been seeing this today while working on my laptop.
> 
> 1) insert USB stick.
> 2) mount UFS partition to /mnt
> 3) copy a file off
> 4) umount /mnt
> 5) remove usb stick
> 6) instant panic
> 
> Oddly, it is the same negative number every time (-559038242), so it
> isn't random/memory corruption.
> 
> 
> 
> Is mount required?
> 
> Warner 
> 
> 
No, I just plugged the USB stick in, and then removed it 10 seconds
later, panic.

I've also seen it in VirtualBox when removing a virtual CD (.iso)


-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Cy Schubert]

In message <2effa324-c428-6135-371b-acb00c803...@freebsd.org>, Allan 
Jude write
s:
> On 2018-01-28 16:28, Warner Losh wrote:
> > On Sun, Jan 28, 2018 at 2:22 PM, thomas masper 
> > wrote:
> > 
> >> Hi,
> >> similar panic happen to me when extracting a pendrive from laptop USB port
> >> (I tried 3 different pendrive).
> >> No issue if I reboot or shutdown. I don't know if those two issues are
> >> related.
> >>
> > 
> > Do you have a reproducible test case? Ideally, it would be 'insert and
> > remove usb thumb drive' but maybe there's more steps between insert and
> > removal.
> > 
> > Warner
> > 
> > 
> > 
> >> panic: Releasing 6 with cnt = -559038242

Converting this to hex we get DEADC0DE.

> >>
> >> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
> >> Copyright (C) 2017 Free Software Foundation, Inc.
> >> License GPLv3+: GNU GPL version 3 or later  >> html
> >>>
> >> This is free software: you are free to change and redistribute it.
> >> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> >> and "show warranty" for details.
> >> This GDB was configured as "x86_64-portbld-freebsd12.0".
> >> Type "show configuration" for configuration details.
> >> For bug reporting instructions, please see:
> >> .
> >> Find the GDB manual and other documentation resources online at:
> >> .
> >> For help, type "help".
> >> Type "apropos word" to search for commands related to "word"...
> >> Reading symbols from /boot/kernel/kernel...Reading symbols from
> >> /usr/lib/debug//boot/kernel/kernel.debug...done.
> >> done.
> >>
> >> Unread portion of the kernel message buffer:
> >> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
> >> da0:   s/n 30E47C20 detached
> >> (da0:umass-sim0:0:0:0): Periph destroyed
> >> panic: Releasing 6 with cnt = -559038242
> >> cpuid = 0
> >> time = 1517158352
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> >> 0xfe00593838c0
> >> vpanic() at vpanic+0x18d/frame 0xfe0059383920
> >> panic() at panic+0x43/frame 0xfe0059383980
> >> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
> >> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe00593839d0
> >> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
> >> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
> >> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
> >> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
> >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
> >> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> >> KDB: enter: panic
> >>
> >> __curthread () at ./machine/pcpu.h:229
> >> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
> >> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
> >> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
> >> #2  0x8040a08b in db_dump (dummy=,
> >> dummy2=, dummy3=, dummy4=)
> >> at /usr/src/sys/ddb/db_command.c:574
> >> #3  0x80409e59 in db_command (last_cmdp=,
> >> cmd_table=, dopager=)
> >> at /usr/src/sys/ddb/db_command.c:481
> >> #4  0x80409bd4 in db_command_loop ()
> >> at /usr/src/sys/ddb/db_command.c:534
> >> #5  0x8040cdff in db_trap (type=, code= >> out>)
> >> at /usr/src/sys/ddb/db_main.c:250
> >> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf= >> out>)
> >> at /usr/src/sys/kern/subr_kdb.c:697
> >> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
> >> at /usr/src/sys/amd64/amd64/trap.c:547
> >> #8  
> >> #9  kdb_enter (why=0x811f101e "panic", msg=)
> >> at /usr/src/sys/kern/subr_kdb.c:479
> >> #10 0x80ac8d3a in vpanic (fmt=,
> >> ap=0xfe0059383960)
> >> at /usr/src/sys/kern/kern_shutdown.c:800
> >> #11 0x80ac8dc3 in panic (
> >> fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\
> >> 377")
> >> at /usr/src/sys/kern/kern_shutdown.c:738
> >> #12 0x80368bb2 in da_periph_release (periph=,
> >> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
> >> #13 dadiskgonecb (dp=) at
> >> /usr/src/sys/cam/scsi/scsi_da.c:1904
> >> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
> >> at /usr/src/sys/geom/geom_disk.c:783
> >> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
> >> at /usr/src/sys/geom/geom_subr.c:746
> >> #16 0x80a15e17 in g_wither_washer ()
> >> at /usr/src/sys/geom/geom_subr.c:461
> >> #17 0x80a112da in g_run_events ()
> >> at /usr/src/sys/geom/geom_event.c:297
> >> #18 0x80a89444 in fork_exit (
> >> callout=0x80a138c0 , arg=0x0,
> >> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
> >> #19 
> >> (kgdb)
> >>
> >>
> >> uname -a
> >> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
> >> r328509M: Sun 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Warner Losh]

On Jan 28, 2018 6:41 PM, "Allan Jude"  wrote:

On 2018-01-28 16:28, Warner Losh wrote:
> On Sun, Jan 28, 2018 at 2:22 PM, thomas masper 
> wrote:
>
>> Hi,
>> similar panic happen to me when extracting a pendrive from laptop USB
port
>> (I tried 3 different pendrive).
>> No issue if I reboot or shutdown. I don't know if those two issues are
>> related.
>>
>
> Do you have a reproducible test case? Ideally, it would be 'insert and
> remove usb thumb drive' but maybe there's more steps between insert and
> removal.
>
> Warner
>
>
>
>> panic: Releasing 6 with cnt = -559038242
>>
>> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later > html
>>>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-portbld-freebsd12.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /boot/kernel/kernel...Reading symbols from
>> /usr/lib/debug//boot/kernel/kernel.debug...done.
>> done.
>>
>> Unread portion of the kernel message buffer:
>> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
>> da0:   s/n 30E47C20 detached
>> (da0:umass-sim0:0:0:0): Periph destroyed
>> panic: Releasing 6 with cnt = -559038242
>> cpuid = 0
>> time = 1517158352
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe00593838c0
>> vpanic() at vpanic+0x18d/frame 0xfe0059383920
>> panic() at panic+0x43/frame 0xfe0059383980
>> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
>> g_disk_providergone() at g_disk_providergone+0x25/frame
0xfe00593839d0
>> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
>> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
>> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
>> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> KDB: enter: panic
>>
>> __curthread () at ./machine/pcpu.h:229
>> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
>> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
>> #2  0x8040a08b in db_dump (dummy=,
>> dummy2=, dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:574
>> #3  0x80409e59 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #4  0x80409bd4 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #5  0x8040cdff in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf=> out>)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
>> at /usr/src/sys/amd64/amd64/trap.c:547
>> #8  
>> #9  kdb_enter (why=0x811f101e "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #10 0x80ac8d3a in vpanic (fmt=,
>> ap=0xfe0059383960)
>> at /usr/src/sys/kern/kern_shutdown.c:800
>> #11 0x80ac8dc3 in panic (
>> fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\
>> 377")
>> at /usr/src/sys/kern/kern_shutdown.c:738
>> #12 0x80368bb2 in da_periph_release (periph=,
>> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
>> #13 dadiskgonecb (dp=) at
>> /usr/src/sys/cam/scsi/scsi_da.c:1904
>> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_disk.c:783
>> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_subr.c:746
>> #16 0x80a15e17 in g_wither_washer ()
>> at /usr/src/sys/geom/geom_subr.c:461
>> #17 0x80a112da in g_run_events ()
>> at /usr/src/sys/geom/geom_event.c:297
>> #18 0x80a89444 in fork_exit (
>> callout=0x80a138c0 , arg=0x0,
>> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
>> #19 
>> (kgdb)
>>
>>
>> uname -a
>> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
>> r328509M: Sun Jan 28 15:38:35 CET 2018
>> to...@laptopw530.tommybsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>>
>> Regards,
>> thomas
>>
>>
>> On Fri, Jan 26, 2018 at 4:07 PM, David Wolfskill 
>> wrote:
>>
>>> On Fri, Jan 26, 2018 at 07:47:48AM -0700, Warner Losh wrote:

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Allan Jude]

On 2018-01-28 16:28, Warner Losh wrote:
> On Sun, Jan 28, 2018 at 2:22 PM, thomas masper 
> wrote:
> 
>> Hi,
>> similar panic happen to me when extracting a pendrive from laptop USB port
>> (I tried 3 different pendrive).
>> No issue if I reboot or shutdown. I don't know if those two issues are
>> related.
>>
> 
> Do you have a reproducible test case? Ideally, it would be 'insert and
> remove usb thumb drive' but maybe there's more steps between insert and
> removal.
> 
> Warner
> 
> 
> 
>> panic: Releasing 6 with cnt = -559038242
>>
>> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later > html
>>>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-portbld-freebsd12.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /boot/kernel/kernel...Reading symbols from
>> /usr/lib/debug//boot/kernel/kernel.debug...done.
>> done.
>>
>> Unread portion of the kernel message buffer:
>> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
>> da0:   s/n 30E47C20 detached
>> (da0:umass-sim0:0:0:0): Periph destroyed
>> panic: Releasing 6 with cnt = -559038242
>> cpuid = 0
>> time = 1517158352
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe00593838c0
>> vpanic() at vpanic+0x18d/frame 0xfe0059383920
>> panic() at panic+0x43/frame 0xfe0059383980
>> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
>> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe00593839d0
>> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
>> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
>> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
>> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> KDB: enter: panic
>>
>> __curthread () at ./machine/pcpu.h:229
>> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
>> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
>> #2  0x8040a08b in db_dump (dummy=,
>> dummy2=, dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:574
>> #3  0x80409e59 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #4  0x80409bd4 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #5  0x8040cdff in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf=> out>)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
>> at /usr/src/sys/amd64/amd64/trap.c:547
>> #8  
>> #9  kdb_enter (why=0x811f101e "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #10 0x80ac8d3a in vpanic (fmt=,
>> ap=0xfe0059383960)
>> at /usr/src/sys/kern/kern_shutdown.c:800
>> #11 0x80ac8dc3 in panic (
>> fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\
>> 377")
>> at /usr/src/sys/kern/kern_shutdown.c:738
>> #12 0x80368bb2 in da_periph_release (periph=,
>> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
>> #13 dadiskgonecb (dp=) at
>> /usr/src/sys/cam/scsi/scsi_da.c:1904
>> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_disk.c:783
>> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_subr.c:746
>> #16 0x80a15e17 in g_wither_washer ()
>> at /usr/src/sys/geom/geom_subr.c:461
>> #17 0x80a112da in g_run_events ()
>> at /usr/src/sys/geom/geom_event.c:297
>> #18 0x80a89444 in fork_exit (
>> callout=0x80a138c0 , arg=0x0,
>> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
>> #19 
>> (kgdb)
>>
>>
>> uname -a
>> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
>> r328509M: Sun Jan 28 15:38:35 CET 2018
>> to...@laptopw530.tommybsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>>
>> Regards,
>> thomas
>>
>>
>> On Fri, Jan 26, 2018 at 4:07 PM, David Wolfskill 
>> wrote:
>>
>>> On Fri, Jan 26, 2018 at 07:47:48AM -0700, Warner Losh wrote:
 On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Konrad Witaszczyk]

On 01/28/2018 22:28, Warner Losh wrote:
> On Sun, Jan 28, 2018 at 2:22 PM, thomas masper 
> wrote:
> 
>> Hi,
>> similar panic happen to me when extracting a pendrive from laptop USB port
>> (I tried 3 different pendrive).
>> No issue if I reboot or shutdown. I don't know if those two issues are
>> related.
>>
> 
> Do you have a reproducible test case? Ideally, it would be 'insert and
> remove usb thumb drive' but maybe there's more steps between insert and
> removal.
> 
> Warner

I hit the same problem after upgrading to r328500. I booted my laptop from a
pendrive, got a GELI password prompt, removed the pendrive, typed in a GELI
password and then I got the kernel panic. Removing the pendrive at an earlier
stage is a workaround for me at the moment.

>> panic: Releasing 6 with cnt = -559038242
>>
>> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later > html
>>>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-portbld-freebsd12.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /boot/kernel/kernel...Reading symbols from
>> /usr/lib/debug//boot/kernel/kernel.debug...done.
>> done.
>>
>> Unread portion of the kernel message buffer:
>> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
>> da0:   s/n 30E47C20 detached
>> (da0:umass-sim0:0:0:0): Periph destroyed
>> panic: Releasing 6 with cnt = -559038242
>> cpuid = 0
>> time = 1517158352
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe00593838c0
>> vpanic() at vpanic+0x18d/frame 0xfe0059383920
>> panic() at panic+0x43/frame 0xfe0059383980
>> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
>> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe00593839d0
>> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
>> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
>> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
>> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> KDB: enter: panic
>>
>> __curthread () at ./machine/pcpu.h:229
>> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
>> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
>> #2  0x8040a08b in db_dump (dummy=,
>> dummy2=, dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:574
>> #3  0x80409e59 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #4  0x80409bd4 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #5  0x8040cdff in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf=> out>)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
>> at /usr/src/sys/amd64/amd64/trap.c:547
>> #8  
>> #9  kdb_enter (why=0x811f101e "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #10 0x80ac8d3a in vpanic (fmt=,
>> ap=0xfe0059383960)
>> at /usr/src/sys/kern/kern_shutdown.c:800
>> #11 0x80ac8dc3 in panic (
>> fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\
>> 377")
>> at /usr/src/sys/kern/kern_shutdown.c:738
>> #12 0x80368bb2 in da_periph_release (periph=,
>> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
>> #13 dadiskgonecb (dp=) at
>> /usr/src/sys/cam/scsi/scsi_da.c:1904
>> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_disk.c:783
>> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_subr.c:746
>> #16 0x80a15e17 in g_wither_washer ()
>> at /usr/src/sys/geom/geom_subr.c:461
>> #17 0x80a112da in g_run_events ()
>> at /usr/src/sys/geom/geom_event.c:297
>> #18 0x80a89444 in fork_exit (
>> callout=0x80a138c0 , arg=0x0,
>> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
>> #19 
>> (kgdb)
>>
>>
>> uname -a
>> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
>> r328509M: Sun Jan 28 15:38:35 CET 2018
>> 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[thomas masper]

> Do you have a reproducible test case? Ideally, it would be 'insert and
> remove usb thumb drive' but maybe there's more steps between insert and
> removal.

Exactly! Just insert and remove the usb thumb drive.
Happen in both USB3 and USB2 ports of the laptop.


Regards
thomas

On Sun, Jan 28, 2018 at 10:28 PM, Warner Losh  wrote:
>
>
> On Sun, Jan 28, 2018 at 2:22 PM, thomas masper 
> wrote:
>>
>> Hi,
>> similar panic happen to me when extracting a pendrive from laptop USB port
>> (I tried 3 different pendrive).
>> No issue if I reboot or shutdown. I don't know if those two issues are
>> related.
>
>
> Do you have a reproducible test case? Ideally, it would be 'insert and
> remove usb thumb drive' but maybe there's more steps between insert and
> removal.
>
> Warner
>
>
>>
>> panic: Releasing 6 with cnt = -559038242
>>
>> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> > >
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-portbld-freebsd12.0".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /boot/kernel/kernel...Reading symbols from
>> /usr/lib/debug//boot/kernel/kernel.debug...done.
>> done.
>>
>> Unread portion of the kernel message buffer:
>> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
>> da0:   s/n 30E47C20 detached
>> (da0:umass-sim0:0:0:0): Periph destroyed
>> panic: Releasing 6 with cnt = -559038242
>> cpuid = 0
>> time = 1517158352
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe00593838c0
>> vpanic() at vpanic+0x18d/frame 0xfe0059383920
>> panic() at panic+0x43/frame 0xfe0059383980
>> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
>> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe00593839d0
>> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
>> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
>> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
>> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> KDB: enter: panic
>>
>> __curthread () at ./machine/pcpu.h:229
>> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
>> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
>> #2  0x8040a08b in db_dump (dummy=,
>> dummy2=, dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:574
>> #3  0x80409e59 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #4  0x80409bd4 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #5  0x8040cdff in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf=> out>)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
>> at /usr/src/sys/amd64/amd64/trap.c:547
>> #8  
>> #9  kdb_enter (why=0x811f101e "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #10 0x80ac8d3a in vpanic (fmt=,
>> ap=0xfe0059383960)
>> at /usr/src/sys/kern/kern_shutdown.c:800
>> #11 0x80ac8dc3 in panic (
>> fmt=0x81b1bbd8 
>> "\257\257\033\201\377\377\377\377")
>> at /usr/src/sys/kern/kern_shutdown.c:738
>> #12 0x80368bb2 in da_periph_release (periph=,
>> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
>> #13 dadiskgonecb (dp=) at
>> /usr/src/sys/cam/scsi/scsi_da.c:1904
>> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_disk.c:783
>> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
>> at /usr/src/sys/geom/geom_subr.c:746
>> #16 0x80a15e17 in g_wither_washer ()
>> at /usr/src/sys/geom/geom_subr.c:461
>> #17 0x80a112da in g_run_events ()
>> at /usr/src/sys/geom/geom_event.c:297
>> #18 0x80a89444 in fork_exit (
>> callout=0x80a138c0 , arg=0x0,
>> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
>> #19 
>> (kgdb)
>>
>>
>> uname -a
>> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
>> r328509M: Sun Jan 28 15:38:35 CET 2018
>> 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Warner Losh]

On Sun, Jan 28, 2018 at 2:22 PM, thomas masper 
wrote:

> Hi,
> similar panic happen to me when extracting a pendrive from laptop USB port
> (I tried 3 different pendrive).
> No issue if I reboot or shutdown. I don't know if those two issues are
> related.
>

Do you have a reproducible test case? Ideally, it would be 'insert and
remove usb thumb drive' but maybe there's more steps between insert and
removal.

Warner



> panic: Releasing 6 with cnt = -559038242
>
> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  html
> >
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /boot/kernel/kernel...Reading symbols from
> /usr/lib/debug//boot/kernel/kernel.debug...done.
> done.
>
> Unread portion of the kernel message buffer:
> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
> da0:   s/n 30E47C20 detached
> (da0:umass-sim0:0:0:0): Periph destroyed
> panic: Releasing 6 with cnt = -559038242
> cpuid = 0
> time = 1517158352
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe00593838c0
> vpanic() at vpanic+0x18d/frame 0xfe0059383920
> panic() at panic+0x43/frame 0xfe0059383980
> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe00593839d0
> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
> g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
> g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
> fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
>
> __curthread () at ./machine/pcpu.h:229
> 229 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:229
> #1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
> #2  0x8040a08b in db_dump (dummy=,
> dummy2=, dummy3=, dummy4=)
> at /usr/src/sys/ddb/db_command.c:574
> #3  0x80409e59 in db_command (last_cmdp=,
> cmd_table=, dopager=)
> at /usr/src/sys/ddb/db_command.c:481
> #4  0x80409bd4 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:534
> #5  0x8040cdff in db_trap (type=, code= out>)
> at /usr/src/sys/ddb/db_main.c:250
> #6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf= out>)
> at /usr/src/sys/kern/subr_kdb.c:697
> #7  0x80f7b498 in trap (frame=0xfe00593837f0)
> at /usr/src/sys/amd64/amd64/trap.c:547
> #8  
> #9  kdb_enter (why=0x811f101e "panic", msg=)
> at /usr/src/sys/kern/subr_kdb.c:479
> #10 0x80ac8d3a in vpanic (fmt=,
> ap=0xfe0059383960)
> at /usr/src/sys/kern/kern_shutdown.c:800
> #11 0x80ac8dc3 in panic (
> fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\
> 377")
> at /usr/src/sys/kern/kern_shutdown.c:738
> #12 0x80368bb2 in da_periph_release (periph=,
> token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
> #13 dadiskgonecb (dp=) at
> /usr/src/sys/cam/scsi/scsi_da.c:1904
> #14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
> at /usr/src/sys/geom/geom_disk.c:783
> #15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
> at /usr/src/sys/geom/geom_subr.c:746
> #16 0x80a15e17 in g_wither_washer ()
> at /usr/src/sys/geom/geom_subr.c:461
> #17 0x80a112da in g_run_events ()
> at /usr/src/sys/geom/geom_event.c:297
> #18 0x80a89444 in fork_exit (
> callout=0x80a138c0 , arg=0x0,
> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
> #19 
> (kgdb)
>
>
> uname -a
> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
> r328509M: Sun Jan 28 15:38:35 CET 2018
> to...@laptopw530.tommybsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
>
> Regards,
> thomas
>
>
> On Fri, Jan 26, 2018 at 4:07 PM, David Wolfskill 
> wrote:
>
> > On Fri, Jan 26, 2018 at 07:47:48AM -0700, Warner Losh wrote:
> > > On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill  >
> > > wrote:
> > >
> > > > This is on my "build machine" (laptop is still building updated ports
> > > > for today, so I don't know yet whether or not it 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[thomas masper]

Hi,
similar panic happen to me when extracting a pendrive from laptop USB port
(I tried 3 different pendrive).
No issue if I reboot or shutdown. I don't know if those two issues are
related.

panic: Releasing 6 with cnt = -559038242

GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0:   s/n 30E47C20 detached
(da0:umass-sim0:0:0:0): Periph destroyed
panic: Releasing 6 with cnt = -559038242
cpuid = 0
time = 1517158352
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00593838c0
vpanic() at vpanic+0x18d/frame 0xfe0059383920
panic() at panic+0x43/frame 0xfe0059383980
dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe00593839a0
g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe00593839d0
g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe00593839f0
g_wither_washer() at g_wither_washer+0x87/frame 0xfe0059383a30
g_run_events() at g_run_events+0x3ca/frame 0xfe0059383a70
fork_exit() at fork_exit+0x84/frame 0xfe0059383ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0059383ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at ./machine/pcpu.h:229
229 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:229
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:346
#2  0x8040a08b in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:574
#3  0x80409e59 in db_command (last_cmdp=,
cmd_table=, dopager=)
at /usr/src/sys/ddb/db_command.c:481
#4  0x80409bd4 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:534
#5  0x8040cdff in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:250
#6  0x80b0d923 in kdb_trap (type=3, code=-61456, tf=)
at /usr/src/sys/kern/subr_kdb.c:697
#7  0x80f7b498 in trap (frame=0xfe00593837f0)
at /usr/src/sys/amd64/amd64/trap.c:547
#8  
#9  kdb_enter (why=0x811f101e "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:479
#10 0x80ac8d3a in vpanic (fmt=,
ap=0xfe0059383960)
at /usr/src/sys/kern/kern_shutdown.c:800
#11 0x80ac8dc3 in panic (
fmt=0x81b1bbd8  "\257\257\033\201\377\377\377\377")
at /usr/src/sys/kern/kern_shutdown.c:738
#12 0x80368bb2 in da_periph_release (periph=,
token=DA_REF_GEOM) at /usr/src/sys/cam/scsi/scsi_da.c:1591
#13 dadiskgonecb (dp=) at
/usr/src/sys/cam/scsi/scsi_da.c:1904
#14 0x80a0fdd5 in g_disk_providergone (pp=0xf80003e8b700)
at /usr/src/sys/geom/geom_disk.c:783
#15 0x80a15f9e in g_destroy_provider (pp=0xf80003e8b700)
at /usr/src/sys/geom/geom_subr.c:746
#16 0x80a15e17 in g_wither_washer ()
at /usr/src/sys/geom/geom_subr.c:461
#17 0x80a112da in g_run_events ()
at /usr/src/sys/geom/geom_event.c:297
#18 0x80a89444 in fork_exit (
callout=0x80a138c0 , arg=0x0,
frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
#19 
(kgdb)


uname -a
FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
r328509M: Sun Jan 28 15:38:35 CET 2018
to...@laptopw530.tommybsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

Regards,
thomas


On Fri, Jan 26, 2018 at 4:07 PM, David Wolfskill 
wrote:

> On Fri, Jan 26, 2018 at 07:47:48AM -0700, Warner Losh wrote:
> > On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill 
> > wrote:
> >
> > > This is on my "build machine" (laptop is still building updated ports
> > > for today, so I don't know yet whether or not it encounters this.)
> > >
> >
> > Running a kernel with INVARIANTS, right?
>
> Yes -- GENERIC.
>
> > > I had performed a source-based update from r328393 to r328436,
> > > rebooted, performed "make delete-old-libs", and all seemed well.
> > >
> >
> > This has my change 328415 in it.
>
> :-)
>
> > > I then issued "sudo shutdown -p now", and serial console shows:
> > > panic: Unholding 6 with cnt = -559038242
> > > cpuid = 3
> > > time = 1516968697
> > > KDB: stack backtrace:
> > > 

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[David Wolfskill]

On Fri, Jan 26, 2018 at 07:47:48AM -0700, Warner Losh wrote:
> On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill 
> wrote:
> 
> > This is on my "build machine" (laptop is still building updated ports
> > for today, so I don't know yet whether or not it encounters this.)
> >
> 
> Running a kernel with INVARIANTS, right?

Yes -- GENERIC.

> > I had performed a source-based update from r328393 to r328436,
> > rebooted, performed "make delete-old-libs", and all seemed well.
> >
> 
> This has my change 328415 in it.

:-)

> > I then issued "sudo shutdown -p now", and serial console shows:
> > panic: Unholding 6 with cnt = -559038242
> > cpuid = 3
> > time = 1516968697
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe4288c0
> > vpanic() at vpanic+0x18d/frame 0xfe428920
> > panic() at panic+0x43/frame 0xfe428980
> > dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe4289a0
> > g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe4289d0
> > g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe4289f0
> > g_wither_washer() at g_wither_washer+0x87/frame 0xfe428a30
> > g_run_events() at g_run_events+0x3ca/frame 0xfe428a70
> > fork_exit() at fork_exit+0x84/frame 0xfe428ab0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe428ab0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > KDB: enter: panic
> > [ thread pid 13 tid 100044 ]
> > Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> > db>
> >
> 
> That's no good. We're releasing a reference to the da peripheral because
> geom has finished with the disk and is giving us a final callback so we can
> drop the reference we took when we created the geom. Trouble is, cnt should
> be like 1 always for this code, but it's not. It looks like it may be bytes
> to a pointer :(
> 
> 
> > As noted, this is a build machine, and it was to be powered off for
> > the rest of the day anyway, so I don't need to get it up & running
> > immediately: I can poke at the ddb prompt, given some clues.
> >
> 
> I don't suppose you can attach kgdb to this machine? I'd be interested to
> see what the contents of the softc are...a

Pointer to how to do that?

I do have ddb right now

> 
> Thanks for the report. This is quite troubling.

Well, let's get it fixed, then! :-)

> Warner
> 

I should still have access to the serial console after I get in to the
office (heading out shortly).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"unfortunately, no trust!” -- well, of course!  You reap what you sow.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[Warner Losh]

On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill 
wrote:

> This is on my "build machine" (laptop is still building updated ports
> for today, so I don't know yet whether or not it encounters this.)
>

Running a kernel with INVARIANTS, right?


> I had performed a source-based update from r328393 to r328436,
> rebooted, performed "make delete-old-libs", and all seemed well.
>

This has my change 328415 in it.


> I then issued "sudo shutdown -p now", and serial console shows:
> panic: Unholding 6 with cnt = -559038242
> cpuid = 3
> time = 1516968697
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe4288c0
> vpanic() at vpanic+0x18d/frame 0xfe428920
> panic() at panic+0x43/frame 0xfe428980
> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe4289a0
> g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe4289d0
> g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe4289f0
> g_wither_washer() at g_wither_washer+0x87/frame 0xfe428a30
> g_run_events() at g_run_events+0x3ca/frame 0xfe428a70
> fork_exit() at fork_exit+0x84/frame 0xfe428ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe428ab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> [ thread pid 13 tid 100044 ]
> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> db>
>

That's no good. We're releasing a reference to the da peripheral because
geom has finished with the disk and is giving us a final callback so we can
drop the reference we took when we created the geom. Trouble is, cnt should
be like 1 always for this code, but it's not. It looks like it may be bytes
to a pointer :(


> As noted, this is a build machine, and it was to be powered off for
> the rest of the day anyway, so I don't need to get it up & running
> immediately: I can poke at the ddb prompt, given some clues.
>

I don't suppose you can attach kgdb to this machine? I'd be interested to
see what the contents of the softc are...a


> Same system had completed a source-based update for stable/11 from
> r328392 to r328429 earlier today without incident (using a different
> slice of the boot drive).
>

Thanks for the report. This is quite troubling.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[David Wolfskill]

On Fri, Jan 26, 2018 at 04:29:47AM -0800, David Wolfskill wrote:
> This is on my "build machine" (laptop is still building updated ports
> for today, so I don't know yet whether or not it encounters this.) 
> 

The laptop did the same source-based update, and did not exhibit the
panic.

(On the laptop) following the "make delete-old-libs", I did a normal
"shutdown -r now" (as I normally continue using the laptop throughout
the day); when it started to boot, I coerced it to boot head again, then
logged in an ran "poweroff" -- to which it complied without issue.

The build machine went from

FreeBSD 12.0-CURRENT #83  r328393M/328393:1200056: Thu Jan 25 04:37:47 PST 2018 

r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64

to

FreeBSD 12.0-CURRENT #84  r328436M/328436:1200056: Fri Jan 26 04:02:06 PST 2018 

r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64


The laptop went from

FreeBSD 12.0-CURRENT #80  r328393M/328393:1200056: Thu Jan 25 04:56:41 PST 2018 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64

to

FreeBSD 12.0-CURRENT #81  r328436M/328436:1200056: Fri Jan 26 05:41:19 PST 2018 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"unfortunately, no trust!” -- well, of course!  You reap what you sow.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

[David Wolfskill]

This is on my "build machine" (laptop is still building updated ports
for today, so I don't know yet whether or not it encounters this.) 

I had performed a source-based update from r328393 to r328436,
rebooted, performed "make delete-old-libs", and all seemed well.

I then issued "sudo shutdown -p now", and serial console shows:

FreeBSD/amd64 (freebeast.catwhisker.org) (ttyu0)

login: Jan 26 12:11:03 Stopping sshd.
Waiting for PIDS: 681.
Stopping rsyncd.
Waiting for PIDS: 652.
Stopping powerd.
Waiting for PIDS: 636.
Stopping ntpd.
Waiting for PIDS: 633, 633.
Stopping lpd.
Waiting for PIDS: 610.
Stopping lockd.
WaitingWARNING: autofs_unmount: vflush failed with error 16
 for PIDS: 592.
Stopping statd.
Waiting for PIDS: 589.
Stopping nfsd.
WaitinlJan 26 12:11:05 ock ordefreebeast syslogr reversal:
 1st 0xf800692cd490 filed: exiting on sidesc structure (filedesc structure) 
@ /usr/src/sys/kern/sys_generic.c:1567
 2nd 0xf8006973f9a0 devfs (devfs) @ /usr/src/gnal 15
sys/kern/vfs_vnops.c:1526
stack backtrace:
#0 0x80b2c2e3 at witness_debugger+0x73
#1 0x80b2c164 at witness_checkorder+0xe34
#2 0x80a9ca21 at lockmgr_lock_fast_path+0x1b1
#3 0x810f8ca9 at VOP_LOCK1_APV+0xd9
#4 0x80ba7746 at _vn_lock+0x66
#5 0x80ba654b at vn_poll+0x3b
#6 0x80992f4d at devfs_poll_f+0xcd
#7 0x80b33255 at kern_poll+0x385
#8 0x80b32ec0 at sys_poll+0x50
#9 0x80f7a37b at amd64_syscall+0x79b
#10 0x80f569c8 at fast_syscall_common+0xfc
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop... 
Syncing disks, vnodes remaining... 5 5 lock order reversal:
 1st 0xf80007927240 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2157
 2nd 0xf80007570d50 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1583
stack backtrace:
#0 0x80b2c2e3 at witness_debugger+0x73
#1 0x80b2c164 at witness_checkorder+0xe34
#2 0x80a9ca21 at lockmgr_lock_fast_path+0x1b1
#3 0x810f8ca9 at VOP_LOCK1_APV+0xd9
#4 0x80ba7746 at _vn_lock+0x66
#5 0x80dc1dac at ffs_sync+0x2cc
#6 0x80b9ce8f at sync_fsync+0xff
#7 0x810f7c19 at VOP_FSYNC_APV+0xd9
#8 0x80b9acc4 at sched_sync+0x284
#9 0x80a88414 at fork_exit+0x84
#10 0x80f56e1e at fork_trampoline+0xe
5 3 2 2 1 1 1 1 1 0 0 0 0 0 done
All buffers synced.
lock order reversal:
 1st 0xf800079c57c8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1280
 2nd 0xf8000795e418 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1371
stack backtrace:
#0 0x80b2c2e3 at witness_debugger+0x73
#1 0x80b2c164 at witness_checkorder+0xe34
#2 0x80a9ca21 at lockmgr_lock_fast_path+0x1b1
#3 0x810f8ca9 at VOP_LOCK1_APV+0xd9
#4 0x80ba7746 at _vn_lock+0x66
#5 0x80dbef63 at ffs_flushfiles+0x93
#6 0x80da24f2 at softdep_flushfiles+0x82
#7 0x80dc15f7 at ffs_unmount+0x77
#8 0x80b8e2c9 at dounmount+0x519
#9 0x80b9800b at vfs_unmountall+0x6b
#10 0x80b73d25 at bufshutdown+0x3a5
#11 0x80ac754a at kern_reboot+0x1da
#12 0x80ac7312 at sys_reboot+0x3c2
#13 0x80f7a37b at amd64_syscall+0x79b
#14 0x80f569c8 at fast_syscall_common+0xfc
Swap device [file] removed.
Uptime: 1m44s
(ada0:ahcich0:0:0:0): spin-down
(ada1:ahcich2:0:0:0): spin-down
(ada2:ahcich3:0:0:0): spin-down
(ada3:ahcich4:0:0:0): spin-down
panic: Unholding 6 with cnt = -559038242
cpuid = 3
time = 1516968697
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe4288c0
vpanic() at vpanic+0x18d/frame 0xfe428920
panic() at panic+0x43/frame 0xfe428980
dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe4289a0
g_disk_providergone() at g_disk_providergone+0x25/frame 0xfe4289d0
g_destroy_provider() at g_destroy_provider+0xae/frame 0xfe4289f0
g_wither_washer() at g_wither_washer+0x87/frame 0xfe428a30
g_run_events() at g_run_events+0x3ca/frame 0xfe428a70
fork_exit() at fork_exit+0x84/frame 0xfe428ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe428ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 13 tid 100044 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> 


As noted, this is a build machine, and it was to be powered off for
the rest of the day anyway, so I don't need to get it up & running
immediately: I can poke at the ddb prompt, given some clues.

When running head, the system does not use ZFS (only UFS2+SU -- not
SUJ -- & tmpfs).

Same system had completed a source-based update for stable/11 from
r328392 to r328429 earlier today without incident (using a different
slice of the boot drive).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"unfortunately, no trust!” -- well, of course!  You 

Re: Panic at shutdown

[Ranjan1018 .]

2015-11-29 0:10 GMT+01:00 Garrett Cooper :

>
> > On Nov 28, 2015, at 12:32, Ranjan1018 . <21474...@gmail.com> wrote:
> >
> > Hi,
> >
> > sometimes I have the panic in the photo at shutdown:
> >
> > http://imgur.com/mXrgFLp
> >
> > Unfortunately this happens randomly.
> >
> > I am running:
> >
> > $ uname -a
> >
> > FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22
> > 17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC  amd64
>
> The panic is in the ZFS code.
>
> Have you run memtest on the machine recently?
>

Good suggestion I have run memtest successfully for few hours on my laptop.

I have understood the panic cause: is an invalid offset.

The original function in
/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c is:

boolean_t
txg_list_member(txg_list_t *tl, void *p, uint64_t txg)
{
int t = txg & TXG_MASK;
txg_node_t *tn = (txg_node_t *)((char *)p + tl->tl_offset);

return (tn->tn_member[t] != 0);
}

I have modified the function to print an uncommon or invalid tl->tl_offset :

boolean_t
txg_list_member(txg_list_t *tl, void *p, uint64_t txg)
{
size_t ofs = tl->tl_offset;
{
static int cnt=0;
if ( (cnt++ % 1000) == 0
|| (ofs != 88 && ofs != 984) )
printf(" %d) tl->tl_offset %zu\n", cnt, ofs);
}

txg_node_t *tn = (txg_node_t *)((char *)p + ofs);

return (tn->tn_member[txg & TXG_MASK] != 0);
}

I have received the panic again with an invalid  tl->tl_offset of
16045693110842147038.
In /val/log/messages I have:

Dec  8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process
`vnlru' to stop...done
Dec  8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process
`bufdaemon' to stop...done
Dec  8 10:32:42 ativ kernel: Waiting (max 60 seconds) for system process
`syncer' to stop...
Dec  8 10:32:42 ativ kernel: Syncing disks, vnodes remaining...0 0 0 done
Dec  8 10:32:42 ativ kernel: All buffers synced.
Dec  8 10:32:42 ativ kernel:  9692) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9693) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9694) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9695) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9708) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9709) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9710) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9711) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9720) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9721) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9722) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel:  9723) tl->tl_offset 384
Dec  8 10:32:42 ativ kernel: Uptime: 1h57m42s
Dec  8 10:32:42 ativ kernel:  9736) tl->tl_offset 16045693110842147038
Dec  8 10:32:42 ativ kernel:
Dec  8 10:32:42 ativ kernel:
Dec  8 10:32:42 ativ kernel: Fatal trap 9: general protection fault while
in kernel mode
Dec  8 10:32:42 ativ kernel: cpuid = 2; apic id = 02
Dec  8 10:32:42 ativ kernel: instruction pointer=
0x20:0x8211b1cb
Dec  8 10:32:42 ativ kernel: stack pointer=
0x28:0xfe0119525990
Dec  8 10:32:42 ativ kernel: frame pointer=
0x28:0xfe01195259c0
Dec  8 10:32:42 ativ kernel: code segment= base 0x0, limit 0xf,
type 0x1b
Dec  8 10:32:42 ativ kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
Dec  8 10:32:42 ativ kernel: processor eflags= interrupt enabled,
resume, IOPL = 0
Dec  8 10:32:42 ativ kernel: current process= 0 (dbu_evict)

Probably the panic is caused by some memory already freed, the hex  value
of 16045693110842147038 is 0xdeadc0dedeadc0de.
To solve the panic I need some tips form someone more expert than me in ZFS
code.

Thanks.

-- Maurizio
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic at shutdown

[NGie Cooper]

> On Dec 8, 2015, at 08:09, Ranjan1018 . <21474...@gmail.com> wrote:

…

> Probably the panic is caused by some memory already freed, the hex  value of 
> 16045693110842147038 is 0xdeadc0dedeadc0de.
> To solve the panic I need some tips form someone more expert than me in ZFS 
> code.

Good investigative work! There was something reported recently about unaligned 
accesses when dealing with msdosfs+zfs+etc, but it was an odd edgecase.

Definitely file a bug and assign it to freebsd-fs@ with the findings you have 
made here.

Thanks :)!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic at shutdown

[Ranjan1018 .]

Hi,

sometimes I have the panic in the photo at shutdown:

http://imgur.com/mXrgFLp

Unfortunately this happens randomly.

I am running:

$ uname -a

FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22
17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC  amd64

Regards,

Maurizio
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic at shutdown

[Garrett Cooper]

> On Nov 28, 2015, at 12:32, Ranjan1018 . <21474...@gmail.com> wrote:
> 
> Hi,
> 
> sometimes I have the panic in the photo at shutdown:
> 
> http://imgur.com/mXrgFLp
> 
> Unfortunately this happens randomly.
> 
> I am running:
> 
> $ uname -a
> 
> FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22
> 17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC  amd64

The panic is in the ZFS code.

Have you run memtest on the machine recently?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on shutdown, r243674M

[Andriy Gapon]

on 30/11/2012 00:36 Ed Maste said the following:
 Rev 243674 with some minor local changes.

Please try this patch:
http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff

I should have committed this earlier, but the fact that we were not getting much
problems when updating resources in place lead me to believe that we would not
get more problems when first deleting and then re-creating resources.

If the patch works OK, I'll commit it tomorrow.

 #12 0x80bfd775 in trap_fatal (frame=0xff800025e870,
 eva=value optimized out)
 at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:867
 #13 0x80bfda3a in trap_pfault (frame=0x0, usermode=0)
 at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:698
 #14 0x80bfd226 in trap (frame=0xff800025e870)
 at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:463
 #15 0x80be71a2 in calltrap () at /tmp/exception-N6d6io.s:179
 #16 0x808bb9c0 in rman_set_bustag ()
 at /home/emaste/src/head-ro/sys/kern/subr_rman.c:941
 #17 0x80356c9d in acpi_cpu_idle ()
 at /home/emaste/src/head-ro/sys/dev/acpica/acpi_cpu.c:1020
 #18 0x80beb268 in cpu_idle_acpi (busy=0)
 at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:685
 #19 0x80beb308 in cpu_idle (busy=0)
 at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:839
 #20 0x808a6058 in sched_idletd (dummy=value optimized out)
 at /home/emaste/src/head-ro/sys/kern/sched_ule.c:2665
 #21 0x808524d4 in fork_exit (
 callout=0x808a5e20 sched_idletd, arg=0x0,
 frame=0xff800025eac0)
 at /home/emaste/src/head-ro/sys/kern/kern_fork.c:995
 #22 0x80be76de in fork_trampoline () at /tmp/exception-N6d6io.s:501
 #23 0x in ?? ()



-- 
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 on shutdown, r243674M

[Ed Maste]

 Please try this patch:
 http://people.freebsd.org/~avg/acpi_cpu_notify.2.diff

 I should have committed this earlier, but the fact that we were not getting 
 much
 problems when updating resources in place lead me to believe that we would not
 get more problems when first deleting and then re-creating resources.

 If the patch works OK, I'll commit it tomorrow.

It works fine for me (of course I can't say with certainty that I've
exercised the path that previously panicked).  Please go ahead and
commit.
___
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

Panic on shutdown, r243674M

[Ed Maste]

Rev 243674 with some minor local changes.

#12 0x80bfd775 in trap_fatal (frame=0xff800025e870,
eva=value optimized out)
at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:867
#13 0x80bfda3a in trap_pfault (frame=0x0, usermode=0)
at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:698
#14 0x80bfd226 in trap (frame=0xff800025e870)
at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:463
#15 0x80be71a2 in calltrap () at /tmp/exception-N6d6io.s:179
#16 0x808bb9c0 in rman_set_bustag ()
at /home/emaste/src/head-ro/sys/kern/subr_rman.c:941
#17 0x80356c9d in acpi_cpu_idle ()
at /home/emaste/src/head-ro/sys/dev/acpica/acpi_cpu.c:1020
#18 0x80beb268 in cpu_idle_acpi (busy=0)
at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:685
#19 0x80beb308 in cpu_idle (busy=0)
at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:839
#20 0x808a6058 in sched_idletd (dummy=value optimized out)
at /home/emaste/src/head-ro/sys/kern/sched_ule.c:2665
#21 0x808524d4 in fork_exit (
callout=0x808a5e20 sched_idletd, arg=0x0,
frame=0xff800025eac0)
at /home/emaste/src/head-ro/sys/kern/kern_fork.c:995
#22 0x80be76de in fork_trampoline () at /tmp/exception-N6d6io.s:501
#23 0x 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 on shutdown, r243674M

[Ed Maste]

On 29 November 2012 17:36, Ed Maste ema...@freebsd.org wrote:

 #14 0x80bfd226 in trap (frame=0xff800025e870)
 at /home/emaste/src/head-ro/sys/amd64/amd64/trap.c:463
 #15 0x80be71a2 in calltrap () at /tmp/exception-N6d6io.s:179
 #16 0x808bb9c0 in rman_set_bustag ()
 at /home/emaste/src/head-ro/sys/kern/subr_rman.c:941
 #17 0x80356c9d in acpi_cpu_idle ()
 at /home/emaste/src/head-ro/sys/dev/acpica/acpi_cpu.c:1020
 #18 0x80beb268 in cpu_idle_acpi (busy=0)
 at /home/emaste/src/head-ro/sys/amd64/amd64/machdep.c:685

FWIW I had a second instance of this panic.  Previous kernel is from
Nov. 14 (prior to the import of ACPICA 20121114) and it has been
stable.
___
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: video drivers are locked up; panic during shutdown

[John Baldwin]

On Saturday, May 19, 2012 7:41:37 pm deeptec...@gmail.com wrote:
 A perhaps more useful crashinfo output, gathered with the use of the 
original (non-debug) kernel.
 

It seems like the mutex was zero'd which can result in this panic when it 
tries to adaptively spin (it sees a thread owner of NULL).

-- 
John Baldwin
___
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

video drivers are locked up; panic during shutdown

[deeptech71]

So while the unstable, reverse-engineered ATI drivers were locked up (which is 
usual, it happens ~5 times a day on average), I pressed the ATX power button to 
initiate a clean shutdown (statistically, this usually succeeds). During the 
shutdown procedure, a panic occurred. (As a result, the filesystem wasn't 
cleanly unmounted.)

I was doing a ``git pull --rebase'' (which turned out to have succeeded) when 
the driver lockup occurred.

The crashinfo output is attached. Note: the kernel used during the panic has no 
debugging symbols; a version compiled with debugging symbols was used for 
crashinfo.
 dumped core - see /var/crash/vmcore.0

Sat May 19 18:36:13 CEST 2012

FreeBSD  10.0-CURRENT FreeBSD 10.0-CURRENT #1 r235500M: Sat May 19 17:53:32 
CEST 2012 root@:/usr/obj/usr/src/sys/HQ  i386

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Cannot access memory at address 0x0
(kgdb) #0  0x in ?? ()
(kgdb) 


ps -axl

UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT  TIME COMMAND


vmstat -s

0 cpu context switches
3230491304 device interrupts
0 software interrupts
3230491296 traps
0 system calls
3230491472 kernel threads created
0  fork() calls
3230491464 vfork() calls
0 rfork() calls
0 swap pager pageins
0 swap pager pages paged in
3230491336 swap pager pageouts
3230491344 swap pager pages paged out
0 vnode pager pageins
0 vnode pager pages paged in
3230491352 vnode pager pageouts
3230491360 vnode pager pages paged out
0 page daemon wakeups
3230491376 pages examined by the page daemon
3230491368 pages reactivated
0 copy-on-write faults
3230491320 copy-on-write optimized faults
0 zero fill pages zeroed
3230491328 zero fill pages prezeroed
0 intransit blocking page faults
3230491312 total VM faults taken
3230491488 pages affected by kernel thread creation
0 pages affected by  fork()
3230491480 pages affected by vfork()
0 pages affected by rfork()
0 pages cached
3230491392 pages freed
3230491384 pages freed by daemon
0 pages freed by exiting processes
3230491424 pages active
3230491432 pages inactive
0 pages in VM cache
0 pages wired down
3230491416 pages free
0 bytes per page
-2108415131 total name lookups
  cache hits (0% pos + 0% neg) system 0% per-directory
  deletions 0%, falsehits 50%, toolong -1%


vmstat -m

vmstat: memstat_kvm_malloc: invalid address (0x7cd6d6c6)
 Type InUse MemUse HighUse Requests  Size(s)


vmstat -z

ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP




vmstat -i

vmstat: malloc(): Cannot allocate memory


pstat -T

 19/  0 files
0M/0M swap space


pstat -s

Device  1K-blocks UsedAvail Capacity


iostat

iostat: devstat_checkversion: userland devstat version 6 is not the same as the 
kernel
devstat_checkversion: devstat version -1065155924
devstat_checkversion: libdevstat newer than kernel



ipcs -a

ipcs: shmsegs: invalid address (0x0)
Message Queues:
T   ID  KEY MODEOWNERGROUPCREATOR  CGROUP   
  CBYTES QNUM   QBYTESLSPID
LRPID STIMERTIMECTIME   



ipcs -T

msginfo:
msgmax:0(max characters in a message)
msgmni:0(# of message queues)
msgmnb:  1312130(max characters in a message queue)
msgtql:   -65536(max # of messages in system)
msgssz:   60(size of a message segment)
msgseg:0(# of message segments in system)

shminfo:
shmmax: 25165824(max shared memory segment size)
shmmin:268435455(min shared memory segment size)
shmmni:   3227543568(max number of shared memory identifiers)
shmseg:   3230161136(max shared memory

panic during shutdown from vfs_umountall()

[Robert Watson]

Running with a MAC kernel, about to try booting identical but non-MAC; I'm
not able to reproduceit , however.  bgfsck may have been running during
the shutdown.  Apparently the device vnode for /usr is vrele()'d one too
many times at some point during the run, resulting in a panic.  This is
with vfs_mount.c:1.116. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Senior Research Scientist, McAfee Research

Script started on Mon Dec  1 12:23:10 2003
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: vrele: negative ref cnt
panic messages:
---
panic: vrele: negative ref cnt
cpuid = 0; 
panic: from debugger
cpuid = 0; 
Uptime: 23h36m45s
Dumping 511 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496
---
Reading symbols from /boot/kernel/snd_maestro3.ko...done.
Loaded symbols for /boot/kernel/snd_maestro3.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/mac_biba/mac_biba.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/mac_biba/mac_biba.ko.debug
Reading symbols from 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/mac_mls/mac_mls.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/mac_mls/mac_mls.ko.debug
Reading symbols from /boot/kernel/r128.ko...done.
Loaded symbols for /boot/kernel/r128.ko
Reading symbols from 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/PAPRIKAMAC/modules/usr/src/sys/modules/linux/linux.ko.debug
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc06719f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc0671dfd in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc048cc82 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4  0xc048cbe2 in db_command (last_cmdp=0xc094efc0, cmd_table=0x0, 
aux_cmd_tablep=0xc08d09cc, aux_cmd_tablep_end=0xc08d09e4)
at /usr/src/sys/ddb/db_command.c:346
#5  0xc048cd25 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6  0xc048fd25 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7  0xc082861c in kdb_trap (type=3, code=0, regs=0xd77c6b48)
at /usr/src/sys/i386/i386/db_interface.c:171
#8  0xc083e688 in trap (frame=
  {tf_fs = 24, tf_es = -1064697840, tf_ds = 16, tf_edi = -1064617494, tf_esi = 1, 
tf_ebp = -679711852, tf_isp = -679711884, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, tf_eax 
= 18, tf_trapno = 3, tf_err = 0, tf_eip = -1065187035, tf_cs = 8, tf_eflags = 642, 
tf_esp = -1064532435, tf_ss = -1064643348})
at /usr/src/sys/i386/i386/trap.c:580
#9  0xc082a068 in calltrap () at {standard input}:94
#10 0xc0671d96 in panic (fmt=0xc08b39ea vrele: negative ref cnt)
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc06cb44e in vrele () at /usr/src/sys/kern/vfs_subr.c:2221
#12 0xc07d4b18 in ffs_unmount (mp=0xc481c800, mntflags=524288, td=0xc1d29500)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:999
#13 0xc06c68f4 in dounmount (mp=0xc481c800, flags=524288, td=0xc1d29500)
at /usr/src/sys/kern/vfs_mount.c:1126
#14 0xc06cce3e in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:3176
#15 0xc06718c3 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:357
#16 0xc06711d4 in reboot (td=0xc1d29500, uap=0xd77c6d14)
at /usr/src/sys/kern/kern_shutdown.c:178
#17 0xc083f050 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940488, tf_esi = -1077940488, 
tf_ebp = -1077940744, tf_isp = -679711372, tf_ebx = -1077940584, tf_edx = -1, tf_ecx = 
4, tf_eax = 55, tf_trapno = 12, tf_err = 2, tf_eip = 134547627, tf_cs = 31, tf_ef
lags = 515, tf_esp = -1077940948, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#18 0xc082a0bd in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---

(kgdb) up
#1  0xc06719f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
372 doadump();
(kgdb) up
#2  0xc0671dfd in panic () at /usr/src/sys/kern/kern_shutdown.c:550
550 boot(bootopt);
(kgdb) up
#3  0xc048cc82 in 

panic during shutdown in lockmgr()

[Thorsten Greiner]

Hi,

with a -CURRENT kernel built today I am consistently getting a panic
during shutdown. Unfortunately a debug kernel refuses to do a core
dump, so I only have a naked stack trace:

panic: lockmgr: thread 0xc1918720, not exclusive lock holder 0xc06b5660 unlocking
#0  0xc04fc40a in doadump ()
#1  0xc04fcaac in boot ()
#2  0xc04fce03 in poweroff_wait ()
#3  0xc04eff3c in lockmgr ()
#4  0xc054b2b2 in vop_stdunlock ()
#5  0xc054b15a in vop_defaultop ()
#6  0xc05e2f73 in ufs_vnoperate ()
#7  0xc0555cd8 in vput ()
#8  0xc05d3a86 in ffs_sync ()
#9  0xc0558a5d in sync ()
#10 0xc04fc5a4 in boot ()
#11 0xc04fc1bf in reboot ()
#12 0xc0632372 in syscall ()
#13 0xc0622fdd in Xint0x80_syscall ()

This panic occurs when I shut the machine down with all filesystems
mounted. I can avoid it when I go to single user mode and umount all
filesystems first.

Please let me know if I can provide further information.

Regards
-Thorsten

-- 
The moon may be smaller than Earth, but it's further away.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

lockmgr panic on shutdown

[Doug White]

I can confirm the lockmgr panic on shutdown reported by someone else
earlier (whose message I mistakenly deleted).

It looks like swapper is trying to undo a lock from pagedaemon and runs
into trouble. This is probably related to the Giant pushdown of
vm_pageout() that alc did last week.

I'm building with INVARIANTS to see if that will catch more info.  Will
report back soon.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: lockmgr panic on shutdown

[Doug White]

More info.

I think this is actually related to kan's reversion of
src/sys/kern/vfs_default.c.  I'm trying rev 1.88 of that file.

In the meantime, here is the panic message and backtrace. I have a
crashdump if desired.

panic: lockmgr: thread 0xc493be40, not exclusive lock holder 0xc071f320 unlocking

#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc0510884 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc0510be7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc05043ea in lockmgr (lkp=0xc49af428, flags=6, interlkp=0x140,
td=0xc493be40) at /usr/src/sys/kern/kern_lock.c:414
#4  0xc055e91f in vop_stdunlock (ap=0x0) at /usr/src/sys/kern/vfs_default.c:299
#5  0xc055e768 in vop_defaultop (ap=0x0) at /usr/src/sys/kern/vfs_default.c:161
#6  0xc061ed88 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2793
#7  0xc06173d0 in ufs_inactive (ap=0x0) at vnode_if.h:1044
#8  0xc061ed88 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2793
#9  0xc05686d7 in vput (vp=0xc49af36c) at vnode_if.h:953
#10 0xc0610245 in ffs_sync (mp=0xc47b2800, waitfor=2, cred=0xc1d07e80,
td=0xc071f320) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1169
#11 0xc056ade4 in sync (td=0xc071f320, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:142
#12 0xc05103e0 in boot (howto=8) at /usr/src/sys/kern/kern_shutdown.c:281
#13 0xc0510046 in reboot (td=0x0, uap=0x0)
at /usr/src/sys/kern/kern_shutdown.c:178
#14 0xc066cf32 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 0, tf_ebp = 
-1077937104, tf_isp = -574005900, tf_ebx = 2, tf_edx = -1, tf_ecx = 3, tf_eax = 55, 
tf_trapno = 12, tf_err = 2, tf_eip = 134516011, tf_cs = 31, tf_eflags = 582, tf_esp = 
-1077937172, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1012
#15 0xc065d91d in Xint0x80_syscall () at {standard input}:144


On Sat, 1 Nov 2003, Doug White wrote:

 I can confirm the lockmgr panic on shutdown reported by someone else
 earlier (whose message I mistakenly deleted).

 It looks like swapper is trying to undo a lock from pagedaemon and runs
 into trouble. This is probably related to the Giant pushdown of
 vm_pageout() that alc did last week.

 I'm building with INVARIANTS to see if that will catch more info.  Will
 report back soon.



-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: lockmgr panic on shutdown

[peter . edwards]

I can confirm the lockmgr panic on shutdown reported by someone else
earlier (whose message I mistakenly deleted).

It looks like swapper is trying to undo a lock from pagedaemon and runs
into trouble. This is probably related to the Giant pushdown of
vm_pageout() that alc did last week.

I'm building with INVARIANTS to see if that will catch more info.  Will
report back soon.

Just happened me too. I think I see the problem:

When boot() calls sync(), it passes thread0 as the thread argument.
This gets propgated up to ffs_sync, which:

  calls vget(), which takes a thread argument.
  does some stuff
  calls vput(), which does _not_ take a thread argument

The vget() is passed thread0, as passed from boot.
The vput() gets the current thread, which is the process calling boot.

The unlocking in vput is asserting that the same thread that aquired
the lock is releasing it, which seems reasonable.

The obvious solution might be to change line 1161 of ffs_vfsops to
pass vget() curthread rather than td. I assume there's a good
reason why thread0 is passed from boot(), but I can't see why
that's of any use to the vnode locking.

i.e.:
Index: ffs_vfsops.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.221
diff -u -r1.221 ffs_vfsops.c
--- ffs_vfsops.c1 Nov 2003 05:51:54 -   1.221
+++ ffs_vfsops.c2 Nov 2003 03:06:42 -
@@ -1158,7 +1158,7 @@
continue;
}
mtx_unlock(mntvnode_mtx);
-   if ((error = vget(vp, lockreq, td)) != 0) {
+   if ((error = vget(vp, lockreq, curthread)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;


How come tha parameters to vget and vput are lopsided like this?

This might have something to do with the commit
of revision 1.218 of ffs_vfsops.c, but I'm not sure.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: lockmgr panic on shutdown

[Doug White]

For giggles I'm rolling back vfs_default.c back to 1.87 since its along
the backtrace path.

I suspect I'll need to back up the whole thing to before the commit for
the struct mount locking until jeff  kan can straighten things out.

On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote:



 I can confirm the lockmgr panic on shutdown reported by someone else
 earlier (whose message I mistakenly deleted).
 
 It looks like swapper is trying to undo a lock from pagedaemon and runs
 into trouble. This is probably related to the Giant pushdown of
 vm_pageout() that alc did last week.
 
 I'm building with INVARIANTS to see if that will catch more info.  Will
 report back soon.

 Just happened me too. I think I see the problem:

 When boot() calls sync(), it passes thread0 as the thread argument.
 This gets propgated up to ffs_sync, which:

   calls vget(), which takes a thread argument.
   does some stuff
   calls vput(), which does _not_ take a thread argument

 The vget() is passed thread0, as passed from boot.
 The vput() gets the current thread, which is the process calling boot.

 The unlocking in vput is asserting that the same thread that aquired
 the lock is releasing it, which seems reasonable.

 The obvious solution might be to change line 1161 of ffs_vfsops to
 pass vget() curthread rather than td. I assume there's a good
 reason why thread0 is passed from boot(), but I can't see why
 that's of any use to the vnode locking.

 i.e.:
 Index: ffs_vfsops.c
 ===
 RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
 retrieving revision 1.221
 diff -u -r1.221 ffs_vfsops.c
 --- ffs_vfsops.c1 Nov 2003 05:51:54 -   1.221
 +++ ffs_vfsops.c2 Nov 2003 03:06:42 -
 @@ -1158,7 +1158,7 @@
 continue;
 }
 mtx_unlock(mntvnode_mtx);
 -   if ((error = vget(vp, lockreq, td)) != 0) {
 +   if ((error = vget(vp, lockreq, curthread)) != 0) {
 mtx_lock(mntvnode_mtx);
 if (error == ENOENT)
 goto loop;


 How come tha parameters to vget and vput are lopsided like this?

 This might have something to do with the commit
 of revision 1.218 of ffs_vfsops.c, but I'm not sure.



-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: lockmgr panic on shutdown

[Doug White]

On Sat, 1 Nov 2003, Doug White wrote:

 For giggles I'm rolling back vfs_default.c back to 1.87 since its along
 the backtrace path.

This didn't work so -CURRENT is fully broke.

I'd suggest staying on 10/30 not before 4PM PST if you want to not crash
on shutdown.


 I suspect I'll need to back up the whole thing to before the commit for
 the struct mount locking until jeff  kan can straighten things out.

 On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote:

 
 
  I can confirm the lockmgr panic on shutdown reported by someone else
  earlier (whose message I mistakenly deleted).
  
  It looks like swapper is trying to undo a lock from pagedaemon and runs
  into trouble. This is probably related to the Giant pushdown of
  vm_pageout() that alc did last week.
  
  I'm building with INVARIANTS to see if that will catch more info.  Will
  report back soon.
 
  Just happened me too. I think I see the problem:
 
  When boot() calls sync(), it passes thread0 as the thread argument.
  This gets propgated up to ffs_sync, which:
 
calls vget(), which takes a thread argument.
does some stuff
calls vput(), which does _not_ take a thread argument
 
  The vget() is passed thread0, as passed from boot.
  The vput() gets the current thread, which is the process calling boot.
 
  The unlocking in vput is asserting that the same thread that aquired
  the lock is releasing it, which seems reasonable.
 
  The obvious solution might be to change line 1161 of ffs_vfsops to
  pass vget() curthread rather than td. I assume there's a good
  reason why thread0 is passed from boot(), but I can't see why
  that's of any use to the vnode locking.
 
  i.e.:
  Index: ffs_vfsops.c
  ===
  RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
  retrieving revision 1.221
  diff -u -r1.221 ffs_vfsops.c
  --- ffs_vfsops.c1 Nov 2003 05:51:54 -   1.221
  +++ ffs_vfsops.c2 Nov 2003 03:06:42 -
  @@ -1158,7 +1158,7 @@
  continue;
  }
  mtx_unlock(mntvnode_mtx);
  -   if ((error = vget(vp, lockreq, td)) != 0) {
  +   if ((error = vget(vp, lockreq, curthread)) != 0) {
  mtx_lock(mntvnode_mtx);
  if (error == ENOENT)
  goto loop;
 
 
  How come tha parameters to vget and vput are lopsided like this?
 
  This might have something to do with the commit
  of revision 1.218 of ffs_vfsops.c, but I'm not sure.
 
 



-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: lockmgr panic on shutdown

[peter . edwards]

 For giggles I'm rolling back vfs_default.c back to 1.87 since its along
 the backtrace path.

This didn't work so -CURRENT is fully broke.

I'd suggest staying on 10/30 not before 4PM PST if you want to not crash
on shutdown.


The patch worked for me. (Well, a slightly modified one: I passed 0 for
the
thread argument to vget: It recognises that as special).

Included here is the patch to both the ffs and default sync operations.
I didn't exercise the default one, but the ffs case is certainly behaving
itself.




Index: kern/vfs_default.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/kern/vfs_default.c,v
retrieving revision 1.89
diff -u -r1.89 vfs_default.c
--- kern/vfs_default.c  1 Nov 2003 05:51:54 -   1.89
+++ kern/vfs_default.c  2 Nov 2003 03:36:03 -
@@ -898,7 +898,7 @@
}
mtx_unlock(mntvnode_mtx);
 
-   if ((error = vget(vp, lockreq, td)) != 0) {
+   if ((error = vget(vp, lockreq, 0)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;
Index: ufs/ffs/ffs_vfsops.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.221
diff -u -r1.221 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c1 Nov 2003 05:51:54 -   1.221
+++ ufs/ffs/ffs_vfsops.c2 Nov 2003 03:22:13 -
@@ -1158,7 +1158,7 @@
continue;
}
mtx_unlock(mntvnode_mtx);
-   if ((error = vget(vp, lockreq, td)) != 0) {
+   if ((error = vget(vp, lockreq, 0)) != 0) {
mtx_lock(mntvnode_mtx);
if (error == ENOENT)
goto loop;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: lockmgr panic on shutdown

[Doug White]

On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote:

  For giggles I'm rolling back vfs_default.c back to 1.87 since its along
  the backtrace path.
 
 This didn't work so -CURRENT is fully broke.
 
 I'd suggest staying on 10/30 not before 4PM PST if you want to not crash
 on shutdown.
 

 The patch worked for me. (Well, a slightly modified one: I passed 0 for
 the thread argument to vget: It recognises that as special).

kan came up with a different patch that changes the vput in
ffs_vfsops:ffs_sync with a vrele.  That should be committed shortly. Since
he's been working in that area I'll defer to him :)


 Included here is the patch to both the ffs and default sync operations.
 I didn't exercise the default one, but the ffs case is certainly behaving
 itself.






-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: lockmgr panic on shutdown

[Bruce Evans]

On Sun, 2 Nov 2003 [EMAIL PROTECTED] wrote:

 The obvious solution might be to change line 1161 of ffs_vfsops to
 pass vget() curthread rather than td. I assume there's a good
 reason why thread0 is passed from boot(), but I can't see why
 that's of any use to the vnode locking.

Passing thread0 in boot() is a quick (and not even wrong) fix for
the problem that there is no valid current process^Wthread in the
panic case.  Long ago in Net/2 (still in Lite2 for at least the
i386 version), sync() in boot() was passed the completely bogus
parameters ((struct sigcontext *)0) (instead of (p, uap, retval).
This worked to the extent that sync()'s proc pointer was not passed
further or not dereferenced.  Now there are lots of locks, and since
thread0 is never the corerect lock holder, things work at most to
the extent that sync()'s proc pointer is not passed further.
curthread is never null in -current, so upgrading to the version that
passes it (i386/i386/machdep.c 1.111 (actually passes curproc)) would
probably help in the non-panic case without increasing bugs for the
panic case.  However, passing curthread is still wrong for the panic
case due to the following complications:
- panics may occur during context switches or in other critical regions
  when curthread is not quite current.
- under SMP, curthread is per-CPU, so having it non-null doesn't really
  help.  Locks may be held by curproc's running on other CPUs, and in
  panic() it is difficult to handle the other CPUs correctly -- if you
  stop them then they won't be able to release their locks, and if you
  let them run they may run into you.  Hopefully in the case of a
  normal shutdown all the other CPUs release their locks and stop before
  the sync().

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

panic on shutdown

[Florian C. Smeets]

Hey Guys,

i got this panic on doing shutdown -r now.

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address   = 0xdeadc0de
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0521678
stack pointer   = 0x10:0xcdccd810
frame pointer   = 0x10:0xcdccd810
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 15 (swi1: net)
kernel: type 12 trap, code=0
Stopped at  strlen+0x8: cmpb$0,0(%edx)
db t
strlen(deadc0de,cdccd8f4,c06e25a8,cdccd848,c04e0993) at strlen+0x8
kvprintf(c067d4f4,c04d9ca0,cdccd8f4,a,cdccd944) at kvprintf+0x5b2
vsnprintf(c06df060,100,c067d4f4,cdccd940,100) at vsnprintf+0x3e
panic(c067d4f4,deadc0de,c0687d51,66e,cdccd958) at panic+0xc9
_mtx_lock_flags(c2e93490,0,c0687d51,66e,c16e7d00) at _mtx_lock_flags+0x66
ip_rtaddr(57b52cd9,cdccdc38,1,14,c16e7d00) at ip_rtaddr+0x5e
ip_forward(c16e7d00,cdccdc38,0,0,c06e10a0) at ip_forward+0xb5
ip_input(c16e7d00,0,c06869f8,89,0) at ip_input+0x756
netisr_processqueue(c0706a70,0,c06869f8,e5,c169c5c0) at 
netisr_processqueue+0x8e

swi_net(0,0,c067bc0d,21b,c16a53c8) at swi_net+0x98
ithread_loop(c16a3c00,cdccdd48,c067ba6f,314,0) at ithread_loop+0x192
fork_exit(c04a5280,c16a3c00,cdccdd48) at fork_exit+0xcf
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcdccdd7c, ebp = 0 ---
Don't know if it's useful or not.

Regards,
flo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: panic on shutdown

[Florian C. Smeets]

I should have added that this is a kernel todays sources on an smp system.

FreeBSD bender 5.1-CURRENT FreeBSD 5.1-CURRENT #73: Sat Oct 25 
20:30:56 CEST 2003 [EMAIL PROTECTED]:/space/obj/space/src/sys/BENDER  i386

Florian C. Smeets wrote:
Hey Guys,

i got this panic on doing shutdown -r now.

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address   = 0xdeadc0de
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0521678
stack pointer   = 0x10:0xcdccd810
frame pointer   = 0x10:0xcdccd810
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 15 (swi1: net)
kernel: type 12 trap, code=0
Stopped at  strlen+0x8: cmpb$0,0(%edx)
db t
strlen(deadc0de,cdccd8f4,c06e25a8,cdccd848,c04e0993) at strlen+0x8
kvprintf(c067d4f4,c04d9ca0,cdccd8f4,a,cdccd944) at kvprintf+0x5b2
vsnprintf(c06df060,100,c067d4f4,cdccd940,100) at vsnprintf+0x3e
panic(c067d4f4,deadc0de,c0687d51,66e,cdccd958) at panic+0xc9
_mtx_lock_flags(c2e93490,0,c0687d51,66e,c16e7d00) at _mtx_lock_flags+0x66
ip_rtaddr(57b52cd9,cdccdc38,1,14,c16e7d00) at ip_rtaddr+0x5e
ip_forward(c16e7d00,cdccdc38,0,0,c06e10a0) at ip_forward+0xb5
ip_input(c16e7d00,0,c06869f8,89,0) at ip_input+0x756
netisr_processqueue(c0706a70,0,c06869f8,e5,c169c5c0) at 
netisr_processqueue+0x8e

swi_net(0,0,c067bc0d,21b,c16a53c8) at swi_net+0x98
ithread_loop(c16a3c00,cdccdd48,c067ba6f,314,0) at ithread_loop+0x192
fork_exit(c04a5280,c16a3c00,cdccdd48) at fork_exit+0xcf
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcdccdd7c, ebp = 0 ---
Don't know if it's useful or not.

Regards,
flo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Kernel panic on shutdown of X server.

[walt]

This problem started about Feb 19 and continues thru today's updates.

Everything seems to work great until I shut down the X server
at which time I get a fatal 'page fault while in kernel mode.'
I have two -CURRENT machines at the moment and only the one
with the nVidia driver (and kernel module) has the page fault
problem.  I know the nVidia people don't support the driver
for -CURRENT but it has been working perfectly until now, so
something important in the kernel changed about four days ago,
apparently.
Anyone else seeing this?



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Kernel panic on shutdown of X server.

[Terry Lambert]

walt wrote:
 This problem started about Feb 19 and continues thru today's updates.
 
 Everything seems to work great until I shut down the X server
 at which time I get a fatal 'page fault while in kernel mode.'
 
 I have two -CURRENT machines at the moment and only the one
 with the nVidia driver (and kernel module) has the page fault
 problem.  I know the nVidia people don't support the driver
 for -CURRENT but it has been working perfectly until now, so
 something important in the kernel changed about four days ago,
 apparently.
 
 Anyone else seeing this?

Which scheduler are you using?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Kernel panic on shutdown of X server.

[walt]

Terry Lambert wrote:
walt wrote:

This problem started about Feb 19 and continues thru today's updates.

Everything seems to work great until I shut down the X server
at which time I get a fatal 'page fault while in kernel mode.'
I have two -CURRENT machines at the moment and only the one
with the nVidia driver (and kernel module) has the page fault
problem.  I know the nVidia people don't support the driver
for -CURRENT but it has been working perfectly until now, so
something important in the kernel changed about four days ago,
apparently.
Anyone else seeing this?


Which scheduler are you using?
I have options SCHED_4BSD in my config file.  I'll try the
other one and see if it changes.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Kernel panic on shutdown of X server.

[Maxim Konovalov]

On 11:50-0800, Feb 23, 2003, walt wrote:

 This problem started about Feb 19 and continues thru today's updates.

 Everything seems to work great until I shut down the X server
 at which time I get a fatal 'page fault while in kernel mode.'

 I have two -CURRENT machines at the moment and only the one
 with the nVidia driver (and kernel module) has the page fault
 problem.  I know the nVidia people don't support the driver
 for -CURRENT but it has been working perfectly until now, so
 something important in the kernel changed about four days ago,
 apparently.

 Anyone else seeing this?

Yes.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+archive/2003/cvs-all/20030223.cvs-all

-- 
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic at shutdown, ums related?

[Josef Karthauser]

On Wed, Apr 24, 2002 at 04:53:32PM -0700, Peter Wemm wrote:
 
 USB is pretty hosed. :-(
 
 For a while, removing the mouse didn't get detected and you had to kill moused
 manually.  Then the removal event happened.  A new moused would start but it
 was impossible to kill -9 the old moused.  If you remove the mouse again, it
 instantly panics the box.  I've not seen what is happening as I've always been
 in X at the time. :-/
 

Is that still happening?  I've got a usoft usb mouse here, and it works
fine for me, pluggin or unplugging - no problems.  There do however
appear to be hub problems - if a hub gets unplugged the usb bus code
loops and doesn't register that it's gone.  I'm using uhci though, are
you, or are you using ohci?

Joe



msg37773/pgp0.pgp
Description: PGP signature

Re: panic at shutdown, ums related?

[Alexander Leidinger]

On 24 Apr, Terry Lambert wrote:

 USB is pretty hosed. :-(
 
 For a while, removing the mouse didn't get detected and you had to kill moused
 manually.  Then the removal event happened.  A new moused would start but it
 was impossible to kill -9 the old moused.  If you remove the mouse again, it
 instantly panics the box.  I've not seen what is happening as I've always been
 in X at the time. :-/

I don't have the need to remove the mouse.

 USB hates Mieces to pieces.  I've taken to using NetGear based KVM
 switches, which is not really an option if the problem is with a
 laptop and/or docking port (sorry), but might be an OK way to deal
 with peripheral sharing on a desktop, until USB gets fixed.

There's a fix for ums, joe want's to talk with the NetBSD developers
first.

I use this fix. The panic I see now is _new_, it's not the one I see if
I don't use the fix.

Bye,
Alexander.

-- 
It is easier to fix Unix than to live with NT.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

panic at shutdown, ums related?

[Alexander Leidinger]

Hi,

backtrace from the console, no core dump:
panic: Removing other than first element

usb_transfer_complete
uhci_device_intr_abort
usbd_ar_pipe
usbd_abort_pipe
ums_disable
ums_close
spec_close
...

It seems I may get it at every shutdown, so if there's something I
should look at...

Bye,
Alexander.

-- 
 The three Rs of Microsoft support: Retry, Reboot, Reinstall.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic at shutdown, ums related?

[Terry Lambert]

Peter Wemm wrote:
 USB is pretty hosed. :-(
 
 For a while, removing the mouse didn't get detected and you had to kill moused
 manually.  Then the removal event happened.  A new moused would start but it
 was impossible to kill -9 the old moused.  If you remove the mouse again, it
 instantly panics the box.  I've not seen what is happening as I've always been
 in X at the time. :-/

USB hates Mieces to pieces.  I've taken to using NetGear based KVM
switches, which is not really an option if the problem is with a
laptop and/or docking port (sorry), but might be an OK way to deal
with peripheral sharing on a desktop, until USB gets fixed.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic at shutdown

[Bill Fenner]

2. cvsup to r1.96 of tty_cons.c, which should fix this, but due to lack
   of testers and the inability to reproduce it here, is unverified.

I've been testing it, and haven't had any panics, but since the panic
was irregular anyway it's hard to say that it's fixed.

  Bill

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic at shutdown

[Jonathan Lemon]

In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
For about a week, I've been getting panics at shutdown, caused by
cn_devopen() calling devsw() with a NULL dev argument.  I imagine it
may be related to recent changes in the console code.  If it's of any
interest, I have -Dh in my /boot.config.

1. A week?  Why, in that time, didn't you let me know of the problem?
2. cvsup to r1.96 of tty_cons.c, which should fix this, but due to lack
   of testers and the inability to reproduce it here, is unverified.
-- 
Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

panic at shutdown

[Dag-Erling Smorgrav]

For about a week, I've been getting panics at shutdown, caused by
cn_devopen() calling devsw() with a NULL dev argument.  I imagine it
may be related to recent changes in the console code.  If it's of any
interest, I have -Dh in my /boot.config.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: panic at shutdown

[Alexander Leidinger]

On  1 Aug, Bill Fumerola wrote:

 #0  boot (howto=256) at ../../kern/kern_shutdown.c:303
 303  dumppcb.pcb_cr3 = rcr3();
 
 type 'bt', this tells us just about as much as if you said
 "it crashed".
 
 though, by the panic message, this seems to be a known bug..

If I see the same bug everybody complains about: add "sync; sleep 1;
sync; sleep 1; sync" to rc.shutdown to work round it (I'm using kernel
sources from yesterday).

Bye,
Alexander.

-- 
  To boldly go where I surely don't belong.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: panic at shutdown

[Luoqi Chen]

 #7  0xc017a726 in vput (vp=0xc8710840) at vnode_if.h:794
 #8  0xc01aee87 in ffs_sync (mp=0xc0ade800, waitfor=2, cred=0xc0721700, 
 p=0xc026d5e0) at ../../ufs/ffs/ffs_vfsops.c:955

Change the vput(vp) call at line 955 of ffs_vfsops.c back to two separate
calls (see previous revision):

VOP_UNLOCK(vp, 0, p);
vrele(vp);

vput assumes curproc is the lock holder, but it's not true in this case.

-lq


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

panic at shutdown

[R Joseph Wright]

I just built a new world/kernel yesterday, and now I get a panic when I shut
down.  I ran gdb on the dump: 

..
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2998272
initial pcb at 25b1c0
panicstr: lockmgr: pid 1, not exclusive lock holder 0 unlocking
panic messages:
---
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: panic at shutdown

[Bill Fumerola]

On Mon, Jul 31, 2000 at 10:37:48PM -0700, R Joseph Wright wrote:
 I just built a new world/kernel yesterday, and now I get a panic when I shut
 down.  I ran gdb on the dump: 
 
 ..
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "i386-unknown-freebsd"...
 IdlePTD 2998272
 initial pcb at 25b1c0
 panicstr: lockmgr: pid 1, not exclusive lock holder 0 unlocking
 panic messages:
 ---
 ---
 #0  boot (howto=256) at ../../kern/kern_shutdown.c:303
 303   dumppcb.pcb_cr3 = rcr3();

type 'bt', this tells us just about as much as if you said
"it crashed".

though, by the panic message, this seems to be a known bug..

-- 
Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
[EMAIL PROTECTED] / [EMAIL PROTECTED]





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: panic at shutdown

[R Joseph Wright]

And Bill Fumerola spoke:
 On Mon, Jul 31, 2000 at 10:37:48PM -0700, R Joseph Wright wrote:
  I just built a new world/kernel yesterday, and now I get a panic when I shut
  down.  I ran gdb on the dump: 
  
  ..
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "i386-unknown-freebsd"...
  IdlePTD 2998272
  initial pcb at 25b1c0
  panicstr: lockmgr: pid 1, not exclusive lock holder 0 unlocking
  panic messages:
  ---
  ---
  #0  boot (howto=256) at ../../kern/kern_shutdown.c:303
  303 dumppcb.pcb_cr3 = rcr3();
 
 type 'bt', this tells us just about as much as if you said
 "it crashed".
 
 though, by the panic message, this seems to be a known bug..
 
 -- 
 Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
 [EMAIL PROTECTED] / [EMAIL PROTECTED]

Sorry :)

GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2998272
initial pcb at 25b1c0
panicstr: lockmgr: pid 1, not exclusive lock holder 0 unlocking
panic messages:
---
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=256) at ../../kern/kern_shutdown.c:303
#1  0xc014bd28 in poweroff_wait (junk=0xc02010a0, howto=1)
at ../../kern/kern_shutdown.c:553
#2  0xc0146af0 in lockmgr (lkp=0xc0c50a00, flags=6, interlkp=0xc87108ac, 
p=0xc7d4be00) at ../../kern/kern_lock.c:382
#3  0xc01779ab in vop_stdunlock (ap=0xc7d51e48) at ../../kern/vfs_default.c:255
#4  0xc01b6ccd in ufs_vnoperate (ap=0xc7d51e48)
at ../../ufs/ufs/ufs_vnops.c:2301
#5  0xc01b1bab in ufs_inactive (ap=0xc7d51e78) at vnode_if.h:865
#6  0xc01b6ccd in ufs_vnoperate (ap=0xc7d51e78)
at ../../ufs/ufs/ufs_vnops.c:2301
#7  0xc017a726 in vput (vp=0xc8710840) at vnode_if.h:794
#8  0xc01aee87 in ffs_sync (mp=0xc0ade800, waitfor=2, cred=0xc0721700, 
p=0xc026d5e0) at ../../ufs/ffs/ffs_vfsops.c:955
#9  0xc017c605 in sync (p=0xc026d5e0, uap=0x0) at ../../kern/vfs_syscalls.c:551
#10 0xc014b777 in boot (howto=0) at ../../kern/kern_shutdown.c:225
#11 0xc014b578 in reboot (p=0xc7d4be00, uap=0xc7d51f80)
at ../../kern/kern_shutdown.c:146
#12 0xc01ecd21 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = -1077936612, tf_esi = -1077936624, tf_ebp = -1077936836, 
  tf_isp = -942333996, tf_ebx = -1077936732, tf_edx = -1, tf_ecx = 4, 
  tf_eax = 55, tf_trapno = 7, tf_err = 2, tf_eip = 134536452, tf_cs = 31, 
  tf_eflags = 643, tf_esp = -1077937056, tf_ss = 47})
at ../../i386/i386/trap.c:1128
#13 0xc01e1ab5 in Xint0x80_syscall ()
#14 0x80486ee in ?? ()
#15 0x8048478 in ?? ()
#16 0x8048139 in ?? ()


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message