Re: TSC as timecounter makes system lag

ndling the configurations, see sys/kern/kern_clocksource.c, the option and ET_FLAG_PERCPU. > > > On Mon, Jan 16, 2017 at 4:20 AM, Konstantin Belousov <kostik...@gmail.com> > wrote: > > > I still do not understand. Is the sysctl output below from the pristine > > boot where no

Re: panic: invalid bcd xxx

On Tue, Feb 28, 2017 at 10:47:39PM +0100, Michael Gmelin wrote: > Booting r313561[0] I get the following panic: > > mountroot: waiting for device /dev/ufs/FreeBSD_install > panic: invalid bcd 177 (also 254, 255 etc.) > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper... > vpanic()... >

Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

On Sun, Sep 04, 2016 at 04:11:39PM +0300, Andriy Gapon wrote: > On 04/09/2016 11:24, Andriy Gapon wrote: > > On 27/08/2016 22:09, Frederic Chardon wrote: > >>> Anybody is able to reproduce this behavior or is it a local problem? > >> Reverting 303970 solves this issue. gcore and adb works again,

Re: Question about wmb() and rmb() and task switching

On Fri, Sep 23, 2016 at 01:46:15PM +0200, Hans Petter Selasky wrote: > Hi, > > Does use of wmb() and rmb() for amd64 as defined in > sys/amd64/include/atomic.h required use of critical_enter()/critical_exit(). > > I was looking at the code in sys/amd64/amd64/cpu_switch.S which switches >

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

On Thu, Sep 22, 2016 at 08:48:29PM +0800, Ben Woods wrote: > Hi everyone, > > I am currently experiencing semi-regular kernel crashes on my FreeBSD > 12-current machine. I am new to kernel debugging, and hoping someone can > have a look at the debugging output below to point me in the direction

Re: r305902: ufs/inode.h:148:15: error: unknown type name 'bool'

On Sat, Sep 17, 2016 at 07:48:06PM +0200, O. Hartmann wrote: > Obviosly r305902 breaks source and so building a kernel, as the compiler > output below > shows. Reverting back to r305900 is fine. > > [...] > ===> lib/libprocstat/zfs (obj) > `zfs.o' is up to date. > Building

Re: kern.proc.pathname failure while booting from zfs

On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote: > Le 20 ao??t 2016 22:03, "Frederic Chardon" a > ??crit : > > > > Hi > > > > I see a strange interaction between zfs on root and kern.proc.pathname > > on my laptop. Whenever I try to use gcore it fails

Re: New warnings from WITNESS

On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote: > bus_dmamap_create with the following non-sleepable locks held: > exclusive sleep mutex mpt (mpt) r = 0 (0xfee2f008) locked @ > dev/mpt/mpt.c:2287 > stack backtrace: > #0 0x80ac0300 at witness_debugger+0x70 > #1

Re: New warnings from WITNESS

On Sun, Nov 06, 2016 at 02:17:45PM +0100, Michael Tuexen wrote: > > On 6 Nov 2016, at 13:28, Konstantin Belousov <kostik...@gmail.com> wrote: > > > > On Sun, Nov 06, 2016 at 12:50:12PM +0100, Michael Tuexen wrote: > >> bus_dmamap_create with the following non-sle

Re: asio and kqueue (2nd trye) (was: RE: (boost::)asio and kqueue problem)

On Fri, Oct 14, 2016 at 09:21:52AM +, hartmut.bra...@dlr.de wrote: > Hi all, > > here is the 2nd try taking into account the comments I received. Since I'm > not familiar with the locking in the sockets area I ask somebody with that > knowledge to check it before I commit it. I have only

Re: SVN r307866 compilation problem

On Mon, Oct 24, 2016 at 02:58:43PM -0400, Michael Butler wrote: > It seems that compilation of -current fails in the case that KDB is not > defined. > > I'm assuming that the following diff achieves what was intended: > > imb@vm01:/usr/src/sys/x86/x86> svn diff > Index: cpu_machdep.c >

Re: r307877: buildkernel fails: x86/cpu_machdep.c:564:1: error: function definition is not allowed here {

On Mon, Oct 24, 2016 at 10:01:48PM +0200, Hartmann, O. wrote: > r307877 fails to buildkernel with the error shown below: > > [...] > /usr/src/sys/x86/x86/cpu_machdep.c:564:1: error: function definition is > not allowed here { > ^ > /usr/src/sys/x86/x86/cpu_machdep.c:574:2: error: expected '}' > }

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting..

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > I am try to enable NUMA in bios and can't boot FreeBSD. > Boot stoped after next messages: > > === > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb So at least the hammer_time() has a chance to initialize

Re: NFSv4 performance degradation with 12.0-CURRENT client

On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: > I have a FreeBSD 10.3-RELEASE-p12 server exporting its home > directories over both NFSv3 and NFSv4. I have a TrueOS client (based > on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) > mounting the home directories over

Re: NFSv4 performance degradation with 12.0-CURRENT client

On Thu, Nov 24, 2016 at 11:42:41AM -0700, Alan Somers wrote: > On Thu, Nov 24, 2016 at 5:53 AM, Rick Macklem wrote: > > > > On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: > >> I have a FreeBSD 10.3-RELEASE-p12 server exporting its home > >> directories over

Re: NFSv4 performance degradation with 12.0-CURRENT client

On Thu, Nov 24, 2016 at 10:45:51PM +, Rick Macklem wrote: > asom...@gmail.com wrote: > >OpenOwner Opens LockOwner LocksDelegs LocalOwn LocalOpen > >LocalLOwn > > 5638141453 0 0 0 0 0 > > 0 > Ok, I think this shows us the

Re: NFSv4 performance degradation with 12.0-CURRENT client

On Fri, Nov 25, 2016 at 12:54:07PM +, Rick Macklem wrote: > Well, ideally theer would be a VOP_MMAPDONE() or something like that, which > would tell the NFSv4 client that I/O is done on the vnode so it can close it. > If there was some way for the NFSv4 VOP_CLOSE() to be able to tell if the

Re: NFSv4 performance degradation with 12.0-CURRENT client

On Sat, Nov 26, 2016 at 11:19:19PM +, Rick Macklem wrote: > Konstantin Belousov wrote: > [stuff snipped] > >I thought that the issue was in tracking any opens and mmaps, but from this > >reply it is not that clear. Do you need callback when all opens and mmaps > >h

Re: make delete-old: sticky remants: mqtest3,

On Tue, Oct 11, 2016 at 05:44:19PM +0200, O. Hartmann wrote: > The following files are sticky on my CURRENT (FreeBSD 12.0-CURRENT #5 > r307003: Mon Oct 10 > 21:28:55 CEST 2016), sources as of revision 307042. Performing "make > delete-old" > in /usr/src seem to kill them in one round after make

Re: options EFIRT: immediate crash of CURRENT

On Sat, Oct 15, 2016 at 02:00:59PM +0200, Hartmann, O. wrote: > > Playing around with some EFI related options and putting > > options EFIRT > > into the kernel config, results in an immediate crash after booting, > see screenshot attached. > > This happens on non-EFI booting systems as well

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Tue, Dec 13, 2016 at 08:43:45PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > > > This is not what I expected. > > Also, I realized that I mis-read the memory test code. It does not > > obliterate memory,

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Wed, Dec 14, 2016 at 01:52:11PM +0300, Slawa Olhovchenkov wrote: > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base= len=00099c00 > SMAP type=02 base=00099c00 len=6400 > SMAP type=02 base=000e

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Wed, Dec 14, 2016 at 11:53:50AM +0200, Konstantin Belousov wrote: > On Tue, Dec 13, 2016 at 08:43:45PM +0300, Slawa Olhovchenkov wrote: > > On Tue, Dec 13, 2016 at 07:25:29PM +0200, Konstantin Belousov wrote: > > > > > This is not what I expected. > > >

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > In other words, it is almost certainly the hang and not a fault causing > > hang. This means that the machine is not compl

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Thu, Dec 15, 2016 at 04:16:24PM +0300, Slawa Olhovchenkov wrote: > On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote: > > > On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Kons

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Tue, Dec 13, 2016 at 02:14:37PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 01:05:35PM +0200, Konstantin Belousov wrote: > > > On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Dec 12, 2016 at 04:20:33PM -

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Tue, Dec 13, 2016 at 02:37:14AM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 04:20:33PM -0600, A. Wilcox wrote: > > > Try the debugging patch below, which unconditionally disables import of > > previous buffer. To test, you would need to boot, then frob options in > >

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Tue, Dec 13, 2016 at 05:34:01PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 05:11:14PM +0300, Slawa Olhovchenkov wrote: > > > On Tue, Dec 13, 2016 at 03:57:59PM +0200, Konstantin Belousov wrote: > > > > > On Tue, Dec 13, 2016 at 03:49:32PM +030

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Tue, Dec 13, 2016 at 03:49:32PM +0300, Slawa Olhovchenkov wrote: > > Boot with NUMA enabled and interleave off. > > Already with patched kernel > > > Patch kernel with the 'if (1 || ...)' patch. > > Reboot, enter BIOS setup and enable interleave there. > > Try to boot - does it boot ? > >

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > Booting... > ESC[01;00H8+0x8+0xe9bdc] > KDB: debugger backends: ddb > KDB: current backend: ddb > exit from kdb_init > KDB: enter: Boot flags requested debugger >

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Tue, Dec 13, 2016 at 06:28:38PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 13, 2016 at 05:01:39PM +0200, Konstantin Belousov wrote: > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base= len=00099c00 > SMAP type=02 base=0

Re: DRM_I915_GEM_OBJECT_MAX_PIN_COUNT failure on -current

On Tue, Dec 13, 2016 at 11:49:37AM -0500, Michael Butler wrote: > I've been bitten by this twice on a KDE desktop in the last 24 hours .. > same error on both occasions :-( > > error: [drm:pid1197:i915_gem_object_pin] *ERROR* WARN ON: obj->pin_count > == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT > pid

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 03:13:36PM +0300, Slawa Olhovchenkov wrote: > > > On Wed, Dec 14, 2016 at 01:39:27PM +0200, Konstantin Belousov wrote: > > > > > In other words, it is almost certainly the h

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Wed, Dec 14, 2016 at 10:29:43PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > On Wed, Dec 14, 2016 at 06:26:27PM +0300, Slawa Olhovchenkov wrote: > > > For test hardware setup (NUMA+interleave), what

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote: > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote: > > > So my opinion did not changed, this sounds like firmware problem. > > I do not see how can I drill into it more. > > I am d

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Konstantin Belousov wrote: > > > On Sun, Dec 11, 2016 at 11:47:09PM +0300, Slawa Olhovchenkov wrote: > > > Booting... > >

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Konstantin Belousov wrote: > > > On Mon, Dec 12, 2016 at 07:21:53PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Dec 12, 2016 at 04:54:18PM +0200, Kons

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Mon, Dec 12, 2016 at 08:43:11PM +0300, Slawa Olhovchenkov wrote: > On Mon, Dec 12, 2016 at 07:24:18PM +0200, Konstantin Belousov wrote: > > > On Mon, Dec 12, 2016 at 08:16:34PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Dec 12, 2016 at 06:54:57PM +0200, Kons

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Slawa Olhovchenkov wrote: > > > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > > > On Sat, Nov 26, 2016 at 12:21:24PM +030

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Sun, Dec 11, 2016 at 10:45:59PM +0300, Slawa Olhovchenkov wrote: > On Sun, Dec 11, 2016 at 09:26:56PM +0200, Konstantin Belousov wrote: > > > On Sun, Dec 11, 2016 at 10:16:26PM +0300, Slawa Olhovchenkov wrote: > > > On Sun, Dec 11, 2016 at 09:21:11PM +0300, Sla

Re: TSC as timecounter makes system lag

On Fri, Jan 13, 2017 at 08:26:04AM +0800, Jia-Shiun Li wrote: > Hi all, > > since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium > T4200 notebook lagged a lot. System time was running a lot slower, > sometimes even looked like it freezed. Keystroke repeat rate was slow too. >

Re: ABI differences between stable/10 and head?

On Fri, Jan 06, 2017 at 09:54:50AM -0500, Kurt Lidl wrote: > Yesterday, I upgraded the kernel on my sparc64 to -head, > so I was running a mis-matched kernel and userland. > The userland was a recent (as of two days ago) stable/10. > > In the nightly report, I noticed the following: > > >

Re: unkillable firefox

On Wed, Dec 28, 2016 at 03:24:39PM -0800, Steve Kargl wrote: > Patch results in a panic when I start X server. > > Fatal trap 12: page fault while in kernel mode > cpuid = 7; apic id = 17 > fault virtual address = 0x30 > fault code = supervisor read data, page not present >

Re: How many CPU cores does FreeBSD support?

On Thu, Jan 05, 2017 at 01:23:55AM +, Eric Joyner wrote: > I started off with a snapshot of 12-CURRENT, but I got a kernel panic on > boot that complained about a duplicate local APIC ID. For now, disabling > Hyper Threading gets rid of that panic. I think there's a KASSERT that > wasn't

Re: How many CPU cores does FreeBSD support?

On Wed, Jan 04, 2017 at 06:53:23PM +, Eric Joyner wrote: > Adding freebsd-current, because that's a good idea. > > I see these lines in the beginning of dmesg: > > MADT: Ignoring local APIC ID 256 (too high) > > > [907/911] > MADT: Ignoring local APIC ID 260 (too high) > > >

Re: Enabling NUMA in BIOS stop booting FreeBSD

On Tue, Dec 20, 2016 at 04:49:29PM -0500, Steve Wills wrote: > Hi, > > On 12/16/2016 16:20, John Baldwin wrote: > > On Thursday, December 15, 2016 03:57:58 PM Adrian Chadd wrote: > >> heh, an updated BIOS that solves the problem will solve the problem. :) > >> > >> I think you have enough

Re: unkillable firefox

On Wed, Dec 28, 2016 at 12:54:53PM -0800, Steve Kargl wrote: > On Tue, Dec 20, 2016 at 01:29:20PM -0800, Steve Kargl wrote: > > Anyone know how to kill firefox? > > > > last pid: 69652; load averages: 0.49, 0.27, 0.24 up 1+02:40:06 > > 13:16:02 > > 126 processes: 1 running, 121

Re: Mozilla firefox freezes/zombie on FreeBSD current

On Mon, Dec 26, 2016 at 10:29:33PM +0300, Subbsd wrote: > Hi, > > On recent FreeBSD version (tested on two host: one from > svn://svn.freebsd.org/base/head ( r310507 now) and second from > https://github.com/FreeBSDDesktop/freebsd-base-graphics.git / > drm-next-4.7 ) and latest firefox (

Re: process killed: text file modification

On Tue, Mar 21, 2017 at 02:30:38AM +, Rick Macklem wrote: > Konstantin Belousov wrote: > [stuff snipped] > > Yes, I have to somewhat retract my claims, but then I have another set > > of surprises. > Righto. > > > I realized (remembered) that nfs has

Re: process killed: text file modification

On Thu, Mar 23, 2017 at 09:39:00PM +, Rick Macklem wrote: > Try whatever you like. However, if the case that failed before doesn't fail > now, > I'd call the test a success. > > Thanks, rick > ps: It looks like Kostik is going to work on converting the NFS > vop_putpages() to > using

Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

On Fri, Mar 24, 2017 at 05:40:15PM +, Darren wrote: > I am getting this panic every hour to every couple of hours. > > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 > 14:56:45 EDT 2017 darren@asrock:/usr/obj/usr/src/sys/GENERIC  amd64 > I manually typed out the

Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

On Fri, Mar 24, 2017 at 08:31:42PM -0700, Gleb Smirnoff wrote: > Darren, > > On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote: > K> On Fri, Mar 24, 2017 at 05:40:15PM +, Darren wrote: > K> > I am getting this panic every hour to every coup

Re: process killed: text file modification

On Thu, Mar 23, 2017 at 12:55:09AM +, Rick Macklem wrote: > Wow, this is looking good to me. I had thought that the simple way to make > ncl_putpages() go through the buffer cache was to replace ncl_writerpc() with > VOP_WRITE(). My concern was all the memory<->memory copying that would > go

Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3

On Sun, Mar 19, 2017 at 04:58:40PM +0100, Dimitry Andric wrote: > On 19 Mar 2017, at 13:36, Rozhuk Ivan wrote: > > > > On Fri, 17 Mar 2017 17:53:24 +0100 > > "O. Hartmann" wrote: > > > >>> Other OS detect AES-NI on this server? > >> > >> I havn't

Re: r314708: panic: tdsendsignal: ksi on queue

On Fri, Mar 17, 2017 at 11:26:43AM -0700, Bryan Drewery wrote: > On 3/10/2017 2:44 AM, Konstantin Belousov wrote: > > On Fri, Mar 10, 2017 at 12:11:51AM +0100, Jilles Tjoelker wrote: > >> This patch introduces a subtle correctness bug. A real SIGCHLD ksiginfo > >> sh

Re: process killed: text file modification

On Fri, Mar 17, 2017 at 09:23:00PM +, Rick Macklem wrote: > Dimitry Andric wrote: > >On 17 Mar 2017, at 15:19, Konstantin Belousov <kostik...@gmail.com> wrote: > >> > >> On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote: > >>> Well, I do

Re: process killed: text file modification

On Sun, Mar 19, 2017 at 08:52:50PM +, Rick Macklem wrote: > Kostik wrote: > [stuff snipped] > >> >> Dirty pages are flushed by writes, so if we have a set of dirty pages > >> >> and > >> >> async vm_object_page_clean() is called on the vnode' vm_object, we get > >> >> a bunch of delayed-write

Re: process killed: text file modification

On Fri, Mar 17, 2017 at 03:10:57AM +, Rick Macklem wrote: > Hope you don't mind a top post... > Attached is a little patch you could test maybe? > > rick > > From: owner-freebsd-curr...@freebsd.org > on behalf of

Re: process killed: text file modification

On Fri, Mar 17, 2017 at 01:53:46PM +, Rick Macklem wrote: > Well, I don't mind adding ncl_flush(), but it shouldn't be > necessary. I actually had it in the first > rendition of the patch, but took it out because it should happen > on the VOP_CLOSE() if any writing to the buffer cache happened

Re: process killed: text file modification

On Tue, Mar 21, 2017 at 09:41:19PM +, Rick Macklem wrote: > Konstantin Belousov wrote: > > Anyway, my position is that nfs VOP_PUTPAGES() should do write through > > buffer cache, not issuing the direct rpc call with the pages as source. > Hmm. Interesting idea. Since a &qu

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

On Sat, Apr 15, 2017 at 11:18:41AM +0200, O. Hartmann wrote: > Am Fri, 14 Apr 2017 20:18:57 +0300 > Konstantin Belousov <kostik...@gmail.com> schrieb: > > > On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote: > > > Fatal trap 12: page fault while in kernel

64-bit inodes (ino64) Status Update and Call for Testing

Inodes are data structures corresponding to objects in a file system, such as files and directories. FreeBSD has historically used 32-bit values to identify inodes, which limits file systems to somewhat under 2^32 objects. Many modern file systems internally use 64-bit identifiers and FreeBSD

Re: process killed: text file modification

On Mon, Apr 17, 2017 at 12:56:43AM +0800, Julian Elischer wrote: > On 13/4/17 5:45 am, Rick Macklem wrote: > > I have just committed a patch to head (r316745) which should fix this. > > (It includes code to handle the recent change to head to make the pageouts > > write through the buffer

Re: hang in dlclose() on rtld lock (powerpc64)

On Thu, Mar 09, 2017 at 09:59:00AM -0600, Justin Hibbits wrote: > When building ports in poudriere, I see gdk-pixbuf-query-modules and > gio-querymodules hanging on r314676, but working in r305820. I took a > backtrace on both in gdb, and see the following (identical between both): > > Program

Re: r314708: panic: tdsendsignal: ksi on queue

On Wed, Mar 08, 2017 at 09:00:17PM -0800, Bryan Drewery wrote: > I'm on r314708. I hit ^C while running 'kyua test' in /usr/tests/bin/pwait. > > > panic: tdsendsignal: ksi on queue > > cpuid = 10 > > > #10 kdb_enter (why=0x814488f5 "panic", msg=) at > > /usr/src/sys/kern/subr_kdb.c:444

Re: r314708: panic: tdsendsignal: ksi on queue

On Fri, Mar 10, 2017 at 12:11:51AM +0100, Jilles Tjoelker wrote: > This patch introduces a subtle correctness bug. A real SIGCHLD ksiginfo > should always be the zombie's p_ksi; otherwise, the siginfo may be lost > if there are too many signals pending for the target process or in the > system. If

Re: smp_rendezvous_action: Are atomics correctly used ?

On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > I have the save question for the cpu_ipi_pending here: > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotate#l1080 > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > Hello, > > > > I'm

Re: smp_rendezvous_action: Are atomics correctly used ?

On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > I have the save question for the cpu_ipi_pending here:

Re: smp_rendezvous_action: Are atomics correctly used ?

On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > >

Re: smp_rendezvous_action: Are atomics correctly used ?

On Fri, Mar 10, 2017 at 04:23:02PM +0100, Alexandre Martins wrote: > Le vendredi 10 mars 2017, 16:46:26 Konstantin Belousov a ?crit : > > On Fri, Mar 10, 2017 at 03:30:21PM +0100, Alexandre Martins wrote: > > > Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a ?crit : >

Re: smp_rendezvous_action: Are atomics correctly used ?

On Fri, Mar 10, 2017 at 03:30:21PM +0100, Alexandre Martins wrote: > Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a ?crit : > > On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > > > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : >

Re: HEADSUP: after r313194 on freebsd-current, lang/gcc ports require a rebuild

On Tue, Feb 28, 2017 at 11:42:48AM -0800, Steve Kargl wrote: > r313194 defined vm_ooffset_t and vm_pindex_t in sys/types.h. > I believe that forces a recompile of lang/gcc ports, and > probably anything built with the lang/gcc port to avoid > dependency issue. Neither "pkg audit -q" nor "pkg

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0xf8001282fb00 > fault code = supervisor read instruction, protection violation > ??() at 0xf8001282fb00 >

Re: type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

On Sun, Jul 09, 2017 at 11:15:18PM -0300, Otac??lio wrote: > Dears > > I'm the maintainer of xosview and I'm debugging rather weird behavior > from it in the latest FreeBSD 12 revisions (12.0-CURRENT #0 r320730 > AMD64) . The problem is occurring on the lines responsible for > collecting

Re: type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

On Mon, Jul 10, 2017 at 06:45:28PM +0900, Tomoaki AOKI wrote: > Hm, for example, sysutils/lsof (userspace app) depends on kernel > source, and I thought the one Otacilio mentioned is something like it. lsof purpose is to dig into a kernel memory to gather information about the process state and

Re: type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

On Mon, Jul 10, 2017 at 03:40:46PM +0900, Tomoaki AOKI wrote: > Hi. > > Members v_swappgsin and v_vnodepgsin are declared on sys/sys/vmmeter.h > as > > u_int on stable/11@r320798 [1] > counter_u64_t on head@r320861 [2] > > respectively. > > Diggin in further, on head@r320861,

Re: type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

On Mon, Jul 10, 2017 at 10:51:43AM -0300, Otac??lio wrote: > Em 10/07/2017 06:49, Konstantin Belousov escreveu: > > On Mon, Jul 10, 2017 at 06:45:28PM +0900, Tomoaki AOKI wrote: > >> Hm, for example, sysutils/lsof (userspace app) depends on kernel > >> source, and

Re: [bmake] bmake sigint handling causing tty corruption

On Tue, Jul 18, 2017 at 11:57:00PM +0300, Dmitry Marakasov wrote: > Hi! > > Me and Ilya Arkhipov were investigating the cause of this bug: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215572 > > In short, when FreeBSD ports options dialog is interrupted by Ctrl+C, > there's chance of

Re: column regression after https://svnweb.freebsd.org/base?view=revision=r320472

On Fri, Jun 30, 2017 at 09:34:42PM +0300, Oleg Ginzburg wrote: > Hi, > > This commit https://svnweb.freebsd.org/base?view=revision=r320472 > breaks column(1) (and can affect something else this way ). Try to execute > sample from man r320472: > > ( printf "PERM LINKS OWNER GROUP SIZE MONTH DAY

Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__

On Sat, Jul 01, 2017 at 07:42:11PM -0700, Mark Millard wrote: > powerpc64 is having programs crash with an attempt > to store addresses over code instead of into > __cleanup_info__ when fgets is used. ntpd is an > example. As is sshd (although I've looked at > its details less). Yes, I think you

Re: Reproducible panic with MAP_GUARD and security.bsd.stack_guard_page > 1

On Sat, Jul 01, 2017 at 01:28:47PM -0400, Shawn Webb wrote: > When running my Stack Clash PoC on a vanilla FreeBSD 12-CURRENT/amd64 VM > and security.bsd.stack_guard_page is > 1: > > https://goo.gl/photos/vZQY4B9jKJRLrNwP7 > > The PoC doesn't need to be run as root on vanilla FreeBSD with a

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: > One nasty problem with this is that it is not possible to figure out at > compile time what the size of time_t is. You always need some sort of > configure-time test, and an external define. It is arguably possible, with

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 08:17:38AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > > ... > > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > > > object directories. > > >

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 09:07:03AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 06:34:42PM +0300, Konstantin Belousov wrote: > > ... > > > Bisection time? Or if there's another approach (or even a suggestion > > > for a revision to try first), I'm up f

Re: regression suspend/resume on Lenovo T420

On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote: > > In message <20170514193006.GA1298@brick>, Edward Tomasz > =?utf-8?Q?Napiera=C5=82 > a?= writes: > > >I've tried to verify that, and sadly it wasn't it for me. The commit > >that does break resume for me is r316767.

Re: regression suspend/resume on Lenovo T420

On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote: > On 15 May 2017, at 7:26, Konstantin Belousov wrote: > > > > Try this. If it works, I will write a proper patch. > > > > diff --git a/sys/amd64/amd64/cpu_switch.S > > b/sys/amd64/amd64/c

Re: regression suspend/resume on Lenovo T420

On Mon, May 15, 2017 at 06:37:58PM +0100, Edward Tomasz Napiera??a wrote: > Thanks! The patch fixes resume for me, for both vt(4) and X11. Thanks everybody for testing, patch below should be committable, modulo bugs. I did not tested it and ask for the same test as the previous debugging patch.

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > New world and kernel r320323 > I get a new error or message when using ruby: > > > /usr/local/sbin/portupgrade -av > : warning: pthread_create failed for timer: Resource temporarily > unavailable, scheduling broken > >

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 05:28:24AM -0700, David Wolfskill wrote: > On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote: > > On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > > > KLD geom_eli.ko: depends on kernel - not available o

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > KLD geom_eli.ko: depends on kernel - not available or version mismatch > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type > swapon: /dev/ada0s4b.eli: Invalid parameters Again remove all kernel build files and try

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a fatal > trap 12, but

Re: Current amd64 new error or warning from today's current with ruby r320323

On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov <kostik...@gmail.com> > wrote: > > > No need, I understood why MAP_STACK failed in this case, thanks to the > > ktrace log. This is indeed somethi

Re: Current amd64 new error or warning from today's current with ruby r320323

On Mon, Jun 26, 2017 at 01:34:35PM -0700, Benno Rice wrote: > > > On Jun 26, 2017, at 13:25, Konstantin Belousov <kostik...@gmail.com> wrote: > > > > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > >> On Sun, Jun 25, 2017 at 11:41 AM, Kons

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

On Sun, Jun 25, 2017 at 05:47:48AM -0700, David Wolfskill wrote: > On Sun, Jun 25, 2017 at 03:32:26PM +0300, Konstantin Belousov wrote: > > On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote: > > > Fatal trap 12: page fault while in kernel mode > > &

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

On Sun, Jun 25, 2017 at 06:05:21AM -0700, David Wolfskill wrote: > On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote: > > ... > > > > The layout of the struct vm_map_entry was changed, the faulted address > > > > is somewhat consistent with

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov <kostik...@gmail.com> > > wrote: > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > >> maybe message got reformat

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote: > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov <kostik...@gmail.com> > > wrote: > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > >> > >>> On

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x120 This is clearly an impossible address. Did you built the kernel with NO_CLEAN ? If yes, try the full build,

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote: > > > On Jun 24, 2017, at 6:23 PM, Konstantin Belousov <kostik...@gmail.com> > > wrote: > > > > On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote: > >> New world and kernel r320

<    3   4   5   6   7   8   9   10   11   12   >