This also happens on Qemu with UEFI.
—
Rebecca
(Apologies for top posting, I’m replying on my phone)
On August 14, 2018 at 10:04:53 AM, Michael Tuexen
(tue...@freebsd.org(mailto:tue...@freebsd.org)) wrote:
> Dear all,
>
> r337761 panics on boot with a GENERIC kernel on a EPYC system:
>
>
On Tue, Aug 14, 2018 at 11:04 AM, Michael Tuexen wrote:
> Dear all,
>
> r337761 panics on boot with a GENERIC kernel on a EPYC system:
Oy. =(
> [...]
> panic: mutex pmap not owned at ../../../amd64/amd64/efirt_machdep.c:268
> [...]
>
> Any idea what is wrong?
>
Ah, this should be fixed by
> On 14. Aug 2018, at 17:09, Kyle Evans wrote:
>
> On Tue, Aug 14, 2018 at 11:04 AM, Michael Tuexen wrote:
>> Dear all,
>>
>> r337761 panics on boot with a GENERIC kernel on a EPYC system:
>
> Oy. =(
>
>> [...]
>> panic: mutex pmap not owned at ../../../amd64/amd64/efirt_machdep.c:268
>>
On 8/12/18 9:50 AM, Honda Michio wrote:
> Hi,
>
> I'm measuring TCP server app performance using my toy web server.
> It just accept TCP connections and responds back HTTP OK to the clients.
> It monitors sockets using kqueue, and processes each ready descriptor using
> a pair of read() and
Hello,
context: amd64, FreeBSD 12.0-ALPHA1 #0 r337682, ZFS. The system is *not*
root-on-zfs. It boots to an SSD. The three disks indicated below are
spinning rust.
NAMESTATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz1-0 ONLINE 0
Ok missed the solution posted earlier: adding ' efi.rt.disabled=1' to
loader.conf fixed the issue for me as well
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
On Tue, Aug 14, 2018 at 3:00 PM, Matthias Gamsjager
wrote:
> Ok missed the solution posted earlier: adding ' efi.rt.disabled=1' to
> loader.conf fixed the issue for me as well
Is your kernel up to r337773 yet? That should have addressed the EFIRT
boot issue.
Thanks,
Kyle Evans
> Is your kernel up to r337773 yet? That should have addressed the EFIRT
> boot issue.
>
>
Rebuilding now. Not sure how late I started so I might have missed it.
___
freebsd-current@freebsd.org mailing list
Hi list,
just compiled current and after reboot into the new kernel the machine
reboots itself at the marked line below. No further info as the reset is
sudden. Reboot with the old kernel from 12 aug works. Removed all kernel
modules but with no result.
Any pointers how to approach this?
Aug 14
On 8/14/18, Matthias Gamsjager wrote:
> Hi list,
>
> just compiled current and after reboot into the new kernel the machine
> reboots itself at the marked line below. No further info as the reset is
> sudden. Reboot with the old kernel from 12 aug works. Removed all kernel
> modules but with no
Hi
Something that we have seen for a long time on FreeBSD is the boot message
Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance may
suffer
Taking a closer look at this with memcontrol I can see that the 256 MB
region that DRM wants to set as WC is already covered by this entry
If you use UEFI boot, have EFIRT compiled in kernel (the case of
GENERIC) or pre-loaded as module, and efirt is not disabled by a tunable,
and the machine resets during kernel initialization, try this.
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index d5d795ab502..c9334eab916
On Tue, Aug 14, 2018 at 3:39 PM Konstantin Belousov
wrote:
> On Tue, Aug 14, 2018 at 08:55:36AM -0500, Eric van Gyzen wrote:
> > On 8/14/18 4:12 AM, Johannes Lundberg wrote:
> > > Hi
> > >
> > > Something that we have seen for a long time on FreeBSD is the boot
> message
> > >
> > > Failed to
On Wed, 6 Jun 2018 01:06:25 +0200
Michael Gmelin wrote:
> On Tue, 5 Jun 2018 16:11:35 +0300
> Konstantin Belousov wrote:
>
> > On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote:
> > >
> > >
> > > On Mon, 4 Jun 2018 14:06:55 +0300
> > > Konstantin Belousov wrote:
> > >
Hi!
Seems like this patch fixed the boot issue on Dell e5440 with UEFI.
Once you get to MFC, please X-MFC-with the following patch:
commit dfe1112fa878c5d8fa0605d1de10c96ecc993569
Author: rlibby
Date: Fri Jul 21 17:11:36 2017 +
__pcpu: gcc -Wredundant-decls
Pollution from
> On 14 Aug 2018, at 22:37, tech-lists wrote:
>
> Hello,
>
> context: amd64, FreeBSD 12.0-ALPHA1 #0 r337682, ZFS. The system is *not*
> root-on-zfs. It boots to an SSD. The three disks indicated below are spinning
> rust.
>
> NAMESTATE READ WRITE CKSUM
> storage
howdy,
running code from today and having lots of issues. when i boot the
system (a kabylake laptop) using legacy mode in the BIOS i see lots of
these errors are thrown in dmesg:
acpi0: on motherboard
Firmware Error (ACPI): Failure creating
[\134_SB.PCI0.XHC.RHUB.HS01._UPC],
On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote:
> i also attempted to boot using UEFI but the system hangs very early in the
> boot process. i have reverted to legacy mode for now so that i can work,
> but am keen to test out any patches or do any other debugging that is
> needed.
Hi Pete,
On 14/08/2018 21:16, Toomas Soome wrote:
On 14 Aug 2018, at 22:37, tech-lists wrote:
Hello,
context: amd64, FreeBSD 12.0-ALPHA1 #0 r337682, ZFS. The system is
*not* root-on-zfs. It boots to an SSD. The three disks indicated
below are spinning rust.
NAMESTATE READ WRITE CKSUM
On 8/14/18 6:13 PM, Kyle Evans wrote:
On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote:
i also attempted to boot using UEFI but the system hangs very early in the
boot process. i have reverted to legacy mode for now so that i can work,
but am keen to test out any patches or do any other
On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright wrote:
>
> On 8/14/18 6:13 PM, Kyle Evans wrote:
>>
>> On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote:
>>>
>>> i also attempted to boot using UEFI but the system hangs very early in
>>> the
>>> boot process. i have reverted to legacy mode for
On Tue, Aug 14, 2018 at 10:56 PM, Pete Wright wrote:
>
> On 8/14/18 8:45 PM, Kyle Evans wrote:
>>
>> On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright wrote:
>>>
>>> On 8/14/18 6:13 PM, Kyle Evans wrote:
On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright
wrote:
>
> i also attempted
On 8/14/18 9:01 PM, Kyle Evans wrote:
I'm curious if you've been bitten somehow by recently enabling EFIRT
in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and
see where that gets you?
i did attempt to set that in loader.conf - and it progressed farther but
kernel panic'd
On 8/14/18 9:06 PM, Pete Wright wrote:
On 8/14/18 9:01 PM, Kyle Evans wrote:
I'm curious if you've been bitten somehow by recently enabling EFIRT
in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and
see where that gets you?
i did attempt to set that in loader.conf - and
On 12/08/2018 18:53, Cy Schubert wrote:
I haven't looked at it closely but from what I saw it was counting scan reads
and issued reads. It may be a simple matter of dividing by 2.
Dividing what by 2?
scan: scrub in progress since Tue Aug 7 21:21:51 2018
804G scanned at 163M/s, 1,06T
In message <93818fab-6b53-bade-dffa-afcf322dc...@zyxst.net>, tech-lists
writes:
> On 12/08/2018 18:53, Cy Schubert wrote:
> > I haven't looked at it closely but from what I saw it was counting scan rea
> ds and issued reads. It may be a simple matter of dividing by 2.
>
> Dividing what by 2?
>
>
On 8/14/18 8:45 PM, Kyle Evans wrote:
On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright wrote:
On 8/14/18 6:13 PM, Kyle Evans wrote:
On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote:
i also attempted to boot using UEFI but the system hangs very early in
the
boot process. i have reverted to
On Tue, 14 Aug 2018 20:41:03 -0700
Pete Wright wrote:
> On 8/14/18 6:13 PM, Kyle Evans wrote:
> > On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote:
> >> i also attempted to boot using UEFI but the system hangs very early in the
> >> boot process. i have reverted to legacy mode for now so
I never have /usr/src on my system (other than the directory that mtree
creates). So when I run mergemaster it's always failing until I remember to
add the -m . (or was it -t ., I sometimes forget).
Given the recent ntpd stuff, I was annoyed enough with this default
behavior to create a fix for
On Tue, Aug 14, 2018 at 08:55:36AM -0500, Eric van Gyzen wrote:
> On 8/14/18 4:12 AM, Johannes Lundberg wrote:
> > Hi
> >
> > Something that we have seen for a long time on FreeBSD is the boot message
> >
> > Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance may
> > suffer
> >
On 8/14/18 4:12 AM, Johannes Lundberg wrote:
Hi
Something that we have seen for a long time on FreeBSD is the boot message
Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance may
suffer
Taking a closer look at this with memcontrol I can see that the 256 MB
region that DRM
On Mon, Aug 13, 2018 at 09:53:22PM -0400, Michael Butler wrote:
> non-SMP builds apparently don't define some required structures ..
Thanks, this should be fixed by r337751.
___
freebsd-current@freebsd.org mailing list
Dear all,
r337761 panics on boot with a GENERIC kernel on a EPYC system:
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered
33 matches
Mail list logo
