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

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

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:

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

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

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

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 > >

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

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) > > +++

DRM (i915kms) panic on r353303

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

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. >

RE: DRM (i915kms) panic on r353303

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

Re: DRM (i915kms) panic on r353303

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]

Re: DRM (i915kms) panic on r353303

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

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

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

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

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,

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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 -

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

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