On Fri, Sep 08, 2023 at 08:55:10AM -0300, Lucas de Sena wrote:
[...]
> Quoting from `xenocara/app/xclock/xclock.c`:
>
> > {
> > /* force reading of XErrorDB into memory to avoid adding "rpath" to
> >pledge below */
> > char buf[1];
> >
> >
Very basic pledge(2) for the whole program. I didn't dive too much into
the details and maybe this can be refined some more. This is kind of a
product of me trying a tool I made `abstain` [1] for usefulness of
pledge(2) execpromises and it helped quickly find that xeyes(1) can run
with a very
On Tue, Aug 08, 2023 at 01:02:53PM +0200, Marc Espie wrote:
> Actually, as far as bsd.port.mk, it doesn't need to
> move too much stuff around thanks to make's lazyness.
>
> Note that having a list of defined MASTER_SITES variables simplifies
> the check.
>
> I've also added a check for the
On Tue, Aug 08, 2023 at 12:51:43PM +0200, Marc Espie wrote:
> Here's a revised diff (reordered plus actual use of the boolean)
> plus concrete example use for bsd.port.mk (disregarding the fact
> _ALL_VARIABLES would have to move *after* all MASTER_SITES have been defined.
I tested this on a
On Mon, Aug 07, 2023 at 09:17:05PM +0100, Stuart Henderson wrote:
[...]
> I think maybe I'd prefer to have some variable that could be used
> *instead* of the existing GH_* variables rather than in conjunction with
> them (so they can be used for all GH archive ports, rather than have
> them a
On Mon, Aug 07, 2023 at 04:42:54PM +0200, Marc Espie wrote:
> I think it could be occasionally useful to know which variables have
> been defined in make.
>
> Incidentally, this DOES exist in GNU make, so I've reused the same name
> for basically the same functionality.
>
> I haven't checked
On Mon, Aug 07, 2023 at 06:59:15PM +0100, Stuart Henderson wrote:
[...]
> I haven't looked at other ports, but asterisk, vim and vmm-firmware do
> not use git submodules.
With vim, it's the way colorschemes are pulled in that *could* be
reworked using GH_SUBMODULES syntax. The old way continues
On Sun, Aug 06, 2023 at 07:00:49PM +0200, Marc Espie wrote:
[...]
> > > I'm also wondering if keeping the main GH_* stuff in bsd.port.mk makes a
> > > lot
> > > of sense, instead of grouping everything in github.port.mk
> >
> > I'm for it, maybe as a second step after the module for just the
>
On Sat, Aug 05, 2023 at 11:27:24PM +0200, Marc Espie wrote:
> Some comments already. I haven't looked very closely.
> On Sat, Aug 05, 2023 at 03:12:18PM -0400, Thomas Frohwein wrote:
> > The current draft hijacks post-extract target, but it would be easy to
> > add this to _pos
b38.tar.gz)
= 2417905
Index: Makefile
===
RCS file: /cvs/ports/games/fna/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile15 Jul 2023 23:24:35 - 1.17
+++ Makefile5 Aug 2023 19:10:00 -
@@ -7,21 +7,16 @@ HOMEPAGE =https://fna
On Mon, Jul 03, 2023 at 11:22:45AM +0200, Marc Espie wrote:
> I hope Vladimir will find the time to complete this answer.
>
> As far as Vlad's work goes, he did a presentation last week-end:
> https://www.lre.epita.fr/news_content/SS_summer_week_pres/Vladimir_Driver_OpenBSD.pptx
>
> (sorry for
On Mon, Feb 13, 2023 at 08:40:22PM +1100, Jonathan Gray wrote:
> On Sun, Feb 12, 2023 at 02:25:47PM -0500, Thomas Frohwein wrote:
> > On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:
> >
> > [...]
> > > > ...
> > > > i915_resize_lm
On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:
[...]
> > ...
> > i915_resize_lmem_bar: stub
> > panic: kernel diagnostic assertion "pdev->pci->sc_bridgetag == NULL"
> > failed: file "/usr/src/sys/dev/pci/drm/drm_linux.c", line 1277
> > ...
>
> The vga arbiter bits need to
On Sat, Feb 04, 2023 at 01:24:42PM +1100, Jonathan Gray wrote:
[...]
>
> I've committed the i915_gem_stolen_lmem_setup() portion.
>
> Another diff
>
> likely some more iomap use will show up later
>
> i915_gem_object_read_from_page_iomap()
> i915_gem_object_map_pfn()
> i915_gem_object_map()
On Fri, Feb 03, 2023 at 12:54:52PM +1100, Jonathan Gray wrote:
[...]
> > +xehp_load_dss_mask: stub
> > +xehp_load_dss_mask: stub
> > +intel_slicemask_from_xehp_dssmask: stub
> > +intel_slicemask_from_xehp_dssmask: stub
> > +i915_gem_stolen_lmem_setup: stub
> >
On Mon, Jan 30, 2023 at 09:32:08PM +1100, Jonathan Gray wrote:
> The current generation of Intel Arc branded graphics cards are part of
> what drm and Mesa refers to as DG2.
>
> https://ark.intel.com/content/www/us/en/ark/products/codename/226095/products-formerly-alchemist.html
>
> In -current
tter clarity, I suggest
updating the descriptions of the corresponding media modes by replacing "[11n]"
and "[11ac]" with "[11n (Wi-Fi 4)]" and "[11ac (Wi-Fi 5)]" respectively.
Thank you for your assistance.
Respectfully,
Thomas Dunn
Sent from my iPad
'logger -t $PROGNAME "kernel relinking done"' EXIT
> +trap 'trap - EXIT
> + logger -st $PROGNAME "$ERRMSG" 2>/dev/console
> + restore_mount' ERR
> +trap 'logger -t $PROGNAME "kernel relinking done"
> + restore_mount' EXIT
>
> # Create kernel compile dir and redirect stdout/stderr to a logfile.
> mkdir -m 700 -p $KERNEL_DIR/$KERNEL
>
>
--
Thomas de Grivel
https://www.kmx.io
On Fri, Nov 04, 2022 at 04:22:55PM +0100, Mark Kettenis wrote:
> > Date: Sat, 5 Nov 2022 02:06:11 +1100
> > From: Jonathan Gray
> >
> > On Fri, Nov 04, 2022 at 09:10:52AM -0500, John Browning wrote:
> > > Hi,
> > > I noticed I did not have sound on my new thinkpad which has a newer
> > > Intel
On Sun, 2022-07-31 at 13:11 +0200, Thomas Wager wrote:
> On Sat, 2022-07-30 at 22:44 +0100, Stuart Henderson wrote:
> > Due to the rule for this file mentioned in the header, I think you'll
> > need to find a developer who has been to the added airports that have
> > replaced
On Sat, 2022-07-30 at 22:44 +0100, Stuart Henderson wrote:
> Due to the rule for this file mentioned in the header, I think you'll
> need to find a developer who has been to the added airports that have
> replaced the metro areas, i.e. KCK MFW QDV QSF, either that or just
> remove them.
You are
On Fri, 2022-07-29 at 16:09 -0400, Daniel Dickman wrote:
> I think they’re called Metropolitan Area Airport Codes:
>
> I found a list here:
> Metropolitan Area Airport Codes
> wikitravel.org
>
>
> Do you want to submit a revised patch with all the corrections?
>
Thanks, I double checked with
On Thu, 2022-07-28 at 21:45 -0400, Daniel Dickman wrote:
>
> No thanks. These are pretty standard ways to refer to groups of
> airports that are close by. We have a bunch of these in the file and
> I'd hate to lose these.
>
> BHZ:All Airports around Belo Horizonte, MG, Brazil
> BUE:All Airports
Hi,
some changes to /share/misc/airport to treat german umlauts more
consistently, remove the "Flugplatz" (german for airport, which is kind
of redundant as it is all airports in the list), remove NRW which does
not exist as IATA code, remove THF which is gone since 2010.
-Thomas
In
unt=0 reference=1
ERROR cluster 1048577 refcount=0 reference=1
32 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
1074802/4915200 = 21.87% allocated, 2.00% fragmented, 0.00% compressed clusters
Image end offset: 70456967168
Kind regards,
Thomas
On Sat, Mar 19, 2022 at 09:15:23PM +0100, Stefan Sperling wrote:
[...]
> > + /* XBox One controller initialization */
>
> Shouldn't this initialization code be under #ifndef SMALL_KERNEL,
> like the rest of the code your patch is adding to this file?
>
> > + if
On Thu, Mar 17, 2022 at 10:58:21PM +0100, Solene Rapenne wrote:
[...]
> >
>
> ping
>
> this diff is still applying to the kernel and allows to use a popular
> and affordable game controller
The diff was written fairly conservatively based on pre-existing code
and NetBSD's solution. It would
Hello,
Stefan S gave a presentation on this here:
https://youtu.be/W5qhWw07qpU
In addition I would get familiar with the coding style of the project:
https://man.openbsd.org/style.9
On Sat, Mar 5, 2022, 9:42 AM Shiran wrote:
> Hi, as the title suggests, I'm a pretty enthusiast guy and
On Thu, Sep 16, 2021 at 12:11:24AM +0200, Mark Kettenis wrote:
> > Date: Wed, 15 Sep 2021 17:29:39 +0200 (CEST)
> > From: Mark Kettenis
> >
> > The diff below is a preliminary diff to fix a suspend/resume issue on
> > recent Thinkpads. This needs testing on a wider range of laptops to
> > make
On Mon, Aug 23, 2021 at 08:57:59AM -0500, joshua stein wrote:
> On Sun, 22 Aug 2021 at 22:37:51 -0600, Thomas Frohwein wrote:
[...]
> > I thought I had the same problem on my new Asus Expertbook B9400CEA.
> > During boot, while reordering libraries and later it would print:
> &g
On Sun, Aug 22, 2021 at 09:50:15PM -0500, joshua stein wrote:
> On a particular laptop with a touchpad behind ihidev, dwiic would
> report a timeout every time it had to fetch touch data:
>
> dwiic0: timed out reading remaining 2
>
> On re-reading the i2c HID spec, the size supplied by
On Wed, 7 Apr 2021 17:00:00 -0700
Mike Larkin wrote:
> Depends on the exact content that got swapped out (as we didn't handle
> TLB flushes correctly), so a crash was certainly a possibility.
> That's why I wanted to see the VMM_DEBUG output.
>
> In any case, Thomas should try -
> > Thomas: I looked at your host dmesg and your provided vm.conf. It
> > looks like 11 vm's with the default 512M memory and one (minecraft)
> > with 8G. Your host seems to have only 16GB of memory, some of which
> > is probably unavailable as it's used by the integrate
On Tue, 6 Apr 2021 14:28:09 -0700
Mike Larkin wrote:
> On Tue, Apr 06, 2021 at 09:15:10PM +0200, Thomas L. wrote:
> > On Tue, 6 Apr 2021 11:11:01 -0700
> > Mike Larkin wrote:
> > > Anything in the host's dmesg?
> >
>
> *host* dmesg. I think you misread what I
On Tue, 6 Apr 2021 11:11:01 -0700
Mike Larkin wrote:
> Anything in the host's dmesg?
Below is the dmesg and latest syslog from one of the VMs.
OpenBSD 6.8 (GENERIC) #1: Tue Nov 3 09:04:47 MST 2020
r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem =
debugging this?
Kind regards,
Thomas
switch internal {
interface bridge0
locked lladdr
group internal
}
vm relay {
disk /data/vmd/relay.qcow2
interface {
switch internal
lladdr fe:e1:ba:d0:00:03
}
}
vm schleuder
On Sat, Mar 13, 2021 at 11:34:29AM +, Stuart Henderson wrote:
> Nothing changed in umb(4) since 6.8-release. The change last year was
> between 6.7 and 6.8 ("IPv6 is no longer on by default. It must be
> enabled with "inet6 eui64").
It seems that the issue I had was not related to OpenBSD but
I can get an IPv6 address with my LTE-Modem via umb with 6.8-release but
not with -current. I am aware that there was some discussion last year
on IPv6 support in umb but I'm not really sure what has changed. In
both cases I do get IPv4.
I use the following config:
$ cat /etc/hostname.umb0
multiple trials including powercycle.
Full dmesg from bsd.upgrade below.
Kind regards,
Thomas
OpenBSD 6.9-beta (RAMDISK_CD) #356: Tue Mar 2 10:50:43 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8465113088 (8072MB)
avail mem = 8204537856 (7824MB
On Fri, Jan 15, 2021 at 06:32:04AM -0700, Thomas Frohwein wrote:
> On Sat, Jan 09, 2021 at 10:50:35AM -0700, Thomas Frohwein wrote:
> > Hi,
> >
> > This diff adds support for the XBox One gamecontroller in a similar way
> > to what we have for the (older) XBox 360 c
On Wed, Feb 03, 2021 at 08:30:42PM +0100, Marcus Glocker wrote:
> On Sun, Jan 31, 2021 at 07:05:29PM +0100, Thomas Jeunet wrote:
>
> > Hello tech,
> >
> > in ugen_set_config, the cached config descriptor (ugen.c:213) is
> > obsolete after the call to usbd_s
t
I haven't yet fully audited how the variable is used.
--
Thomas Jeunet
Index: ugen.c
===
RCS file: /var/cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.113
diff -u -p -r1.113 ugen.c
--- ugen.c 28 Jan 2021 12:50:28 -0
uhidev?"
.Cd "umstc* at uhidev?"
@@ -73,6 +74,7 @@ only dispatches data to them based on th
.Xr ucycom 4 ,
.Xr ugold 4 ,
.Xr uhid 4 ,
+.Xr ujoy 4 ,
.Xr ukbd 4 ,
.Xr ums 4 ,
.Xr umstc 4 ,
Index: share/man/man4/ujoy.4
===
RCS file: share/man/man4/ujoy.4
diff -N
On Sat, Jan 09, 2021 at 10:50:35AM -0700, Thomas Frohwein wrote:
> Hi,
>
> This diff adds support for the XBox One gamecontroller in a similar way
> to what we have for the (older) XBox 360 controller [1][2]. This diff
> is based on the pertinent code in NetBSD's uhidev.c.
&g
On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
> On Thu, Jan 07, 2021 at 08:20:35PM +0100, Marcus Glocker wrote:
>
> > > I have heard from others who tried the diff that the PS4 controller is
> > > causing problems with the way it attaches. I ordered one to trial-and-
> > > error
On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
[...]
> So the problem doesn't seem to be in your new ujoy(4) code, but how the
> dev/hid/hid.c:hid_is_collection() function tries to cope with the PS4
> controller.
>
> I'm not much in to HID, but when I sync up the
Hi,
This diff adds support for the XBox One gamecontroller in a similar way
to what we have for the (older) XBox 360 controller [1][2]. This diff
is based on the pertinent code in NetBSD's uhidev.c.
Similarities include that the device doesn't provide a report
descriptor, so this diff adds one
On Sat, Nov 21, 2020 at 08:10:03AM +0200, Timo Myyrä wrote:
> Hi,
>
> The last attempt at adding Kensington Slimblade trackball support seems
> to have stalled:
> https://marc.info/?l=openbsd-tech=147444999319756=2
>
> I tested the diff and it still seems apply with little fuzz and works
> with
On Wed, Jan 06, 2021 at 10:48:58PM +0100, Marcus Glocker wrote:
[...]
> The implementation as such looks fine to me.
> But I quickly gave the diff a spin before on amd64 using my PS
> controller, and the result is not what I would expect.
>
> With uhid, I can access the controller on
om 4 ,
.Xr ugold 4 ,
.Xr uhid 4 ,
+.Xr ujoy 4 ,
.Xr ukbd 4 ,
.Xr ums 4 ,
.Xr umstc 4 ,
Index: share/man/man4/ujoy.4
===
RCS file: share/man/man4/ujoy.4
diff -N share/man/man4/ujoy.4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man4/ujoy.4 28 Dec 2020 03:25:31 -
Hi timo
On Sat, Nov 21, 2020 at 08:10:03AM +0200, Timo Myyrä wrote:
> Hi,
>
> The last attempt at adding Kensington Slimblade trackball support seems
> to have stalled:
> https://marc.info/?l=openbsd-tech=147444999319756=2
Thanks for digging this up. I got a Slimblade, but have been using
; 2) {
- sr_error(sd->sd_sc, "%s requires two or more chunks",
+ if (no_chunk < 1) {
+ sr_error(sd->sd_sc, "%s requires one or more chunks",
sd->sd_name);
return
On Sun, Sep 13, 2020 at 09:23:36AM +0100, Laurence Tratt wrote:
> Since I recently opened my big fat mouth and suggested that
> "kern.video.record" (analogous to kern.audio.record) might be a good idea, I
I support this suggestion. I think the idea behind it is based on the
same concerns that led
The present patch changes the rc.subr(8) manual page to match
the implementation.
The current manual page for rc.subr(8) says that $pexp is "A regular
expression to be passed to pgrep(1) in order to find the desired process
or to be passed to pkill(1) to stop it."
The file /etc/rc.d/rc.subr
Hello,
I was using base gcc but switching to base clang fixes the warnings on
-current at least.
Is base gcc not supported anymore ?
Sorry for the noise.
Cheers,
Le jeu. 5 mars 2020 à 16:59, Theo de Raadt a écrit :
>
> Todd C. Miller wrote:
>
> > On Thu, 05 Mar 2020 16:07:48 +
Actually I see the same problem on 6.6-stable :
including readline/readline.h produces warnings.
Any -Werror hope some day ?
cheers
Le mer. 4 mars 2020 à 13:41, Thomas de Grivel a écrit :
>
> With latest OpenBSD snapshot on amd64
>
> In file included from /usr/include/readline/c
rev
3.00/1.00 addr 1
uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev
3.00/1.00 addr 1
ugen0 at uhub1 port 1 "Intel Bluetooth" rev 2.00/0.02 addr 2
uhub2 at uhub1 port 2 configuration 1 interface 0 "Genesys Logic
USB2.0 Hub" rev 2.00/60.52
On Tue, Jan 21, 2020, at 7:10 PM, Mark Kettenis wrote:
> The attached diff fixes amdgpu(4) and might very well fix radeondrm(4)
> as well.
[...]
For the record, this fixes running piglit with radeon on my HD7570 since this
was committed. It used to lock up on the test spec/arb_sync/sync_api,
On Thu, 5 Dec 2019 13:35:40 +
"Lindner, Thomas 1. (Nokia - DE/Nuremberg)"
wrote:
> The (untested) patch below makes login_passwd behave as described in
> the manpage.
I've now been able to test the patch and login/su/doas/ssh still work
as expected. All the other login_
issue
reject silent and then exit with a 0 status.
So I checked and indeed:
# /usr/libexec/auth/login_passwd -schallenge foo 3>&1
authorize
The (untested) patch below makes login_passwd behave as described in the
manpage.
Kind regards,
Thoma
My bad, SBCL uses the libc's wrappers indeed looking at the sources.
Le ven. 29 nov. 2019 à 22:41, Josh Elsasser a écrit :
>
> On Fri, Nov 29, 2019 at 10:12:10AM +0100, Thomas de Grivel wrote:
> > Maybe Go is not the only problem, I see SBCL compiling syscalls too.
> >
> >
o avoid calling the libc stubs?
> I don't believe so. Especially if those segments are in network facing
> programs and/or generated on the fly. At worst a nasty JIT can generate code
> to call & of libc syscall(2) stub with SYS_* symbolic names. That approach
> remains simple and workable for the developer, but somewhat more difficult for
> an attacker who not know the relevant locations.
>
--
Thomas de Grivel
kmx.io
-a | grep mpls
net.mpls.ttl=255
net.mpls.mapttl_ip=1
net.mpls.mapttl_ip6=0
--
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "tho...@habets.se" };
char kernel[]= { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pu
net.mpls.mapttl_ip6=0
--
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "tho...@habets.se" };
char kernel[]= { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { "9907 8698
APERM);
> + histbase = reallocarray(NULL, histsize + 1, sizeof(char *));
> + if (histbase == NULL)
> + internal_errorf("allocating history storage: %s",
> + strerror(errno));
> *histbase = NULL;
&g
This can be hard to debug, and could indeed prevent debugging, since
it can take out the ability to run /bin/sh, depending on how you've
set up your environment.
Before:
$ HISTSIZE=10 /bin/sh
/bin/sh: internal error: unable to allocate memory
<--- no ksh
With this pa
$
On Thu, Jun 06, 2019 at 11:41:07PM +0200, Mark Kettenis wrote:
[...]
> It seems to work fine on my Intel Broadwell laptop. I haven't tested
> this on radeon(4) yet. So further testing, especially on systems with
> 4GB of memory or more is necessary.
>
> Please test.
Tested on a desktop with
acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", "u=
ri": "https://acme-v01.api.letsencrypt.org/acme/challenge/x1Rh_VhMUuYxk_v22=
zHe32fL2zh7sRNh2LSKFNwkqxA/11749932858", "token": "FF1lMKPyjmEeEURPWUyLwBe8=
ZRj3ozkdUGkyfOmGT5s", "keyAuthorization": "FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkd=
UGkyfOmGT5s.YJLLEKdoM4e4WocQ9C9xvXqa6dAO4zUn6hdCgEgIfBs" }] (337 bytes)=
=
=20
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/x1Rh_VhMUu=
Yxk_v22zHe32fL2zh7sRNh2LSKFNwkqxA/11749932858: status =
=
=20
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificat=
e
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: bad HTTP: =
403
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "de=
tail": "Error creating new cert :: authorizations for these names not found=
or expired: lists.dl6tom.de", "status": 403 }] (171 bytes)=
=20
acme-client: bad exit: netproc(64946): 1
The token in /var/www/acme seems fine as far as I am able to judge:
# cat /var/www/acme/FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkdUGkyfOmGT5s
FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkdUGkyfOmGT5s.YJLLEKdoM4e4WocQ9C9xvXqa6dAO4zU=
n6hdCgEgIfBs
Kind regards
Thomas Lindner
On Sat, 5 Jan 2019 17:56:01 -0800
Mike Larkin wrote:
> Did you kill all the old vmd processes?
>
> -ml
>
I tested again and it works now. There were restarts in between.
I will try killing vmd processes if this happens again, thanks.
Kind regards,
Thomas
that it can't open the disk (log snippet
below).
Is the qcow2 image somehow locked and can I unlock it?
Or is it corrupted? If so, is it recommanded using qcow2 images or are raw
images more robust?
Kind regards,
Thomas
Jan 4 16:00:52 hilbert vmd[76370]: startup
Jan 4 16:00:52 hilbert vmd
Since cscope supports C++, would the team accept a patch that updates
the fnmatch
in do_cscope to recognize .cc, .cpp and .hpp files?
plus it's really 6 new lines in rc.subr, no big deal.
Le mar. 4 sept. 2018 à 10:53, Thomas de Grivel a écrit :
>
> why ? well all interactive process get a quarter range nice priority
> advance compared to all daemon tasks, at least for a laptop
> environment it really makes s
ter, but
if you don't like it nobody foces you huh ?
--
Thomas de Grivel
http://kmx.io
Le mar. 4 sept. 2018 à 07:57, Alexandre Ratchov a écrit :
>
> On Tue, Sep 04, 2018 at 04:58:53AM +0200, Thomas de Grivel wrote:
> >
> > And I still feel the default nice priority of 10 is r
at 10:34:51PM +0200, Thomas de Grivel wrote:
> > Hello,
>
> Hi.
>
> > Following patch allows sysadmins to configure nice values for RC daemons.
> > Default nice value is set to 10 as I wish to prioritize interactive
> > applications over system daemons and I thin
Le lun. 3 sept. 2018 à 23:33, Philip Guenther a écrit :
>
> On Mon, Sep 3, 2018 at 11:46 AM Thomas de Grivel wrote:
>>
>> I was browsing the DRM code ported from Linux and it's a terrible
>> mess, is there any ongoing project to clean up that codebase o
I was browsing the DRM code ported from Linux and it's a terrible
mess, is there any ongoing project to clean up that codebase or
rewrite it entirely ?
--
Thomas de Grivel
me know if it is of any interest to you.
commit 1f4121df3ae31121d435571ffdbd93a20c1e8a07
Author: Thomas de Grivel
Date: Mon Sep 3 21:52:37 2018 +0200
Add a $daemon_nice parameter.
If not overriden by the launched daemon the default nice value is 10.
See nice(1) for more details
Hi,
It appears that HD Audio from AMD's generation Ryzen can't handle MSI.
This leads to the bug that I reported here:
https://marc.info/?l=openbsd-bugs=151648196215922=2
Disabling MSI resolves the problem on my current system which is a Raven
Ridge APU. I don't have the Summit Ridge hardware
Hi,
This is a diff to add a bunch of AMD Summit Ridge (17h) and Raven Ridge
PCI devices. It's in preparation of an upcoming diff for these that I've
worked on in collaboration with brynet@.
The link to http://www.pcidatabase.com/ in the comments for pcidevs
isn't retrievable anymore. I have
think that my suspicion is correct? Would you consider that to
be a bug?
Thanks!
Thomas Munro
Same as the rejected patch for the temporary 63.html, but this time for a
relevant page.
--- 62.html.orig2018-03-16 14:17:49.0 +0100
+++ 62.html 2018-03-16 14:18:07.0 +0100
@@ -180,9 +180,9 @@
MiRA 802.11n TX rate scaling now supports devices with unequal
Typo fix for 802.11 driver man page links
--- 63.html.orig2018-03-16 12:41:10.0 +0100
+++ 63.html 2018-03-16 12:42:36.0 +0100
@@ -181,9 +181,9 @@
MiRA 802.11n TX rate scaling now supports devices with unequal numbers
of Tx and Rx streams. Fixes 11n
In December, I found the mono port in a state where it only built with the
(deprecated) mcs compiler, and it would catch a SIGABRT predominantly when
exiting applications (including any call to the newer csc/roslyn compiler).
I've since made what seems like partial progress with mono's
The following patch use the proper address space when using a kernel
with FUSE_DEBUG (kernel instead of user, see the copyin above). While
here, add some sanity check to the debug function fuse_dump_buff.
--
Thomas Jeunet
Index: sys/miscfs/fuse/fuse_device.c
.
IKEV2_CRITICAL_PAYLOAD is only used to create a log message in
ikev2_pld_payloads (ikev2_pld.c), so the impact of this bug is small,
but correctly logging whether a payload is critical seems useful.
Best regards,
Thomas
--- a/ikev2.h
+++ b/ikev2.h
@@ -78,7 +78,7 @@ struct ikev2_payload
Am 09.11.2016 um 20:36 schrieb Vincent Gross:
> On Wed, 9 Nov 2016 13:16:46 +
> Thomas Klute <thomas.kl...@achelos.de> wrote:
>
>> Hi tech@,
>>
>> this patch contains fixes for two bugs that break IKE rekeying
>> initiated by iked. Please re
(see
comment in the patch for details).
This patch includes and supersedes the one for only the first bug I
sent yesterday.
Best regards,
Thomas
[1] https://marc.info/?l=openbsd-bugs=147739504516767=2
[2] https://marc.info/?l=openbsd-bugs=147747405806461=2
Index: src/sbin/iked/ikev2.c
Hi tech@,
a week ago I reported to bugs@ that iked "forgets" the local and peer addresses
associated with an IKE SA while rekeying it if iked has initiated the rekeying,
breaking any IKE requests iked tries to send after rekeying [1]. The patch
below fixes the bug by copying the addresses from
Hi,
I just updated from a 5.7-current snapshot (15th June) to a recent one
(29th June).
Now, when I try to 'startx' I get the following error:
$ startx
xauth: (stdin):1: bad display name turin.local:0 in add command
/usr/X11R6/bin/X: can't load library 'libfreetype.so.24.0'
xinit: giving up
Regards,
Thomas
[1] http://marc.info/?l=openbsd-miscm=115272548814461w=2
Index: src/sbin/dmesg/dmesg.8
===
RCS file: /cvs/src/sbin/dmesg/dmesg.8,v
retrieving revision 1.15
diff -u -p -u -r1.15 dmesg.8
--- src/sbin/dmesg/dmesg.8 13
In the most recent algorithms lecture I heard we used log for base 2, ln for
base e, and lg for base 10. But asymptotically the base doesn't matter and the
notation coventions differ. So I'd also go for consistency with other
documentation.
On March 3, 2015 5:48:20 PM CET, frantisek holop
hi,
when playing around with the brainpool curves we realised that trying to
establish a tls connection between s_server and s_client using brainpool
curves always ended with a handshake error. it seems 3 lines were missed
when merging a change from openssl[1].
attached patch removes one tab
This doesn't fix the problems, only removes markers alerting us
to audit it.
Memory management in these files is still missing integer overflow
checks, NULL return checks, and is full of crazy abominations [...]
Yes, I saw that but I thought I'd take care of one thing first
then send
Don't cast {m,re}alloc. No point and it's inconsistent already.
Index: apps.c
===
RCS file: /cvs/src/lib/libssl/src/apps/apps.c,v
retrieving revision 1.42
diff -u -p -r1.42 apps.c
--- apps.c 22 Apr 2014 14:54:13 - 1.42
replacement within OpenBSD to be beneficial? Do you have an example?
2. Common and universal error type, qc_error. Such errors can be generated
from errno values as well as from Windows API errors.
Welcome to strerrno()
[...]
-- Thomas Adam
Add IDs for Elan Microelectronics barcode scanner (from usb.ids).
uhidev1 at uhub3 port 4 configuration 1 interface 0 vendor 0x04f3 product
0x0001 rev 1.10/1.00 addr 3
uhidev1 at uhub3 port 4 configuration 1 interface 0 Elan Microelectronics
Corp. Barcode Scanner rev 1.10/1.00 addr 3
Index:
Add ATI Radeon HD 7850 and 7850 HD Audio to pcidevs.
Verified with the Windows driver information (I was
unable to find these ids anywhere else).
Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1664
On Sun, 13 Jan 2013 12:18:50 + (UTC)
Alexey E. Suslikov alexey.susli...@gmail.com wrote:
Thomas Pfaff tpfaff at tp76.info writes:
product ATI RADEON_HD6400_HDA 0xaa98 Radeon HD 6400 Audio
+product ATI RADEON_HD7850_HDA 0xaab0 Radeon HD 7850 HD Audio
I think 7850 audio
On Mon, 19 Nov 2012 18:44:23 +0100
Thomas Pfaff tpf...@tp76.info wrote:
Add ATI Radeon HD 7850 to pcidevs.
Sorted by PCI ID this time (dmesg also included).
Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving
1 - 100 of 188 matches
Mail list logo
