Florian Obser writes:
> On 2024-06-17 15:02 +02, Sebastien Marie wrote:
>> Hi,
>>
>> I am using dhcp6leased on my gateway to get ipv6-pd over pppoe from my
>> ISP.
>>
>> The problem is when the pppoe0 disconnect/reconnect due to LCP keepalive
>
) to
have ipv6 working again.
During the disconnect/reconnect, the status switch from 'active' to 'no
carrier' and come back to 'active'. I wonder if dhcp6leased would be
able to detect such state to reinit itself ?
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
+ 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
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
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 hex
luajit-5.1.so.1.0
There is already a diff for luajit at
https://marc.info/?l=openbsd-ports=168667722510843=2 (I included it below).
It was first reported with neovim, but I found later that neovim was using
embedded version of luajit (so p
ac0e6787 <+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
race (and a disassemble) of the SIGILL ?
Thanks.
--
Sebastien Marie
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 kill
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 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
rd.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
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
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
ese tests are expected to be run as root (in order to not have
unlimited stacksize-max).
But I don't have sparc64 to check if it is fine.
--
Sebastien Marie
uvn_detach(>u_obj);
> - vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
> -
> return TRUE;
> }
>
> @@ -1483,11 +1437,9 @@ uvm_vnp_sync(struct mount *mp)
> continue;
>
> /*
> - * gain reference. watch out for persisting uvns (need to
> - * regain vnode REF).
> + * gain reference.
>*/
> - if (uvn->u_obj.uo_refs == 0)
> - vref(vp);
> + KASSERT(uvn->u_obj.uo_refs > 0);
> uvn->u_obj.uo_refs++;
>
> SIMPLEQ_INSERT_HEAD(_sync_q, uvn, u_syncq);
--
Sebastien Marie
ot;Intel Rate Matching Hub" rev
2.00/0.04 addr 2
uhub4 at uhub2 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
root on sd0a (9b2a096b20485911.a) swap on sd0b dump on sd0b
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
--
Sebastien Marie
}
>
> /*
>* gain reference. watch out for persisting uvns (need to
> @@ -1497,7 +1490,6 @@ uvm_vnp_sync(struct mount *mp)
> if (uvn->u_obj.uo_refs == 0)
> vref(vp);
> uvn->u_obj.uo_refs++;
> - rw_exit(uvn->u_obj.vmobjlock);
>
> SIMPLEQ_INSERT_HEAD(_sync_q, uvn, u_syncq);
> }
--
Sebastien Marie
ll process all unlocked uvn, sleep only at end of the loop, and
restart the uvn_wlist processing.
> if ((uvn->u_flags & UVM_VNODE_BLOCKED) != 0) {
> rw_exit(uvn->u_obj.vmobjlock);
> continue;
> @@ -1499,11 +1476,10 @@ uvm_vnp_sync(struct mount *mp)
> uvn->u_obj.uo_refs++;
> rw_exit(uvn->u_obj.vmobjlock);
>
> - SIMPLEQ_INSERT_HEAD(_sync_q, uvn, u_syncq);
> + SIMPLEQ_INSERT_HEAD(_q, uvn, u_syncq);
> }
>
> - /* step 3: we now have a list of uvn's that may need cleaning. */
> - SIMPLEQ_FOREACH(uvn, _sync_q, u_syncq) {
> + SIMPLEQ_FOREACH(uvn, _q, u_syncq) {
> rw_enter(uvn->u_obj.vmobjlock, RW_WRITE);
> #ifdef DEBUG
> if (uvn->u_flags & UVM_VNODE_DYING) {
> @@ -1528,6 +1504,4 @@ uvm_vnp_sync(struct mount *mp)
> /* now drop our reference to the uvn */
> uvn_detach(>u_obj);
> }
> -
> - rw_exit_write(_sync_lock);
> }
>
--
Sebastien Marie
on might be possible inside uvm_vnp_terminate() or
uvm_vnp_uncache(): they have both code path for uo_refs ==0 and >0 (and
without UVM_VNODE_CANPERSIST, a uvn should always have refs or be "free").
uvm_vnp_uncache() might be deletable.
Thanks.
--
Sebastien Marie
running to mount filesystems before your hang). so for now I am unsure which
device could be disabled in boot_config(8) to test it.
Thanks.
--
Sebastien Marie
On Tue, May 03, 2022 at 07:52:16PM +0200, Alexander Bluhm wrote:
> On Mon, May 02, 2022 at 06:53:08AM +0200, Sebastien Marie wrote:
> > New diff, with new iteration on vnode_history_*() functions. I added a
> > label in
> > the record function. I also changed when showing th
On Thu, Apr 28, 2022 at 08:47:53PM +0200, Martin Pieuchot wrote:
> On 28/04/22(Thu) 16:54, Sebastien Marie wrote:
> > On Thu, Apr 28, 2022 at 04:04:41PM +0200, Alexander Bluhm wrote:
> > > On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> > > > Here a
On Thu, Apr 28, 2022 at 04:04:41PM +0200, Alexander Bluhm wrote:
> On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> > Here a new diff (sorry for the delay) which add a new vnode_history_record()
> > point inside uvn_detach() (when 'uvn' object has UVM_VNODE_
r entry to deduce if the 'uvn' has
UVM_VNODE_CANPERSIST or not, and as we are using a ring, info could be
overrided...
let's see if we could make progress.
Alexander and Andrew, could you generate the problem with this diff ?
Thanks.
--
Sebastien Marie
diff 8d3b4fd4f5e7dfb98f0fe3fdbfb579f0dfe8d3
e.
see the whole man page (man EVP_CIPHER_CTX_get_iv) to get the public interface.
--
Sebastien Marie
photos.
On Wed, Apr 13, 2022 at 11:42:22AM +0200, Martin Pieuchot wrote:
> On 12/04/22(Tue) 14:58, Sebastien Marie wrote:
> > [...]
> > uvn_io: start: 0x8000ffab9688, type VREG, use 0, write 0, hold 0, flags
> > (VBIOONFREELIST)
> > tag VT_UFS, ino 1480228
On Tue, Apr 12, 2022 at 09:46:24AM +0300, Andrew Krasavin wrote:
> On Tue, Apr 12, 2022 at 06:44:09AM +0200, Sebastien Marie wrote:
> > On Mon, Apr 11, 2022 at 10:35:37PM +0300, Andrew Krasavin wrote:
> > >
> > > Unfortunately, I didn't have a chance to get to my ho
Warriors
> Of The World/2002 Warriors Of The World [2002 Japan ZACB-1058 Zain]/Manowar -
> Warriors Of The World (ZACB-1058).flac
> $
>
> So, it is an ordinary file that qbittorrent distributes over
> the network.
Thanks.
--
Sebastien Marie
On Fri, Apr 08, 2022 at 11:07:22AM +0200, Alexander Bluhm wrote:
> On Fri, Apr 08, 2022 at 06:38:47AM +0200, Sebastien Marie wrote:
> > I have a diff for adding some stacktrace history for vnode (keeping track of
> > lasts vref/vrele/vget/vput). but I am not sure it wou
On Fri, Apr 08, 2022 at 06:38:47AM +0200, Sebastien Marie wrote:
> On Thu, Apr 07, 2022 at 02:53:07PM +0200, Alexander Bluhm wrote:
> > On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
> > > > panic: vref used where vget required
> > >
&g
On Thu, Apr 07, 2022 at 12:06:45PM +0300, Andrew Krasavin wrote:
> On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
>
> uvn_io: start: 0xfd834f678210, type VREG, use 0, write 0, hold 0, flags
> (VBIOONFREELIST)
> tag: VT_UFS, ino 19627621, on dev 4,
one or two vprint() would be interesting to know.
please report the backtrace, the vprint() (if any), and ddb output for
"show vnode /f 0xXYZ"
Thanks.
--
Sebastien Marie
diff 34ceb667563449b0c2871b87a9bb5cb5ae05fa82 /home/semarie/repos/openbsd/src
blob - 13c70890ccc11f131013d14b853f4f06
penbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Could you check in your log the exact previous version you where
using, and report it ?
Something like:
# grep -R ': OpenBSD ' /var/log/messages
# zgrep -R ': OpenBSD ' /var/log/messages*.gz
Thanks.
--
Sebastien Marie
On Tue, Feb 15, 2022 at 08:40:11AM -0700, Todd C. Miller wrote:
> On Mon, 14 Feb 2022 20:05:30 +0100, Sebastien Marie wrote:
>
> > One aspect that I haven't verified for now is the difference between
> > using "tls" (early initialisation) and not using it (late
>
On Mon, Feb 14, 2022 at 11:10:01AM -0700, Todd C. Miller wrote:
> On Mon, 14 Feb 2022 17:43:47 +0100, Sebastien Marie wrote:
>
> > It seems I need to explicitly add "tls" on the action line to enforce
> > the tls verification now.
> >
> > - actio
I am unsure if the behaviour change was intented or not. If it
persists it might need some documentation (a current.html entry) for
users to update their configuration (as TLS session might not be
checked anymore whereas it was previously).
Thanks.
--
Sebastien Marie
On Mon, Feb 14, 202
ction "local"
match from local mail-from for any action "relay-free"
match from local mail-from for any action "relay-o2switch"
match for domain "xyz.fr" action "relay-o2switch"
Thanks.
--
Sebastien Marie
arie@
just some nits below.
> On Mon, Feb 07, 2022 at 08:28:47AM +0100, Sebastien Marie wrote:
> > Hi,
> >
> > I am seeing that fw_update(8) does unregisteration of installed
> > firmwares (removing /var/db/pkg/ files) if it is unable to fetch
> > SHA256.si
,vmm
In my case, pf on the gateway was blocking connection.
Thanks.
--
Sebastien Marie
trieving revision 1.48
> diff -u -p -r1.48 namei.h
> --- sys/namei.h 2 Sep 2021 12:35:23 - 1.48
> +++ sys/namei.h 8 Jan 2022 11:32:39 -
> @@ -268,6 +268,7 @@ structnchstats {
> #define UNVEIL_WRITE0x02
> #define UNVEIL_CREATE 0x04
> #define UNVEIL_EXEC 0x08
> -#define UNVEIL_USERSET 0x0F
> +#define UNVEIL_USERSET 0x10
> +#define UNVEIL_MASK 0x0F
>
> #endif /* !_SYS_NAMEI_H_ */
--
Sebastien Marie
On Tue, Dec 21, 2021 at 01:57:01PM +0100, Claudio Jeker wrote:
> On Wed, Dec 01, 2021 at 04:43:13PM +0100, Claudio Jeker wrote:
> > On Wed, Dec 01, 2021 at 02:14:40PM +0100, Sebastien Marie wrote:
> > > Hi,
> > >
> > > I have a program with unexpected
.out: stat: /usr/bin: No such file or directory
If I explicity add `unveil("/usr/bin", "r")`, it is working as expected.
The order of unveil("/") and unveil("/usr/bin/id") doesn't change the
problem. unveil(NULL, NULL) isn't required for reproducing.
Thanks.
--
Sebastien Marie
ase.
> + */
> old_reverse = atomic_cas_ptr(>reverse, NULL, sk);
> if (old_reverse != NULL)
> KASSERT(old_reverse == sk);
> - else
> - pf_state_key_ref(sk);
> +
> + pf_state_key_ref(sk);
> }
>
> #if NPFLOG > 0
--
Sebastien Marie
taskq_thread(80033000) at taskq_thread+0x9f
end trace frame: 0x0, count: 1
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{1}>
Thanks.
--
Sebastien Marie
ULL at line
> 1090.
>
> >
> > I could try to run with your commit and see if I could trigger it more
> > easily or found some elements influencing it. I could try with GENERIC
> > for example to see if I still trigger the same assert() or if it is
> > more like Olivier.
>
> I need to think of how to further debug the thing.
>
> >
> > my LAN was several hosts with the same kernel and only this machine
> > trigger the panic, so it shouldn't be strictly linked to the
> > environment.
> >
Thanks
--
Sebastien Marie
e elements influencing it. I could try with GENERIC
for example to see if I still trigger the same assert() or if it is
more like Olivier.
my LAN was several hosts with the same kernel and only this machine
trigger the panic, so it shouldn't be strictly linked to the
environment.
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
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 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
;/usr/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
arget 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
ing 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
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
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
pthread_t thread;
thread_spawn();
thread_wait();
}
return EXIT_SUCCESS;
}
$ cc -Wall test-thread.c -lpthread -o test-thread
$ ./test-thread
Segmentation fault (core dumped)
Thanks.
--
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
ctl.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
d "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
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.
>
>
s (or something new for
system user without the need of lot of ressources).
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
9f
> 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
3 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
iven, ...' is
present in 6.7 and not in 6.6 (changed on 2019-12-02 with c1cbe94b).
Thanks.
--
Sebastien Marie
ed 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
sizeof(in6_ridreq.ifr_addr));
>
> log_debug("%s: %s", __func__, if_name);
>
--
Sebastien Marie
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 saw
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
, on 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
053 }
I am unsure if the problem is kernel related or in dhcpcd ...
Thanks.
--
Sebastien Marie
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
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 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 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 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
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
ot; ]; 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
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
ase too small: /var/db/locate.database
The change should be discarded or at least permit '-' as valid option.
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
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
em
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 -p -
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
in log
all', and nothing in /var/log/pflog at the time.
Any advice on possible fallout is welcome.
Thanks.
--
Sebastien Marie
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_disable
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
n 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
abled_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
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 right thing
ne: 09 Min Gnt: 0b Max Lat: 34
0x0040: Capability 0x01: Power Management
State: D0
--
Sebastien Marie
- r600_read_disabled_bios()
- init registers
- radeon_read_bios()
- restore registers
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.
> &
ing problem: all elements are here at the end of
the process (after ^D or ^C), but not at '\n' time.
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
r
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
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
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
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
1 - 100 of 201 matches
Mail list logo
