Re: VM errors on -current

On 2015-11-06 20:02, Michael Butler wrote: > Is anyone else seeing VM errors from X on -current with an old Intel > display adapter? > > agp0: on vgapci0 > agp0: aperture size is 256M, detected 7932k stolen memory > > [ .. snip .. ] > > kernel: vm_fault: pager read error, pid 1103 (Xorg)

Re: VM errors on -current

On 11/06/15 20:04, Allan Jude wrote: > On 2015-11-06 20:02, Michael Butler wrote: >> Is anyone else seeing VM errors from X on -current with an old Intel >> display adapter? >> >> agp0: on vgapci0 >> agp0: aperture size is 256M, detected 7932k stolen memory >> >> [ .. snip .. ] >> >> kernel:

VM errors on -current

Is anyone else seeing VM errors from X on -current with an old Intel display adapter? agp0: on vgapci0 agp0: aperture size is 256M, detected 7932k stolen memory [ .. snip .. ] kernel: vm_fault: pager read error, pid 1103 (Xorg) <- ?? kdm[993]: X server for display :0 terminated

Re: Panic with PF on current.

> On 06 Nov 2015, at 01:12, Daniel Dettlaff wrote: > I have interesting verbose output with backtrace (not panic) from one of my > VMs: http://s.verknowsys.com/f0d457ce9420399baaf531012c33eb81.png > It’s triggered by autostarting jail on bridged vlan interface (no VNET >

Re: nanoBSD: buidlworld failure

On Fri, 6 Nov 2015 00:43:35 -0800 NGie Cooper wrote: > > On Nov 5, 2015, at 22:51, O. Hartmann wrote: > > > > Since two days, I receive the error shown below on a build machine building > > nanoBSD. The recent CURRENT (nanoBSD sources AND the

Re: nanoBSD: buidlworld failure

> On Nov 5, 2015, at 22:51, O. Hartmann wrote: > > Since two days, I receive the error shown below on a build machine building > nanoBSD. The recent CURRENT (nanoBSD sources AND the building host) is > > FreeBSD 11.0-CURRENT #2 r290394: Thu Nov 5 16:30:20 CET 2015

Re: Timing issue with Dummynet on high kernel timer interrupt

Ideally there'd be both behaviours: * You'd specify whether a timer/sleep needs to be exact or can withstand some jitter (which is what linux provides); and * You can communicate to the kernel its aggressiveness for coalescing wakeups. Teaching powerd to flip on/off a sysctl for this isn't that

Re: Timing issue with Dummynet on high kernel timer interrupt

On Fri, 6 Nov 2015, Ian Lepore wrote: On Fri, 2015-11-06 at 17:51 +0100, Hans Petter Selasky wrote: On 11/06/15 17:43, Ian Lepore wrote: On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote: Hi, Do the test II results change with this setting? sysctl

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

On 11/06/15 01:55, Mateusz Guzik wrote: On Thu, Nov 05, 2015 at 04:35:22PM -0700, Ian Lepore wrote: On Thu, 2015-11-05 at 14:19 -0800, John Baldwin wrote: On Thursday, November 05, 2015 01:45:19 PM Adrian Chadd wrote: On 5 November 2015 at 11:26, Mateusz Guzik wrote: On

Re: strange kernel crash

On Fri, Nov 06, 2015 at 01:20:13PM +0200, Andriy Gapon wrote: > Unread portion of the kernel message buffer: > > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0x80619a1e > stack pointer =

Re: r289932 causes pf reversion - breaks rules with broadcast destination

On 2015-11-05 12:39:22 (-0500), Tom Uffner wrote: > So, if my rule was "working" due to false positive in a comparison that has > now been fixed, how many other address comparisons were affected by this > error? > > There are 36 occurrences of PF_ANEQ in pf.c and 2 in

Re: strange kernel crash

On 06/11/2015 17:35, Konstantin Belousov wrote: > This is a second report, please take a look at > https://lists.freebsd.org/pipermail/freebsd-current/2015-October/057975.html > I have no idea as well. In my case it does not look like the code was overwritten, though. -- Andriy Gapon

Re: Timing issue with Dummynet on high kernel timer interrupt

Hi, I spent some time to write a test application to investigate this issue and I found some irregularities, that when kern.eventtimer.periodic=0, the timer appears to run very irregular. Test software: == fetch http://home.selasky.org:8192/privat/callout_test_dummynet.tar.gz

Re: Timing issue with Dummynet on high kernel timer interrupt

On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote: > Hi, > > I spent some time to write a test application to investigate this > issue > and I found some irregularities, that when > kern.eventtimer.periodic=0, > the timer appears to run very irregular. > > Test software: >

Re: Timing issue with Dummynet on high kernel timer interrupt

On 11/06/15 17:43, Ian Lepore wrote: On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote: Hi, Do the test II results change with this setting? sysctl kern.timecounter.alloweddeviation=0 Yes, it looks much better: debug.total: 10013 -> 0 debug.total: 10013 -> 0 debug.total:

Re: Timing issue with Dummynet on high kernel timer interrupt

On 11/06/15 17:51, Hans Petter Selasky wrote: On 11/06/15 17:43, Ian Lepore wrote: On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote: Hi, Do the test II results change with this setting? sysctl kern.timecounter.alloweddeviation=0 Yes, it looks much better: debug.total:

Re: Timing issue with Dummynet on high kernel timer interrupt

On Fri, 2015-11-06 at 17:51 +0100, Hans Petter Selasky wrote: > On 11/06/15 17:43, Ian Lepore wrote: > > On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote: > > > Hi, > > > > > Do the test II results change with this setting? > > > >sysctl kern.timecounter.alloweddeviation=0 > >

strange kernel crash

Unread portion of the kernel message buffer: Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x80619a1e stack pointer = 0x28:0xfe04f57856f0 frame pointer = 0x28:0xfe04f57857b0 code segment

Re: Timing issue with Dummynet on high kernel timer interrupt

On Fri, 2015-11-06 at 17:57 +0100, Hans Petter Selasky wrote: > On 11/06/15 17:51, Hans Petter Selasky wrote: > > On 11/06/15 17:43, Ian Lepore wrote: > > > On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote: > > > > Hi, > > > > > > > > Do the test II results change with this setting?

Re: strange kernel crash

On 11/06/15 12:20, Andriy Gapon wrote: Now the strange part: 0x80619a18 <+744>: jne0x80619a61 <__mtx_lock_flags+817> 0x80619a1a <+746>: mov%rbx,(%rsp) => 0x80619a1e <+750>: movq $0x0,0x18(%rsp) 0x80619a27 <+759>: movq

panic in zfs on reboot

I updated my machine that tracks head and rebooted it, and it panic'd during the 'shutdown -r' execution. Panic String: solaris assert: zrl->zr_refcount == 0 (0x2 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c, line: 64 (kgdb) bt #0 doadump (textdump=1) at

Re: strange kernel crash

On 6 Nov, Konstantin Belousov wrote: > On Fri, Nov 06, 2015 at 01:20:13PM +0200, Andriy Gapon wrote: >> Unread portion of the kernel message buffer: >> >> Fatal trap 1: privileged instruction fault while in kernel mode >> cpuid = 0; apic id = 00 >> instruction pointer =

Re: panic in zfs on reboot

On 11/6/15 1:12 PM, Kurt Lidl wrote: I updated my machine that tracks head and rebooted it, and it panic'd during the 'shutdown -r' execution. Panic String: solaris assert: zrl->zr_refcount == 0 (0x2 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c, line: 64

Re: Timing issue with Dummynet on high kernel timer interrupt

Adrian Chadd wrote this message on Fri, Nov 06, 2015 at 11:15 -0800: > Ideally there'd be both behaviours: > > * You'd specify whether a timer/sleep needs to be exact or can > withstand some jitter (which is what linux provides); and Isn't that what the precision argument in callout is for? See

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

On 5 Nov 2015, at 16:55, Mateusz Guzik wrote: > >> Will that cause problems, especially for code inside a loop >> where the compiler may decide to shuffle things around? >> > > Lock value is volatile, so the compiler should not screw us up. Note: volatile means do not

Re: FYI: SVN to GIT converter currently broken, github is falling behind

2015-11-05 15:46 GMT+01:00 Ulrich Spörlein : > 2015-11-04 18:57 GMT+01:00 Ulrich Spörlein : >> The recent SVN update on the cluster broke svn2git in certain circumstances. >> >> To fix this and make sure no content was dropped, the converter has >> been stopped

Re: strange kernel crash

On 06/11/2015 20:02, Hans Petter Selasky wrote: > On 11/06/15 12:20, Andriy Gapon wrote: >> Now the strange part: >> >> 0x80619a18 <+744>: jne0x80619a61 >> <__mtx_lock_flags+817> >> 0x80619a1a <+746>: mov%rbx,(%rsp) >> => 0x80619a1e <+750>: