Konstantin Belousov wrote:
>On Mon, Aug 10, 2020 at 12:46:00AM +, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>> >On Fri, Aug 07, 2020 at 09:43:14PM -0700, Kirk McKusick wrote:
>> >> I do not have the answer to your question, but I am copying Kostik
>> >> as if anyone knows the answer,
(Please send the followup to freebsd-testing@ and note Reply-To is set.)
FreeBSD CI Weekly Report 2020-08-09
===
Here is a summary of the FreeBSD Continuous Integration results for the period
from 2020-08-02 to 2020-08-09.
During this period, we have:
* 1823
The problem identified in Warner's email was fixed in r364030, so an
easy solution is updating from r363678 or earlier directly to r364030
or later.
Best,
Conrad
On Mon, Aug 10, 2020 at 3:20 AM Dennis Clarke wrote:
>
> On 8/5/20 9:19 PM, Warner Losh wrote:
> > If you are upgrading across
Hi,
I am currently getting the following error during a "make installworld":
---
[...]
===> share/zoneinfo/tests (install)
install -o root -g wheel -m 555 backward_test
/usr/tests/share/zoneinfo/backward_test
On 8/5/20 9:19 PM, Warner Losh wrote:
> If you are upgrading across r363679, you may have installworld fail, as
> documented in UPDATING.
>
> I have a fix (that requires a trip through buildworld) that's under review
> at https://reviews.freebsd.org/D25967 . The changes are likely good, but
>
Hi,
On 2020-08-10 12:59, Alexandre Levy wrote:
Looking at the code, the error happens during the call to VM_OBJECT_WLOCK
(memory page locking for write ?) in the intel_freebsd.c (see [1] below).
I'm out for a few days but I'll try to dig more into it when I'm back next
weekend although I have
On 2020-08-10 12:59, Alexandre Levy wrote:
I could reproduce with GENERIC kernel and i915 kms compiled with DEBUG and
I got this additional info (still no crash dump though) :
If you have the debugger enabled, you will need to type "dump" in the
crash handler to get the core-dump.
--HPS
I could reproduce with GENERIC kernel and i915 kms compiled with DEBUG and
I got this additional info (still no crash dump though) :
Kernel page fault with the following non-sleepable locks held:
kernel: exclusive rw vm object (vm object) r = 0 (0xf8037533bc60)
locked @
On 2020-07-23 21:26, Bjoern A. Zeeb wrote:
That’ll probably work; still, the deferred teardown work seems wrong to
me; I haven’t investigated; the patch kind-of says exactly that as
well: if “wait until deferred stuff is done” is all we are doing, why
can we not do it on the spot then?
Hi
Ah thanks, I was doing a make config-recursive and that didn't show the
DEBUG option. It's recompiling the module with DEBUG now.
Le lun. 10 août 2020 à 09:43, Hans Petter Selasky a
écrit :
> On 2020-08-10 10:41, Alexandre Levy wrote:
> > I'm recompiling the kernel using GENERIC at the moment
On 2020-08-10 10:41, Alexandre Levy wrote:
I'm recompiling the kernel using GENERIC at the moment but I'm not sure how
to enable debugging in i915 kms, there is no compile option for that, am I
missing something ?
Type:
make config
Before building the i915kms port, then there should be a
I'm recompiling the kernel using GENERIC at the moment but I'm not sure how
to enable debugging in i915 kms, there is no compile option for that, am I
missing something ?
Le lun. 10 août 2020 à 08:44, Hans Petter Selasky a
écrit :
> Hi,
>
> On 2020-08-10 00:19, Alexandre Levy wrote:
> > Hi,
> >
Hi,
On 2020-08-10 00:19, Alexandre Levy wrote:
Hi,
I installed the port drm-devel-kmod for Plex to be able to transcode videos
using the integrated GPU of my Intel Celeron G5900.
I'm running r364031 and the kernel is compiled with GENERIC-NODEBUG profile.
Transcoding has been working fine
13 matches
Mail list logo
