Analyzing kernel panic from VIMAGE/Netgraph takedown

Stopping a VIMAGE+Netgraph jail in 12.2 in the same way as it did work with Rel. 11.4, crashes the kernel after 2 or 3 start/stop iterations. Specifically. this does not work: exec.poststop = "/usr/sbin/ngctl shutdown ${ifname1l}:"; Also this new option from Rel.12 does not work either, it

Re: Kernel panic in zfs code; 12-STABLE

On 7/18/2019 15:35, Karl Denninger wrote: > On 7/18/2019 15:19, Eugene Grosbein wrote: >> 19.07.2019 3:13, Karl Denninger wrote: >> >>> FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019 >>> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP >>> >>> Note -- no patches

Re: Kernel panic in zfs code; 12-STABLE

On 7/18/2019 15:19, Eugene Grosbein wrote: > 19.07.2019 3:13, Karl Denninger wrote: > >> FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019 >> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP >> >> Note -- no patches of any sort in the ZFS code; I am NOT running any

Re: Kernel panic in zfs code; 12-STABLE

19.07.2019 3:13, Karl Denninger wrote: > FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019 > k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP > > Note -- no patches of any sort in the ZFS code; I am NOT running any of > my former patch set. > >

Kernel panic in zfs code; 12-STABLE

FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019 k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP Note -- no patches of any sort in the ZFS code; I am NOT running any of my former patch set. NewFS.denninger.net dumped core - see /var/crash/vmcore.8 Thu Jul 18

Re: Kernel panic on 12-STABLE-r348203 amd64

KDB: stack backtrace: >>> #0 0x80c16df7 at ??+0 >>> #1 0x80bcaccd at ??+0 >>> #2 0x80bcab23 at ??+0 >>> #3 0x80f0b03c at ??+0 >>> #4 0x80f08d8d at ??+0 >>> #5 0x80f0bb3d at ??+0 >>> #6 0xff

Re: Kernel panic on 12-STABLE-r348203 amd64

Anyone know why ? This box has 64G ram. -- mark saad | nones...@longcount.org So after some poking in the bios this has to do with how the Dell NUMA options are set. If the system is set Cluster On Die mode, you get a kernel panic Home Snoop or Early Snoop no issue. Hi Mark, Could you rep

Re: Kernel panic on 12-STABLE-r348203 amd64

f80f0b03c at ??+0 > #4 0x80f08d8d at ??+0 > #5 0x80f0bb3d at ??+0 > #6 0x80f0b301 at ??+0 > #7 0x80f0b3d1 at ??+0 > #8 0x80f066c4 at ??+0 > #9 0x80f0543f at ??+0 > #10 0x80f23aef at ??+0 > #11 0x80f1133b at

Re: Kernel panic on 12-STABLE-r348203 amd64

On Wed, Jun 5, 2019 at 12:29 PM Mark Saad wrote: > > All > I was wondering if anyone could shed some light on this boot panic I > saw yesterday. This is on a Dell R630 with Bios 2.9.1 booting > 12.0-STABLE-r348203 amd64. > I reverted this back to 12.0-RELEASE-p4 and its fine . > > The only

Kernel panic on 12-STABLE-r348203 amd64

All I was wondering if anyone could shed some light on this boot panic I saw yesterday. This is on a Dell R630 with Bios 2.9.1 booting 12.0-STABLE-r348203 amd64. I reverted this back to 12.0-RELEASE-p4 and its fine . The only custom options I had were in loader.conf

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

This morning, RELEASE-p5 came about. I did a freebsd-update without issue. However, as I said, I am running amd64 and not i386 on my server. So there must be something more involved here. ___ freebsd-stable@freebsd.org mailing list

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

Possibly same issue on amd64 server in my VPS but my laptop updated just fine. vm_fault_hold: fault on nofault entry, addr: 0 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

On Wed, 15 May 2019 at 00:03, Ed Maste wrote: > > On Wed, 15 May 2019 at 15:09, wintellect Auser > wrote: > > > > Hi all, > > > > Wanted to make you aware of an issue I have encountered, sorry if this is > > the wrong list. > > This is the right place and thank you for reporting. Looking into

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

On Wed, 15 May 2019 at 15:09, wintellect Auser wrote: > > Hi all, > > Wanted to make you aware of an issue I have encountered, sorry if this is > the wrong list. This is the right place and thank you for reporting. Looking into it. ___

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

> Hi all, > > Wanted to make you aware of an issue I have encountered, sorry if this is > the wrong list. > > I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using: > > freebsd-fetch update > freebsd-fetch install > > and use the GENERIC kernel. Upon reboot the system kernel panics when >

12.0-RELEASE-p4 kernel panic on boot

Hi all, Wanted to make you aware of an issue I have encountered, sorry if this is the wrong list. I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using: freebsd-fetch update freebsd-fetch install and use the GENERIC kernel. Upon reboot the system kernel panics when attempting to mount the

12.0-RELEASE-p4 kernel panic on i386 boot

Hi all, Wanted to make you aware of an issue I have encountered, sorry if this is the wrong list. I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using: freebsd-fetch update freebsd-fetch install and use the GENERIC kernel. Upon reboot the system kernel panics when attempting to mount the

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

Lee Damon wrote on 2019/03/02 01:36: On 3/1/19 15:38 , Miroslav Lachman wrote: Did you tried to boot "safe mode"? (selectable in boot menu). I completely forgot about safe mode. Yep. It boots. I'm going to finish the freebsd-update process then reboot into safe mode again. I'm out of time

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

On 3/1/19 15:38 , Miroslav Lachman wrote: Did you tried to boot "safe mode"? (selectable in boot menu). I completely forgot about safe mode. Yep. It boots. I'm going to finish the freebsd-update process then reboot into safe mode again. I'm out of time to work on this today and am only in

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

Lee Damon wrote on 2019/03/02 00:06: Darn it. I get the same kernel panic with that one. I'm compiling locally but I don't expect that to make any difference. I'll need to go pawing through the release notes and see if there are any references to deprecated hardware that might be involved

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

this kernel instead of default /boot/kernel. Darn it. I get the same kernel panic with that one. I'm compiling locally but I don't expect that to make any difference. I'll need to go pawing through the release notes and see if there are any references to deprecated hardware that might

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

... why isn't the host coming back? Oh look, kernel panic.   Fatal trap 12: page fault while in kernel mode   cpuid = 1; apci id = 01   fault virtual address = 0x84   fault code = supervisor read data, page not present I went back from freebsd-update to source upgrades few years ago and now

more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

that the host is running RELENG the next step was to update from 10.4 to 11.2 via freebsd-update freebsd-update freebsd-install freebsd-update upgrade -r 11.2-RELEASE freebsd-update install so far, so good. Now it all falls apart shutdown -r now ... why isn't the host coming back? Oh look, kernel panic

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 Rodney W. Grimes changed: What|Removed |Added CC|sta...@freebsd.org | --- Comment #15 from Rodney

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #14 from Andrey V. Elsukov --- (In reply to Sergey Anokhin from comment #13) > (In reply to Andrey V. Elsukov from comment #11) > > I'd preferred to try to rebuild kernel if it's no difference between turning > off VIMAGE from

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #13 from Sergey Anokhin --- (In reply to Andrey V. Elsukov from comment #11) I'd preferred to try to rebuild kernel if it's no difference between turning off VIMAGE from kernel config and applying patch because kernel building

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #12 from Sergey Anokhin --- (In reply to Andrey V. Elsukov from comment #9) Sure, now I'm building kernel without VIMAGE. I'll let you know about testing result -- You are receiving this mail because: You are on the CC list

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #11 from Andrey V. Elsukov --- Created attachment 201968 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201968=edit Proposed patch Also, you can test this patch instead, it should fix panic with VIMAGE option. The

[Bug 235684] security/ipsec-tools kernel panic

c.d/racoon onestart Starting racoon. (pts/1)[root@server:~]# /usr/local/etc/rc.d/racoon onestop Stopping racoon. Waiting for PIDS: 5662 kernel panic btw, I've noticed that kernel panic during stopping racoon. # kgdb kernel /var/crash/vmcore.last GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD] Copyright

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #9 from Andrey V. Elsukov --- Can you try to remove `option VIMAGE` from your kernel config? It looks like the problem is similar to the one described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235699 -- You are

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #8 from Sergey Anokhin --- (In reply to Jan Bramkamp from comment #6) Did you mean try to set kern.maxssiz into /boot/loader.conf? -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #7 from Sergey Anokhin --- btw, perhaps it can be helpful: if port security/ipsec-tools was built with default options (make rmconfig), so the bug doesn't reproduced -- You are receiving this mail because: You are on the CC

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 Jan Bramkamp changed: What|Removed |Added CC||cr...@bultmann.eu --- Comment #6

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #5 from Andrey V. Elsukov --- (In reply to Sergey Anokhin from comment #4) > (In reply to Andrey V. Elsukov from comment #3) > > There is a mind that if turn off > > options IPSEC_DEBUG &g

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #4 from Sergey Anokhin --- (In reply to Andrey V. Elsukov from comment #3) There is a mind that if turn off options IPSEC_DEBUG kernel panic will disappear -- You are receiving this mail because: You are on the CC

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #3 from Andrey V. Elsukov --- KEYDBG() macro executed only when net.key.debug is set to non-zero value. It looks like your sysctl.conf didn't set it. Also, it looks impossible to get page fault with fault address 0x28 in this

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 --- Comment #2 from Sergey Anokhin --- (In reply to Andrey V. Elsukov from comment #1) kernel config: (pts/2)[root@server:~]# cat /usr/src/sys/amd64/conf/SERVER # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For

[Bug 235684] security/ipsec-tools kernel panic

#1 from Andrey V. Elsukov --- (In reply to Sergey Anokhin from comment #0) > I see kernel panic during racoon restart. > > # uname -rv > 12.0-STABLE FreeBSD 12.0-STABLE r343904 SERVER Please, show the content of your kernel config and what sysctl variables do you changed aga

[Bug 235684] security/ipsec-tools kernel panic

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684 Sergey Anokhin changed: What|Removed |Added CC||b...@freebsd.org,

[Bug 235683] ZFS kernel panic when access to data or scrub

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683 Sergey Anokhin changed: What|Removed |Added CC||sta...@freebsd.org -- You are

Repeated kernel panic on 11.2-RELEASE-p7

Dear list, After some time, I have again experienced a kernel panic on a (physical) server, running Freebsd 11.2-RELEASE-p7 with custom/debug kernel, ZFS root. Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer= 0x20:0x82299013

Kernel panic going multiuser under 12 ( was Re: More CARP issues under 12 (maybe not CARP after all))

Just to get the subject correct, as I tested this disabling CARP and I still see the panic when going multi-user. It netwprking related as the panic is in the ARP code, and seems to happen when the network interfaces are configured. The machine was using a mix of em and igb interfaces, but

Re: Kernel panic on 11.2-RELEASE-p7

Dear list, About a week ago, we had a kernel panic on Freebsd 11.2-RELEASE-p7 with GENERIC kernel, ZFS root. As the kernel was not compiled with debug support enabled, the resulting "vmcore" files were of little use. Consequently, I recompiled kernel with debug support: --- GENERIC

Re: Kernel panic on 11.2-RELEASE-p7

> > > > On Fri, Dec 28, 2018 at 11:34 AM Andriy Gapon wrote: > >> On 28/12/2018 12:07, Jurij Kovačič via freebsd-stable wrote: >> > Dear list, >> > >> > This morning the server mentioned in my previous e-mail (Freebsd >> > 11.2-RELEASE-p7

Re: Kernel panic on 11.2-RELEASE-p7

, 2018 at 11:34 AM Andriy Gapon wrote: > On 28/12/2018 12:07, Jurij Kovačič via freebsd-stable wrote: > > Dear list, > > > > This morning the server mentioned in my previous e-mail (Freebsd > > 11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another kernel >

Re: Kernel panic on 11.2-RELEASE-p7

On 28/12/2018 12:07, Jurij Kovačič via freebsd-stable wrote: > Dear list, > > This morning the server mentioned in my previous e-mail (Freebsd > 11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another kernel > panic: > > Fatal trap 9: general protection fault

Re: Kernel panic on 11.2-RELEASE-p7

Dear list, This morning the server mentioned in my previous e-mail (Freebsd 11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another kernel panic: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer= 0x20:0x82299013 stack

Kernel panic on 11.2-RELEASE-p7

Dear list, I hope I am posting this to the correct list - if not, I apologize (and please advise where to post this instead). Today I experienced a kernel panic on a (physical) server, running Freebsd 11.2-RELEASE-p7 with GENERIC kernel, ZFS root: Fatal trap 9: general protection fault while

Re: Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

On Thu, 6 Dec 2018 09:38-0800, Navdeep Parhar wrote: > Can you please file a bug at https://bugs.freebsd.org/bugzilla/ and > assign it to me? See PR 233851. -- Trond. ___ freebsd-stable@freebsd.org mailing list

Re: Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

Can you please file a bug at https://bugs.freebsd.org/bugzilla/ and assign it to me? Regards, Navdeep On 12/6/18 4:02 AM, Trond Endrestøl wrote: > After booting stable/12 r341604, running a custom kernel including > cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode: > >

Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

After booting stable/12 r341604, running a custom kernel including cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode: GEOM_ELI: Device gpt/swap0.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: hardware Fatal trap 12: page fault while in kernel mode cpuid =

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

gt;>>> Hi all! > >>>> > >>>> One of out users observed an VNET related kernel panic with epairs > >>>> in > >>>> a jail. Seems like some of the > >>> > >>> Well would be great for a start to (a) email virtualis

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

On 8/3/18, Bjoern A. Zeeb wrote: > On 3 Aug 2018, at 20:42, Oliver Pinter wrote: > >> On 8/3/18, Bjoern A. Zeeb wrote: >>> On 3 Aug 2018, at 18:48, Oliver Pinter wrote: >>> >>>> Hi all! >>>> >>>> One of out users observed an VNE

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

On 3 Aug 2018, at 20:42, Oliver Pinter wrote: On 8/3/18, Bjoern A. Zeeb wrote: On 3 Aug 2018, at 18:48, Oliver Pinter wrote: Hi all! One of out users observed an VNET related kernel panic with epairs in a jail. Seems like some of the Well would be great for a start to (a) email

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

On 8/3/18, Bjoern A. Zeeb wrote: > On 3 Aug 2018, at 18:48, Oliver Pinter wrote: > >> Hi all! >> >> One of out users observed an VNET related kernel panic with epairs in >> a jail. Seems like some of the > > Well would be great for a start to (a) email vi

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

On 3 Aug 2018, at 18:48, Oliver Pinter wrote: Hi all! One of out users observed an VNET related kernel panic with epairs in a jail. Seems like some of the Well would be great for a start to (a) email virtualisation@ as well, (b) include a panic message, backtrace or other related

VNET related kernel panic on jail startup with epairs on 11-STABLE

Hi all! One of out users observed an VNET related kernel panic with epairs in a jail. Seems like some of the vnet related patches does not gets backported to 11-STABLE (they are marked as MFC candidate): SVN r33 and r313168, these are for the panic fix. https://github.com/HardenedBSD

11.2-RC1-i386-bootonly.iso new install kernel panic - solved?

I installed a 11.2-RC1-i386-bootonly.iso on a Pentium 4 desktop test system.There was a double kernel panic, followed by a single kernel panic.On a manual poweroff/power-on (reboot) I edited both:/boot/loader.conf with the code: i915_load="YES"and/etc/rc.conf with code: kld_lis

Re: FreeBSD 11.2-BETA3 Kernel Panic (Page Fault) when loading kernel module "vboxdrv.ko"

See my response of a few minutes ago the another report of this issue. Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org

FreeBSD 11.2-BETA3 Kernel Panic (Page Fault) when loading kernel module "vboxdrv.ko"

Caused by KBI change (Does not kernel panic after rebuild) This problem is reproducible System: FreeBSD 11.2-BETA3 Runs on: Oracle VirtualBox dmesg: (recorded with script(1) + telnet(1)) ===|cut here|=== Script started on Thu May 31 19:49:21 2018 Command: telnet localhost 4997 Trying 127.0.0.1

Re: Kernel Panic of 10.2-RELEASE

> Le 18 juil. 2017 à 18:47, Daniel Genis a écrit : > > Hello, Hello, > Take a look at this commit: https://github.com/freebsd/freebsd/commit/d99ba5c > It might be the issue you're encountering. Yes, it is. Here ’s the corresponding PR :

Re: Kernel Panic of 10.2-RELEASE

t;Jul 18 18:09:40 penitencier kernel: VI_LOCKedlock type zfs: EXCL by >thread 0xf8014f242940 (pid 60698, zfs, tid 100747) >Jul 18 18:09:40 penitencier kernel: panic: vputx: negative ref cnt >Jul 18 18:09:40 penitencier kernel: cpuid = 1 >Jul 18 18:09:40 penitencier kernel: KDB:

Kernel Panic of 10.2-RELEASE

lock type zfs: EXCL by thread 0xf8014f242940 (pid 60698, zfs, tid 100747) Jul 18 18:09:40 penitencier kernel: panic: vputx: negative ref cnt Jul 18 18:09:40 penitencier kernel: cpuid = 1 Jul 18 18:09:40 penitencier kernel: KDB: stack backtrace: Jul 18 18:09:40 penitencier kernel: #0

11.1-RC1 kernel panic (zfs recv)

I've had a kernel crash with 3 different RC1 kernels. kernel: FreeBSD 11.1-RC1 #71 r313908+b08656c3ba28(releng/11.1): Sun Jul 2 23:15:23 PDT 2017 kernel: FreeBSD 11.1-RC1 #72 r313908+64e0abde4c70(releng/11.1): Mon Jul 3 07:43:42 PDT 2017 kernel: FreeBSD 11.1-RC1 #73

Re: Kernel panic

>> On 21. Jun 2017, at 21:56, Steven Hartland <kill...@multiplay.co.uk> o:kill...@multiplay.co.uk>> wrote: >> >> Given how old 9.1 is, even if you did investigate its unlikely it would >> get fixed. >> >> I'd recommend updating to 11

Re: Kernel panic

n 21/06/2017 17:35, Efraín Déctor wrote: Hello. Today one of my servers crashed with a kernel panic. I got this message: panic: cancel_mkdir_dotdot: Lost inodedep I was just moving some files using WinSCP and then the server crashed. How can I trace the root of the problem?. I check and th

Re: Kernel panic

it would get fixed. I'd recommend updating to 11.0-RELEASE and see if the panic still happens. On 21/06/2017 17:35, Efraín Déctor wrote: Hello. Today one of my servers crashed with a kernel panic. I got this message: panic: cancel_mkdir_dotdot: Lost inodedep I was just moving some files

Re: Kernel panic

Given how old 9.1 is, even if you did investigate its unlikely it would get fixed. I'd recommend updating to 11.0-RELEASE and see if the panic still happens. On 21/06/2017 17:35, Efraín Déctor wrote: Hello. Today one of my servers crashed with a kernel panic. I got this message: panic

Kernel panic

Hello. Today one of my servers crashed with a kernel panic. I got this message: panic: cancel_mkdir_dotdot: Lost inodedep I was just moving some files using WinSCP and then the server crashed. How can I trace the root of the problem?. I check and the raid seems to be ok: mfi0 Volumes: Id

Re: Kernel panic in smp rendezvous

> On May 11, 2017, at 3:01 AM, Konstantin Belousov wrote: > > On Wed, May 10, 2017 at 03:29:39PM -0700, Olivier Cinquin wrote: >> Hi, >> I'm getting the following kernel panics on recent 11-STABLE (r317883): >> >> spin lock 0x81df43d0 (smp rendezvous) held by

Re: Kernel panic in smp rendezvous

On Wed, May 10, 2017 at 03:29:39PM -0700, Olivier Cinquin wrote: > Hi, > I'm getting the following kernel panics on recent 11-STABLE (r317883): > > spin lock 0x81df43d0 (smp rendezvous) held by 0xf8019c7a7000 (tid > 100845) too long > timeout stopping cpus > panic: spin lock held too

Re: FreeBSD Vagrant Box Kernel Panic

Hello, > Am 10.05.2017 um 21:24 schrieb Robert Simmons : > It appears that the maintainer of the boxes should create a > 11.0-RELEASE-p10 box and revoke the -p1 box. The official Hashicorp boxes have been invoking freebsd-update on startup for a while, now. So every box

Kernel panic in smp rendezvous

Hi, I'm getting the following kernel panics on recent 11-STABLE (r317883): spin lock 0x81df43d0 (smp rendezvous) held by 0xf8019c7a7000 (tid 100845) too long timeout stopping cpus panic: spin lock held too long cpuid = 12 KDB: stack backtrace: db_trace_self_wrapper() at

FreeBSD Vagrant Box Kernel Panic

I was reading the previous thread about the current Vagrant box for FreeBSD 11.0-STABLE on atlas.hashicorp.com. The broken box is still not updated. Who is the maintainer of these boxes? On a side note, the reason freebsd/FreeBSD-11.0-RELEASE is revoked is there is a newer -p1 box:

Re: Kernel panic on production system - what now?

On 03/24/2017 03:28, Patrick M. Hausen wrote: > Hi all, > > Mar 24 02:39:36 ph001 kernel: kernel trap 12 with interrupts disabled > Mar 24 02:39:36 ph001 kernel: > Mar 24 02:39:36 ph001 kernel: > Mar 24 02:39:36 ph001 kernel: Fatal trap 12: page fault while in kernel mode > Mar 24 02:39:37

Kernel panic on production system - what now?

Hi all, Mar 24 02:39:36 ph001 kernel: kernel trap 12 with interrupts disabled Mar 24 02:39:36 ph001 kernel: Mar 24 02:39:36 ph001 kernel: Mar 24 02:39:36 ph001 kernel: Fatal trap 12: page fault while in kernel mode Mar 24 02:39:37 ph001 kernel: cpuid = 8; apic id = 08 Mar 24 02:39:37 ph001

Re: unionfs or tmpfs Kernel Panic on 10.2-BETA1

On Sat, Jul 18, 2015 at 11:54:59AM -0400, Shawn Webb wrote: Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at revision bf2d0b176566519b95f21d01cc101f4b60247ab8 in this repo: https://github.com/HardenedBSD/hardenedBSD/tree/hardened/experimental/opnsense-10-stable === Begin

unionfs or tmpfs Kernel Panic on 10.2-BETA1

Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at revision bf2d0b176566519b95f21d01cc101f4b60247ab8 in this repo: https://github.com/HardenedBSD/hardenedBSD/tree/hardened/experimental/opnsense-10-stable === Begin Log === Trying to mount root from

Re: unionfs or tmpfs Kernel Panic on 10.2-BETA1

On Saturday, 18 July 2015 09:12:52 David Wolfskill wrote: On Sat, Jul 18, 2015 at 11:54:59AM -0400, Shawn Webb wrote: Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at revision bf2d0b176566519b95f21d01cc101f4b60247ab8 in this repo:

Re: unionfs or tmpfs Kernel Panic on 10.2-BETA1

On Saturday, 18 July 2015 12:24:37 Shawn Webb wrote: On Saturday, 18 July 2015 09:12:52 David Wolfskill wrote: On Sat, Jul 18, 2015 at 11:54:59AM -0400, Shawn Webb wrote: Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at revision bf2d0b176566519b95f21d01cc101f4b60247ab8

Re: 10.1 NVMe kernel panic

On Thu, May 21, 2015 at 8:33 AM, Sean Kelly smke...@smkelly.org wrote: Greetings. I have a Dell R630 server with four of Dell’s 800GB NVMe SSDs running FreeBSD 10.1-p10. According to the PCI vendor, they are some sort of rebranded Samsung drive. If I boot the system and then load nvme.ko and

Re: 10.1 NVMe kernel panic

Jim, Thanks for the reply. I set hw.nvme.force_intx=1 and get a new form of kernel panic: http://smkelly.org/stuff/nvme_crash_force_intx.txt http://smkelly.org/stuff/nvme_crash_force_intx.txt It looks like the NVMes are just failing to initialize at all now. As long as that tunable

10.1 NVMe kernel panic

Greetings. I have a Dell R630 server with four of Dell’s 800GB NVMe SSDs running FreeBSD 10.1-p10. According to the PCI vendor, they are some sort of rebranded Samsung drive. If I boot the system and then load nvme.ko and nvd.ko from a command line, the drives show up okay. If I put

Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

, I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause a kernel panic. For example a simple command like the following causes a panic: zpool create /tmp/zfstut/disk1 This issue

Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

this back in November, but I don't seem to have had a reply so I'll chase. On 21/04/2015 16:23, Will Green wrote: Hello, I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause a kernel panic

File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

Hello, I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause a kernel panic. For example a simple command like the following causes a panic: zpool create /tmp/zfstut/disk1 This issue

Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

they cause a kernel panic. For example a simple command like the following causes a panic: zpool create /tmp/zfstut/disk1 This issue was identified in PR 195061: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 And fixed in r274619 (2014-11-17): https://svnweb.freebsd.org/base?view

Kernel Panic on vm_page_insert

to perform a build world. My system is also an AMD64. Sep 28 05:47:48 host kernel: panic: vm_page_insert: offset already allocated Sep 28 05:47:48 host kernel: cpuid = 1 Sep 28 05:47:48 host kernel: KDB: stack backtrace: Sep 28 05:47:48 host kernel: #0 0x80489c66 at kdb_backtrace+0x66

RE: kernel panic: ffs_valloc: dup alloc

To: freebsd-stable@freebsd.org; andriy.kornats...@live.com Subject: Re: kernel panic: ffs_valloc: dup alloc Date: Mon, 13 May 2013 14:14:09 +0200 From: ronald-freeb...@klop.yi.org On Mon, 13 May 2013 11:10:04 +0200, Andriy Kornatskyy andriy.kornats...@live.com wrote

kernel panic: ffs_valloc: dup alloc

The core.txt and info files can be found in attached archive. If you need vmcore, just let me know where I can upload it. ASUS K73E Architecture: i386 OS: FreeBSD 9.1-RELEASE-p3 Please let me know should you need some other information. Thanks. Andriy

kernel panic: ffs_valloc: dup alloc

The core.txt and info files can be found in attached archive (there are 2 crash reports there). If you need vmcores, just let me know where I can upload them. ASUS K73E Architecture: i386 OS: FreeBSD 9.1-RELEASE-p3 Please let me know should you need some other information. Thanks. Andriy

Re: kernel panic: ffs_valloc: dup alloc

On Mon, 13 May 2013 11:10:04 +0200, Andriy Kornatskyy andriy.kornats...@live.com wrote: The core.txt and info files can be found in attached archive (there are 2 crash reports there). If you need vmcores, just let me know where I can upload them. ASUS K73E Architecture: i386 OS: FreeBSD

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

On Monday, April 01, 2013 12:29:46 pm Xin Li wrote: Yes, this is a bandaid and the right fix should be refactor the code a little bit to make sure that no interrupt handler is installed before the driver have done other initializations but I don't have hardware that can reproduce this issue

9.1-REL Supermicro H8DCL-iF kernel panic

This has been brought up before for a different board, none specifically mentioned this one nor the if_em driver (it was if_igb before on a X8DTU-6+ board). References: http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4/1/13 12:04 AM, Ryan McIntosh wrote: This has been brought up before for a different board, none specifically mentioned this one nor the if_em driver (it was if_igb before on a X8DTU-6+ board). References:

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

I could try that patch, however that was intended for if_igb.c which for my system (and the panic's are almost identical except if_em for me) I'd have to apply that fix to if_em.c and I haven't looked at the source just yet. If you can give me a patch I'll do apply and test it shortly though.

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4/1/13 12:34 AM, Ryan McIntosh wrote: I could try that patch, however that was intended for if_igb.c which for my system (and the panic's are almost identical except if_em for me) I'd have to apply that fix to if_em.c and I haven't looked at

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

I can confirm that works as intended. I appreciate the prompt response and it looks like there's a real fix. For google reference for anyone else searching.. Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE Boot message: panic: m_getzone: m_getjcl: invalid cluster type cpuid = 0 KBD:

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote: I can confirm that works as intended. I appreciate the prompt response and it looks like there's a real fix. For google reference for anyone else searching.. Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE Boot

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4/1/13 5:25 AM, Jeremy Chadwick wrote: On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote: I can confirm that works as intended. I appreciate the prompt response and it looks like there's a real fix. For google reference for

  1   2   3   4   5   6   7   >