On Mon, May 13, 2019 at 3:10 AM Ulrich Windl
<ulrich.wi...@rz.uni-regensburg.de> wrote:
>
> >>> tedheadster <tedheads...@gmail.com> schrieb am 11.05.2019 um 19:19 in 
> >>> Nachricht
> <CAP8WD_Y69T_2gk4+gUan4vKozAYtv_djF7cJ=uuio8j54d6...@mail.gmail.com>:
> > On Sat, May 11, 2019 at 12:30 PM Florian Weimer <f...@deneb.enyo.de> 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,
> >   I figured out the problem, I just haven't written code to fix it.
> > The documentation I can find is silent about what is returned in %ecx
> > and %ebx when calling cpuid function 0x00000001 on IDT Winchip-C6 and
> > Winchip2.
> >
> > I think %ecx  should properly contain 0x00000000, but it instead puts
> > the 'auls' characters from cpuid function 0x00000000 (vendor string
> > 'CentaurHauls') in %ecx:
> >
> > %ebx = 0x746e6543 = "Cent"
> > %edx = 0x48727561 = "aurH"
> > %ecx = 0x736c7561 = "auls"
> >
> > This sets bit 30 (0x736c7561) 'on', the 'supports rdrand' bit.
> >
> > So we have to code around the vendor and chip model in this case.
> > Jeffrey Walton gave some coding examples I might consider
> > (https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380).
>
>
> I didn't see the start of this thread, but is it another attempt to 
> re-implement /proc/cpuinfo's flags?
>

No, I don't propose we re-implement /proc/cpuinfo's flags.

We need code around the IDT Winchip2 not reporting correct information
in %ecx when given a cpuid() request with parameter 0x00000001.

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

Reply via email to