oerbeek wrote:
> > >
> > > > On Fri, Dec 25, 2020 at 12:59:10PM +0100, Otto Moerbeek wrote:
> > > >
> > > > > On Fri, Dec 25, 2020 at 12:35:57PM +0100, Mark Kettenis wrote:
> > > > >
> > > > > > > Date: Fri, 25 De
> Date: Fri, 25 Dec 2020 11:34:47 +0100
> From: Otto Moerbeek
>
> On Thu, Dec 24, 2020 at 01:29:28PM +0100, Uli Schlachter wrote:
>
> > Hi,
> >
> > due to that other thread, it occurred to me that getaddrinfo() also has
> > another bug: It leaks memory. _asr_use_resolver() allocates memory
> >
> From: AIsha Tammy
> Date: Thu, 24 Dec 2020 19:58:06 -0500
Can you send eeprom -p output for this machine?
> Hi,
> New installation of latest snapshot on Pine64 LTS model fails with
>
> Stopped at 0xfe8000553ba0:panic: uvm_fault failed: ff80009eca34
> esr 9604 far fe80005
> Date: Thu, 24 Dec 2020 12:27:01 +0100
> From: Otto Moerbeek
>
> On Thu, Dec 24, 2020 at 10:36:37AM +0100, Otto Moerbeek wrote:
>
> > On Thu, Dec 24, 2020 at 08:25:45AM +0100, Uli Schlachter wrote:
> >
> > > Hi everyone,
> > >
> > > Am 24.12.20 um 04:35 schrieb Alexey Sokolov:
> > > [...]
> >
> From: "Theo de Raadt"
> Date: Sat, 12 Dec 2020 18:10:38 -0700
>
> Jonathan Gray wrote:
>
> > > Index: sys/arch/i386/include/setjmp.h
> > > ===
> > > RCS file: /mount/openbsd/cvs/src/sys/arch/i386/include/setjmp.h,v
> > > retrievi
tall / upgrade using
> that?
Not really.
A few things to try:
- Does it boot with bsd.sp instead of bsd.mp?
- What happens if you disable the following drivers in the bsd.mp kernel:
pchgpio
acpibtn
acpiac
acpibat
acpihid
acpipwrres
acpicpu
Cheers,
Mark
> Date: Mon, 30 Nov 2020 19:12:19 +0100
> From: Alexander Bluhm
>
> On Thu, Nov 26, 2020 at 04:51:23PM +0100, Marcus MERIGHI wrote:
> > Starting stack trace...
> > panic(81de557b) at panic+0x11d
> > kerntrap(8000229c1630) at kerntrap+0x114
> > alltraps_kern_meltdown() at alltraps_kern
> Date: Sun, 29 Nov 2020 12:54:10 +
> From: Stuart Henderson
>
> On 2020/11/29 13:20, Theo Buehler wrote:
> > On Sun, Nov 29, 2020 at 11:22:06AM +, Stuart Henderson wrote:
> > > I have now seen mine crash with just the base "on by default" daemons,
> > > one incoming ssh connection, top,
> Date: Fri, 27 Nov 2020 18:43:47 +0100
> From: Marcus MERIGHI
>
> s...@spacehopper.org (Stuart Henderson), 2020.11.27 (Fri) 17:54 (CET):
> > On 2020/11/27 16:21, Marcus MERIGHI wrote:
> > > It happened again; anything I should do when "syncing disks..." is done?
>
> This time around it doesn't
I believe this has been fixed already; update to 6.8.
erbeek wrote:
> > > > On Fri, Nov 20, 2020 at 11:09:25AM +0100, Mark Kettenis wrote:
> > > >
> > > > > It's a relatively new driver. It uses MSI which pretty much rules out
> > > > > an issue with shared interrupts. So I suspect
> Date: Sat, 21 Nov 2020 09:17:19 -0700
> From: Aaron Bieber
>
> On Sat, 21 Nov 2020 at 16:34:55 +0100, Mark Kettenis wrote:
> > > Date: Sat, 21 Nov 2020 13:04:40 +0100 (CET)
> > > From: Mark Kettenis
> > >
> > > > From: Aaron Bi
> Date: Sat, 21 Nov 2020 13:04:40 +0100 (CET)
> From: Mark Kettenis
>
> > From: Aaron Bieber
> > Date: Fri, 20 Nov 2020 17:04:57 -0700
> >
> > Hi!
> >
> > I recently swapped out the motherboard in my desktop only to find the
> > onboard eth
> From: Aaron Bieber
> Date: Fri, 20 Nov 2020 17:04:57 -0700
>
> Hi!
>
> I recently swapped out the motherboard in my desktop only to find the
> onboard ethernet is one of those new fancy 2.5G ports.. Anyway - I
> picked up an Intel 82574L card, as the em man page calls that one out
> specifical
It's a relatively new driver. It uses MSI which pretty much rules out
an issue with shared interrupts. So I suspect this is an issue with
the rge(4) driver. In the past we have fun with packet counter
overflow interrupts. Is the storm present immediately after you bring
up the interface? Or ev
> Date: Fri, 30 Oct 2020 08:34:46 -0700 (PDT)
> From: j...@bitminer.ca
>
> >Synopsis:arm64 ilogbf(0.0) incorrect result, should be INT_MIN
> >Category:system
> >Environment:
> System : OpenBSD 6.8
> Details : OpenBSD 6.8-current (GENERIC.MP) #871: Wed Oct 28
> 10:16:1
> Date: Wed, 28 Oct 2020 23:54:40 -0400
> From: George Koehler
>
> >Synopsis:linux/io.h changes broke radeondrm RV350 macppc
> >Category:powerpc
> >Environment:
> System : OpenBSD 6.8
> Details : OpenBSD 6.8-current (GENERIC) #8: Wed Oct 28 22:51:59 EDT
> 2020
>
> Date: Fri, 16 Oct 2020 20:41:29 +0200 (CEST)
> From: mel...@marvinborner.de
>
> >Synopsis:AMDGPU no-retry page fault at boot
> >Category:kernel
> >Environment:
> System : OpenBSD 6.8
> Details : OpenBSD 6.8-current (GENERIC.MP) #115: Fri Oct 16
> 00:42:26 MDT 2020
>
> Date: Tue, 6 Oct 2020 13:06:04 +
> From: Miod Vallat
>
> >Synopsis:lib/csu/init_priority regress test failure on macppc
> >Category:powerpc
> >Environment:
> System : OpenBSD 6.8
> Details : OpenBSD 6.8-current (GENERIC) #3: Tue Oct 6 07:58:23 GMT
> 2020
>
> From: "Nicola Dell'Uomo"
> Date: Mon, 5 Oct 2020 09:44:49 +0200
>
> if you log into cwm or xfce on X1 Carbon 8th gen, trackpad stops working
> after a random time; there's no need to suspend to ram in order to
> repeat this problem. Sometimes trackpad works again after a random time.
> I thi
> Date: Tue, 29 Sep 2020 19:18:05 +0200
> From: Klemens Nanni
>
> Just installed the latest snapshot on a Lemote 8089D:
>
> Prep miniroot on USB stick:
>
> $ what miniroot68.img
> /home/kn/miniroot68.img:
> OpenBSD 6.8 (RAMDISK) #52: Mon Sep 28 18:29:30 MDT 2020
> PD KSH
Does the diff below help?
Index: dev/pci/dwiic_pci.c
===
RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
retrieving revision 1.10
diff -u -p -r1.10 dwiic_pci.c
--- dev/pci/dwiic_pci.c 18 Feb 2020 12:13:40 - 1.10
+++ dev/pci/dwii
> Date: Sat, 26 Sep 2020 16:32:05 +0200 (CEST)
> From: Mark Kettenis
> Cc: nicola.dellu...@delluomo-morettin.com, bugs@openbsd.org
>
> > Date: Sat, 26 Sep 2020 15:28:15 +0200 (CEST)
> > From: Mark Kettenis
> >
> > > Date: Sat, 26 Sep 2020 11:55
> Date: Sat, 26 Sep 2020 15:28:15 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Sat, 26 Sep 2020 11:55:40 +0200
> > From: "Nicola Dell'Uomo"
> >
> > Il giorno Tue, 22 Sep 2020 12:44:00 +0200 (CEST)
> > Mark Kettenis ha scritto:
> &g
> Date: Sat, 26 Sep 2020 11:55:40 +0200
> From: "Nicola Dell'Uomo"
>
> Il giorno Tue, 22 Sep 2020 12:44:00 +0200 (CEST)
> Mark Kettenis ha scritto:
>
> > Sorry, but we need to see the panic and subsequent acpihid(4) output.
> > If that output doesn&
On 2020-09-17 23:42, Jonathan Gray wrote:
The big difference between July and now is the Mesa 20.1 update which
occurred at the end of August.
It seems to point to memory being incorrectly handled in the kernel.
There never seems to be a simple test case to reproduce problems.
Problems only see
Sorry, but we need to see the panic and subsequent acpihid(4) output.
If that output doesn't survive a reboot, please take a picture and
carefully transcribe the panic and any subsequent output.
Thanks,
Mark
> From: Josh Rickmar
> Date: Mon, 14 Sep 2020 22:48:18 +
>
> >Synopsis:Ryzen CPUs show Go mem corruption during concurrent forking
> >Category:kernel (?)
> >Environment:
> System : OpenBSD 6.8
> Details : OpenBSD 6.8-beta (GENERIC.MP) #0: Mon Sep 14 09:43:05 EDT
> Date: Tue, 25 Aug 2020 18:00:11 +
> From: Mikolaj Kucharski
> Reply-To: bugs@openbsd.org, miko...@kucharski.name
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Sun, Aug 16, 2020 at 01:23:54PM +, Mikolaj Kucharski wrote:
> > On Mon, Aug 10, 2020 at 08:3
> Date: Fri, 21 Aug 2020 20:41:25 +0200
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> This happens on clean -CURRENT on an EdgeRouter PRO 8:
>
> Index: sys/arch/octeon/conf/GENERIC.MP
> ===
On a recent -current system, cpio(1), using the -p option, does
not update the target directory with newer files. For example,
when copying a file from ~/tmp/a to ~/tmp/b:
[mark@green:~/tmp/a]$ ls -l
total 4
-rw-r--r-- 1 mark mark 3 Aug 7 09:39 x
[mark@green:~/tmp/a]$ ls -l ../b
total 4
-rw-r
> Date: Fri, 7 Aug 2020 12:31:39 +0200
> From: Alexandre Ratchov
>
> On Fri, Aug 07, 2020 at 10:08:25AM +0100, Patrick Harper wrote:
> > I think asynchronous transfers don't work with xhci right now, which
> > appears to be how your DAC works. If you can disable USB 3.0 in the
> > BIOS/UEFI set
> From: Mike Belopuhov
> Date: Thu, 30 Jul 2020 09:21:32 +0200
>
> On 29/07/2020 15:23, Mark Kettenis wrote:
> >> Date: Wed, 29 Jul 2020 23:01:15 +1000
> >> From: Jonathan Gray
> >>
> >> On Wed, Jul 29, 2020 at 02:05:18PM +0200, Andre Stoebe w
> Date: Wed, 29 Jul 2020 23:01:15 +1000
> From: Jonathan Gray
>
> On Wed, Jul 29, 2020 at 02:05:18PM +0200, Andre Stoebe wrote:
> > >Synopsis: Panic on boot with Hyper-V since Jun 17 snapshot
> > >Category: kernel
> > >Environment:
> > System : OpenBSD 6.7
> > Details : OpenBSD
view. What you point out above is certainly
true, but
then it is consistent with the current behaviour when searching for the
beginning-of-line ('^') anchor and the point at the beginning of a
non-empty line. In that case, the point does not move.
-mark
--
Mark Willson
mark.will...@hydrus.org.uk
https://hydrus.org.uk
> -Original Message-
> From: Theo Buehler
> Sent: 20 July 2020 21:12
> To: Mark Willson
> Cc: bugs@openbsd.org; hil...@codemadness.org
> Subject: Re: mg: segmentation fault when using query-replace-regexp
>
> On Mon, Jul 13, 2020 at 03:47:13PM +0100, Mark
.a) swap on sd0b dump on sd0b
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
fd1 at fdc0 drive 1: density unknown
acpi0: PM1 stuck (en 0x101 st 0x1), clearing
Thanks,
-mark
--
Mark Willson
mark.will...@hydrus.org.uk
https://hydrus.org.uk
> Date: Fri, 10 Jul 2020 17:47:21 +0300 (EEST)
> From: p...@irofti.net
>
> >Synopsis:Default X configuration with Firefox temporarily locks up x250
> >with Firefox
> >Category:kernel
> >Environment:
> System : OpenBSD 6.7
> Details : OpenBSD 6.7-current (GENERIC.MP) #
issue disappear.
There, you fixed it yourself.
The old intel driver is unsupported on your hardware.
Cheers,
Mark
> Date: Sat, 4 Jul 2020 17:24:24 +0200
> From: Paul de Weerd
>
> Hi Mark,
>
> Thanks for the reply and the diff!
>
> On Sat, Jul 04, 2020 at 12:19:59AM +0200, Mark Kettenis wrote:
> | That probably means Paul is using somewhat broken firmware.
>
> pkg_i
> Date: Sat, 4 Jul 2020 21:38:46 +1000
> From: Jonathan Gray
>
> On Sat, Jul 04, 2020 at 12:22:41PM +0200, Landry Breuil wrote:
> > On Sat, Jul 04, 2020 at 05:58:07PM +1000, Jonathan Gray wrote:
> > > On Fri, Jul 03, 2020 at 11:14:02PM -0400, Joe Gidi wrote:
> > > > Hello,
> > > >
> > >
> > > f
> Date: Fri, 3 Jul 2020 22:59:21 +0100
> From: Stuart Henderson
> Cc: Mark Kettenis , bugs@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On 2020/07/03 22:34, Paul de Weerd wrote:
> > Hi Mark,
> >
> > On Fri,
> Date: Fri, 3 Jul 2020 13:37:19 +0200
> From: Paul de Weerd
>
> [ CC:'ing Mark ]
>
> My first guess hit the spot: after reverting Mark's commit, my RPi3
> boots again, please find the dmesg below.
These bits from you old dmesg worry me:
> | | cpu1 at m
> From: Janne Johansson
> Date: Mon, 15 Jun 2020 19:15:36 +0200
> Content-Type: multipart/mixed; boundary="ea5a1505a8229334"
>
> Recent AMD box with a bunch of nvme drives, never booted anything, crashes
> with
> panic: pr_find_pagehead: dma256: page header missing
> after listing som
> Date: Mon, 15 Jun 2020 09:59:32 -0600
> From: Bob Beck
>
> May 2 kernel. This may have since been fixed, and I will be sysupgrading.
>
> Just recording here in case it hasn't been. lots of stuff in fltamapcopy
> when I broke into ddb
/* didn't work? must be out of RAM. slee
> Date: Thu, 11 Jun 2020 19:35:48 +0100
> From: Stuart Henderson
>
> And this, I was resizing a mupdf window at the time.
Should already be fixed. See jsg's commit eralier today.
> uvm_fault(0xfd87039e5890, 0x58, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at intel_partial_
> Date: Thu, 11 Jun 2020 11:07:11 +0100
> From: Laurence Tratt
>
> The recent DRM update has fixed one long-ish-standing bug for me where Xorg
> sometimes would get stuck while executing Xsession (I could never work out
> why) which is really good!
>
> However I've now had the following kernel p
> Date: Wed, 10 Jun 2020 11:28:04 +0200
> From: Otto Moerbeek
>
> On Tue, Jun 09, 2020 at 08:28:57PM +0200, Mark Kettenis wrote:
>
> > > Date: Tue, 9 Jun 2020 20:08:42 +0200
> > > From: Otto Moerbeek
> > >
> > > On Tue, Ju
> Date: Tue, 9 Jun 2020 20:08:42 +0200
> From: Otto Moerbeek
>
> On Tue, Jun 09, 2020 at 04:19:34PM +0200, Mark Kettenis wrote:
>
> > > Date: Tue, 9 Jun 2020 16:08:26 +0200
> > > From: Otto Moerbeek
> > >
> > > On Tue, Jun 09, 2020 at 04:05
erbeek wrote:
> > > > On Tue, Jun 09, 2020 at 08:01:12AM +0200, Otto Moerbeek wrote:
> > > >
> > > > > On Mon, Jun 08, 2020 at 09:46:23PM +0200, Mark Kettenis wrote:
> > > > >
> > > > > > > Date: Mon, 8 Jun 2020 20:27:22 +020
> Date: Tue, 9 Jun 2020 14:47:13 +0200
> From: Paul de Weerd
>
> Hi all,
>
> I've done a round of upgrades on some of my systems, including my GPD
> Win. The upgrade went fine, but shortly after going multi-user the
> system becomes unresponsive and starts scrolling these two lines
> continuall
> Date: Mon, 8 Jun 2020 20:27:22 +0200
> From: Otto Moerbeek
>
> Hi.
>
> a page fault trap happens if I boot my Thnkpad X1 6th generation in the dock
> or put it in the dock afterwards. The dock has two DP monitors connected.
>
> If I change connector_bad_edid() to return immediately things see
mes with OpenBSD.
Alternatively use the built-in UEFI boot manager and add an option to
load OpenBSD. Admittedly OpenBSD doesn't offer any help setting this
up. But your Linux install should come with the necessary tools to do
this.
Cheers,
Mark
>
> Hi,
>
> Thanks for a great o/s
> 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 the new one.
That might be why the device stops responding. The fact that cleaning
up from a failed USB tra
ok, I need a little bit more info than that.
Can you build a -current kernel with the diff below and send me the
(complete) dmesg output it produces?
Index: arch/amd64/pci/acpipci.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/acpipci.
> Date: Mon, 18 May 2020 18:09:36 +0200
> From: Moises Simon
>
> On Mon, May 18, 2020 at 04:59:22PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 18 May 2020 16:39:06 +0200
> > > From: Moises Simon
> > >
> > > On Mon, Feb 10, 2020 at 01:57:15PM +
> Date: Mon, 18 May 2020 16:39:06 +0200
> From: Moises Simon
>
> On Mon, Feb 10, 2020 at 01:57:15PM +0100, Mark Kettenis wrote:
> > Macpipcioises Simon schreef op 2020-02-01 15:16:
> > > On Wed, Jan 29, 2020 at 10:48:10PM -0700, Nayden Markatchev wrote:
> >
After lots of testing and searching similar issues (which are
already fixed or hardware related), i've switched to a newer
B450 board (MSI) + Ryzen 5 w/o iGPU about one week ago and never
had any hangs/freezes since then. (not even with the two-sided
pdf document).
--
Mark Patruck ( ma
> Date: Thu, 14 May 2020 19:20:00 +1000
> From: Jonathan Gray
>
> On Wed, May 13, 2020 at 11:11:56PM -0700, jo...@armadilloaerospace.com wrote:
> > On a system with VGA graphics, like a VirtualBox:
> >
> > Boot to X.
> > ctrl-alt-F1 back to text mode.
> > As root:
> > wsfontload -h 8 -e ibm /usr
Thanks for the report. I committed a fix for this.
> Date: Wed, 6 May 2020 09:53:56 +0200
> From: Martin Pieuchot
> Cc: bugs@openbsd.org
>
> 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 th
> Date: Sat, 2 May 2020 11:33:17 +0200
> From: Martin Pieuchot
>
> 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 see
On 2020-05-01 17:07, Martin Pieuchot wrote:
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
- - || - has comp. issues with the mainboard
- there are software issues with amdgpu(4)
I know about this thread on freedesktop.org [1], but again...
before buying sth new, i'd like to know about your findings.
Thanks,
-Mark
[1] https://bugs.freedesktop.org/show_bug.cgi?id=105
> Date: Fri, 24 Apr 2020 21:24:40 +0200
> From: Klemens Nanni
>
> My primary domain paniced due to FFS/softdep while; after rebooting it
> i noticed one out of six guest domains having paniced as well.
>
> This paricular one is the only one having a PCI-E device passed through,
> namely one of
> Date: Mon, 20 Apr 2020 14:21:53 +0200
> From: "Alexander Shendi (Web.DE)"
>
> Hi Jonathan,
>
> Thank you for taking the time to respond to my message. I am sure
> you are aware that there are 2 different kinds of Pinebooks (*not*
> the Pinebook Pro). One is the older 14" model, the later is th
> Date: Sun, 19 Apr 2020 14:49:12 +0200
> From: Alexander Shendi
>
> >Synopsis:Kernel panic using standard /bsd kernel
> >Category:kernel, amd64
> >Environment:
> System : OpenBSD 6.7
> Details : OpenBSD 6.7-beta (GENERIC.MP) #140: Sat Apr 18 22:50:48
> MDT 2020
>
> From: "Theo de Raadt"
> cc: Patrick Wildt
> Comments: In-reply-to Mikolaj Kucharski
>message dated "Mon, 13 Apr 2020 18:55:37 -."
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <61132.158680562...@cvs.openbsd.org>
> Date: Mon, 13 Apr 2020 13:20:27 -0600
>
> Mikolaj Kucha
> Date: Sat, 11 Apr 2020 21:46:49 +0200
> From: Patrick Wildt
>
> On Sat, Apr 11, 2020 at 12:41:36PM +, Mikolaj Kucharski wrote:
> > On Sat, Apr 11, 2020 at 09:06:57AM +, Mikolaj Kucharski wrote:
> > > >Synopsis:kernel panic with message _dmamap_sync: ran off map!
> > > >Category:
> Date: Wed, 1 Apr 2020 20:27:54 +0200
> From: Charlene Wendling
You're leaving out the actual panic (show panic), but:
> ddb{1}> trace
> db_enter() at db_enter+0xc
> panic(0) at panic+0xe0
> rw_assert_rdlock(e61f0e88) at rw_assert_rdlock+0x60
> rw_exit_read(9741b8) at rw_exit_read+0x14
> if_inp
I can confirm that the softdep related hangs i saw are gone.
No more issues since the beginning of my tests almost one
week ago.
Thanks,
-Mark
On 2020-03-09 17:51, Todd C. Miller wrote:
I just committed my minimal fix.
- todd
--
Mark Patruck ( mark at wrapped.cx )
GPG key
0x812b3589handle_workitem_freeblocks+0x39
cs 0x8
rflags 0x10286__ALIGN_SIZE+0xf286
rsp 0x8000225ca1f0
ss 0x10
handle_workitem_freeblocks+0x39:cmpq$0x1,0x18(%ra
le_workitem_freefile+0x2a: movq0x20(%rax),%rcx
-Mark
- todd
Index: /sys/ufs/ffs/ffs_softdep.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.148
diff -u -p -u -r1.148 ffs_softdep.c
--- /sys/ufs
or any info - especially to get more debugging
output.
-Mark
--
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51
https://www.wrapped.cx
> Date: Fri, 21 Feb 2020 21:49:33 +1100
> From: Jonathan Gray
>
> On Fri, Feb 21, 2020 at 04:45:01PM +1100, Jonathan Gray wrote:
> > On Tue, Feb 18, 2020 at 12:37:10AM +0100, alexandre wrote:
> > >
> > > > On Mon, Feb 17, 2020 at 01:31:08AM +0100, Alexandre wrote:
> > > > > Hello,
> > > > >
> >
> Date: Wed, 12 Feb 2020 15:24:46 +0100
> From: Martin Pieuchot
Haven't forgotten about these.
> Some warnings reported by WITNESS:
>
> witness: lock order reversal:
> 1st 0x81332b38 &rq->lock (&rq->lock)
> 2nd 0x806a0050 rcs0 (&timeline->lock)
> lock order "&timeline->lock"(m
> Date: Sun, 16 Feb 2020 11:29:03 +0200
> From: Artturi Alm
>
> Hi,
>
> was going after another bug when i found these, the "on" is kind of wrongly
> named, i guess? (fwiw., i only compared against dev/ic/vga.c)
>
> the meaningful variable from sys/dev/wsconsc/wsdisplay.c:
> ..
> 179 in
> From: "Theo de Raadt"
> Date: Thu, 13 Feb 2020 11:50:11 -0700
>
> Denis wrote:
>
> > I installed MC77xx about three years ago into OpenBSD driven machine. It
> > actively uses everyday with msm mode driver. The question was how to
> > detect UMB and MSM devices and attach suitable driver simu
Macpipcioises Simon schreef op 2020-02-01 15:16:
On Wed, Jan 29, 2020 at 10:48:10PM -0700, Nayden Markatchev wrote:
thank you for the bug report.
there is a diff in snapshots that is likely to have caused this
regression. i've backed it out and ran a snapshot built. the new
snapshot should hit
This particular generation of NVIDIA hardware has always caused
problems.
So far any attempts to fix it broke more other hardware so I gave up.
Impatient Banshee schreef op 2020-02-05 15:12:
Synopsis: acpi prevents PCIe expansion cards to work properly
Category: kernel
Environment:
stalling a
snapshot, or at least try booting a snapshot kernel and see how far it
gets?
The issue here is that this machine actually has two graphics devices:
1. Intel integrated graphics on the CPU
2. AST2000 graphics on the management controller
We try to be clever and determine which devic
> Date: Fri, 10 Jan 2020 13:37:38 -0500
> From: Bryan Steele
>
> On Fri, Jan 10, 2020 at 02:59:10AM -0500, James Hastings wrote:
> > > On Sat, Jan 04, 2020 at 06:23:44PM +0100, Mark Kettenis wrote:
> > > > Date: Sat, 4 Jan 2020 12:03:14 -0500
> > > >
Should be fixed by the following diff:
(ok's welcome)
Index: dev/acpi/acpiprt.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiprt.c,v
retrieving revision 1.48
diff -u -p -r1.48 acpiprt.c
--- dev/acpi/acpiprt.c 25 Oct 2016 06:48:58 -
> Date: Sat, 4 Jan 2020 12:03:14 -0500
> From: Bryan Steele
>
> On Sat, Jan 04, 2020 at 11:30:56AM -0500, Bryan Steele wrote:
> > On Sat, Jan 04, 2020 at 05:07:04PM +0100, Mark Kettenis wrote:
> > > > Date: Sat, 4 Jan 2020 10:52:24 -0500
> > > > From: B
Jon, Chris,
Does the problem occur when you disable amdgpio(4) in the kernel?
Type "boot -c" at the bootloader prompt and then "disable amdgpio" at
the UKC> prompt followed by "quit".
unusable. Maybe
just print the pin every 1 times:
static count = 0;
if ((count++ % 1) == 0)
printf("st %llx\n", status)
Cheers,
Mark
> -Bryan.
>
> interrupt total rate
> irq0/clock1558764
> Date: Sat, 4 Jan 2020 10:27:47 -0500
> From: Chris Bennett
>
> On Sat, Jan 04, 2020 at 09:42:40AM -0500, Jon Fineman wrote:
> > I sysupgraded to 6.6 current #583 on my laptop. The prior current was
> > working, not sure what number.
> >
> > About 30-60 seconds after booting it presumably crash
> Date: Tue, 17 Dec 2019 09:11:28 -0800
> From: guent...@openbsd.org
>
> On Tue, 17 Dec 2019, Mark Kettenis wrote:
> ...
> > > However, thos "vmmaplk" instances really are different classes. In
> > > the sys_mlock codepath it is a lock for a userland
> Date: Tue, 17 Dec 2019 09:55:06 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Tue, 17 Dec 2019 09:25:49 +0100
> > From: Anton Lindqvist
> >
> > On Tue, Dec 17, 2019 at 04:01:52PM +1100, Bradley Latus wrote:
> > > Unsure if this ever got through.
> Date: Tue, 17 Dec 2019 09:25:49 +0100
> From: Anton Lindqvist
>
> On Tue, Dec 17, 2019 at 04:01:52PM +1100, Bradley Latus wrote:
> > Unsure if this ever got through.
>
> Already reported[1] but not fixed.
>
> [1]
> https://syzkaller.appspot.com/bug?id=3871fa3807e9588df440bc83440638d52811160e
> Date: Wed, 23 Oct 2019 11:43:25 +0200
> From: Otto Moerbeek
>
> On Wed, Oct 23, 2019 at 11:17:02AM +0200, Paul de Weerd wrote:
>
> > Hi Otto,
> >
> > On Wed, Oct 23, 2019 at 10:58:24AM +0200, Otto Moerbeek wrote:
> > | I could * this has to do with the logging changes. Previously, debug
> > |
> From: Jerome Kasper
> Date: Thu, 10 Oct 2019 11:06:04 +0200
>
> Hello again bugs@,
>
> as my wording might be confusing, i wanted to improve my description
> about that bug report. I know it’s release time, so please don’t
> take this mail as a push for an answer, this is not the case, i’m
> n
> Date: Tue, 08 Oct 2019 04:38:16 +
> From: Zachary Buhman
>
> >Synopsis: dwge nonfunctional on ROCK64
> >Category:
> >Environment:
> Architecture: OpenBSD.arm64
> Machine : arm64
> board : ROCK64
> (https://www.pine64.org/devices/single-board-computers/rock64/)
> OpenBSD miniroot66
;slow" Cortex-A53 cores and other network stack code may run there as
well.
I'm not sure 900 Mbit/s is actually achievable on this hardware.
Allegedly the busses on ARM SoCs often are a bottle-neck. Can you
achieve such rates with other OSes ib this hardware?
Cheers,
Mark
&
> Date: Sun, 6 Oct 2019 17:13:58 +0200 (CEST)
> From: d.rausch...@gmail.com
>
> >Synopsis:kernel-panic on starting network with -current
> >Category:kernel panic
> >Environment:
> System : OpenBSD 6.6
> Details : OpenBSD 6.6-beta (GENERIC) #267: Sun Sep 29 11:26:16 MDT
> From: Rudolf Leitgeb
> Date: Sat, 28 Sep 2019 17:27:20 +0200
>
> > Someone who doesn't develop in the kernel makes proposal for
> > a platform they deride as sucking, so why not just do the worst
> > possible job because who cares
>
> That platform is perfect for what I need, that's why I inst
Hi Mike,
On 9/26/19 3:17 PM, Mike Larkin wrote:
On Thu, Sep 26, 2019 at 11:54:03AM +0200, Mark Patruck wrote:
When running OpenBSD 6.6-beta on bare metal with hw.smt=0...
...and SMT disabled in BIOS
hw.machine=amd64
hw.model=AMD EPYC 7402P 24-Core Processor
hw.ncpu=24
hw.ncpufound=24
hw.smt
trace frame: 0x7f7f40d0, count: -7
ddb{2}> ps
On 9/25/19 7:31 PM, Mike Larkin wrote:
On Wed, Sep 25, 2019 at 06:57:20PM +0200, Mark Patruck wrote:
After trying lots of different combinations in ESXi (VM templates, Cores
per Socket) w/o luck, i've even disabled SMT in BIOS. Althou
re, tmux.core), but after
additional 10-20sec the system becomes more stable.
On 9/24/19 6:36 PM, Mark Patruck wrote:
As written earlier, when booting bsd.mp leaving smt off, everything's
fine - the system boots till the end.
The interesting thing is, it seems like turning hw.smt=1 instantly kills
hat, i'm also wondering why dmesg says, the L3 cache is disabled...
cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 128MB 64b/line disabled L3 cache
On 9/24/19 12:56 PM, Mark Patruck wrote:
Hi,
while doing some tests on an AMD Ep
201 - 300 of 684 matches
Mail list logo
