On Mon, May 20, 2024 at 11:53:26AM +0200, Martin Pieuchot wrote:
> On 19/05/24(Sun) 23:50, Vitaliy Makkoveev wrote:
> >
> >
> > > On 19 May 2024, at 22:05, Anthony J. Bentley wrote:
> > >
> > > Vitaliy Makkoveev writes:
> > >>> On 17 May 2024, at 12:06, Stuart Henderson =
> > >> wrote:
> >
Hi,
On OpenBSD 7.5 and -current tcpdump on pfsync interfaces stopped
working. Morover running it with malloc_conf=S make it dump core.
How to repeat ?
Setup a pair of firewalls with carp(4) and pfsync(4).
Run tcpdump -n -i pfsync0 on one of the firewalls.
Expected result
In OpenBSD 7.3 one
On Sat, Apr 27, 2024 at 07:20:15PM +0200, Kirill A. Korinsky wrote:
> On Sat, 27 Apr 2024 19:06:40 +0200,
> Matthieu Herrb wrote:
> >
> > Does your Xorg.0.log say "X.Org X Server 1.21.1.12" or
> > "X.Org X Server 1.21.1.13" ?
> >
>
There was a regression in Xorg 21.1.12 that may be the cause. It's
supposed to be fixed by 21.1.13 (it should be in recent snapshots).
--
Matthieu Herrb
X11 that it crashes, and
> how can I future debug it?
>
> I've tried to create folders for core dump as:
>
> ~ $ ls -l /var/crash
> total 12
> drwxrwxrwx 2 root wheel 512 Apr 27 14:05 X
> drwxrwxrwx 2 root wheel 512 Apr 27 14:00 X11
> -rw-r--r-- 1 root wheel 5 Oct 10 2023 minfree
> ~ $
>
The binary is Xorg. so create /var/crash/Xorg
--
Matthieu Herrb
dn't change. It's your user session that is
now failing (but shouldn't...). There's probably a typo somewhere.
The error message is probably in ~/.xsession-errors or in
/var/log/xenodm.log
--
Matthieu Herrb
chromium and/or firefox. check
/etc/chromium/unveil.* and /etc/firefox/unveil.* files.
remove them and re-install the packages to make sure you have the
correct ones (or copy them back from /usr/local/share/examples/)
--
Matthieu Herrb
n
advance by running :
fw_update amdgpu
If this works, see the config(8) manual page for details to save the
modified kernel.
--
Matthieu Herrb
@ xcb_connection_t *xcb_connect_to_display
>
> if(auth) {
> c = xcb_connect_to_fd(fd, auth);
> -goto out;
> }
> -
> -if(_xcb_get_auth_info(fd, , display))
> +else if(_xcb_get_auth_info(fd, , display))
> {
> c = xcb_connect_to_fd(fd, );
> free(ourauth.name);
>
--
Matthieu Herrb
Thanks for your report.
Could you also send us the /var/log/Xorg.0.log.old file (once xenodm has
restarted) so that we can see the exact crash from the Xorg server ?
Thanks.
--
Matthieu Herrb
le((g_argv[j] != NULL)&&(i<8))
{
if(strcmp(g_argv[j],"-s")!=0)
--
Matthieu Herrb
fault of the upgrade to libpciaccess 0.17 that I
committed 2 days ago. I've just added a fix. It will be in a future
snapshot.
--
Matthieu Herrb
On Sun, Nov 06, 2022 at 07:07:06AM -0700, Todd C. Miller wrote:
> On Sun, 06 Nov 2022 10:44:10 +0000, Matthieu Herrb wrote:
>
> > Thanks for the report. You're right that this was overlooked when I
> > wrote this code.
> >
> > I'd suggest the more complete (and paran
t; * argvmay be NULL (error from kvm_getargv(3))
> > * argv[0] may be NULL (cmd withheld by application)
> > */
> > if (argv == NULL || argv[0] == NULL)
> > *cmdname = strdup("");
> > else
> > *cmdname = strdup(argv[0]);
>
--
Matthieu Herrb
build the X server once more with :
doas make -f Makefile.bsd-wrapper build CFLAGS="-O0 -g"
Once it has crashed, you should have a Xorg.core file in your home
directory. To get a backtrace install egdb from packages (pkg_add gdb)
and run it
egdb /usr/xobj/xserver/hw/xfree86/Xorg Xorg.core
inside egdb run the 'bt' command.
--
Matthieu Herrb
On Tue, Aug 30, 2022 at 03:35:56PM +0200, Walter Alejandro Iglesias wrote:
> On Aug 29 2022, Matthieu Herrb wrote:
> > On Sat, Aug 27, 2022 at 01:07:30PM +0200, Walter Alejandro Iglesias wrote:
> > > X crashes when moving cursor from keyboard bindings. I can reproduce
> >
_unlock();
return;
+}
input_options = input_option_new(input_options, "name", strdup(path));
input_options = input_option_new(input_options, "driver", strdup(driver));
@@ -213,6 +220,7 @@
}
unwind:
input_option_free_list(_options);
+input_unlock();
}
static void
--
Matthieu Herrb
thok || priv_pw_check(user, pass, style));
#elif defined(BSD_AUTH)
char *pass;
char *style;
--
Matthieu Herrb
veil to xlock during r2k22, but I wonder what.
Unfortunatly since xlock is setgid, ktracing it is not trivial...
--
Matthieu Herrb
k other applications that use
unveil and need to handle fontconfig (chromium and the mozillas come
to my mind) know about those variables.
--
Matthieu Herrb
"r");
unveil("/var/cache/fontconfig", "r");
unveil("/usr/local/share/icons", "r");
--
Matthieu Herrb
cation in ports where these message
cause it to mal-function.
There are fonts with those encoding available in ports (and it's still
possible to package the fonts with extra encodings in ports if there
is a real need -- but it didn't show up yet).
--
Matthieu Herrb
rent branch)
He also started some documentation on the internals there :
http://lab.knightsofnii.com/kristaba/openbsd-drm-howto.git
*warning* : all this is 7 years old so a lot have changed in the Linux
DRM code since then and merging this code in -current is probably
more work than starting over.
--
Matthieu Herrb
o do all the modes management I mentionned above).
And I'm not sure there is interest to make the OpenBSD grow by some kB
to support those ancient cards. But it can be a fun project.
--
Matthieu Herrb
s call to free() in the error path of a failed memory
allocation. You're very unlikely to have reached that code branch in a
normal situation.
Without a way to reproduce the crash and without a stack trace, it's
going to be hard to tell where the bug is or to fix it.
--
Matthieu Herrb
that jwm is causing this
kind of issue.
Could you try with another window manager (fvwm, cwm, or one from
ports) and see if you can reproduce ?
Or may be you just restarted the X server twice after a crash and lost
the Xorg.0.log.old with the actual error.
Please tell me what you can find.
--
Matthieu Herrb
On Mon, Nov 15, 2021 at 11:50:41AM +0100, Peter N. M. Hansteen wrote:
> On Sun, Nov 14, 2021 at 12:25:45PM +0100, Matthieu Herrb wrote:
> > On Sun, Nov 14, 2021 at 10:44:40AM +0100, Peter N. M. Hansteen wrote:
> > > On Sat, Nov 13, 2021 at 12:16:22PM +0100, Ma
ything special you do to reproduce the crash ?
(application, window manager,. specific input devices ... )
The XAllowEvent() call that seem to cause it is not used by any
application in base as far as I can see. So this code path in the X
server is not tested often, but this area got quite some churn during
the 1.20 -> 21.1 release cycle...
--
Matthieu Herrb
le containing just the 4
lines below ? The intel(4) driver has not been updated for a while and
is almost abandonned upstreams. Your hardware should work with
modesetting(4) too:
Section Device
Identifier "modesetting"
Driver "modesetting"
EndSection
--
Matthieu Herrb
On Sun, Nov 14, 2021 at 10:44:40AM +0100, Peter N. M. Hansteen wrote:
> On Sat, Nov 13, 2021 at 12:16:22PM +0100, Matthieu Herrb wrote:
> >
> > did I miss something or is this still pending ?
>
> I just tested, the problem unfortunately persists.
Strange, it wor
On Mon, Nov 01, 2021 at 06:53:38PM +0100, Matthieu Herrb wrote:
> On Mon, Nov 01, 2021 at 12:30:19PM +0100, Landry Breuil wrote:
> > Le Mon, Nov 01, 2021 at 12:15:01PM +0100, Matthieu Herrb a écrit :
> > >
> > > The problem I see with this approach is that it prov
On Mon, Nov 01, 2021 at 12:30:19PM +0100, Landry Breuil wrote:
> Le Mon, Nov 01, 2021 at 12:15:01PM +0100, Matthieu Herrb a écrit :
> >
> > The problem I see with this approach is that it provides a tool that
> > make it possible to do brute-force password check
The problem I see with this approach is that it provides a tool that
make it possible to do brute-force password checking.
I think that a solution where main screensaver process keeps the setgid
auth bit, forks a privileged child to do the password check and
revokes it's setgid privilege is better. But I'd like hear other
people on this (millert@, kn@,...)
But whether glib will properly recognise that the process doesn't have
privileges anymore is an open question before someone has looked at
the code or tried it.
--
Matthieu Herrb
On Sun, Oct 31, 2021 at 09:48:53PM +0100, Landry Breuil wrote:
> Le Sun, Oct 31, 2021 at 09:39:35PM +0100, Matthieu Herrb a écrit :
> > On Fri, Oct 29, 2021 at 10:33:04AM +0200, Peter N. M. Hansteen wrote:
> > > On Fri, Oct 29, 2021 at 10:05:34AM +0200, Landry Breuil wrote:
>
/libexec/xfce4-screensaver-dialog
which fails with the following error:
** (xfce4-screensaver-dialog:72106): ERROR **: 21:36:25.353: Failed to
connect to xfconf daemon: Cannot spawn a message bus when setuid.
I don't know much about xfconf / dbus / setuid applications
interactions, but this doesn't look like something related to changes
in base.
--
Matthieu Herrb
g).
Anyways it looks like ypu're trying to run OpenBSD/i386 on a machine
that's capable of running the 64 bits (amd64) version.
There are known issues with OpenBSD/i386 in this kind of situation. So
try to install OpenBSD/amd64 instead and report back.
--
Matthieu Herrb
sizeof(cpu_model) - strlen(cpu_model),
" (Revision 0x%x)", pvr & 0x);
--
Matthieu Herrb
d me of the commit message for
pixman/pixmman-vmx.c 1.9 :
| revert pixman-vmx.c to the version of pixman-0.32.8.
| gcc 4.2 is not able to compile the new version.
| XXX switch back to 0.34 once macppc switches to clang.
I need to check that too ... before committing 0.40...
--
Matthieu Herrb
ads me to wonder if KARL could have an impact on the
issue in case there is some un-initialized memory access somewhere in
the code...
>
> All the best,
> Peter
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
--
Matthieu Herrb
river "modesetting"
EndSection
Otherwise if you have time for tihs, can you try to get an X
backtrace, (see /usr/xenocara/README for instructions, possibly
outdated...)
--
Matthieu Herrb
ich
.Nm
-presents, offers the familiar login and password prompts, unless
+presents.
+The xlogin widget offers the familiar login and password prompts.
+.PP
+If
.Ic autoLogin
-is set.
+is set the designated user is automatically logged in.
.Pp
-After the user logs in,
+After the user logged in,
.Nm
runs the
.Pa Xstartup
--
Matthieu Herrb
eedesktop.org/xorg/driver/xf86-video-ati/-/commit/c0eb5dbd9c1db6b6d5b1574bcd8c584170d7ab54
Yes that looks like the problem... We can probably merge this commit.
>
> The modesetting driver is used with startx which is why you don't see
> that there.
>
> I am not sure why the ring test fails on ES1000. I had another report
> off list of it failing on a system with ES1000.
No idea here.
--
Matthieu Herrb
ot dependant on the
layout and translates them to keysyms depending on the XKB
configuration.
wsconsctl is for the console. X only looks at the current wsconsctl
seting on startup to set the initial XKB config.
IF you change wsconsctl settings while X is running it should have no
effect. And setxkbmap should have no effect on the wsconsctl settings
either.
Could you check with xev which keysyms are produced by M-slash before
and after changing the XKB config ?
--
Matthieu Herrb
Hi,
Trying to look at IPv6 traffic on my wireguard VPN with
tcpdump -n -i wg0 ip6
also shows all IPv4 traffic. Other interfacees seem to filter the v6
protocol correctly.
Any suggestion before I try to dig into the kernel code (which I'm not
really familiar with) ?
--
Matthieu Herrb
Exp $
-xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail
-
xsetroot -fg \#6f6f6f -bg \#bfbfbf -bitmap
/usr/X11R6/include/X11/bitmaps/root_weave
+
+xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail
# install package openbsd-backgrounds
# then uncomment:
Can you confirm it ?
--
Matthieu Herrb
vh, VGA_DAC_WRITE, 0x00);
> for (i = 0; i < 3 * 256; i++)
> vga_raw_write(vh, VGA_DAC_DATA, *palette++);
> -
> - vga_raw_read(vh, 0x0a); /* reset flip/flop */
> -
> - vga_enable(vh);
> }
>
> void
--
Matthieu Herrb
e against the system libz for the actual
decompression code. (ie FT_CONFIG_OPTION_USE_ZLIB is defined in
ftoption.h)
--
Matthieu Herrb
or the looping X
server case ? I looks like xenodm fails to start the login widget for
some reason. There may be some information there.
You can also try to run xenodm -debug 255 > xenodm.log 2>&1 as root
and look at / send the resulting log file.
--
Matthieu Herrb
4 and 5
[ 2043.204] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type:
MOUSE, id 7)
[ 2043.207] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1
[ 2043.207] (**) /dev/wsmouse: (accel) acceleration profile 0
[ 2043.208] (**) /dev/wsmouse: (accel) acceleration factor: 2.000
[ 2043.208] (**) /dev/wsmouse: (accel) acceleration threshold: 4
--
Matthieu Herrb
BoxPtr pbox = REGION_RECTS (damage);
--
Matthieu Herrb
define NUM_TARGETS 6
> #endif
> Atom* std_targets = (Atom*)XtMalloc(NUM_TARGETS*sizeof(Atom));
> int i = 0;
> std_targets[i++] = XA_TIMESTAMP(d);
> std_targets[i++] = XA_HOSTNAME(d);
> +#ifdef TCPCONN
> std_targets[i++] = XA_IP_ADDRESS(d);
> +#endif
> std_targets[i++] = XA_USER(d);
> std_targets[i++] = XA_CLASS(d);
> std_targets[i++] = XA_NAME(d);
--
Matthieu Herrb
memcpy(*value, , sizeof(addr));
+ *type = XA_NET_ADDRESS(d);
+ *format = 8;
+ return True;
+#endif
}
#endif
if (*target == XA_USER(d)) {
--8<------
/*
* Copyright (c) 2020 Matthieu Herrb
*
* Permiss
On Sat, Jan 11, 2020 at 05:47:05PM +, Stuart Henderson wrote:
> On 2020/01/11 17:24, Matthieu Herrb wrote:
> > On Tue, Jan 07, 2020 at 09:00:04PM +0100, Benjamin Baier wrote:
> >
> > Hi,
> >
> > While I've been able to write a small application that repro
configuration there ? (running over an SSH
tunnel, or anything that might trigger a decision to get the IP
address of the selection owner...)
Trying to find where this is done in the claws-mail/gtk+2/
dependencies is indeed not simple...
--
Matthieu Herrb
X backtrace (following the instructions in
/usr/xenocara/README on how to get a core file, and then running egdb
from ports on it) ? or at lease provide us the /var/log/Xorg.0.log
file from a crash ?
Thanks in advance.
--
Matthieu Herrb
n...).
Please look at /var/log/Xorg.0.log.old for any error messages.
--
Matthieu Herrb
On Mon, Oct 21, 2019 at 11:19:57AM +0200, Matthieu Herrb wrote:
> On Mon, Oct 21, 2019 at 09:52:57AM +0100, Stuart Henderson wrote:
> > On 2019/10/21 10:44, Matthieu Herrb wrote:
> > > I've observed this on several of our VMs after upgrading them to OpenBSD
> > >
On Mon, Oct 21, 2019 at 09:52:57AM +0100, Stuart Henderson wrote:
> On 2019/10/21 10:44, Matthieu Herrb wrote:
> > I've observed this on several of our VMs after upgrading them to OpenBSD
> > 6.6.
>
> This has been a problem for ages with no suggested ideas for what might
ger) are you using ?
If it's XFCE, the have a look at the package readme, the part that
suggests tweking vblank_mode...
I don't see anything else significant that may have changed in the
last days (except perhaps some of the drm commits...).
--
Matthieu Herrb
strongly suggest that we simply delete the whole
> program from OpenBSD without any replacement. That is what we usually
> do with software that is broken, obviously unmaintained, and useless.
>
> Any objections?
>
None from me.
Not worth the effort to add mandoc.db support. Nowadays we can build
an electron app around man.openbsd.org if we need a replacement :)
--
Matthieu Herrb
On Thu, Aug 08, 2019 at 09:42:49AM +0200, Sebastien Marie wrote:
> On Wed, Aug 07, 2019 at 07:47:43PM +0200, Matthieu Herrb wrote:
> > On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
> > >
> > > I will also have a look on why did the extra built-in
On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
>
> I will also have a look on why did the extra built-in modes disapear.
> But I think that if you can run a better driver than xf86-video-vesa,
> it is better.
Hi again,
I think I've found the problem.
It's caused by
I have a machine wih a Radeon HD 2400 that works well. I just
need to recheck when I'm home this evening.
I will also have a look on why did the extra built-in modes disapear.
But I think that if you can run a better driver than xf86-video-vesa,
it is better.
--
Matthieu Herrb
On Sun, Aug 04, 2019 at 04:25:03PM +0200, Klemens Nanni wrote:
> On Sun, Aug 04, 2019 at 12:40:50PM +0200, Matthieu Herrb wrote:
> > Did you try with the updates to libX11 and libXft that I sent to tech@
> > a few weeks ago ? There is one change in libXft which may be relevant.
&g
bb9b36c780) at /x/app/cwm/kbfunc.c:484
> #8 0x0bb9389c3ffa in xev_handle_keypress (ee=0x7f7fa2a8) at
> /x/app/cwm/xevents.c:336
> #9 0x0bb9389c519d in xev_process () at /x/app/cwm/xevents.c:491
> #10 0x0bb9389b763f in main (argc=0, argv=0x7f7fa450) at
> /x/app/cwm/calmwm.c:114
--
Matthieu Herrb
it. So you say if I install it
> natively it would work fine?
Probably, yes. I'm using LibreOffice regularly under OpenBSD and it
works fine most of the time.
--
Matthieu Herrb
to get work done with LibreOffice, either consider
installing OpenBSD natively on your machine (so that a real
accelerated driver can be used to manage the display), or just install
an run LibreOffice on your host system.
The display under VirtualBox, without the Virtual Box extensions is
to be considered as unsupported.
--
Matthieu Herrb
ch may have its
own set of bugs, or expose bugs in the driver Xorg is using on
OpenBSD.
--
Matthieu Herrb
session, if i plug this screen, it's OK, too!
>
> If I start xenodm with the plugged external screen, once I log-in, I get
> back to xenodm login screen.
Are there any errors messages in ${HOME}/.xsession-errors ?
--
Matthieu Herrb
On Wed, May 22, 2019 at 12:31:48AM -0700, Mike Larkin wrote:
> On Wed, May 22, 2019 at 08:46:06AM +0200, Matthieu Herrb wrote:
> > Hi,
> >
> > The latest syspatch failed for me on one machine running syspatch:
> >
> > $ doas syspatch
> > G
ion 1 interface 0 "Generic Ultra Fast Media"
rev 2.00/1.98 addr 4
umass0: using SCSI over Bulk-Only
scsibus3 at umass0: 2 targets, initiator 0
sd1 at scsibus3 targ 1 lun 0: SCSI0 0/direct
removable serial.0424224000225001
sd1: 3776MB, 512 bytes/sector, 7733248 sectors
vscsi0 at root
scsibus4 at vscsi0: 256 targets
softraid0 at root
scsibus5 at softraid0: 256 targets
root on sd0a (d3f1a22c1d4f10ad.a) swap on sd0b dump on sd0b
--
Matthieu Herrb
x14200 bored smr
1 334494 0 0 3 0 initexec swapper
0 0 -1 0 3 0x10200 cfpendswapper
ddb> trace
db_enter(10,8000221c98c0,202,8,81817f60,8000221c98c0) at db=
_ent
er+0x10
panic(81ade306,81ade306,8000221b2bb8,8000221c4000,f=
fff8
000221c9a30,0) at panic+0x128
pageflttrap(8000221c9a30,0,fffc7b7e9fcec41a,8000221c9a30,6,0) at pa=
gefl
ttrap+0x2aa
kerntrap(8000221c9a30,8000221c9a30,c7bcebe1010315d3,0,0,81c=
fb96
0) at kerntrap+0x7c
alltraps_kern(6,81cfb960,8007ad80,10,0,0) at alltraps_kern+=
0x7b
0(8000221c9b20,8007ad80,85dc4a00f1d276b7,80073c00,f=
fff8
1725bba,0) at 0
Xintr_ioapic_level11_untramp(0,0,0,0,8001c200,800239c0) at =
Xint
r_ioapic_level11_untramp+0x1a3
acpicpu_idle(5d15791c772851f,0,81cf3ff0,0,81cf3ff0,0) at ac=
picp
u_idle+0x25e
sched_idle(81cf3ff0,81cf3ff0,0,0,81cf3ff0,8=
19dc
1a0) at sched_idle+0x1d5
end trace frame: 0x0, count: -9
ddb> show panic
attempt to execute user address 0x0 in supervisor mode
ddb>=20
--=20
Matthieu Herrb
019 15:50:16 -
> @@ -139,7 +139,9 @@ wscons_add_keyboard(void)
> break;
> }
> for (i = 0; kbdvar[i].val; i++)
> -if ((wsenc & kbdvar[i].val) == kbdvar[i].val) {
> +if ((wsenc & kbdvar[i].val) == kbdvar[i].val &&
> +(KB_ENCODING(wsenc) == KB_ENCODING(kbdvar[i].val) ||
> +!KB_ENCODING(kbdvar[i].val))) {
> LogMessageVerb(X_INFO, 3, "wskbd: using variant %s\n",
> kbdvar[i].name);
> input_options = input_option_new(input_options,
--
Matthieu Herrb
enodm
> >Fix:
> unknown
Hi,
Thanks for the report. can you check the contents of
/var/log/xenodm.log and send it here if there are any visible error
messages ?
--
Matthieu Herrb
On Mon, Mar 04, 2019 at 09:14:45AM +0100, Matthieu Herrb wrote:
> On Sat, Mar 02, 2019 at 10:24:22PM +0200, Mihai Popescu wrote:
> > Hello,
> >
> > I am able to generate a segmentation fault on X with chromium help.
> > This is happening each time I visit the
for (i = 0; i < cursor_size; i++) {
+ argb = image[i];
+ if (!drmmode_cursor_pixel(crtc, , ,
+ _gamma))
+ goto retry;
+
+ ptr[i] = cpu_to_le32(argb);
+ }
}
}
--
Matthieu Herrb
ng away from it to the modesettings driver. Hopefully the current
work on upgrading the kernel-side DRM code and the upcoming upgrade to
xserver 1,20.x will also improve the modesetting driver on OpenBSD, so
that less people will need to run the intel driver.
--
Matthieu Herrb
1]
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/README?rev=1.42=text/plain
--
Matthieu Herrb
t;832x624"x0.0 57.28 832 864
> 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816
> 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216
> 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376
> 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280
> 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1600x1000"x60.0 133.14 1600
> 1704 1872 2144 1000 1001 1004 1035 -hsync +vsync (62.1 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1600x1200"x0.0 162.00 1600
> 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1680x1050"x0.0 119.00 1680
> 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1920x1080"x60.0 172.80 1920
> 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "720x480"x0.0 27.00 720 736
> 798 858 480 489 495 525 -hsync -vsync (31.5 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1440x480i"x0.0 27.00 1440
> 1478 1602 1716 480 488 494 525 interlace -hsync -vsync (15.7 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1920x1080"x0.0 148.50 1920
> 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "720x576"x0.0 27.00 720 732
> 796 864 576 581 586 625 -hsync -vsync (31.2 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1440x576i"x0.0 27.00 1440
> 1464 1590 1728 576 580 586 625 interlace -hsync -vsync (15.6 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1920x1080"x0.0 148.50 1920
> 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
> [1050507.209] (EE) Segmentation fault at address 0xaae4da74000
> [1050507.216] (EE)
> Fatal server error:
> [1050507.216] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [1050507.216] (EE)
> [1050507.216] (EE)
> Please consult the The X.Org Foundation support
>at http://wiki.x.org
> for help.
> [1050507.216] (EE) Please also check the log file at
> "/var/log/Xorg.0.log" for additional information.
> [1050507.216] (EE)
> [1050507.218] (EE) ws: /dev/wsmouse: unknown command 4
> [1050507.218] (II) AIGLX: Suspending AIGLX clients for VT switch
> [1050507.664] (EE) Server terminated with error (1). Closing log file.
--
Matthieu Herrb
ol_persist)
> stderr_null();
>
> argv[0] = shell;
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
--
Matthieu Herrb
On Sat, Nov 17, 2018 at 09:47:19PM +1100, Darren Tucker wrote:
> On Sat, 17 Nov 2018 at 18:29, Matthieu Herrb wrote:
>
> > on amd64-current on the client side, mosh now fails to connect to
> > remote hosts :
> >
> > /usr/local/bin/mosh: Did not find remote I
h is started with
> ControlPersist; based on patch from Steffen Prohaska
--
Matthieu Herrb
ed.org/packages/16/d8/bc6316cf98419719bd59c91742194c111b6f2e85abac88e496adefaf7afe/six-1.11.0.tar.gz
100%
|*****|
29860 00:00
29860 bytes received in 0.07 seconds (412.27 KB/s)
--
Matthieu Herrb
On Sun, Oct 28, 2018 at 06:45:16PM +0100, Klemens Nanni wrote:
> On Sun, Oct 28, 2018 at 06:19:11PM +0100, Matthieu Herrb wrote:
> > -strlcpy(prompt, message, messageLen);
> > +strlcpy(prompt, message, messageLen+3);
> So this turns "logi" into "lo
int promptNum, co
return -1;
}
-strlcpy(prompt, message, messageLen);
+strlcpy(prompt, message, messageLen+3);
/* Make sure text prompts have at least two spaces at end */
e = messageLen;
--
Matthieu Herrb
+.It Pa /usr/X11R6/share/X11/app-defaults/SshAskpass
+The default application resources.
.El
.Sh SEE ALSO
.Xr ssh 1 ,
--
Matthieu Herrb
On Wed, Oct 17, 2018 at 10:51:00AM +0300, Gregory Edigarov wrote:
>
> On 16.10.18 13:18, Matthieu Herrb wrote:
> >On Tue, Oct 16, 2018 at 10:59:19AM +0100, Stuart Henderson wrote:
> >>On 2018/10/16 12:17, Gregory Edigarov wrote:
> >>>if somebody tell me h
re efficient.
Also, are you forcing X to use the intel driver via an xorg.conf file?
--
Matthieu Herrb
irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
lpt0 at isa0 port 0x378/4 irq 7
vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
efifb at mainbus0 not configured
uhidev0 at uhub0 port 3 configuration 1 interface 0 "Cypress Sem Cypress USB
Mouse" rev 1.00/4.9c addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (d0243d0b9c113a2f.a) swap on sd0b dump on sd0b
--
Matthieu Herrb
On Mon, Aug 06, 2018 at 06:32:01PM +0200, Claudio Jeker wrote:
> On Mon, Aug 06, 2018 at 06:23:28PM +0200, Matthieu Herrb wrote:
> > Hi,
> >
> > fcntl(2) says:
> >
> > F_GETFD Get the close-on-exec flag associated with the file
> > descriptor f
@ -100,10 +100,7 @@ Get the close-on-exec flag associated wi
.Fa fd
as
.Dv FD_CLOEXEC .
-If the returned value ANDed with
-.Dv FD_CLOEXEC
-is 0,
-the file will remain open across
+If the returned value is 0, the file will remain open across
.Fn exec ,
otherwise the file will be closed upon execution of
.Fn exec
--
Matthieu Herrb
ev 2.00/26.03 addr 2
video0 at uvideo0
uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev
2.00/0.04 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed
sd1: 235839MB, 512 bytes/sector, 482999472 sectors
root on sd1a (51923af16755d8a7.a) swap on sd1b dump on sd1b
iwm0: hw rev 0x140, fw ver 16.242414.0, address 7c:7a:91:ef:4e:d0
--
Matthieu Herrb
if (info->ChipFamily < CHIP_FAMILY_R600)
+ if (info->ChipFamily < CHIP_FAMILY_TAHITI)
return FALSE;
} else {
if (info->ChipFamily < CHIP_FAMILY_TAHITI)
--
Matthieu Herrb
On Sun, Feb 11, 2018 at 02:50:30PM +0100, Martin Pieuchot wrote:
> On 11/02/18(Sun) 12:37, Matthieu Herrb wrote:
> > Hi,
> >
> > I ugraded my laptop from sources to -current yesterday. Since then
> > firefox stops resolving host names after a dozen of minutes o
On Sun, Feb 11, 2018 at 04:51:47PM +0100, Landry Breuil wrote:
> On Sun, Feb 11, 2018 at 03:13:07PM +0100, Matthieu Herrb wrote:
> > On Sun, Feb 11, 2018 at 02:50:30PM +0100, Martin Pieuchot wrote:
> > > On 11/02/18(Sun) 12:37, Matthieu Herrb wrote:
> > > > Hi,
> &
On Sun, Feb 11, 2018 at 02:50:30PM +0100, Martin Pieuchot wrote:
> On 11/02/18(Sun) 12:37, Matthieu Herrb wrote:
> > Hi,
> >
> > I ugraded my laptop from sources to -current yesterday. Since then
> > firefox stops resolving host names after a dozen of minutes o
On Sun, Feb 11, 2018 at 01:09:36PM +0100, Mark Kettenis wrote:
> > From: "Peter N. M. Hansteen" <pe...@bsdly.net>
> > Date: Sun, 11 Feb 2018 12:49:49 +0100
> >
> > n 02/11/18 12:37, Matthieu Herrb wrote:
> > > I ugraded my laptop from sources to -
bisecting ?
--
Matthieu Herrb
at softraid0: 256 targets
root on sd0a (f5535e6a0e453526.a) swap on sd0b dump on sd0b
fd0 at fdc0 drive 1: density unknown
obsd64-current
dce76d73-7af5-fb02-1389-4cb713dd99b4
2097152
2097152
4
hvm
destroy
restart
restart
/usr/bin/kvm
--
Matthieu Herrb
PCI-e
graphics.
--
Matthieu Herrb
1 - 100 of 156 matches
Mail list logo
