February 14, 2021 8:35 AM, "Marcus Glocker" wrote:
> On Sun, Feb 14, 2021 at 01:25:34PM +, martin.qu...@disroot.org wrote:
>
>> February 14, 2021 2:30 AM, "Marcus Glocker" wrote:
>>
>> On Sun, Feb 14, 2021 at 01:16:12AM +, martin.qu...@disroot.org wrote:
>>
>> February 13, 2021 5:05
February 14, 2021 2:30 AM, "Marcus Glocker" wrote:
> On Sun, Feb 14, 2021 at 01:16:12AM +, martin.qu...@disroot.org wrote:
>
>> February 13, 2021 5:05 PM, "Marcus Glocker" wrote:
>>
>> On Sat, Feb 13, 2021 at 09:35:31PM +, martin.qu...@disroot.org wrote:
>>
>> February 13, 2021 12:34
February 13, 2021 5:05 PM, "Marcus Glocker" wrote:
> On Sat, Feb 13, 2021 at 09:35:31PM +, martin.qu...@disroot.org wrote:
>
>> February 13, 2021 12:34 PM, "Marcus Glocker" wrote:
>>
>> On Sat, Feb 13, 2021 at 04:50:46PM +, martin.qu...@disroot.org wrote:
>>
>> February 13, 2021
February 13, 2021 12:34 PM, "Marcus Glocker" wrote:
> On Sat, Feb 13, 2021 at 04:50:46PM +, martin.qu...@disroot.org wrote:
>
>> February 13, 2021 10:44 AM, "Anton Lindqvist" wrote:
>>
>> Hi,
>>
>> On Sat, Feb 13, 2021 at 01:58:28PM +, martin.qu...@disroot.org wrote:
>>
>> On amd64,
February 13, 2021 10:44 AM, "Anton Lindqvist" wrote:
> Hi,
>
> On Sat, Feb 13, 2021 at 01:58:28PM +, martin.qu...@disroot.org wrote:
>
>> On amd64, upgrading from 6.8 stable to snapshot my Logitech G413 \
>> keyboard is not sending keypresses. i.e) Pressing the "a" key \
>> does nothing.
On amd64, upgrading from 6.8 stable to snapshot my Logitech G413 \
keyboard is not sending keypresses. i.e) Pressing the "a" key \
does nothing. There’s an error message saying \
“uhidev_intr: bad repid 48” To test that it's not a \
problem with my keyboard I noticed that the function keys still
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
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
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
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 validation
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 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
weird web console, so my apologies
> if this isn't enough information.
What is the date of the snapshots? If you can reproduce this could you
give us the output of the "trace" command?
Thanks,
Martin
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 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
On Mon, Jul 06, 2020 at 11:51:10PM +1000, Jonathan Gray wrote:
> On Mon, Jul 06, 2020 at 11:17:34AM +0200, Martin Ziemer wrote:
> > On Wed, Jul 01, 2020 at 01:47:57PM +1000, Jonathan Gray wrote:
> > > On Tue, Jun 30, 2020 at 07:10:10PM +0200, Martin Ziemer wrote:
>
On Wed, Jul 01, 2020 at 01:47:57PM +1000, Jonathan Gray wrote:
> On Tue, Jun 30, 2020 at 07:10:10PM +0200, Martin Ziemer wrote:
> > With this patch (and driver "intel" in /etc/X11/xorg.conf) my system works.
> > Tested suspend/resume and normal browsing.
>
> Tha
On Wed, Jul 01, 2020 at 01:53:14AM +1000, Jonathan Gray wrote:
> cherryview/braswell still had trouble even after recent port of drm from
> linux 5.7.
>
> I can run X on -current with < gen8 style rings.
>
> Index: dev/pci/drm/i915/i915_pci.c
>
B revision 1.0
uhub3 at usb3 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00
addr 1
usb4 at ohci1: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00
addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: n
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
tsc: Fast TSC calibration failed
tsc: Unable to calibrate against PIT
tsc: No referece (HPET/PMTIMER) available
tsc: Marking TSC unstable due to could not calculate TSC khz
Martin
>Synopsis: Crash when using bridge interface
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7-current (GENERIC.MP) #287: Sun Jun 21
19:57:32 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
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
> > >
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
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
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
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 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
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
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, Martin.
Good news. It seems I found the main cause of stuttering problem, but some
small stutters are present anyway and lead to package applications.
Firstly, I've changed max. open file descriptors for default: and two times
more for some applications like asterisk: postgresql
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 -
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
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
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?
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 0x8136a880
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
On 10/04/20(Fri) 12:18, Pascal Cabaud wrote:
> Hello Martin,
>
> Thanks for searching bits in this bug report. Are the APU really popular
> to run OpenBSD or is there a problem with them: AFAICS, i've found many
> reports in archives...
The problem is unlikely to be related
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(T
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 reported
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
Hello Martin,
Have you found anything regarding the issue?
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 I can't move to -current right now.
I
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 problem w
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) 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
>
>
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:
>
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
I've shared decoded ktrace with about 56s of mpv video playing to reduce it's
size. I've done one more ktrace for mpv and decoded file shows only 164
sched_yield instances for me. It seems treading problem appears only in stutter
times and don't related to mpv program?
Martin
‐‐‐ Original
I try to share required info ASAP from AMD SOC machine.
Martin, please note that I start mpv itself first time right after your
suggestion to watch your presentation. I didn't use it before for years. So
stutters present on both i7 and AMD SOC systems I have with any background
software
disabling most of them)
sh
systat
Xorg
spectrwm
xterm
xterm
init
xenodm
iostat
ksh
cron
Xorg
top
sh
ksh
sh
xenodm
getty
getty
getty
getty
getty
Can it be system's scheduler problem itself?
Martin
‐‐‐ Original Message ‐‐‐
On Friday, April 3, 2020 8:13 AM, Martin Pieuchot wrote:
> On 02/04
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
Hello, Martin.
Before running mpv to watch the video I _completely_ disabled all the software
from packages from loading in /etc/rc.conf.local to exclude them totally from
testing loop. I do it on i7 2-core CPU machine.
For now from boot runs only:
1. syslogd, pflogd, nsd, unbound, ntpd
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"?
> Shutter
Before starting the video 2017 bsdcon, disabled all the packages software on
both AMD and i7 and run mpv player and test both machines.
Shutters on both platforms happened when APM change low CPU frequency to high.
Maybe it's an apmd issue?
Martin
‐‐‐ Original Message ‐‐‐
On Thursday
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
> >
‐‐‐ Original Message ‐‐‐
On Thursday, April 2, 2020 2:35 PM, Martin Pieuchot wrote:
> On 02/04/20(Thu) 13:59, Martin wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, April 2, 2020 1:21 PM, Martin Pieuchot m...@openbsd.org wrote:
> >
> > &g
shot and see?
Cheers,
Martin
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
‐‐‐ 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 PM, Martin Pieuchot m...@openbsd.org wrote:
> >
> > &g
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 changi
‐‐‐ 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 its
> > state from 'idle' to 'active' with related disk activi
process changing its
state from 'idle' to 'active'.
3. GENERIC (no MP) - stutters are minimal, after 48 hours I can see them very,
very rare and on AMD SOC only.
Martin
‐‐‐ Original Message ‐‐‐
On Saturday, March 28, 2020 7:45 PM, Martin wrote:
> ‐‐‐ Original Mess
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 SO
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 would
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
‐‐‐ Original Message ‐‐‐
On Saturday, March 28, 2020 3:29 PM, Martin Pieuchot wrote:
> 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 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 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
ing has been changed between 6.4 - 6.6.
Martin
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
>
>
8/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
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd1 at scsibus3 targ 1 lun 0:
sd1: 953
...@openbsd.org
Martin
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 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 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 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
Some warnings reported by WITNESS:
witness: lock order reversal:
1st 0x81332b38 >lock (>lock)
2nd 0x806a0050 rcs0 (>lock)
lock order ">lock"(mutex) -> ">lock"(mutex) first seen at:
#0 witness_checkorder+0x449
#1 mtx_enter+0x34
#2 __i915_request_submit+0x5b
#3
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
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 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
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 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
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
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
When halting/rebooting a i386 VM on an amd64 host (dmesg attached), the
following fault is triggered.
The same happens with a self built -current kernel w/o any suspect UVM
diff :o)
kernel: protection fault trap, code=0
Stopped at pmap_apte_flush+0x6:movl%eax,%cr3
ddb> tr
On 23/10/19(Wed) 17:55, Lauri Tirkkonen wrote:
> [...]
> I did some bisecting today: using the github src mirror, I built
> bsd.rd's on a fresh 6.5 install (which I had to manually bootstrap
> libc.so.95.1 on to build all the necessary revisions), booted them on
> a Hetzner VM, and checked whether
On 21/10/19(Mon) 13:28, Alexandr Nedvedicky wrote:
> Hello,
>
>
> >
> > > The vnode is not locked in this path
> > > either so it won't end up waiting on the ongoing vclean().
> >
> > That leads to an interesting question: should we serialize device access
>
On 19/10/19(Sat) 10:30, Anton Lindqvist wrote:
> On Wed, Jul 31, 2019 at 06:11:33PM +0100, Stuart Henderson wrote:
> > July 29 amd64 snap. I had just tested something in a vm (not very
> > common for me) and did "halt -p" in the guest. Immediately afterwards
> > I hit this:
> >
> >
>Synopsis: No acceleration and suspend on braswell, also some crashes
>Environment:
System : OpenBSD 6.6
Details : OpenBSD 6.6-beta (DRMDEBUG) #0: Tue Oct 1 09:40:21 CEST
2019
hor...@mouse.tda.lan:/usr/src/sys/arch/amd64/compile/DRMDEBUG
On 05/09/19(Thu) 23:54, Alexander Bluhm wrote:
> Hi,
>
> When doing a forced unmount on a stressed file system, it may crash
> here.
>
> uvm_fault(0xfd85827449a0, 0x50, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at vfs_lookup+0x5d8: testb $0x1,0x50(%rcx)
> ddb{2}> bt
On 06/07/19(Sat) 20:17, Klemens Nanni wrote:
> Running latest snapshot on a T5240.
>
> The machine paniced while removing interfaces from protected domains.
> Here is the console log showing both the bridge's configuration as well
> as the commands used:
There's a mtx_leave() missing in
On 05/06/19(Wed) 13:09, Russell Sutherland wrote:
> >Synopsis: machine crashes when issuing the ifconfig bridge0 command
> >Category: kernel
> >Environment:
> System : OpenBSD 6.5
> Details : OpenBSD 6.5-current (GENERIC.MP) #5: Mon Jun 3
> 07:46:49 MDT 2019
>
On 09/06/19(Sun) 15:41, Martin Pieuchot wrote:
> [...]
> Another way to prevent stack exhaustion would be to return a reference
> to any `rt' that needs to be deleted instead of deleting it in place.
Diff below does that by adding a new `prt' argument to rtable_walk().
I'm willing
On 05/06/19(Wed) 21:40, Alexander Bluhm wrote:
> On Sat, May 25, 2019 at 02:44:02PM -0300, Martin Pieuchot wrote:
> > It looks like a stack exhaustion.
> > Having a non-recursive art_table_walk() might be a solution.
>
> We see a similar crash on OpenBSD 6.5.
hen the NetBSD code looked really similar to the OpenBSD code but
> really changed in 2008 when I first investigated this.
What you're describing is a known limitation of the actual logic to
cache route entries. There have been multiple attempts to improve it
but none of them landed in the tree.
Cheers,
Martin
On 25/05/19(Sat) 00:51, Lévai, Dániel wrote:
> Hi everyone!
>
> I had this panic in the recent days.
> Attached the ddb output (traces, ps) and the dmesg.
> Unfortunately I wasn't around when it happened, I have no clue what went on
> with the machine then.
> Reading through the traces it has
On 23/05/19(Thu) 02:29, Tom Smyth wrote:
> Hello
> Kernel panic when ifconfig is called and 2 bridges are running in two
> different rdomains
Your trace shows that a context switch occurs while a thread is still
holding a mutex. It isn't clear which thread is that.
The traces shows that a
One new info on this problem:
If is start glxinfo there comes the following error:
i965: Failed to submit batchbuffer: Input/output error
glxgears also produces the same output.
On 01/05/19(Wed) 09:34, Hrvoje Popovski wrote:
> On 30.4.2019. 23:40, Martin Pieuchot wrote:
> > On 30/04/19(Tue) 14:45, Hrvoje Popovski wrote:
> >> Hi all,
> >>
> >> if i have bridge with rstp on interfaces and rstp on switch and i want
> >> to disable
On 02/05/19(Thu) 22:33, nay...@openbsd.org wrote:
> >Synopsis:kernel crash while browsing with ~20 chrome tabs
> >Category:kernel crash
> >Environment:
> System : OpenBSD 6.5
> Details : OpenBSD 6.5-current (GENERIC.MP) #0: Thu May 2 10:35:18
> MDT 2019
>
101 - 200 of 550 matches
Mail list logo
