On 11/22/23 9:34 PM, Mike Pumford wrote:
this fixes kern/57268
Thanks, Mike, excellent work!
This fixes kern/57268 also for my Gen7 Intel HD Graphics 4400.
r.
On 23/11/2023 17:52, Rhialto wrote:
I will check
https://github.com/freebsd/drm-kmod/blob/master/drivers/gpu/drm/i915/i915_pci.c
whco does show some differences in the GEN4_FEATURES macro. The first
thing I checked was however some completely new field, so that would
probably be irrelevant.
On 23/11/2023 06:15, Brett Lymn wrote:
On Wed, Nov 22, 2023 at 08:34:22PM +, Mike Pumford wrote:
Yes! This makes X work for me too. I had gone down the rabbit hole of
trying to get the drmkms to apply the workarounds for gen 8 to my gen 7
GPU in the hope that it would work - it did once
On 23/11/2023 08:51, Martin Husemann wrote:
On Thu, Nov 23, 2023 at 09:47:21AM +0100, tlaro...@kergis.com wrote:
Smart move and great initiative! Please do send patches to
tech-k...@netbsd.org in order for the developers working with drmkms
to see them and, hopefully, apply them to the cvs
On Wed 22 Nov 2023 at 20:34:22 +, Mike Pumford wrote:
> - .ppgtt_type = INTEL_PPGTT_FULL, \
> + .ppgtt_type = INTEL_PPGTT_ALIASING, \
It seems my GM45 is Gen 4 (a bit older...) but at least it seems that is
supposed to be supported.
static const struct intel_device_info gm45_info = {
So one thing to check is that while you didn't seem to be doing an
update build, so everything should have been cleaned before it
started, you might want to try making certain of that by manually
cleaning it all (rm -fr on relevant directories) and trying again.
It is possible that the change
MKRADEONFIRMWARE=no -V MKREPRO=yes -
V MKRUMP=no -V MKX11=no -V MKX11FONTS=no -V MKX11MOTIF=no -V MKZFS=no -V MKYP=no
-V USE_YP=no -V MKHESIOD=no -V USE_HESIOD=no -V MKPAM=yes -V USE_PAM=yes -V MKS
KEY=no -V USE_SKEY=no -m alpha -D /release/testing/alpha -O /usr/obj/testing/alp
ha -R /local/snap/20231123
Date:Thu, 23 Nov 2023 12:13:42 +0100
From:Ede Wolf
Message-ID: <77602506-626c-4fff-90ec-48e2f4aaf...@nebelschwaden.de>
| Ok, I did not see this as yet verified, because, as with MKKERBEROS=yes
| and USE_KERBEROS=yes the build fails as well. Even though at a
Am 23.11.23 um 12:00 schrieb Martin Husemann:
On Thu, Nov 23, 2023 at 11:58:08AM +0100, Ede Wolf wrote:
Btw, this does not seem to be alpha-port specific. I've just tried to
compile on amd64 for amd64, exactly the same mk.conf (with the obvious
exception of CPUFLAGS) and of course changing -a
On Thu, Nov 23, 2023 at 11:58:08AM +0100, Ede Wolf wrote:
> Btw, this does not seem to be alpha-port specific. I've just tried to
> compile on amd64 for amd64, exactly the same mk.conf (with the obvious
> exception of CPUFLAGS) and of course changing -a and -m for build.sh:
As Robert noted, it is
Am 23.11.23 um 10:21 schrieb Ede Wolf:
Am 22.11.23 um 17:00 schrieb Martin Husemann:
On Wed, Nov 22, 2023 at 04:21:01PM +0100, Ede Wolf wrote:
My build says somethig different about warnings and errors (Marking
by me,
of course):
Am 22.11.23 um 17:59 schrieb tlaro...@kergis.com:
On Wed, Nov 22, 2023 at 04:21:01PM +0100, Ede Wolf wrote:
[...]
My mk.conf should be rather unspectacular as well:
# cat /etc/mk.conf
CPUFLAGS = -mcpu=21164a
# world related stuff:
NETBSDSRCDIR=/data/src
BSDOBJDIR=/data/obj
Am 22.11.23 um 17:49 schrieb Robert Elz:
Date:Wed, 22 Nov 2023 16:21:01 +0100
From:Ede Wolf
Message-ID:
| # cat /etc/mk.conf
| MKKERBEROS=no
That one is the problem, the COPTS.crypto.c entry that Martin mentioned
is not included if MKKERBEROS is "no".
Am 22.11.23 um 17:00 schrieb Martin Husemann:
On Wed, Nov 22, 2023 at 04:21:01PM +0100, Ede Wolf wrote:
My build says somethig different about warnings and errors (Marking by me,
of course):
/data/src/crypto/external/bsd/libsaslc/lib/../dist/src/crypto.c: In function
'saslc__crypto_md5_hex':
On Thu, Nov 23, 2023 at 09:47:21AM +0100, tlaro...@kergis.com wrote:
> Smart move and great initiative! Please do send patches to
> tech-k...@netbsd.org in order for the developers working with drmkms
> to see them and, hopefully, apply them to the cvs sources.
Adding them to the PR is good
On Wed, Nov 22, 2023 at 08:34:22PM +, Mike Pumford wrote:
>
>
> On 18/11/2023 11:34, tlaro...@kergis.com wrote:
> > On Sat, Nov 18, 2023 at 11:14:12AM +, Mike Pumford wrote:
> > Yes, there has been a major refactoring in the Linux code regarding
> > headers for example. The whole Linux
On Thu, Nov 23, 2023 at 04:45:20PM +1030, Brett Lymn wrote:
> On Wed, Nov 22, 2023 at 08:34:22PM +, Mike Pumford wrote:
> >
> > And translated it into the patch attached to this message. A kernel with
> > this patch boots and runs X successfully Still see a little bit of cache
> > tearing but
17 matches
Mail list logo
