Re: Panic at shutdown
> 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-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
> 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"
Panic at shutdown
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, ums related?
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?
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?
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, ums related?
Alexander Leidinger wrote: > 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... 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. :-/ Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic at shutdown, ums related?
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
>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
In article [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
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
> #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
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
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
Re: panic at shutdown
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
panic at shutdown
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
