Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Julian Elischer]

On 10/8/19 4:22 PM, Ryan Stone wrote:

I haven't found any good references on the subject, but here's my understanding:

- epoch_enter() and epoch_exit() are very inexpensive operations
(cheaper than mtx, rw_lock or rm_lock operations) that are use to mark
read-only critical sections
- epoch_wait() guarantees that no threads that were in the critical
section when it was first called are still in the critical section
when it completes

With this guarantee, you can safely destroy an object with the
following procedure:

1. Atomically remove all global pointers to the object (e.g. remove it
from any lists that the critical sections might look it up in).  This
must be done atomically because read-only threads can be concurrently
running in the critical section.  This guarantees that no more threads
can get a pointer to it.
2. Call epoch_wait() to drain all threads that already held pointers
to it before step 1.
3. You now hold the only pointer to the object, so you are free to
destroy it as you please.


Ok thanks. Gottit.  thanks for the description.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: memstick installer doesn't install loader.efi into ESP

[Yuri Pankov]

On 10/8/2019 9:07 AM, Yuri Pankov wrote:

On Mon, Oct 7, 2019, at 5:23 AM, Yuri Pankov wrote:

Just tried reinstalling the system on my laptop using the latest
available memstick snapshot
(https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20191004-r353072-memstick.img),
using UEFI boot, and default ZFS partitioning, and it didn't boot after
installation.  Booting into the installer again, I noticed that ESP is
empty.

Reinstalling again after wiping pool labels and clearing partitions
didn't change anything, though I noticed the "/tmp/bsdinstall-esps: no
such file or directory" in the installer log.

Mounting ESP, creating EFI/FreeBSD/ directory, copying /boot/loader.efi
there, and creating appropriate Boot variable solves it, of course, but
I'm wondering what have gone wrong.

Laptop has NVMe drive (nvd0, empty, gpart destroy -F nvd0), SATA drive
(ada0, empty, gpart destroy -F ada0), and is booting from USB memstick
(da0); no Boot variables defined when booting to installer (other than
defaults ones for laptop).  Any other details I should provide here?


I think I see the problem, bootconfig script uses ZFSBOOT_DISKS variable that 
isn't defined and always empty and auto-detection must be unreliable in some 
cases, at least for me as I reproduced it on another system with NVMe device 
adding a SATA disk as well (didn't look into the details).  Should be easy to 
fix, review incoming.


https://reviews.freebsd.org/D21930
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Ryan Stone]

I haven't found any good references on the subject, but here's my understanding:

- epoch_enter() and epoch_exit() are very inexpensive operations
(cheaper than mtx, rw_lock or rm_lock operations) that are use to mark
read-only critical sections
- epoch_wait() guarantees that no threads that were in the critical
section when it was first called are still in the critical section
when it completes

With this guarantee, you can safely destroy an object with the
following procedure:

1. Atomically remove all global pointers to the object (e.g. remove it
from any lists that the critical sections might look it up in).  This
must be done atomically because read-only threads can be concurrently
running in the critical section.  This guarantees that no more threads
can get a pointer to it.
2. Call epoch_wait() to drain all threads that already held pointers
to it before step 1.
3. You now hold the only pointer to the object, so you are free to
destroy it as you please.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Matthew Macy]

On Tue, Oct 8, 2019 at 15:01 Julian Elischer  wrote:

> On 10/8/19 2:42 PM, Walter Parker wrote:
> > See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time
>
> but I was refering to the new "epoch" faciity in the kernel..  ( man 9
> epoch  )




That’s what one would assume given that the thread started with a panic in
said system. Epoch is built on concurrency kit’s EBR implementation. Hence
the link I shared.


>
>
> https://www.freebsd.org/cgi/man.cgi?query=epoch=0=9=FreeBSD+13-current=default=html
>
>
> >
> >
> > Walter
> >
> > On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer  > > wrote:
> >
> > Is there a paper or good description of the epoch concept? (more
> > readable than epoch(9)).
> > Haven't been to enough BSD confs recently.
> >
> > julian
> > ___
> > freebsd-current@freebsd.org 
> > mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org
> > "
> >
> >
> >
> > --
> > The greatest dangers to liberty lurk in insidious encroachment by
> > men of zeal, well-meaning but without understanding.   -- Justice
> > Louis D. Brandeis
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Julian Elischer]

On 10/8/19 2:42 PM, Walter Parker wrote:

See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time


but I was refering to the new "epoch" faciity in the kernel..  ( man 9 
epoch  )


https://www.freebsd.org/cgi/man.cgi?query=epoch=0=9=FreeBSD+13-current=default=html





Walter

On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer > wrote:


Is there a paper or good description of the epoch concept? (more
readable than epoch(9)).
Haven't been to enough BSD confs recently.

julian
___
freebsd-current@freebsd.org 
mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org
"



--
The greatest dangers to liberty lurk in insidious encroachment by 
men of zeal, well-meaning but without understanding.   -- Justice 
Louis D. Brandeis



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Julian Elischer]

On 10/8/19 2:45 PM, Matthew Macy wrote:



On Tue, Oct 8, 2019 at 14:42 Walter Parker > wrote:


See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time



Unrelated.
http://concurrencykit.org/slides.html

And see also Keir Fraser’s thesis where the idea originated.


Walter

On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer
mailto:jul...@freebsd.org>> wrote:

> Is there a paper or good description of the epoch concept? (more
> readable than epoch(9)).
> Haven't been to enough BSD confs recently.
>
> julian
> ___
> freebsd-current@freebsd.org
 mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org
"
>


-- 
The greatest dangers to liberty lurk in insidious encroachment

by men of
zeal, well-meaning but without understanding.   -- Justice Louis
D. Brandeis
___
freebsd-current@freebsd.org 
mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org
"


thanks for the answers


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Matthew Macy]

On Tue, Oct 8, 2019 at 14:42 Walter Parker  wrote:

> See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time
>
>

Unrelated.
http://concurrencykit.org/slides.html

And see also Keir Fraser’s thesis where the idea originated.

>
> Walter
>
> On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer  wrote:
>
> > Is there a paper or good description of the epoch concept? (more
> > readable than epoch(9)).
> > Haven't been to enough BSD confs recently.
> >
> > julian
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
>
>
> --
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding.   -- Justice Louis D.
> Brandeis
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Walter Parker]

See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time


Walter

On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer  wrote:

> Is there a paper or good description of the epoch concept? (more
> readable than epoch(9)).
> Haven't been to enough BSD confs recently.
>
> julian
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Julian Elischer]

Is there a paper or good description of the epoch concept? (more 
readable than epoch(9)).

Haven't been to enough BSD confs recently.

julian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DRM (i915kms) panic on r353303

[Mateusz Guzik]

Thanks for testing.

On 10/8/19, M - Krasznai András  wrote:
> Hi
>
> after the patch my X server on FreeBSD-13 works again, thanks!
>
> best regards
>
> András Krasznai
>
> -Eredeti üzenet-
> Feladó: owner-freebsd-curr...@freebsd.org
> [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Mateusz Guzik
> Küldve: 2019. október 8. 15:15
> Címzett: Renato Botelho
> Másolatot kap: freebsd-current
> Tárgy: Re: DRM (i915kms) panic on r353303
>
> Try this:
>
> https://people.freebsd.org/~mjg/pmap-nosparse.diff
>
> On 10/8/19, Renato Botelho  wrote:
>> I'm not sure which revision I was before it broke.  I can try to bisect
>> if necessary.
>>
>> I'm getting a panic as you can see on these pictures [1] after I
>> upgraded my ThinkPad x230 to r353303.
>>
>> drm-current-kmod is in the last version and I already tried to rebuild
>> it just to be sure.
>>
>> Any help would be much appreciated.
>>
>> [1] https://imgur.com/a/JmZ4uTv
>> --
>> Renato Botelho
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org"
>>
>
>
> --
> Mateusz Guzik 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>


-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: DRM (i915kms) panic on r353303

[M - Krasznai András]

Hi

after the patch my X server on FreeBSD-13 works again, thanks!

best regards

András Krasznai

-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Mateusz Guzik
Küldve: 2019. október 8. 15:15
Címzett: Renato Botelho
Másolatot kap: freebsd-current
Tárgy: Re: DRM (i915kms) panic on r353303

Try this:

https://people.freebsd.org/~mjg/pmap-nosparse.diff

On 10/8/19, Renato Botelho  wrote:
> I'm not sure which revision I was before it broke.  I can try to bisect
> if necessary.
>
> I'm getting a panic as you can see on these pictures [1] after I
> upgraded my ThinkPad x230 to r353303.
>
> drm-current-kmod is in the last version and I already tried to rebuild
> it just to be sure.
>
> Any help would be much appreciated.
>
> [1] https://imgur.com/a/JmZ4uTv
> --
> Renato Botelho
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>


-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DRM (i915kms) panic on r353303

[Renato Botelho]

On 08/10/19 10:15, Mateusz Guzik wrote:
> Try this:
> 
> https://people.freebsd.org/~mjg/pmap-nosparse.diff

It fixed the problem here.

Thanks for the quick reply!
-- 
Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DRM (i915kms) panic on r353303

[Mateusz Guzik]

Try this:

https://people.freebsd.org/~mjg/pmap-nosparse.diff

On 10/8/19, Renato Botelho  wrote:
> I'm not sure which revision I was before it broke.  I can try to bisect
> if necessary.
>
> I'm getting a panic as you can see on these pictures [1] after I
> upgraded my ThinkPad x230 to r353303.
>
> drm-current-kmod is in the last version and I already tried to rebuild
> it just to be sure.
>
> Any help would be much appreciated.
>
> [1] https://imgur.com/a/JmZ4uTv
> --
> Renato Botelho
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>


-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

DRM (i915kms) panic on r353303

[Renato Botelho]

I'm not sure which revision I was before it broke.  I can try to bisect
if necessary.

I'm getting a panic as you can see on these pictures [1] after I
upgraded my ThinkPad x230 to r353303.

drm-current-kmod is in the last version and I already tried to rebuild
it just to be sure.

Any help would be much appreciated.

[1] https://imgur.com/a/JmZ4uTv
-- 
Renato Botelho

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[David Wolfskill]

This was on my laptop (build machine, which was updated in parallel,
but uses a different NIC, had no issues) after a src update from
r353176 to r353298; laptop's NIC is wlan(4) (which is iwn(4), in
this case).

The ddb "dump" command recorded a dump, which I managed to capture; the
information may be found at
http://www.catwhisker.org/~david/FreeBSD/head/r353298/

Here's the backtrace (from
http://www.catwhisker.org/~david/FreeBSD/head/r353298/core.txt.0):

panic: Assertion in_epoch(net_epoch_preempt) failed at 
/usr/src/sys/net/if.c:3694
cpuid = 3
time = 1570535588
KDB: stack backtrace:
db_trace_self_wrapper() at 0x8049ebab = 
db_trace_self_wrapper+0x2b/frame 0xfe103196a8b0
vpanic() at 0x80b979bd = vpanic+0x19d/frame 0xfe103196a900
panic() at 0x80b97753 = panic+0x43/frame 0xfe103196a960
if_delmulti_ifma_flags() at 0x80ca9231 = 
if_delmulti_ifma_flags+0x141/frame 0xfe103196a990
inm_release_task() at 0x80d3211c = inm_release_task+0x1ac/frame 
0xfe103196a9f0
gtaskqueue_run_locked() at 0x80be1c59 = 
gtaskqueue_run_locked+0xf9/frame 0xfe103196aa40
gtaskqueue_thread_loop() at 0x80be1a18 = 
gtaskqueue_thread_loop+0x88/frame 0xfe103196aa70
fork_exit() at 0x80b55714 = fork_exit+0x84/frame 0xfe103196aab0
fork_trampoline() at 0x8101f28e = fork_trampoline+0xe/frame 
0xfe103196aab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic


I was unable to boot from (yesterday's) kernel.old -- loader whined
something about a header mismatch (I think -- there was a fair bit
of text-overwriting).  I was able to extract the dump by rebooting
from the same kernel, but disabling the NIC first, then switching
to a vty, logging in, and I managed to run "sync" a few times before
it panicked again.

I expect that for tomorrow, I'll end up "cloning" the stable/12
slice over the top of the head slice, then upgrade from stable/12
to head again.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
I am amazed that anyone would condone what Trunp has publicly admitted he did.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

[Sergey Kandaurov]

On Mon, Oct 07, 2019 at 09:48:16AM -0700, John Baldwin wrote:
> On 9/25/19 10:33 AM, Sergey Kandaurov wrote:
> > 
> > Index: lib/libsysdecode/mktables
> > ===
> > --- lib/libsysdecode/mktables   (revision 352685)
> > +++ lib/libsysdecode/mktables   (working copy)
> > @@ -157,7 +157,7 @@
> >  gen_table "sigcode" "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"   
> > "sys/signal.h"
> >  gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"   
> > "sys/umtx.h"
> >  gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"
> > "sys/umtx.h"
> > -gen_table "caprights"   
> > "CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"   
> > "sys/capsicum.h"
> > +gen_table "caprights"   
> > "CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"   
> > "sys/capsicum.h"
> >  gen_table "sctpprpolicy""SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+" 
> > "netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
> >  gen_table "cmsgtypesocket"  "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"  
> > "sys/socket.h"
> >  if [ -e "${include_dir}/x86/sysarch.h" ]; then
> 
> CAP_SEEK and CAP_MMAP_X might also be subject to this.  However, I'm not quite
> understanding the regex, or at least why the modified portion of the regex 
> isn't
> something like this:
> 
> (CAPRIGHT\(|\(CAP_LOOKUP)

This won't match against CAP_LOOKUP on the right side, as in CAP_FSTATAT,
but since it is built from CAP_FSTAT and CAP_LOOKUP, it should be fine still.

> That is, you currently have [()A-Z_|[:space:]]+ for an expression that I think
> will only ever match a single '(' character.

All this sad magic is for preceding characters before CAP_LOOKUP,
such as in "(CAP_FSTAT | CAP_LOOKUP".  But seems it isn't needed.

> A more general form that might work for CAP_SEEK and CAP_MMAP_X might be
> to match on 'CAP_ | 0x 
> (CAPRIGHT\(|\([^)]*CAP_[A-Z_]+ \| 0x[0-9]+)

Given the above, it looks fine.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on boot with r353298 (last known working r35295)

[Gary Jennejohn]

On Tue, 8 Oct 2019 09:23:30 +
M - Krasznai Andr__s  wrote:

> Hi
> 
> r353298 running on lenovo T510. Panics after starting X session, the panic is
> 
> panic: vm_fault, fault on nofault entry, addr: 0xfe00821a000
> 
> It is preceded by several error messages referring to 
> 
> drm_modeset_is_locked  failed at 
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm_atomic_helper.c:577. 
> then line 622 and then line 821 of the same 
> drm_atomic_helper.c module.
> 
> 
> best regards
> 
> Andras Krasznai
> 
> -Eredeti __zenet-
> Felad__: owner-freebsd-curr...@freebsd.org 
> [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmaz__ Evilham
> K__ldve: 2019. okt__ber 8. 11:00
> C__mzett: FreeBSD Current
> T__rgy: Panic on boot with r353298 (last known working r35295)
> 
> Hey, just a heads up that on a Lenovo A485 (AMD Ryzen processor), 
> r353298 panics somewhat late in the boot process. r352925 is my 
> last known working build.
> I am building GENERIC-NODEBUG.
> 
> Sadly my pulse is shaky and I can't properly read the picture I 
> took, it appears to say:
> 
> Fatal trap 32: page fault while in kernel mode
> *something, something*
> fault mode = supervisor read data, page not present
> 
> Will try to get more details and a proper dump when I have some 
> time off (hopefully later today), just thought I'd warn before.
>

Works for me with a first-generation Ryzen 5 (but in a tower, not
a laptop) and I use a graphics card from Nvidia.

X11 also starts without errors, but I use nvidia-driver and not
drm-current-kmod.

Maybe recompiling drm-current-kmod would help.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Panic on boot with r353298 (last known working r35295)

[M - Krasznai András]

Hi

r353298 running on lenovo T510. Panics after starting X session, the panic is

panic: vm_fault, fault on nofault entry, addr: 0xfe00821a000

It is preceded by several error messages referring to 

drm_modeset_is_locked  failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm_atomic_helper.c:577. 
then line 622 and then line 821 of the same 
drm_atomic_helper.c module.


best regards

Andras Krasznai

-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Evilham
Küldve: 2019. október 8. 11:00
Címzett: FreeBSD Current
Tárgy: Panic on boot with r353298 (last known working r35295)

Hey, just a heads up that on a Lenovo A485 (AMD Ryzen processor), 
r353298 panics somewhat late in the boot process. r352925 is my 
last known working build.
I am building GENERIC-NODEBUG.

Sadly my pulse is shaky and I can't properly read the picture I 
took, it appears to say:

Fatal trap 32: page fault while in kernel mode
*something, something*
fault mode = supervisor read data, page not present

Will try to get more details and a proper dump when I have some 
time off (hopefully later today), just thought I'd warn before.
--
Evilham
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic on boot with r353298 (last known working r35295)

[Evilham]

Hey, just a heads up that on a Lenovo A485 (AMD Ryzen processor), 
r353298 panics somewhat late in the boot process. r352925 is my 
last known working build.

I am building GENERIC-NODEBUG.

Sadly my pulse is shaky and I can't properly read the picture I 
took, it appears to say:


Fatal trap 32: page fault while in kernel mode
*something, something*
fault mode = supervisor read data, page not present

Will try to get more details and a proper dump when I have some 
time off (hopefully later today), just thought I'd warn before.

--
Evilham
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: memstick installer doesn't install loader.efi into ESP

[Yuri Pankov]

On Mon, Oct 7, 2019, at 5:23 AM, Yuri Pankov wrote:
> Just tried reinstalling the system on my laptop using the latest 
> available memstick snapshot 
> (https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20191004-r353072-memstick.img),
>  
> using UEFI boot, and default ZFS partitioning, and it didn't boot after 
> installation.  Booting into the installer again, I noticed that ESP is 
> empty.
> 
> Reinstalling again after wiping pool labels and clearing partitions 
> didn't change anything, though I noticed the "/tmp/bsdinstall-esps: no 
> such file or directory" in the installer log.
> 
> Mounting ESP, creating EFI/FreeBSD/ directory, copying /boot/loader.efi 
> there, and creating appropriate Boot variable solves it, of course, but 
> I'm wondering what have gone wrong.
> 
> Laptop has NVMe drive (nvd0, empty, gpart destroy -F nvd0), SATA drive 
> (ada0, empty, gpart destroy -F ada0), and is booting from USB memstick 
> (da0); no Boot variables defined when booting to installer (other than 
> defaults ones for laptop).  Any other details I should provide here?

I think I see the problem, bootconfig script uses ZFSBOOT_DISKS variable that 
isn't defined and always empty and auto-detection must be unreliable in some 
cases, at least for me as I reproduced it on another system with NVMe device 
adding a SATA disk as well (didn't look into the details).  Should be easy to 
fix, review incoming.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"