On Sun, May 19, 2019, 3:33 PM Olaf van der Spek wrote:
> On Sun, May 19, 2019 at 2:31 PM tedheadster wrote:
> >
> > On Sun, May 19, 2019 at 7:31 AM Olaf van der Spek wrote:
> > >
> > > What's eax after cpuid function 0?
> >
> > After calling
On Sun, May 19, 2019 at 7:31 AM Olaf van der Spek wrote:
>
> What's eax after cpuid function 0?
After calling cpuid function 0x0, %eax returns the expected 0x1.
Here is the output of 'cpuid -r'.
# cpuid -r
CPU 0:
0x 0x00: eax=0x0001 ebx=0x746e6543 ecx=0x736c7561 edx=0x48727561
On Sat, May 18, 2019 at 6:57 PM Segher Boessenkool
wrote:
> Something like
>
> *__ebx = *__ecx = *__edx = 0;
> asm volatile("" : "+r"(*__eax), "+r"(*__ebx), "+r"(*__ecx), "+r"(*__edx));
> __cpuid (__leaf, *__eax, *__ebx, *__ecx, *__edx);
>
> should do the trick.
Segher,
that got closer,
On Sat, May 18, 2019 at 5:30 PM Segher Boessenkool
wrote:
> That won't help, the compiler will remove those dead stores.
>
> Add a
>
> asm("" ::: "memory");
>
> between these two lines?
>
This didn't seem to do anything:
--- cpuid.h.orig 2019-05-14 05:52:11.0 -0400
+++ cpuid.h 2019-05
On Mon, May 13, 2019 at 4:49 PM Mike Gilbert wrote:
>
> Just a guess: I wonder if that 'auls' value is left over from the
> previous CPUID result. If that's the case, a simple solution might be
> to zero-out ebx, ecx, and edx in __cpuid().
Mike,
I tried your suggestion and added this patch to g
On Mon, May 13, 2019 at 3:10 AM Ulrich Windl
wrote:
>
> >>> tedheadster schrieb am 11.05.2019 um 19:19 in
> >>> Nachricht
> :
> > On Sat, May 11, 2019 at 12:30 PM Florian Weimer wrote:
> >> Can you capture register contents at the point of the cra
On Sat, May 11, 2019 at 12:30 PM Florian Weimer wrote:
> Can you capture register contents at the point of the crash?
>
> Does this reproduce in a chroot? Maybe you can trace the whole thing
> with a debugger. Does the crash reproduce if you single-step through
> the whole function?
Florian,
On Tue, May 7, 2019 at 10:55 AM Jeffrey Walton wrote:
>
> As far as I know the instruction is only defined for Intel, AMD and
> Hyogen cpus. See, for example,
> https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380.
>
Jeff,
I think you missed my point. The rdrand instruction is _not_
su
On Tue, May 7, 2019 at 10:27 AM Segher Boessenkool
wrote:
> But it should not execute it, it is guarded by some cpuid things.
>
> If the assembler does not like the insn, first do (in the same asm) an
> assembler pseudo-instruction to select a CPU that does have that insn,
> then the rdrand, and t
GCC and systemd teams:
I compiled systemd-241 and expressly set march=winchip-c6 (an i486
class cpu). It generated illegal instructions (rdrand) in the code.
Oddly, it does NOT do this when I set march=i486:
Dump of assembler code for function rdrand:
0xb7e21440 <+0>: push %esi
0xb7e
>>
>> Feb 14 23:48:57 intel486 systemd[1]: user@0.service: About to execute:
>> /lib/systemd/systemd --user
>> Feb 14 23:48:57 intel486 systemd[1]: user@0.service: Forked
>> /lib/systemd/systemd as 111
>> Feb 14 23:48:57 intel486 systemd[1]: user@0.service: Changed dead -> start
>> Feb 14 23:48:57
Team,
I have compiled my linux kernel using 'allnoconfig' and added back
in all the kernel options that have been documented as necessary for
systemd. I'm still getting an error. It fails trying to start
user@0.service, and it is related to PAM somehow.
Here is the debug log:
Feb 14 23:48:57 in
On Thu, Dec 28, 2017 at 4:29 PM, Mike Gilbert wrote:
> On Thu, Dec 28, 2017 at 3:18 PM, Lennart Poettering
> wrote:
>>
>> Please send a patch for this. We lack the relevant hardware and
>> can't test this. In fact, for most such portability support for
>> less-than-mainsrtream systems we rely on
I am doing regression testing on old hardware. systemd-233 just
generated the following error on startup:
traps:systemd[1] trap invalid opcode ip:b7d97361 sp:bfa2f6bc error:0
in libsystemd-shared-233.so[b7d3e000+1cc000]
systemd[1]: Caught , dumped core as pid 78.
systemd[1]: Freezing execution
I
14 matches
Mail list logo
