Corinna Vinschen corinna-cygwin at cygwin.com writes:
Thanks. Can you please also show me the output of cpuid 0x801e?
Looks like newer AMDs provide additional topology info...
Opteron 6328
0x80083030 5007
0x801e0025 0102 0101
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Sorry, forgot one :(. What's the output of cpuid 0x0001?
0x0001? I've added 0x8001 in case that was a typo.
Opteron 6328
0x000100600f20 01080800 3e98320b 178bfbff
0x800100600f20 3000 01ebbfff 2fd3fbff
On Aug 17 11:08, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Sorry, forgot one :(. What's the output of cpuid 0x0001?
0x0001? I've added 0x8001 in case that was a typo.
Heh, no, it wasn't :)
Opteron 6328
0x000100600f20 01080800 3e98320b
On Aug 17 08:27, Achim Gratz wrote:
Achim Gratz Stromeko at nexgo.de writes:
The output is correct now for a SandyBridge dual-core CPU with
logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.
Another IvyBridge dual-core w/ HT looks also correct.
However, for the
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Oh, ok. It seems I accidentally dropped a piece of code there. Can you
do me a favor and run the following test application? I just need the
value your Piledrive CPU returns in ecx returned by cpuid 0x8008:
Opteron 6328
0x8008
On Aug 17 10:51, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Thanks. Can you please also show me the output of cpuid 0x801e?
Looks like newer AMDs provide additional topology info...
Opteron 6328
0x80083030 5007
On Aug 17 13:31, Corinna Vinschen wrote:
On Aug 17 11:08, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Sorry, forgot one :(. What's the output of cpuid 0x0001?
0x0001? I've added 0x8001 in case that was a typo.
Heh, no, it wasn't :)
On Aug 17 09:12, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Oh, ok. It seems I accidentally dropped a piece of code there. Can you
do me a favor and run the following test application? I just need the
value your Piledrive CPU returns in ecx returned by cpuid
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Uhm... one last question? What's the output of `lscpu'?
Not available on Cygwin and I don't have access to a Linux box with that
processor. I can ask, but it'll take some time.
Regards,
Achim.
--
Problem reports:
On Aug 17 12:42, Achim Gratz wrote:
Achim Gratz Stromeko at NexGo.DE writes:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Uhm... one last question? What's the output of `lscpu'?
Not available on Cygwin and I don't have access to a Linux box with that
processor. I can ask,
Corinna Vinschen corinna-cygwin at cygwin.com writes:
No worries and thank you. I just don't quite understand the stuff
returned by 801e and what I see above.
Different architectures, so these are not expected to match.
Do I understand this
correctly that a single CPU has 2 NUMA
Achim Gratz Stromeko at NexGo.DE writes:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Uhm... one last question? What's the output of `lscpu'?
Not available on Cygwin and I don't have access to a Linux box with that
processor. I can ask, but it'll take some time.
No Linux on bare
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Please give the latest snapshot from https://cygwin.com/snapshots/
a try.
Looks good:
32bit (1001)~ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD
On Aug 17 13:12, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
No worries and thank you. I just don't quite understand the stuff
returned by 801e and what I see above.
Different architectures, so these are not expected to match.
Sure, I wasn't expecting
On Aug 17 15:47, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Please give the latest snapshot from https://cygwin.com/snapshots/
a try.
Looks good:
32bit (1001)~ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 21
On Aug 14 20:25, Achim Gratz wrote:
Corinna Vinschen writes:
Cool, thanks for your quick feedback.
Thanks for the snapshot!
We should just be aware that this is ultimately a kludge. I think I now
finally understand what would have to be done to get a generic solution
which results
Achim Gratz Stromeko at nexgo.de writes:
The output is correct now for a SandyBridge dual-core CPU with
logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.
Another IvyBridge dual-core w/ HT looks also correct.
However, for the Piledriver Opteron 6328 in the 2012R2 server, Cygwin
On Aug 15 17:11, Achim Gratz wrote:
Corinna Vinschen writes:
Btw., can you please also check /proc/cpuinfo?
The output is correct now for a SandyBridge dual-core CPU with
logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.
Thanks!
I've also tried to find out why the L3
On Aug 15 17:41, Marco Atzeri wrote:
On 14/08/2015 15:45, Corinna Vinschen wrote:
Marco, please see below in terms of L3 cache info. Thanks,
[cut]
Btw., can you please also check /proc/cpuinfo?
As discussed, Cygwin's emulation fell short on L3 cache info. I now
added code to fetch L3
Corinna Vinschen writes:
I've also tried to find out why the L3 cache is not reported for AMD in
cpuinfo. It seems the reason is that it is logically part of the
northbridge system, even if it is on-die and gets reported via CPUID.
Ok, interesting. Still strange, isn't it?
In any case,
On 14/08/2015 15:45, Corinna Vinschen wrote:
Marco, please see below in terms of L3 cache info. Thanks,
[cut]
Btw., can you please also check /proc/cpuinfo?
As discussed, Cygwin's emulation fell short on L3 cache info. I now
added code to fetch L3 cache info as well as correct processor
Corinna Vinschen writes:
Btw., can you please also check /proc/cpuinfo?
The output is correct now for a SandyBridge dual-core CPU with
logical processors (aka HT) and an IvyBridge dual-core CPU w/o HT.
I've also tried to find out why the L3 cache is not reported for AMD in
cpuinfo. It seems
Marco, please see below in terms of L3 cache info. Thanks,
On Aug 14 10:56, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I checked in the change we were talking about. Please give the latest
snapshot from https://cygwin.com/snapshots/ a try.
I've had a quick
On Aug 13 19:53, Corinna Vinschen wrote:
On Aug 13 18:33, Corinna Vinschen wrote:
On Aug 12 20:59, Achim Gratz wrote:
Corinna Vinschen writes:
I think so, but there are likely some corner cases. But I think that
had been proposed and shot down already, so I was trying to come up
On Aug 14 20:25, Achim Gratz wrote:
Corinna Vinschen writes:
Btw., can you please also check /proc/cpuinfo?
Yes, I have both AMD and Intel machines I can test this with.
As discussed, Cygwin's emulation fell short on L3 cache info. I now
added code to fetch L3 cache info as well as
Corinna Vinschen writes:
Cool, thanks for your quick feedback.
Thanks for the snapshot!
We should just be aware that this is ultimately a kludge. I think I now
finally understand what would have to be done to get a generic solution
which results in correct POSIX permission evaluation for
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I checked in the change we were talking about. Please give the latest
snapshot from https://cygwin.com/snapshots/ a try.
I've had a quick look and things look good. I'll have to roll out the
snapshot to our server and revert the script
Corinna Vinschen writes:
Cygwin is aware of them and access(2) explicitely checks for them. That
obviously doesn't help for applications like perl, who know better
than the underlying OS how to evaluate perms.
Just for clarification, Perl doesn't know better. It's documented
that the file
On Aug 12 20:59, Achim Gratz wrote:
Corinna Vinschen writes:
I think so, but there are likely some corner cases. But I think that
had been proposed and shot down already, so I was trying to come up with
something less intrusive.
This is relatively unintrusive. The current user token
Corinna Vinschen writes:
This puzzles me a bit. As example you gave something like
rwx---+ gratz Domain Users [...] foo
Given the code in recent Cygwin versions, this shouldn't happen if the
user gratz is member of the Domain Users group. The current code
doesn't test all groups in
On Aug 13 18:33, Corinna Vinschen wrote:
On Aug 12 20:59, Achim Gratz wrote:
Corinna Vinschen writes:
I think so, but there are likely some corner cases. But I think that
had been proposed and shot down already, so I was trying to come up with
something less intrusive.
This is
On Aug 11 08:42, Achim Gratz wrote:
I've thought some more about those strange shares I need to use that have
inherited ACL that don't let me change the ACL at all and hence prevent
Cygwin from fixing up the POSIX permissions. That generally ends up with
permissions like these:
% ll test
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I don't know what to do about this. We're talking back and forth
about reflecting group perms into user perms and whether we do it
or not, it always seems to have some downside on some installations.
Since there are fundamental differences
Corinna Vinschen writes:
I think so, but there are likely some corner cases. But I think that
had been proposed and shot down already, so I was trying to come up with
something less intrusive.
This is relatively unintrusive. The current user token is always
available. So if owner ==
On Aug 12 15:50, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I don't know what to do about this. We're talking back and forth
about reflecting group perms into user perms and whether we do it
or not, it always seems to have some downside on some installations.
Corinna Vinschen writes:
Cygwin is aware of them and access(2) explicitely checks for them. That
obviously doesn't help for applications like perl, who know better
than the underlying OS how to evaluate perms.
Perl is making use of an explicit guarantee in POSIX' ACL specification,
placed
On Aug 12 20:09, Achim Gratz wrote:
Corinna Vinschen writes:
Cygwin is aware of them and access(2) explicitely checks for them. That
obviously doesn't help for applications like perl, who know better
than the underlying OS how to evaluate perms.
Perl is making use of an explicit
I've thought some more about those strange shares I need to use that have
inherited ACL that don't let me change the ACL at all and hence prevent
Cygwin from fixing up the POSIX permissions. That generally ends up with
permissions like these:
% ll test
total 10
d---rwx---+ 1 gratz
Greetings, Achim Gratz!
I've thought some more about those strange shares I need to use that have
inherited ACL that don't let me change the ACL at all and hence prevent
Cygwin from fixing up the POSIX permissions. That generally ends up with
permissions like these:
% ll test
total 10
Andrey Repin writes:
Perl is known to have special treatment of file permissions.
It's perfectly valid to do this from a POSIX perspective and Perl is not
the only program to do this (but it's easier to show the result with
Perl). As far as POSIX is concerned, the mode bits that Cygwin presents
40 matches
Mail list logo
