d
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (27bd8f55e67324d4.a) swap on wd0b dump on wd0b
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
Thanks.
--
Sebastien Marie
On Mon, Mar 12, 2018 at 03:26:12PM +0100, Florian Obser wrote:
> On Mon, Mar 12, 2018 at 11:12:51AM +0100, Sebastien Marie wrote:
> > Hi,
> >
> > I upgraded several hosts (i386 and amd64) and the stable ipv6 address
> > generated using soii (Semantically Opaque Interfa
t; rev 1.00/1.00
addr 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (d4c88ed12283c942.a) swap on wd0b dump on wd0b
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
--
Sebastien Marie
On Fri, Mar 16, 2018 at 08:45:32AM +0100, Sebastien Marie wrote:
> Hi,
>
> After upgrading an i386 host from:
>
> OpenBSD 6.2-current (GENERIC) #405: Tue Feb 27 14:48:56 MST 2018
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>
> to latest snaps
), &so2, type, SCARG(uap,
protocol));
462 if (error)
463 goto free1;
464
465 error = soconnect2(so1, so2);
466 if (error != 0)
467 goto free2;
Could I have confirmation if it is a bug or not ? I am unsure if
socketpair(2) should set the peer information or not. But at least,
ENOTCONN is wrong: socketpair(2) returns connected sockets.
Thanks.
--
Sebastien Marie
On Sat, Apr 07, 2018 at 09:29:30PM -0600, Theo de Raadt wrote:
> Philip Guenther wrote:
>
> > On Sat, 7 Apr 2018, Sebastien Marie wrote:
> > > While running testsuite on third-party program, I found some weird
> > > behaviour on us side regarding socketpair(2) and
lang/rust port; and the
binary could be considered as "fragile" (it is a crosscompiled binary
from amd64) but it seems correct as it is fine with bsd.sp.
Below the dmesg of GENERIC.
--
Sebastien Marie
OpenBSD 6.3-current (GENERIC) #263: Sat Apr 28 23:21:01 MDT 2018
dera...@arm64.o
On Wed, May 02, 2018 at 03:53:54PM +0300, Paul Irofti wrote:
> On Wed, May 02, 2018 at 02:23:06PM +0200, Sebastien Marie wrote:
> > Hi,
> >
> > I recently received a pine64 board for doing Rust work on it (thanks
> > danj@) and I have some problems with it.
> >
&
}
}
$ cc -g -Wall monotonic.c
$ time ./a.out
ts0=(485220,477812476)
ts1=(485220,477728098)
Abort trap (core dumped)
ts0 should be <= ts1 if the result was monotonic.
dmesg below.
Thanks.
--
Sebastien Marie
OpenBSD 6.3-current (GENERIC) #281: Sat May 12 13:30:59 MDT 2018
dera...@arm64.openb
On Sat, May 19, 2018 at 08:30:12AM +0200, Sebastien Marie wrote:
> Hi,
>
> Working on lang/rust on arm64, I experiment rustc panic due to not
> monotonic timestamp. I tried to reproduce the problem in plain C.
>
> My test program is just a loop of calling
> clock_gettime(CLO
.168.92.2)
debug: mta: freeing [relay:192.168.92.2,port=25,mx]
debug: mta: freeing [connector:[]->[relay:192.168.92.2,port=25,mx],0x0]
The daemon sent the mail without problem. I send a new mail.
$ date | mail root
$
smtpd fails to send it as previously.
debug: smtp: new client on listener: 0x79f89000
7957c8192a148eac smtp event=connected address=local host=bert.local
smtp: 0x79f8b000: fd 13 from queue
smtp: 0x79f8b000: message fd 13
debug: 0x79f8b000: end of message, error=0
7957c8192a148eac smtp event=message address=local host=bert.local
msgid=f1e28283 from= to= size=342 ndest=1
proto=ESMTP
7957c8192a148eac smtp event=closed address=local host=bert.local reason=quit
debug: smtp: 0x79f8b000: deleting session: done
debug: scheduler: evp:f1e282831e1952d0 scheduled (mta)
debug: mta: querying smarthost for xsmarthost:...
debug: mta: querying smarthost
warn: Failed to retrieve smarthost for envelope f1e282831e1952d0
debug: control -> client: pipe closed
debug: clearing p=client, fd=11, pid=0
And it will be send when restarting the daemon...
Thanks.
--
Sebastien Marie
eup();
517
518
519 return(retval);
520 }
printf(9) enter in `kprintf_mutex' to use kprintf().
but as witness_checkorder() might want to use printf(9), it could result
in deadlock situation (calling printf(9) from printf(9)).
I dunno what would be the right solution. Maybe witness should use
kprintf() directly (without taking kprintf_mutex) ? but it could result
in mangled output.
--
Sebastien Marie
34592, which is
0x2 which is PLEDGE_CHOWN (0x140008fb80 would be no sens in this
context).
Please wait for another snapshot or rebuild your kernel from source (to
backoff the offending diff which is in snapshot).
Sorry for the inconvenience.
--
Sebastien Marie
t;, but the underline problem could be bad detection or unsupported
configuration: it seems the graphical card is on PCIE.
But I prefer to report the problem.
Below sendbug report, with dmesg from recompiled kernel with DRMDEBUG.
Thanks.
Sebastien Marie
>Synopsis: drm:pid0:r600_init *
tely whitelisted namei() call?
For now, a diff with ni_pledge=PLEDGE_PATH. But I would prefer to
whitelist the call: this filesystem access below to the kernel and not
to slaacd.
Thanks.
--
Sebastien Marie
Index: dev/firmload.c
===
R
be welcome :)
Below an extract of /var/log/messages with dmesg of #863 and #869.
--
Sebastien Marie
Sep 8 06:35:11 ida /bsd: OpenBSD 6.4-beta (GENERIC) #863: Wed Sep 5 18:47:31
MDT 2018
Sep 8 06:35:11 ida /bsd:
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Sep 8 06:35:1
ink you should be
able to reproduce without it.
inside the bsd.rd image, after "file system full" report, search for
recently created files, specially in /etc and in /tmp (with subdirs).
thanks
--
Sebastien Marie
On Tue, Sep 18, 2018 at 03:52:26PM +0200, Sebastien Marie wrote:
>
> I tried to test some hardware compoments like hard-disk, but it seems ok
> (smart is ok, and dd is able to read the whole disk without problem).
I tried to downgrade to my previous working state (#863), and it still
ializing kernel modesetting (ARUBA 0x1002:0x9993 0x1849:0x9993).
radeondrm0: 1366x768, 32bpp
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wskbd2: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
wsmouse0 detached
ums0 detached
uhidev2 detached
uhidev2 at uhub3 port 4 configuration 1 interface 0 "PixArt Cherry USB Optical
Mouse" rev 2.00/1.00 addr 4
uhidev2: iclass 3/1
ums0 at uhidev2: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
--
Sebastien Marie
the process isn't cleared on execve(2) due to execpromises
use. see https://github.com/openbsd/src/blob/master/sys/kern/kern_exec.c#L530
I am unsure if it is intented or not. but at some point, it has been discussed
if unveil(2) should be inherited or not (comments in kern_exec.c are trace of
that).
For now, you need to unveil(2) all files required to reexecute your file, or not
use execpromises.
Thanks.
--
Sebastien Marie
is given, ...' is
present in 6.7 and not in 6.6 (changed on 2019-12-02 with c1cbe94b).
Thanks.
--
Sebastien Marie
uhub3 port 1 configuration 1 interface 0 "Silicon Labs CP2102 USB to
UART Bridge Controller" rev 1.10/1.00 addr 2
ucom0 at uslcom0 portno 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (055d82c92ce5e61f.a) swap on wd0b dump on wd0b
inteldrm0: 1280x800, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Thanks.
--
Sebastien Marie
p+0x19f
> cpu_idle_mwait_cycle() at cpu_idle_mwait_cycle+0x61
> end trace frame: 0x0, count: -5
Just a guest from your backtrace. I assume you have cable plugged on serial, and
your system is configured with db.console=1.
Your system seems to detect a BREAK on the serial, and enter on ddb(4).
Thanks.
--
Sebastien Marie
On Sun, Jun 14, 2020 at 05:31:26PM +0200, Marcus MERIGHI wrote:
> sema...@online.fr (Sebastien Marie), 2020.06.14 (Sun) 14:23 (CEST):
> > On Sun, Jun 14, 2020 at 12:45:46PM +0200, Marcus MERIGHI wrote:
> > > ddb{0}> bt
> > > db_enter() at db_enter+0x10
> > &g
if _syspatch user should be in 'daemon' class (or something new for
system user without the need of lot of ressources).
Thanks.
--
Sebastien Marie
On Fri, Aug 07, 2020 at 01:43:52PM +0200, Sebastien Marie wrote:
> Hi,
>
> I recently added a new step in my ansible playbook to ran sysupgrade on batch
> of
> hosts: it install a temporary /etc/nologin to prevent users to log-in while
> sysupgrade is fetching sets.
>
>
backend and "sdl" audio
output backend. Could you try another driver for each to see if it is related to
one of them ?
$ mpv --vo=sdl http://url/some.mkv
and
$ mpv --ao=sndio http://url/some.mkv
for example ?
(see mpv --ao=help and mpv --vo=help for list of backends. trying with "null"
backend is also a possibility)
Thanks.
--
Sebastien Marie
00 1.64
> +++ smtpctl.8 14 Sep 2020 07:31:03 -
> @@ -247,8 +247,12 @@ Shows if MTA, MDA and SMTP systems are c
> Recursively look up SPF records for the domains read from stdin.
> For example:
> .Bd -literal -offset indent
> -# smtpctl spf walk < domains.txt
> +$ smtpctl spf walk < domains.txt
> .Ed
> +.Pp
> +SPF records may contain macros which cannot be included in a static list and
> +must be resolved dynamically at connection time.
> +spf walk cannot provide full results in these cases.
> .It Cm trace Ar subsystem
> Enables real-time tracing of
> .Ar subsystem .
>
--
Sebastien Marie
7JeS3kmTj8=
Is it is the same on your side too ? if yes, it means hypervisor
doesn't have constant behaviour.
Thanks.
--
Sebastien Marie
nt
main(int argc, char *argv[])
{
while (1) {
pthread_t thread;
thread_spawn(&thread);
thread_wait(&thread);
}
return EXIT_SUCCESS;
}
$ cc -Wall test-thread.c -lpthread -o test-thread
$ ./test-thread
Segmentation fault (core dumped)
Thanks.
--
Sebastien Marie
On Tue, Dec 01, 2020 at 06:12:32PM +0100, Sebastien Marie wrote:
> Hi,
>
> I have a random segfault while using threads with custom stack.
sorry, I omitted to mention some elements (thanks deraadt@):
dmesg contains such lines:
[test-thread]79782/462309 sp=6a5e0e4df18 inside 6a
enther@, it makes sense.
I will report the problem upstream (I was running testsuite of zig and
chasing random segfault in tests when threads were involved). Their
std.Thread implementation (for the pthread version used for OpenBSD)
is freeing the allocated stack (and so we are crashing).
Regards.
--
Sebastien Marie
ing
> -an allocator which has a matching deallocator that discards whole
> -pages, to clear the
> -.Ar MAP_STACK
> -attribute afterwards.
> +The passed memory object should not be deallocated or reused,
> +even when the thread using it has terminated.
> +If there is no need for a specific memory object as stack,
> +the
> +.Xr pthread_attr_set_stacksize 3
it is pthread_attr_setstacksize
ok semarie@ with that.
> +function should be used.
> .Sh RETURN VALUES
> Upon successful completion,
> .Fn pthread_attr_setstack
--
Sebastien Marie
lly, the target thread is about to terminate.
The results of multiple simultaneous calls to
.Fn pthread_join
specifying the same target thread are undefined.
Thanks.
--
Sebastien Marie
r/src/sys/kern/kern_synch.c", line 826
Starting stack trace...
panic(81dfbc8e) at panic+0x11d
__assert(81e64b54,81e0a6ee,33a,81e03b7f) at
__assert+0x2b
refcnt_rele(fd810bf02458) at refcnt_rele+0x6f
pf_state_key_unref(fd810bf023f0) at pf_state_key_unref+0x21
pf_remove_state(fd810c0c4578) at pf_remove_state+0x1fa
pf_purge_expired_states(2) at pf_purge_expired_states+0x232
pf_purge(82236a30) at pf_purge+0x33
taskq_thread(80032080) at taskq_thread+0x81
end trace frame: 0x0, count: 249
End of stack trace.
syncing disks...8 7 done
[EOT]
--
Sebastien Marie
On Tue, May 04, 2021 at 11:47:55AM +0200, Alexandr Nedvedicky wrote:
> Hello Sebastien,
>
> On Tue, May 04, 2021 at 11:08:19AM +0200, Sebastien Marie wrote:
> > Hi,
> >
> > Currently, I am regulary (~1 per day) get panic on an amd64 host (OpenBSD
> > 6.9-current
oduce the crash.
I will first try with another rule:
pass in inet6 proto tcp to (self) port 80 rdr-to
2001:41d0:fe39:c05c:56b8:d15b:2e0a:8775 port 8000
to avoid the possible NAT-64.
And next (if I still trigger the assert) I will rebuild a kernel and
backout this specific commit.
It should permit to see if the commit is the problem or not.
Thanks.
--
Sebastien Marie
On Tue, May 04, 2021 at 04:50:06PM +0200, Sebastien Marie wrote:
> On Tue, May 04, 2021 at 02:15:05PM +0200, Alexandr Nedvedicky wrote:
> > Hello Sebastien,
> >
> > thank you for additional info about previously working kernel.
> >
> > it looks like your ol
as we already have for
another directory subtility:
a directory that is removed and recreated after a call to
unveil() will appear to not exist.
Or we could try to duplicate the logical from unveil_check_final() to
unveil_check_compoment(), but I fear of corner-cases it could introduce.
Thanks.
--
Sebastien Marie
ported very well to OpenBSD? For
> screenshots see the attachments.
LibreOffice requires dbus to be running.
You could take a look at /usr/local/share/doc/pkg-readmes/dbus
--
Sebastien Marie
ing problem: all elements are here at the end of
the process (after ^D or ^C), but not at '\n' time.
Thanks.
--
Sebastien Marie
On Fri, Jul 12, 2019 at 12:00:37PM +0200, Sebastien Marie wrote:
> On Fri, Jul 12, 2019 at 11:09:20AM +0200, Solene Rapenne wrote:
> > >Description:
> > There is a behavior change with "cat - | tee foobar" since 6.5 and
> > 25th June snapshot.
> >
sabled_bios()
- r600_read_disabled_bios()
- init registers
- radeon_read_bios()
- restore registers
Thanks.
--
Sebastien Marie
01 Line: 09 Min Gnt: 0b Max Lat: 34
0x0040: Capability 0x01: Power Management
State: D0
--
Sebastien Marie
if (r == false || rdev->bios == NULL) {
Now, I know it is only a workaround on this specific machine.
I still dunno if:
- radeon_read_disabled_bios() should return false (because it
isn't the right way for this specific card), and so the use of
radeon_read_platform_bios() is the r
s().
So with i386, radeon_read_disabled_bios() failed, and it returns false,
whereas it returns true on amd64 (and a "bad" bios, so r600_init aborts).
I will try to figure which part of radeon_read_disabled_bios() failed
on i386 in order to have some elements to understand why it didn't with
amd64.
Thanks.
--
Sebastien Marie
: *Built-in mode "640x480"
[ 39.849] (**) VESA(0): *Built-in mode "720x400"
[39.849] (**) VESA(0): Display dimensions: (430, 270) mm
[39.849] (**) VESA(0): DPI set to (75, 96)
[39.849] (**) VESA(0): Using "Shadow Framebuffer"
The virtual size isn't "720x400" anymore.
Thanks.
--
Sebastien Marie
On Thu, Aug 08, 2019 at 06:57:57AM +0200, Sebastien Marie wrote:
> On Wed, Aug 07, 2019 at 11:12:57PM +0200, Mark Kettenis wrote:
> > > > Can you try to figure out where exactly reading the BIOS from the card
> > > > goes wrong?
> > >
> > > radeon
On Thu, Aug 08, 2019 at 10:23:15AM +0200, Sebastien Marie wrote:
>
> I will try to compare i386 and amd64 in r600_read_disabled_bios().
I didn't found any major difference between i386 and amd64. the values
below are the same for i386 and amd64.
- radeon_get_bios()
- radeon_read_di
rule (and no quick rule). I have a 'block in log
all', and nothing in /var/log/pflog at the time.
Any advice on possible fallout is welcome.
Thanks.
--
Sebastien Marie
jsg@
Please note that the drm error is expected for this hardware, but
previously the fallback path worked well.
Disabling radeondrm* in UKC is a working workaround.
Full dmesg below.
Thanks.
--
Sebastien Marie
OpenBSD 6.6-beta (GENERIC.MP) #28: Tue Aug 27 09:35:21 CEST 2019
semarie@mira.lo
stem
continues to boot.
the diff itself looks fine. so ok semarie@
Thanks.
--
Sebastien Marie
> Index: dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.48
> diff -u
oftraid0: 256 targets
root on sd0a (f1307242b412e6c8.a) swap on sd0b dump on sd0b
initializing kernel modesetting (RV610 0x1002:0x94C3 0x1028:0x0402 0x00).
drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init
[TTM] Memory type 2 has not been initialized
drm0 detached
radeondrm0 detached
vga1 at pci1 dev 0 function 0 "ATI Radeon HD 2400 Pro" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
If required, I could try to get a dmesg from failing GENERIC.MP with
acpipci. It isn't provided for now, as I need to patch the kernel to
force a reboot to kept dmesg buffer.
Thanks.
--
Sebastien Marie
On Fri, Sep 06, 2019 at 12:11:24PM +0200, Mark Kettenis wrote:
>
> What happens if you disable acpipci(4) when booting bsd.rd?
It just boots fine.
I tested booting bsd.rd, and also a GENERIC.MP. Both are fine.
Below a full dmesg of GENERIC.MP with acpipci* disabled.
--
Sebastien
abase file.
# locate test
locate: database too small: /var/db/locate.database
The change should be discarded or at least permit '-' as valid option.
Thanks.
--
Sebastien Marie
locate.updatedb(8) as 'nobody'.
so 'nobody' would have to have write perm to /var/db to create temporary
file, and you din't want that.
--
Sebastien Marie
t;-" ]; then
> + FCODESDIR=$( dirname "${FCODES}" )
> + if [ ! -w "${FCODESDIR}" ]; then
> + echo "$0: no permission to create $FCODES"
> + exit 1
> + fi
> fi
>
> case X"$SEARCHPATHS" in
--
Sebastien Marie
bing dmesg).
I should be able to get a serial ddb once I figured how to plug a serial port on
the connector on the mainboard if it helps.
Thanks.
--
Sebastien Marie
OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENER
On Tue, Oct 15, 2019 at 12:40:10PM +1100, Jonathan Gray wrote:
> On Mon, Oct 14, 2019 at 08:10:36PM +0200, Sebastien Marie wrote:
> >
> > I should be able to get a serial ddb once I figured how to plug a serial
> > port on
> > the connector on the mainboard if it
On Tue, Oct 15, 2019 at 12:40:10PM +1100, Jonathan Gray wrote:
> On Mon, Oct 14, 2019 at 08:10:36PM +0200, Sebastien Marie wrote:
> > Hi,
> >
> > I recently tested OpenBSD on a system with a "ATI Radeon Vega", and I have
> > problem on initialization: th
On Wed, Oct 16, 2019 at 09:16:41AM +0200, Sebastien Marie wrote:
> uvm_fault(0x82011010, 0x18, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at dc_link_aux_transfer+0x85: movq0x18(%r14),%rax
> ddb{0}> trace
> dc_link_aux_transfer(8013c4
On Wed, Oct 16, 2019 at 09:15:41PM +1100, Jonathan Gray wrote:
> On Wed, Oct 16, 2019 at 10:42:45AM +0200, Sebastien Marie wrote:
> > On Wed, Oct 16, 2019 at 09:16:41AM +0200, Sebastien Marie wrote:
> >
> > > uvm_fault(0x82011010, 0x18, 0, 1) -> e
> >
On Wed, Oct 16, 2019 at 01:46:51PM +0200, Sebastien Marie wrote:
>
> even if the display is a bit short for real use.
with a proper screen it is fine (my old test screen should be a bit old).
initializing kernel modesetting (RAVEN 0x1002:0x15DD 0x1002:0x15DD 0xCB).
[drm] *ERROR* con
052 return flags;
1053 }
I am unsure if the problem is kernel related or in dhcpcd ...
Thanks.
--
Sebastien Marie
the network side:
- the switch where the device is connected lost is power connection and go down
(and go back up, less than 1 second after)
- the device has additionnal power supply and keep running
Thanks.
--
Sebastien Marie
On Sat, Dec 07, 2019 at 09:31:20AM +0100, Florian Obser wrote:
> On Sat, Dec 07, 2019 at 07:09:17AM +0100, Sebastien Marie wrote:
> > Hi,
> >
> > On an i386 and an aarch64 hosts, I have occasionally the following error in
> > syslog:
>
> is there a way to tell w
On Sat, Dec 07, 2019 at 11:47:58AM +0100, Sebastien Marie wrote:
>
> For now, I recompiled slaacd with debug symbols, and will keep it running like
> that in order to catch it the next time. But such switchs aren't very
> frequent...
A new one, with symbols this time. I still
ress->addr,
> + sizeof(in6_ridreq.ifr_addr));
>
> log_debug("%s: %s", __func__, if_name);
>
--
Sebastien Marie
t;: int3
0x00218a4a <+58>: int3
0x00218a4b <+59>: int3
0x00218a4c <+60>: ret
End of assembler dump.
>From my understanding, the `syscall` isn't permitted because it comes from the
static library libc_p.a inside the dynamic program a.out.
Thanks.
--
Sebastien Marie
ist).
The snapshot kernel is enforcing indirect-branch-tracking.
Could you identify the exact program which dies ? I assume it was segfaulted
with SIGILL.
Thanks.
--
Sebastien Marie
core date is older, and I am unsure it is present in your .xsession.
But xfce4-session is a good candidate for Xorg terminaison.
Could you extract a backtrace with egdb ?
--
Sebastien Marie
On Mon, Jun 12, 2023 at 04:17:18PM +0200, Peter N. M. Hansteen wrote:
> On Mon, Jun 12, 2023 at 03:51:10PM +0200, Sebastien Marie wrote:
> > On Mon, Jun 12, 2023 at 03:40:26PM +0200, Peter N. M. Hansteen wrote:
> > >
> > > [Mon Jun 12 15:28:27] peter@zaida:~$ ls -l *cor
On Mon, Jun 12, 2023 at 04:54:00PM +0200, Peter N. M. Hansteen wrote:
> On Mon, Jun 12, 2023 at 04:47:41PM +0200, Sebastien Marie wrote:
> > > (gdb)
> > >
> > > with some instruction I might be able to extract more information.
> > >
> >
> >
On Mon, Jun 12, 2023 at 06:28:55PM +0200, Peter N. M. Hansteen wrote:
> On Mon, Jun 12, 2023 at 05:59:08PM +0200, Sebastien Marie wrote:
> > the package is too old. the signature date is 2023-04-16, so it hasn't been
> > built with cf-protection=branch. it is why the kernel
et a egdb backtrace (and a disassemble) of the SIGILL ?
Thanks.
--
Sebastien Marie
0x0e68ac0e6787 <+7>: leardx,[rsp+rdi*8+0x10]
> 0x0e68ac0e678c <+12>:learsi,[rsp+0x8]
the _start function doesn't begin with `endbr64'. the compiler which generated
it doesn't use the -fcf-protection=branch option.
please ensure your base system is up to date, and next rebuild the package with
the newly installed compiler.
thanks.
--
Sebastien Marie
bluajit-5.1.so.1.0
There is already a diff for luajit at
https://marc.info/?l=openbsd-ports&m=168667722510843&w=2 (I included it below).
It was first reported with neovim, but I found later that neovim was using
embedded version of
On Fri, Jun 23, 2023 at 11:12:37AM +0200, Peter N. M. Hansteen wrote:
> Hi,
>
> Sorry this took so long,
>
> On 6/15/23 06:49, Sebastien Marie wrote:
> > On Wed, Jun 14, 2023 at 10:49:32PM +0200, Peter N. M. Hansteen wrote:
> > > A similar situation with hexchat
Nov 14 08:38:16 bert last message repeated 10 times
Nov 14 08:48:16 bert last message repeated 10 times
Nov 14 08:58:17 bert last message repeated 10 times
Nov 14 09:08:17 bert last message repeated 10 times
Thanks.
--
Sebastien Marie
> + logmsg(LOG_NOTICE, "%s", pcap_geterr(hpcap));
> }
>
> if (gotsig_close)
Your description makes sense, and it fixes the empty log message.
ok semarie@
Thanks.
--
Sebastien Marie
Claudio Jeker writes:
> On Fri, Nov 17, 2023 at 09:46:56AM +0100, Sebastien Marie wrote:
>
> How about this instead. pcap_dispatch() returns -1 on error and -2 (aka
> PCAP_ERROR_BREAK) on interrupt. On interrupt there is no need to print
> anything (no matter the signal). pcap_get
expect unveil(2) to error out if the partition is readonly.
Reading code source, I see we already have code for managing exceptions
like that. so I assume a different code path.
I will try to investigate deeper in the week-end.
thanks.
--
Sebastien Marie
On Fri, Oct 26, 2018 at 02:53:48PM +0200, Sebastien Marie wrote:
> Hi,
>
> On IRC, someone reported problem with tcpdump whereas /etc was readonly.
> I will not comment on this unsupported configuration, but instead
> looking at unveil(2) itself as it is the root cause of
_ctl: no server running
doing _rc_rm_runfile
(failed)
# cd / && rcctl start postgresql
postgresql(ok)
I am unsure about the correct solution. Maybe just having a `cd /' in
rcexec ? it isn't the exact same behaviour (chdir to home directory),
but at least / is expected to be readable.
thanks.
--
Sebastien Marie
possibility, but it seems wrong to me to use chroot for this
purpose.
for (2), it could be done by adding "cd /" after FUNCS_ONLY check. but I
am unsure if it could trigger some side-effects.
--
Sebastien Marie
Please ensure the specified path can be accessed.
doing _rc_rm_runfile
(failed)
minio seems to use its HOME environment to look at configuration
directory.
regards.
--
Sebastien Marie
On Mon, Oct 29, 2018 at 12:48:19AM +0100, Antoine Jacoutot wrote:
> On Sun, Oct 28, 2018 at 07:18:53PM +0100, Sebastien Marie wrote:
> > On Sun, Oct 28, 2018 at 05:21:38PM +0100, Antoine Jacoutot wrote:
> > >
> > > Thinking about it I wonder if this shouldn&#x
993 port [tcp/imaps] succeeded!
nc: tls handshake failed (handshake failed: error:04FFF08F:rsa
routines:CRYPTO_internal:invalid digest length)
Something changed.
Thanks.
--
Sebastien Marie
On Tue, Nov 13, 2018 at 07:58:00AM +, Mikolaj Kucharski wrote:
> Hi,
>
> I just upgraded base system
On Tue, Nov 13, 2018 at 11:28:23AM +, Stuart Henderson wrote:
> On 2018/11/13 09:37, Sebastien Marie wrote:
> > Hi,
> >
> > Moving the thread to bugs@ has it seems to be an issue with libssl.
> >
> > When connecting with nc(1) to outlook.office365.com:99
seems to me it it is odd: if I correctly understood, the change
occurs in tls1.2 stuff, and here the connection is done using tls1.
Thanks.
--
Sebastien Marie
if (ferror(fp))
err(EXIT_FAILURE, "ferror\n");
errx(EXIT_FAILURE, "something else\n");
}
}
return EXIT_SUCCESS;
}
$ cc -Wall test.c && ./a.out
^D
a.out: something else
Is it a bug to not set the __SEOF flag or it is expected for unbuffered
FILE ?
Thanks.
--
Sebastien Marie
On Tue, Dec 11, 2018 at 03:08:38PM -0700, Todd C. Miller wrote:
> On Tue, 11 Dec 2018 20:35:05 +0100, Sebastien Marie wrote:
>
> > According to stdio.h, 6 = __SNBF | __SRD, so "unbuffered" and "OK to read".
> >
> > the feof() call returns false
; __SNBF) != 0) {
> /*
>* We know if we're unbuffered that our buffer is empty, so
> @@ -82,6 +83,7 @@ fread(void *buf, size_t size, size_t cou
> FUNLOCKFILE(fp);
> return ((total - resid) / size);
> }
> +#endif
>
> while (resid > (r = fp->_r)) {
> (void)memcpy(p, fp->_p, r);
--
Sebastien Marie
ed back it makes sens.
> + break;
> + }
> + fake._p += fake._r;
> + resid -= fake._r;
> }
> FUNLOCKFILE(fp);
> - return ((total - resid) / size);
> + return (count);
> }
>
> while (resid > (r = fp->_r)) {
Thanks.
--
Sebastien Marie
On Fri, Dec 14, 2018 at 10:49:23AM -0700, Todd C. Miller wrote:
> On Fri, 14 Dec 2018 08:45:31 +0100, Sebastien Marie wrote:
>
> After thinking about this a bit more I believe it best to just use
> the existing FILE * and swap in the buffer temporarily. There's
> no need t
> + fp->_bf._size = 1;
> + fp->_r = 0;
> +
> + FUNLOCKFILE(fp);
> + return (count);
> + }
> +
> while (resid > (r = fp->_r)) {
> (void)memcpy(p, fp->_p, r);
> fp->_p += r;
--
Sebastien Marie
iter)
>
> https://imgur.com/a/jJlyXpy
>
> dmesg is attached
>
> Thxs!
>
--
Sebastien Marie
EXIT_SUCCESS;
}
$ cc -Wall -lpthread test.c
$ ./a.out
main: 0
c
c handler
c
c handler
c
c handler
c
c handler
c
c handler
c
c handler
c
c
c
c
c handler
c handler
[<--- HANG HERE]
If I am compiling libpthread with rthread_rwlock_compat.c instead
of rthread_rwlock.c (and no -DFUTEX), the program terminate without
hanging.
Thanks.
--
Sebastien Marie
On Sat, Mar 02, 2019 at 01:56:56PM +, Visa Hankala wrote:
> On Sat, Mar 02, 2019 at 10:29:07AM +0100, Sebastien Marie wrote:
> > I am experiencing dead-lock with the new futex based rwlock
> > implementation commited few days ago.
>
> The problem happens if a read-wri
On Sat, Mar 02, 2019 at 04:00:19PM +, Visa Hankala wrote:
> On Sat, Mar 02, 2019 at 04:37:04PM +0100, Sebastien Marie wrote:
> > Thread 1 (thread 469200):
> > #0 sched_yield () at -:3
> > #1 0x0a8c0609d9c5 in _libc__spinlock (lock=Variable "lock" is not
1 - 100 of 213 matches
Mail list logo
