Re: drm2, i915kms cause instant lock-up
On Tue, Feb 21, 2017 at 10:29:43PM -0800, Steve Kargl wrote: > On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote: > > > Well, I found the guilty commit. r313934 breaks loading > > > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop. > > > details below. > > > > > > I'll also note that starting at r313902 or so, after > > > loading i915kms.ko console output on vt is slooow. > > > A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user, > > > and 1.08 sys, but the drawing on screen takes more than > > > 30 seconds. One can painfully watch each line of output > > > be rastered across the screen. > > > > > > Kib you can read the details below. If you need more info, > > > ping me. I did notice that i686_mem.c used constants of the > > > form 0xULL prior to the merge into x86_mem.c. You now > > > use 0xfffUL. I have no idea whether this is related to > > > cause. > > > > Well, yes, I found two instances more of such bugs, one seems to be > > innocent, > > and another might be the issue. Please try this on top of r313934 or > > the latest HEAD. > > (patch delete) > > At -r313934 + patch seems to fix the hang on loading i915kms.ko and > also the slw output to vt. Thanks for the quick response. I'll > update to top of tree to check that there isn't any other problems. > A kernel and modules from top of tree works as expected. Thanks for the fix. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2, i915kms cause instant lock-up
On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote:
> On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> > Well, I found the guilty commit. r313934 breaks loading
> > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop.
> > details below.
> >
> > I'll also note that starting at r313902 or so, after
> > loading i915kms.ko console output on vt is slooow.
> > A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user,
> > and 1.08 sys, but the drawing on screen takes more than
> > 30 seconds. One can painfully watch each line of output
> > be rastered across the screen.
> >
> > Kib you can read the details below. If you need more info,
> > ping me. I did notice that i686_mem.c used constants of the
> > form 0xULL prior to the merge into x86_mem.c. You now
> > use 0xfffUL. I have no idea whether this is related to
> > cause.
>
> Well, yes, I found two instances more of such bugs, one seems to be innocent,
> and another might be the issue. Please try this on top of r313934 or
> the latest HEAD.
>
> diff --git a/sys/x86/x86/x86_mem.c b/sys/x86/x86/x86_mem.c
> index 8e93883863a..d639224f840 100644
> --- a/sys/x86/x86/x86_mem.c
> +++ b/sys/x86/x86/x86_mem.c
> @@ -260,7 +260,7 @@ x86_mrfetch(struct mem_range_softc *sc)
>
> /* Compute the range from the mask. Ick. */
> mrd->mr_len = (~(msrv & mtrr_physmask) &
> - (mtrr_physmask | 0xfffL)) + 1;
> + (mtrr_physmask | 0xfffLL)) + 1;
> if (!mrvalid(mrd->mr_base, mrd->mr_len))
> mrd->mr_flags |= MDF_BOGUS;
>
> @@ -638,7 +638,7 @@ x86_mrinit(struct mem_range_softc *sc)
>* Determine the size of the PhysMask and PhysBase fields in
>* the variable range MTRRs.
>*/
> - mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffUL;
> + mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffULL;
>
> /* If fixed MTRRs supported and enabled. */
> if ((mtrrcap & MTRR_CAP_FIXED) && (mtrrdef & MTRR_DEF_FIXED_ENABLE)) {
At -r313934 + patch seems to fix the hang on loading i915kms.ko and
also the slw output to vt. Thanks for the quick response. I'll
update to top of tree to check that there isn't any other problems.
--
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2, i915kms cause instant lock-up
On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> Well, I found the guilty commit. r313934 breaks loading
> either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop.
> details below.
>
> I'll also note that starting at r313902 or so, after
> loading i915kms.ko console output on vt is slooow.
> A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user,
> and 1.08 sys, but the drawing on screen takes more than
> 30 seconds. One can painfully watch each line of output
> be rastered across the screen.
>
> Kib you can read the details below. If you need more info,
> ping me. I did notice that i686_mem.c used constants of the
> form 0xULL prior to the merge into x86_mem.c. You now
> use 0xfffUL. I have no idea whether this is related to
> cause.
Well, yes, I found two instances more of such bugs, one seems to be innocent,
and another might be the issue. Please try this on top of r313934 or
the latest HEAD.
diff --git a/sys/x86/x86/x86_mem.c b/sys/x86/x86/x86_mem.c
index 8e93883863a..d639224f840 100644
--- a/sys/x86/x86/x86_mem.c
+++ b/sys/x86/x86/x86_mem.c
@@ -260,7 +260,7 @@ x86_mrfetch(struct mem_range_softc *sc)
/* Compute the range from the mask. Ick. */
mrd->mr_len = (~(msrv & mtrr_physmask) &
- (mtrr_physmask | 0xfffL)) + 1;
+ (mtrr_physmask | 0xfffLL)) + 1;
if (!mrvalid(mrd->mr_base, mrd->mr_len))
mrd->mr_flags |= MDF_BOGUS;
@@ -638,7 +638,7 @@ x86_mrinit(struct mem_range_softc *sc)
* Determine the size of the PhysMask and PhysBase fields in
* the variable range MTRRs.
*/
- mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffUL;
+ mtrr_physmask = (((uint64_t)1 << cpu_maxphyaddr) - 1) & ~0xfffULL;
/* If fixed MTRRs supported and enabled. */
if ((mtrrcap & MTRR_CAP_FIXED) && (mtrrdef & MTRR_DEF_FIXED_ENABLE)) {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2, i915kms cause instant lock-up
On Tue, Feb 21, 2017 at 09:37:41PM -0800, Steve Kargl wrote: > On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote: > > > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > > > > > > > Well, the good news seems to be that r313254 and older are 'ok'. > > > > So, something between r313943 and r313254 is triggering a the > > > > problem. I'm still bisecting, but it might take a day or two. > > > > > > > > > > I've been able to narrow the range down to r313854 to r313943. > > > If I had to guess, the issue may be related to > > > > > > Author: kib > > > Date: Fri Feb 17 21:08:32 2017 > > > New Revision: 313898 > > > URL: https://svnweb.freebsd.org/changeset/base/313898 > > > > > > Log: > > > Merge i386 and amd64 mtrr drivers. > > > > > > I won't be able to investigate until later tonight (~ 10 hours from now). > > > > >From what I see in other messages, you are using i386 kernel on Core2 > > class machine, am I right ? Did r313897 worked fine ? Re-reading your email, I noticed you asked about r313897. I'll rebuild the kernel at this revision and r313898 and get back to to you. Yes, it is i386 on a core2 system. : FreeBSD 12.0-CURRENT #20 r313931: Tue Feb 21 21:02:18 PST 2017 root@laptop-kargl:/mnt/obj/mnt/src/sys/MOBILE i386 FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) VT(vga): text 80x25 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2000 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE > > > > r313898 has a bug for i386 architecture, which was fixed in r313934. > > Could you compile kernel from r313898 sources with r313934 applied on > > top of it ? I mean, take r313898 and apply the changes from r313934 > > either manually or with patch, but not take any further changes from > > svn after r313898. > > > > I just completed the bisection. r313934 is the problem. > 'svn update -r 313933' boots and I can load drm2.ko. > 'svn update -r 313934' boots and hangs on loading the > module. > > As I noted in another reply I just sent, around -r313902 > I can load the i915kms.ko but console output to vt is slw. > Perhaps, a locking issue that 313934 exacerbated. > > -- > Steve > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2, i915kms cause instant lock-up
On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote: > > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > > > > > Well, the good news seems to be that r313254 and older are 'ok'. > > > So, something between r313943 and r313254 is triggering a the > > > problem. I'm still bisecting, but it might take a day or two. > > > > > > > I've been able to narrow the range down to r313854 to r313943. > > If I had to guess, the issue may be related to > > > > Author: kib > > Date: Fri Feb 17 21:08:32 2017 > > New Revision: 313898 > > URL: https://svnweb.freebsd.org/changeset/base/313898 > > > > Log: > > Merge i386 and amd64 mtrr drivers. > > > > I won't be able to investigate until later tonight (~ 10 hours from now). > > >From what I see in other messages, you are using i386 kernel on Core2 > class machine, am I right ? Did r313897 worked fine ? > > r313898 has a bug for i386 architecture, which was fixed in r313934. > Could you compile kernel from r313898 sources with r313934 applied on > top of it ? I mean, take r313898 and apply the changes from r313934 > either manually or with patch, but not take any further changes from > svn after r313898. > I just completed the bisection. r313934 is the problem. 'svn update -r 313933' boots and I can load drm2.ko. 'svn update -r 313934' boots and hangs on loading the module. As I noted in another reply I just sent, around -r313902 I can load the i915kms.ko but console output to vt is slw. Perhaps, a locking issue that 313934 exacerbated. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2, i915kms cause instant lock-up
Well, I found the guilty commit. r313934 breaks loading either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop. details below. I'll also note that starting at r313902 or so, after loading i915kms.ko console output on vt is slooow. A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user, and 1.08 sys, but the drawing on screen takes more than 30 seconds. One can painfully watch each line of output be rastered across the screen. Kib you can read the details below. If you need more info, ping me. I did notice that i686_mem.c used constants of the form 0xULL prior to the merge into x86_mem.c. You now use 0xfffUL. I have no idea whether this is related to cause. -- steve On Mon, Feb 20, 2017 at 03:52:24PM -0800, Steve Kargl wrote: > With a kernel and world from r313943 sources (circa > Feb 19, 2017), kldload of either drm2.ko or i915kms.ko > will lock up the system. There is no keyboard response, > screen output, or panic. Just a locked up system. > > A kernel from r313027 and its modules boots fine. > 'kldload drm2.ko' yields the following in /var/log/messages: > > agp0: on vgapci0 > agp0: aperture size is 256M, detected 7676k stolen memory > info: [drm] Initialized drm 1.1.0 20060810 > > 'kldload drm2.ko' yields the following in /var/log/messages: > drmn0: on vgapci0 > intel_iicbb0 on drmn0 > iicbus0: on iicbb0 addr 0xf2 > iic0: on iicbus0 > iicbus1: on intel_gmbus0 > iic1: on iicbus1 > intel_iicbb1 on drmn0 > iicbus2: on iicbb1 addr 0xf2 > iic2: on iicbus2 > iicbus3: on intel_gmbus1 > iic3: on iicbus3 > intel_iicbb2 on drmn0 > iicbus4: on iicbb2 addr 0xf2 > iic4: on iicbus4 > iicbus5: on intel_gmbus2 > iic5: on iicbus5 > intel_iicbb3 on drmn0 > iicbus6: on iicbb3 addr 0xf2 > iic6: on iicbus6 > iicbus7: on intel_gmbus3 > iic7: on iicbus7 > intel_iicbb4 on drmn0 > iicbus8: on iicbb4 addr 0xf2 > iic8: on iicbus8 > iicbus9: on intel_gmbus4 > iic9: on iicbus9 > intel_iicbb5 on drmn0 > iicbus10: on iicbb5 addr 0xf2 > iic10: on iicbus10 > iicbus11: on intel_gmbus5 > iic11: on iicbus11 > info: [drm] MSI enabled 1 message(s) > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > composite sync not supported > intel_sdvo_ddc_proxy397632 on drmn0 > intel_sdvo_ddc_proxy397632: detached > intel_sdvo_ddc_proxy397664 on drmn0 > intel_sdvo_ddc_proxy397664: detached > drmn0: taking over the fictitious range 0xe000-0xf000 > info: [drm] initialized overlay support > info: [drm] Connector LVDS-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.LVDS-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector VGA-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.VGA-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector SVIDEO-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.SVIDEO-1 > info: [drm] - kern.vt.fb.default_mode > composite sync not supported > fbd0 on drmn0 > VT: Replacing driver "vga" with new "fb". > info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > > A diff of dmesg.boot for the good kernel and bad kernel shows > > --- /root/dmesg.good 2017-02-20 13:30:06.707702000 -0800 > +++ /root/dmesg.bad 2017-02-20 13:42:10.271942000 -0800 > @@ -2,11 +2,11 @@ > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > -FreeBSD 12.0-CURRENT #3 r313027: Mon Feb 20 11:59:15 PST 2017 > +FreeBSD 12.0-CURRENT #1 r313943: Sun Feb 19 09:18:03 PST 2017 > root@laptop-kargl:/mnt/obj/mnt/src/sys/MOBILE i386 > FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM > 3.9.1) > VT(vga): text 80x25 > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class > CPU) > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class > CPU) >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > Features=0xbfebfbff >Features2=0xe3bd > @@ -15,7 +15,7 @@ >VT-x: (disabled in BIOS) HLT,PAUSE >TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > -avail memory = 3663994880 (3494 MB) > +avail memory = 3665018880 (3495 MB) > Event timer "LAPIC" quality 100 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > @@ -24,7 +24,7 @@ > ioapic0 irqs 0-23 on motherboard > random: entropy device external interface > kbd1 at kbdmux0 > -module_register_init: MOD_LOAD (vesa, 0xc0bf7440, 0) error 19 > +module_register_init: MOD_LOAD (vesa, 0xc0ae6db0, 0) error 19 > nexus0 > vtvga0: on motherboard > acpi0: on motherboard > @@ -42,7 +42,7 @@ > attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > -Timecounter "ACPI-safe" fre
Re: drm2, i915kms cause instant lock-up
On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote: > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > > > Well, the good news seems to be that r313254 and older are 'ok'. > > So, something between r313943 and r313254 is triggering a the > > problem. I'm still bisecting, but it might take a day or two. > > > > I've been able to narrow the range down to r313854 to r313943. > If I had to guess, the issue may be related to > > Author: kib > Date: Fri Feb 17 21:08:32 2017 > New Revision: 313898 > URL: https://svnweb.freebsd.org/changeset/base/313898 > > Log: > Merge i386 and amd64 mtrr drivers. > > I won't be able to investigate until later tonight (~ 10 hours from now). >From what I see in other messages, you are using i386 kernel on Core2 class machine, am I right ? Did r313897 worked fine ? r313898 has a bug for i386 architecture, which was fixed in r313934. Could you compile kernel from r313898 sources with r313934 applied on top of it ? I mean, take r313898 and apply the changes from r313934 either manually or with patch, but not take any further changes from svn after r313898. If such kernel does not boot, I will provide further instructions. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r313938 breaks portsnap
On Tue, 21 Feb 2017 at 10:44 pm, Vladimir Zakharov wrote: > Hello > > After recent upgrade portsnap doesn't work anymore: > > # portsnap fetch update > Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. > Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. > Fetching snapshot metadata... done. > Updating from Tue Feb 21 16:05:39 MSK 2017 to Tue Feb 21 16:59:30 MSK 2017. > Fetching 5 metadata patches.lam: unable to limit stdio: Capabilities > insufficient > done. > Applying metadata patches... done. > Fetching 5 metadata files... lam: unable to limit stdio: Capabilities > insufficient > /usr/sbin/portsnap: cannot open > 8c94d2c3f8fcea20eb1fd82021566c99c63a010e6b3702ee11e7a491795bcfb8.gz: No > such file or directory > metadata is corrupt. > > Reverting r313938 fixes the problem. As it wasn't immediately clear to me: The r313938 being referred to is the change to base to capsicumize lam(1). https://svnweb.freebsd.org/base?view=revision&revision=313938 Regards, Ben -- -- From: Benjamin Woods woods...@gmail.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: int128_t and uint128_t typeinfo
On 21 Feb 2017, at 18:26, Dimitry Andric wrote: > > On 21 Feb 2017, at 13:48, Hartmut Brandt wrote: >> >> it looks like the typeinfo for __int128_t and __uint128_t is missing from >> our dynamically linked libcxxrt. ... > * We also need to add the typeinfo for __u?int128_t * and __u?int128_t > const * > * Maybe these should be under the CXXABI_2.0 version, since that is > where newer libstdc++ places them > * Maybe these should be dependent on whether the architecture supports > 128 bit integers at all > > I need to think a bit on the above, then I'll commit a fix. Okay, can you please try r314061? -Dimitry signature.asc Description: Message signed with OpenPGP
Re: drm2, i915kms cause instant lock-up
On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > Well, the good news seems to be that r313254 and older are 'ok'. > So, something between r313943 and r313254 is triggering a the > problem. I'm still bisecting, but it might take a day or two. > I've been able to narrow the range down to r313854 to r313943. If I had to guess, the issue may be related to Author: kib Date: Fri Feb 17 21:08:32 2017 New Revision: 313898 URL: https://svnweb.freebsd.org/changeset/base/313898 Log: Merge i386 and amd64 mtrr drivers. I won't be able to investigate until later tonight (~ 10 hours from now). -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: int128_t and uint128_t typeinfo
On 21 Feb 2017, at 13:48, Hartmut Brandt wrote: > > it looks like the typeinfo for __int128_t and __uint128_t is missing from our > dynamically linked libcxxrt. I added it like: > > Index: lib/libcxxrt/Version.map > === > --- lib/libcxxrt/Version.map (revision 313007) > +++ lib/libcxxrt/Version.map (working copy) > @@ -192,6 +192,11 @@ > "typeinfo name for unsigned short"; > "typeinfo name for double"; > > +"typeinfo for __int128"; > +"typeinfo for unsigned __int128"; > +"typeinfo name for __int128"; > +"typeinfo name for unsigned __int128"; > + > "typeinfo name for bool*"; > "typeinfo name for wchar_t*"; > "typeinfo name for short*"; > > I'm not sure whether this is the right place in the file where to add it. > Could somebody please check? Yes, this is the right place, though with a few caveats: * We also need to add the typeinfo for __u?int128_t * and __u?int128_t const * * Maybe these should be under the CXXABI_2.0 version, since that is where newer libstdc++ places them * Maybe these should be dependent on whether the architecture supports 128 bit integers at all I need to think a bit on the above, then I'll commit a fix. -Dimitry P.S.: I'm going to ignore libstdc++ in base, since it is obsolete. signature.asc Description: Message signed with OpenPGP
Re: Laptop very sluggish diring smoke-test @r314036
On Tue, Feb 21, 2017 at 03:45:36PM +0100, Mateusz Guzik wrote: > ... > > stable/11 -- I had been waiting for it to finish the reboot for > > around 5 minutes, watching: "Syncing disks, vnodes remaining ..." > > when the thought of noting the amount of elapsed time between reports > > of the numbers of remaining vnodes occurred to me: it was about 10 > > seconds each. > > > > Normally, it's closer to 2 seconds, if that, IIRC. > > > > In any case, overall behavior seemed fairly consistent with that > > magnitude of a slowdown overall. > > > > Can you check if the problem IS NOT present on r313995 but IS present on > r313996? Only rebuilding the kernel + modules is necessary. > > If the problem was not introduced by r313996 I'm afraid you will have to > bisect. > > -- > Mateusz Guzik Well I "cloned" my head slice (4) to slice 3, updating source on slice 3 to r313995, rebooted to slice 3... and noticed that it didn't seem slugglish at all (unlike the earlier "smoke-test"). So before I did anything else, I rebooted it... and the countdown after "Syncing disks, vnodes remaining..." was about 1 second each. So I'm not sure what happened, but it looks as if I can't (readily) reproduce the symptom. I'll try experimenting a bit more as time permits today (but I actually use the laptop in my day-to-day work, so that may prove challenging). Sorry for the noise. Peace, david -- David H. Wolfskill da...@catwhisker.org How could one possibly "respect" a misogynist, racist, bullying con-man??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
r313938 breaks portsnap
Hello After recent upgrade portsnap doesn't work anymore: # portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Tue Feb 21 16:05:39 MSK 2017 to Tue Feb 21 16:59:30 MSK 2017. Fetching 5 metadata patches.lam: unable to limit stdio: Capabilities insufficient done. Applying metadata patches... done. Fetching 5 metadata files... lam: unable to limit stdio: Capabilities insufficient /usr/sbin/portsnap: cannot open 8c94d2c3f8fcea20eb1fd82021566c99c63a010e6b3702ee11e7a491795bcfb8.gz: No such file or directory metadata is corrupt. Reverting r313938 fixes the problem. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Laptop very sluggish diring smoke-test @r314036
On Tue, Feb 21, 2017 at 06:39:08AM -0800, David Wolfskill wrote: > This morning's daily "head" update & smoke-test was from: > > FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #263 > r313988M/313991:1200021: Mon Feb 20 06:31:32 PST 2017 > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > to > > FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #264 > r314036M/314036:1200021: Tue Feb 21 05:52:20 PST 2017 > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > On reboot, the system was very sluggish; unfortunately, I failed > to try to quantify that until I had already started the reboot to > stable/11 -- I had been waiting for it to finish the reboot for > around 5 minutes, watching: "Syncing disks, vnodes remaining ..." > when the thought of noting the amount of elapsed time between reports > of the numbers of remaining vnodes occurred to me: it was about 10 > seconds each. > > Normally, it's closer to 2 seconds, if that, IIRC. > > In any case, overall behavior seemed fairly consistent with that > magnitude of a slowdown overall. > Can you check if the problem IS NOT present on r313995 but IS present on r313996? Only rebuilding the kernel + modules is necessary. If the problem was not introduced by r313996 I'm afraid you will have to bisect. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Laptop very sluggish diring smoke-test @r314036
This morning's daily "head" update & smoke-test was from: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #263 r313988M/313991:1200021: Mon Feb 20 06:31:32 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 to FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #264 r314036M/314036:1200021: Tue Feb 21 05:52:20 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 On reboot, the system was very sluggish; unfortunately, I failed to try to quantify that until I had already started the reboot to stable/11 -- I had been waiting for it to finish the reboot for around 5 minutes, watching: "Syncing disks, vnodes remaining ..." when the thought of noting the amount of elapsed time between reports of the numbers of remaining vnodes occurred to me: it was about 10 seconds each. Normally, it's closer to 2 seconds, if that, IIRC. In any case, overall behavior seemed fairly consistent with that magnitude of a slowdown overall. Peace, david -- David H. Wolfskill da...@catwhisker.org How could one possibly "respect" a misogynist, racist, bullying con-man??!? See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
int128_t and uint128_t typeinfo
Hi, it looks like the typeinfo for __int128_t and __uint128_t is missing from our dynamically linked libcxxrt. I added it like: Index: lib/libcxxrt/Version.map === --- lib/libcxxrt/Version.map(revision 313007) +++ lib/libcxxrt/Version.map(working copy) @@ -192,6 +192,11 @@ "typeinfo name for unsigned short"; "typeinfo name for double"; +"typeinfo for __int128"; +"typeinfo for unsigned __int128"; +"typeinfo name for __int128"; +"typeinfo name for unsigned __int128"; + "typeinfo name for bool*"; "typeinfo name for wchar_t*"; "typeinfo name for short*"; I'm not sure whether this is the right place in the file where to add it. Could somebody please check? Thanks, harti@ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r313268 - head/sys/kern [through -r313271 for atomic_fcmpset use and later: fails on PowerMac G5 "Quad Core"; -r313266 works]
[Back to the powerpc64 context.] On 2017-Feb-20, at 11:10 AM, Mateusz Guzik wrote: > On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote: >> [Note: I experiment with clang based powerpc64 builds, >> reporting problems that I find. Justin is familiar >> with this, as is Nathan.] >> >> I tried to update the PowerMac G5 (a so-called "Quad Core") >> that I have access to from head -r312761 to -r313864 and >> ended up with random panics and hang ups in fairly short >> order after booting. >> >> Some approximate bisecting for the kernel lead to: >> (sometimes getting part way into a buildkernel attempt >> for a different version before a failure happens) >> >> -r313266: works (just before use of atomic_fcmpset) >> vs. >> -r313271: fails (last of the "use atomic_fcmpset" check-ins) >> >> (I did not try -r313268 through -r313270 as the use was >> gradually added.) >> >> So I'm currently running a -r313864 world with a -r313266 >> kernel. >> >> No kernel that I tried that was from before -r313266 had the >> problems. >> >> Any kernel that I tried that was from after -r313271 had the >> problems. >> >> Of course I did not try them all in other direction. :) >> > > I found that spin mutexes were not properly handling this, fixed in > r313996. > > Locally I added a if (cpu_tick() % 2) return (0); snipped to amd64 > fcmpset to simulate failures. Everything works, while it would easily > fail without the patch. > > That said, I hope this concludes the 'missing check for not-reread value > of failed fcmpset' saga. > > -- > Mateusz Guzik -r313999 is an improvement for powerpc64: it boots and I can log in on the old PowerMac G5 so-called "Quad Core". But, e.g., buildworld buildkernel eventually hangs and later the powerpc64 panics for "spin lock held too long". === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem compiling akonadi
On Tue, 21 Feb 2017 09:00-, Filippo Moretti wrote: > While trying to compile akonadi I get the following error: > ===> Installing for qtchooser-39===> Checking if qtchooser already > installed===> Registering installation for qtchooser-39 as > automaticInstalling qtchooser-39...pkg-static: qtchooser-39 conflicts with > qt4-dbus-4.8.7 (installs files into the same place). Problematic file: > /usr/local/bin/qdbus*** Error code 70 > Stop.make[5]: stopped in /usr/ports/misc/qtchooser*** Error code > 1Stop.make[4]: stopped in /usr/ports/devel/qt4-qmake*** Error code > 1Stop.make[3]: stopped in /usr/ports/devel/qt4-moc*** Error code > 1Stop.make[2]: stopped in /usr/ports/devel/automoc4*** Error code > 1Stop.make[1]: stopped in /usr/ports/databases/akonadi*** Error code > 1Stop.make: stopped in /usr/ports/databases/akonadi > sincerelyFilippo I had to: pkg delete qt4-linguisttools pkg delete qt4-rcc pkg delete qt4-moc Then I installed qtchooser, and next, I upgraded qt5-core only. Now, you should be able to upgrade the remaining ports. Note, I use ports which I build on my own, not pre-compiled packages. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Problem compiling akonadi
While trying to compile akonadi I get the following error: ===> Installing for qtchooser-39===> Checking if qtchooser already installed===> Registering installation for qtchooser-39 as automaticInstalling qtchooser-39...pkg-static: qtchooser-39 conflicts with qt4-dbus-4.8.7 (installs files into the same place). Problematic file: /usr/local/bin/qdbus*** Error code 70 Stop.make[5]: stopped in /usr/ports/misc/qtchooser*** Error code 1Stop.make[4]: stopped in /usr/ports/devel/qt4-qmake*** Error code 1Stop.make[3]: stopped in /usr/ports/devel/qt4-moc*** Error code 1Stop.make[2]: stopped in /usr/ports/devel/automoc4*** Error code 1Stop.make[1]: stopped in /usr/ports/databases/akonadi*** Error code 1Stop.make: stopped in /usr/ports/databases/akonadi sincerelyFilippo ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
lam broken in 313938 ?
Hello Found that after 313938 (Capsicum-ize lam) it's doesn't work. portsnap auto Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Thu Feb 16 11:34:22 EET 2017 to Tue Feb 21 08:57:00 EET 2017. Fetching 5 metadata patches.lam: unable to limit stdio: Capabilities insufficient done. Applying metadata patches... done. Fetching 5 metadata files... lam: unable to limit stdio: Capabilities insufficient /usr/sbin/portsnap: cannot open 789d9ed1b338af92d7dfd15adeebe34ecf15455ff60ca989ca07dea13d1fed8b.gz: No such file or directory metadata is corrupt. Checked on few machines with current on board.. Any suggestion ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
