> 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 amd64
>
>
> [...]
> cc -O
> 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
> feature enabled)
>
Thi
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 building host) is
> >
> > FreeBSD 11.0-CURRENT #2 r
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
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 reorder loads/stores *to
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 Thu, Nov 05, 2015 at
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 = 0x28:0xfe04
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 if_pfsync.c
>
Most of them
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
___
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
tar
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:
> ==
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: 1
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: 10
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
> >
>
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?
>
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 = 0x20:0x80619a1
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 $0x0,
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
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
(k
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 t
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 kern.timecounter.allowedde
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
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 and we're working on bringing a fixed
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>: mov
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 unexpectedl
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) <
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_f
27 matches
Mail list logo
