> 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 invest
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:
> >
> >
> 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
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.
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 a
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
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,
>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: sen
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 w
> #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):
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 t
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 det
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 "i
13 matches
Mail list logo
