Re: how to mark llvm* forbidden?
On 04/05/17 15:32, Chris H wrote: On Wed, 5 Apr 2017 21:51:40 + Brooks Davis wrote On Wed, Apr 05, 2017 at 11:42:16AM -0700, Chris H wrote: OK I'm chasing -CURRENT, and I performed an initial install, followed by a new world/kernel && ports about a mos ago. Last Friday, I svn upped the system (src && ports), rebuilt/installed world/kernel. I just began rebuilding the ports, only to find that when finished, I will likely end up with every version of llvm && clang from version 3 to the now current 4. My build session is currently tying nearly every core on the CPU with llvm builds. Given that llvm4 comes in base. Is there *any* reason I can not insist that the ports I upgrade, or build, just use the version(s) of clang/llvm in base? If so. How do I inform the ports that they may *only* use the version(s) in base? In general you can't. There are many reasons including: the base llvm doesn't include the requisite cmake bits for cmake based ports, some ports use unstable APIs and require specific LLVM versions, and some use LLVM tools or libraries that aren't built/installed as part of the base system. There are probably some ports where the base clang is fine but that's probably mostly down to someone getting USES variables right. -- Brooks Grumble.. That's what I was afraid I might hear. Thanks, Brooks! Even if it's not what I was hoping to hear. :) FWIW, this is biting me hard right now too. I feel your pain... I'm a c++17 junky but I might have to let go of llvm-devel. Russell --Chris ___ 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" ___ 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: how to mark llvm* forbidden?
On Wed, 5 Apr 2017 21:51:40 + Brooks Davis wrote > On Wed, Apr 05, 2017 at 11:42:16AM -0700, Chris H wrote: > > OK I'm chasing -CURRENT, and I performed an initial > > install, followed by a new world/kernel && ports about a > > mos ago. Last Friday, I svn upped the system (src && ports), > > rebuilt/installed world/kernel. I just began rebuilding > > the ports, only to find that when finished, I will likely > > end up with every version of llvm && clang from version 3 > > to the now current 4. My build session is currently tying > > nearly every core on the CPU with llvm builds. Given that > > llvm4 comes in base. Is there *any* reason I can not insist > > that the ports I upgrade, or build, just use the version(s) > > of clang/llvm in base? If so. How do I inform the ports > > that they may *only* use the version(s) in base? > > In general you can't. There are many reasons including: the base llvm > doesn't include the requisite cmake bits for cmake based ports, some > ports use unstable APIs and require specific LLVM versions, and some use > LLVM tools or libraries that aren't built/installed as part of the base > system. > > There are probably some ports where the base clang is fine but that's > probably mostly down to someone getting USES variables right. > > -- Brooks Grumble.. That's what I was afraid I might hear. Thanks, Brooks! Even if it's not what I was hoping to hear. :) --Chris ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 2017-Apr-5, at 10:20 AM, Alexey Dokuchaev wrote: > On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: >> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : >>> ... >>> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. >> >> So, you are comparing the size of the llvm39 package with the size of >> the llvm40 after extraction ? > > Ha, didn't realize it, I'm so dumb. What the size of llvm40-*.txz then? > I don't have it cached locally yet... Someone else provided a comparison. But as for the installed-size goes: Looks like pkg delete's report of size is truncated or rounded to an integral GiByte count for llvm40. pkg info shows (reminder: powerpc64 context): # pkg info llvm40 | grep "Flat size" Flat size : 1.38GiB So I did not pick a good estimate to report for installed-size for the no-WITH_DEBUG variant's scale for installed-size. === 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: how to mark llvm* forbidden?
On Wed, Apr 05, 2017 at 11:42:16AM -0700, Chris H wrote: > OK I'm chasing -CURRENT, and I performed an initial > install, followed by a new world/kernel && ports about a > mos ago. Last Friday, I svn upped the system (src && ports), > rebuilt/installed world/kernel. I just began rebuilding > the ports, only to find that when finished, I will likely > end up with every version of llvm && clang from version 3 > to the now current 4. My build session is currently tying > nearly every core on the CPU with llvm builds. Given that > llvm4 comes in base. Is there *any* reason I can not insist > that the ports I upgrade, or build, just use the version(s) > of clang/llvm in base? If so. How do I inform the ports > that they may *only* use the version(s) in base? In general you can't. There are many reasons including: the base llvm doesn't include the requisite cmake bits for cmake based ports, some ports use unstable APIs and require specific LLVM versions, and some use LLVM tools or libraries that aren't built/installed as part of the base system. There are probably some ports where the base clang is fine but that's probably mostly down to someone getting USES variables right. -- Brooks signature.asc Description: PGP signature
Re: Is ipfilter firewall with ippool working?
In message <58e50379.6090...@gmail.com>, Ernie Luzar writes: > I have been a ipfilter user since Freebsd 3.0 without any complaints. > Now I'm trying to get ippool to function. I have been able to add a > pool, but now I want to refresh it's contents. From what I read in "man > 8 ippool", I have to remove the pool from core and then re-add it with > the complete new content. When I issue this command to remove the named > ippool from core, I get message saying "Segmentation fault (core > dumped)" and the system continues as normal. > > ippool -R -m unsolicited > > I know that in 2016 ipfilter was forked and updated to be freebsd > friendly. Thinking maybe something in the kernel code was changed that > now is causing this problem. I'm running release 11.0. > > Is there anyone out there who has ipfilter/ippool working? Hi, I use ipfilter (and have for a couple of decades on Solaris and FreeBSD). We haven't forked it but we are fixing bugs and pushing them upstream. Looking at the ippool source, this is another case of the source or man page being incorrect. Looking at earlier versions of the source and man pages, it appears to have been broken for almost forever. This is not the first command line parsing issue or man page discrepancy in ipfilter. Can you please file a PR and assign it to me? The todos will be to: 1. Determine whether the man page or the code is correct. 2. Verify that all arguments are parsed (and subsequently processes). 3. Verify that correct error messages are produced as appropriate. For now you can issue ippool -R -m unsolicited POOL_TYPE, where pool type is documented in the man page with -t (though that will also need to be verified). The ippool parser thinks the pool type is a positional argument not an option. I'd like to verify Darren Reed's (original author's) intention before blindly "fixing" anything. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
Le 05/04/2017 à 19:20, Alexey Dokuchaev a écrit : > On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: >> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : >>> ... >>> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. >> So, you are comparing the size of the llvm39 package with the size of >> the llvm40 after extraction ? > Ha, didn't realize it, I'm so dumb. What the size of llvm40-*.txz then? > I don't have it cached locally yet... On my builds: -rw-r--r-- 6 nobody wheel 256105968 4 avr. 17:54 llvm39-3.9.1_4.txz -rw-r--r-- 6 nobody wheel 304951340 4 avr. 18:02 llvm40-4.0.0_2.txz -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
how to mark llvm* forbidden?
OK I'm chasing -CURRENT, and I performed an initial install, followed by a new world/kernel && ports about a mos ago. Last Friday, I svn upped the system (src && ports), rebuilt/installed world/kernel. I just began rebuilding the ports, only to find that when finished, I will likely end up with every version of llvm && clang from version 3 to the now current 4. My build session is currently tying nearly every core on the CPU with llvm builds. Given that llvm4 comes in base. Is there *any* reason I can not insist that the ports I upgrade, or build, just use the version(s) of clang/llvm in base? If so. How do I inform the ports that they may *only* use the version(s) in base? Thank you for all your time, and consideration. --Chris ___ 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: increased power consumption lately?
> On Apr 5, 2017, at 10:39, Adrian Chadd wrote:
>
> hm, you could use dtrace to find what's calling that function and
> print out the call stack?
*does shrug* something like this (I realize it’s not printing out arg0
— arg0 is a union that would need decoding)?
Thanks,
-Ngie
$ cat AcpiNsLookup.d
fbt:kernel:AcpiNsLookup:entry
{
printf("PathInfo: %s\nType: %d\nFlags: %u",
stringof(arg1), arg2, arg3);
}
$ sudo dtrace -s AcpiNsLookup.d
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: increased power consumption lately?
hm, you could use dtrace to find what's calling that function and
print out the call stack?
-adrian
On 5 April 2017 at 02:32, Johannes Lundberg wrote:
> Is there an easy way to do that with existing tools or do I need to add
> debug printing to the code?
>
>
> On Tue, Apr 4, 2017 at 9:39 PM, Adrian Chadd wrote:
>>
>> hiya,
>>
>> looks like yeah, you're going to have to do a bit more debugging. Can you
>> see what args are being passed to AcpiNsLookup() ?
>>
>>
>>
>> -adrian
>>
>>
>> On 3 April 2017 at 03:24, Johannes Lundberg wrote:
>>>
>>> Hi Adrian
>>>
>>> The three threads are kernel(acpi_task_{0-2}) and they use ~30% each so
>>> total 100% of one core.
>>>
>>> Machine is 2013 MBP
>>>
>>> pmcstat screenshot attached.
>>>
>>>
>>> On Thu, 30 Mar 2017 at 21:16, Adrian Chadd wrote:
I don't /think/ so - which thread is it on your end? Can you run
pmcstat -S instructions -T to see what's taking your CPU?
-adrian
On 28 March 2017 at 13:36, Johannes Lundberg wrote:
> Hi
>
> Personally I got some acpi-something kernel thread at 100% CPU
> constant
> usage. Need to lock CPU freq at lower value otherwise it runs with
> turboboost all the time.
>
> Could it be the same for you?
>
> On Tue, 28 Mar 2017 at 20:58, Adrian Chadd wrote:
>>
>> hiya,
>>
>> I've noticed that my battery life on my haswell laptop (T540p) seems
>> to have taken a nosedive lately. I could've /sworn/ it was getting
>> better than 15-16W at idle.
>>
>> Has anyone noticed any massive decrease in battery life lately?
>>
>>
>>
>> -adrian
>> ___
>> 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"
>>
>>
>
___
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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: > Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : > > ... > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > > So, you are comparing the size of the llvm39 package with the size of > the llvm40 after extraction ? Ha, didn't realize it, I'm so dumb. What the size of llvm40-*.txz then? I don't have it cached locally yet... ./danfe ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Wednesday 05 April 2017 19:44:51 Slawa Olhovchenkov wrote: > On Wed, Apr 05, 2017 at 04:15:41PM +, Alexey Dokuchaev wrote: > > > I've also tried without WITH_DEBUG= and now. . . > > > > > > # pkg delete llvm40 > > > Checking integrity... done (0 conflicting) > > > Deinstallation has been requested for the following 1 packages (of 0 > > > packages in the universe): > > > > > > Installed packages to be REMOVED: > > > llvm40-4.0.0 > > > > > > Number of packages to be removed: 1 > > > > > > The operation will free 1 GiB. > > > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > > I'm surely looking forward modularization of LLVM port; rebuilding it > > every time becomes a real PITA given that X11 stack requires it. :-( > > What real reason of requiring llvm for X11? > I am about run time depends: > > # pkg info -r llvm39 > llvm39-3.9.1_4: > libEGL-13.0.6 > dri-13.0.6,2 > > # ldd /usr/local/lib/libXvMCr600.so > /usr/local/lib/libXvMCr600.so: > [...] > libLLVM-3.9.so => /usr/local/llvm39/lib/libLLVM-3.9.so (0x803e0) > libLTO.so => /usr/local/llvm39/lib/../lib/libLTO.so (0x80820) [...] > > # ls -lh /usr/local/llvm39/lib/libLLVM-3.9.so > /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel38M Apr > 2 18:18 /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel > 47M Apr 2 18:18 /usr/local/llvm39/lib/libLLVM-3.9.so > > libXvMCr600 realy do run-time llvm interpetation and linker-time > optimisation?! > > Also, I am don't see any realy dependence libEGL-13.0.6 from llvm. Yes, Mesa really uses LLVM at runtime for shader compilation/optimization, and Xorg depends on Mesa for GLX, etc. ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
Le 05/04/2017 à 18:15, Alexey Dokuchaev a écrit :
> On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote:
>> LLVM 3.8 introduced the option to build a shared LLVM library, which is
>> what Mesa needs for use at runtime (for e.g. compiling shaders), separate
>> from linking to it. Previous versions only had one option, if the library
>> was built then all the LLVM binaries were staticly linked to it. [...]
>>
>> llvm{35,36,37} are statically linked and thus smaller than normal. llvm38
>> switched to dynamic linking, the default, thus the size grew.
> Hmm, I don't quite get it: shouldn't static linking actually increase the
> binaries (and thus the package) size?
>
>> I assume llvm40 will be a bit bigger, but do not expect to see another
>> jump as you've observed.
> As Mark Millard reports:
>
>> I've also tried without WITH_DEBUG= and now. . .
>>
>> # pkg delete llvm40
>> Checking integrity... done (0 conflicting)
>> Deinstallation has been requested for the following 1 packages (of 0
>> packages in the universe):
>>
>> Installed packages to be REMOVED:
>> llvm40-4.0.0
>>
>> Number of packages to be removed: 1
>>
>> The operation will free 1 GiB.
> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me.
So, you are comparing the size of the llvm39 package with the size of
the llvm40 after extraction ?
--
Mathieu Arnold
signature.asc
Description: OpenPGP digital signature
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote:
> On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote:
> > LLVM 3.8 introduced the option to build a shared LLVM library, which is
> > what Mesa needs for use at runtime (for e.g. compiling shaders), separate
> > from linking to it. Previous versions only had one option, if the library
> > was built then all the LLVM binaries were staticly linked to it. [...]
> >
> > llvm{35,36,37} are statically linked and thus smaller than normal. llvm38
> > switched to dynamic linking, the default, thus the size grew.
>
> Hmm, I don't quite get it: shouldn't static linking actually increase the
> binaries (and thus the package) size?
>
I might have reversed static and shared somewhere in the linking explanation,
or not properly described the situation. Versions prior to 3.8 could either
build libLLVM as a static library and link all the LLVM binaries to that
(recommended), or build it as a shared library and link the LLVM binaries to
that (recommended for development only, but Mesa needs libLLVM.so). LLVM 3.8
introduced the 3rd option, build the shared library for external use, i.e.
Mesa, but link the LLVM binaries to the libLLVM*.a bits that were used to
build the shared library.
llvm37 was built the non-recommended way for the benefit of Mesa, the LLVM
binaries were linked to the shared library that Mesa used. llvm38 turned
building/linking of the shared library, so there would be some increase since
each LLVM binary now had that portion static linked. llvm39 turned on building
of the shared library but did not enable linking with it so the LLVM binaries
remain linking that part static, meaning the package grows by the size the
shared library that is installed but not used by LLVM itself.
Those were changes to a portion, not a complete change between static and
shared linking for the whole package, so I was somewhat surprised by the size
difference you noted, but of course I had forgotten that all the parts were
collapsed into the llvm port. There was a brief period in which llvm39 was
fully switched to dynamic linking, which made it considerably smaller but
caused runtime problems (and was also likely to be slower).
> > I assume llvm40 will be a bit bigger, but do not expect to see another
> > jump as you've observed.
>
> As Mark Millard reports:
> > I've also tried without WITH_DEBUG= and now. . .
> >
> > # pkg delete llvm40
> > Checking integrity... done (0 conflicting)
> > Deinstallation has been requested for the following 1 packages (of 0
> > packages in the universe):
> >
> > Installed packages to be REMOVED:
> > llvm40-4.0.0
> >
> > Number of packages to be removed: 1
> >
> > The operation will free 1 GiB.
>
> That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me.
> I'm surely looking forward modularization of LLVM port; rebuilding it
> every time becomes a real PITA given that X11 stack requires it. :-(
>
> ./danfe
I have both llvm39 and llvm40 installed here (amd64) with all options enabled
and without any WITH_DEBUG. According to pkg, the flat (installed) size of
llvm39 is 1.10GB and llvm40 is 1.31GB, so not a huge difference (<20%) but
still steady growth. The best solution to cut rebuild time for LLVM is ccache.
___
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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Wed, Apr 05, 2017 at 04:15:41PM +, Alexey Dokuchaev wrote: > > I've also tried without WITH_DEBUG= and now. . . > > > > # pkg delete llvm40 > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > > > > Installed packages to be REMOVED: > > llvm40-4.0.0 > > > > Number of packages to be removed: 1 > > > > The operation will free 1 GiB. > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > I'm surely looking forward modularization of LLVM port; rebuilding it > every time becomes a real PITA given that X11 stack requires it. :-( What real reason of requiring llvm for X11? I am about run time depends: # pkg info -r llvm39 llvm39-3.9.1_4: libEGL-13.0.6 dri-13.0.6,2 # ldd /usr/local/lib/libXvMCr600.so /usr/local/lib/libXvMCr600.so: [...] libLLVM-3.9.so => /usr/local/llvm39/lib/libLLVM-3.9.so (0x803e0) libLTO.so => /usr/local/llvm39/lib/../lib/libLTO.so (0x80820) [...] # ls -lh /usr/local/llvm39/lib/libLLVM-3.9.so /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel38M Apr 2 18:18 /usr/local/llvm39/lib/../lib/libLTO.so -rwxr-xr-x 1 root wheel47M Apr 2 18:18 /usr/local/llvm39/lib/libLLVM-3.9.so libXvMCr600 realy do run-time llvm interpetation and linker-time optimisation?! Also, I am don't see any realy dependence libEGL-13.0.6 from llvm. ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote:
> LLVM 3.8 introduced the option to build a shared LLVM library, which is
> what Mesa needs for use at runtime (for e.g. compiling shaders), separate
> from linking to it. Previous versions only had one option, if the library
> was built then all the LLVM binaries were staticly linked to it. [...]
>
> llvm{35,36,37} are statically linked and thus smaller than normal. llvm38
> switched to dynamic linking, the default, thus the size grew.
Hmm, I don't quite get it: shouldn't static linking actually increase the
binaries (and thus the package) size?
> I assume llvm40 will be a bit bigger, but do not expect to see another
> jump as you've observed.
As Mark Millard reports:
> I've also tried without WITH_DEBUG= and now. . .
>
> # pkg delete llvm40
> Checking integrity... done (0 conflicting)
> Deinstallation has been requested for the following 1 packages (of 0
> packages in the universe):
>
> Installed packages to be REMOVED:
> llvm40-4.0.0
>
> Number of packages to be removed: 1
>
> The operation will free 1 GiB.
That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me.
I'm surely looking forward modularization of LLVM port; rebuilding it
every time becomes a real PITA given that X11 stack requires it. :-(
./danfe
___
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"
Is ipfilter firewall with ippool working?
I have been a ipfilter user since Freebsd 3.0 without any complaints. Now I'm trying to get ippool to function. I have been able to add a pool, but now I want to refresh it's contents. From what I read in "man 8 ippool", I have to remove the pool from core and then re-add it with the complete new content. When I issue this command to remove the named ippool from core, I get message saying "Segmentation fault (core dumped)" and the system continues as normal. ippool -R -m unsolicited I know that in 2016 ipfilter was forked and updated to be freebsd friendly. Thinking maybe something in the kernel code was changed that now is causing this problem. I'm running release 11.0. Is there anyone out there who has ipfilter/ippool working? ___ 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"
pkg wrong architecture pRoBlEm !!
Script started on Wed Apr 5 03:05:22 2017 Command: pkg add -f /var/cache/pkg/vim-8.0.0534-c8fbf335b0.txz pkg: Ignoring bad configuration entry in pkg.conf: "/usr/cache/pkg" pkg: Ignoring bad configuration entry in pkg.conf: "INDEX-12" Installing vim-8.0.0534... pkg: wrong architecture: FreeBSD:12:i386 instead of freebsd:12:x86:32 package vim is already installed, forced install Extracting vim-8.0.0534: 0% Extracting vim-8.0.0534: 0% Extracting vim-8.0.0534: 1% Extracting vim-8.0.0534: 2% Extracting vim-8.0.0534: 3% Extracting vim-8.0.0534: 4% Extracting vim-8.0.0534: 5% Extracting vim-8.0.0534: 6% Extracting vim-8.0.0534: 7% Extracting vim-8.0.0534: 8% Extracting vim-8.0.0534: 9% Extracting vim-8.0.0534: 10% Extracting vim-8.0.0534: 11% Extracting vim-8.0.0534: 12% Extracting vim-8.0.0534: 13% Extracting vim-8.0.0534: 14% Extracting vim-8.0.0534: 15% Extracting vim-8.0.0534: 16% Extracting vim-8.0.0534: 17% Extracting vim-8.0.0534: 18% Extracting vim-8.0.0534: 19% Extracting vim-8.0.0534: 20% Extracting vim-8.0.0534: 21% Extracting vim-8.0.0534: 22% Extracting vim-8.0.0534: 23% Extracting vim-8.0.0534: 24% Extracting vim-8.0.0534: 25% Extracting vim-8.0.0534: 26% Extracting vim-8.0.0534: 27% Extracting vim-8.0.0534: 28% Extracting vim-8.0.0534: 29% Extracting vim-8.0.0534: 30% Extracting vim-8.0.0534: 31% Extracting vim-8.0.0534: 32% Extracting vim-8.0.0534: 33% Extracting vim-8.0.0534: 34% Extracting vim-8.0.0534: 35% Extracting vim-8.0.0534: 36% Extracting vim-8.0.0534: 37% Extracting vim-8.0.0534: 38% Extracting vim-8.0.0534: 39% Extracting vim-8.0.0534: 40% Extracting vim-8.0.0534: 41% Extracting vim-8.0.0534: 42% Extracting vim-8.0.0534: 43% Extracting vim-8.0.0534: 44% Extracting vim-8.0.0534: 45% Extracting vim-8.0.0534: 46% Extracting vim-8.0.0534: 47% Extracting vim-8.0.0534: 48% Extracting vim-8.0.0534: 49% Extracting vim-8.0.0534: 50% Extracting vim-8.0.0534: 51% Extracting vim-8.0.0534: 52% Extracting vim-8.0.0534: 53% Extracting vim-8.0.0534: 54% Extracting vim-8.0.0534: 55% Extracting vim-8.0.0534: 56% Extracting vim-8.0.0534: 57% Extracting vim-8.0.0534: 58% Extracting vim-8.0.0534: 59% Extracting vim-8.0.0534: 60% Extracting vim-8.0.0534: 61% Extracting vim-8.0.0534: 62% Extracting vim-8.0.0534: 63% Extracting vim-8.0.0534: 64% Extracting vim-8.0.0534: 65% Extracting vim-8.0.0534: 66% Extracting vim-8.0.0534: 67% Extracting vim-8.0.0534: 68% Extracting vim-8.0.0534: 69% Extracting vim-8.0.0534: 70% Extracting vim-8.0.0534: 71% Extracting vim-8.0.0534: 72% Extracting vim-8.0.0534: 73% Extracting vim-8.0.0534: 74% Extracting vim-8.0.0534: 75% Extracting vim-8.0.0534: 76% Extracting vim-8.0.0534: 77% Extracting vim-8.0.0534: 78% Extracting vim-8.0.0534: 79% Extracting vim-8.0.0534: 80% Extracting vim-8.0.0534: 81% Extracting vim-8.0.0534: 82% Extracting vim-8.0.0534: 83% Extracting vim-8.0.0534: 84% Extracting vim-8.0.0534: 85% Extracting vim-8.0.0534: 86% Extracting vim-8.0.0534: 87% Extracting vim-8.0.0534: 88% Extracting vim-8.0.0534: 89% Extracting vim-8.0.0534: 90% Extracting vim-8.0.0534: 91% Extracting vim-8.0.0534: 92% Extracting vim-8.0.0534: 93% Extracting vim-8.0.0534: 94% Extracting vim-8.0.0534: 95% Extracting vim-8.0.0534: 96% Extracting vim-8.0.0534: 97% Extracting vim-8.0.0534: 98% Extracting vim-8.0.0534: 99% Extracting vim-8.0.0534: 100% Command exit status: 0 Script done on Wed Apr 5 03:05:54 2017 as SAMBA44 is here per UPDATING, not only does pkg install vim which has already been fetched need samba43 download, but the wrong architecture problem above makes it a real conundrum. How to make pkg smart enough to either point to which file it gets each from to change to one OR the other, and put it in /usr/src/PKG-UPDATING, since the pkg is in base, OR present a choice of options "keep this architecture, pkg will do FOO, or keep that architecture, pkg will do BAR, " and let the user pick? I know I can fix this just by waiting a week and doing beta stuff, but it would be nice to have a polished ncurses or something what-will-happen choice or why-it-happened explanation so conf files can be edited. Thanks J Bouquet ___ 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: increased power consumption lately?
Is there an easy way to do that with existing tools or do I need to add
debug printing to the code?
On Tue, Apr 4, 2017 at 9:39 PM, Adrian Chadd wrote:
> hiya,
>
> looks like yeah, you're going to have to do a bit more debugging. Can you
> see what args are being passed to AcpiNsLookup() ?
>
>
>
> -adrian
>
>
> On 3 April 2017 at 03:24, Johannes Lundberg wrote:
>
>> Hi Adrian
>>
>> The three threads are kernel(acpi_task_{0-2}) and they use ~30% each so
>> total 100% of one core.
>>
>> Machine is 2013 MBP
>>
>> pmcstat screenshot attached.
>>
>>
>> On Thu, 30 Mar 2017 at 21:16, Adrian Chadd wrote:
>>
>>> I don't /think/ so - which thread is it on your end? Can you run
>>> pmcstat -S instructions -T to see what's taking your CPU?
>>>
>>>
>>>
>>> -adrian
>>>
>>>
>>> On 28 March 2017 at 13:36, Johannes Lundberg wrote:
>>> > Hi
>>> >
>>> > Personally I got some acpi-something kernel thread at 100% CPU constant
>>> > usage. Need to lock CPU freq at lower value otherwise it runs with
>>> > turboboost all the time.
>>> >
>>> > Could it be the same for you?
>>> >
>>> > On Tue, 28 Mar 2017 at 20:58, Adrian Chadd wrote:
>>> >>
>>> >> hiya,
>>> >>
>>> >> I've noticed that my battery life on my haswell laptop (T540p) seems
>>> >> to have taken a nosedive lately. I could've /sworn/ it was getting
>>> >> better than 15-16W at idle.
>>> >>
>>> >> Has anyone noticed any massive decrease in battery life lately?
>>> >>
>>> >>
>>> >>
>>> >> -adrian
>>> >> ___
>>> >> freebsd-current@freebsd.org mailing list
>>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f
>>> reebsd.org"
>>>
>>
>
___
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"
