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

2018-01-28 Thread Cy Schubert
In message 

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

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-28 Thread 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"

2018-01-26 Thread 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"

2018-01-26 Thread 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"

2018-01-26 Thread 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


Re: Panic at shutdown

2015-12-08 Thread 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

2015-12-08 Thread 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"

Re: Panic at shutdown

2015-11-28 Thread 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

2012-11-30 Thread 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

2012-11-30 Thread 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


Re: Panic on shutdown, r243674M

2012-11-29 Thread 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: panic on shutdown

2003-10-25 Thread 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]


Re: panic at shutdown, ums related?

2002-04-27 Thread 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?

2002-04-25 Thread 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



Re: panic at shutdown, ums related?

2002-04-24 Thread 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

2001-11-04 Thread 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

2001-11-03 Thread 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



Re: panic at shutdown

2000-08-01 Thread 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

2000-08-01 Thread 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



Re: panic at shutdown

2000-07-31 Thread 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

2000-07-31 Thread 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