Re: [systemd-devel] Illegal CPUID instruction causes systemd core dump

[Reindl Harald]

Am 05.01.2018 um 05:51 schrieb D.S. Ljungmark:

If you want I can bring a small form factor early x86 to Fosdem.

Industrial, rugged little things with x86 chipset was rather popular
for a while, and you can still order them new.  The ones I have aren't
i486 but a 586 (cyrix, I think).


i am sure you can find everything if you want

but are you running a recent distribution with the newest software on 
that box? i strongly doubt!


P.S.: what about using proper mail- clients which knows list-headers 
instead "reply-all" and break threads because the faster offlist-mail 
leading to filter out the list-mail with the headers which comes later 
or do they also not exist on such old hardware?



On Thu, Dec 28, 2017 at 8:26 PM, Reindl Harald  wrote:

Am 28.12.2017 um 20:07 schrieb tedheadster:


I am doing regression testing on old hardware. systemd-233 just
generated the following error on startup:

I believe it is getting an illegal instruction trap on this first
generation 486 because it is calling "cpuid" in detect_vm_cpuid()
without first checking if the hardware supports it; it doesn't in this
case.

The gcc compiler provides a workaround in the cpuid.h header file. You
can call __get_cpuid_max() first and check the return value > 0.


https://stackoverflow.com/questions/14266772/how-do-i-call-cpuid-in-linux#14266932

The Linux kernel still supports the 486 so we have to code around this
case, even if it is ancient hardware



don't get me wrong - i am for 15 years now in the IT and my first PC in 1999
was a i686

i don't see how a brand new systemd and a mordern userland is supposed to
run on 20 years or older hardware where nearly eveyr distribution these days
is i586 or i686 only or starts to drop 32bit at all

if you have that old hardware normally you don't use leading edge software
on it and as a user (not systemd developer) i would love to see erevry
single line of code for 20 years old hardware is removed to make it cleaner
and in doubt faster on recent systems

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Illegal CPUID instruction causes systemd core dump

[D.S. Ljungmark]

If you want I can bring a small form factor early x86 to Fosdem.

Industrial, rugged little things with x86 chipset was rather popular
for a while, and you can still order them new.  The ones I have aren't
i486 but a 586 (cyrix, I think).

On Thu, Dec 28, 2017 at 8:26 PM, Reindl Harald  wrote:
>
>
> Am 28.12.2017 um 20:07 schrieb tedheadster:
>>
>> I am doing regression testing on old hardware. systemd-233 just
>> generated the following error on startup:
>>
>> I believe it is getting an illegal instruction trap on this first
>> generation 486 because it is calling "cpuid" in detect_vm_cpuid()
>> without first checking if the hardware supports it; it doesn't in this
>> case.
>>
>> The gcc compiler provides a workaround in the cpuid.h header file. You
>> can call __get_cpuid_max() first and check the return value > 0.
>>
>>
>> https://stackoverflow.com/questions/14266772/how-do-i-call-cpuid-in-linux#14266932
>>
>> The Linux kernel still supports the 486 so we have to code around this
>> case, even if it is ancient hardware
>
>
> don't get me wrong - i am for 15 years now in the IT and my first PC in 1999
> was a i686
>
> i don't see how a brand new systemd and a mordern userland is supposed to
> run on 20 years or older hardware where nearly eveyr distribution these days
> is i586 or i686 only or starts to drop 32bit at all
>
> if you have that old hardware normally you don't use leading edge software
> on it and as a user (not systemd developer) i would love to see erevry
> single line of code for 20 years old hardware is removed to make it cleaner
> and in doubt faster on recent systems
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to stop systemctl --user processes before backup runs then restart

[Tomasz Torcz ️]

On Thu, Jan 04, 2018 at 07:35:05PM +, Barry Scott wrote:
> On Thursday, 4 January 2018 13:08:33 GMT Colin Guthrie wrote:
> > Barry Scott wrote on 31/12/17 17:41:
> > > I think that for my backups to run for a user I will need to stop their
> > > systemd user services.
> > Out of curiosity, why do you think that the process needs to be stopped
> > for the backups to run?
> 
> The process of concern are running fetchmail that is calling into dovecot.
> 
> If I do not stop dovecot the Mail dir will not be consistent.
> If I do not stop the fetchmail process then dovecot will be called
> and the backup can see an inconsistent state.


  In such cases you should use "fsreeze" around backups.

-- 
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzich...@chrome.pl "God is more forgiving."

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to stop systemctl --user processes before backup runs then restart

[Barry Scott]

On Thursday, 4 January 2018 13:08:33 GMT Colin Guthrie wrote:
> Barry Scott wrote on 31/12/17 17:41:
> > I think that for my backups to run for a user I will need to stop their
> > systemd user services.
> Out of curiosity, why do you think that the process needs to be stopped
> for the backups to run?

The process of concern are running fetchmail that is calling into dovecot.

If I do not stop dovecot the Mail dir will not be consistent.
If I do not stop the fetchmail process then dovecot will be called
and the backup can see an inconsistent state.

How do I know this? Becuase I created bad backups in the past.

systemd --user is great at running the fetchmail processes for
the sand boxed email users. I just need to figure out how to stop them
in a way that is "systemd" smart.

Barry


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to stop systemctl --user processes before backup runs then restart

[Colin Guthrie]

Barry Scott wrote on 31/12/17 17:41:
> I think that for my backups to run for a user I will need to stop their 
> systemd user services.

Out of curiosity, why do you think that the process needs to be stopped
for the backups to run?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trouble with speed/mode in .link files - RESOLVED/PATCH

[Lennart Poettering]

On Mi, 03.01.18 15:32, Bruce A. Johnson (bjohn...@blueridgenetworks.com) wrote:

> My problem seems to be a bug in ethtool-util.c's set_slinksettings().
> The base parameters were not being copied into the ethtool_link_settings
> request, so they were all zero and ioctl didn't like that.  I've pasted
> the patch below.  Please let me know if there is anything else I need to
> do to get this to the right person.

Could you submit this as PR on github please? This makes review much
easier! Thanks!

>  __u32 link_mode_data[3 * 
> ETHTOOL_LINK_MODE_MASK_MAX_KERNEL_NU32];
> -} ecmd = {
> -.req.cmd = ETHTOOL_SLINKSETTINGS,
> -};
> +} ecmd;
>  unsigned int offset;
>  int r;
>  
>  if (u->base.cmd != ETHTOOL_GLINKSETTINGS || 
> u->base.link_mode_masks_nwords <= 0)
>  return -EINVAL;
>  
> +memset(, sizeof(ecmd), 0);
> +memcpy(, >base, sizeof(ecmd.req));
> +ecmd.req.cmd = ETHTOOL_SLINKSETTINGS;

We genereally pefer initialization at declaration time instead of
explicit memset(), as this tends to provide nicer code. Hence, please
keep at least the zero-initialization in the declaratin above.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Trouble with speed/mode in .link files - RESOLVED/PATCH

[Mantas Mikulėnas]

On Wed, Jan 3, 2018 at 10:32 PM, Bruce A. Johnson <
bjohn...@blueridgenetworks.com> wrote:

> My problem seems to be a bug in ethtool-util.c's set_slinksettings().
> The base parameters were not being copied into the ethtool_link_settings
> request, so they were all zero and ioctl didn't like that.  I've pasted
> the patch below.  Please let me know if there is anything else I need to
> do to get this to the right person.
>

It would be best if you could submit a pull request on GitHub:
https://github.com/systemd/systemd

Although patches via email are occassionally accepted, at minimum you
should send full commits using `git send-email` (or `git format-patch`).

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Better docs: Word "Type" has two meanings

[Thomas Güttler]

  
  
For new comers like me it took some time to understand that the
  word "Type" has two
meaning in systemd context.



The first: from "man systemd.service"

https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=
> Type: Configures the process start-up type for this service
  unit. 




The second from "man systemctl"
https://www.freedesktop.org/software/systemd/man/systemctl.html#-t

> -t, --type= The argument should be a
  comma-separated list of unit types such as service and socket.
  



Maybe the docs could be
  improved to make this more clear?


Regards,
  Thomas Güttler



-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
  

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel