Re: [gentoo-user] DRM error: couldn't read SADs

[80x24]

On Sun, Feb 11, 2018 at 12:47 AM, Peter Humphrey  wrote:
>
> [drm:dce_v11_0_afmt_setmode] *ERROR* Couldn't read SADs: 0
> [...]
> traps: plugin-containe[6833] general protection ip:7f0a2e1711b1 
> sp:7fff6f64dc30 error:0 in ld-2.25.so[7f0a2e15c000+23000]
>
> What is a SAD (other than a seasonal affective disorder)? That library comes
> from glibc, of which I've had 5 versions or revisions in that time

Never heard of it neither. Digging into the kernel source gives

static void radeon_audio_write_sad_regs(struct drm_encoder *encoder)
{
   struct drm_connector *connector = radeon_get_connector_for_encoder$
   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
   struct cea_sad *sads;
   int sad_count;

   if (!connector)
   return;

   sad_count = drm_edid_to_sad(radeon_connector_edid(connector), $
   if (sad_count <= 0) {
   DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
   return;
   }
   BUG_ON(!sads);

   if (radeon_encoder->audio && radeon_encoder->audio->write_sad_regs)
   radeon_encoder->audio->write_sad_regs(encoder, sads, sad_c$

kfree(sads);
}


in theses files

drivers/gpu/drm/radeon/radeon_audio.c
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c

which ``drm_edid_to_sad‘’ is defined in drivers/gpu/drm/drm_edid.c.
Comments read

/**
 * drm_edid_to_sad - extracts SADs from EDID
 * @edid: EDID to parse
 * @sads: pointer that will be set to the extracted SADs
 *
 * Looks for CEA EDID block and extracts SADs (Short Audio Descriptors) fr$
 *
 * Note: The returned pointer needs to be freed using kfree().
 *
 * Return: The number of found SADs or negative number on error.
 */

Considering the term ``EDID'' and some audio related words, I think
it's reading some info from your monitor.

-- 
Silence is golden.

Re: [gentoo-user] "systemd sysv-utils blocker resolution"

[Rich Freeman]

On Sat, Feb 10, 2018 at 10:02 PM, allan gottlieb  wrote:
> On Sat, Feb 10 2018, Rich Freeman wrote:
>
>>
>> Interesting.  Does /sbin/reboot exist?
>
> gottlieb@E6430 ~ $ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 16 Jan 28 13:08 /sbin/reboot -> ../bin/systemctl
>
>> What does "qfile /sbin/reboot" return?
>
> gottlieb@E6430 ~ $ qfile /sbin/reboot
> sys-apps/systemd (/sbin/reboot)

Ok, your systemd is built with USE=sysv-utils.

>> Ultimately it comes down to whether you care about the compatibility
>> symlinks.  It probably isn't a bad idea to have them though.  Maybe
>> some day you'll install a UPS and its shutdown scripts will just call
>> shutdown/poweroff/etc and not work.  Software that shuts down using
>> either systemctl or dbus would be fine.
>
> Since you lean toward having the symlinks, why is the new default for
> the use flag on?  Upstream?

When the flag is on the symlinks are created.  They're only missing
(from systemd) when the flag is off.

> Also why do I have the symlinks with the 236-r5 system, contracting the
> news item.  (This is true for both machines.)

You have them because the default is USE=sysv-utils, which installs
the symlinks.

The real question is why euse didn't show you has having the flag
enabled.  That I'm not sure about.  It shows it as enabled on my
system.  I'd have to dig into where it is getting its data and how
this might get out of sync.

To avoid a second email - a lack of depcleaning might explain why
software like openrc/netifrc is still installed.  I don't believe it
has anything to do with the output of euse.

-- 
Rich

Re: [gentoo-user] "systemd sysv-utils blocker resolution"

[Dale]

allan gottlieb wrote:
> I have a question on this news item.
>
> I use systemd (gnome3) on a gentoo stable system.
> eix reports that sys-apps/systemd-236-r5 is installed
>
> But
>euse -I sysv-utils
> reports
>no matching entries found
>
> Is something wrong?
>
> I do *not* have
>   sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
> in my world file.
>
> However, the last two are installed.
>
> thanks,
> allan
>
>


I would use 'equery d openrc netifrc'to see what if anything depends on
them.  If you get packages listed, then you know why they are there, and
maybe why as well.  If it lists nothing, then --depclean should clean it
up when you get a chance to run it. 

Just my thinking.

Dale

:-)  :-) 

Re: [gentoo-user] Re: "systemd sysv-utils blocker resolution"

[allan gottlieb]

On Sun, Feb 11 2018, Nikos Chantziaras wrote:

> On 11/02/18 02:16, allan gottlieb wrote:
>> I have a question on this news item.
>>
>> I use systemd (gnome3) on a gentoo stable system.
>> eix reports that sys-apps/systemd-236-r5 is installed
>>
>> But
>> euse -I sysv-utils
>> reports
>> no matching entries found
>>
>> Is something wrong?
>>
>> I do *not* have
>>sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
>> in my world file.
>>
>> However, the last two are installed.
>
> When you ran:
>
>   emerge -auDN --changed-deps --with-bdeps=y @world
>
> did you forget to run:
>
>   emerge -a --depclean
>
> afterwards?

I am indeed behind in depcleaning.  Does that explain why
   euse doesn't fine sysv-utils
and why
   I have the symlinks /sbin/poweroff and friends with systemd-236?

I will be working on depcleans but rather slowly.

thanks for the help.
allan

Re: [gentoo-user] "systemd sysv-utils blocker resolution"

[allan gottlieb]

On Sat, Feb 10 2018, Rich Freeman wrote:

> On Sat, Feb 10, 2018 at 7:16 PM, allan gottlieb  wrote:
>> I have a question on this news item.
>>
>> I use systemd (gnome3) on a gentoo stable system.
>> eix reports that sys-apps/systemd-236-r5 is installed
>>
>> But
>>euse -I sysv-utils
>> reports
>>no matching entries found
>>
>> Is something wrong?
>>
>> I do *not* have
>>   sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
>> in my world file.
>>
>> However, the last two are installed.
>>
>
> Interesting.  Does /sbin/reboot exist?

gottlieb@E6430 ~ $ ls -l /sbin/reboot
lrwxrwxrwx 1 root root 16 Jan 28 13:08 /sbin/reboot -> ../bin/systemctl

> What does "qfile /sbin/reboot" return?

gottlieb@E6430 ~ $ qfile /sbin/reboot
sys-apps/systemd (/sbin/reboot)

> The only thing that is changing is a default - that flag was defaulted
> off before, and is defaulted on now.  So, an emerge --changed-use -u
> world should reinstall systemd with this flag enabled, assuming you
> didn't manually disable it.

I have not dis- or en- abled the flag

> In any case, you can probably actually survive without poweroff,
> reboot, etc, assuming you shutdown using systemctl.  Obviously some
> legacy scripts/programs/etc that are supposed to shut down your system
> might balk at the missing symlinks.  All the use flag does is install
> compatibility symlinks to systemctl for these sysvinit programs and
> their manpages.

My poweroff sequence is to use the gnome icon to logoff
and then the gnome icon to poweroff

> Unless you have some package installed that explicitly depends on
> sysvinit or openrc you should be fine.  Do you actually get any
> blockers/etc?

No blockers.  I have two similar machines.  Only problems are a
long-standing difficulty with one machine compiling chromium and a known
bug in compiling webkit-gtk-2.4.11-r200 on either machine.

> Ultimately it comes down to whether you care about the compatibility
> symlinks.  It probably isn't a bad idea to have them though.  Maybe
> some day you'll install a UPS and its shutdown scripts will just call
> shutdown/poweroff/etc and not work.  Software that shuts down using
> either systemctl or dbus would be fine.

Since you lean toward having the symlinks, why is the new default for
the use flag on?  Upstream?

Also why do I have the symlinks with the 236-r5 system, contracting the
news item.  (This is true for both machines.)

Thanks again for all your help,
allan

[gentoo-user] Re: "systemd sysv-utils blocker resolution"

[Nikos Chantziaras]

On 11/02/18 02:16, allan gottlieb wrote:

I have a question on this news item.

I use systemd (gnome3) on a gentoo stable system.
eix reports that sys-apps/systemd-236-r5 is installed

But
euse -I sysv-utils
reports
no matching entries found

Is something wrong?

I do *not* have
   sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
in my world file.

However, the last two are installed.


When you ran:

  emerge -auDN --changed-deps --with-bdeps=y @world

did you forget to run:

  emerge -a --depclean

afterwards?

Re: [gentoo-user] "systemd sysv-utils blocker resolution"

[Rich Freeman]

On Sat, Feb 10, 2018 at 7:16 PM, allan gottlieb  wrote:
> I have a question on this news item.
>
> I use systemd (gnome3) on a gentoo stable system.
> eix reports that sys-apps/systemd-236-r5 is installed
>
> But
>euse -I sysv-utils
> reports
>no matching entries found
>
> Is something wrong?
>
> I do *not* have
>   sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
> in my world file.
>
> However, the last two are installed.
>

Interesting.  Does /sbin/reboot exist?  What does "qfile /sbin/reboot" return?

The only thing that is changing is a default - that flag was defaulted
off before, and is defaulted on now.  So, an emerge --changed-use -u
world should reinstall systemd with this flag enabled, assuming you
didn't manually disable it.

In any case, you can probably actually survive without poweroff,
reboot, etc, assuming you shutdown using systemctl.  Obviously some
legacy scripts/programs/etc that are supposed to shut down your system
might balk at the missing symlinks.  All the use flag does is install
compatibility symlinks to systemctl for these sysvinit programs and
their manpages.

Unless you have some package installed that explicitly depends on
sysvinit or openrc you should be fine.  Do you actually get any
blockers/etc?

Ultimately it comes down to whether you care about the compatibility
symlinks.  It probably isn't a bad idea to have them though.  Maybe
some day you'll install a UPS and its shutdown scripts will just call
shutdown/poweroff/etc and not work.  Software that shuts down using
either systemctl or dbus would be fine.

-- 
Rich

[gentoo-user] "systemd sysv-utils blocker resolution"

[allan gottlieb]

I have a question on this news item.

I use systemd (gnome3) on a gentoo stable system.
eix reports that sys-apps/systemd-236-r5 is installed

But
   euse -I sysv-utils
reports
   no matching entries found

Is something wrong?

I do *not* have
  sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
in my world file.

However, the last two are installed.

thanks,
allan

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Sat, 10 Feb 2018 21:20:16 + schrieb Wol's lists:

> On 10/02/18 20:06, Rich Freeman wrote:
>> On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow 
>> wrote:
>>> Am Sat, 10 Feb 2018 19:38:56 + schrieb Wols Lists:
>>>
 On 10/02/18 18:56, Kai Krakow wrote:
> role and /usr takes the role of /, and /home already took the role
> of /usr (that's why it's called /usr, it was user data in early
> unix). The

 Actually no, not at all. /usr is not short for USeR, it's an acronym
 for User System Resources, which is why it contains OS stuff, not
 user stuff. Very confusing, I know.
>>>
>>>  From
>>>  https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:
>>>
 In the original Unix implementations, /usr was where the home
 directories of the users were placed (that is to say, /usr/someone
 was then the directory now known as /home/someone). In current
 Unices, /usr is where user-land programs and data (as opposed to
 'system land' programs and data) are. The name hasn't changed, but
 it's meaning has narrowed and lengthened from "everything user
 related" to "user usable programs and data". As such, some people may
 now refer to this directory as meaning 'User System Resources' and
 not 'user' as was originally intended.
>>>
>>> So, actually the acronym was only invented later to represent the new
>>> role of the directory. ;-)
>>>
>>>
>> A bit more of history here:
>> 
>> http://www.osnews.com/story/25556/
Understanding_the_bin_sbin_usr_bin_usr_sbin_Split
>> 
> Fascinating. And I made a typo, which is interesting too - I always knew
> it as Unix System Resources - typing "user" was a mistake ... I wonder
> how much weird info is down to mistakes like that :-)

You should trust your hidden secret skills more... :-D


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Failed builds of kbuild and cdrdao with "undefined reference to `__alloca'"

[Andreas K. Huettel]

Am Samstag, 10. Februar 2018, 03:39:04 CET schrieb tu...@posteo.de:
>
> > What's your sys-libs/glibc ?!
> 
> [I] sys-libs/glibc
> Installed versions:  (2.2)^s(09:54:43 AM 02/04/2018)

Heh, guessed so. Welcome to the wonderful world of early testing. 

It will take some time until the rest of Gentoo catches up with the changes in 
glibc-2.27 (and later). 

In the meantime I suggest you file bug reports (with Gentoo, and if there's no 
newer upstream version yet, also with upstream). Patches will eventually 
materialize.

Please always indicate clearly which version of glibc (i.e., either the 
version, or in case of , the commit or precise date/time).

[Just for the record, running glibc- on your main system is in my opinion 
crazy. And I package that thing.]

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Wol's lists]

On 10/02/18 20:06, Rich Freeman wrote:

On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow  wrote:

Am Sat, 10 Feb 2018 19:38:56 + schrieb Wols Lists:


On 10/02/18 18:56, Kai Krakow wrote:

role and /usr takes the role of /, and /home already took the role of
/usr (that's why it's called /usr, it was user data in early unix). The


Actually no, not at all. /usr is not short for USeR, it's an acronym for
User System Resources, which is why it contains OS stuff, not user
stuff. Very confusing, I know.


 From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:


In the original Unix implementations, /usr was where the home
directories of the users were placed (that is to say, /usr/someone was
then the directory now known as /home/someone). In current Unices, /usr
is where user-land programs and data (as opposed to 'system land'
programs and data) are. The name hasn't changed, but it's meaning has
narrowed and lengthened from "everything user related" to "user usable
programs and data". As such, some people may now refer to this
directory as meaning 'User System Resources' and not 'user' as was
originally intended.


So, actually the acronym was only invented later to represent the new
role of the directory. ;-)



A bit more of history here:

http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

Fascinating. And I made a typo, which is interesting too - I always knew 
it as Unix System Resources - typing "user" was a mistake ... I wonder 
how much weird info is down to mistakes like that :-)


Cheers,
Wol

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Sat, 10 Feb 2018 15:06:06 -0500 schrieb Rich Freeman:

> On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow 
> wrote:
>> Am Sat, 10 Feb 2018 19:38:56 + schrieb Wols Lists:
>>
>>> On 10/02/18 18:56, Kai Krakow wrote:
 role and /usr takes the role of /, and /home already took the role of
 /usr (that's why it's called /usr, it was user data in early unix).
 The
>>>
>>> Actually no, not at all. /usr is not short for USeR, it's an acronym
>>> for User System Resources, which is why it contains OS stuff, not user
>>> stuff. Very confusing, I know.
>>
>> From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:
>>
>>> In the original Unix implementations, /usr was where the home
>>> directories of the users were placed (that is to say, /usr/someone was
>>> then the directory now known as /home/someone). In current Unices,
>>> /usr is where user-land programs and data (as opposed to 'system land'
>>> programs and data) are. The name hasn't changed, but it's meaning has
>>> narrowed and lengthened from "everything user related" to "user usable
>>> programs and data". As such, some people may now refer to this
>>> directory as meaning 'User System Resources' and not 'user' as was
>>> originally intended.
>>
>> So, actually the acronym was only invented later to represent the new
>> role of the directory. ;-)
>>
>>
> A bit more of history here:
> 
> http://www.osnews.com/story/25556/
Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

Thanks, nice reading.

I'm looking forward to Gentoo usrmerge. While supported with 17.1 
profile, I just don't want to try. There's probably lots of bugs around 
in packages.

Although it's tempting to just symlink /bin /sbin /lib* to their /usr 
counterparts.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Rich Freeman]

On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow  wrote:
> Am Sat, 10 Feb 2018 19:38:56 + schrieb Wols Lists:
>
>> On 10/02/18 18:56, Kai Krakow wrote:
>>> role and /usr takes the role of /, and /home already took the role of
>>> /usr (that's why it's called /usr, it was user data in early unix). The
>>
>> Actually no, not at all. /usr is not short for USeR, it's an acronym for
>> User System Resources, which is why it contains OS stuff, not user
>> stuff. Very confusing, I know.
>
> From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:
>
>> In the original Unix implementations, /usr was where the home
>> directories of the users were placed (that is to say, /usr/someone was
>> then the directory now known as /home/someone). In current Unices, /usr
>> is where user-land programs and data (as opposed to 'system land'
>> programs and data) are. The name hasn't changed, but it's meaning has
>> narrowed and lengthened from "everything user related" to "user usable
>> programs and data". As such, some people may now refer to this
>> directory as meaning 'User System Resources' and not 'user' as was
>> originally intended.
>
> So, actually the acronym was only invented later to represent the new
> role of the directory. ;-)
>

A bit more of history here:

http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

-- 
Rich

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Sat, 10 Feb 2018 19:38:56 + schrieb Wols Lists:

> On 10/02/18 18:56, Kai Krakow wrote:
>> role and /usr takes the role of /, and /home already took the role of
>> /usr (that's why it's called /usr, it was user data in early unix). The
> 
> Actually no, not at all. /usr is not short for USeR, it's an acronym for
> User System Resources, which is why it contains OS stuff, not user
> stuff. Very confusing, I know.

>From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:

> In the original Unix implementations, /usr was where the home
> directories of the users were placed (that is to say, /usr/someone was 
> then the directory now known as /home/someone). In current Unices, /usr 
> is where user-land programs and data (as opposed to 'system land'
> programs and data) are. The name hasn't changed, but it's meaning has 
> narrowed and lengthened from "everything user related" to "user usable 
> programs and data". As such, some people may now refer to this 
> directory as meaning 'User System Resources' and not 'user' as was 
> originally intended.

So, actually the acronym was only invented later to represent the new 
role of the directory. ;-)


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Wols Lists]

On 10/02/18 18:56, Kai Krakow wrote:
> role and /usr takes the role of /, and /home already took the role of /usr 
> (that's why it's called /usr, it was user data in early unix). The 

Actually no, not at all. /usr is not short for USeR, it's an acronym for
User System Resources, which is why it contains OS stuff, not user
stuff. Very confusing, I know.

Cheers,
Wol

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 19:02:10 -0500 schrieb Rich Freeman:

> On Thu, Feb 8, 2018 at 6:18 PM, Wol's lists 
> wrote:
>>
>> /var/tmp is defined as the place where programs store stuff like crash
>> recovery files. Mounting it tmpfs is going to screw up any programs
>> that reply on that *defined* behaviour to recover after a crash.
>>
>>
> Care to cite an example of such a program in the Gentoo repo?  I
> certainly can't think of any, and I've been running with /var/tmp on
> tmpfs for over a decade.
> 
> /var/cache strikes me as a much better place for some kind of recovery
> file.  While /var/tmp is typically less volatile than /tmp, it isn't
> really something that software should just rely on.

I don't think that /var/cache is a better choice here. Cache directories 
should be treated as data that could be rebuilt at ANY time. That's 
certainly not true for crash dump files. They simply don't belong there.

Thus, crash dumps should go to non-volatile directories like /var/tmp.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Fri, 09 Feb 2018 12:30:21 +0200 schrieb gevisz:

> 2018-02-09 10:11 GMT+02:00 Neil Bothwick :
>> On Thu, 8 Feb 2018 23:18:19 +, Wol's lists wrote:
>>
>>> > More specifically, /var/tmp is traditionally supposed to be
>>> > non-volatile (across reboots).
>>> >
>>> > Comparatively the contents of /tmp can be volatile (across reboots).
>>> >
>>> > I would advise against mounting /var/tmp on tmpfs.
>>> >
>>> EMPHATICALLY YES.
>>>
>>> /tmp is defined as being volatile - stuff can disappear at any time.
>>>
>>> /var/tmp is defined as the place where programs store stuff like crash
>>> recovery files. Mounting it tmpfs is going to screw up any programs
>>> that reply on that *defined* behaviour to recover after a crash.
>>>
>>> Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know
>>> -
>>> I do it myself.
>>
>> Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
>> make.conf. Job done!
> 
> It is an interesting idea. But why it is not done by default then?
> 
> Can somebody think of a situation when it should not be done?
> 
> My /tmp is not on tmpfs currently. Only /run
> 
> May be, it is not a good idea to put /mnt on tmpfs at the time of
> Spector and Meltdown?

Portage doesn't run off /tmp by default because general recommendation is 
to mount /tmp with noexec. Build scripts won't be able to run that way.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Fri, 09 Feb 2018 10:58:35 + schrieb Neil Bothwick:

> On Fri, 09 Feb 2018 10:12:01 +, Peter Humphrey wrote:
> 
>> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
>> > make.conf. Job done!
>> 
>> Acting on the advice of various Gentoo guides, I have this:
>> 
>> # grep tmp /etc/fstab tmpfs   /var/tmp/portagetmpfs
>> noatime,uid=portage,gid=portage,mode=0775  0 0 tmpfs   /tmp
>>tmpfs noatime,nosuid,nodev,noexec,mode=1777   0 0
>> 
>> Are you saying I don't gain anything from it?
> 
> I can't see any benefit from the added complexity. If you want portage
> to use a tmpfs for its temporary directory, why not use one that is
> already there?

The point here is having /tmp as noexec. That's not exactly what I'd call 
added complexity.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 14:50:31 -0500 schrieb Rich Freeman:

> On Thu, Feb 8, 2018 at 2:17 PM, Dale  wrote:
>> As someone else pointed out, if you start using swap, that generally
>> defeats the purpose of tmpfs.
>>
>>
> I'll just add one thing to this, which I've probably already said ages
> ago:
> 
> In an ideal world swap would STILL be better than building on disk,
> because it gives the kernel fewer constraints around what gets written
> to disk.
> 
> Anything written to disk MUST end up on the disk within the dirty
> writeback time limit.  Anything written to tmpfs doesn't ever have to
> end up on disk, and if it is swapped the kernel need not do it in any
> particular timeframe.  Also, the swapfile doesn't need the same kinds of
> integrity features as a filesystem, which probably lowers the cost of
> writes somewhat (if nothing else after a reboot there is no need to run
> tmpreaper on it).
> 
> So, swapping SHOULD still be better than building on disk, because any
> object file that doesn't end up being swapped is a saved disk IO, and
> the stuff that does get swapped will hopefully get written at a more
> opportune time vs forcing the kernel to stop what is doing after 30s (by
> default) to make sure that something gets written no matter what (if it
> wasn't deleted before then).

I can only second this.

> That's all in an ideal world.  In practice I've never found the kernel
> swapping algorithms to be the best in the world, and I've seen a lot of
> situations where it hurts.  I run without a swapfile for this reason. 
> It pains me to do it because I can think of a bunch of reasons why this
> shouldn't help, and yet for whatever reason it does.

I really prefer having inactive things being swapped out than discarding 
cache from memory. But since kernel 4.9 this no longer works so well. I'm 
still seeking the reason. But for that reason, building in tmpfs is no 
longer such an appealing option as before.

Otherwise, I was quite happy with swap behavior, exactly for the reasons 
you initially outlined.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 16:42:23 -0700 schrieb Grant Taylor:

> On 02/08/2018 03:32 PM, gevisz wrote:
>> In this case it would be nice to hear a reason.
> 
> I think the reason probably goes back a number of years.  When /tmp was
> made volatile (ram / swap backed) there was a need for non-volatile temp
> space.  Thus, /var/tmp was created as non-volatile specifically for the
> purpose to of surviving across reboots.  (At least that's my
> understanding.)

I don't think this is the reason. Both directories have been there since 
ages, long before someone even considered putting that into ram disks. 
Historically, there would even be /usr/tmp.

The point here is that /var is "variable" data in contrast to "read-only" 
data on the other partitions. This makes /var a candidate for persistent 
OS-state. You could simply keep / and /usr on volatile storage (or even 
read-only storage) and all your variable, non-volatile data would be in
/var.

Having /tmp on tmpfs is then a logical consequence of this because / 
could be read-only. Also, /etc should be symlinked to /var/etc to enable 
and keep configuration changes over reboots, although this could also be 
populated by a boot-strapping process (e.g., IP configuration).

This is especially interesting for container-based, dynamic cloud servers 
which would spawn and disappear on demand, you just need to keep the non-
volatile state directory /var. Usually, such systems start with an empty
/etc directory which is populated by a boot-strapping process.

Following that idea, /var/tmp should also be non-volatile.

Bringing this idea further forward, everything related to the OS-image 
should move to /usr (catchword "usrmerge"), and then / which contains
/var and /etc could be writeable and non-volatile, /usr would contain
boot-strapping configuration and be read-only, /etc would be populated on 
first boot. The idea of /tmp on tmpfs is just kept here.

The idea of having everything boot-related in / doesn't apply since years 
(and wasn't the original idea anyways). These days, initramfs takes this 
role and /usr takes the role of /, and /home already took the role of /usr 
(that's why it's called /usr, it was user data in early unix). The 
splitting we have today is a result of size-constraints of early systems 
when the OS no longer fit one disk, when / became the early boot-
environment (initramfs today). Today, the OS uses dynamic linking when 
most of it was statically linked in the early day, and thus there are 
dependencies between / and /usr that cannot be untangled easily, and 
renders the split for early boot-environments difficult to maintain. So 
everything might easily move to /usr and / can become a non-volatile 
state partition containing /var and /etc. And early boot lives in 
initramfs (to setup /usr mount).


>> That's why I have asked if it does not harm.
> 
> I don't think it will actually harm the Operating System.  Some daemons
> may get cross if files they know that they created no longer exist after
> a reboot.
> 
> Though things should gracefully handle the absence of such files and
> re-create them.
> 
> The biggest Ah Ha moment I ever saw someone have was when they spent
> more than an hour getting a Solaris patch cluster to the machine,
> extracted it to /tmp, rebooted into single user mode, and went where the
> 

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 19:11:48 +0200 schrieb gevisz:

> I never used tmpfs for portage TMPDIR before and now decided to give it
> a try.
> 
> I have 8GB of RAM and 12GB of swap on a separate partition.
> 
> Do I correctly understood
> https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs that I can safely
> set in the fstab the size of my tmpfs to 12GB so that the chromium could
> be emerged in tmpfs (using the swap) without the need to set
> notmpfs.conf for chromium and the likes.
> 
> And I am going to set the whole /var/tmp/ on tpmfs instead of just
> /var/tmp/portage Is it ok?

I'm using systemd automounts to discard /var/tmp/portage when there is no
longer a user of this directory. It has one caveat: If you want to
inspect build problems, you should keep a shell running inside.

Here's the configuration:

$ fgrep portage /etc/fstab
none /var/tmp/portage tmpfs 
noauto,size=150%,uid=250,gid=250,mode=0775,x-systemd.automount 0 0

$ cat /etc/tmpfiles.d/portage.conf
D /var/tmp/portage 0775 portage portage
x /var/tmp/portage

I used ccache before but building in tmpfs is much faster.

I'm currently experimenting with tuning vm.watermark_scaling_factor as the
kernel tends to swap storms with very high desktop latencies during package
builds which consume a lot of tmpfs. This is behavior I'm seeing since
kernel 4.9, worked better before.

As such, I think it makes most sense to put only /var/tmp/portage on tmpfs.
Programs may expect /var/tmp as being non-volatile over reboots.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] DRM error: couldn't read SADs

[Peter Humphrey]

Hello list,

My VGA card is:

# lspci | grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Ellesmere [Radeon Pro WX 5100]

I've been getting these entries in dmesg every time I boot the machine, ever
since I installed the card some months ago:

[drm:dce_v11_0_afmt_setmode] *ERROR* Couldn't read SADs: 0
[...]
traps: plugin-containe[6833] general protection ip:7f0a2e1711b1 sp:7fff6f64dc30 
error:0 in ld-2.25.so[7f0a2e15c000+23000]

What is a SAD (other than a seasonal affective disorder)? That library comes
from glibc, of which I've had 5 versions or revisions in that time


The error seems not to be doing any harm, but it'd be good to clear it up.
Google hasn't helped me. Can anyone offer me a hint?

-- 
Regards,
Peter.

Re: [gentoo-user] Grub2 boot problem

[Magnus Johansson]

2018-02-07 18:50 GMT+01:00 Steven Lembark :
> On Mon, 5 Feb 2018 22:00:39 +0100
> Magnus Johansson  wrote:
>
> From my grub.cfg:
>
> insmod gzio
> insmod part_msdos
> insmod diskfilter
> insmod mdraid1x
> insmod raid5rec
> insmod lvm
> insmod xfs
>
> Sanity check that you have all of the necessary modules installed
> (e.g., "mdraid*" "raid5rec").

How do you mean? Since 'set root' and 'configfile' makes it boot I'd
assume the modules are there?

I ran 'set' from grub2 shell and

cmdpath=(hd0)
prefix=(mduuid/)/root=grub
root=mduuid/

Where  is the correct UUID.

Which looks ok?