>Synopsis: Defects in mg text editor related to regex searching
>Category: user
>Environment:
System : OpenBSD 6.3
Details : OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT
2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/co
Thanks for the quick reply i'll give it a try next week!
2013/10/11 Stuart Henderson
> On 2013/10/11 11:09, Stuart Henderson wrote:
> > On 2013/10/11 00:23, m...@m021.nl wrote:
> > > >Synopsis: Realtek 8168 ethernet not working
> > > >Category: bugs
> > > >Environment:
> > > System :
So far so good! I applied the patch, build the new kernel and I can confirm
my NICs are now recognized and working.
-- Mark
2013/10/11 Mark
> Thanks for the quick reply i'll give it a try next week!
>
>
> 2013/10/11 Stuart Henderson
>
>> On 2013/10/11 11:09, Stuar
d -T ld.script -X --warn-common -nopie -o newbsd
'${SYSTE...)
Any clue on that?
Regards
Mark.
> Date: Sun, 25 Apr 2010 00:55:01 -0600 (MDT)
> From: "J.C. Roberts"
>
> On Sat, 24 Apr 2010 19:42:49 -0700 (PDT) j...@elsasser.org wrote:
>
> > >Description:
> > After discovering that the my root disk no longer shows up with the
> > bsd.rd for the latest snapshot, I tracked down the probl
> Date: Thu, 22 Feb 2018 07:50:57 +0100 (CET)
> From: j...@navratil.cz
Please try a -current snapshot.
> 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:
> > > On 04/02/18(Sun) 11:28, Artturi Alm wrote:
> > > > Hi,
> > > >
> > > > machdep.forceukbd=1 feels broken to me,
memcpy(&lastmatch, ®ex_match[0], sizeof(regmatch_t));
+ if (regex_match[0].rm_so == 0 &&
+ regex_match[0].rm_eo == 0) break;
regex_match[0].rm_so++;
regex_match[0].rm_eo = llength(clp)
> Date: Tue, 24 Apr 2018 10:35:36 +0200
> From: Landry Breuil
>
> All that to say, maybe that means that video(1) can/should be adapted to
> use another method/encoding, because the camera itself works in firefox
> and is supported. If YUY2 and UYVY are not going to come back with
> modesetting..
ondrm_attachhook+0x2b
> > config_process_deferred_mountroot() at
> > config_process_deferred_mountroot+0x2c
> > main(0) at main+0x7bf
>
> After spending some time trying to track this down I have come up with
> the diff below and included it in ~jsg/radeon.diff.4 can
inteldrm(4) code detects a connection on the S-Video connector. Since
the default is to mirror the console framebuffer on all connected
outputs, the framebuffer is configured as 848x480 such that the full
contents are visible on both outputs.
It seems this model does indeed have a S-Video output. Do you have
that hooked up to something?
Cheers,
Mark
> Date: Thu, 26 Apr 2018 22:01:01 +0200
> From: Theo Buehler
>
> I have an USB-to-SATA cable with a samsung disk attached. When I plug it
> in, the disk tries to attach as a uplcom0. mpi saw that this is due to a
> re-used id and cooked the diff below with which it attaches as umass and
> is prop
> From: Thomas Sullivan
> Date: Sat, 28 Apr 2018 04:03:27 +1000
>
> I've tried reinstalling `amd64` and booting `bsd.sp` but I'm seeing the
> same thing.
>
> Manually resetting `force` to false inside `intel_tv_detect` causes it to
> return the current connector status (presumably
> `connector_s
> Date: Fri, 27 Apr 2018 21:32:19 -0700
> From: Josh Elsasser
>
> This problem still seems to be present. Anyone interested?
It's a bug in our binutils that is hard to fix.
Short-term fix would be to remove the -fno-pie flag, Long term fix is
to switch to lld. Unfortunately lld has a differen
> From: "Elias M. Mariani"
> Date: Fri, 11 May 2018 14:11:36 -0300
>
> I'm using a virtual machine with OpenBSD, the vm hosts nfsd, the real
> machine (rm?) mounts the nfs with "doas mount_nfs host:/remote
> /local".
That's a really, resally, really bad idea.
> Date: Wed, 16 May 2018 09:24:05 +0200
> From: Theo Buehler
>
> On Mon, May 14, 2018 at 01:05:07PM +0200, Otto Moerbeek wrote:
> > On Sun, May 13, 2018 at 10:34:13PM +0200, Alexander Bluhm wrote:
> >
> > > Hi,
> > >
> > > When executing the posixtestsuite port, the i386 kernel crashes.
> > > I
> Date: Tue, 22 May 2018 14:04:56 +0200 (CEST)
> From: eda...@muj-disk.cz
>
> >Synopsis:xbacklight not working on Lenovo ideapad S210 Touch
> >Category:system
> >Environment:
> System : OpenBSD 6.3
> Details : OpenBSD 6.3-current (GENERIC.MP) #38: Wed May 9 17:38:06
sing the other lock and retrying so progress is
> made. The fix for WITNESS complaining is to mark vmmaplk as a vnode lock.
>
> ok?
I don't think so. While we have UVM_FLAG_TRYLOCK, I don't think it is
used in the code paths shown in the original report.
This may still be a fa
> Date: Sun, 3 Jun 2018 13:51:19 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Sat, 2 Jun 2018 15:08:14 -0700
> > From: Philip Guenther
> >
> > On Sat, 2 Jun 2018, Christophe Prévotaux wrote:
> > > This a witness report I got on boot with snaps
chine. But you can't use that memory anyway on a 32-bit OpenBSD
system. And if the physmem variable includes a lot of memory that
isn't actually usable, the kernel will make bad choices in sizing
various things.
Cheers,
Mark
> OpenBSD 6.3-current (GENERIC.MP) #8: Thu Jul 5 00:59:43 C
up the physical memory
below the 4GB boundary you must end up with significantly less than 4G
of physical memory.
Showing the eeprom -p output would help me tell you what's wrong.
> On Thu, Jul 05, 2018 at 02:00:45PM +0200, Peter J. Philipp wrote:
> > On Thu, Jul 05, 2018 at 11:20:51AM +0
00014000
The last two have a starting address >= 0x0001 and
therefore can't be used in 32-bit mode. So these should not be
counted.
Cheers,
Mark
> Date: Sat, 21 Jul 2018 21:33:01 +0200
> From: Sebastian Benoit
>
> Hi,
>
> this is on an orange pi pc2
>
> it was running cvs up at the time.
Yes. Mine does that too. I have no clue what causes this. I don't
see it on any of my other arm64 boards. And patrick@ says his
H5-based nanopi bo
> Date: Mon, 23 Jul 2018 11:09:28 +0200
> From: Alexander Bluhm
>
> On Sat, Jul 21, 2018 at 09:30:36PM +0200, Eivind Eide wrote:
> > There are no crash with drm disabled. I'm attaching the dmesg to this
> > mail. So the update to radeondrm are the cause.
>
> So we know that "ATI Radeon Mobility
> 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
> 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: 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: 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
issue disappear.
There, you fixed it yourself.
The old intel driver is unsupported on your hardware.
Cheers,
Mark
> 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) #
.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
> -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
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
> 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
> 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: 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
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, 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
> ===
> 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
> 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
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
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
> 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&
> 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 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
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: 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
> 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, 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
>
> 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: 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, 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
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
> 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
> 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
> 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
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
I believe this has been fixed already; update to 6.8.
> 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
> 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: 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
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
> 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
> 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: 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: 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
> >
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: 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 wit
> 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 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:
>
> Reboot
> 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
> msgbuf_putchar_unlock
> 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
> 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 do
> 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,
> 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.
Th
> 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.
> >
> > uv
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
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
> 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: 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: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: 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
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
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".
> 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
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: 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
> > > >
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
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:
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
> 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
> 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
> 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: 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,
> > > > >
> >
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
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
0x812b3589handle_workitem_freeblocks+0x39
cs 0x8
rflags 0x10286__ALIGN_SIZE+0xf286
rsp 0x8000225ca1f0
ss 0x10
handle_workitem_freeblocks+0x39:cmpq$0x1,0x18(%ra
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
> 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
> 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:
1 - 100 of 751 matches
Mail list logo
