On 30/04/19(Tue) 14:45, Hrvoje Popovski wrote:
> Hi all,
>
> if i have bridge with rstp on interfaces and rstp on switch and i want
> to disable rstp on openbsd interfaces i'm getting fault trap. I can
> reproduce it on 6.4 and on -current.
> i can't reproduce it if i don't have rstp on switch.
On 30/04/19(Tue) 15:41, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > When my machine doesn't get a reply from a DNS server, generally the
> > wifi router of the place where I'm drinking coffee, applications sit
> > in gethostbyname(3) "indefinitely". At least to
On 30/04/19(Tue) 08:06, David Gwynne wrote:
>
>
> > On 30 Apr 2019, at 03:24, Martin Pieuchot wrote:
> >
> > On 29/04/19(Mon) 17:24, David Gwynne wrote:
> >> On Sun, Apr 28, 2019 at 06:57:02PM -0300, Martin Pieuchot wrote:
> >>> On 23/04/19(Tue) 1
When my machine doesn't get a reply from a DNS server, generally the
wifi router of the place where I'm drinking coffee, applications sit
in gethostbyname(3) "indefinitely". At least too long for me to wait
and I end up killing the app.
$ cat /etc/resolv.conf
# Generated by iwm0
On 29/04/19(Mon) 17:24, David Gwynne wrote:
> On Sun, Apr 28, 2019 at 06:57:02PM -0300, Martin Pieuchot wrote:
> > On 23/04/19(Tue) 12:16, Olivier Antoine wrote:
> > > >Synopsis:panic: Stopped at kqueue_scan
> > > >Category:kernel i386
> > > >
On 23/04/19(Tue) 12:16, Olivier Antoine wrote:
> >Synopsis:panic: Stopped at kqueue_scan
> >Category:kernel i386
> >Environment:
> System : OpenBSD 6.5
> Details : OpenBSD 6.5-current (GENERIC.MP) #1368: Sun Apr 21
> 19:50:46 MDT 2019
>
>
On 26/04/19(Fri) 11:23, Olivier Antoine wrote:
> Hi, could it be that the problem is related to pipex?
> My npppd.conf rely on the default pipex settings (on)
> But net.pipex.enable is 0 since I have no explicit settings in my
> /etc/sysctl.conf
> Under these conditions, I have no difficulty to
On 23/04/19(Tue) 12:16, Olivier Antoine wrote:
> >Synopsis:panic: Stopped at kqueue_scan
> >Category:kernel i386
> >Environment:
> System : OpenBSD 6.5
> Details : OpenBSD 6.5-current (GENERIC.MP) #1368: Sun Apr 21
> 19:50:46 MDT 2019
>
>
Hello,
On 24/03/19(Sun) 01:00, Hrvoje Popovski wrote:
> Hi all,
>
> while playing around with stp and pair interfaces and using exactly the
> same example as in man (4) pair
>
> ifconfig pair0 up
> ifconfig pair1 rdomain 1 patch pair0 up
> ifconfig pair2 up
> ifconfig pair3 rdomain 1 patch
On 26/02/19(Tue) 00:49, James Hastings wrote:
> On 02/25/2019 02:22 PM, Martin Pieuchot wrote:
> > On 18/02/19(Mon) 03:31, James Hastings wrote:
> >> On 17/02/19(Sun) 15:07, Martin Pieuchot wrote:
> >>> On 15/02/19(Fri) 01:47, James Hastings wrote:
> &g
Wow, this was a fast reaction: The solution was checked in just before
i submitted the bug!
I just checked out version 1.92 and recompiled my kernel:
The problem is fixed.
On Wed, Feb 27, 2019 at 01:44:18PM +, Stuart Henderson wrote:
> On 2019/02/27 13:25, Martin Ziemer wrote:
> >
>Synopsis: ure0: usb error on tx: TIMEOUT in current snapshot
>Category:
>Environment:
System : OpenBSD 6.4
Details : OpenBSD 6.4-current (GENERIC) #1: Wed Feb 27 12:14:57 CET
2019
On 18/02/19(Mon) 03:31, James Hastings wrote:
> On 17/02/19(Sun) 15:07, Martin Pieuchot wrote:
> > On 15/02/19(Fri) 01:47, James Hastings wrote:
> > > I settled on a patch providing an additional 250ms powerdelay in
> uhub(4).
> > > mue(4) reliably attaches now, but h
On 24/02/19(Sun) 10:55, Artturi Alm wrote:
> On Mon, Feb 18, 2019 at 03:31:45AM -0500, James Hastings wrote:
> > On 17/02/19(Sun) 15:07, Martin Pieuchot wrote:
> > > On 15/02/19(Fri) 01:47, James Hastings wrote:
> > > > I settled on a patch providing an additional
On 15/02/19(Fri) 01:47, James Hastings wrote:
> On 11/02/19(Mon) 18:58, Artturi Alm wrote:
> > On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote:
> > > On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> > > > Hi,
> > > >
> > > > rath
On 11/02/19(Mon) 18:58, Artturi Alm wrote:
> On Mon, Feb 11, 2019 at 02:15:43PM -0200, Martin Pieuchot wrote:
> > On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> > > Hi,
> > >
> > > rather than patching uhub(4), i figured this would be less not-ok,
> > >
On 10/02/19(Sun) 20:46, Artturi Alm wrote:
> Hi,
>
> rather than patching uhub(4), i figured this would be less not-ok,
> if not ok as-is, given its way more limited scope.
Why shouldn't we patch uhub(4)?
> diff below works for me, but i suppose playing w/timeouts is a must,
> for root on nfs?
On 10/02/19(Sun) 10:25, Florian Obser wrote:
> on resume I was greeted by:
> [typed from a photo (http://sha256.net/dump/usbd_fill_deviceinfo.jpg)]
> kernel: page fault trap, code =0
> Stopped at strlcpy+0x35: movzbl 0(%rsi, %rax,1), %ecx
> strlcpy(81459c81,0,7f) at strlcpy+0x35
>
On 25/01/19(Fri) 02:24, Alexander Bluhm wrote:
> On Tue, Jan 22, 2019 at 12:19:11PM -0200, Martin Pieuchot wrote:
> > > There are still things I don't understand. After a while the CPU
> > > time for idle5, idle6, idle7 does not increase anymore. I am doing
> >
This is fun.
On 17/12/18(Mon) 22:30, Alexander Bluhm wrote:
> On Fri, Nov 02, 2018 at 10:19:15PM +0100, Mark Kettenis wrote:
> > I think Ted is pointing out a different issue here that doesn't really
> > have anything to do with SMT. The issue is that in some cases we end
> > up with CPUs
On 31/10/18(Wed) 02:55, Artturi Alm wrote:
> Hi,
>
> spam in the subject does make ttyC0 unusable in practice with urndis(4).
> I don't like repeating myself, so all i provide is the link where this
> behaviour requiring while (len > 1) is explained:
>
enc1 create
> >
> > use "tap enc1" in iked.conf (hint: "tap enc0" works)
> >
> > For testing purposes it makes sense to lower "lifetime" to f.e. 2m.
> >
> >
> > On Tue, Sep 25, 2018 at 10:50:43AM -0300, Martin Pie
On 20/11/18(Tue) 18:29, Anton Lindqvist wrote:
> On Tue, Nov 20, 2018 at 09:39:52AM +, Natasha Kerensikova wrote:
> > Hello,
> >
> > Context:
> >
> > I have a Thinkpad X220 with an integrated WWAN modem "Lenovo F5521gw",
> > which presents itself as USB devices umodem0-2, ucom0-2, and ugen0
Please don't use bugs@ for feature requests. The safest bet for getting
a feature in the future is to send a diff.
... this said, I think your particular problem can be solved by using
bioctl(8) to build a softraid with CONCAT discipline to combine physical
disk partitions into a "logical
On 27/09/18(Thu) 09:29, Claudio Jeker wrote:
> On Wed, Sep 26, 2018 at 04:57:02PM -0300, Martin Pieuchot wrote:
> > On 26/09/18(Wed) 15:56, Élie Bouttier wrote:
> > > On 9/26/18 12:42 PM, Martin Pieuchot wrote:
> > > > Hello,
> > > >
> > &g
On 26/09/18(Wed) 15:56, Élie Bouttier wrote:
> On 9/26/18 12:42 PM, Martin Pieuchot wrote:
> > Hello,
> >
> > On 26/09/18(Wed) 11:59, e...@bouttier.eu wrote:
> >>> Synopsis: Page fault in rt_setgwroute triggered by npppd under
> >>> speci
Hello,
On 26/09/18(Wed) 11:59, e...@bouttier.eu wrote:
> >Synopsis: Page fault in rt_setgwroute triggered by npppd under specific
> >circumstances
> >Category: kernel (networking)
> >Environment:
> System : OpenBSD 6.3
> Details : OpenBSD 6.3 (GENERIC) #100: Sat
Hello and thanks for the report.
On 21/09/18(Fri) 23:06, e...@bouttier.eu wrote:
> >Synopsis: Panic when destroying vlan interface with virtio parent in
> >promisc mode
> >Category: kernel (net)
> >Environment:
> System : OpenBSD 6.3
> Details : OpenBSD
Hello Tom,
On 12/09/18(Wed) 18:58, Tom Murphy wrote:
> On Wed, Sep 12, 2018 at 12:55:01PM -0300, Martin Pieuchot wrote:
> > On 08/09/18(Sat) 12:07, Tom Murphy wrote:
> > > On Thu, Sep 06, 2018 at 01:06:50PM -0300, Martin Pieuchot wrote:
> > > > Tom, as I said
On 11/09/18(Tue) 07:35, r.ga...@biche.org wrote:
> Le 26.06.2018 17:52, Romain Gabet a écrit :
>
> > Hi,
> >
> > I think there is a problem with ipcomp : packets are compressed even
> > in some cases where compression does not reduce their size ; as a
> > result they are rejected by the remote
Hello Tom,
On 08/09/18(Sat) 12:07, Tom Murphy wrote:
> On Thu, Sep 06, 2018 at 01:06:50PM -0300, Martin Pieuchot wrote:
> > Tom, as I said previously you've found a race in the ugen(4) driver.
> >
> > That's the symptom:
> >
> > > [...]
> &
On 05/09/18(Wed) 21:32, Tom Murphy wrote:
> Hi Martin,
Tom, as I said previously you've found a race in the ugen(4) driver.
That's the symptom:
> [...]
> usb_detach_wait: ugen1 didn't detach
To be able to understand which race we are chasing, could you rebuild a
kernel with UGEN_DEBU
On 05/09/18(Wed) 09:51, Tom Murphy wrote:
> [...]
> I physically unplug the phone and the kernel starts generating the xhci0:
> timeout aborting transfer messages in a loop.
Aah! So the messages appear *after* you unplugged the device. That
makes sense. Does the diff below help? I just
On 31/08/18(Fri) 09:19, Tom Murphy wrote:
> [...]
> Here's the dmesg from a XHCI_DEBUG kernel before it crashes (it appears
> to loop quite a few times before the kernel protection fault kicks in.)
You're now hitting a bug a ugen(4). Because you're detaching a device
while ugen_do_read() is
On 30/08/18(Thu) 18:15, Tom Murphy wrote:
> On Thu, Aug 30, 2018 at 10:30:04AM -0300, Martin Pieuchot wrote:
> > On 30/08/18(Thu) 14:00, Tom Murphy wrote:
> > > On Wed, Aug 29, 2018 at 10:44:51AM -0300, Martin Pieuchot wrote:
> > > > On 28/08/18(Tue) 22:22, Tom Murph
On 30/08/18(Thu) 14:00, Tom Murphy wrote:
> Hi Martin,
>
> On Wed, Aug 29, 2018 at 10:44:51AM -0300, Martin Pieuchot wrote:
> > On 28/08/18(Tue) 22:22, Tom Murphy wrote:
> > > On Tue, Aug 28, 2018 at 04:20:41PM -0300, Martin Pieuchot wrote:
> > > > Hello Tom,
On 28/08/18(Tue) 22:22, Tom Murphy wrote:
> On Tue, Aug 28, 2018 at 04:20:41PM -0300, Martin Pieuchot wrote:
> > Hello Tom,
> >
> > On 28/08/18(Tue) 11:10, Tom Murphy wrote:
> > > On Tue, Aug 28, 2018 at 02:49:38PM +0900, Bryan Linton wrote:
> > > >
Hello Tom,
On 28/08/18(Tue) 11:10, Tom Murphy wrote:
> On Tue, Aug 28, 2018 at 02:49:38PM +0900, Bryan Linton wrote:
> > On 2018-08-25 21:40:57, Tom Murphy wrote:
> > > On Thu, Aug 23, 2018 at 08:45:54PM +0900, Tom Murphy wrote:
> > > > I've narrowed it down.
> > > >
> > > >Last kernel where
On 20/07/18(Fri) 14:32, Theo de Raadt wrote:
> Martin Pieuchot wrote:
>
> > On 20/07/18(Fri) 03:12, Mike Larkin wrote:
> > > On Wed, Jul 18, 2018 at 11:34:41PM +, Romain wrote:
> > > > > I'm wondering if this is due to the fact that we detach usb(4)
>
On 20/07/18(Fri) 03:12, Mike Larkin wrote:
> On Wed, Jul 18, 2018 at 11:34:41PM +, Romain wrote:
> > > I'm wondering if this is due to the fact that we detach usb(4) devices on
> > > suspend. Looks like this may be trying to process a timeout that
> > > corresponds
> > > to a device that is
On 06/07/18(Fri) 12:49, Alexander Bluhm wrote:
> On Mon, May 07, 2018 at 05:21:19PM +0200, Alexander Bluhm wrote:
> > panic: vinvalbuf: dirty bufs
>
> At least I know what is going on here.
>
> vinvalbuf() calls ffs_fsync() to write all dirty buffers of the
> mount point to disk.
>
>
On 28/06/18(Thu) 14:53, Visa Hankala wrote:
> 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 :
On 16/06/18(Sat) 23:31, multiplexd wrote:
> [...]
> As a supplementary question, is it intended that (non-default) rdomains
> cannot be "deleted" at runtime after they have been created?
Let's say that deletion hasn't been implemented.
On 06/06/18(Wed) 16:21, multiplexd wrote:
> >Synopsis: Assertion failure when adding point-to-point routes to
> >interfaces in rdomain with deleted loopback
> >Category: Reliability
> >Environment:
> System : OpenBSD 6.3
> Details : OpenBSD 6.3 (GENERIC) #3: Thu
On 07/06/18(Thu) 19:22, Philip Guenther wrote:
> On Thu, 7 Jun 2018, Mike Larkin wrote:
> > Is this a panic inside the guest in vmm, or is this the host panicing when
> > you're doing something while a VM is running in vmm on that host?
> >
> > Can't really tell from the trace here...
>
> This
On 28/05/18(Mon) 22:24, Marc Peters wrote:
> Hi List,
>
> i am having issues with OpenBSD 6.3, latest patches as of today applied. We
> are using gif-tunnels between our datacenters, transport encryption and
> OpenBGPD to announce the prefixes between the datacenters. The boxes also
> have
If a process exit(3)s while one of its threads is blocking in accept(2)
and the half-opened descriptor has already been dup'ed, we get the
following panic:
panic: closef: count (1) < 2
Stopped at db_enter+0x5: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*204115
On 17/05/18(Thu) 21:30, Michael-John Turner wrote:
> On Mon, May 14, 2018 at 03:13:12PM +0200, Martin Pieuchot wrote:
> > Could you try the diff below and as soon as you see the message in the
> > dmesg, get the output of 'route -n show -inet6' and send us both?
>
> It's
On 20/05/18(Sun) 21:10, Alexander Bluhm wrote:
> On Sun, May 20, 2018 at 07:24:05AM +0200, p...@centroid.eu wrote:
> > http://centroid.eu/private/p523.jpg
>
> ml_enqueue+0x11
> /usr/src/sys/kern/uipc_mbuf.c:1498
> * 33a1: 48 89 71 08 mov%rsi,0x8(%rcx)
> 33a5:
between the kernel used during install and the
"normal" kernel so I don't know why the normal one has issues.
Thanks,
-Martin
P.S. Since I cannot get the installed kernel to load properly I can
obviously not run dmesg, but here is the output of 'dmesg' as run from
the installer USB ke
On 16/05/18(Wed) 08:06, Harald Dunkel wrote:
> Hi folks,
Thanks for the report.
> hopefully its allowed to repost this message here:
>
> One gateway running 6.3 ran into the debugger last night. Last words:
>
> login: kernel: protection fault trap, code=0
> Stopped at export_sa+0x5c:
After upgrading to the last packaged version of firefox, browsing become
once again unusable. This time the problem seems due to rendering, as
switching back to the "intel" driver made the rendering of the pages
normal again. With the "modesetting" driver it takes multiple seconds
and scrolling
On 13/05/18(Sun) 23:16, Michael-John Turner wrote:
> Hi,
>
> On Thu, May 10, 2018 at 05:13:17PM +0200, Alexander Bluhm wrote:
> > When an IPv6 neigbor discovery timeout occurs, the kernel tries to
> > remove the NDP entry. It is stored in the routing table. The
> > problem is that this NDP
On 13/05/18(Sun) 05:36, Artturi Alm wrote:
> Hi,
>
>
> I was looking at fixing my code for ctf pprinting arrays in ddb(4),
> and came across ctf in section 5 man pages for freebsd with google,
> which lead me to wondering about this, and even think about possibility
> of an bug here, since the
On 08/05/18(Tue) 22:26, Michael-John Turner wrote:
> [...]
> ndp info overwritten for fe80:d::b408:97aa:a658:760e by 40:85:1b:ab:69:d5 on
> vlan41
> ndp info overwritten for fe80:c::b408:97aa:a658:760e by c8:00:44:93:05:62 on
> vlan40
Could you post your routing table so we can understand which
On 09/05/18(Wed) 12:13, Artturi Alm wrote:
> On Wed, May 09, 2018 at 10:23:41AM +0200, Martin Pieuchot wrote:
> > On 09/05/18(Wed) 07:48, Artturi Alm wrote:
> > > On Tue, May 08, 2018 at 01:44:39AM +0300, Artturi Alm wrote:
> >
> >
> > No bug are irrelevant t
On 09/05/18(Wed) 07:48, Artturi Alm wrote:
> On Tue, May 08, 2018 at 01:44:39AM +0300, Artturi Alm wrote:
No bug are irrelevant to fix. But working with you is hard, really
hard. You never explain what the problem is. Reading your email is
an exercise in frustration because you can do some
atch-00_kqueue_fix
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-00_kqueue_fix 11 Apr 2018 14:26:44 -
@@ -0,0 +1,2060 @@
+commit aa39a0557c679fc345b0ba72a87c33152eb8ebcd
+Author: Martin Pieuchot <m...@openbsd.org>
+Date: Tue Feb 20 16:57:00 2018 +
+
+kqueue: Multiple f
On 10/04/18(Tue) 11:57, Mark Kettenis wrote:
> > Date: Tue, 27 Mar 2018 13:40:02 +0200
> > From: Martin Pieuchot <m...@openbsd.org>
> >
> > On 05/02/18(Mon) 18:31, Artturi Alm wrote:
> > > On Mon, Feb 05, 2018 at 02:51:48PM +0100, Martin Pieuchot wrote:
>
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, as i use "sv", an
configuration 1 interface 0 "ASIX Elec. Corp.
> AX88179" rev 3.00/1.00 addr 2
> axen0: AX88179, address xx:xx:xx:xx:xx:xx
> rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 PHY, rev. 5
> uhidev0 at uhub3 port 1 configuration 1 interface 0 "Dell Dell Smart
> Card Reader Key
Since we switched to the modesetting driver by default, the supported
XvImage formats no longer include YUY2 nor UYVY which are expected by
video(1). Using the following Xorg.conf makes video(1) works again.
Section "Device"
Identifier "Device0"
Driver "intel"
EndSection
Attached are the
On 20/03/18(Tue) 20:09, Alexander Bluhm wrote:
> On Tue, Mar 20, 2018 at 02:24:40PM +0100, Martin Pieuchot wrote:
> > So here's a diff to add locking to NFS nodes. I couldn't reproduce the
> > panic above with it. So I'd be interested if you could try it. Note
> > that I
On 20/03/18(Tue) 17:04, Visa Hankala wrote:
> 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 08/03/18(Thu) 23:16, Alexander Bluhm wrote:
> Hi,
>
> When rebooting the NFS client while the NFS file system is actively
> used, the kernel crashes. The socket at 0xd73c2d9c is filled with
> dead beef, so it is a use after free. It is an i386 kernel built
> today.
There are multiple known
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 wrote:
> > > This is a regression that came with the TOCTOU race fix in kern_s
On 19/03/18(Mon) 15:58, Stefan Sperling wrote:
> The following will trigger "panic: rw_enter: netlock locking against myself":
The solution is to call bpfdetach() outside of the NET_LOCK(), it should
not need it. Diff below does that, does it work for you?
Index: net/if.c
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
> [...]
> Now gdb just hangs there and does nothing instead of exiting as
> From mkb Sun Feb 25 14:19:33 2018
> From: mar...@martinbrandenburg.com
> To: bugs@openbsd.org
> Subject: intermittent sluggish behavior; seems to be acpi related
>
> >Synopsis:intermittent sluggish behavior; seems to be acpi related
> >Category:amd64
> >Environment:
> System :
On 26/02/18(Mon) 15:20, C. wrote:
> Category:
> Webcam / Video
>
> Environment:
> System : OpenBSD 6.2
> Details : OpenBSD 6.2 (GENERIC.MP) #5: Fri Feb 2 23:02:19 CET
> 2018
>
>
>Synopsis: intermittent sluggish behavior; seems to be acpi related
>Category: amd64
>Environment:
System : OpenBSD 6.2
Details : OpenBSD 6.2-current (GENERIC.MP) #10: Wed Feb 21 21:26:27
MST 2018
On 29/01/18(Mon) 21:25, Artturi Alm wrote:
> On Mon, Jan 29, 2018 at 08:03:38PM +0100, Martin Pieuchot wrote:
> > On 29/01/18(Mon) 20:38, Artturi Alm wrote:
> > > On Mon, Jan 29, 2018 at 10:42:20AM +0100, Martin Pieuchot wrote:
> > > > Hello Artturi,
> >
On 11/02/18(Sun) 12:37, Matthieu Herrb wrote:
> Hi,
>
> I ugraded my laptop from sources to -current yesterday. Since then
> firefox stops resolving host names after a dozen of minutes or so.
What do you mean with "stops resolving host names"? What happens? What
do you see?
How did figure out
On 04/02/18(Sun) 11:28, Artturi Alm wrote:
> Hi,
>
> machdep.forceukbd=1 feels broken to me, as i use "sv", and it doesn't respect
> /etc/kbdtype.
If you unplug/replug your USB keyboard after having booted does it
respect /etc/kbdtype?
On 29/01/18(Mon) 20:40, Remi Locherer wrote:
> On Mon, Jan 29, 2018 at 07:33:47PM +0100, Remi Locherer wrote:
> > > Problem Description
> > Local originating traffic leaves the system on the wrong interface
> > after a more specific route was added. This is problematic for services
> > like
On 29/01/18(Mon) 20:38, Artturi Alm wrote:
> On Mon, Jan 29, 2018 at 10:42:20AM +0100, Martin Pieuchot wrote:
> > Hello Artturi,
> >
> > On 28/01/18(Sun) 09:08, Artturi Alm wrote:
> > > >Synopsis:stuck in netlock
> > > >Category:
Hello Artturi,
On 28/01/18(Sun) 09:08, Artturi Alm wrote:
> >Synopsis:stuck in netlock
> >Category:amd64
> >Environment:
> System : OpenBSD 6.2
> Details : OpenBSD 6.2-current (GENERIC.MP) #333: Sun Jan 7
> 09:13:00 MST 2018
>
>
On 28/01/18(Sun) 19:38, Denis wrote:
> Catch the second one kernel panic.
>
> The output is the same, but on another kernel. Hope this helps.
Sadly it doesn't. It only creates frustration from both sides. Please
see https://www.openbsd.org/report.html .
Hello Denis,
On 27/01/18(Sat) 12:38, Denis wrote:
> Hello Martin,
>
> Thank you for your attention to the problem with run driver.
>
> Here is DDB output.
Sorry but can you give more context? How does this happen, why do
you need to do? What is the output of 'ps', what is yo
we
can't tell what is the first (real) problem.
And please stop cross posting. bugs@ is enough for such problems :)
Thanks,
Martin
When sending SIGTSTP to a multi-threaded process, it can ends up hanging
forever. Here's an example, courtesy of espie@:
$ mpv madalena.mp3
After pressing 'Ctrl+z' here's how the process state looks like:
PID TID PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
8461
Hello Hrvoje,
On 23/01/18(Tue) 14:33, Hrvoje Popovski wrote:
> [...]
> uvm_fault(0x81b23f30, 0xb8, 0, 1) -> e
This is the offset of `if_carp'.
Since you're destroying vlans, which are the parent of your carps, we
can assume
For testing purposes I have two identical VMs except that one is i386
and the other amd64. They share the same tap(4) interface, so they
cannot run at the same time:
$ vmctl status
ID PID VCPUS MAXMEM CURMEM TTYOWNER NAME
1 35130 1128M102M ttyp6
I'm running an OpenBSD amd64 guest into an amd64 host. Dmesgs
attached. The VM config is as follow:
vm "qemu" {
memory 128M
disk "/usr/hack/mpi/qemu/amd64/disk.img"
local interface tap0 lladdr 70:5f:ca:21:8d:70
disable
owner mpi
}
I run dhclient(8) and
On 18/12/17(Mon) 05:53, Jason Tubnor wrote:
> On 14 December 2017 at 22:44, Martin Pieuchot <m...@openbsd.org> wrote:
>
> >
> > Here's a diff that should fix the problem, do you confirm?
> >
> > Index: net/if_vxlan.c
> > =
On 09/01/18(Tue) 11:40, Christian Ruesch wrote:
> After today's upgrade to OpenBSD -current for amd64, the server can no longer
> boot and ends up in a kernel panic.
>
> If you need any further information, please let me know and I will try to get
> it.
Which snapshot were you using
On 03/01/18(Wed) 10:36, Martin Pieuchot wrote:
> On 02/01/18(Tue) 12:48, Ted Unangst wrote:
> > Martin Pieuchot wrote:
> > > on -current amd64, simply doing "$ ktrace -p $pid_of_firefox" is enough
> > > to freeze my box:
> >
> > ktrace of ch
On 02/01/18(Tue) 12:48, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > on -current amd64, simply doing "$ ktrace -p $pid_of_firefox" is enough
> > to freeze my box:
>
> ktrace of chrome would do that going back at least six months.
And nobody reported the bug! Now it's harder to track it down :/
On 02/01/18(Tue) 17:14, Martin Pieuchot wrote:
> on -current amd64, simply doing "$ ktrace -p $pid_of_firefox" is enough
> to freeze my box:
Same problem with chromium. It seems that a CPU is never giving the
KERNEL_LOCK() back. It always happen when executing one of the browser
on -current amd64, simply doing "$ ktrace -p $pid_of_firefox" is enough
to freeze my box:
OpenBSD 6.2-current (GENERIC.MP) #313: Mon Jan 1 17:51:21 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8238301184 (7856MB)
avail mem = 7981707264 (7611MB)
Hello Jason,
On 29/11/17(Wed) 12:13, Jason Tubnor wrote:
> On 28 November 2017 at 20:33, Martin Pieuchot <m...@openbsd.org> wrote:
> > Could you do:
> >
> > # sysctl kern.splassert=2
> >
> > And report the tracebacks?
> >
>
> Hi Martin,
>
On 14/12/17(Thu) 12:03, Peter Hessler wrote:
> This is the normal arm64 "pmap bug" panic.
Thanks Peter, the diff below should fix the two problems present in your
trace:
> ddb> show panic
> uvm_fault failed: ff80002619b4
I love that arm64 is doing the right thing and call panic(9) for UVM
>Synopsis: inteldrm crashes on braswell under heavy usage
>Category: ???
>Environment:
System : OpenBSD 6.2
Details : OpenBSD 6.2-current (GENERIC.MP) #4: Fri Nov 24 12:24:51
CET 2017
d ID) of the process.
Same thing for the em(4) panic you reported before. I made an educated
guess about which race can occur. But having the trace of all active
processes help a lot!
Thanks for you great reports,
Martin
On 29/11/17(Wed) 18:25, Hrvoje Popovski wrote:
> hi all,
>
> sending ip6 traffic from host connected to vlan200 on ix0 to host
> connected to vlan300 on ix1 and running
>
> ifconfig vlan200 destroy
> ifconfig ix0 down
> sh netstart vlan200
> sh netstart ix0
> ifconfing vlan300 destroy
> ifconfig
On 29/11/17(Wed) 12:13, Jason Tubnor wrote:
> On 28 November 2017 at 20:33, Martin Pieuchot <m...@openbsd.org> wrote:
>
> >
> > Could you do:
> >
> > # sysctl kern.splassert=2
> >
> > And report the tracebacks?
> >
>
> Hi Martin,
&
On 07/12/17(Thu) 08:34, Landry Breuil wrote:
> Hi,
>
> i've been having kvm VMs running 6.2 hardlocking/deadlocking since a
> while, all those running on proxmox 5.1 using linux 4.13.8 & qemu-kvm
> 2.9.1. There were hardlocks upon reboot which were 'solved' by disabling
> x2apic emulation in kvm
Hello Jason,
Could you do:
# sysctl kern.splassert=2
And report the tracebacks?
On 28/11/17(Tue) 10:49, Jason Tubnor wrote:
> >Synopsis: kernel/driver for vxlan(4) pf(4) queue issue 6.2 and above
> >Category: base/network
> >Environment:
> System : OpenBSD 6.2
>
>Synopsis: inteldrm crashes on braswell under heavy usage
>Category: ???
>Environment:
System : OpenBSD 6.2
Details : OpenBSD 6.2-current (GENERIC.MP) #4: Fri Nov 24 12:24:51
CET 2017
Hello Hrvoje,
On 09/11/17(Thu) 01:11, Hrvoje Popovski wrote:
> while sending ip6 packets from host connected to vlan200 to host
> connected vlan300 and then destroying vlan300 i'm getting kernel page
> fault. it's clean snapshot from 2017-11-08. it's easily reproducible
You found a nice race.
>
201 - 300 of 550 matches
Mail list logo
