this might be the same as
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57153
it's the same faulting function and similar offset...
.mrg.
hiya.
the new compat32 sets rearrangement has broken the GCC 12 build,
due to dropping "gcc=10" tag in some places. that's a minor issue,
and i'll fix that soon (though having looked closer at the first
"grep -r" output below, i see most of these are affected. i'll
just initially be fixing
Paul Goyette writes:
> Does anyone have an example of how to configure raid0 on a GPT disk?
these are my notes i refer to every so often:
https://www.netbsd.org/~mrg/gpt-raid-setup.txt
it's gpt on each with type raid, which gives you dkN @ diskN,
you then create a raid with those dkNs, and then
Paul Goyette writes:
> On Tue, 5 Mar 2024, Paul Goyette wrote:
>
> > I _think_ it will work correctly if I modify fstab to refer to
> > NAME=Builds instead of ccd0. I will update here after I confirm.
>
> Yes this seems to work.
this is very much preferred. "ccd0" is the device i suspect if
you
ah. the problem is that struct isc_nmhandle grew a pointer member,
adding 4 bytes to the struct size, and it uses C99 [] variable array
for the final member, which is later assigned to other pointers, and
this memory was now only 4-byte aligned. this hack patch works to
stop named crashing for
this appears to be a badly aligned structure issue. i can reproduce
it by doing "anita interact" with any recent sparc .iso, editing the
named.conf to start, starting named, and doing 'dig ns netbsd.org'
would trigger the crash.
the stack trace is:
(gdb) bt
#0 ns__client_request
actually, i found a core file in /var/chroot/named/etc/namedb/named.core.
my build is missing debug info so i don't have a good idea what.
.mrg.
> Unfortunately there was no core dump.
this is almost certainly because /var/chroot/named is not writeable
by user named, which is on purpose.
you can set the corefile path for this process after it starts using
sysctl proc.$pid.corename. i think setting to "/var/tmp/%n.core"
should allow it
> On Mon 05 Feb 2024 at 10:18:09 +1100, matthew green wrote:
> > perhaps convert into a DBG(4, ...)?
>
> On Mon 05 Feb 2024 at 02:20:25 +0300, Valery Ushakov wrote:
> > May be make it reported only once, so that the message is still there
> > in the log, but it's no
> if (hscroll || vscroll) {
> xf86Msg(X_WARNING, "%s: hscroll=%d, vscroll=%d\n",
> pInfo->name, hscroll, vscroll);
[ ... ]
> This touchpad method is not supported by the xf86-input-mouse driver so
> with that one the touchpad
> = note: ld: /usr/libexec/liblto_plugin.so: error loading plugin:
> /usr/libexec/liblto_plugin.so: Undefined PLT symbol
> "unlink_if_ordinary" (symnum = 47)
this part should be fixed now. probably needs a pullup..
.mrg.
Thomas Klausner writes:
> Hi!
>
> As noted in PR 57565, the default ARFLAGS in share/mk/sys.mk are
> broken - they use 'l' which changed behaviour between binutils 2.34
> and 2.39.
>
> Ok to commit the change?
>
> (This broke the build of ruby-nokogiri recently, which is how I
> noticed.)
the
Patrick Welche writes:
> On Thu, Nov 23, 2023 at 12:31:34PM +, Robert Swindells wrote:
> >
> > Patrick Welche wrote:
> > > I'm trying to build a release on amd64 using
> > >
> > > HAVE_MESA_VER=21
> > > HAVE_GCC=12
> >
> > What does pkgsrc graphics/MesaLib do if built using gcc 12?
>
> It
Rin Okuyama writes:
> Hi Andrius,
>
> If you still have this AQC100 in working condition, can you try this patch?
>
> https://gist.github.com/rokuyama/ab6ba1a0fac7fa15f243d63a99e14f33
>
> I've collected three fibre aq(4) variants (all rev 2), and link status
> interrupts work just fine for me. I
i'm pretty sure i've solved this properly this attempt, but
review on this change would be appreciated.
https://www.netbsd.org/~mrg/if_rge.c.v3.diff
it includes a potential way to avoid wm(4) calling panic() if
bus_dmamap_load*() fails..
.mrg.
> hmmm, but in thie case, no buffers would should be set to
> be available for rx, so nowthing should pass RGE_OWN() at
> L1245 i'd hope. i still see the problem with everything
> being depleted, but then it should just stop getting any
> rx packets at all...
>
> networking folks, am i missing
> #3 0x80fe6e5f in kern_assert ()
> #4 0x8058be67 in bus_dmamap_sync ()
> #5 0x8044edc7 in rge_rxeof ()
> #6 0x804536fd in rge_intr ()
i'm pretty sure this is the 2nd bus_dmamap_sync() call, as that's
the only dma map that has load/unload applied at run time,
> panic: kernel diagnostic assertion "offset < map->dm_maps" failed: file
> "/usr/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset 0x0 >= 0x0
this is from:
KASSERTMSG(offset < map->dm_mapsize,
"bad offset 0x%"PRIxBUSADDR" >= 0x%"PRIxBUSSIZE,
offset, map->dm_mapsize);
the mapsize
i just commited what i believe is a fix for this problem, and for
another potential memory leak i saw from inspection.
seems to work for me on an amd64 host, been through several down/up
sequences, though i did not force the memory alloc failure directly.
(annoyingly, it takes 10-11s to regain
Martin Husemann writes:
> On Fri, Sep 29, 2023 at 09:52:42AM +, Chavdar Ivanov wrote:
> > Sep 29 01:53:13 ymir /netbsd: [ 228407.9443196] panic: kernel diagnostic
> > assertion "offset < map->dm_mapsize" failed: file
> > "/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset
Thomas Klausner writes:
> panic: kernel diagnostic assertion "!cpu_softintr_p()" failed: file
> "/usr/src/sys/kern/subr_kmem.c", line 451
>
> gdb says:
>
> #10 0x80e3551e in vpanic (fmt=0x813a1880 "kernel %sassertion
> \"%s\" failed: file \"%s\", line %d ",
Malte Dehling writes:
> Dear all,
>
> is there a way to get an external display to work on a ThinkPad W530?
> >From what I read, both the mini-dp and the vga connector work only
> with discrete graphics, which I have enabled in the BIOS
> (optimus/switching mode). At boot I see these lines:
>
> [
> nbmtree: .: missing directory in specification
> nbmtree: failed at line 1 of the specification
there must be something wrong in your build tree or src tree.
i updated and built this from a clean tree fine.
this should have been fixed with this pullup:
revision 1.175.2.1
date: 2023-09-04
Mark Davies writes:
> Trying to boot a Dell Power Edge R6515 that has an AMD EPYC 7313P with
> 10.0_BETA from a couple of day ago panics with:
>
>
> panic: kernel diagnostic assertion "rcr4() & CR4_SMAP" failed: file
> "...sys/arch/x86/x86/patch.c"
>
> backtrace of:
> vpanic()
>
> [ 1.051227] i915drmkms: preliminary hardware support disabled
this is a combo of the driver data for tiger lake (11th gen) having
"require_force_probe" set to 1 (our drm base), and the netbsd probe
code seeing this set and not matching properly.
there's nothing you're doing wrong, it just
> I pass it in LDFLAGS=-L${GMPOBJ}
? this doesn't help gmp.h being missing... i don't know what is up
and for me, it works because pkgsrc gmp is installed.
.mrg.
> christos
>
> > On Aug 13, 2023, at 2:41 PM, matthew green wrote:
> >
> > FWIW, when i was loo
FWIW, when i was looking at why my build worked it seems that
the build is thinking it's building against the tools gmp but
the -I path to find it is missing, but -I/usr/pkg/include is
so that for me i'm getting the host gmp.h, but it's linking
the tools libgmp.a.
one problem i've seen in kern_tc.c when the timecounter returns
a smaller value is that tc_delta() ends up returning a very large
(underflowed) value, and that makes the consumers of it do a very
wrong thing. eg, -2 becomes 2^32-2, and then eg in binuptime:
477 bintime_addx(bt,
can you try commenting/removing this line (@L44 in -current) in
external/gpl3/gcc/usr.bin/Makefile.inc:
CXXFLAGS+= -std=gnu++98
i started seeing at least the gcc.c failure with GCC 10.5, and it
seems that the upstream build doesn't use this by default now, and
removing it fixed the build
> But maybe modesetting is mature enough (and intel bad enough)
> to warrant being the default for Intel GPUs.
i'm not familiar with the various intel chipsets, i've only had
a couple of them over the years and besides porting the kabylake
bits into the older drm version, i've not really touched
> > though NetBSD's cpu selection algorithm doesn't (yet anyway) really
> > understand processors like this.
>
> The scheduler did use first cores first, with performance cores
> using low cpu numbers, they should be utilized first but not
> necessarily for the important workloads.
>
> It now
things to do:
- reinstall bootxx_ffsvN -- make sure you're installing the right
ffsvN. you can use "dumpfs | head -2", and it should
say FFSv1 or FFSv2 here. that's "installboot" that you may have
already done, but perhaps used the wrong one?
- re-copy /boot. cp /usr/mdec/boot /
-
> `./build.sh -j 6 -u -x -U -o -T ../obj/tooldir.NetBSD-9.3-amd64 release
> install-image'
have you tried without "-o"? that might be the trigger here.
it should work, but maybe it's broken in the src/compat build.
thanks.
.mrg.
Chavdar Ivanov writes:
> On Sat, 4 Mar 2023 at 23:30, Michael van Elst wrote:
> >
> > ci4...@gmail.com (Chavdar Ivanov) writes:
> >
> > >Since my last aarch64 build yesterday, 03/03/2023, my machine no
> > >longer boots automatically,
> >
> > sys/arch/evbarm/fdt/fdt_machdep.c 1.100
> >
> >
thanks for your patches and help, Jeff!
Taylor R Campbell writes:
> > Date: Tue, 21 Feb 2023 13:20:13 -0800
> > From: Jeff Frasca
> >
> > I was going to try the radeon driver again, because I want to see if
> > my wayland compositor works better against it than the AMDGPU driver
> > (I'm
the old drm code for i915 is probably extremely obsolete at this
point. i don't think it works on anything that current does
(or least, before the latest refresh -- i think there are still
a couple of blank screens, but i think newer than this code would
support anyway.)
the only reason i
Robert Elz writes:
> I wonder if perhaps part of the reason (or perhaps all of it) that
> Paul and I see problems, where others aren't, is that we are both
> building from a read only mounted source tree.
oh yeah - this is only going to break r/o src tree builds, which is
also something i use as
> > Sources updated to 2022-12-31 at 13:42:04 UTC and all output dirs (obj,
> > release, dist, tools) were cleaned.
>
> Is no-one else seeing this problem with ``build.sh tools'' ?
it's not seen by most because it depends upon the timestamps of
some files.. my first attempt to fix it failed, i
nia writes:
> On Thu, Dec 22, 2022 at 08:05:02AM +0530, Mayuresh wrote:
> > On Thu, Dec 22, 2022 at 06:18:41AM +1300, Lloyd Parkes wrote:
> > > I used the second (non-BIOS) image because I guessed it might be a hybrid
> > > installer. I think that my old NUCs only support BIOS booting from USB
> >
"John D. Baker" writes:
> I've updated to sources containing the new libX11 and rebuilt "wm/fvwm"
> without the patches posted in:
>
> https://mail-index.netbsd.org/pkgsrc-users/2022/10/17/msg036348.html
>
> and the resulting fvwm appears to work properly.
>
> Thanks!
great news. thanks for
hi folks.
FYI: i just added this note to UPDATING:
2022:
The new libdrm import worsened the conflict issues for the
kdump/ktruss ioctl, and i915 now conflicts with base, and has
been turned off. This will cause update build issues like:
hi folks.
the newly released libX11 1.8.2 claims to fix issues in fvwm,
xfce, and some motif stuff, related to hanging because of the
thread safety changes.
i know some problems were fixed, but this should now make the
old binaries work again. i've merged into -current.
if you have something
> > > If anyone wants to play with UEFI booting and has access to a recent Xen
> > > DOM0 system you can install the pkgsrc/sysutils/ovmf package and point a
> > pkgsrc/sysutils/ovmf does not build on -current at least - and hasn't been
> > building for a long while.
>
> Hmm... unfortunate...
i've commited my fix for this after testing it.
.mrg.
rudolf writes:
> Hi,
>
> I have "USE_SSP=yes" in mk.conf and the build is failing with:
>
> --- dependall-drivers ---
> /usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drmmode_display.c:
>
> In function 'drmmode_crtc_gamma_set':
>
> > (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h
> >
> > OpenBSD/luna88k maintainer (Kenji Aoyama) reported the following fix
> > was neceesary for non-XFree86 driver based dumb server (on luna88k etc.):
> > https://gist.github.com/ao-kenji/afb0ea5b6dca04975161f84ab41ba32b
>
Robert Swindells writes:
>
> I wrote:
> > It looks like not all the functions are getting setup in the glamor
> > struct by load_glamor(), I'm guessing because those functions are
> > not exported by libglamoregl.so.
> >
> > Do we need to add more source files to this:
> >
> >
Robert Swindells writes:
>
> I wrote:
> >
> >>> [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5]
> >>> [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465]
> >>> [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0)
> >>> [0x75b46379c930]
>
> > > [184218.xxx] fatal page fault in supervisor mode
> > > [184218.xxx] trap type 6 code 0x2 ...
> >
> > this line's contents would have included the fault address,
> > which is kinda useful for next time :-)
>
> I've got the rip -- it's 0x8095e177.
oh - i was after the "cr2" value --
> [184218.xxx] warning:
> /usr/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/disp/nouveau_nvkm_engine_disp_headgf119.c:83:
> 1
can you patch this code to print the value of "data" here?
it's probably a bad request for userland, but the BUG_ON()
here does not give you any indication on
> can you post the whole Xorg.0.log somewhere? most of
> my i915 systems have become non-functional the last few
> years, but i have one system to test.
unfortunately, my system (kaby lake, GT 630) seems to work
fine with xorg-server 21.1.4 for me.
> TL;DR: after upgrading via the sets available from releng builds from
> July 16th (http://releng.netbsd.org/builds/HEAD/202207160630Z) I'm not
> able to start X on amd64 with i915 graphics. Separately, there may be
> issues with libX11 1.8.1 where clients will hang due to recursive locks
>
hi folks.
i've updated most of xsrc to their latest versions.
fontconfig and Mesa are remaining. i've tested the
new code on amd64 and arm64, and built several ports
to confirm they still build. the biggest change is
the new xorg-server.
there are probably a few build issues left to find
> (but I'm nots sure 64KB blocksize is valied on FFS because
> newfs(8) man page just says 4KB-32KB for it)
FWIW, i've been using 64K block *and frag size FFS for over
a decade without any problem, on a file system that almost
always has extremely large files on it.
so, this should be fixed in
> I've tried overwriting the first 100MB of the 'dp' entry in my fstab
> with zeroes in the hope of getting rid of the crashdump, but that
> didn't help either. How can I get rid of the crashdump so savecore
> doesn't try again to write it out?
martin answered this, but to answer differently, the
nia writes:
> blkdiscard(8) seems like a command in -current that's useful for regular
> maintenance of SSDs.
>
> I would assume that a regular run of:
>
> blkdiscard -v /dev/rwd0d
>
> would be useful to TRIM an entire SSD, obviously destructively, so would
> be useful when reinstalling NetBSD.
k...@munnari.oz.au writes:
> Anyway, let me know what you think - is this worth finishing, or will
> the changes break people's scripts (or something similar) - or do you
> just prefer it the current way.
i like this.
i find the ordering of the default output has the same problem,
and had
[ .. ]
> install 9.99.96 in a Virtual Machine (on Linux using KVM) I noticed that
> after installing to a qcow2 disk any attempt to boot the disk results in
> not being about to find the boot device. However, the boot log shows
was this between 2022-05-08 and 2022-05-22? i accidentally
broke
Phil Nelson writes:
> On Wed, 11 May 2022 11:15:42 +1000
> matthew green wrote:
>
> > do you have anything else handy to test? gpus are crazy stupid
> > prices these days :-(
>
> Hi Matthew,
>
> My department has several nvidia around and I have not yet fo
Brook Milligan writes:
> I am trying to use a Trendnet TEW-648UBM usb wifi dongle, which is
> supposed to be recognized by the urtwn driver. However, it is
> recognized as a ugen device, instead.
>
> [ 2.9586490] ugen0 at uhub1 port 1
> [ 2.9586490] ugen0: Realtek (0x20f4) 802.11n WLAN
Phil Nelson writes:
> Hi All,
>
>I've been trying to get -current running on a new Dell Precision
> 3650. It is a UEFI boot only machine and when booting -current
> with a Radeon HD 5450 installed (which works great on 9.2 on
> an Dell Optiplex 7040) it panics when it can't find the Radeon
> Radeon RX 550 (HDMI, DP, and DVI with a DVI to HTML converter)
FWIW, i put my RX 550 into my test box yesterday and ran my
basic stress test -- 12 glxgears tiled separately and then
playing a movie on top of it.
it failed. the GPU resets itself a few times, there's severe
display
Tom Ivar Helbekkmo writes:
> Robert Elz writes:
>
> > Any advice?
>
> Well, in my experience, nvidia is probably something you only want if
> you have lots of RAM in your workstation. In HEAD, there's a lot of
> memory leaking going on - every change to the image on the monitor leaks
>
Robert Elz writes:
> Date:Sat, 07 May 2022 14:28:12 +1000
> From: matthew green
> Message-ID: <16731.1651897...@splode.eterna.com.au>
>
> Thanks for the reply.
>
> | the GTX 16xx are both in the recent supported list for
> | new dr
> What I need from the new one is no different than I needed
> then, a flat frame buffer, capable of supporting 3 high res
> monitors (3840x2160, 1440x2560 (portrait mode), and 2560x1080.)
it's the 3840x2160 that makes the older cards not potential
for your requirements -- they're max at
> Perhaps you, like me, are frustrated that USB serial devices can get
> enumerated in non-deterministic ways, which makes putting those device
> names in configuration files (such as /etc/remote) less than useful.
>
> I threw together a little devpubd hook to fix this problem for those
> adapters
Farhan Khan writes:
> Hi all,
> I am trying to understand a snippet of athn(9) code for the purpose of
> porting to FreeBSD. I am reading the function athn_usb_htc_setup()
> located in /usr/src/sys/dev/usb/if_athn_usb.c. After tracing it
> through, it seems to terminate at a usbd_setup_xfer(9)
this should be fixed now. sorry for the fallout.
.mrg.
Jaap Boender writes:
> > connected to a dell ultrasharp lcd (both 2415 and 2715 models) using
> > it's audio jack connected to a 2.1 speaker setup.
>
> So just to be sure - you get the sound to the monitor by HDMI and then
> onwards with the audio jack? Then there's basically no difference in our
i don't have anything useful for you, except to say that this should
or can be a working setup.
> I've got a setup with two sound cards: the on-board sound chip, and the
> graphics card (a Radeon RX550). These both seem to be dectected (after
> adding the HDAUDIO_ENABLE_HDMI option to the
> I'm looking to upgrade my graphics card. What's the newest generation
> that's well supported by NetBSD-current now?
> NVidia "Pascal" (e.g. GTX 1050 Ti)?
> Radeon "Polaris" (e.g. Radeon RX 550)?
> or even something newer?
we have reports that 1030 works well. i still haven't gotten
a newer
> Please update and try again? (I've only compile-tested the changes,
> will take a closer look tomorrow if it doesn't fix the problem.)
seems to work for me. i can once again mostly play 720p video
with "mpv -vo x11".
thanks!
.mrg.
> > On Dec 8, 2021, at 10:52 AM, Greg A. Woods wrote:
> >
> > That's one bullet I've dodged entirely already since my oldest systems
> > are running netbsd-5 stable. (Though in theory isn't there supposed to
> > be COMPAT support for SA?)
>
> int
> compat_60_sys_sa_register(lwp_t *l,
>
> libGL error: failed to open drm device: Permission denied
> libGL error: failed to load driver: i965
>
> how can I solve this? Usually it is the means of adding oneself to a
> specific group, changing devfs, but found nothing of there like.
check the perms on /dev/dri/card0. make sure your
hi folks.
an unfortunate problem with the DTS 5.15 update is that the
sdio device has been enabled by default, which means that
the default ordering of sdmmc(4) devices changes, which leads
to the ld(4) numbers changing too.
the old sdmmc0 and sdmmc1 become sdmmc1 and sdmmc2, and so
ld0 and
> > wd1 at atabus1 drive 0
> > autoconfiguration error: ahcisata0 port 1: setting WDCTL_RST failed for
> > drive 0
> > wd1: autoconfiguration error: IDENTIFY failed
> > wd1(ahcisata0:1:0): using PIO mode 0
> >
> > and booting fails. Reverting and booting with 9.99.90 gets me a working box:
> >
>
Tom Ivar Helbekkmo writes:
> I have this Java application (JSynthLib) that needs to talk MIDI with my
> synthesizers. I've previously run it with older versions of the JRE,
> using the LinuxCharDevMidiProvider that came with it - but that no
> longer works with the current environments. All I
> I feel that this failure is related to recent gmp update.
probably. it didn't happen initially but i see it now.
will fix..
.mrg.
> but starting tmesh via gdb works??
i've had some crashes with pkgsrc/graphics/blender lately that
go away in gdb. (it's kinda annoying, the -g enabled blender
takes a really long time for gdb to load...)
this is amd64 and 9.1-ish userland.
.mrg.
dashdruid writes:
> Hello List,
>
> I keep getting this error whatever I try to build from pkgsrc on NetBSD9.1
> i386.
>
> Even if I follow the basic tutorial with figlet:
>
> https://wiki.netbsd.org/pkgsrc/how_to_use_pkgsrc/
>
> It's the same error for all packages.
what's the actual error?
>
can you try without an xorg.conf at all? this hardware is
not currently supported by our kernel drm driver and will
need to fallback to wsfb or vesa. it should do automatically
without an xorg.conf to force a driver.
in general, X -configure is no longer recommend, and a
minimal xorg.conf for
> I too get long pauses with cvs, both at the beginning,
> and even longer at the end after update is complete.
the end part is most likely cvs cleaning up after itslf by
removing all the subdirs it created but doesn't need.
check disk io or ktrace for this part -- it's usually a
local iops
> Here (or pkgsrc-users?) seems ok. But my question would be if cgal
> documents that it needs a C++11 compiler, in which case this change is
> right regardless, or if it's supposed to be ok with C++03, in which case
> maybe something else is wrong.
the release notes from 2017 say that demos
matthew green writes:
> i saw a report that netbsd-8 can't be built on -current but i'm
> not finding it right now.
>
> i can confirm this is the case. you can work around the GCC 10
> inspired issues for now with eg:
>
>./build.sh -V HOST_CFLAGS='-fcommon -O2'
thi
i saw a report that netbsd-8 can't be built on -current but i'm
not finding it right now.
i can confirm this is the case. you can work around the GCC 10
inspired issues for now with eg:
./build.sh -V HOST_CFLAGS='-fcommon -O2'
but then there is a -current regex vs -8 file magic regex issue.
> > - build.sh with no -u (update), and set -V HAVE-GCC=10 as a
> >option. this ensures that everything is actually rebuilt
> >with the new compiler.
>
> I'm guessing that should be "-V HAVE_GCC=10", but even so I just can't
yup!
> get this to build. I always get the message "cc:
"Thomas Mueller" writes:
> > i've switched the alpha, amd64, sparc*, riscv*, ia64, and vax ports
> > have all been switched to GCC 10.
>
> > please send-pr or send email here about problems you encounter.
>
> > thanks.
>
>
> > .mrg.
>
> What about the i386 port?
see
hi folks.
i've switched the alpha, amd64, sparc*, riscv*, ia64, and vax ports
have all been switched to GCC 10.
please send-pr or send email here about problems you encounter.
thanks.
.mrg.
hi folks.
(please reply privately to this spams-many-lists message, and
i will keep src/external/gpl3/gcc/README.gcc10 updated with
the latest status.)
i've just commited the final parts that make most platforms build
(and many run) with GCC 10 as the system compiler.
i've tested these
Martin Husemann writes:
> On Sun, Apr 11, 2021 at 10:37:21AM +1000, matthew green wrote:
> > > How can you invoke a make to test this (besides a full build.sh and adding
> > > some output to the makefiles)?
> > > Or: can you just fix and request pullup ;-)
> &
Martin Husemann writes:
> On Sat, Apr 10, 2021 at 04:12:55PM +1000, matthew green wrote:
> > Martin Husemann writes:
> > > On Sat, Apr 10, 2021 at 08:38:39AM +1000, matthew green wrote:
> > > > for a quick fix, this is OK, but long term, these are built
> &
Martin Husemann writes:
> On Sat, Apr 10, 2021 at 08:38:39AM +1000, matthew green wrote:
> > for a quick fix, this is OK, but long term, these are built
> > for sparc64 compat32 as well, and benefit from having this
> > code in place.
>
> I have seen that
> Different to other asm code that e.g. properly detetects various VIS
> instructions that may or may not be available on the current CPU, the code
> in ghash-sparcv9.pl is plain sparcv9 code and can not be enabled for our
> sparc builds.
>
> Christos, can you disable all "modes" asm and request
> >> and one more
> >>
> >> __sigaction_sigtramp(SIGILL...)
> >>
> >> Then, at the end:
> >>
> >> PSIG SIGILL SIG_DFL: code=ILL_ILLOPC, addr=0xedccbdf0, trap=2)
>
> Program was terminated due to an illegal opcode being detected in
> the gcm_ghash_4bit() assembly function:
yes. John, can
> In this particular example server it's in a Dell R510 with a pair of
> 6-core E5645 CPUs that "cpuid" shows the following for (in the dom0):
this is a westmere-ep CPU, which does not support rdseed
or rdrand. rdrand appeared in ivybridge (2 generations
later, with sandybridge in the middle.)
> Joerg thinks that this is an nfs issue (a bug with nfs giving incorrect data).
even if true, tar shouldn't *core dump*. is there a path
to RCE here some where? it's clearly overwriting pointers
with strings, so unless someone can clearly show there is
no code exec vector here, it seems
radeondrm does not support any modern graphics card, and
we don't have a working amdgpu driver yet (last i tried,
it hung at boot and i did not have a serial console setup
to test with yet.)
you can have almost OK stuff with the vesa driver. maybe
wsfb also can work.
we're working (slower than
Yorick Hardy writes:
> Dear current-users,
>
> Happy new year!
happy new year yorick! and everyone.
> [ 659.839003] usbd_create_xfer() at netbsd:usbd_create_xfer+0x186
> [ 659.849001] usbd_open_pipe_intr() at netbsd:usbd_open_pipe_intr+0x74
> [ 659.849001] uhidev_open() at
nice. LGTM.
.mrg.
> On 10.11.2020 09:19, matthew green wrote:
> > there was not nearly enough discussion for this and i object
> > quite strongly about this. please revert immediately and
> > begin a real discussion.
>
> Revert MKCATPAGES change?
yes, all of it. your proposal was n
1 - 100 of 241 matches
Mail list logo
