On Sat, Jul 06, 2024 at 11:11:43AM +0200, Landry Breuil wrote:
> Le Tue, Jul 02, 2024 at 07:50:56PM +, Miod Vallat a écrit :
> > > hi,
> > >
> > > playing with 7.5 on an edgerouter poe, it panics at boot:
> >
> > Congratulations, you've reached a divide by zero in the kernel.
> >
> > This
On Thu, Jul 04, 2024 at 01:06:49PM +0200, Landry Breuil wrote:
> Le Wed, Jul 03, 2024 at 02:31:02PM +0000, Visa Hankala a écrit :
> > On Wed, Jul 03, 2024 at 03:02:52PM +0200, Landry Breuil wrote:
> > > Le Tue, Jul 02, 2024 at 07:50:56PM +, Miod Vallat a éc
On Wed, Jul 03, 2024 at 03:02:52PM +0200, Landry Breuil wrote:
> Le Tue, Jul 02, 2024 at 07:50:56PM +, Miod Vallat a écrit :
> > > hi,
> > >
> > > playing with 7.5 on an edgerouter poe, it panics at boot:
> >
> > Congratulations, you've reached a divide by zero in the kernel.
> >
> > This
On Tue, Apr 23, 2024 at 02:48:32PM +0200, Martin Pieuchot wrote:
> On 22/04/24(Mon) 16:18, Mark Kettenis wrote:
> > > Date: Mon, 22 Apr 2024 15:39:55 +0200
> > > From: Alexander Bluhm
> > >
> > > Hi,
> > >
> > > I see a witness lock order reversal warning with soreceive. It
> > > happens
On Fri, Jun 16, 2023 at 04:06:58PM +0300, Vitaliy Makkoveev wrote:
> On Fri, Jun 16, 2023 at 02:16:29PM +0200, Peter J. Philipp wrote:
> > On Fri, Jun 16, 2023 at 02:30:27PM +0300, Vitaliy Makkoveev wrote:
> > > On Fri, Jun 16, 2023 at 10:53:33AM +0200, Peter J. Philipp wrote:
> > > > On Fri, Jun
On Sun, Dec 18, 2022 at 07:24:09PM +0100, xavie...@mailoo.org wrote:
> New patch applied, same procedure:
>
> se-h1# uname -v
> GENERIC.MP#1
>
> se-h1# tail -f /dev/ugen0.01
>
> [user remove the USB device]
>
> tail: /dev/ugen0.01: Input/output error
> tail: Lost file /dev/ugen0.01:
On Sun, Dec 18, 2022 at 02:32:09PM +0100, xavie...@mailoo.org wrote:
> I tested, it looks promising:
>
> 0. Rebooted on the new GENERIC.MP built, uname -v
>
> GENERIC.MP#0
>
> 1. Physical plug
>
> ugen0 at uhub0 port 7 "INNO TECH USB to Serial" rev 1.10/0.02 addr 3
>
> 2. Read
>
> tail -f
On Sat, Dec 17, 2022 at 02:32:03PM +0100, xavie...@mailoo.org wrote:
> While doing the following actions:
>
> 1. Plugging this USB device:
>
> ugen0 at uhub0 port 7 "INNO TECH USB to Serial" rev 1.10/0.02 addr 2
>
> 2. Running (remotely via ssh)
>
> tail -f /dev/ugen0.01
>
> 3. Physically
On Mon, Jun 20, 2022 at 06:50:11PM +0200, Anton Lindqvist wrote:
> On Sun, Jun 19, 2022 at 11:34:53AM +0000, Visa Hankala wrote:
> > On Fri, Jun 17, 2022 at 04:25:48PM +0300, Mikhail wrote:
> > > I was debugging tog in lldb and in second tmux window opened another
> > &g
On Mon, Jun 20, 2022 at 01:59:25PM +0200, Martin Pieuchot wrote:
> On 19/06/22(Sun) 11:34, Visa Hankala wrote:
> > On Fri, Jun 17, 2022 at 04:25:48PM +0300, Mikhail wrote:
> > > I was debugging tog in lldb and in second tmux window opened another
> > > bare tog ins
On Fri, Jun 17, 2022 at 04:25:48PM +0300, Mikhail wrote:
> I was debugging tog in lldb and in second tmux window opened another
> bare tog instance, after a second I got this panic:
>
> panic: kernel diagnostic assetion "p->p_kq->kq_refcnt.r_refs == 1"
> failed file
On Sat, May 07, 2022 at 07:47:12PM +1000, Joel Sing wrote:
> After upgrading an OpenBSD arm64 (pine64+ board) Go builder to 7.1, the
> following has been triggered twice (once every couple of days):
>
> panic: kernel diagnostic assertion "kn->kn_kq == kq" failed: file
>
On Sat, May 07, 2022 at 07:47:12PM +1000, Joel Sing wrote:
> After upgrading an OpenBSD arm64 (pine64+ board) Go builder to 7.1, the
> following has been triggered twice (once every couple of days):
>
> panic: kernel diagnostic assertion "kn->kn_kq == kq" failed: file
>
On Mon, Jan 24, 2022 at 09:17:29PM -0600, Ed Ahlsen-Girard wrote:
>
> To: bugs@openbsd.org
> Subject: rox-filer on -current has been slow for a week or so.
> From: eagir...@cox.net
> Cc: eagir...@cox.net
> Reply-To: eagir...@cox.net
>
> >Synopsis:rox-filer was running quite slow starting about
On Sat, Dec 11, 2021 at 09:37:08AM +, Visa Hankala wrote:
> On Sat, Dec 11, 2021 at 09:58:54AM +0100, Mark Kettenis wrote:
> > > Date: Sat, 11 Dec 2021 01:13:32 +0100
> > > From: Alexander Bluhm
>
> > > witness: lock order reversal:
> > > 1st 0xf
On Sat, Dec 11, 2021 at 09:58:54AM +0100, Mark Kettenis wrote:
> > Date: Sat, 11 Dec 2021 01:13:32 +0100
> > From: Alexander Bluhm
> > witness: lock order reversal:
> > 1st 0xfd886921d8d8 vmmaplk (>lock)
> > 2nd 0x800022c54130 nfsnode (>n_lock)
> > lock order data w2 -> w1 missing
> >
Here is a revised fix for the panic. It prevents the error by keeping
knotes attached to the fd-indexed knote list during and after the badfd
conversion. This should ensure that no knotes get enqueued after
kqpoll_exit() has finished kqueue_purge().
A badfd knote needs to be delivered only within
On Tue, Nov 16, 2021 at 10:12:58PM +0100, Alexander Bluhm wrote:
> On Tue, Nov 16, 2021 at 12:45:58PM +0100, Alexander Bluhm wrote:
> > According to my console log it was runnig for 5 hours without crash.
> > I will continue testing today.
>
> After another 7:30 hours of stress testing the diff
On Sun, Nov 14, 2021 at 11:35:26PM +0100, Alexander Bluhm wrote:
> Hi,
>
> on my arm64 regress machine I saw this panic during syslogd regress:
>
> OpenBSD 7.0-current (GENERIC.MP) #1391: Fri Nov 12 21:55:27 MST 2021
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
>
On Wed, Oct 27, 2021 at 09:02:08PM -0400, Dave Voutila wrote:
>
> Dave Voutila writes:
>
> > Was tinkering on a bt(5) script for trying to debug an issue in vmm(4)
> > when I managed to start hitting a panic "wakeup: p_stat is 2" being
> > triggered by kqueue coming from the softnet kernel
On Fri, Oct 22, 2021 at 06:21:44PM +0200, p...@delphinusdns.org wrote:
> >Synopsis:opening and closeing bpf rapidly causes problems
> >Category:system
> >Environment:
> System : OpenBSD 7.0
> Details : OpenBSD 7.0 (GENERIC.MP) #1332: Thu Sep 30 16:53:51 MDT
> 2021
>
On Tue, Sep 14, 2021 at 07:31:33PM +0200, Peter J. Philipp wrote:
> On Tue, Sep 14, 2021 at 10:48:44AM -0600, Theo de Raadt wrote:
> > Mark Kettenis wrote:
> >
> > > To be honest, I do think that adding __packed is a reasonable way to
> > > handle protocol structs like this where performance
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
> > retrieving revision 1.6
> > diff -u -p -u -r1.6 print-wg.c
> > --- print-wg.c
On Thu, Jan 07, 2021 at 05:49:48PM +0100, Alexander Bluhm wrote:
> As you can see here, the iperf3 udp performance dropped by 29% at 22nd
> December.
> http://bluhm.genua.de/perform/results/2021-01-05T15%3A48%3A19Z/gnuplot/udp.png
>
> All numbers for each commit at that day are here:
>
On Thu, Jan 07, 2021 at 11:51:02AM -, Miod Vallat wrote:
>
> >> 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_unlocked()
On Thu, Jan 07, 2021 at 07:08:05AM +, Miod Vallat wrote:
> > The per-CPU struct is mapped using a 64K locked TLB entry. That TLB
> > entry is installed by sun4u_bootstrap_cpu(), which gets called *after*
> > initsmgbuf() is called. So this issue was introduced when locking was
> > added to
On Wed, Dec 23, 2020 at 01:46:51PM +, Stuart Henderson wrote:
> On 2020/12/22 06:24, Martin Pieuchot wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2020/12/22 06:24:45
> >
> > Modified files:
> > sys/kern : sys_generic.c
> >
> > Log
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
> > uaudio0: class v1, full-speed, sync, channels: 1 play, 1
On Thu, May 28, 2020 at 01:41:43PM +0100, Stuart Henderson wrote:
> No idea if related to the hangs I saw earlier, but I've just hit a
> uaudio-related kernel crash when starting to play a video in firefox.
>
> RA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xde: can't
> set
I have reverted the patch. Let's see if I could somehow reproduce
the problem myself so I can study it.
On Mon, May 25, 2020 at 03:21:01PM +0100, Stuart Henderson wrote:
> visa pointed me at sys/kern/kern_event.c r1.132 as a possibility -
> I reverted that yesterday and haven't seen the system
On Sun, May 17, 2020 at 05:26:06AM +0200, Klemens Nanni wrote:
> Index: /sys/arch/sparc64/sparc64/mem.c
> ===
> RCS file: /cvs/src/sys/arch/sparc64/sparc64/mem.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 mem.c
> ---
On Sat, Apr 11, 2020 at 11:54:04PM +1000, David Gwynne wrote:
> On Sat, Apr 11, 2020 at 01:43:20PM +0000, Visa Hankala wrote:
> > On Sat, Apr 11, 2020 at 11:09:54PM +1000, David Gwynne wrote:
> > > On Sat, Apr 11, 2020 at 03:21:49AM +, Visa Hankala wrote:
> > > >
On Sat, Apr 11, 2020 at 11:09:54PM +1000, David Gwynne wrote:
> On Sat, Apr 11, 2020 at 03:21:49AM +0000, 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
On Fri, Apr 10, 2020 at 11:39:59PM +0200, Hrvoje Popovski wrote:
> hostname.tpmr20
> trunkport vxlan20
> trunkport vlan20
> up
>
>
> x3550m4# ifconfig tpmr20 destroy
>
> splassert: vlan_ioctl: want 2 have 0
> Starting stack trace...
> vlan_ioctl(8129d800,80206910,800021d048a8) at
On Fri, Apr 10, 2020 at 01:30:47PM -0600, Theo de Raadt wrote:
> Why did it take almost a year to find this?
>
> Or is this bug due to ioctl(2) becoming UNLOCKED on 2020/02/22?
This is not related to ioctl(2) becoming UNLOCKED. Lower-layer ioctl
code, soo_ioctl() included, lock the kernel when
rom the Network Stack to prevent possible
deadlock situations with smr_barrier().
bridge_input() is still KERNEL_LOCK()ed as well as bridge_filterrule().
ok visa@
> Visa Hankala wrote:
>
> > On Fri, Apr 10, 2020 at 10:16:47AM -0400, David Hill wrote:
> > > On a April 9
On Fri, Apr 10, 2020 at 10:16:47AM -0400, David Hill wrote:
> On a April 9, 2020 cvs built machine:
>
> An splassert shows when I add or delete vlan0 on bridge0
>
> # ifconfig bridge0 add vlan0
> splassert: vlan_ioctl: want 2 have 0
> Starting stack trace...
>
On Tue, Mar 31, 2020 at 10:19:36PM +, Bryan Stenson wrote:
> I started "doas ktrace -p " after boot.
>
> However, your clue about "...quotaon(8) could miss the trace file
> vnode..." seems relevant here. I did use "doas quotaoff /home" and
> "doas quotaon -u /home" while proving to myself
On Tue, Mar 31, 2020 at 07:01:52AM +, Bryan Stenson wrote:
> yes, but for an unrelated issue (lots of learning in these isolated times).
>
> On Tue, Mar 31, 2020 at 7:00 AM Theo de Raadt wrote:
> >
> > Were you really performing a ktrac of pflogd?
> >
> > Bryan Stenson wrote:
> >
> > >
On Sat, Feb 29, 2020 at 12:06:17PM -0700, Allen Smith wrote:
> umass0: using SCSI over Bulk-Only
> scsibus0 at umass0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0: removable
> serial.090c1000418120001168
> panic: _dmamap_sync: ran off map!
This is caused by wrong endianess. The diff
On Wed, Nov 20, 2019 at 11:04:15AM -, Miod Vallat wrote:
> Index: sys/arch/mips64/mips64/vm_machdep.c
> ===
> RCS file: /OpenBSD/src/sys/arch/mips64/mips64/vm_machdep.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 vm_machdep.c
On Mon, Nov 04, 2019 at 11:04:21AM -0600, Amit Kulkarni wrote:
> On Sun, Nov 3, 2019 at 1:33 PM Mike Larkin wrote:
> >
> > On Sun, Nov 03, 2019 at 11:01:08AM -0800, Mike Larkin wrote:
> > > On Sun, Nov 03, 2019 at 03:52:00PM +0100, Martin Pieuchot wrote:
> > > > When halting/rebooting a i386 VM
On Sun, Oct 20, 2019 at 02:33:31AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Sat, Oct 19, 2019 at 10:30:07AM +0200, 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
> > >
On Fri, Sep 13, 2019 at 07:57:33PM -0700, Bryan Stenson wrote:
> I just followed the excellent INSTALL.octeon, but had a difficult time
> updating the bootcmd. I think U-boot needs to boot the "bsd" file,
> not the "boot" file (there isn't one, afaik).
Which version of OpenBSD did you install?
On Wed, Jul 31, 2019 at 08:22:55PM +0200, Alexandr Nedvedicky wrote:
> Looks like it can be related to my commit from May:
>
>
> https://github.com/openbsd/src/commit/b50d0c1cf040666aed872208cd6f6ba609197b11#diff-7922ad1d2f6422aa72d4bacd1bf41909
>
> I'll try to take a look. The steps to
On Fri, Mar 01, 2019 at 03:12:41PM -0600, Abel Abraham Camarillo Ojeda wrote:
> panic: assertwaitok: non-zero mutex count: 1
> Stopped at 0x813d9b8c: jr ra
> 0x813d9b90: nop
> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> *328985 76286 0
On Sun, Mar 03, 2019 at 12:13:29PM +0100, Sebastien Marie wrote:
> On Sat, Mar 02, 2019 at 04:00:19PM +0000, Visa Hankala wrote:
> > On Sat, Mar 02, 2019 at 04:37:04PM +0100, Sebastien Marie wrote:
> > > Thread 1 (thread 469200):
> > > #0 sched_yield () at -:3
&
On Sat, Mar 02, 2019 at 01:40:50PM -0500, Ted Unangst wrote:
> Visa Hankala wrote:
> > On Sat, Mar 02, 2019 at 04:37:04PM +0100, Sebastien Marie wrote:
> > > Thread 1 (thread 469200):
> > > #0 sched_yield () at -:3
> > > #1 0x0a8c0609d9c5 in
On Sat, Mar 02, 2019 at 04:37:04PM +0100, Sebastien Marie wrote:
> Thread 1 (thread 469200):
> #0 sched_yield () at -:3
> #1 0x0a8c0609d9c5 in _libc__spinlock (lock=Variable "lock" is not
> available.) at /usr/src/lib/libc/thread/rthread.c:50
> #2 0x0a8c060702be in _thread_flockfile
On Sat, Mar 02, 2019 at 10:29:07AM +0100, Sebastien Marie wrote:
> I am experiencing dead-lock with the new futex based rwlock
> implementation commited few days ago.
The problem happens if a read-write lock has been read-locked and
there are multiple writers waiting. The unlock routine will
On Mon, Oct 01, 2018 at 01:50:59PM +0200, Hrvoje Popovski wrote:
> Hi all,
>
> while testing sasha's "pfsync: avoid a recursion on PF_LOCK" diff i
> manage to get panic. first i thought that this panic have something to
> do with sasha@ work but i can easily reproduce it on clean -current.
>
>
On Wed, Jun 27, 2018 at 08:46:04PM +0200, Landry Breuil wrote:
> On Wed, Jun 27, 2018 at 05:37:54PM +0100, Laurence Tratt wrote:
> > >Synopsis: kernel_lock not locked
> > >Category: kernel
> > >Environment:
> > System : OpenBSD 6.3
> > Details : OpenBSD 6.3-current (GENERIC.MP)
On Thu, Jun 07, 2018 at 05:13:06PM -0700, Philip Guenther wrote:
> (The weird "show witness" output for scsi_base.c mutexes is because
> they're on the stack and need to be unlinked from witness before
> returning; that *might* be causing the problem here, but I doubt it. I'm
> starting on a
On Sat, Jun 02, 2018 at 03:08:14PM -0700, Philip Guenther wrote:
> On Sat, 2 Jun 2018, Christophe Prévotaux wrote:
> > This a witness report I got on boot with snapshot Jun 1st amd64
> >
> > root on sd0a (9b49e3196b9bfae8.a) swap on sd0b dump on sd0b
> > lock order reversal:
> > 1st
On Thu, Apr 19, 2018 at 04:47:36PM -0400, mabi wrote:
> The VPN works fine for low data traffic but as soon as I start a big transfer
> between the two sites the kernel panics when iked wants to rekey the SA. I
> can reproduce this on demand by using the iperf tool for example.
Please test the
On Mon, Mar 19, 2018 at 12:27:10PM +0100, Martin Pieuchot wrote:
> Thanks for the report.
>
> On 19/03/18(Mon) 09:49, Theo Buehler wrote:
> > This is a regression that came with the TOCTOU race fix in kern_sig.c 1.216:
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_sig.c#rev1.216
On Tue, Mar 20, 2018 at 10:45:56AM +0100, Martin Pieuchot wrote:
> On 19/03/18(Mon) 15:38, Visa Hankala wrote:
> > On Mon, Mar 19, 2018 at 12:27:10PM +0100, Martin Pieuchot wrote:
> > > Thanks for the report.
> > >
> > > On 19/03/18(Mon) 09:49, Theo Buehler
On Mon, Mar 19, 2018 at 12:27:10PM +0100, Martin Pieuchot wrote:
> Thanks for the report.
>
> On 19/03/18(Mon) 09:49, Theo Buehler wrote:
> > This is a regression that came with the TOCTOU race fix in kern_sig.c 1.216:
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_sig.c#rev1.216
The patch is included in the most recent octeon snapshot:
Build date: 1511043183 - Sat Nov 18 22:13:03 UTC 2017
On Fri, Nov 17, 2017 at 08:52:59PM -0600, Justin Hibbits wrote:
> Attached is a patch that adds the Ubiquiti Unifi Security Gateway identifier
> to OpenBSD/octeon.
>
> I made the same change to FreeBSD. The USG is virtually identical to the
> EdgeRouter Lite, except maybe the CPU clock speed.
On Thu, Jun 22, 2017 at 02:24:46PM +0200, Janne Johansson wrote:
> while compiling a new kernel with "nice make -j3"...
>
>
> login: panic: pool_do_get: dwc2qtd free list modified: page
> 0x98041cf7; item addr 0x98041cf70018; offset 0x0=0xadbeef
This should be fixed by a patch that
On Sat, Jan 09, 2016 at 04:33:03PM +0100, Tobias Ulmer wrote:
> Argh, too soon.. Started a make build to create some load and it
> paniced:
I backed out the MP pmap diff so the kernel should work again on IP32.
62 matches
Mail list logo
