> From: Greg Steuck
> Date: Mon, 10 Jan 2022 20:59:17 -0800
>
> Greg Steuck writes:
>
> > This failure can be reduced to a trivial program which does change
> > its behavior for the worse if s_cos.S is taken out:
> >
> > #include
> > #include
> >
> > int main(int a, char**b) {
> > double
> From: "Theo de Raadt"
> Date: Sat, 15 Jan 2022 10:03:07 -0700
>
> Additionally, the /boot code must be able to see that the disk contains
> a hibernate signature, and this may not work if your swap partition
> is at such a far into the disk.
>
> #size offset fstype
> Date: Mon, 10 Jan 2022 15:40:34 +0100 (CET)
> From: Mark Kettenis
>
> > Date: Mon, 10 Jan 2022 14:40:50 +0100
> > From: Alexander Bluhm
> >
> > On Thu, Jan 06, 2022 at 03:59:55PM +0100, Alexander Bluhm wrote:
> > > My armv7 regress machine han
> Date: Mon, 10 Jan 2022 14:40:50 +0100
> From: Alexander Bluhm
>
> On Thu, Jan 06, 2022 at 03:59:55PM +0100, Alexander Bluhm wrote:
> > My armv7 regress machine hangs every day in regress/sys/kern/fork-exit.
>
> Maybe a show uvm provides some information.
Not really. I can reproduce the
> From: Daniel Dickman
> Date: Sun, 9 Jan 2022 16:36:33 -0500
>
> On Sun, Jan 9, 2022 at 4:18 PM Mark Kettenis wrote:
> >
> > > From: Greg Steuck
> > > Date: Sun, 09 Jan 2022 12:47:14 -0800
> > >
> > > Greg Steuck writes:
>
> From: Greg Steuck
> Date: Sun, 09 Jan 2022 12:47:14 -0800
>
> Greg Steuck writes:
>
> > This was reduced from a ghc test. The results of the program differ
> > between OpenBSD 7.0-current-amd64 and a couple of other systems:
>
> Thanks to phessler@ for testing on arm64 where the bug doesn't
> Date: Mon, 20 Dec 2021 15:10:42 +0100
> From: Anton Lindqvist
>
> On Mon, Dec 20, 2021 at 01:19:54PM +, cipher-hea...@riseup.net wrote:
> > I booted into bsd.rd to grep in /var/log/messages when I last ran
> > sysupgrade:
> >
> > Dec 19 22:11:48 0 sysupgrade: installed new /bsd.upgrade.
> Date: Mon, 20 Dec 2021 15:10:42 +0100
> From: Anton Lindqvist
>
> On Mon, Dec 20, 2021 at 01:19:54PM +, cipher-hea...@riseup.net wrote:
> > I booted into bsd.rd to grep in /var/log/messages when I last ran
> > sysupgrade:
> >
> > Dec 19 22:11:48 0 sysupgrade: installed new /bsd.upgrade.
> Date: Mon, 20 Dec 2021 17:55:14 +0100
> From: Paul de Weerd
>
> While watching a video under firefox, I experienced what appeared to
> be a halt of the system: the system no longer responded to
> keyboard/mouse (no keyboard led activity), or to the network. As I
> have a RPi connected to the
> Date: Tue, 14 Dec 2021 22:54:48 +
> From: Renato Aguiar
>
> "Mark Kettenis" writes:
>
> >
> > Does the diff below help?
> >
> >
> > Index: dev/ic/dwiic.c
> > =
> From: Jeremie Courreges-Anglas
> Date: Tue, 14 Dec 2021 13:29:11 +0100
>
> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> > riscv64.ports was running dpb(1) with two other members in the build
> > cluster. A few minutes ago I found it in ddb(4). The report is short,
> > sadly, as
> Date: Tue, 14 Dec 2021 02:20:11 +
> From: Renato Aguiar
>
> I did some investigation over the weekend and I was able to get more
> information about the problem and find a better workaround.
>
> There are 3 devices attaching to `dwiic* at pci0':
>
> dwiic0 at pci0 dev 21 function 0
> Date: Tue, 14 Dec 2021 02:20:11 +
> From: Renato Aguiar
>
> I did some investigation over the weekend and I was able to get more
> information about the problem and find a better workaround.
>
> There are 3 devices attaching to `dwiic* at pci0':
>
> dwiic0 at pci0 dev 21 function 0
> Date: Sat, 11 Dec 2021 05:10:41 -0700
> From: Ted Bullock
>
> On 2021-12-11 4:41 a.m., Mark Kettenis wrote:
> >> Date: Fri, 10 Dec 2021 17:24:58 -0700
> >> From: Ted Bullock
> > So the real problem is:
> >
> >> [drm] *ERROR* radeon: ring
> Date: Fri, 10 Dec 2021 17:24:58 -0700
> From: Ted Bullock
>
> On 2021-12-10 12:53 a.m., Jonathan Gray wrote:
> > On Thu, Dec 09, 2021 at 10:01:30PM -0700, Ted Bullock wrote:
> >> Thoughts folks? This is clearly going to impact all big endian + radeon
> >> gear.
> >>
> >> Actually, I bet that
> Date: Sat, 11 Dec 2021 01:13:32 +0100
> From: Alexander Bluhm
>
> Hi,
>
> I have turned on witness during a full regress run on amd64. It
> found two issues. Basically I am posting this as baseline, so I
> can see if things get better or worse. If someone wants to fix
> them, I can dig
> Date: Mon, 6 Dec 2021 12:54:52 -0700
> From: Ted Bullock
>
> On 2021-12-05 5:15 p.m., Theo de Raadt wrote:
> > Jonathan Gray wrote:
> >> On Sun, Dec 05, 2021 at 04:54:28PM -0700, Ted Bullock wrote:
> >>> Hey folks,
> >>>
> >>> Looking into another usability fault with the SunBlade 100. This
> Date: Mon, 1 Nov 2021 22:33:50 +
> From: Klemens Nanni
I just committed a fix for this. Should be in the next snapshot.
> Neither RAMDISK nor GENERIC.MP from snapshots boot on my Raspberry 4
> Model B unless I disable xhci(4).
>
> I flashed miniroot70.img to an SD card, booted from it,
etting to the bottom of this!
> On 2021-11-25 5:22 a.m., Ted Bullock wrote:
> > On 2021-11-25 5:05 a.m., Mark Kettenis wrote:
> >> From: Ted Bullock
> >>> On 2021-11-25 3:55 a.m., Otto Moerbeek wrote:
> >>>>> + parent = OF_parent(handle);
> Date: Wed, 1 Dec 2021 12:23:00 +0100
> From: Patrick Wildt
>
> Hi,
>
> I was actually wondering why we removed it and it stems from a
> discussion with kettenis when I was doing cleanup, he wrote:
>
> "Maybe it is time to retire the boot_file parsing completely. These
> days we use the
> Date: Sun, 28 Nov 2021 14:32:34 +0100
> From: Martin Pieuchot
>
> On 08/09/21(Wed) 07:33, Anton Lindqvist wrote:
> > On Tue, Sep 07, 2021 at 09:59:22PM -0500, j...@jcs.org wrote:
> > > >Synopsis:ppp panic: locking against myself
> > > >Category:kernel
> > > >Environment:
> > >
> Date: Thu, 25 Nov 2021 04:28:55 -0700
> Content-Language: en-US
> Cc: Theo de Raadt ,
> Mark Kettenis , bugs@openbsd.org
> From: Ted Bullock
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 2021-11-25 3:55 a.m., Otto Moerbeek wrote:
> >
> Date: Thu, 25 Nov 2021 11:55:24 +0100
> From: Otto Moerbeek
>
> On Wed, Nov 24, 2021 at 02:48:29PM -0700, Ted Bullock wrote:
>
> > On 2021-11-20 2:49 p.m., Ted Bullock wrote:
> > > This patch disables fchmod in the bootblock for IDE drives on sparc64
> > >
> > > I can confirm that this
> Date: Wed, 24 Nov 2021 14:48:29 -0700
> From: Ted Bullock
Hi Ted,
Yes, I think your idea is sane and the diff looks good. But I'd like
to test it myself before I commit it and I haven't found the time to
do so yet.
Do remind me if I haven't done so in a week or so.
Thanks,
Mark
>
> Date: Wed, 17 Nov 2021 02:09:50 +
> From: Klemens Nanni
>
> On Sat, Nov 13, 2021 at 09:36:21AM -0700, Theo de Raadt wrote:
> > Did the vm previously have a fdc? I doubt it. I am surprised fdcprobe()
> > returns a success.
>
> Turns out fdc(4) attaches only sometimes. Sometimes on cold
> Date: Sat, 13 Nov 2021 15:45:19 -0700
> From: Ted Bullock
>
> On 2021-11-04 4:04 p.m., Ted Bullock wrote:
> > On 2021-11-02 5:36 p.m., Ted Bullock wrote:
> >> Reporting an issue that is causing my SunBlade 100 (ultrasparc64)
> >> workstation to be unable too boot.
> >
> > I've identified
> Date: Fri, 5 Nov 2021 14:59:05 +
> From: Stuart Henderson
>
> On 2021/11/05 09:32, Paul de Weerd wrote:
> > Linking brcmfmac43455-sdio.raspberrypi,4-model-b.txt (which is what is
> > used with u-boot, I believe) to this name in /etc/firmware fixed bwfm0
> > for me (although performance
> From: Andrew Grillet
> Date: Tue, 2 Nov 2021 14:14:13 +
>
> These were attached to the email I sent last week - that is, the entire
> contents of the directories in
> which I defined the ldom.conf file and the results of compiling it. I have
> attached the file again.
>
> In each case,
> From: Andrew Grillet
> Date: Tue, 2 Nov 2021 13:13:16 +
>
> Hi,
>
> I have found my notes, and OBSD 6.4 ldomctl definitely does not produce a
> workable config on a T1000.
What really needs to be done is compare the files generated by 6.3
ldomctl and the 6.4 ldomctl (or 7.0 ldomctl) such
> Date: Tue, 2 Nov 2021 00:05:49 +
> From: Klemens Nanni
>
> On Mon, Nov 01, 2021 at 10:40:33PM +, Stuart Henderson wrote:
> > On 2021/11/01 22:33, Klemens Nanni wrote:
> > 7.0-release is definitely known. EDK2-based definitely works. Older U-Boot
> > should work.
> >
> > > U-Boot
> Date: Fri, 22 Oct 2021 16:55:44 +0200
> From: Paul de Weerd
Well:
> acpi0 at bios0: ACPI 6.1
> acpi0: sleep states S0 S4 S5
so the BIOS doesn't implement S3. Maybe there is a BIOS update.
Otherwise you'll have to complain to Dell.
Do you see any output with the BOOTX64.EFI from 7.0?
> pool_do_get() at pool_get+0x76
> pool_get() at pmap_enter+0x128
> pmap_enter() at uvm_fault_upper+0x1c2
> uvm_fault_upper() at uvm_fault+0xb2
> uvm_fault() at do_trap_user+0x120
> do_trap_user() at cpu_exception_handler_user+0x7a
>
>
> The conserver logs for this console
> Date: Tue, 14 Sep 2021 13:29:05 +
> From: Visa Hankala
>
> On Tue, May 04, 2021 at 07:29:20AM +0200, Peter J. Philipp wrote:
> > > Index: print-wg.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/tcpdump/print-wg.c,v
> > >
> Date: Wed, 8 Sep 2021 05:47:29 +0200 (CEST)
> From: Nik Reist
>
> During a new install of version 6.9 from both "install" and
> "miniroot" img files, it completes the install successfully but does
> not create a UEFI boot entry. All partitions appear to be created
> properly regardless of
> Date: Tue, 31 Aug 2021 13:58:14 +0200
> From: Solène Rapenne
>
> >Synopsis:kernel crash on bsd.mp with a network PC Card
> >Category:kernel
> >Environment:
> System : OpenBSD 7.0
> Details : OpenBSD 7.0-beta (GENERIC) #187: Sat Aug 21 14:18:05 MDT
> 2021
>
> Date: Tue, 24 Aug 2021 19:18:08 +0200
> From: Paul de Weerd
>
> Hi Mark,
>
> On Tue, Aug 24, 2021 at 06:15:50PM +0200, Mark Kettenis wrote:
> | > Perhaps it's because it lives behind a riser card, on a PCIe to NVMe
> | > adapter (SuperMicro's AOC-SLG3-2M2)
> Date: Tue, 24 Aug 2021 17:31:20 +0200
> From: Paul de Weerd
>
> hi all,
>
> I have a new machine where the kernel doesn't detect an NVMe block
> device. I'm not sure what to look for in dmesg/pcidump, but it seems
> to not appear at all. The only devices that are 'not configured'
> don't
> Date: Fri, 30 Jul 2021 09:29:43 +0200
> From: Anton Lindqvist
>
> >Synopsis:serial console no output
> >Category:amd64
> >Environment:
> System : OpenBSD 6.9
> Details : OpenBSD 6.9-current (GENERIC.MP) #381: Fri Jul 30
> 09:02:53 CEST 2021
>
> Date: Tue, 27 Jul 2021 11:38:20 +1000
> From: Jonathan Gray
>
> On Mon, Jul 26, 2021 at 08:45:24AM +0100, Edd Barrett wrote:
> > Hi,
> >
> > I upgraded my snapshot last week and the machine no longer suspends. I
> > don't know exactly which snap caused this, as I hadn't been upgrading
> >
> Date: Fri, 23 Jul 2021 13:13:27 +0200
> From: Marcus Glocker
>
> On Thu, 22 Jul 2021 23:44:54 +0200
> Marcus Glocker wrote:
>
> > On Thu, 22 Jul 2021 23:07:30 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > > Date: Thu, 22 Jul
> Date: Thu, 22 Jul 2021 22:59:28 +0200
> From: Marcus Glocker
>
> I can install and boot an 6.9 on it (although XHCI fails to
> initialize), but with a miniroot69.img snapshot of today, I'm getting a
> panic with the RAMDISK kernel before the installation procedure starts.
>
> Is this
> Date: Wed, 14 Jul 2021 15:50:46 +1000
> From: Jonathan Gray
>
> On Tue, Jul 13, 2021 at 10:11:29PM +0100, Tom Murphy wrote:
> > Hi Jonathan,
> >
> > On Tue, Jul 13, 2021 at 01:13:03PM +1000, Jonathan Gray wrote:
> > > On Mon, Jul 12, 2021 at 06:22:36PM +, Tom Murphy wrote:
> > > > I had
> Date: Tue, 6 Jul 2021 14:40:54 -0400 (EDT)
> From: k...@intricatesoftware.com
>
> >Synopsis:kernel data fault in data_access_fault
> >Category:sparc64
> >Environment:
> System : OpenBSD 6.9
> Details : OpenBSD 6.9-current (GENERIC.MP) #3: Thu Jul 1 18:00:32
> EDT
Sounds like Intel changed the way CPU frequency scaling is implemented
on these new CPUs. Somebody will have to look into this, but many
OpenBSD developers prefer to buy machines with AMD CPU which is
probably why this hasn't happened yet.
t; recognition site so I didn't have to fix or type much.
> >
> > On Mon, Jun 14, 2021, 1:29 PM Stuart Henderson wrote:
> >
> > > On 2021/06/14 20:32, Mark Kettenis wrote:
> > > > > From: Evan Littmann
> > > > > Date: Sun, 13 Jun 2021
> Date: Thu, 17 Jun 2021 18:06:13 +1000
> From: Jonathan Gray
>
> On Thu, Jun 17, 2021 at 09:44:14AM +0200, Mark Kettenis wrote:
> > > Date: Wed, 16 Jun 2021 23:52:47 -0400
> > > From: Brad Smith
> > >
> > > On Wed, Jun 16, 2021 at 07:46:03PM -
t; recognition site so I didn't have to fix or type much.
> >
> > On Mon, Jun 14, 2021, 1:29 PM Stuart Henderson wrote:
> >
> > > On 2021/06/14 20:32, Mark Kettenis wrote:
> > > > > From: Evan Littmann
> > > > > Date: Sun, 13 Jun 2021
> From: Evan Littmann
> Date: Sun, 13 Jun 2021 17:28:50 -0700
>
> Hello,
>
> I am using OpenBSD 6.9 on an HP EliteDesk 705 G1 desktop mini and it can't
> boot after install due to a panic in mii_phy_setmedia related to the bge
> driver which might be related to this bug
>
Synopsis: NMI errors are flooded to the console on amd64, i386 works
perfectly
Category: kernel
Environment:
System : OpenBSD 6.9
Details : OpenBSD 6.9 (GENERIC.MP) #0: Thu May 20 02:27:25 MDT 2021
Please use the ports gdb.
The base gdb is pretty much useless for debugging code built with
clang, especially userland code that uses threads.
> From: "David N. Arnold"
> Date: Tue, 11 May 2021 22:29:58 -0400
>
> On Tue, May 11, 2021 at 4:45 PM Mark Kettenis wrote:
> > Nice bit of debugging!
>
> Thanks! This is my first serious go with OpenBSD.
>
> > Anyway, here is a diff that prevents t
> From: "David N. Arnold"
> Date: Mon, 10 May 2021 18:28:28 -0400
>
> System description:
>
> 13-inch, Mid 2009 MacBook Pro (MacBookPro5,5) with memory upgraded to 8 GB.
>
> Observed behavior:
>
> On boot, system immediately hangs at:
>
> probing: pc0 mem[
>
> Steps to reproduce:
>
>
> From: Peter Nicolai Mathias Hansteen
> Date: Sat, 8 May 2021 13:15:10 +0200
>
> > 7. mai 2021 kl. 23:28 skrev Mark Kettenis :
> >>
> >> Yeah, nothing changed.
> >
> > That said, can you try the attached diff? Again I'm curious if
> >
> Date: Fri, 7 May 2021 21:04:19 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Fri, 7 May 2021 10:24:19 +0200
> > From: "Peter N. M. Hansteen"
> >
> > On Thu, May 06, 2021 at 05:00:47PM +0200, Peter N. M. Hansteen wrote:
> > > Hi Mark,
&
> Date: Fri, 7 May 2021 10:24:19 +0200
> From: "Peter N. M. Hansteen"
>
> On Thu, May 06, 2021 at 05:00:47PM +0200, Peter N. M. Hansteen wrote:
> > Hi Mark,
> >
> > On Thu, May 06, 2021 at 04:30:00PM +0200, Mark Kettenis wrote:
> > > >
&g
> Date: Thu, 6 May 2021 16:17:51 +0200
> From: "Peter N. M. Hansteen"
>
> Hi Mark,
>
> Are there other tests I could usefully perform for this one?
Not sure. The BIOS on this machine is kinda broken. It adbertises
itself as "hardware reduced" ACPI (so
> Date: Thu, 6 May 2021 21:59:12 +1000
> From: Jonathan Gray
>
> On Wed, May 05, 2021 at 04:47:50PM -0500, Scott Cheloha wrote:
> > Hi,
> >
> > On a hunch I added additional parameter checks to task_add(9) and
> > task_del(9) and caught intel(4) doing something strange.
> >
> > The patch is
> Date: Mon, 3 May 2021 23:06:58 +0200
> From: "Peter N. M. Hansteen"
> Cc: bugs@openbsd.org
> Content-Type: multipart/mixed; boundary="xA/hR9rv41MU9mZo"
> Content-Disposition: inline
>
>
> [1:text/plain Hide]
>
> Hi Mark,
>
> On Mo
Hi Peter,
Here is a small diff. Two questions:
1. Does the machine powerdown if you do halt -p with this diff?
2. Does the diff fix the crashes?
Thanks,
Mark
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> Date: Sun, 2 May 2021 13:05:49 +0200
> From: "Peter N. M. Hansteen"
>
> On Sat, May 01, 2021 at 07:58:20PM +0200, Peter N. M. Hansteen wrote:
> > On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
> > >
> > > Or perhaps boot -c and disable acpicpu* if that doesn't break anything.
> Date: Thu, 29 Apr 2021 09:52:10 +0100
> From: Stuart Henderson
>
> On 2021/04/27 10:35, Alexander Bluhm wrote:
> > On Mon, Apr 26, 2021 at 07:43:29PM +0200, Alexander Bluhm wrote:
> > > One of my i386 machines paniced during make -j 9 build.
> >
> > This is perfectly reproducable. Machine
> Date: Wed, 21 Apr 2021 10:24:43 +0200
> From: Martin Pieuchot
>
> On 16/04/21(Fri) 16:50, Jérôme Frgacic wrote:
> > Thanks for your answer. :)
> >
> > > Could you set "sysctl kern.splassert=2" in order to get a useful
> > > stacktrace for this issue? This is probably where some attention is
> Date: Fri, 9 Apr 2021 07:09:06 +1000
> From: Jonathan Matthew
>
> On Thu, Apr 08, 2021 at 10:24:06AM +0200, Martin Pieuchot wrote:
> > firefox often crash when somebody else connects to the jitsi I'm in.
> > The trace looks like a stack exhaustion, see below.
> >
> > Does this ring a bell?
>
> Date: Thu, 8 Apr 2021 10:24:06 +0200
> From: Martin Pieuchot
>
> firefox often crash when somebody else connects to the jitsi I'm in.
> The trace looks like a stack exhaustion, see below.
I doesn't to me. Take a look at frame #531 and the instruction it is
actually faulting on.
> Does this
> Date: Mon, 29 Mar 2021 21:55:46 +0200
> From: Theo Buehler
> Cc: bugs@openbsd.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Mon, Mar 29, 2021 at 09:25:04PM +0200, Mark Kettenis wrote:
> > > Date: Thu, 25 Mar 2021 08:00:56
> Date: Thu, 25 Mar 2021 08:00:56 +0100
> From: Theo Buehler
>
> On Wed, Mar 24, 2021 at 05:11:52PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 24 Mar 2021 09:47:56 +0100
> > > From: Theo Buehler
> > >
> > > On Tue, Mar 23, 2021 at 08:29:29PM
> Date: Wed, 24 Mar 2021 09:47:56 +0100
> From: Theo Buehler
>
> On Tue, Mar 23, 2021 at 08:29:29PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 23 Mar 2021 17:39:45 +0100
> > > From: Theo Buehler
> > >
> > > On Tue, Mar 23, 2021 at 05:28:37PM
> Date: Tue, 23 Mar 2021 17:39:45 +0100
> From: Theo Buehler
>
> On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 23 Mar 2021 16:56:33 +0100
> > > From: Theo Buehler
> > >
> > > On Tue, Mar 23, 2021 at 04:13:53PM
> Date: Tue, 23 Mar 2021 16:56:33 +0100
> From: Theo Buehler
>
> On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > From: Theo Buehler
> >
> > It would help if you could try and boot a kern
> Date: Tue, 23 Mar 2021 14:14:40 +0100
> From: Theo Buehler
It would help if you could try and boot a kernel that adds some debug
prints instead of calling aml_die(). Probably need to know the values
of alen, bpos, blen, mode and flag for starters.
Cheers,
Mark
> I tried installin
> Date: Wed, 17 Mar 2021 11:47:25 +0900 (JST)
> From: YASUOKA Masahiko
>
> On Tue, 16 Mar 2021 16:03:27 -0700
> Rafael Ávila de Espíndola wrote:
> > Patrick Wildt writes:
> >
> >> Am Tue, Mar 16, 2021 at 03:25:46PM -0700 schrieb Rafael Ávila de Espíndola:
> >>>
> >>> Patrick Wildt writes:
>
issues.
Do you some further details?
Kind regards
Mark
On 04.03.21 12:19, Stuart Henderson wrote:
No need to patch to check this, it is null, see r9 in sh reg (it is
%reg9 in my disassembly)
--
Sent from a phone, apologies for poor formatting.
On 4 March 2021 10:16:58 Karel Gardas wrote
> Date: Sat, 6 Mar 2021 16:47:26 +
> From: Stuart Henderson
>
> there's the case of "don't want to use it _yet_", for example you might
> want to setup umb ready for use but only bring it up manually when
> needed, or you might want to setup pppoe and don't want it to start
> trying to
m my point of view it is important to check and optimize the I/O
error handling as I/O errors can always happen and in such case the OS
should not crash (other hardware combinations might be impacted es well).
Mark, since you do have hardware to test, are you able to develop and
push the patch to t
Thanks a lot for your perfect support and really valuable hints Stuart.
On 02.03.21 22:22, Stuart Henderson wrote:
"trace" and "sh reg" from ddb would give more clues.
...
Things to try for this:
"sysctl machdep.forceukbd=1" may allow the keyboard to work
"sysctl ddb.panic=0" I don't know
> Date: Tue, 2 Mar 2021 23:21:51 +
> From: Stuart Henderson
>
> Don't know if it's important, but if I try to use gdb on a process
> using libcrypto on arm64 (rpi4) I get this.
>
> $ egdb ftp
> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU
Thanks a lot Stuart.
On 02.03.21 18:25, Stuart Henderson wrote:
[cc's trimmed back to bugs@]
On 2021/03/02 19:00, Mark Schneider wrote:
...
Thanks a lot for all hints Stuart.
The isolated 1TB SSD Samsung PRO 860 drives have some AHCI errors
(OpenBSD_6.9beta-RAID5-3x1TB-SSD-isolated.txt
On 02.03.21 10:39, Stuart Henderson wrote:
On 2021/03/02 00:09, Mark Schneider wrote:
Hi,
Thank you for your feeeback.
Also OpenBSD 6.9beta snapshot is crashing when I setup RAID5 with three
"Samsung PRO 860 1TB" SSDs.
OpenBSD obsd69b.it-infra.org 6.9 GENERIC.MP#368 amd64
obsd
150GB"
Today I have used only 6G SATA cables for the RAID configuration.
What I really worry about is the fact, that OpenBSD 6.8 or 6.9beta is
crashing with RAID5 based on Samsung PRO 860 512MB or 1TB SSD drives.
Kind regards
Mark
On 01.03.21 15:35, Atanas Vladimirov wrote:
On 202
> Date: Wed, 17 Feb 2021 11:32:42 +0100
> From: Stefan Sperling
>
> On Tue, Feb 16, 2021 at 11:24:31PM +0100, Grégoire Jadi wrote:
> > Hi,
> >
> > Here is another uvm_fault related to iwn, but this time *not* when
> > unhibernating. I just "grabbed" my laptop that was playing music.
> >
> >
> Date: Wed, 3 Feb 2021 21:59:11 +
> From: Edd Barrett
>
> Hi,
>
> Yesterday I kicked off a dpb(1) run on a Raspberry Pi 4. When I came
> back later, the following crash was on the serial console.
>
> I don't know what triggers it, I'm afraid.
>
> I can try things, if anyone has ideas.
> Date: Wed, 3 Feb 2021 12:51:02 +0100
> From: Marcus Glocker
>
> On Wed, 3 Feb 2021 11:41:17 +
> Edd Barrett wrote:
>
> > On Wed, Feb 03, 2021 at 11:17:01AM +, Stuart Henderson wrote:
> > > btw the problem was seen with umb, it's not just ugen.
> >
> > From mglocker@'s explanation,
> Reply-To:
> From: "Christian Jullien"
>
> I will no longer use MAP_FIXED on OpenBSD and accept that save/restore fails
> on this system. It is a rather minor feature.
>
> Note for myself: I clearly accept that MAP_FIXED can fails to allocate at a
> given address but, when succeeded I still
> Date: Thu, 7 Jan 2021 22:03:15 +1000
> From: Jonathan Matthew
>
> On Wed, Jan 06, 2021 at 12:53:45PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 6 Jan 2021 21:29:52 +1000
> > > From: Jonathan Matthew
> > >
> > > On Wed, Jan 06, 2021 at 10:52
> From: Miod Vallat
> Date: Thu, 7 Jan 2021 11:51:02 - (UTC)
>
> >> Indeed. Wrappinge the mutex operations in msgbuf_putchar with if (!cold)
> >> makes the kernel boot again.
> >
> > Here is a diff for that.
>
> After a bit more thinking, it might be worth introduce a
>
> Date: Wed, 6 Jan 2021 19:14:08 +
> From: Miod Vallat
>
> I have been confused by a very strange issue on sparc64 over the last
> few days, and I can't figure out its cause.
>
> What happens is that cold boots work, but warm boots (i.e. rebooting)
> almost always fail like this:
>
>
> Date: Wed, 6 Jan 2021 21:29:52 +1000
> From: Jonathan Matthew
>
> On Wed, Jan 06, 2021 at 10:52:48AM +0100, Mark Kettenis wrote:
> > > Date: Wed, 6 Jan 2021 20:29:09 +1100
> > > From: Jonathan Gray
> > >
> > > On Tue, Jan 05, 2021 at 10:28:2
> Date: Wed, 6 Jan 2021 20:29:09 +1100
> From: Jonathan Gray
>
> On Tue, Jan 05, 2021 at 10:28:20PM -1000, st...@wdwd.me wrote:
> > I tested with a Protectli FW1 router (dmesg below) forwarding packets
> > between two test machines. The latency spikes occur when running headless
> > beginning
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
> 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
> > >
l / 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
> 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 this
101 - 200 of 608 matches
Mail list logo
