Re: [gentoo-user] /proc/meminfo
On 4/26/21 11:17 PM, cal wrote: > On 4/26/21 10:14 PM, the...@sys-concept.com wrote: >> On 4/26/21 10:09 PM, cal wrote: >>> On 4/26/21 8:56 PM, the...@sys-concept.com wrote: My new PC has two 8GB sticks so total 16GB RAM but cat /proc/meminfo MemTotal: 14230648 kB Shouldn't it show 15GB+ ? >>> The kernel takes up some RAM, although I wouldn't expect 2GB worth. You >>> can check that with `dmesg | grep Memory:`. >>> >>> The other possibility is that your RAM manufacturer used "gigabyte" to mean >>> 10^9 instead of 2^30, meaning that you actually have fewer than 16GiB. >>> Hard disk manufacturers have been pulling this trick for years; I'm not >>> sure if it's common for RAM. >>> >>> cal >> >> Thanks for the input. I forgot to mention that this AMD is CPU +GPU, so is >> it possible that GPU take some RAM? >> >> dmesg | grep Memory >> [0.065475] Memory: 14159016K/14587784K available (16397K kernel code, >> 2527K rwdata, 3968K rodata, 1172K init, 1552K bss, 428508K reserved, 0K >> cma-reserved) >> [1.553492] amdgpu :09:00.0: amdgpu: Trusted Memory Zone (TMZ) >> feature disabled as experimental (default) >> >> > By CPU+GPU, you mean the GPU is integrated into the CPU die? If so, > then yes, it is likely sharing system RAM. Elsewhere in dmesg probably > says how much. You can also probably find this in the BIOS somewhere. > > cal Yes, that is the case. So that would explain missing RAM.
Re: [gentoo-user] /proc/meminfo
On 4/26/21 10:14 PM, the...@sys-concept.com wrote: > On 4/26/21 10:09 PM, cal wrote: >> On 4/26/21 8:56 PM, the...@sys-concept.com wrote: >>> My new PC has two 8GB sticks so total 16GB RAM >>> but cat /proc/meminfo >>> MemTotal: 14230648 kB >>> Shouldn't it show 15GB+ ? >>> >> The kernel takes up some RAM, although I wouldn't expect 2GB worth. You can >> check that with `dmesg | grep Memory:`. >> >> The other possibility is that your RAM manufacturer used "gigabyte" to mean >> 10^9 instead of 2^30, meaning that you actually have fewer than 16GiB. Hard >> disk manufacturers have been pulling this trick for years; I'm not sure if >> it's common for RAM. >> >> cal > > Thanks for the input. I forgot to mention that this AMD is CPU +GPU, so is > it possible that GPU take some RAM? > > dmesg | grep Memory > [0.065475] Memory: 14159016K/14587784K available (16397K kernel code, > 2527K rwdata, 3968K rodata, 1172K init, 1552K bss, 428508K reserved, 0K > cma-reserved) > [1.553492] amdgpu :09:00.0: amdgpu: Trusted Memory Zone (TMZ) feature > disabled as experimental (default) > > By CPU+GPU, you mean the GPU is integrated into the CPU die? If so, then yes, it is likely sharing system RAM. Elsewhere in dmesg probably says how much. You can also probably find this in the BIOS somewhere. cal
Re: [gentoo-user] /proc/meminfo
On 4/26/21 10:09 PM, cal wrote: > On 4/26/21 8:56 PM, the...@sys-concept.com wrote: >> My new PC has two 8GB sticks so total 16GB RAM >> but cat /proc/meminfo >> MemTotal: 14230648 kB >> Shouldn't it show 15GB+ ? >> > The kernel takes up some RAM, although I wouldn't expect 2GB worth. You can > check that with `dmesg | grep Memory:`. > > The other possibility is that your RAM manufacturer used "gigabyte" to mean > 10^9 instead of 2^30, meaning that you actually have fewer than 16GiB. Hard > disk manufacturers have been pulling this trick for years; I'm not sure if > it's common for RAM. > > cal Thanks for the input. I forgot to mention that this AMD is CPU +GPU, so is it possible that GPU take some RAM? dmesg | grep Memory [0.065475] Memory: 14159016K/14587784K available (16397K kernel code, 2527K rwdata, 3968K rodata, 1172K init, 1552K bss, 428508K reserved, 0K cma-reserved) [1.553492] amdgpu :09:00.0: amdgpu: Trusted Memory Zone (TMZ) feature disabled as experimental (default)
Re: [gentoo-user] /proc/meminfo
On 4/26/21 10:21 PM, Dale wrote: > the...@sys-concept.com wrote: >> My new PC has two 8GB sticks so total 16GB RAM >> but cat /proc/meminfo >> MemTotal: 14230648 kB >> >> Shouldn't it show 15GB+ ? >> >> >> > > > I have 32Gbs here. This is what it shows: > > > root@fireball / # cat /proc/meminfo > MemTotal: 32918508 kB > > > I would think it should show half that. Odd for sure. Run memtest or > some equivalent maybe?? > > Dale In my main system have similar output: cat /proc/meminfo MemTotal: 32854284 kB
Re: [gentoo-user] /proc/meminfo
the...@sys-concept.com wrote: > My new PC has two 8GB sticks so total 16GB RAM > but cat /proc/meminfo > MemTotal: 14230648 kB > > Shouldn't it show 15GB+ ? > > > I have 32Gbs here. This is what it shows: root@fireball / # cat /proc/meminfo MemTotal: 32918508 kB I would think it should show half that. Odd for sure. Run memtest or some equivalent maybe?? Dale :-) :-)
Re: [gentoo-user] /proc/meminfo
On 4/26/21 8:56 PM, the...@sys-concept.com wrote: My new PC has two 8GB sticks so total 16GB RAM but cat /proc/meminfo MemTotal: 14230648 kB Shouldn't it show 15GB+ ? The kernel takes up some RAM, although I wouldn't expect 2GB worth. You can check that with `dmesg | grep Memory:`. The other possibility is that your RAM manufacturer used "gigabyte" to mean 10^9 instead of 2^30, meaning that you actually have fewer than 16GiB. Hard disk manufacturers have been pulling this trick for years; I'm not sure if it's common for RAM. cal
[gentoo-user] /proc/meminfo
My new PC has two 8GB sticks so total 16GB RAM but cat /proc/meminfo MemTotal: 14230648 kB Shouldn't it show 15GB+ ?
[gentoo-user] Multilib wrapped headers with amd64/no-multilib profile?
Hi,
In Gentoo Prefix on amd64 host with a no-multilib profile, for
packages that inherit multilib multilib-minimal, the multilib-build
eclass wraps headers as if multilib were enabled.
One example is mpi.h header in sys-cluster/openmpi. I am using a custom
modified ebuild, but the differences shouldn't be relevant to this issue.
The wrapper is causing problems for me, for reasons that are not
relevant here [1]. This question here is whether the wrapping should
takes place at all with no-multilib profile.
Wrapping happens on amd64 with this profile:
gentoo:default/linux/amd64/17.1/no-multilib/prefix/kernel-3.2+
For reference, as expected, no wrapping happens on ppc64le with:
gentoo:default/linux/ppc64le/17.0/prefix/kernel-3.2+
The above profile is a parent of my custom profile but this shouldn't be
relevant, the custom profile is simple, it just sets compiler flags,
package lists, use flags.
Diagnosis: multilib-build.eclass wrapps the headers because it is
detecting the "abi_flag" as set. So, as far as I understand, it
(wrongly?) ends up on the code path for yes-multilib instead of
no-multilib:
multilib_prepare_wrappers()
...
if [[ ${MULTILIB_WRAPPED_HEADERS[@]} ]]; then
# If abi_flag is unset, then header wrapping is unsupported on
# this ABI. This means the arch doesn't support multilib at all
# -- in this case, the headers are not wrapped and everything
# works as expected.
^ I want the case described in this comment, but not happening
if [[ ${MULTILIB_ABI_FLAG} ]]; then
^ this is set to abi_x86_64.amd64...
...because MULTIBUILD_VARIANT is set
...because MULTIBUILD_VARIANTS contains the flag
...because multilib_get_enabled_abi_pairs() adds it there
...because 'use abi_x86_64' evaluates to true
...presumably because in gentoo/profies/sarch/amd64/
A. use.force contains abi_x86_64, and/or
B. make.defaults sets IUSE_IMPLICIT="abi_x86_64"
Workaround: override in my derived profile:
1. in make.defaults: USE="-abi_x86_64"
2. in use.force: -abi_x86_64
Then, 'use abi_x86_64' evals to false and the header is not wrapped.
Before digging deeper, I figured I'd ask whether this is by design to
end up doing multilib things with no-multilib profile, or if it's some
issue with the way the ebuild is using multilib eclasses. What is
the correct way to disable multilib for good? Thanks for any insights.
[1] The wrapper does not cover the case when Clang is passed -target
le64-unknown-unkown-unknown, which doesn't set the macros for x86_64
that the wrapper checks. I'm not faulting the wrapper, though.
Re: [gentoo-user] Network switch - LED will not turn ON
On 4/26/21 11:12 AM, Matt Connell (Gmail) wrote: > On Mon, 2021-04-26 at 10:47 -0600, the...@sys-concept.com wrote: >> 70ft (about 21m) > > 70 feet is nowhere near the limit for ethernet over CAT5e cable. > Combine the link behavior with poor performance and I suspect your > cable is just shoddy. If they cable is the problem the LED port on the 70ft long cable on the switch would be orange "not green"; correct me anybody if I'm wrong. I'll connect another box later on and try different cable, maybe cat 6
Re: [gentoo-user] Network switch - LED will not turn ON
On Mon, 2021-04-26 at 10:47 -0600, the...@sys-concept.com wrote: > 70ft (about 21m) 70 feet is nowhere near the limit for ethernet over CAT5e cable. Combine the link behavior with poor performance and I suspect your cable is just shoddy.
[gentoo-user] Network switch - LED will not turn ON
I have a computer that is about 70ft (about 21m) from the router I constantly get a very low speed over cat 5e (about 11Mbps). Yesterday I've tried to connect that PC via Gigabit switch (Trendnet TEG-S80G) but when I disconnect the CAT5e cable from main router, the light on the switch did not light up at all. I exchange the Trendnet switch with older one Belkin switch (that is closer to the router) and Belkin switch gave me green LED light without any problem in place that is 70ft away. Plugging the Trendnet closer to the router worked as well. So it seems to me Trendnet switches are limited how far it can be from the router. Though, even with the Belkin switch having two green lights I'm still getting about 11Mbps transfer rate.
Re: [gentoo-user] xscreensaver-demo has vanished
On Mon, 26 Apr 2021 at 06:13, Philip Webb wrote: > Can anyone explain what has happened ? Although this is set to disappear in the next version (not in gentoo yet), it is still there for me in 5.45. >From the next version it will be called xscreensaver-settings. I would try re-emerging the package and check the output. Regards, Arve
