On Sat, Feb 24, 2018 at 04:20:50PM -0500, Johan Huldtgren wrote:
> trying to connect to my gateway today I found the following
> panic. This is 100% reproducible anytime I connect via
> openvpn and then generate traffic. This first happened on
> the Feb 7th snap, I updated and it happens on the lat
Hi,
When executing the libc ieeefp/except regression test, the i386 kernel
panics.
root@ot2:/usr/src/regress/lib/libc/ieeefp/except# make
cc -O2 -pipe -MD -MP -c /usr/src/regress/lib/libc/ieeefp/except/except.c
cc -o except except.o
./except fltdiv
panic: kernel diagnostic assertion "_kern
On Tue, Feb 27, 2018 at 11:15:22AM -0300, Johan Huldtgren wrote:
> Patch does not change anything, it panics as soon as I've connected and
> I try to ping something on the inside. I couldn't find any logging for
> this, I assume it would be in messages or daemon?
When it crashes, there is no log.
On Fri, Mar 02, 2018 at 02:25:21PM +0100, Pierre Emeriaud wrote:
> panic: netlock: lock not held
> ifpromisc(800021f85400,805ae000) at ifpromisc+0xb3
> bpfioctl(ff027eb5fc18,ff027eb5fc18,ff02414ac4a0,20004269,ff02414ac4a0)
> at bpfioctl+0x53c
I would say this is a mis
Do we want this syslogd feature that it only removes files it created
at startup?
On Sat, Feb 10, 2018 at 12:28:31AM +0100, Alexander Bluhm wrote:
> The file removal is part of a regression introduced by moving to
> fork+exec. Before only files that were actually open were removed.
>
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.
bluhm
root@ot2:.../~# find /mount >/dev/null & sleep 5; reboot -q
[1] 9698
syncing d
Hi,
Since Mar 17 snapshot all relayd TLS regression tests fail. The
relayd child processes crash at startup in BIO_new_file().
bluhm
Core was generated by `relayd'.
Program terminated with signal SIGABRT, Aborted.
#0 _thread_sys_open () at -:3
3 -: No such file or directory.
#0 _thread
On Mon, Mar 19, 2018 at 12:54:01PM -0600, Theo de Raadt wrote:
> Look in dmesg. This is probably pledge.
Yes. relayd[20400]: pledge "rpath", syscall 5
> PLease test with new library also.
Bug has been fixed. All tests pass now.
bluhm
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 didn't do much tests in write mode, so I'd suggest exporting your
> "/mount" as
On Thu, Mar 22, 2018 at 12:07:14AM -0500, Emilio Perea wrote:
> Patch provided by Hans-Joerg Hoexer fixed the problem. Thanks!
All fixes have been commited to i386 OpenBSD -current and are
available as snapshot. Please report again if there is still
anything wrong.
bluhm
On Thu, Apr 05, 2018 at 11:41:51AM +0200, Patrick Wildt wrote:
> I have seen that issue as well. I think it's because we are now
> being passed the data and we don't have to do the copyin ourselves.
> When the conversion happened, someone forgot to remove the copyin.
>
> Does this help?
OK bluhm
On Sun, Apr 08, 2018 at 07:10:27AM +0200, Sebastien Marie wrote:
> I think it is the more simple way to achieve it. Moving the related code
> from unp_connect() to unp_connect2() should be possible (only few direct
> callers of {so,unp_}connect2() ), but unp_connid will not be copied on
> the two s
Hi,
my i386 regression test machine crashed with the Tue Apr 17 snapshot
in radeondrm_attachhook().
uvm_fault(0xd0ccfb70, 0xd11e, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at pmap_page_remove_pae+0x18: cmpl$0,0x48(%edi)
pmap_page_remove_pae(d11e0800) at pmap_page_remov
On Wed, Apr 18, 2018 at 08:30:16PM +1000, Jonathan Gray wrote:
> On Wed, Apr 18, 2018 at 11:40:06AM +0200, Alexander Bluhm wrote:
> > my i386 regression test machine crashed with the Tue Apr 17 snapshot
> > in radeondrm_attachhook().
>
> So the machine doesn't
On Wed, Apr 18, 2018 at 10:29:30PM +1000, Jonathan Gray wrote:
> sys/dev/pci/drm/drm_linux.h rev 1.85 should help
I have compiled and successfully booted a kernel with that commit.
bluhm
On Thu, Apr 19, 2018 at 12:10:04AM +1000, Jonathan Gray wrote:
> That's with the big radeon update diff as well?
That was current. Boots fine.
With ~jsg/radeon.diff.2 it still crashes. I have checked, it is
the diff with
if (rdev->rio_mem_size > 0)
bus_space_unmap(rdev-
On Tue, Apr 24, 2018 at 08:18:42PM +1000, Jonathan Gray wrote:
> 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 you confirm
> that it works for you as well?
With this diff my machine boots fine. No monitor connect,
Hi,
I have seen a crash in the regress/sys/nfs test. It was during
run-regress-cleanup, the last command I see is:
umount -f -t nfs -h 127.0.0.1 -a || true
uvm_fault(0xd0d2f2a8, 0xefff, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at nfs_timer+0x30: cmpl$0,0xc(%ebx)
ddb{0}>
Hi,
My amd64 regress machine paniced two times here.
panic: vinvalbuf: dirty bufs
Stopped at db_enter+0x5: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
*518352 74317 0 0x2 00K umount
ddb{0}> trace
db_enter() at db_enter+0x5
panic() at
Hi,
While running my nightly regression tests, I compiled
/ports/misc/posixtestsuite. It was the first time that I was running
regress while having some other load on the machine. During
regress/lib/libc/ieeefp/except the machine hang. It has 2 CPUs.
The final output of the test:
===> ieeefp/
On Wed, May 09, 2018 at 06:21:54PM +0200, Hans-Joerg Hoexer wrote:
> Hi,
>
> I think this fallout from using interrupt gates now. I did not properly
> enable interrupts for dna, fpu and f00f_redirect: Thux npxintr() tries to
> get the kernel lock with interrupts disabled. Meanwhile the IPI for
On Tue, May 08, 2018 at 10:26:02PM +0100, Michael-John Turner wrote:
> panic: kernel diagnostic assertion "!ISSET(rt->rt_flags, RTF_LOCAL)" failed:
> file "/usr/src/sys/netinet6/nd6.c", line 725
I have added this diagnostic assertion during 6.3 developemnt.
When an IPv6 neigbor discovery timeout
Hi,
When executing the posixtestsuite port, the i386 kernel crashes.
It is this one:
/usr/local/libexec/posixtestsuite/conformance/interfaces/mmap/31-1.test
bluhm
root@ot1:.../~# te/conformance/interfaces/mmap/31-1.test <
off: f000, lpanic: kernel diagnostic assertion "
On Mon, May 14, 2018 at 01:05:07PM +0200, Otto Moerbeek wrote:
> This fixes the panic.
All i386 regress tests pass with this.
http://bluhm.genua.de/regress/results/latest.html
> The error returned is not expected by the test
> suite (ENOMEM vs EOVERFLOW), but that's another matter imo.
Currentl
On Wed, May 16, 2018 at 10:20:49AM +0200, Martin Pieuchot wrote:
> That means that the TDB has already been freed. This is possible
> because the timeout sleeps on the NET_LOCK(). Diff below should prevent
> that by introducing a tdb_reaper() function like we do in other parts of
> the stack.
>
On Sat, May 19, 2018 at 12:57:19PM +0200, Peter J. Philipp wrote:
> panic: kernel diagnostic assertion...(cut)
This is an important line.
panic: kernel diagnostic assertion "_kernel_lock_held()" failed in file "/us
Then the photo is cut, but I can guess what is next.
> soassertlocked(815c
On Sat, May 19, 2018 at 02:08:55PM +0200, Peter J. Philipp wrote:
> > panic: kernel diagnostic assertion "_kernel_lock_held()" failed in file "/us
It is /usr/src/sys/kern/uipc_socket2.c, line 314
302 void
303 soassertlocked(struct socket *so)
304 {
305 switch (so->so_proto
On Sat, May 19, 2018 at 02:30:27PM +0200, Peter J. Philipp wrote:
> I have applied it now, what it was
> missing was a terminating semicolon on KERNEL_LOCK(), so far my C goes I was
> able to correct that.
Ah, I tested a GENERIC non MP kernel in qemu. There the define is
a noop and the compiler i
On Sat, May 19, 2018 at 08:45:01AM -0400, mabi wrote:
> If that might help you guys, this seems quite similar to the issue I have
> encountered and reported on this mailing list back in April:
> https://marc.info/?l=openbsd-bugs&m=152417193124446&w=2
This is unrelated, the expire bug was introduc
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: eb 07 jmp33ae
1492 void
14
On Tue, May 22, 2018 at 07:32:29AM +0200, Harald Dunkel wrote:
> Do you think this is worth a syspatch?
You are asking this question for three times. The answer is no.
Errata and syspatch are for security issues that can be triggered
remotely or by a local non-root user. If we would fix every p
On Mon, May 28, 2018 at 10:24:33PM +0200, Marc Peters wrote:
> ddb{0}> bt
> export_sa(10,80002240c0b0) at export_sa+0x5c
> pfkeyv2_expire(8095c400,8095c400) at pfkeyv2_expire+0x14e
> tdb_timeout(80002240c260) at tdb_timeout+0x39
> softcl
Hi,
On my amd64 regress machine I see a witness_warn panic now.
OpenBSD 6.3-current (GENERIC.MP) #65: Fri Jun 1 17:44:06 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
acquiring duplicate lock of same type: "&mp->mnt_lock"
1st vfslock @ /usr/src/sys/kern/vfs_
On Mon, Jun 04, 2018 at 01:23:53AM +0200, Alexander Bluhm wrote:
> On my amd64 regress machine I see a witness_warn panic now.
It is triggered by /usr/src/regress/sys/kern/mount. With visa@'s
improved stack trace I see:
run-regress-unmount-busy
cp -r /usr /mnt/regre
On Mon, Jun 04, 2018 at 08:30:55PM +0200, Alexander Bluhm wrote:
> On Mon, Jun 04, 2018 at 01:23:53AM +0200, Alexander Bluhm wrote:
> > On my amd64 regress machine I see a witness_warn panic now.
>
> It is triggered by /usr/src/regress/sys/kern/mount. With visa@'s
> imp
On Mon, Jun 04, 2018 at 08:53:49PM +0200, Alexander Bluhm wrote:
> userret: returning with the following locks held:
> exclusive rrwlock inode r = 0 (0xff023d492b48) locked @
> /usr/src/sys/ufs/uf
> s/ufs_vnops.c:1559
> #0 witness_lock+0x254
> #1 _rw_enter+0x29b
> #2
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.
if ((error = VOP_FSYNC(vp, cred, MNT_WAIT, p)) !
On Wed, Jul 18, 2018 at 08:39:17PM +0200, Eivind Eide wrote:
> Over several snapshots after 6.3 I get reliable system crash after a
> few minutes uptime on this old i386 machine of mine.
It would be helpful to know when this started. Does it happen with
6.3? Since 6.3 we have commited i386 Meltd
On Wed, Jul 18, 2018 at 07:13:15AM +, Daniel Stocker wrote:
> ddb{0}> trace
> export_sa(10,800022368520) at export_sa+0x5c
> pfkeyv2_expire(81409800,81409800) at pfkeyv2_expire+0x14e
> tdb_timeout(8000223686d0) at tdb_timeout+0x39
> softclock_thread(0) at softclock_threa
On Fri, Jul 20, 2018 at 05:22:20PM +0100, Stuart Henderson wrote:
> For bluhm and bugs@ readers, Eivind narrowed it down to between these:
>
> OpenBSD 6.3-current (GENERIC) #567: Sun Apr 22 08:12:07 MDT 2018
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>
> OpenBSD 6.3-cur
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 M7" is broken with the new drm
code. Unfortunately I have no experience with
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_meltdown+0x7b
> fill_file(80ca8000,fd811c6a23d0,fd81012516f8,
On Wed, Dec 09, 2020 at 04:55:09PM -0300, K R wrote:
> pflog0 logs incorrect timestamp on i386. The machine in question is
> running under QEMU:
Works for me on a i386 xeon machine.
> hw.vendor=QEMU
hw.machine=i386
hw.model=Intel(R) Xeon(TM) CPU 3.06GHz ("GenuineIntel" 686-class)
hw.ncpu=4
hw.v
On Thu, Dec 10, 2020 at 10:22:40AM -0300, Martin Pieuchot wrote:
> This code path is executed w/o KERNEL_LOCK(), could you try the diff
> below and try hard to reproduce the crash?
With this diff it took me about 1.5 hours to reproduce.
root@ot6:.../malloc_duel# while make regress; do date; done
On Fri, Dec 11, 2020 at 03:14:52PM -0500, Johan Huldtgren wrote:
> init: single user shell terminated, restarting
> init: single user shell terminated, restarting
The problem is that libc setjmp tries to save the MXCSR register.
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 58
On Sun, Dec 13, 2020 at 06:59:18PM -0300, K R wrote:
> Just found a bare metal i386 P4 machine with the same problem:
Interresting. Also works with my Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
root@ot1:.../~# tcpdump -c 1 -nl -tt -i pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: li
On Mon, Dec 14, 2020 at 07:10:20PM -0300, K R wrote:
> On Sun, Dec 13, 2020 at 7:33 PM Alexander Bluhm
> wrote:
> > I use -current. Yours is a 6.8-stable if I recall correctly.
> > Can you try -current snapshot?
>
> It worked! Just tried -current on both machines, b
On Thu, Dec 10, 2020 at 11:20:58PM +0100, Alexander Bluhm wrote:
> root@ot6:.../malloc_duel# while make regress; do date; done
> ./malloc_duel
> Thu Dec 10 21:45:42 CET 2020
> ...
> Thu Dec 10 23:10:01 CET 2020
> ./malloc_duel
>
> Often it happens faster, but this time fr
Hi,
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:
http://bluhm.genua.de/perform/results/2021-01-05T15%3A48%3A19Z/perform.html
It is
On Mon, Jan 04, 2021 at 08:11:53PM +0100, Alexander Bluhm wrote:
> On my old Opteron I forced to activate the meltdown protection with
> this diff. With that malloc_duel is running for more than a day.
> Usually it crashes after minutes.
On non-meldtdown CPU, swapping the U+K Page-Table
On Wed, Jan 27, 2021 at 07:11:49AM +0100, alf wrote:
> initializing kernel modesetting (RV100 0x1002:0x515E 0x103C:0x31FB 0x02).
> NMI ... going to debugger
> Stopped at tsc_delay+0x63: lfence
I have a machine that also has this problem since upgrade to OpenBSD 6.8.
initializing kernel modes
On Wed, Feb 05, 2020 at 05:52:00PM +, Peter M??ller wrote:
> after experimenting with different MTU sizes and pf normalisation rules,
> I am getting the feeling of a root cause lying somewhere near path MTU
> discovery - perhaps in combination with IPsec.
A coworker ran into the same trace wit
On Fri, Feb 05, 2021 at 02:01:31AM +0100, Alexander Bluhm wrote:
> I have created an automated test from his setup.
I have commited a regress test that automatically builds the affected
setup. In case someone wants to play with it, run
make -C /usr/src/regress/sys/net/pair clean run-tcpbenc
Hi,
My arm64 regress machines do an install every Saturday. The other
days of the week it is only an upgrade. Installing these machines
broke between January 30 and February 6.
http://bluhm.genua.de/regress/results/2021-02-06T16%3A17%3A03Z/setup-ot10.log
After install it cannot boot the kernel
On Thu, Feb 25, 2021 at 10:07:32AM +0100, stef...@fritz.wtf wrote:
> >Description:
> After patching my system with syspatch to 6.8-014 no connections to the
> server where possible, no ssh, no smtp, https, imap. Disabling pf allowed
> connections.
I don't see how the errata diff can crea
On Thu, Feb 25, 2021 at 05:00:20PM +0100, Steffen Fritz wrote:
> So, layer 8 problem? Don't think so, but I cannot reproduce it and it
> works now.
I don't know. tobhe@ saw simmilar problems yesterday evening. But
there GENERIC was accidently replaced with GENERIC.MP when errata
was applied. An
On Thu, Feb 25, 2021 at 06:46:05PM +0100, Alexander Bluhm wrote:
> tobhe@ saw simmilar problems yesterday evening. But
> there GENERIC was accidently replaced with GENERIC.MP when errata
> was applied.
My problem is definitely unrelated to the errata patch. It happend
again, the clock
On Thu, Nov 07, 2019 at 11:08:38AM +0100, igor kos wrote:
> If I started isakmpd on OBSD 6.6:
>
> test66/etc/isakmpd>isakmpd -4 -K -T -d
> 154833.658332 Default isakmpd: starting [priv]
> 154833.660031 Default conf_reinit: open("/etc/isakmpd/isakmpd.conf",
> O_RDONLY, 0) failed: Permission denied
>
On Wed, Oct 30, 2019 at 05:56:38PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> So I did poke around and it looks like tcp_notify() requires a small tweak. I
> did check NetBSD and it looks like NetBSD is suffering from the same glitch
> (unless I'm missing something).
>
> The change below makes
On Thu, Nov 07, 2019 at 03:56:12PM +0100, Alexander Bluhm wrote:
> On Thu, Nov 07, 2019 at 11:08:38AM +0100, igor kos wrote:
> > If I started isakmpd on OBSD 6.6:
> >
> > test66/etc/isakmpd>isakmpd -4 -K -T -d
> > 154833.658332 Default isakmpd: starting [priv]
> &g
On Sun, Nov 17, 2019 at 02:17:14PM +, Stuart Henderson wrote:
> On 2019/11/17 14:44, Sebastien Marie wrote:
> > I am unsure if the problem is kernel related or in dhcpcd ...
>
> I think this should do the trick (not tested yet). I wonder how many
> more of these are in ports.
Our kernel had we
On Mon, Nov 18, 2019 at 08:42:30AM +0100, Claudio Jeker wrote:
> On Sun, Nov 17, 2019 at 02:03:21PM -0700, Todd C. Miller wrote:
> > On Sun, 17 Nov 2019 20:38:59 +0100, Alexander Bluhm wrote:
> >
> > > I think the best way to handle it, is to make the kernel strict and
>
On Sat, Nov 30, 2019 at 01:42:38PM +0100, Jeremie Courreges-Anglas wrote:
>
> Similar to the recent "dhcpcd: if_learnaddrs: if_addrflags6: Invalid
> argument" thread[0]. At least ports/net/openvpn is affected, as
> reported by Landry*. kdump looks like:
>
> 88944 openvpn CALL ioctl(4,SIOCGIFN
On Wed, Dec 11, 2019 at 08:23:02AM +, Ulrich Nanz wrote:
> System : OpenBSD 6.6
> Details : OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> isakmpd does no
On Fri, Dec 20, 2019 at 10:33:02PM -0700, Bobby Johnson wrote:
> I've tried to see if I could change the entry point by altering delta
> in sys/arch/amd64/stand/efiboot/exec_i386.c. But even with a small
> change my test vm won't boot with it.
For changing the entry point, you have to fix the del
On Fri, Dec 20, 2019 at 10:33:02PM -0700, Bobby Johnson wrote:
> Any clues how I could test further?
The laptop I had hang after printing the enry point. To debug
I moved a reset function around to find the final line that is
executed before the hang.
#include
void
cpu_reset(void)
{
out
On Sat, Jan 11, 2020 at 09:43:15PM +, Marcos Madeira | Secure Networks
wrote:
> cpu0: QEMU Virtual CPU version 2.5+, 3602.34 MHz, 06-06-03
There is a bug in QEMU cpu emulation. It interpretes some SSE
instruction in the pfctl binary incorrectly. If I remeber correctly
this happnes in set_ip
On Fri, Jan 31, 2020 at 03:21:00PM +, Peter M??ller wrote:
> tcp_output(80584ee0) at tcp_output+0x1941
> tcp_output(80584ee0) at tcp_output+0x1941
> tcp_output(80584ee0) at tcp_output+0x1941
Looks like stack exhaustion. tcp_output() calls tcp_mtudisc(
On Sun, Mar 08, 2020 at 10:15:08AM -0600, Todd C. Miller wrote:
> On Sat, 07 Mar 2020 19:35:10 -0700, Bob Beck wrote:
>
> > makes sense to me and has my ok. could we see if bluhm@ can be sure this
> > still works with his workload?
>
> Thanks, waiting to see if bluhm@ can confirm this doesn't ca
On Fri, Jun 24, 2016 at 07:16:27AM -0400, RD Thrush wrote:
> OpenBSD 6.0-beta (RAMDISK_CD) #1996: Thu Jun 23 07:29:40 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory
amd64 snapshot with this kernel was broken
Hi,
When running some scapy regression tests, a current i386 machine
triggered this panic.
bluhm
panic: kernel diagnostic assertion "bpfilter_lookup(unit) == NULL" failed: file
"../../../../net/bpf.c", line 1645
Stopped at Debugger+0x7: leave
TIDPIDUID PRFLAGS PFLAGS
On Fri, Sep 02, 2016 at 09:43:13AM +0200, Andreas Bartelt wrote:
> I'm observing very slow ssh / sshd performance on current (tested on amd64).
> Throughput is less than 1/50th of what I'm typically seeing on my boxes.
> This drop in performance seems to be independent of the used ciphers (tested
>
On Fri, Sep 02, 2016 at 10:33:19AM +0200, Andreas Bartelt wrote:
> On 09/02/16 10:24, Alexander Bluhm wrote:
> > I see a performance drop to 10 Mbit/sec on some old i386 machines
> > with em(4). Can you try this kernel diff to see wether it is the
> > same problem?
> &
On Wed, Sep 28, 2016 at 12:09:35PM +0200, Paul de Weerd wrote:
> I ran into this issue while manually configuring a set of aliases on
I can reproduce it on -current:
while ifconfig vio0 inet delete; do :; done
while ifconfig vio1 inet delete; do :; done
netstat -rn -f inet
DestinationGat
On Mon, Oct 03, 2016 at 12:23:08PM +0200, Martin Pieuchot wrote:
> Index: netinet/in.c
> ===
> RCS file: /cvs/src/sys/netinet/in.c,v
> retrieving revision 1.129
> diff -u -p -r1.129 in.c
> --- netinet/in.c 4 Sep 2016 10:32:01 -000
On Thu, Oct 06, 2016 at 11:12:18PM +0200, Christian Weisgerber wrote:
> Something is very broken at the intersection of IPv6, NDP, and IPsec
> in -current.
I also see issues with IPv6 and NDP, but no IPsec involved. There
are several other threads on bugs@ about broken IPv6.
It seems that sendin
On Mon, Oct 24, 2016 at 02:06:43PM +, Florian Obser wrote:
> Note that we can remove all the checks since in6_pcbaddrisavail() does
> all of this for us.
I support using in6_pcbaddrisavail() for raw sockets. Code reuse
is good.
> - if (ifa && ifatoia6(ifa)->ia6_flags &
> -
On Tue, Nov 15, 2016 at 04:33:13PM +, Rivo Nurges wrote:
> PF allows to filter based on route labels. Cloned routes created by PMTU
> don't inherit route labels and PF filtering fails.
We inherit the label for cloned routes, it makes sense to inherit
it also for dynamic routes.
> This patch
On Mon, Nov 21, 2016 at 03:15:39PM +0100, Martin Pieuchot wrote:
> naddy@ confirmed this diff fixes his tunnel mode setup, ok?
IPv6 neighbor discovery over IPsec does not work reliably. It uses
link-local, global and multicast addresses and depending on your
flows and SA it either works or not.
On Mon, Jan 02, 2017 at 09:53:14AM +0100, Martin Pieuchot wrote:
> This is still an issue, multiple diffs are floating around, could we
> commit a fix?
The only real bug is the length check. Unfortunaltely it will not
fix naddy's setup. I noone objects, I will commit this as it makes
the behavio
On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> kernel: protection fault trap, code=0
> Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> ax)
> ddb{3}> fd_getfile() at fd_getfile+0x20
> sys_fstat() at sys_fstat+0x43
> syscall() at syscall+0x27b
It crashes in f
On Wed, Dec 23, 2015 at 05:27:58PM +0100, Stefan Kempf wrote:
> Same panic here, but with a different trace (see below).
> It looks like the pf_state_key reference count is not always
> updated. When the packet header of an mbuf is duplicated, the
> reference count is not being increased. But freei
On Tue, Feb 09, 2016 at 11:03:59AM +0100, Martin Pieuchot wrote:
> Since brightness support has been added to acpithinkpad(4) I can easily
> trigger a regression on my x220:
>
> - Switching to the first virtual console just after xdm starts using the
> Ctrl+Alt+F1 key combination turns my screen
On Thu, Mar 24, 2016 at 05:21:00PM +0100, Frederic URBAN wrote:
> panic: kernel diagnostic assertion "sotoinpcb(inp->inp_socket) == inp"
> failed: file "../../../../netinet/tcp_input.c", line 632
> Stopped at? ? ? ? ? Debugger+0x9:? ? leave
> ? ? TID? ? ? PID? ? ? UID? ? ? ? PRFLAGS? ? ? ? P
On Tue, Mar 29, 2016 at 11:46:20AM +0100, Stuart Henderson wrote:
> On 2016/03/24 20:27, Sebastien Marie wrote:
> > Hi,
> >
> > I encountered a problem with IPv6 connectivity after upgrade to snapshot
> > Mar 23 on my amd64 router.
> >
> > The router use a pppoe session to get IPv4 and IPv6. I ha
On Wed, Mar 30, 2016 at 09:17:52PM +0200, Vincent Gross wrote:
> Hi, can you apply this diff and check if the problem persists ?
It does not help my syslogd regression test.
cd /usr/src/regress/usr.sbin/syslogd && SUDO=sudo make
run-regress-args-server-udp6.pl
I have also tried memset(&valid, 0
On Thu, Mar 31, 2016 at 10:42:19AM +0200, Sebastien Marie wrote:
> On Wed, Mar 30, 2016 at 09:17:52PM +0200, Vincent Gross wrote:
> >
> > Hi, can you apply this diff and check if the problem persists ?
> >
> > diff --git a/sys/netinet6/udp6_output.c b/sys/netinet6/udp6_output.c
> > index f9473d8.
On Fri, May 13, 2016 at 11:43:43AM +0100, Dimitris Papastamos wrote:
> After I rebuilt and booted the kernel today I noticed dmesg -s
> produces no output. I suspect this is to do with the recent change:
Here is alternative way to fix sendsyslog(2) with LOG_CONS. I also
works when /dev/console i
On Thu, Dec 03, 2015 at 03:09:37PM +, Sevan / Venture37 wrote:
> panic: no HDR: pppxwrite
Please try this (untested)
bluhm
Index: net/if_pppx.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_pppx.c,v
retrieving revision 1
On Thu, Dec 03, 2015 at 04:14:08PM +, Sevan / Venture37 wrote:
>
>
> On 03/12/2015 16:08, Mike Belopuhov wrote:
> > this looks correct.
>
> I applied Alexander's patch on top of yours.
> Still crashed.
That's because Mike's patch got the same bug by copy@pase.
So we could see what is going
On Thu, Dec 03, 2015 at 04:40:07PM +, Sevan / Venture37 wrote:
> Confirmed, with the amended you suggested, OpenBSD no longer panics when
> I establish a connection.
I have commited the fix. Thanks for testing.
bluhm
On Fri, Dec 11, 2015 at 12:37:40AM +0100, Einfach Jemand wrote:
> Below is a patch against the -current version of syslogd.c that makes
> syslogd -m functional again.
Thanks for the fix, I have commited it.
> I ran the regression tests for syslogd with the patch and found no
> differences so fa
On Wed, May 31, 2017 at 10:11:45AM +0200, oanto...@ethnao.no-ip.biz wrote:
> s = socket(res->ai_family,
> res->ai_socktype,res->ai_protocol);
> if (s == -1)
> errx(1,"socket");
> int enable = 1;
>
On Wed, Aug 30, 2017 at 09:20:40PM +1000, Jonathan Gray wrote:
> @@ -680,8 +680,9 @@ config_getproto(struct relayd *env, stru
> s = sizeof(*proto);
>
> styl = IMSG_DATA_SIZE(imsg) - s;
> + proto->style = NULL;
> if (styl > 0) {
I think this chunk is the important part of th
On Mon, Sep 04, 2017 at 11:38:03PM +1000, Jonathan Gray wrote:
> On Mon, Sep 04, 2017 at 02:39:17PM +0200, Alexander Bluhm wrote:
> > On Wed, Aug 30, 2017 at 09:20:40PM +1000, Jonathan Gray wrote:
> > > @@ -680,8 +680,9 @@ config_getproto(struct relayd *env, stru
> &g
On Fri, Nov 03, 2017 at 07:06:34PM +0100, Matthias Schmidt wrote:
> my system dropped into ddb when running X11 and quitting Firefox (with
> the intention to quit X and shutdown).
pf_test_rule+0xa0b is when pf_send_tcp() calls ip_send().
This was fixed here:
https://marc.info/?l=openbsd-cvs&m=150
On Thu, Nov 16, 2017 at 12:06:45PM -0200, arfrei...@cpan.org wrote:
> >Synopsis: missing "software" on dictionary files
I have added "software" to our dictionary in -current which will
be released as OpenBSD-6.3.
Thanks for the bug report.
bluhm
On Mon, Nov 20, 2017 at 02:46:22PM +0100, Martin Pieuchot wrote:
> The problem is that ip6_forward() contains an unchecked if_get(). Diff
> below should fix that.
OK bluhm@
> Index: netinet6/ip6_forward.c
> ===
> RCS file: /cvs/src/
On Mon, Nov 20, 2017 at 08:07:04PM +0100, Jiri Navratil wrote:
> So there is difference between man page and command.
You have to read further down:
STANDARDS
Historic versions of the grep utility also supported the flags [-ruy].
This implementation supports those options; however, thei
On Wed, Nov 29, 2017 at 06:31:31PM +0100, Landry Breuil wrote:
> 18:25:21.580108 rule 1/(match) [uid 0, pid 33213] pass out on em0: [uid
> 1000, pid 23403]
>
> interestingly i couldnt figure out what the info '[uid 0, pid 33213]'
> was referring to since on the local system there's no such pid (in
1 - 100 of 385 matches
Mail list logo
