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 j
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
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
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.
>
> NewFS.denninger.ne
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 15
= 1
>>> 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
n the loader works. 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
t ??+0
> #3 0x80f0b03c 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 0x
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 custo
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
kern.geom.label.gptid.enable
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
https://lists.freebsd.o
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 m
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 it
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.
___
freebsd-stable@fr
> 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
> attempt
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 filesys
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 filesys
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 to
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 th
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 mi
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 hardwar
r now
... 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 a
t 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, ke
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 W.
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
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
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 f
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&action=edit
Proposed patch
Also, you can test this patch instead, it should fix panic with VIMAGE option.
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]
Copy
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 rece
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.
__
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 li
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
Jan Bramkamp changed:
What|Removed |Added
CC||cr...@bultmann.eu
--- Comment #6 fr
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
>
&
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
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 li
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 mo
#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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684
Sergey Anokhin changed:
What|Removed |Added
CC||b...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683
Sergey Anokhin changed:
What|Removed |Added
CC||sta...@freebsd.org
--
You are re
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
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
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
>
>
>
> 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
, 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
>
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
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
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 in
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
https://lists.freebsd.org/mailman/listi
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:
>
> GEOM_ELI
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 = 3
>>> 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
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
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
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 virt
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
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
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
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 m
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
> 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 :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2074
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: stack backtrace:
>Jul 18 18:
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
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 r313908+ff3a058c4f83(releng
56, Steven Hartland > 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.0-RELEASE and see if the panic still happens.
>>
>> On 2
raí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 the raid seems to be ok:
mfi0 Vo
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 using WinSCP and then the ser
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:
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
> 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 0xf8019c7a7000
>> (tid
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
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 automatically updates itse
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 db_trace_self_
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:
https://atlas.h
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 ph001
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 kerne
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 bf2d0b176566519b95f21d01cc101f4b60
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:
> >
> > https://github.com/HardenedBSD/
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
>
> ===
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 ufs:/dev/ufs/HardenedBSD_Install
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
On Thu, May 21, 2015 at 8:33 AM, Sean Kelly 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
> nvd.ko from
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
nvm
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.
For example a simp
ote:
>> 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 ca
eeBSD 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 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
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 was
ing when I went 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_back
> 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
> wrote:
&
On Mon, 13 May 2013 11:10:04 +0200, Andriy Kornatskyy
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 9.1-RELEASE-p3
Please let
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
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___
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
I had to get some sleep lol. Yes Jeremy, I do completely understand that
and likewise FreeBSD was unusable without any type of semi-hack fix, let
alone fixing it properly, as without msix the system was pretty slow. If
you'd like access or are up for trying to fix the driver I'm all for being
a gui
On Mon, Apr 01, 2013 at 09:29:46AM -0700, Xin Li wrote:
> -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
> >> respo
-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
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
>
>
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: sta
-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
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.
Ryan
1 - 100 of 653 matches
Mail list logo
