On 29/01/18(Mon) 21:25, Artturi Alm wrote:
> On Mon, Jan 29, 2018 at 08:03:38PM +0100, Martin Pieuchot wrote:
> > On 29/01/18(Mon) 20:38, Artturi Alm wrote:
> > > On Mon, Jan 29, 2018 at 10:42:20AM +0100, Martin Pieuchot wrote:
> > > > Hello Artturi,
> >
On 26/02/18(Mon) 15:20, C. wrote:
> Category:
> Webcam / Video
>
> Environment:
> System : OpenBSD 6.2
> Details : OpenBSD 6.2 (GENERIC.MP) #5: Fri Feb 2 23:02:19 CET
> 2018
>
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/co
Thanks for the report.
On 19/03/18(Mon) 09:49, Theo Buehler wrote:
> This is a regression that came with the TOCTOU race fix in kern_sig.c 1.216:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_sig.c#rev1.216
> [...]
> Now gdb just hangs there and does nothing instead of exiting as
On 19/03/18(Mon) 15:58, Stefan Sperling wrote:
> The following will trigger "panic: rw_enter: netlock locking against myself":
The solution is to call bpfdetach() outside of the NET_LOCK(), it should
not need it. Diff below does that, does it work for you?
Index: net/if.c
===
On 19/03/18(Mon) 15:38, Visa Hankala wrote:
> On Mon, Mar 19, 2018 at 12:27:10PM +0100, Martin Pieuchot wrote:
> > Thanks for the report.
> >
> > On 19/03/18(Mon) 09:49, Theo Buehler wrote:
> > > This is a regression that came with the TOCTOU race fix in kern_s
On 08/03/18(Thu) 23:16, Alexander Bluhm wrote:
> Hi,
>
> When rebooting the NFS client while the NFS file system is actively
> used, the kernel crashes. The socket at 0xd73c2d9c is filled with
> dead beef, so it is a use after free. It is an i386 kernel built
> today.
There are multiple known i
On 20/03/18(Tue) 17:04, Visa Hankala wrote:
> On Tue, Mar 20, 2018 at 10:45:56AM +0100, Martin Pieuchot wrote:
> > On 19/03/18(Mon) 15:38, Visa Hankala wrote:
> > > On Mon, Mar 19, 2018 at 12:27:10PM +0100, Martin Pieuchot wrote:
> > > > Thanks for the report.
> &
On 20/03/18(Tue) 20:09, Alexander Bluhm wrote:
> On Tue, Mar 20, 2018 at 02:24:40PM +0100, Martin Pieuchot wrote:
> > So here's a diff to add locking to NFS nodes. I couldn't reproduce the
> > panic above with it. So I'd be interested if you could try it. Note
>
Since we switched to the modesetting driver by default, the supported
XvImage formats no longer include YUY2 nor UYVY which are expected by
video(1). Using the following Xorg.conf makes video(1) works again.
Section "Device"
Identifier "Device0"
Driver "intel"
EndSection
Attached are the out
00 addr 1
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> vmm0 at mainbus0: SVM/RVI
> sdmmc0: can't enable card
> axen0 at uhub0 port
On 05/02/18(Mon) 18:31, Artturi Alm wrote:
> On Mon, Feb 05, 2018 at 02:51:48PM +0100, Martin Pieuchot wrote:
> > On 04/02/18(Sun) 11:28, Artturi Alm wrote:
> > > Hi,
> > >
> > > machdep.forceukbd=1 feels broken to me, as i use "sv", and it doesn&#x
On 10/04/18(Tue) 11:57, Mark Kettenis wrote:
> > Date: Tue, 27 Mar 2018 13:40:02 +0200
> > From: Martin Pieuchot
> >
> > On 05/02/18(Mon) 18:31, Artturi Alm wrote:
> > > On Mon, Feb 05, 2018 at 02:51:48PM +0100, Martin Pieuchot wrote:
> > > &
ff -N patches/patch-00_kqueue_fix
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-00_kqueue_fix 11 Apr 2018 14:26:44 -
@@ -0,0 +1,2060 @@
+commit aa39a0557c679fc345b0ba72a87c33152eb8ebcd
+Author: Martin Pieuchot
+Date: Tue Feb 20 16:57:00 2018 +
+
+kqueue: Multiple fixes and s
On 09/05/18(Wed) 07:48, Artturi Alm wrote:
> On Tue, May 08, 2018 at 01:44:39AM +0300, Artturi Alm wrote:
No bug are irrelevant to fix. But working with you is hard, really
hard. You never explain what the problem is. Reading your email is
an exercise in frustration because you can do some goo
On 09/05/18(Wed) 12:13, Artturi Alm wrote:
> On Wed, May 09, 2018 at 10:23:41AM +0200, Martin Pieuchot wrote:
> > On 09/05/18(Wed) 07:48, Artturi Alm wrote:
> > > On Tue, May 08, 2018 at 01:44:39AM +0300, Artturi Alm wrote:
> >
> >
> > No bug are irrelevant t
On 08/05/18(Tue) 22:26, Michael-John Turner wrote:
> [...]
> ndp info overwritten for fe80:d::b408:97aa:a658:760e by 40:85:1b:ab:69:d5 on
> vlan41
> ndp info overwritten for fe80:c::b408:97aa:a658:760e by c8:00:44:93:05:62 on
> vlan40
Could you post your routing table so we can understand which
On 13/05/18(Sun) 05:36, Artturi Alm wrote:
> Hi,
>
>
> I was looking at fixing my code for ctf pprinting arrays in ddb(4),
> and came across ctf in section 5 man pages for freebsd with google,
> which lead me to wondering about this, and even think about possibility
> of an bug here, since the ct
On 13/05/18(Sun) 23:16, Michael-John Turner wrote:
> Hi,
>
> On Thu, May 10, 2018 at 05:13:17PM +0200, Alexander Bluhm wrote:
> > When an IPv6 neigbor discovery timeout occurs, the kernel tries to
> > remove the NDP entry. It is stored in the routing table. The
> > problem is that this NDP route
After upgrading to the last packaged version of firefox, browsing become
once again unusable. This time the problem seems due to rendering, as
switching back to the "intel" driver made the rendering of the pages
normal again. With the "modesetting" driver it takes multiple seconds
and scrolling i
On 16/05/18(Wed) 08:06, Harald Dunkel wrote:
> Hi folks,
Thanks for the report.
> hopefully its allowed to repost this message here:
>
> One gateway running 6.3 ran into the debugger last night. Last words:
>
> login: kernel: protection fault trap, code=0
> Stopped at export_sa+0x5c: movl
On 20/05/18(Sun) 21:10, Alexander Bluhm wrote:
> On Sun, May 20, 2018 at 07:24:05AM +0200, p...@centroid.eu wrote:
> > http://centroid.eu/private/p523.jpg
>
> ml_enqueue+0x11
> /usr/src/sys/kern/uipc_mbuf.c:1498
> * 33a1: 48 89 71 08 mov%rsi,0x8(%rcx)
> 33a5:
On 17/05/18(Thu) 21:30, Michael-John Turner wrote:
> On Mon, May 14, 2018 at 03:13:12PM +0200, Martin Pieuchot wrote:
> > Could you try the diff below and as soon as you see the message in the
> > dmesg, get the output of 'route -n show -inet6' and send us both?
>
If a process exit(3)s while one of its threads is blocking in accept(2)
and the half-opened descriptor has already been dup'ed, we get the
following panic:
panic: closef: count (1) < 2
Stopped at db_enter+0x5: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*204115 8002
On 28/05/18(Mon) 22:24, Marc Peters wrote:
> Hi List,
>
> i am having issues with OpenBSD 6.3, latest patches as of today applied. We
> are using gif-tunnels between our datacenters, transport encryption and
> OpenBGPD to announce the prefixes between the datacenters. The boxes also
> have isak
On 07/06/18(Thu) 19:22, Philip Guenther wrote:
> On Thu, 7 Jun 2018, Mike Larkin wrote:
> > Is this a panic inside the guest in vmm, or is this the host panicing when
> > you're doing something while a VM is running in vmm on that host?
> >
> > Can't really tell from the trace here...
>
> This wa
On 06/06/18(Wed) 16:21, multiplexd wrote:
> >Synopsis: Assertion failure when adding point-to-point routes to
> >interfaces in rdomain with deleted loopback
> >Category: Reliability
> >Environment:
> System : OpenBSD 6.3
> Details : OpenBSD 6.3 (GENERIC) #3: Thu
On 16/06/18(Sat) 23:31, multiplexd wrote:
> [...]
> As a supplementary question, is it intended that (non-default) rdomains
> cannot be "deleted" at runtime after they have been created?
Let's say that deletion hasn't been implemented.
On 28/06/18(Thu) 14:53, Visa Hankala wrote:
> On Wed, Jun 27, 2018 at 08:46:04PM +0200, Landry Breuil wrote:
> > On Wed, Jun 27, 2018 at 05:37:54PM +0100, Laurence Tratt wrote:
> > > >Synopsis:kernel_lock not locked
> > > >Category:kernel
> > > >Environment:
> > > System : Op
On 06/07/18(Fri) 12:49, Alexander Bluhm wrote:
> On Mon, May 07, 2018 at 05:21:19PM +0200, Alexander Bluhm wrote:
> > panic: vinvalbuf: dirty bufs
>
> At least I know what is going on here.
>
> vinvalbuf() calls ffs_fsync() to write all dirty buffers of the
> mount point to disk.
>
>
On 20/07/18(Fri) 03:12, Mike Larkin wrote:
> On Wed, Jul 18, 2018 at 11:34:41PM +, Romain wrote:
> > > I'm wondering if this is due to the fact that we detach usb(4) devices on
> > > suspend. Looks like this may be trying to process a timeout that
> > > corresponds
> > > to a device that is
On 20/07/18(Fri) 14:32, Theo de Raadt wrote:
> Martin Pieuchot wrote:
>
> > On 20/07/18(Fri) 03:12, Mike Larkin wrote:
> > > On Wed, Jul 18, 2018 at 11:34:41PM +, Romain wrote:
> > > > > I'm wondering if this is due to the fact that we detach usb(4)
On 18/08/20(Tue) 18:53, Marcus Glocker wrote:
> On Wed, 12 Aug 2020 21:39:15 +0200
> Marcus Glocker wrote:
>
> > jmc was so nice to send me his trouble device over to do some further
> > investigations. Just some updates on what I've noticed today:
> >
> > - The issue isn't specific to xhci(4).
On 21/08/20(Fri) 11:46, Marcus Glocker wrote:
> On Wed, 19 Aug 2020 20:31:05 +0200
> Marcus Glocker wrote:
>
> > On Wed, Aug 19, 2020 at 01:21:35PM +0200, Marcus Glocker wrote:
> >
> > > On Wed, 19 Aug 2020 12:02:23 +0200
> > > Martin Pieuchot wrote:
On 25/11/20(Wed) 19:41, AIsha Tammy wrote:
> Replicable bug that has happened from sysupgrading to snapshot.
> VPS was working perfectly until this sysupgrade.
>
> VPS boots - drops to kernel panic ddb
>
> Seems to be some mutex issue?
> Had to manually copy information cuz weird web console, so
On 24/11/20(Tue) 09:23, Pierre Emeriaud wrote:
> > Trying to use mgre(4), I found what looks like a reliable way to crash
> > the kernel which might be of interest.
> >
> > This machine is a one-month-old-current fairly light router, with inet
> > default within rdomain 1. I will upgrade to a more
On 26/11/20(Thu) 09:21, AIsha Tammy wrote:
> On 11/26/20 6:51 AM, Martin Pieuchot wrote:
> > On 25/11/20(Wed) 19:41, AIsha Tammy wrote:
> >> Replicable bug that has happened from sysupgrading to snapshot.
> >> VPS was working perfectly until this sysupgrade.
> >&
On 26/11/20(Thu) 20:38, Pierre Emeriaud wrote:
> Hello Martin
>
> Le jeu. 26 nov. 2020 à 14:27, Martin Pieuchot a écrit :
> >
> > >
> > > $ doas route -T1 add 192.0.2.2/32 -link -iface vlan12
> >
> > I wonder if the problem isn't in the validati
On 27/11/20(Fri) 15:47, Denis Fondras wrote:
> > It is, I guess a fix should go in net/rtsock.c to prevent adding "-link"
> > entry on routing table different from ifp->if_rdomain.
> >
>
> I came up with this, which is more radical.
Which is not exactly what we want. This will prevent adding an
Thanks for the report.
On 21/12/20(Mon) 17:00, Aning wrote:
> It's the second mail i try to send to mailing list. After 12 hours i still
> can't view the first one on marc.info
> It have 15 photo attachments, but all mail was less than 25 mg. Often
> protonmail responds when email wasn't receive
Hello,
On 24/12/20(Thu) 12:35, th...@liquidbinary.com wrote:
> >Synopsis:If network drops while running top over SSH, runaway process
> >Category:minor, poor handling of failure mode
> >Environment:
> System : OpenBSD 6.7
> Details : OpenBSD 6.7 (GENERIC) #5: Wed Oct 2
Firefox from -current, tab crashes, kernel says:
firefox[86270]: pledge "", syscall 289
Trace is:
#0 shmget () at /tmp/-:3
#1 0x0b38d9347d7b in ?? () from /usr/X11R6/lib/modules/dri/swrast_dri.so
#2 0x0b38d994ac4b in ?? () from /usr/X11R6/lib/modules/dri/swrast_dri.so
#3 0x0b38d8
On 22/02/21(Mon) 13:48, Stuart Henderson wrote:
> Not much information on this but it's an unusual one so I thought I'd
> post in case it's of interest to anyone. (Re-typed from a screen photo,
> it's remote and used by non-technical people, this is all I have).
>
> panic: uao_fin_swhash_elt: can'
On 23/02/21(Tue) 07:53, Jonathan Matthew wrote:
> On Mon, Feb 22, 2021 at 01:48:01PM +, Stuart Henderson wrote:
> > Not much information on this but it's an unusual one so I thought I'd
> > post in case it's of interest to anyone. (Re-typed from a screen photo,
> > it's remote and used by non-t
Test program below, provided by robert@ blows up when compiled with
"-static" and "-no-pie":
$ c++ -no-pie -static e.cc && ./a.out
Segmentation fault (core dumped)
#0 libunwind::EHHeaderParser::decodeEHHdr
(addressSpace=..., ehHdrStart=4211204, ehHdrEnd=4876, ehHdrInfo=...)
at /usr/s
When debugging a multi-threaded process with egdb(1), exiting the
debugger generally result in this:
PID TID PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
15448 242044 100 64M 179M idle fsleep0:11 0.00% soffice.bin
15448 251679 100 64M 179M stop/
On 19/11/19(Tue) 11:22, Martin Pieuchot wrote:
> When debugging a multi-threaded process with egdb(1), exiting the
> debugger generally result in this:
>
> PID TID PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
> 15448 242044 100 64M 179M idle
Thanks for the report.
> ddb{0}>
> memcpy(80165000,fd804da1f728,8d8,80165000,b5bd47118
> ed5c95a,80165000) at memcpy+0x15
> uvideo_vs_cb(fd80778f2870,801667d8,0) at uvideo_vs_cb+0x8b
> usb_transfer_complete(fd80778f2870) at usb_transfer_complete+0x20f
>
On 15/01/20(Wed) 20:26, Vadim Zhukov wrote:
> I have a diff or two for that, will send when I'll come home.
After discussing the issue with Peter Stuge, we figured out that
the free should happen *after* calling config_detach() for the child
device (video(4)).
When video(4) is detached it will ca
Diff below enables a ptrace(2) regress coming from NetBSD.
With usr.bin/make built since -D2020-01-14, that includes -current, it
complains during the last test:
make: Child (52049) not in table?
FAILED
That results in a failing test, however the syscall correctly reports
EBUSY.
On 29/01/20(Wed) 15:00, Marc Espie wrote:
> On Wed, Jan 29, 2020 at 02:04:06PM +0100, Martin Pieuchot wrote:
> > Diff below enables a ptrace(2) regress coming from NetBSD.
> >
> > With usr.bin/make built since -D2020-01-14, that includes -current, it
> > com
Some warnings reported by WITNESS:
witness: lock order reversal:
1st 0x81332b38 &rq->lock (&rq->lock)
2nd 0x806a0050 rcs0 (&timeline->lock)
lock order "&timeline->lock"(mutex) -> "&rq->lock"(mutex) first seen at:
#0 witness_checkorder+0x449
#1 mtx_enter+0x34
#2 __i915_request_
On 17/02/20(Mon) 14:55, Joerg Jung wrote:
>
> > On 26. Sep 2019, at 15:02, Stuart Henderson wrote:
> > On 2019/09/26 13:45, Stuart Henderson wrote:
> >> On 2019/09/26 11:16, Joerg Jung wrote:
> >>> Hi,
> >>>
> >>> I run a few busy (~800 req/s) NSD servers which I upgraded
> >>> to 6.5, all stoc
On 27/02/20(Thu) 16:58, boudew...@indes.com wrote:
> >Synopsis:boolean indicators in sensorsd.conf(5) are too cumbersome
> >Category:system
> >Environment:
> System : OpenBSD 6.6
> Details : OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT
> 2019
>
On 28/02/20(Fri) 10:02, Boudewijn Dijkstra wrote:
> Op Thu, 27 Feb 2020 17:30:34 +0100 schreef Martin Pieuchot
> :
> > On 27/02/20(Thu) 16:58, boudew...@indes.com wrote:
> > > >Synopsis:boolean indicators in sensorsd.conf(5) are too
> > > >cumbe
On 28/02/20(Fri) 12:34, Boudewijn Dijkstra wrote:
> Op Fri, 28 Feb 2020 11:14:43 +0100 schreef Martin Pieuchot
> :
> > On 28/02/20(Fri) 10:02, Boudewijn Dijkstra wrote:
> > > Op Thu, 27 Feb 2020 17:30:34 +0100 schreef Martin Pieuchot
> > > :
> > > > O
On 27/03/20(Fri) 22:43, Charlene Wendling wrote:
> Hi,
>
> >Environment:
> System : OpenBSD 6.6
> Details : OpenBSD 6.6-current (GENERIC.MP) #676: Fri Feb 14
> 02:26:37 MST 2020
> dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
>
> Architect
On 28/03/20(Sat) 09:33, Martin wrote:
> After about a week of tests on freshly installed system i can conclude that
> two things affect on stutters 6.6 amd64 with all the patches included. To
> exclude hardware related problems I've changed AMD SOC PC to a new different
> one with the exactly th
On 28/03/20(Sat) 15:30, Stuart Henderson wrote:
> After updating my laptop from
>
> OpenBSD 6.6-current (GENERIC.MP) #653: Thu Feb 20 21:40:37 MST 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> to
>
> OpenBSD 6.6-current (GENERIC.MP) #84: Fri Mar 27 23:50:29
On 29/03/20(Sun) 17:17, Stuart Henderson wrote:
> [...]
> I guess I'll just move it to a wifi network on a different vlan for now.
Well I wouldn't be surprise if the issue is exposed by the use of two
cloning routes. One way to move forward would be to add the name of the
interface in the error
On 30/03/20(Mon) 22:11, Stuart Henderson wrote:
> On 2020/03/30 10:29, Martin Pieuchot wrote:
> > On 29/03/20(Sun) 17:17, Stuart Henderson wrote:
> > > [...]
> > > I guess I'll just move it to a wifi network on a different vlan for now.
> >
> > Well I
On 31/03/20(Tue) 15:08, Martin wrote:
> 1. top -SH -s .3 points me that stutters arrive once process changing its
> state from 'idle' to 'active' with related disk activity.
What about %spin and %intr?
> 2. Any machine with 6.6 GENERIC.MP affected.
> 2.1. 4-core AMD GX-420CA SOC - stutters m
On 02/04/20(Thu) 12:58, Martin wrote:
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, March 31, 2020 3:27 PM, Martin Pieuchot wrote:
>
> > On 31/03/20(Tue) 15:08, Martin wrote:
> >
> > > 1. top -SH -s .3 points me that stutters arrive once process changing
On 02/04/20(Thu) 13:59, Martin wrote:
> ‐‐‐ Original Message ‐‐‐
> On Thursday, April 2, 2020 1:21 PM, Martin Pieuchot wrote:
> > On 02/04/20(Thu) 12:58, Martin wrote:
> >
> > > ‐‐‐ Original Message ‐‐‐
> > > On Tuesday, March 31, 2020 3:27
On 02/04/20(Thu) 16:22, Bastien Durel wrote:
> Hello,
>
> Here is the initial report I made on misc@ about a kernel panic
> triggered by route removal by bird (bird-2.0.6 from ports)
This should be fixed in -current by a commit krw@ did back in November,
could you test a snapshot and see?
Cheers
On 02/04/20(Thu) 18:30, Bastien Durel wrote:
> Le jeudi 02 avril 2020 à 17:15 +0200, Martin Pieuchot a écrit :
> > On 02/04/20(Thu) 16:22, Bastien Durel wrote:
> > > Hello,
> > >
> > > Here is the initial report I made on misc@ about a kernel panic
> >
On 02/04/20(Thu) 18:40, Martin wrote:
> Before starting the video 2017 bsdcon, disabled all the packages software on
> both AMD and i7 and run mpv player and test both machines.
What do you mean? Which software are running? What do you see in
"top -SH -s .3"?
> Shutters on both platforms happ
On 03/04/20(Fri) 09:40, Martin wrote:
> Hello, Martin.
> [...]
> When I run mpv and try to watch 720p video. In case of stutters after some
> time of watching audio flow desyncronized with video flow and mpv show video
> FPS/2 rate afterwards.
>
> Each time of stutter mpv increase 'Dropped' like
On 06/04/20(Mon) 16:54, Charlene Wendling wrote:
> On Wed, 1 Apr 2020 20:27:54 +0200
> Charlene Wendling wrote:
>
> I've got another one, still with:
>
> OpenBSD 6.6-current (GENERIC.MP) #692: Sat Mar 21 10:19:57 MDT 2020
> dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
T
Thanks for your report.
On 07/04/20(Tue) 16:04, Laurent Salle wrote:
> On 06/04/2020 14.36, Laurent Salle wrote:
> > If you wish, I may do some more test the next time the problem occurs.
>
> I've done more tests.
>
> This time, I've noticed the following message on the console "arpresolve:
> un
On 09/04/20(Thu) 16:10, Massimiliano Stucchi wrote:
> >Synopsis:Crash while using ospfd over vxlan
> >Category:bug
> >Environment:
> System : OpenBSD 6.6
> Details : OpenBSD 6.6 (GENERIC.MP) #5: Sun Feb 16 01:56:11 MST 2020
>
> r...@syspatch-66-am
Hello Pascal,
On 09/04/20(Thu) 16:10, Pascal Cabaud wrote:
> > Synopsis: Once a day, my APU1D4 used to crash
> > Category: kernel
> > Environment:
> System : OpenBSD 6.6
> Details : OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT
> 2019
>
>
On 09/04/20(Thu) 20:22, Laurent Salle wrote:
> On 08/04/2020 06.52, Martin Pieuchot wrote:
>
> > It's the same bug as reported by sthen@. Two interfaces in the same subnet
> > have two identical cloning routes:
>
> I've been able to reproduce systematically the
On 10/04/20(Fri) 09:42, Martin wrote:
> Have you found anything regarding the issue?
No I haven't.
> Now I have time to add dt(4) in conf/GENERIC build & install a new kernel,
> build & install btrace(8) and set kern.allowdt=1 in /etc/sysctl.conf.
>
> Looks like dt(4) is a part of -current, but
On 10/04/20(Fri) 11:18, Claudio Jeker wrote:
> On Fri, Apr 10, 2020 at 10:47:53AM +0200, Martin Pieuchot wrote:
> > On 09/04/20(Thu) 20:22, Laurent Salle wrote:
> > > On 08/04/2020 06.52, Martin Pieuchot wrote:
> > >
> > > > It's the same bug as rep
On 10/04/20(Fri) 13:19, Claudio Jeker wrote:
> On Fri, Apr 10, 2020 at 12:14:17PM +0200, Martin Pieuchot wrote:
> > On 10/04/20(Fri) 11:18, Claudio Jeker wrote:
> > > On Fri, Apr 10, 2020 at 10:47:53AM +0200, Martin Pieuchot wrote:
> > > > On 09/04/20(Thu) 20:22, Lau
ated to the hardware.
> Le 2020-04-10 09:58, Martin Pieuchot disait :
> > Thanks for the report. This looks to me like a memory corruption in
> > the kernel. This is hard to understand because the panic(9) only show
> > the symptom, not the actual bug.
>
> Ok, I'm reco
On 11/04/20(Sat) 23:09, David Gwynne wrote:
> On Sat, Apr 11, 2020 at 03:21:49AM +, Visa Hankala wrote:
> > On Fri, Apr 10, 2020 at 01:30:47PM -0600, Theo de Raadt wrote:
> > > Why did it take almost a year to find this?
> > >
> > > Or is this bug due to ioctl(2) becoming UNLOCKED on 2020/02/2
On 26/02/20(Wed) 17:39, Mark Kettenis wrote:
> > Date: Wed, 12 Feb 2020 15:24:46 +0100
> > From: Martin Pieuchot
>
> Haven't forgotten about these.
The following are still present on 6.7-beta built from today's sources:
witness: lock order reversal:
1st 0x8
On 14/10/19(Mon) 16:17, Alexander Bluhm wrote:
> On Fri, Oct 11, 2019 at 01:19:02PM +, L??vai, D??niel wrote:
> > uvm_fault(0xfd8124d90960, 0x7f884cecdcf8, 0, 2) -> e
^^
Do I understand correctly that the faulting page is 0x7f884cecd000?
PTE_BA
Thanks for the report.
On 18/04/20(Sat) 18:17, Julian Brost wrote:
> I encountered a reproducible kernel panic during an accidental IPv6
> misconfiguration. In order to reproduce, the OpenBSD machine must be in
> the same subnet as a router that has fe80::1/64 configured and sends
> IPv6 route adv
On 20/04/20(Mon) 14:27, Julian Brost wrote:
> On 2020-04-20 12:14, Martin Pieuchot wrote:
> >> login: panic: kernel diagnostic assertion "!ISSET(rt->rt_flags,
> >> RTF_LOCAL)" failed: file "/usr/src/sys/netinet6/nd6.c", line 727
> >
> > Th
On 20/04/20(Mon) 15:44, Anton Lindqvist wrote:
> > Index: netinet6/nd6.c
> > ===
> > RCS file: /cvs/src/sys/netinet6/nd6.c,v
> > retrieving revision 1.229
> > diff -u -p -r1.229 nd6.c
> > --- netinet6/nd6.c 29 Nov 2019 16:41:01 -
Program below is the smaller version of a syzkaller report [0]. After
running it one is left without usable console. A second execution will
make openpty(3) pick a different "/dev/tty*" node:
50361 crashCALL ioctl(3,PTMGET,0x7f7eda80)
50361 crashNAMI "/dev/ptypd"
50361 crash
Hello Mark,
Thanks for the report.
On 01/05/20(Fri) 16:51, Mark Patruck wrote:
> Problem:
>
> With amdgpu(4) enabled, everything runs fine and smooth for minutes,
> sometimes hours (especially if you don't start lots of programs), but
> all of a sudden X freezes. That means, you can move
On 01/05/20(Fri) 12:13, Anton Lindqvist wrote:
> The order in which the pty master/slave is closed seems to be the
> trigger here. While not duping the master, it's closed before the slave.
> In the opposite scenario, the slave is closed before the master. While
> closing the slave, it ends up here
On 02/05/20(Sat) 10:40, Anton Lindqvist wrote:
> On Fri, May 01, 2020 at 05:17:36PM +0200, Martin Pieuchot wrote:
> > On 01/05/20(Fri) 12:13, Anton Lindqvist wrote:
> > > The order in which the pty master/slave is closed seems to be the
> > > trigger here. While not dup
On 02/05/20(Sat) 16:02, Mark Kettenis wrote:
> > Date: Sat, 2 May 2020 11:33:17 +0200
> > From: Martin Pieuchot
> > [...]
> > Do we see that the issue is caused by the order in which descriptors are
> > closed in fdfree()? The current deadlock occurs because the du
Following backtrace found by robert@'s syzkaller exposes a context /
locking issue related to wsmux's ioctl rwlock:
panic: acquiring blockable sleep lock with spinlock or critical section held
(rwlock) wsmuxlk
trace:
panic+0x15c
witness_checkorder+0x10e0
rw_enter_read+0x66
ws
On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
> On 5/22/20 9:05 PM, Mark Kettenis wrote:
> > > From: Łukasz Lejtkowski
> > > Date: Fri, 22 May 2020 20:51:57 +0200
> > >
> > > Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
> > > too high. Should be 12,25-12,50 V. I replaced to th
On 29/05/20(Fri) 15:57, Visa Hankala wrote:
> On Fri, May 29, 2020 at 04:27:46PM +0200, Alexandre Ratchov wrote:
> > On Thu, May 28, 2020 at 01:41:43PM +0100, Stuart Henderson wrote:
> > > uaudio0 at uhub7 port 2 configuration 1 interface 1 "GN Netcom GN 9350"
> > > rev 2.00/1.00 addr 7
> > > uaud
On 28/06/20(Sun) 22:17, Stuart Henderson wrote:
> Thanks to Jens A. Griepentrog for reporting and bisecting, we discovered
> that sys/conf.h r1.150 broke /dev/ipmi. I found a machine to test on and
> reverting the commit fixes things, but given the commit message I guess
> the diff below (which als
On 06/05/16(Fri) 01:13, Hrvoje Popovski wrote:
> Hi,
>
> I've got
> http://www.supermicro.com/products/motherboard/Xeon/D/X10SDV-TP8F.cfm
> for my openbsd lab. Default BIOS settings for usb is USB3 and with that
> settings i can't install openbsd on it, or boot installed openbsd.
> I have installe
On 31/05/16(Tue) 21:11, Evgeniy Sudyr wrote:
> Hrvoje,
>
> looks my last comment was wrong. I apologise for detracting from this
> important discussion.
>
> We all need support / fix for xhci(4) driver instead of disabling USB
> 3.0 support.
>
> I have same issue on my desktop with Asus z170-k m
On 06/06/16(Mon) 23:20, Giovanni Bechis wrote:
> On Sun, Jun 05, 2016 at 09:39:23PM +0200, giova...@paclan.it wrote:
> > >Synopsis: if I suspend my Toshiba laptop it resumes immediately
> > >Category: kernel/acpi
> > >Environment:
> > System : OpenBSD 6.0
> > Details : OpenBSD 6.
On 04/06/16(Sat) 14:49, Edd Barrett wrote:
> Hi,
>
> My x240t has a touch screen and a stylus. It works well upon first boot
> (asides from the pointer co-ordinates are not yet translated when the
> screen is rotated). However, after suspend and wake, placing the pen on
> or near the screen will c
On 01/06/16(Wed) 16:39, Martijn van Duren wrote:
> [...]
> upd0 detached
> uhidev0 detached
> kernel: protection fault trap, code=0
> Stopped atupd_sensor_invalidate+0xe: movq0xc8(%rsi),%rbx
> ddb{0}> trace
> upd_sensor_invalidate() at upd_sensor_invalidate+0xe
> upd_update_report_cb(
On 14/06/16(Tue) 15:18, Florian Obser wrote:
> Hi,
> I'm seeing this panic on my v6 gateway running in a vm (don't ask):
> It has a v6 tunnel via HE on gif0.
>
> I hope I copied all relevant information, if not, my appologies, I'm
> in a hurry currently, please just ask for more.
>
> I will proba
On 14/06/16(Tue) 20:10, Florian Obser wrote:
> On Tue, Jun 14, 2016 at 06:26:00PM +0200, Martin Pieuchot wrote:
> > On 14/06/16(Tue) 15:18, Florian Obser wrote:
> > > Hi,
> > > I'm seeing this panic on my v6 gateway running in a vm (don't ask):
&g
On 19/06/16(Sun) 11:26, Marcus MERIGHI wrote:
> When booting bsd.rd, after the line
>
> umass0 at uhub4 port 4 configuration 3 interface 0 "Lenovo F5521gw" rev
> 2.00/0.00 addr 3
>
> there is a long (minutes) delay.
>
> To me it seems bsd.rd these days finds a umass device the so-called WWAN
>
On 19/06/16(Sun) 14:23, Marcus MERIGHI wrote:
> m...@openbsd.org (Martin Pieuchot), 2016.06.19 (Sun) 13:28 (CEST):
> > On 19/06/16(Sun) 11:26, Marcus MERIGHI wrote:
> > > When booting bsd.rd, after the line
> > >
> > > umass0 at uhub4 port 4 configuratio
1 - 100 of 527 matches
Mail list logo
