Re: Panic: 12.2 fails to use VIMAGE jails

On Wed, Dec 09, 2020 at 02:00:37PM +1100, Dewayne Geraghty wrote: ! On a jail with config: ! exec.start = "/bin/sh -x /etc/rc"; ! exec.stop = "/bin/sh /etc/rc.shutdown"; ! exec.clean; ! ! test_prod { jid=7; persist; ip4.addr = ! "10.0.7.96,10.0.5.96,127.0.5.96"; devfs_ruleset = "6"; ! host.hostu

Re: Panic: 12.2 fails to use VIMAGE jails

Peter, I’m not interested in discussing software development methodology here. Please drop me from this thread. Let me know if/when you have a test case I can work from. Regards, Kristof On 9 Dec 2020, at 11:54, Peter wrote: On Tue, Dec 08, 2020 at 07:51:07PM -0600, Kyle Evans wrote: !

Re: Panic: 12.2 fails to use VIMAGE jails

On Tue, Dec 08, 2020 at 07:51:07PM -0600, Kyle Evans wrote: ! You seem to have misinterpreted this; he doesn't want to narrow it ! down to one bug, he wants simple steps that he can follow to reproduce Maybe I did misinterpret, but then I don't really understand it. I would suppose, when testing

Re: Panic: 12.2 fails to use VIMAGE jails

On 9 Dec 2020, at 2:31, Peter wrote: On Tue, Dec 08, 2020 at 08:02:47PM +0100, Kristof Provost wrote: ! > Sorry for the bad news. ! > ! You appear to be triggering two or three different bugs there. That is possible. Then there are two or three different bugs in the production code. In any cas

Re: Panic: 12.2 fails to use VIMAGE jails

On Tue, Dec 8, 2020 at 7:45 PM Peter wrote: > > > On Tue, Dec 08, 2020 at 08:02:47PM +0100, Kristof Provost wrote: > > Can you reduce your netgraph use case to a small test case that can trigger > ? the problem? > > I'm sorry, I fear I don't get Your point. > Assumed there are actually two or thre

Re: Panic: 12.2 fails to use VIMAGE jails

On Tue, Dec 08, 2020 at 08:02:47PM +0100, Kristof Provost wrote: ! > Sorry for the bad news. ! > ! You appear to be triggering two or three different bugs there. That is possible. Then there are two or three different bugs in the production code. In any case, my current workaround, i.e. delayi

Re: Panic: 12.2 fails to use VIMAGE jails

Here is the next funny crashdump - I obtained this one twice and also the sysctl_rtsock() again. I can reproduce this by just starting and stopping a most simple jail that does only exec.start = "/bin/sleep 4 &"; (And as usual, when I let it time out, nothing bad happens.) Fatal trap 9:

Re: Panic: 12.2 fails to use VIMAGE jails

On 8 Dec 2020, at 19:49, Peter wrote: On Tue, Dec 08, 2020 at 04:50:00PM +0100, Kristof Provost wrote: ! Yeah, the bug is not exclusive to epair but that’s where it’s most easily ! seen. Ack. ! Try http://people.freebsd.org/~kp/0001-if-Fix-panic-when-destroying-vnet-and-epair-simultan.patch

Re: Panic: 12.2 fails to use VIMAGE jails

On Tue, Dec 08, 2020 at 04:50:00PM +0100, Kristof Provost wrote: ! Yeah, the bug is not exclusive to epair but that’s where it’s most easily ! seen. Ack. ! Try http://people.freebsd.org/~kp/0001-if-Fix-panic-when-destroying-vnet-and-epair-simultan.patch Great, thanks a lot. Now I have bad news

Re: Panic: 12.2 fails to use VIMAGE jails

On 8 Dec 2020, at 0:34, Peter wrote: Hi Kristof, it's great to read You! On Mon, Dec 07, 2020 at 09:11:32PM +0100, Kristof Provost wrote: ! That smells a lot like the epair/vnet issues in bugs 238870, 234985, 244703, ! 250870. epair? No. It is purely Netgrh here. Yeah, the bug is not excl

Re: Panic: 12.2 fails to use VIMAGE jails

Hi Kristof, it's great to read You! On Mon, Dec 07, 2020 at 09:11:32PM +0100, Kristof Provost wrote: ! That smells a lot like the epair/vnet issues in bugs 238870, 234985, 244703, ! 250870. epair? No. It is purely Netgraph here. ! I pushed a fix for that in CURRENT in r368237. It’s schedul

Re: Panic: 12.2 fails to use VIMAGE jails

On 7 Dec 2020, at 13:54, Peter wrote: After clean upgrade (from source) from 11.4 to 12.2-p1 my jails do no longer work correctly. Old-fashioned jails seem to work, but most are VIMAGE+NETGRAPH style, and do not work properly. All did work flawlessly for nearly a year with Rel.11. If I start 2-

Re: panic when stopping jails

Forgot to mention that it is a very recent 12-STABLE and I don’t suspect any recent commits. It is just that jails are now stopped more often. > On 3 Dec 2019, at 11:47, peter.b...@bsd4all.org wrote: > > Hi, > > I’m getting the following panic when stopping jais. When ifunit_ref iterates > ov

Re: panic: I/O to pool appears to be hung on vdev

15.11.2019 13:08, Eugene Grosbein wrote: > Hi! > > Recently I did routine source upgrade from 11.2-STABLE/amd64 to 11.3-STABLE > r354667 > that went without any problem. After less than 2 days of uptime it paniced > and failed to reboot (hung), > screenshot is here: http://www.grosbein.net/freeb

Re: panic: I/O to pool appears to be hung on vdev

15.11.2019 13:08, Eugene Grosbein wrote: > Hi! > > Recently I did routine source upgrade from 11.2-STABLE/amd64 to 11.3-STABLE > r354667 > that went without any problem. After less than 2 days of uptime it paniced > and failed to reboot (hung), > screenshot is here: http://www.grosbein.net/freeb

Re: efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)

Hi, This patch resolves the panic when booting without efi.rt.disabled=1 for me. Thanks! Jan M. > On 31 May 2019, at 20:35, Konstantin Belousov wrote: > > On Fri, May 31, 2019 at 04:19:57PM +0200, Jan Martin Mikkelsen wrote: >> Hi, >> >> Christian has pointed me at this >> https://bugs.fre

Re: efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)

On Fri, May 31, 2019 at 04:19:57PM +0200, Jan Martin Mikkelsen wrote: > Hi, > > Christian has pointed me at this > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233534 which he raised > after his email. The workaround was to boot with “efi.rt.disabled=1”. > > I took a closer look at what i

efirtc causing panic (was Re: Panic booting 12-RC2 on amd64)

Hi, Christian has pointed me at this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233534 which he raised after his email. The workaround was to boot with “efi.rt.disabled=1”. I took a closer look at what is going on. The problem is that the EFI rt_gettime call is faulting, and the fault

Re: Panic booting 12-RC2 on amd64

Hi, I see exactly the same stacktrace on a Celeron J1900 based system with 12.0-p5 when using a UEFI boot. With a non-UEFI boot it works fine (except vt not working until the new 915kms.ko is loaded). With safe mode on it also works fine. Did you find any more information? Regards, Jan. > O

Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()

On Wed, 17 Apr 2019 12:05+0200, Trond Endrestøl wrote: > On Wed, 17 Apr 2019 12:41+0300, Andrey V. Elsukov wrote: > > > On 15.04.2019 16:31, Trond Endrestøl wrote: > > > Has anyone else witnessed a panic during reboot involving > > > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > >

Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()

On Wed, 17 Apr 2019 12:41+0300, Andrey V. Elsukov wrote: > On 15.04.2019 16:31, Trond Endrestøl wrote: > > Has anyone else witnessed a panic during reboot involving > > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > > > The stack trace goes more or less like this: > > > > db_trace_s

Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()

On 15.04.2019 16:31, Trond Endrestøl wrote: > Has anyone else witnessed a panic during reboot involving > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > The stack trace goes more or less like this: > > db_trace_self_wrapper() > vpanic() > panic() > trap_fatal() > trap() > calltrap()

Re: Panic during reboot involving softclock_call_cc(), nd6_timer() and nd6_dad_start()

On Mon, 15 Apr 2019 15:31+0200, Trond Endrestøl wrote: > Has anyone else witnessed a panic during reboot involving > softclock_call_cc(), nd6_timer(), and nd6_dad_start()? > > The stack trace goes more or less like this: > > db_trace_self_wrapper() > vpanic() > panic() > trap_fatal() > trap() >

Re: Panic on 11-STABLE with Xen guest

On 11/26/18 13:31, John Baldwin wrote: > On 11/22/18 12:39 PM, Joe Clarke wrote: >> I believe after the commit 340016 for the dynamic IRQ layout, my Xen VM >> started to panic. I just upgraded the kernel today and saw this: >> >> xen: unable to map IRQ#2 >> panic: Unable to register interrupt over

Re: Panic on 11-STABLE with Xen guest

On Mon, Nov 26, 2018 at 10:31:43AM -0800, John Baldwin wrote: > On 11/22/18 12:39 PM, Joe Clarke wrote: > > I believe after the commit 340016 for the dynamic IRQ layout, my Xen VM > > started to panic. I just upgraded the kernel today and saw this: > > > > xen: unable to map IRQ#2 > > panic: Unab

Re: Panic on 11-STABLE with Xen guest

On 11/22/18 12:39 PM, Joe Clarke wrote: > I believe after the commit 340016 for the dynamic IRQ layout, my Xen VM > started to panic. I just upgraded the kernel today and saw this: > > xen: unable to map IRQ#2 > panic: Unable to register interrupt override > cpuid = 0 > KDB: stack backtrace: > #0

Re: Panic on 11-STABLE with Xen guest

On 11/25/18 18:22, Richard M.Timoney wrote: > I have the same failure to boot 11-stable as a DomU host on xen_version: > 4.4.1 > > > Kernel I was trying was recent, FreeBSD 11.2-STABLE (GENERIC) #23 > r334205:340834 > > > commit 340016 for the dynamic IRQ layout seems rather involved and I doub

Re: Panic booting 12-RC2 on amd64

26.11.2018 15:49, Christian Ullrich wrote: >>> 26.11.2018 1:26, Christian Ullrich wrote: >>> I'd really like to upgrade to 12. If anyone can suggest something I can try, I'll be happy to do experiments. >>> >>> Try verbose boot (boot -v), collect pre-panic output and post it again. > >

Re: Panic booting 12-RC2 on amd64

* Christian Ullrich wrote: > * Eugene Grosbein wrote: > >> 26.11.2018 1:26, Christian Ullrich wrote: >> >>> I'd really like to upgrade to 12. If anyone can suggest something I can >>> try, I'll be happy to do experiments. >> >> Try verbose boot (boot -v), collect pre-panic output and post it agai

Re: Panic booting 12-RC2 on amd64

* Eugene Grosbein wrote: > 26.11.2018 1:26, Christian Ullrich wrote: > >> I'd really like to upgrade to 12. If anyone can suggest something I can >> try, I'll be happy to do experiments. > > Try verbose boot (boot -v), collect pre-panic output and post it again. This is from the 12-RC2 memstick

Re: Panic on 11-STABLE with Xen guest

I have the same failure to boot 11-stable as a DomU host on xen_version: 4.4.1 Kernel I was trying was recent, FreeBSD 11.2-STABLE (GENERIC) #23 r334205:340834 commit 340016 for the dynamic IRQ layout seems rather involved and I doubt I could isolate the problem, but maybe it is in 338631: x

Re: Panic booting 12-RC2 on amd64

26.11.2018 1:26, Christian Ullrich wrote: > I'd really like to upgrade to 12. If anyone can suggest something I can > try, I'll be happy to do experiments. Try verbose boot (boot -v), collect pre-panic output and post it again. ___ freebsd-stable@fre

Re: Panic (gpf) in early boot after upgrading FreeBSD 10.4 -> 11.2 on Ganeti

On Mon, 12 Nov 2018 01:58:12 -0500, Konstantin Belousov wrote: > On Sun, Nov 11, 2018 at 11:24:48PM -0500, Rob Austein wrote: > > > > panic: general protection fault > > cpuid = 0 > > KDB: stack backtrace: > > #0 0x80b3d587 at kdb_backtrace+0x67 > > #1 0x80af6b2

Re: Panic (gpf) in early boot after upgrading FreeBSD 10.4 -> 11.2 on Ganeti

On Sun, Nov 11, 2018 at 11:24:48PM -0500, Rob Austein wrote: > Belated upgrade (don't ask) of a pair of FreeBSD 10.4 VMs to 11.2. > Each VM got as far as: > > freebsd-update -r 11.2-RELEASE update > freebsd-update install > reboot > > Each VM got an immediate kernel panic after the reboot (

Re: panic: vdrop: holdcnt 0

On Thu, Mar 22, 2018 at 7:37 AM, Eugene M. Zheganin wrote: > Hello, > > On 22.03.2018 18:05, Eugene M. Zheganin wrote: > >> today I eventyally got "panic: vdrop: holdcnt 0" on an iSCSI host, on an >> 11.1. Since I don't see any decent information on this - I just wanted to >> ask - what this kind

Re: panic: vdrop: holdcnt 0

Hello, On 22.03.2018 18:05, Eugene M. Zheganin wrote: today I eventyally got "panic: vdrop: holdcnt 0" on an iSCSI host, on an 11.1. Since I don't see any decent information on this - I just wanted to ask - what this kind of panic generally mean ? And where do I go with this. The only PR I see

Re: panic when loading mlxen

> On 3 Feb 2018, at 12:16, Hans Petter Selasky wrote: > > Hi, > > I think Alexander came ahead of me: > > https://svnweb.freebsd.org/base?view=revision&revision=328805 > > Can you try r328805 ? > > --HPS yup, it works, well it doesn’t panic. thanks danny _

Re: panic when loading mlxen

Hi, I think Alexander came ahead of me: https://svnweb.freebsd.org/base?view=revision&revision=328805 Can you try r328805 ? --HPS ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, se

Re: panic when loading mlxen

> On 3 Feb 2018, at 11:34, Hans Petter Selasky wrote: > > On 02/03/18 08:34, Daniel Braniss wrote: >>> On 2 Feb 2018, at 20:47, K. Macy wrote: >>> >>> That's odd since it doesn't use any of taskqgroup stuff. I take it you >>> can't get a core? >> no core but some more info: >> db> bt >> Traci

Re: panic when loading mlxen

On 02/03/18 08:34, Daniel Braniss wrote: On 2 Feb 2018, at 20:47, K. Macy wrote: That's odd since it doesn't use any of taskqgroup stuff. I take it you can't get a core? no core but some more info: db> bt Tracing pid 0 tid 10 td 0x81e0e500 taskqgroup_attach_cpu() at taskqgroup_

Re: panic when loading mlxen

> On 2 Feb 2018, at 20:47, K. Macy wrote: > > That's odd since it doesn't use any of taskqgroup stuff. I take it you > can't get a core? no core but some more info: db> bt Tracing pid 0 tid 10 td 0x81e0e500 taskqgroup_attach_cpu() at taskqgroup_attach_cpu+0x4f/frame 0x822e4

Re: panic when loading mlxen

That's odd since it doesn't use any of taskqgroup stuff. I take it you can't get a core? Also, why are you loading it in loader.conf (slower) as opposed to rc.conf? -M On Fri, Feb 2, 2018 at 4:46 AM, Daniel Braniss wrote: > with latest stable (r328769) when I have > mlxen_load=“YES” >

Re: Panic in unionfs "it is not a unionfs-vnode"

Oops, wrong list. I just resent to freebsd-current. > On 15 Nov 2017, at 12:48, Jan Mikkelsen wrote: > > Hi, > > I got the panic below in unionfs. Head as at 325569, 2017-11-09 12:41:00 > +1100 (Thu, 09 Nov 2017). > > This is a ufs filesystem union mounted on top of a read-only ufs /etc. I kn

bhyve ppt usage can cause severe RAM corruption [Was: Re: panic: Memory modified after free in zio_create, passthru in use]

Bezüglich Harry Schmalzbauer's Nachricht vom 11.06.2017 12:37 (localtime): > Bezüglich Harry Schmalzbauer's Nachricht vom 06.06.2017 14:03 (localtime): >> Hello, >> >> suddenly, I'm getting this error: >> /lib/libc.so.7: Undefined symbol "xdr_accepted_reply" >> >> Very mysterious: It showed up o

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Harry Schmalzbauer's Nachricht vom 03.10.2017 16:39 (localtime): > Bezüglich Andriy Gapon's Nachricht vom 03.10.2017 16:28 (localtime): >> On 03/10/2017 17:19, Harry Schmalzbauer wrote: >>> Have tried several different txg IDs, but the latest 5 or so lead to the >>> panic and some other

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Andriy Gapon's Nachricht vom 03.10.2017 16:28 (localtime): > On 03/10/2017 17:19, Harry Schmalzbauer wrote: >> Have tried several different txg IDs, but the latest 5 or so lead to the >> panic and some other random picked all claim missing devices... >> Doh, if I only knew about -T some d

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

On 03/10/2017 17:19, Harry Schmalzbauer wrote: > Have tried several different txg IDs, but the latest 5 or so lead to the > panic and some other random picked all claim missing devices... > Doh, if I only knew about -T some days ago, when I had all 4 devices > available. I don't think that the err

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Andriy Gapon's Nachricht vom 03.10.2017 11:20 (localtime): > On 03/10/2017 11:43, Harald Schmalzbauer wrote: > ... >> action: The pool can be imported despite missing or damaged devices. The >> fault tolerance of the pool may be compromised if imported. > ... >> Is it impossibl

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

On 03/10/2017 11:43, Harald Schmalzbauer wrote: ... > action: The pool can be imported despite missing or damaged devices. The > fault tolerance of the pool may be compromised if imported. ... > Is it impossible to import degraded pools in general, or only together> with > "-X -T"? It sh

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Harry Schmalzbauer's Nachricht vom 02.10.2017 20:28 (localtime): > Bezüglich Andriy Gapon's Nachricht vom 02.10.2017 13:49 (localtime): >> On 01/10/2017 00:38, Harry Schmalzbauer wrote: >>> Now my striped mirror has all 4 devices healthy available, but all >>> datasets seem to be lost. >

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Andriy Gapon's Nachricht vom 02.10.2017 13:49 (localtime): > On 01/10/2017 00:38, Harry Schmalzbauer wrote: >> Now my striped mirror has all 4 devices healthy available, but all >> datasets seem to be lost. >> No problem for 450G (99,9_%), but there's a 80M dataset which I'm really >> mis

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Scott Bennett's Nachricht vom 01.10.2017 15:20 (localtime): > On Sat, 30 Sep 2017 23:38:45 +0200 Harry Schmalzbauer > > wrote: … >> >> OpenIndiana also panics at regular import. >> Unfortunately I don't know the aequivalent of vfs.zfs.recover in OI. >> >> panic[cpu1]/thread=ff

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

On 01/10/2017 00:38, Harry Schmalzbauer wrote: > Now my striped mirror has all 4 devices healthy available, but all > datasets seem to be lost. > No problem for 450G (99,9_%), but there's a 80M dataset which I'm really > missing :-( If it's not too late now, you may try to experiment with an "unwi

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

On Sat, 30 Sep 2017 23:38:45 +0200 Harry Schmalzbauer wrote: > Bez?glich Harry Schmalzbauer's Nachricht vom 30.09.2017 19:25 (localtime): >> Bez?glich Harry Schmalzbauer's Nachricht vom 30.09.2017 18:30 (localtime): >>> Bad surprise. >>> Most likely I forgot to stop a PCIe-Passthrough NIC b

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Harry Schmalzbauer's Nachricht vom 30.09.2017 19:25 (localtime): > Bezüglich Harry Schmalzbauer's Nachricht vom 30.09.2017 18:30 (localtime): >> Bad surprise. >> Most likely I forgot to stop a PCIe-Passthrough NIC before shutting down >> that (byhve(8)) guest – jhb@ helped my identifyi

Re: panic: Solaris(panic): blkptr invalid CHECKSUM1

Bezüglich Harry Schmalzbauer's Nachricht vom 30.09.2017 18:30 (localtime): > Bad surprise. > Most likely I forgot to stop a PCIe-Passthrough NIC before shutting down > that (byhve(8)) guest – jhb@ helped my identifying this as the root > cause for sever memory corruptions I regularly had (on stab

Re: [SOLVED] Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

On Thu, Jul 13, 2017 at 05:06:12PM -0700, Mark Johnston wrote: > On Thu, Jul 13, 2017 at 01:06:30PM +, Glen Barber wrote: > > On Wed, Jul 12, 2017 at 11:29:05PM -0700, jungle boogie wrote: > > > On 07/10/2017 10:48 PM, Konstantin Belousov wrote: > > > > On Mon, Jul 10, 2017 at 01:00:05PM -0700,

Re: [SOLVED] Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

On Thu, Jul 13, 2017 at 01:06:30PM +, Glen Barber wrote: > On Wed, Jul 12, 2017 at 11:29:05PM -0700, jungle boogie wrote: > > On 07/10/2017 10:48 PM, Konstantin Belousov wrote: > > > On Mon, Jul 10, 2017 at 01:00:05PM -0700, Mark Johnston wrote: > > > > I suspect that this is a result of r32076

Re: [SOLVED] Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

On Wed, Jul 12, 2017 at 11:29:05PM -0700, jungle boogie wrote: > On 07/10/2017 10:48 PM, Konstantin Belousov wrote: > > On Mon, Jul 10, 2017 at 01:00:05PM -0700, Mark Johnston wrote: > > > I suspect that this is a result of r320763. That change removed a field > > > from struct vm_map_entry, which

Re: [SOLVED] Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

On 07/10/2017 10:48 PM, Konstantin Belousov wrote: On Mon, Jul 10, 2017 at 01:00:05PM -0700, Mark Johnston wrote: I suspect that this is a result of r320763. That change removed a field from struct vm_map_entry, which is embedded in struct vm_map. Virtualbox does not reference the fields of stru

Re: [SOLVED] Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

On Mon, Jul 10, 2017 at 01:00:05PM -0700, Mark Johnston wrote: > I suspect that this is a result of r320763. That change removed a field > from struct vm_map_entry, which is embedded in struct vm_map. Virtualbox > does not reference the fields of struct vm_map directly, but it does > call vm_map_pm

Re: [SOLVED] Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

On Mon, Jul 10, 2017 at 09:47:50PM +0200, José G. Juanino wrote: > El Monday 10 de July a las 21:24:41 CEST, José G. Juanino escribió: > >El Sunday 09 de July a las 23:48:29 CEST, David Boyd escribió: > >>With latest VM-IMAGE (vmdk) for 11.1-RC2 system panics. I haven't > >>been able to process t

[SOLVED] Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

El Monday 10 de July a las 21:24:41 CEST, José G. Juanino escribió: El Sunday 09 de July a las 23:48:29 CEST, David Boyd escribió: With latest VM-IMAGE (vmdk) for 11.1-RC2 system panics. I haven't been able to process the panic completely, but the backtrace looks mysteriously similar to those

Re: Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice

El Sunday 09 de July a las 23:48:29 CEST, David Boyd escribió: With latest VM-IMAGE (vmdk) for 11.1-RC2 system panics. I haven't been able to process the panic completely, but the backtrace looks mysteriously similar to those provided with PR219146. Initially, the VM-IMAGE booted just fine.

Re: Panic in nvidia module

On Mon, Mar 27, 2017 at 11:39:28AM -0700, Larry Rosenman wrote: > On 3/27/17, 11:34 AM, "Jonathan Chen" behalf of j...@chen.org.nz> wrote: Thanks Larry & Jonathan, rebuidling the nvidia driver against the new kernel solved the issue. -- David Marec https://lapinbilly.eu __

Re: Panic in nvidia module

On 3/27/17, 11:34 AM, "Jonathan Chen" wrote: On 28 March 2017 at 07:12, David Marec wrote: > greeting, > > Tracking 11-Stable, > - now : 316014, - > kernel panics on 'page fault' within nvidia module. > The system boots and works well ( 'vt' in graphic mode) until x

Re: Panic in nvidia module

On 28 March 2017 at 07:12, David Marec wrote: > greeting, > > Tracking 11-Stable, > - now : 316014, - > kernel panics on 'page fault' within nvidia module. > The system boots and works well ( 'vt' in graphic mode) until xorg starts. Everytime you sync up STABLE, you have to rebuild your nvidia-

Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

Just pop open the crashdump and "print *ifp" in the last stack frame before trap. -a On 11 August 2016 at 16:42, David Wolfskill wrote: > On Thu, Aug 11, 2016 at 04:37:26PM -0700, Adrian Chadd wrote: >> Eep. Is this anotehr case where there's a race and ifp is NULL or the >> ll pointer for ifp

Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

On Thu, Aug 11, 2016 at 04:37:26PM -0700, Adrian Chadd wrote: > Eep. Is this anotehr case where there's a race and ifp is NULL or the > ll pointer for ifp is NULL or use-after-free'd? I don't know, but it's the only panic of a similar nature I've seen -- though since on any given day, I'm usually

Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

.. and maybe we should revert or comment out the code until we figure out what to do about LLADDR checks. (I see this in the detach path too; same kind of race. Sigh.) -adrian On 11 August 2016 at 16:37, Adrian Chadd wrote: > Eep. Is this anotehr case where there's a race and ifp is NULL or t

Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

Eep. Is this anotehr case where there's a race and ifp is NULL or the ll pointer for ifp is NULL or use-after-free'd? I remember bumping into these here and there because we don't seem to have a well defined lifecycle for lladdr access. ;( -adrian On 10 August 2016 at 12:10, Bryan Drewery wro

Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

On 8/10/16 9:54 AM, David Wolfskill wrote: > Happened after a few iterations of {"pkill dhclient" followed by > "dhclient wlan0"}. > > Gory details (both "normal" and gzipped, and including the crash > dump and crashinfo) are in > . >

Re: Panic on BETA1 in the ZFS subsystem

On 22/07/2016 16:39, Steven Hartland wrote: > Yes does indeed sound like what happened to me. Can you think of any way that we can use to limit the zio_execute chaining? Like somehow keeping track of the nesting and returning NULL instead of a queued zio when we reach a limit. -- Andriy Gapon _

Re: Panic on BETA1 in the ZFS subsystem

On 21/07/2016 13:52, Andriy Gapon wrote: On 21/07/2016 15:25, Karl Denninger wrote: The crash occurred during a backup script operating, which is (roughly) the following: zpool import -N backup (mount the pool to copy to) iterate over a list of zfs filesystems and... zfs rename fs@zfs-base fs

Re: Panic on BETA1 in the ZFS subsystem

On 7/21/2016 07:52, Andriy Gapon wrote: > On 21/07/2016 15:25, Karl Denninger wrote: >> The crash occurred during a backup script operating, which is (roughly) >> the following: >> >> zpool import -N backup (mount the pool to copy to) >> >> iterate over a list of zfs filesystems and... >> >> zfs re

Re: Panic on BETA1 in the ZFS subsystem

On 21/07/2016 15:25, Karl Denninger wrote: > The crash occurred during a backup script operating, which is (roughly) > the following: > > zpool import -N backup (mount the pool to copy to) > > iterate over a list of zfs filesystems and... > > zfs rename fs@zfs-base fs@zfs-old > zfs snapshot fs@z

Re: Panic on BETA1 in the ZFS subsystem

On 7/21/2016 03:07, Andriy Gapon wrote: > On 21/07/2016 00:54, Karl Denninger wrote: >> io_type = ZIO_TYPE_FREE, >> io_child_type = ZIO_CHILD_VDEV, >> io_cmd = 0, >> io_priority = ZIO_PRIORITY_TRIM, >> io_flags = 789633, >> io_stage = ZIO_STAGE_VDEV_IO_DONE, >> io_pipeline = 3080192,

Re: Panic on BETA1 in the ZFS subsystem

On 21/07/2016 00:54, Karl Denninger wrote: > io_type = ZIO_TYPE_FREE, > io_child_type = ZIO_CHILD_VDEV, > io_cmd = 0, > io_priority = ZIO_PRIORITY_TRIM, > io_flags = 789633, > io_stage = ZIO_STAGE_VDEV_IO_DONE, > io_pipeline = 3080192, > io_orig_flags = 525441, > io_orig_stage =

Re: Panic on BETA1 in the ZFS subsystem

On 7/20/2016 16:32, Andriy Gapon wrote: > On 20/07/2016 17:26, Karl Denninger wrote: >> #185 0x8222955d in zio_vdev_io_start (zio=0xf80108754770) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2870 >> #186 0x82225d96 in zio_execute (zio=) >> at /usr/

Re: Panic on BETA1 in the ZFS subsystem

On 20/07/2016 17:26, Karl Denninger wrote: > #185 0x8222955d in zio_vdev_io_start (zio=0xf80108754770) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:2870 > #186 0x82225d96 in zio_execute (zio=) > at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs

Re: Panic on BETA1 in the ZFS subsystem

An attempted repeat of the transfer panic'd the machine again immediately. I removed all of the snapshots on the root zfs and the copy ran to completion. This appears to be identical to the problem that was previously present where snapshots on the root filesystem sometimes are corrupted, with th

Re: Panic on BETA1 in the ZFS subsystem

The panic was due to stack exhaustion, why it was so deep not looked. On 20/07/2016 15:32, Karl Denninger wrote: The panic occurred during a zfs send/receive operation for system backup. I've seen this one before, unfortunately, and it appears that it's still there -- may be related to https

Re: Panic on BETA1 in the ZFS subsystem

The panic occurred during a zfs send/receive operation for system backup. I've seen this one before, unfortunately, and it appears that it's still there -- may be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207464 On 7/20/2016 09:26, Karl Denninger wrote: > Came out of the ZFS

Re: Panic with sym on 10.2

On Tue, Jan 19, 2016 at 03:39:55PM +0100, Andrea Venturoli wrote: > On 01/19/16 15:19, Matthew Seaman wrote: > > On 01/19/16 13:13, Andrea Venturoli wrote: > >> Two days ago I upgraded a (perfectly working) 9.3/i386 box to 10.2p10 > >> Since then I've had two panics with the following message: > >>

Re: Panic with sym on 10.2

On 01/19/16 15:19, Matthew Seaman wrote: On 01/19/16 13:13, Andrea Venturoli wrote: Two days ago I upgraded a (perfectly working) 9.3/i386 box to 10.2p10 Since then I've had two panics with the following message: panic: assertion "lp->busy_itl==0&&lp->busy_itlq==0" failed: file /usr/src/sys/dev

Re: [panic] 10.1-RELEASE-p14 #4 r285499M sporadic reboot

* Zeus Panchenko, 2015-07-22 : > on important production server I've started to experience weird regular > (once a day-two) sporadic reboots after last upgrade (2015-07-17), and > would appreciate if someone could help me to analyze further and fix the > issue. > > Collected crash information bel

Re: Panic [page fault] in _ieee80211_crypto_delkey(): stable/10/amd64 @r286878

On Wed, Aug 19, 2015 at 01:01:24PM -0700, David Wolfskill wrote: > On Wed, Aug 19, 2015 at 12:25:38PM -0700, Adrian Chadd wrote: > > ... But we definitely ahe enough to put into a PR.. > > ... > > Bug 202494 - Panic [page fault] in _ieee80211_crypto_delkey() >

Re: Panic [page fault] in _ieee80211_crypto_delkey(): stable/10/amd64 @r286878

On Wed, Aug 19, 2015 at 12:25:38PM -0700, Adrian Chadd wrote: > ... But we definitely ahe enough to put into a PR.. > ... Bug 202494 - Panic [page fault] in _ieee80211_crypto_delkey() Peace, david -- David H. Wolfskill

Re: Panic [page fault] in _ieee80211_crypto_delkey(): stable/10/amd64 @r286878

hi, you'll have to do some debugging. it looks like it's some kind of odd race - line 461 is _ieee80211_crypto_delkey(); line 105 is cipher_detach() and it blows up there. Try "wlandebug +crypto" during your next boot and let's see what it logs for the key. If you can 'print *key' in kgdb on the

Re: Panic [page fault] in _ieee80211_crypto_delkey(): stable/10/amd64 @r286878

On Tue, Aug 18, 2015 at 04:20:07PM -0700, David Wolfskill wrote: > I was minding my own business in a staff meeting this afternoon, and my > laptop rebooted; seems it got a panic. I've copied the core.txt.0 file > to , along with a > verbose dme

Re: panic: wm_page_unwire

> On 20 июня 2015 г., at 13:01, Konstantin Belousov wrote: > > > I was able to reproduce something related, this may be very well your > problem. Take the attached program. Select a scratch file on UFS mount > point, say x. Run the following commands: > mlock_modify x& > dd if=/dev/zero of=x

Re: panic: wm_page_unwire

On Sat, Jun 20, 2015 at 10:23:39AM +0300, Dmitry Sivachenko wrote: > > > On 19 июня 2015 г., at 22:57, Dmitry Sivachenko wrote: > > > > Hello, > > > > got this panic today on my 10.1-STABLE #0 r279956 box: > > > > > > > Well, I tracked this down a bit. Rather easy way to panic -stable box

Re: panic: wm_page_unwire

> On 19 июня 2015 г., at 22:57, Dmitry Sivachenko wrote: > > Hello, > > got this panic today on my 10.1-STABLE #0 r279956 box: > > Well, I tracked this down a bit. Rather easy way to panic -stable box (mine is r279956), but I can't reliably reproduce this. It happens when there is a pro

Re: panic: pmap active 0xfffff8001b7154b8

Small update for archiving purposes: I’ve been in contact with bdrewery and kib outside of the mailing list which resulted in the following patch: https://svnweb.freebsd.org/base?view=revision&revision=282679 We’re currently in the

Re: panic: pmap active 0xfffff8001b7154b8

> > What we really need is a full core dump (minidump) and backtrace. This > will let us inspect the pmap state. > > https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > > https://www.freebsd.org/d

Re: panic: pmap active 0xfffff8001b7154b8

On 5/7/2015 10:06 AM, Bryan Drewery wrote: > On 5/7/2015 7:08 AM, Johan Schuijt-Li wrote: >> Hi, >> >> We’ve been seeing (seemingly) random reboots on 10.1-RELEASE virtual >> machines (KVM virtualisation) on our production servers. In an attempt to >> determine what was causing this we’ve switche

Re: panic: pmap active 0xfffff8001b7154b8

On 5/7/2015 7:08 AM, Johan Schuijt-Li wrote: > Hi, > > We’ve been seeing (seemingly) random reboots on 10.1-RELEASE virtual machines > (KVM virtualisation) on our production servers. In an attempt to determine > what was causing this we’ve switched to running a kernel with INVARIANTS > enabled.

Re: panic with if_iwi(4) upon "netif restart"

Sure, uhm, just remind me to commit it to -HEAD in the next few days. Then I'll get it backported to stable/9. Thanks, -adrian On 29 September 2013 10:03, Alexey Dokuchaev wrote: > On Wed, Jul 04, 2012 at 06:51:56PM +0200, Bernhard Schmidt wrote: > > On Tuesday 19 June 2012 07:28:11 Alexey

Re: panic with if_iwi(4) upon "netif restart"

On Wed, Jul 04, 2012 at 06:51:56PM +0200, Bernhard Schmidt wrote: > On Tuesday 19 June 2012 07:28:11 Alexey Dokuchaev wrote: > > On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: > > > does "ps" in kgdb reveal multiple instances of wpa_supplicant running? > > > If so, this seems to

Re: Panic: 9.2-PRERELEASE - enc_daemon

- John's Original Message - > Hi Folks, > >I'm seeing a panic with the 9.2-PRERELEASE code. The system > will stay up for anywhere from a couple of seconds to a few hours > and then panic. I have continued to look at this problem and believe I have made some progress but still have

  1   2   3   4   5   6   7   8   9   10   >