On Mon, Sep 16, 2019 at 05:44:28PM +1000, Peter Jeremy wrote:
> On 2019-Sep-16 09:32:52 +0300, Konstantin Belousov
> wrote:
> >On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote:
> >> I'm consistently seeing panics in the NFS code on recent -current on
> &
On Tue, Sep 17, 2019 at 02:42:51PM +0900, Masachika ISHIZUKA wrote:
> >> This panic happens on 1300047 (both r352239 and r352386) with core
> >> i5-7500 as follows. This panic dose not happen on r351728 (1300044).
> >> (The following lines were typed by hand so they might have some miss
> >> type
On Tue, Sep 17, 2019 at 08:18:26PM +1000, Peter Jeremy wrote:
> On 2019-Sep-17 11:06:58 +0300, Konstantin Belousov
> wrote:
> >Try the following change, which more accurately tries to avoid
> >vnode_pager_setsize(). The real cause requires much more extensive
> >changes.
On Sat, Sep 21, 2019 at 12:19:19PM -0400, Ryan Stone wrote:
> If I try direct exec ld via rtld, I get the following failure:
>
> # /libexec/ld-elf.so.1 /usr/bin/ld
> ld-elf.so.1: /usr/bin/ld: mmap of entire address space failed: Cannot
> allocate memory
>
> Is there some sysctl limit I need to bu
On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote:
> The latest VM snapshot (FreeBSD-13.0-CURRENT-amd64-20190920-r352544.qcow2)
> instapanics on boot:
>
> panic: Unregistered use of FPU in kernel
>
> stack trace:
> ...
> sse42_crc32c
> readsuper
> ffs_sbget
> g_label_ufs_taste_common
>
On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote:
> On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov
> wrote:
>
> > On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote:
> > > The latest VM snapshot
> > (FreeBSD-13.0-CURRENT-amd64-20190920-r3
On Thu, Sep 26, 2019 at 02:12:21PM -0600, Alan Somers wrote:
> On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov
> wrote:
>
> > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote:
> > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov <
> >
On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote:
>
> We observe a problem that happens very rarely (about once a month across many
> test machines). The problem is that a thread remain in sleepq_timedwait()
> even
> after its timeout expires. The thread's td_slpcallout looks like t
On Tue, Oct 22, 2019 at 02:48:56PM +0300, Andriy Gapon wrote:
> On 22/10/2019 13:44, Konstantin Belousov wrote:
> > On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote:
> >>
> >> We observe a problem that happens very rarely (about once a month across
> >
On Mon, Nov 11, 2019 at 01:22:09PM +0100, Hans Petter Selasky wrote:
> On 2019-11-11 11:44, Hans Petter Selasky wrote:
> > Seems like we can optimise away one more write memory barrier.
> >
> > If you are building from ports, simply:
> >
> > cd work/kms-drm*
> > cat seqlock.diff | patch -p1
> >
On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote:
> HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory
>
> I assume that there is missing error handling in or logic here somewhere
> as every one of my machines is spamming my consoles on startup with this
> new messag
On Tue, Sep 16, 2014 at 12:08:54PM -0700, Sean Bruno wrote:
> On Tue, 2014-09-16 at 21:57 +0300, Konstantin Belousov wrote:
> > On Tue, Sep 16, 2014 at 11:40:15AM -0700, Sean Bruno wrote:
> > > HV_KVP: open /dev/hv_kvp_dev failed; error: 2 No such file or directory
> > >
hr_stack_initial = rlim.rlim_cur;
diff --git a/share/man/man7/libthr.7 b/share/man/man7/libthr.7
new file mode 100644
index 000..16d916f
--- /dev/null
+++ b/share/man/man7/libthr.7
@@ -0,0 +1,254 @@
+.\" Copyright (c) 2014 The FreeBSD Foundation, Inc.
+.\" All rights reserved.
+.\"
+.
On Mon, Sep 22, 2014 at 09:19:30AM -0400, Daniel Eischen wrote:
> On Sun, 21 Sep 2014, Julian Elischer wrote:
>
> > On 9/20/14, 3:27 AM, John Baldwin wrote:
> >> On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote:
> >>> On Mon, Sep 15, 2014 at
bthr.3
@@ -1,6 +1,11 @@
.\" Copyright (c) 2005 Robert N. M. Watson
+.\" Copyright (c) 2014 The FreeBSD Foundation, Inc.
.\" All rights reserved.
.\"
+.\" Part of this documentation was written by
+.\" Konstantin Belousov under sponsorship
+.\" from the FreeBSD Foun
Please find at the
https://kib.kiev.ua/kib/drm/i915.1.patch
a patch which provides some updates to the i915 driver. At large, this
is import of the batch of Linux commits, and as such, it is interesting
mostly as attempt to restart the race to get us more up to date Linux code
imported. It might pr
On Fri, Oct 03, 2014 at 05:25:33PM +0900, Kohji Okuno wrote:
> Hi,
>
> At least in i386 && 9-stable, when we call pmap_mapdev() and
> pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased
> incorrectly.
>
> pmap_mapdev_attr()->pmap_kenter_attr():
> In this path, kernel_pmap.pm_stats.r
On Sat, Oct 04, 2014 at 05:00:36PM +0900, Kohji Okuno wrote:
> Hi, Konstantin,
>
> Thank you for your comment.
> And, your change is better than mine.
At the end of the mail is commit candidate. I did not even compiled this.
Can you test and report back, please ?
>
> > Do you mean that this pan
On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
> Hi, Konstantin,
>
> > At the end of the mail is commit candidate. I did not even compiled this.
> > Can you test and report back, please ?
>
> Could you check the following?
> (1) should use kernel_pmap->pm_stats.resident_count
>
On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
> Hi Konstantin,
>
> Thank you for your prompt response.
> I will test and report from next monday.
>
> >> In addtion, I have one question.
> >> In current and 10-stable, is vm_map_delete() called by kva_free()?
> > No, kva_free() only
On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote:
> Hi,
>
> > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
> >> Hi Konstantin,
> >>
> >> Thank you for your prompt response.
> >> I will test and report from next monday.
> >>
> >> >> In addtion, I have one question.
> >>
On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
> (kgdb) #0 doadump (textdump=1) at pcpu.h:219
> #1 0x80661efd in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:447
> #2 0x80662450 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:746
On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
> On 10/05/2014 13:00, Konstantin Belousov wrote:
> > On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote:
> >> (kgdb) #0 doadump (textdump=1) at pcpu.h:219
> >> #1 0x80661ef
On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:
>
> On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
> > On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote:
> >> On 10/05/2014 13:00, Konstantin Belousov wrote:
> >>> On Sun, Oct 0
On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote:
> >From the same frame, please do
> p *(struct drm_i915_private *)(dev->private)
I probably figured out what is wrong, but it is still interesting to
see this piece of data.
For everybody who has the issue with bla
On Tue, Oct 07, 2014 at 02:08:06PM -0400, Adam McDougall wrote:
> On 10/07/2014 12:44, Konstantin Belousov wrote:
> > On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote:
> >>
> >> On 10/7/2014 12:20 AM, Konstantin Belousov wrote:
> >>> On Mon,
On Tue, Oct 07, 2014 at 04:04:54PM -0400, Adam McDougall wrote:
> On 10/07/2014 14:01, Konstantin Belousov wrote:
> > On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote:
> >> >From the same frame, please do
> >> p *(struct drm_i915_priva
On Mon, Oct 13, 2014 at 07:29:43PM +0800, Julian Elischer wrote:
> I'm faced with porting some code that has patched the 8.0 kernel
> to accept up to 16 args in a syscall.
> It makes my skin crawl a bit but if I can't give a good reason to
> suggest that they do things differently in 10 (pass a poi
On Wed, Oct 15, 2014 at 11:56:33PM -0600, Justin T. Gibbs wrote:
> avg pointed out the rate limiting code in vm_pageout_scan() during discussion
> about PR 187594. While it certainly can contribute to the problems discussed
> in that PR, a bigger problem is that it can allow the OOM killer to be
On Sun, Oct 19, 2014 at 10:53:35AM -0700, Jim Pazarena wrote:
> I find that while a job is running via the at facility, that is,
> atrun has executed it, every subsequent execution of atrun (via
> cron) STAYS running while the original program (executed by atrun)
> is still active.
>
> Generally,
On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote:
> On 10/08/2014 13:05, Konstantin Belousov wrote:
> > There are more occurences of the bug I fixed once in patch version 2.
> > Also, since pmap changes were committed in modified form, please try
> > the u
In fact, try
https://www.kib.kiev.ua/kib/drm/i915.5.patch
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote:
> On 10/22/2014 08:26, Konstantin Belousov wrote:
> > On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote:
> >> On 10/08/2014 13:05, Konstantin Belousov wrote:
> >>> There are more occuren
On Fri, Oct 24, 2014 at 04:43:28PM +0100, Robert Watson wrote:
> On Thu, 23 Oct 2014, Rick Macklem wrote:
>
> > Someone just pinged me on this and I figured I should bring it up.
> >
> > 1 - Is anyone out there still using oldnfs due to unresolved
> >problems with the new one? (I am not aware
On Fri, Oct 24, 2014 at 01:42:20PM -0400, Ed Maste wrote:
> On 24 October 2014 12:17, Konstantin Belousov wrote:
> >
> > I remember the main reason for keeping oldnfs, both server and client,
> > around in HEAD was to facilitate MFC of fixes to the branches which
> > st
On Sun, Oct 26, 2014 at 08:14:05AM -0400, Rick Macklem wrote:
> Beeblebrox wrote:
> > Sorry guys, we have a considerable time-zone difference.
> >
> > >> It appears that the sysctl must be set before mountd, nfsd are
> > >> started to take effect. (Or they must be restarted after it is
> > >> set.
On Sun, Oct 26, 2014 at 06:42:29PM -0400, Rick Macklem wrote:
> Worked fine for me. Do you mind if I commit this or would you rather
> do it.
I committed the change as r273727.
One issue with the commit is the specified MFC. The change will compile
on stable/10, but as far as I remember the state
On Mon, Oct 27, 2014 at 12:02:11AM +0300, Chagin Dmitry wrote:
> On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote:
> > On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote:
> > > On 10/22/2014 08:26, Konstantin Belousov wrote:
> >
> > U
On Mon, Nov 10, 2014 at 02:49:39AM +0100, Luigi Rizzo wrote:
> It was noticed that there is huge dev_lock() contention when multiple
> processes do a poll() even on independent file descriptors.
>
> Turns out that not just poll but most syscalls on file descriptors
> (as opposed to sockets) in sys
On Mon, Nov 10, 2014 at 10:44:12AM +0100, Luigi Rizzo wrote:
> On Mon, Nov 10, 2014 at 10:34:57AM +0200, Konstantin Belousov wrote:
> > On Mon, Nov 10, 2014 at 02:49:39AM +0100, Luigi Rizzo wrote:
> > > It was noticed that there is huge dev_lock() contention when multiple
> &g
On Thu, Nov 13, 2014 at 12:39:40PM -0500, Eric van Gyzen wrote:
> There is a [practically] tautological assertion in kern_umtx.c. I have
> not even compile-tested the following patch. I'll test it when I have
> time. I'd be grateful if someone beats me to it.
>
> Eric
>
>
> diff --git a/sys/k
On Fri, Nov 14, 2014 at 03:52:39AM +0300, Andrey V. Elsukov wrote:
> On 08.11.2014 07:23, John-Mark Gurney wrote:
> > Hello,
> >
> > Over the last few months, I've been working on a project to add support
> > for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is
> > sponsored by
On Wed, Nov 26, 2014 at 04:41:27PM -0800, Davide Italiano wrote:
> On Mon, Aug 25, 2014 at 12:37 PM, John Baldwin wrote:
> > On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote:
> >> One of my personal goals for 11 is to get rid of cloning mechanism
> >> entirely, and pty(4) is one of
On Fri, Nov 28, 2014 at 04:29:42PM +0300, Eygene Ryabinkin wrote:
> Konstantin, *, good day.
>
> I noticed that the current ioctl processing code for drm2 implicitely
> assumes that the number of native ioctls is higher than that of 32-bit
> compat ones, so it immediately gives EINVAL when
> nr >=
On Sat, Dec 06, 2014 at 04:01:26PM +0100, Dimitry Andric wrote:
> [trimmed CC list to -current]
>
> On 06 Dec 2014, at 04:59, Garrett Cooper wrote:
> > 2. Why isn?t this value determined once in Makefile.inc1 (per build
> > phase), then passed down from there
>
> Because you are supposed to
On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
> Hi,
>
> I've experienced a hard lockup on head r275563, amd64.
>
> The hardware is a laptop with an intel graphics card.
>
> If any further info is required just ask.
>
> I had just launched a virtualbox VM with Windows 7, the syst
On Sat, Dec 13, 2014 at 01:13:04AM +0100, Guido Falsi wrote:
> On 12/10/14 09:58, Guido Falsi wrote:
> > On 12/10/14 09:52, Konstantin Belousov wrote:
> >> On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
> >>
> [...]
> >>> -
On Mon, Jan 05, 2015 at 02:18:17PM +0100, Hans Petter Selasky wrote:
> Hi,
>
> There is a limitiation on the number of interrupt vectors available when
> only a single processor is running. To have more interrupts available we
> need to start SMP earlier when building a monotolith kernel and not
On Tue, Jan 06, 2015 at 09:37:30AM -0500, John Baldwin wrote:
> On 1/5/15 8:18 AM, Hans Petter Selasky wrote:
> > Hi,
> >
> > There is a limitiation on the number of interrupt vectors available when
> > only a single processor is running. To have more interrupts available we
> > need to start SMP
/src/sys/kern/sys_generic.c:718
> #9 0x80d8590a in amd64_syscall (td=0xf80009c74000, traced=0)
> at subr_syscall.c:133
> #10 0x80d632ab in Xfast_syscall ()
> at /usr/src/sys/amd64/amd64/exception.S:395
> #11 0x0008022a56fa in ?? ()
> Previous frame inner
On Thu, Jan 08, 2015 at 05:09:23PM +0100, Micha?? Stanek wrote:
> Hello all,
>
> I ran into an issue with AHCI BAR allocation on arm64. The AHCI PCI driver
> in sys/dev/ahci/ahci_pci.c assumes that ABAR (AHCI Base Address) register
> is located at offset 0x24 (BAR5) in the PCI header. Specificatio
On Fri, Jan 09, 2015 at 06:07:39PM +0100, Micha?? Stanek wrote:
> 2015-01-08 21:40 GMT+01:00 Konstantin Belousov :
>
> > > However, if
> > > AHCI uses 64-bit base addresses, then this register consists of two
> > dwords
> > > starting at offset 0x20 - BAR4
On Mon, Jan 12, 2015 at 05:21:24PM +0100, Micha?? Stanek wrote:
> OK, I added AHCI_Q_ABAR0 as a new quirk and test the bit in
> ahci_pci_attach. It works the same. New patch is in the attachment.
>
Committed as r277100.
Thank you.
___
freebsd-current@fr
On Tue, Jan 20, 2015 at 08:55:05AM +, Poul-Henning Kamp wrote:
> I just tried current as of yesterday and had to give up rather quickly.
>
> unbound sig#11'ed on bootup, couldn't find a coredump.
>
> Trying to read a PDF file with evince I got one:
>
> $ evince
> Fatal error 'mutex is on lis
On Thu, Jan 22, 2015 at 11:16:41AM +0100, Hans Petter Selasky wrote:
> On 01/20/15 11:47, Slawa Olhovchenkov wrote:
> > On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote:
> >
> >> On 01/17/15 23:18, Hans Petter Selasky wrote:
> >>> On 01/17/15 20:11, Jason Wolfe wrote:
>
> >>
On Thu, Jan 22, 2015 at 12:02:01PM +0100, Edward Tomasz Napiera??a wrote:
> I'm trying to fix resume on my T61, broken by some change several
> months ago; according to pciconf it's 'Mobile GM965/GL960 Integrated
> Graphics Controller (primary)'. It's running current CURRENT and
> up to date packa
On Wed, Jan 21, 2015 at 01:47:06PM -0800, Steve Kargl wrote:
> Just got this panic. If anyone is interested I have the
> kenrel and core, so can do some additional poking around.
>
> troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.0
>
> Wed Jan 21 13:28:04 PST 2015
>
> FreeBSD
On Sat, Jan 24, 2015 at 12:46:33PM +0300, Chagin Dmitry wrote:
> Hi,
>
>
> dchagin.static.corbina.net dumped core - see /var/crash/vmcore.7
>
> Sat Jan 24 01:02:20 MSK 2015
>
> FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #2
> r277611+c41ef74(lemul): Sat Jan 24 00:53:45
On Fri, Jan 23, 2015 at 07:58:08AM -0800, Steve Kargl wrote:
> On Fri, Jan 23, 2015 at 12:51:00PM +0200, Konstantin Belousov wrote:
> > On Wed, Jan 21, 2015 at 01:47:06PM -0800, Steve Kargl wrote:
> > > Fatal trap 9: general protection fault while in kernel mode
> > &
On Sat, Jan 24, 2015 at 10:42:45PM +0300, Chagin Dmitry wrote:
> On Sat, Jan 24, 2015 at 12:35:19PM +0200, Konstantin Belousov wrote:
> > On Sat, Jan 24, 2015 at 12:46:33PM +0300, Chagin Dmitry wrote:
> > > Hi,
> > >
> > >
> > > dchagin.static.corb
On Sun, Jan 25, 2015 at 05:15:59PM +0300, Dmitry Chagin wrote:
> 2015-01-25 15:06 GMT+03:00 Konstantin Belousov :
>
> > On Sat, Jan 24, 2015 at 10:42:45PM +0300, Chagin Dmitry wrote:
> > > On Sat, Jan 24, 2015 at 12:35:19PM +0200, Konstantin Belousov wrote:
> > > &
On Tue, Jan 27, 2015 at 11:31:03PM +0300, Gleb Smirnoff wrote:
> Got this in bhyve VM on boot up and mount:
>
> Starting file system checks:
> /dev/vtbd0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/vtbd0p3: clean, 1617700 free (222876 frags, 174353 blocks, 5.9%
> fragmentation)
>
>
> Fatal tra
On Wed, Jan 28, 2015 at 09:22:30PM +0300, Gleb Smirnoff wrote:
> On Wed, Jan 28, 2015 at 12:48:42PM +0200, Konstantin Belousov wrote:
> K> > Stopped at softdep_slowdown+0x1d3: idivl %ecx,%eax
> K> > db> bt
> K> > Tracing pid 49 tid 100045 td 0xf800026e
On Sat, Jan 31, 2015 at 09:07:23AM -0600, Eric Badger wrote:
> In FreeBSD 9, examining the VM map of a process (with e.g. 'procstat
> -v') with a tmpfs file mapped showed a VNODE type and displayed the file
> path. In 10.0 up to CURRENT (I believe this started at r250030), instead
> SWAP is show
On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote:
>
> On 01/31/2015 09:36 AM, Konstantin Belousov wrote:
> > First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ?
> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type;
> I'd o
On Mon, Feb 02, 2015 at 10:22:36AM -0800, Steve Kargl wrote:
> On Mon, Feb 02, 2015 at 01:10:47PM -0500, Eric van Gyzen wrote:
> > On 02/02/2015 12:59, Steve Kargl wrote:
> > > (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93
> > > ) at pcpu.h:219
> > > #1 0x80559f47 in
On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote:
>
> On 02/02/2015 03:30 AM, Konstantin Belousov wrote:
> > On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote:
> >> On 01/31/2015 09:36 AM, Konstantin Belousov wrote:
> >>> First,
On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote:
> Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been
> introduced to 11.x/head/-current.With HZ=1000 (the default for bare
> metal,
> not for a vm); the clocks stop just after 24 days of uptime. This means
>
On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote:
> If you let bsdtar continue, and press control-T a few times, does the
> user time (u) increase at all? Does it ever go any further, if you let
> it run for a very long time?
>
> I believe a problem may have been introduced by r2779
On Wed, Feb 04, 2015 at 10:15:04AM -0500, John Baldwin wrote:
> On Tuesday, February 03, 2015 10:33:36 PM Konstantin Belousov wrote:
> > On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote:
> > > On 02/02/2015 03:30 AM, Konstantin Belousov wrote:
> > > > On S
On Thu, Feb 05, 2015 at 12:45:55AM -0800, Alfred Perlstein wrote:
>
>
> On 2/5/15 12:30 AM, Konstantin Belousov wrote:
> > On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote:
> >> If you let bsdtar continue, and press control-T a few times, does the
> >&
On Fri, Feb 06, 2015 at 05:10:24PM +, Poul-Henning Kamp wrote:
> Thinkpad T430s:
>
> 11.0-CURRENT #15 r278283: Thu Feb 5 22:45:26 UTC 2015
>
> Anybody know what this means ?
There is no public documentation about renderer power and clock
management. It seems that NDA'ed doc does not contain
On Thu, Feb 12, 2015 at 02:39:12AM +, Glen Barber wrote:
> Hi,
>
> Within the next 24 hours, I will merge the release-install-debug branch
> into head, which will enable building and installing stripped debugging
> files by default.
>
> In general, this should have no significant impact, but
On Sun, Feb 15, 2015 at 03:37:17PM +0100, Ranjan1018 . wrote:
> Hi,
> the bug was introduced in r278473. Suspend/resume works again if I disable
> the x2APIC support with hw.x2apic_enable=0 in /boot/loader.conf, tested in
> r278473 and r278741.
So how it is related to i915 ?
Try the patch.
diff
On Sun, Feb 15, 2015 at 07:45:44PM +0100, Ranjan1018 . wrote:
>
> Unfortunately does not work for me. Tested with r278803.
Does your machine resume if you boot with hw.x2apic_enable set to 0
from the loader prompt ? Confirm that x2apic is disabled after tunable
frobbing, with sysctl hw.apic.x2ap
On Sun, Feb 15, 2015 at 08:43:55PM +0100, Ranjan1018 . wrote:
> 2015-02-15 19:59 GMT+01:00 Konstantin Belousov :
>
> > On Sun, Feb 15, 2015 at 07:45:44PM +0100, Ranjan1018 . wrote:
> > >
> > > Unfortunately does not work for me. Tested with r278803.
> >
>
On Mon, Feb 16, 2015 at 08:10:06PM -0800, Sean Bruno wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> https://people.freebsd.org/~sbruno/Xen_APIC_panic.png
>
> I suspect that there may be one or two more lines above this that are
> relevant to this panic, but XENHVM kernel's now pan
On Tue, Feb 17, 2015 at 12:00:04PM -0800, Sean Bruno wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/17/15 00:56, Konstantin Belousov wrote:
> > On Mon, Feb 16, 2015 at 08:10:06PM -0800, Sean Bruno wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Ha
On Thu, Feb 19, 2015 at 11:50:49AM -0800, Neel Natu wrote:
> Hi Adrian,
>
> On Wed, Feb 18, 2015 at 10:09 PM, Adrian Chadd wrote:
> > Hi,
> >
> > Since this is the (at least) second round of "x2apic support broke me"
> > changes, can we please either back them out or set it to default to
> > '0'
On Fri, Feb 20, 2015 at 03:09:49PM -0600, Andrew Wilcox wrote:
> Hello,
>
> The i386 port, both 10-STABLE and 11-CURRENT, will not boot on systems
> without SSE support. This is caused by r273995, as using `svn merge -c
> -273995` (and hacking-and-sloshing through the few compiler errors
> aft
On Sat, Feb 21, 2015 at 12:27:22PM -0800, Sean Bruno wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Well, this is new. It looks like current panic'd when trying to dump a
> core from a qemu crash? I can leave this at the debugger for now as
> this is a machine doing mips packa
On Sun, Feb 22, 2015 at 09:34:29AM -0800, Sean Bruno wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> > Err. Is it easily reproducable in your setup ? The core file vnode
> > is indeed unreferenced before notification is sent.
> >
> > Try this.
> >
> > diff --git a/sys/kern/kern_s
On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote:
> Hmm ... looks unrelated to signals (maybe). This looks like a common
> ZFS deadlock that is yet undiagnosed. I do not have a show alllocks
> command available in db> . I will show each lock information below:
Add witness.
>
> db> sh
On Sun, Feb 22, 2015 at 03:00:25PM -0800, Sean Bruno wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/22/15 10:54, Sean Bruno wrote:
> > On 02/22/15 10:53, Konstantin Belousov wrote:
> >> On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote:
&g
On Mon, Mar 02, 2015 at 04:17:03PM -0800, Adrian Chadd wrote:
> On 2 March 2015 at 16:12, K. Macy wrote:
> >>> Right above vm_page_hold():
> >>> /*
> >>> * Keep page from being freed by the page daemon
> >>> * much of the same effect as wiring, except much lower
> >>> * overhead and should be u
On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote:
> On Fri, Mar 20, 2015 at 02:08:23AM +, jenkins-ad...@freebsd.org wrote:
> > lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by
> > uid 977 (pid 29170); see tuning(7) and login.conf(5)
> > passed [0.551s]
>
On Fri, Mar 20, 2015 at 10:52:06AM +0100, Mateusz Guzik wrote:
> On Fri, Mar 20, 2015 at 11:34:51AM +0200, Konstantin Belousov wrote:
> > On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote:
> > > On Fri, Mar 20, 2015 at 02:08:23AM +, jenkins-ad...@freebsd.org wrote
On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote:
> Hello everybody,
>
> The malloc_init_hard() function defined in jemalloc_jemalloc.c, FreeBSD
> 11 r277486 reads:
>
> static bool
> malloc_init_hard(void)
> {
> ...
> if (base_boot()) {
> malloc_mutex_unlock(&in
On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote:
> From: Mateusz Guzik
>
> Prior to this change the kernel would take p1's credentials and assign
> them tempororarily to p2. But p1 could change credentials at that time
> and in effect give us a use-after-free.
In which way could it
On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote:
> On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote:
> > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote:
> > > From: Mateusz Guzik
> > >
> > > Prior to th
On Sat, Mar 21, 2015 at 07:19:31PM +0100, Mateusz Guzik wrote:
> On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote:
> > On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote:
> > > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote:
>
On Sat, Mar 21, 2015 at 11:20:26AM +0200, Ivan A. Kosarev wrote:
>
> On 03/21/2015 03:02 AM, Konstantin Belousov wrote:
> > On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote:
> >> #12 0x0008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698
>
On Mon, Mar 23, 2015 at 01:50:26PM +0200, Ivan A. Kosarev wrote:
>
> On 03/21/2015 11:31 PM, Konstantin Belousov wrote:
> > On Sat, Mar 21, 2015 at 11:20:26AM +0200, Ivan A. Kosarev wrote:
> >> On 03/21/2015 03:02 AM, Konstantin Belousov wrote:
> >>> On Fri, Mar 2
On Fri, Mar 27, 2015 at 01:49:03PM -0700, Rui Paulo wrote:
> On Mar 27, 2015, at 12:26, Eric van Gyzen wrote:
> >
> > In a nutshell:
> >
> > Clang emits SSE instructions on amd64 in the common path of
> > pthread_mutex_unlock. This reduces performance by a non-trivial amount.
> > I'd
> > like
On Fri, Mar 27, 2015 at 10:40:57PM +0100, Jilles Tjoelker wrote:
> On Fri, Mar 27, 2015 at 03:26:17PM -0400, Eric van Gyzen wrote:
> > In a nutshell:
>
> > Clang emits SSE instructions on amd64 in the common path of
> > pthread_mutex_unlock. This reduces performance by a non-trivial
> > amount.
On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote:
> On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote:
> H> On 03/30/15 23:19, Gleb Smirnoff wrote:
> H> > On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote:
> H> > M> I get the following panic on current svn
On Tue, Mar 31, 2015 at 02:51:47AM +0300, Konstantin Belousov wrote:
> On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote:
> > On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote:
> > H> On 03/30/15 23:19, Gleb Smirnoff wrote:
> > H> > On S
On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote:
> Kernel memory for data transferred via the queued interface is
> allocated from the zone allocator in MAXPHYS sized chunks, and user
> data is copied in and out. This is likely faster than the
> vmapbuf()/vunmapbuf() method used
On Tue, Mar 31, 2015 at 04:50:51PM -0600, Kenneth D. Merry wrote:
> On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote:
> > On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote:
> > > Kernel memory for data transferred via the queued interface is
&g
On Sun, Apr 05, 2015 at 06:47:21PM +0300, Gleb Smirnoff wrote:
> This is r281079.
>
> Since vm_page_advise() may call vm_page_dirty() in the MADV_DONTNEED case,
> the assertion is valid. So, looks like vm_fault_dontneed() needs W-lock on
> the first_object.
>
Either this, or vm_page_advise() coul
101 - 200 of 1254 matches
Mail list logo
