On Aug 17 15:47, Achim Gratz wrote:
> Corinna Vinschen 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
Corinna Vinschen 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 Opteron(tm) Processor
On Aug 17 13:12, Achim Gratz wrote:
> Corinna Vinschen 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 that. I r
Corinna Vinschen 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 nodes? Does that
On Aug 17 12:42, Achim Gratz wrote:
> Achim Gratz NexGo.DE> writes:
> > Corinna Vinschen 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 s
Achim Gratz NexGo.DE> writes:
> Corinna Vinschen 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 metal with Bulldozer
Corinna Vinschen 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: http://cygwin.com/problems.html
F
On Aug 17 13:31, Corinna Vinschen wrote:
> On Aug 17 11:08, Achim Gratz wrote:
> > Corinna Vinschen 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
On Aug 17 11:08, Achim Gratz wrote:
> Corinna Vinschen 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 178bfbff
>
Corinna Vinschen 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
0x80083030
On Aug 17 10:51, Achim Gratz wrote:
> Corinna Vinschen 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
> 0x801e00
Corinna Vinschen 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
Core i5-3320M
0
On Aug 17 09:12, Achim Gratz wrote:
> Corinna Vinschen 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 0x800
Corinna Vinschen 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
0x80083030
On Aug 17 08:27, Achim Gratz wrote:
> Achim Gratz 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
Achim Gratz 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
reports
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
> > whic
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 ca
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 c
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
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 to
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 th
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 w
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
Marco, please see below in terms of L3 cache info. Thanks,
On Aug 14 10:56, Achim Gratz wrote:
> Corinna Vinschen 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 t
Corinna Vinschen 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 changes, but it se
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
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 f
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.
>
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 grou
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
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 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 explic
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 15:50, Achim Gratz wrote:
> Corinna Vinschen 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
Corinna Vinschen 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 between how W
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 t
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 presen
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 1
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 Domain
40 matches
Mail list logo
