Re: failure notice

[R0b0t1]

On Fri, Apr 13, 2018 at 10:51 PM, Brian Inglis
 wrote:
> On 2018-04-13 21:10, Jeffrey Walton wrote:
>>> On Fri, Apr 13, 2018 at 8:36 PM, Jeffrey Walton  wrote:
 On Fri, Apr 13, 2018 at 7:51 AM, Corinna Vinschen
  wrote:
> On Apr 12 23:01, Jeffrey Walton wrote:
>> Hi Everyone,
>>
>> I'm working on an AMD A6-9220 and seeing unusual results from
>> /proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
>> may be present in earlier versions, too.
>>
>> Russinovich's coreinfo is shown below
>> (https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo).
>> Notice /proc/cpuinfo is missing aesni, pclmul, rdrand, SSE4.1, SSE4.2,
>> AVX, etc.
>
> Note that, in theory, cpuinfo has to be extended for each new CPU
> generation.  That's a lot of work for marginal gain (Cygwin's not a real
> kernel) so I'm doing this only very seldomly.
>
> Patches welcome, of course!

 Thanks Corinna. I think I found the file of interest at fhandler_proc.cc.

 Whitespace is a bit off. It is a mix of tabs and space:

   if (features1 & (1 << 0))
 print (" fpu");
   if (features1 & (1 << 1))
 print (" vme");

 Should I perform a whitespace check-in before things begin? Or can you
 knock it out?
>>>
>>> The attachment is pp 572-74 from AMD's Programmer's Guide, Volume 3,
>>> General-Purpose and System Instructions (December 2017)
>>> (https://support.amd.com/TechDocs/24594.pdf). I believe it has the all
>>> the necessary information.
>>>
>>> Are there any objections to using it?
>> Any ideas how to get this through? It is a three page PDF extracted from the
>> AMD manual. It has the necessary information for the CPUID updates.
> Just include the link to Appendix D section 2 from the ToC:
> https://support.amd.com/TechDocs/24594.pdf#G14.931059
>

He may be concerned about the longterm availability of the referenced passages.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: failure notice

[Brian Inglis]

On 2018-04-13 21:10, Jeffrey Walton wrote:
>> On Fri, Apr 13, 2018 at 8:36 PM, Jeffrey Walton  wrote:
>>> On Fri, Apr 13, 2018 at 7:51 AM, Corinna Vinschen
>>>  wrote:
 On Apr 12 23:01, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm working on an AMD A6-9220 and seeing unusual results from
> /proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
> may be present in earlier versions, too.
>
> Russinovich's coreinfo is shown below
> (https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo).
> Notice /proc/cpuinfo is missing aesni, pclmul, rdrand, SSE4.1, SSE4.2,
> AVX, etc.

 Note that, in theory, cpuinfo has to be extended for each new CPU
 generation.  That's a lot of work for marginal gain (Cygwin's not a real
 kernel) so I'm doing this only very seldomly.

 Patches welcome, of course!
>>>
>>> Thanks Corinna. I think I found the file of interest at fhandler_proc.cc.
>>>
>>> Whitespace is a bit off. It is a mix of tabs and space:
>>>
>>>   if (features1 & (1 << 0))
>>> print (" fpu");
>>>   if (features1 & (1 << 1))
>>> print (" vme");
>>>
>>> Should I perform a whitespace check-in before things begin? Or can you
>>> knock it out?
>>
>> The attachment is pp 572-74 from AMD's Programmer's Guide, Volume 3,
>> General-Purpose and System Instructions (December 2017)
>> (https://support.amd.com/TechDocs/24594.pdf). I believe it has the all
>> the necessary information.
>>
>> Are there any objections to using it?
> Any ideas how to get this through? It is a three page PDF extracted from the
> AMD manual. It has the necessary information for the CPUID updates.
Just include the link to Appendix D section 2 from the ToC:
https://support.amd.com/TechDocs/24594.pdf#G14.931059

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Incorrect /proc/cpuinfo for AMD A6-9220

[Jeffrey Walton]

On Fri, Apr 13, 2018 at 7:51 AM, Corinna Vinschen
 wrote:
> On Apr 12 23:01, Jeffrey Walton wrote:
>> Hi Everyone,
>>
>> I'm working on an AMD A6-9220 and seeing unusual results from
>> /proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
>> may be present in earlier versions, too.
>>
>> Russinovich's coreinfo is shown below
>> (https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo).
>> Notice /proc/cpuinfo is missing aesni, pclmul, rdrand, SSE4.1, SSE4.2,
>> AVX, etc.
>
> Note that, in theory, cpuinfo has to be extended for each new CPU
> generation.  That's a lot of work for marginal gain (Cygwin's not a real
> kernel) so I'm doing this only very seldomly.
>
> Patches welcome, of course!

Thanks Corinna. I think I found the file of interest at fhandler_proc.cc.

Whitespace is a bit off. It is a mix of tabs and space:

  if (features1 & (1 << 0))
print (" fpu");
  if (features1 & (1 << 1))
print (" vme");

Should I perform a whitespace check-in before things begin? Or can you
knock it out?

Jeff

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Global Telephony & VoIP Software Users Base

[diana . evans]

Hi,



Would you be interested in Targeting *Global Telephony & VoIP Software
Users Base* for your market expansion?



*We have 100% Opt-In Data intelligence for*:



ü  Nextiva Users

ü  InContact Users

ü  Vonage Users

ü  UberConference Users

ü  Cisco Users

ü  Grasshopper Users

ü  8x8 Users

ü  Genesys PureConnect and more.



Kindly review and let know if you’re interested in receiving more
information.



Regards,

*Diana Evans*

If see no interest please revert unsubscribe.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: More oddities with multiple processor groups

[Achim Gratz]

Brian Inglis writes:
> Have you tried installing and running hwloc package to find out how it sees 
> your
> system?

Yes.  That is OK, but it doesn't change the fact that an application in
Cygwin can see N processors, but then can't actually run on all of them.
If Cygwin would switch the process to processor group aware state by
default then my understanding is that at least the processor group would
have to be explicitly selected for each thread, while on Linux the
scheduler would eventually use all of the NUMA nodes unless the
application tells it prefers different affinities.

> If you run lstopo under X, you get a pretty diagram, but you can also run
> lstopo-no-graphics aka hwloc-ls without X. Running "apropos hwloc" lists
> commands you can use to manipulate the topology.

I'll have that machine switched to "flat mode" which will result in a
single processor group (still with two NUMA nodes, so things like MPI
still know what to do).  I have no actual use for the current topology
and don't want to deal with the obvious complications, especially as I
seem to be the only person who'd have them.  If I can free up some time
I will want to find out why top crashes, but for me that'l be the end of
it if I even get that far.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [Bug] File permissions across domains

[Achim Gratz]

Corinna Vinschen writes:
> It's dirt easy:

For you... :-)  I know next to nothing about all this stuff.

> Ok.  However, MSDN explicitely suggests to fetch the AuthZ context
> from the current user token, if the idea is to ask for the permissions
> of the current user.  It's much less costly than calling
> AuthzInitializeContextFromSid.

OK.

> Is your account an admin account by any chance?  If so, does it work if
> you run in an elevated shell?

As I said, I have both an admin and a normal account that show the same
behaviour (it makes no difference if the admin account is used with
elevated privileges or not).

> I don't understand what you're trying to say here.  Are there
> differences or not?

You're on to something.  I have over 500 groups in my token in the old
domain, but only half of those end up in the token when I'm logged in on
the machine in the new domain (at least as far as Cygwin is concerned as
obviously I can still access the files when I'm actually trying).  I
scheduled an audience with one of the AD guys some time next week, he
thinks he can explain why that happens and hopefully it's something that
can be fixed on the AD side.  Eventually I'll have my account migrated
to the new domain later this year anyway at which point these sort of
problems should go away, but at least for the next two months I'll have
to stick it out.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: More oddities with multiple processor groups

[Corinna Vinschen]

On Apr 13 12:29, Brian Inglis wrote:
> On 2018-04-13 08:12, L A Walsh wrote:
> > Achim Gratz wrote:
> >> The problem here is that on Linux you don't need to do anything extra to 
> >> use any of the advertised logical processors from a single application, 
> >> while on Windows you need to first create a thread and set it's affinity to
> >> a different group than where your process was started in, then assign each
> >> new thread an affinity to one of the available groups.  If you don't do
> >> that, all threads will be restricted to the original group.
> > Not exactly true.  They are not *restricted* -- it's a *feature* of the
> > Windows scheduler, in that future procs/threads inherit the cpu of the
> > parent.  Linux's scheduler is more advanced as well as being replaceable.  
> > MS
> > doesn't want you to do that
> >> there might need to be some option to restrict Cygwin to a single processor
> >> group for some applications to work (correctly).
> > There is.  Start them all on a single cpu & set the cpu mask.  Pretty much 
> > the same way you restrict procs on linux -- you can run them with a specific
> > cpu mask, and most programs will keep running w/that mask.
> > Unfortunately, AFAIK, I don't think POSIX specifies a way to set affinities,
> > so I'm not sure how cygwin would do it.
> 
> Glibc adds {pthread,sched}_...affinity... functions.
> Linux uses namespaces, control groups (cgroups), cpusets, sysfs/kernfs:

We would only be able to support it partially.  Windows doesn't
allow to set thread affinity across CPU groups.  There's no simple
function to set process CPU group affinity, only a function to set
process affinity within a single group.  And it has a restriction
in that all current threads have to run in the same CPU group.
The API is pretty tricky.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: More oddities with multiple processor groups

[Brian Inglis]

On 2018-04-13 08:12, L A Walsh wrote:
> Achim Gratz wrote:
>> The problem here is that on Linux you don't need to do anything extra to 
>> use any of the advertised logical processors from a single application, 
>> while on Windows you need to first create a thread and set it's affinity to
>> a different group than where your process was started in, then assign each
>> new thread an affinity to one of the available groups.  If you don't do
>> that, all threads will be restricted to the original group.
> Not exactly true.  They are not *restricted* -- it's a *feature* of the
> Windows scheduler, in that future procs/threads inherit the cpu of the
> parent.  Linux's scheduler is more advanced as well as being replaceable.  MS
> doesn't want you to do that
>> there might need to be some option to restrict Cygwin to a single processor
>> group for some applications to work (correctly).
> There is.  Start them all on a single cpu & set the cpu mask.  Pretty much 
> the same way you restrict procs on linux -- you can run them with a specific
> cpu mask, and most programs will keep running w/that mask.
> Unfortunately, AFAIK, I don't think POSIX specifies a way to set affinities,
> so I'm not sure how cygwin would do it.

Glibc adds {pthread,sched}_...affinity... functions.
Linux uses namespaces, control groups (cgroups), cpusets, sysfs/kernfs:
util-linux provides unshare and taskset (not on Cygwin).
BSDs use cpu or processor sets functions and commands.
Mac OS X/Darwin supports either same or different thread cache affinity set and
tag /hints/ (which could be used like cpu sets), but only cache sharing cpu
counts, no explicit cpu identification or control.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] potrace 1.15-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* potrace-1.15-1
* libpotrace0-1.15-1
* libpotrace-devel-1.15-1

Potrace is a tool for tracing a bitmap, which means, transforming a
bitmap into a smooth, scalable image.  The input is a bitmap (PBM,
PGM, PPM, or BMP), and the default output is one of several vector
file formats.  A typical use is to create EPS files from scanned data,
such as company or university logos, handwritten notes, etc.  The
resulting image is not jaggy like a bitmap, but smooth.  It can then
be rendered at any resolution.

This is an update to the latest upstream release.

Ken Brown
Cygwin's potrace maintainer

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

potrace 1.15-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* potrace-1.15-1
* libpotrace0-1.15-1
* libpotrace-devel-1.15-1

Potrace is a tool for tracing a bitmap, which means, transforming a
bitmap into a smooth, scalable image.  The input is a bitmap (PBM,
PGM, PPM, or BMP), and the default output is one of several vector
file formats.  A typical use is to create EPS files from scanned data,
such as company or university logos, handwritten notes, etc.  The
resulting image is not jaggy like a bitmap, but smooth.  It can then
be rendered at any resolution.

This is an update to the latest upstream release.

Ken Brown
Cygwin's potrace maintainer

Re: More oddities with multiple processor groups

[Brian Inglis]

On 2018-04-11 12:05, Achim Gratz wrote:
> I seem to be the first to try Cygwin on a box that has multiple
> processor groups, which seems odd.  Anyway, I've already noticed two
> more things that indicate that Cygwin and/or Cygwin applications
> currently don't deal well with the situation:
> 
> 1. Trying to run top, it shows only the first 16 processors and then
> exits with an error that "openproc failed".  Interestingly enough it
> will keep running despite this error when running under strace (still
> only showing the processors from one group, presumably the one that top
> got started in).
> 
> 2. Git will correctly determine that it can use 32 threads for garbage
> collection, but it starts them all in the same processor group.
> 
> The problem here is that on Linux you don't need to do anything extra to
> use any of the advertised logical processors from a single application,
> while on Windows you need to first create a thread and set it's affinity
> to a different group than where your process was started in, then assign
> each new thread an affinity to one of the available groups.  If you
> don't do that, all threads will be restricted to the original group.
> 
> 
> Some more info on these differences (and already a bit outdated
> w.r.t. the way processor groups are formed):
> 
> https://software.intel.com/en-us/blogs/2010/12/16/tbb-30-high-end-many-cores-and-windows-processor-groups
> 
> If it would be possible for Cygwin to hide that ugliness from Cygwin
> applications I think that'd be highly welcome.  Otherwise there might
> need to be some option to restrict Cygwin to a single processor group
> for some applications to work (correctly).

Have you tried installing and running hwloc package to find out how it sees your
system?
If you run lstopo under X, you get a pretty diagram, but you can also run
lstopo-no-graphics aka hwloc-ls without X. Running "apropos hwloc" lists
commands you can use to manipulate the topology.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] teckit 2.5.7-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* teckit-2.5.7-1
* libteckit0-2.5.7-1
* libteckit-devel-2.5.7-1

TECkit is a low-level toolkit intended to be used by other
applications that need to perform encoding conversions (e.g., when
importing legacy data into a Unicode-based application).  The primary
component of the TECkit package is therefore a library that performs
conversions; this is the TECkit engine.  The engine relies on
mapping tables in a specific binary format (for which documentation is
available); there is a compiler that creates such tables from a
human-readable mapping description (a simple text file).

Ken Brown
Cygwin's TECkit maintainer

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

teckit 2.5.7-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* teckit-2.5.7-1
* libteckit0-2.5.7-1
* libteckit-devel-2.5.7-1

TECkit is a low-level toolkit intended to be used by other
applications that need to perform encoding conversions (e.g., when
importing legacy data into a Unicode-based application).  The primary
component of the TECkit package is therefore a library that performs
conversions; this is the TECkit engine.  The engine relies on
mapping tables in a specific binary format (for which documentation is
available); there is a compiler that creates such tables from a
human-readable mapping description (a simple text file).

Ken Brown
Cygwin's TECkit maintainer

Re: More oddities with multiple processor groups

[L A Walsh]

Achim Gratz wrote:

The problem here is that on Linux you don't need to do anything extra to
use any of the advertised logical processors from a single application,
while on Windows you need to first create a thread and set it's affinity
to a different group than where your process was started in, then assign
each new thread an affinity to one of the available groups.  If you
don't do that, all threads will be restricted to the original group.


Not exactly true.  They are not *restricted* -- it's a *feature*
of the Windows scheduler, in that future procs/threads inherit the
cpu of the parent.  Linux's scheduler is more advanced as well as
being replaceable.  MS doesn't want you to do that


there might
need to be some option to restrict Cygwin to a single processor group
for some applications to work (correctly).

---
	There is.  Start them all on a single cpu & set the cpu 
mask.  Pretty much the same way you restrict procs on linux --

you can run them with a specific cpu mask, and most programs will
keep running w/that mask.

Unfortunately, AFAIK, I don't think POSIX specifies
a way to set affinities, so I'm not sure how cygwin would do it.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [Bug] File permissions across domains

[Corinna Vinschen]

On Apr 12 21:16, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I inspected the source code which handles this kind of thing.  What it
> > does is to ask Windows for permissions of SID X on file Y, using AuthZ.
> 
> That seems to be working correctly.  For all old domain SID I've looked
> at, they've been prefixed by 0x7FFF when seen by the new domain
> machine, so both the SID and conversion of uid/gid works correctly.  If
> it didn't I'd not be able to see my homedir and other stuff too.

That's not what I was talking about.  Of course the SIDs are correct,
but that has nothing to do with file permission evaluation.  AuthZ
is only doing the latter.

> > See sec_acl.cc, line 1127ff.  This calls a function
> > authz_get_user_attribute which in turn calls a method
> > authz_ctx::get_user_attribute, sec_helper.cc, line 811ff.
> >
> > This method checks if the owner of the file is the current user.  Given
> > this test is done using SIDs, not Cygwin uids, this should be you, *iff*
> > you're logged in as the same user on both machines at the time you
> > created the above output.  This in turn should create the Authz context
> > for the current user from the current process token and the subsequent
> > AuthzAccessCheck should give the same result on both machines.
> 
> I've looked briefly at the source code, but I don't really see what's
> going on.

It's dirt easy:

1. fetch an AuthZ context for the current user from the current
   process token:

 AuthzInitializeContextFromToken

2. Ask AuthZ for the permissions on file Y:

 AuthzAccessCheck

authz_ctx::get_user_attribute is really only a few lines.

> While poking around, I noticed that the error/bug is far more
> specific than I thought:
> 
> The merging of the access rights bestowed by access groups is working
> correctly if the file is not owned by the current user, but fails if
> it's owned by the current user.  I have a second account that I must use
> for doing anything administrative and it's also in the old domain.

Ok.  However, MSDN explicitely suggests to fetch the AuthZ context
from the current user token, if the idea is to ask for the permissions
of the current user.  It's much less costly than calling
AuthzInitializeContextFromSid.

Is your account an admin account by any chance?  If so, does it work if
you run in an elevated shell?

I'm reluctant to switch to AuthzInitializeContextFromSid all the time
for the reasons outlined above.

> > One reason could be that you're member of OLD+cygwinupload only on the
> > old machine, while this group is not in your current process token when
> > logged in on your NEW machine.  You should check your token.  In terms
> > of group membership an `id' call should suffice.  But there may be
> > other differences in the token.
> 
> That all seems to be correct as far as I can tell.

I don't understand what you're trying to say here.  Are there
differences or not?

> > If that's not the problem, you will have to debug this, because
> > only you have access to this environment.
> 
> Given the sheer size of the function I'd appreciate if you could point
> out on which line the decision is made whether the file is owned by me
> or not.

I pointed pretty much exactly at the lines in question.  The decision is
made in authz_ctx::get_user_attribute, as is the AuthZ call to ask for
the actual permissions, just two AuthZ calls and a mere 50 lines of
code.

Only if the owner SID is not the current user,
authz_ctx::get_user_attribute calls authz_ctx_cache::context, just
a few lines above, and also only about 30 lines of code.

Worst of all, there are comments!


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Problem with NC.1.107

[Brian Inglis]

On 2018-04-13 02:44, L A Walsh wrote:
> Jay Cotton wrote:
> You said:
>> I don't see the PE32+ executable (console) x86-64, for MS Windows
>>> >>> string.
> Whereas, when I used the file command, it printed out exactly
> what you were searching for.  Thus my assertion that your file
> command is the likely culprit.
>> file /usr/bin/nc
>> /usr/bin/nc: PE32+ executable (console) x86-64 (stripped to external PDB),
>> for MS Windows
> As for the not-executable error message, have you checked,
> as suggested elsewhere, whether or not you have some cheap
> anti-virus installed that blocks programs that are not viruses
> like 'nc'?

Try:
$ which file nc | xargs ls -glo
-rwxr-xr-x 1 22035 Mar 18 08:18 /usr/bin/file
-rwxr-xr-x 1 24576 Mar 19  2013 /usr/bin/nc
$ which file nc | xargs file
/usr/bin/file: PE32+ executable (console) x86-64, for MS Windows
/usr/bin/nc:   PE32+ executable (console) x86-64 (stripped to external PDB), for
MS Windows
$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc cygwin.com 80
HTTP/1.1 200 OK
Date: Fri, 13 Apr 2018 11:45:41 GMT
Server: Apache
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Security-Policy: default-src 'self' http: https:
Connection: close
Content-Type: text/html; charset=UTF-8

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Incorrect /proc/cpuinfo for AMD A6-9220

[Corinna Vinschen]

On Apr 12 23:01, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I'm working on an AMD A6-9220 and seeing unusual results from
> /proc/cpuinfo. I think this may be an issue with the latest Cygwin. It
> may be present in earlier versions, too.
> 
> Russinovich's coreinfo is shown below
> (https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo).
> Notice /proc/cpuinfo is missing aesni, pclmul, rdrand, SSE4.1, SSE4.2,
> AVX, etc.

Note that, in theory, cpuinfo has to be extended for each new CPU
generation.  That's a lot of work for marginal gain (Cygwin's not a real
kernel) so I'm doing this only very seldomly.

Patches welcome, of course!


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Gestour Venditravels

[Andrey Repin]

Greetings, Antonio Sanchez!

No top-posting in the list, please. And retain list messages in list.
And please teach your email client to not quote raw email addresses.


>> Greetings, Angelina Anglade!
>>  
 >>> *Mise a jour de Gestour Windows...*
 >>> *      0 [main] rsync 2052 find_fast_cwd: WARNING: Couldn't compute
 >>> FAST_CWD pointer.  Please report this problem to*
 >>> *the public mailing list cygwin@cygwin.com *
>>  
>>  This is mostly harmless warning. Which was fixed over a decade ago.
>>  Please see
>> https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
>>  for details.



> the problem is not the warning but what comes after that (see screenshot
> attached): a connection timeout to updte.gestour.com and a warning that the 
> program "prjCli.exe" is not found. 


> System: We are using it on Windows 10 Pro. The last version of cygwin is
> installed.

You did not read the FAQ entry, did you?
In modern Cygwin, the message is different.

> We have tried in two different computers. 
> Firewal: We deactivated our firewall and even tryied using an VPN. 

> There is anything we can do about it?

Yes. First, update your Cygwin and ensure it is the only version installed.
Then use simpler network diagnostic tools, such as telnet, to ensure the
address/port you are attempting to connect to is actually reachable.


-- 
With best regards,
Andrey Repin
Friday, April 13, 2018 14:24:03

Sorry for my terrible english...
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with NC.1.107

[L A Walsh]

Jay Cotton wrote:

Here is the package listing at cygwin

nc: A simple but powerful network tool (installed binaries and support
files)

2013-03-19 15:35   0 usr/
2013-03-19 15:35   0 usr/bin/
2013-03-19 15:35   24576 usr/bin/nc.exe
2013-03-19 15:35   0 usr/share/
2013-03-19 15:35   0 usr/share/man/
2013-03-19 15:35   0 usr/share/man/man1/
2013-03-19 15:305052 usr/share/man/man1/nc.1.gz



---
Right.  It has the two files I mentioned below, and
nc.exe isn't a text file or makefile -- but is shown by the
cygwin "file" command as an executable.


You said:

I don't see the PE32+ executable (console) x86-64, for MS Windows

>>> string.


Whereas, when I used the file command, it printed out exactly
what you were searching for.  Thus my assertion that your file
command is the likely culprit.


file /usr/bin/nc
>>
/usr/bin/nc: PE32+ executable (console) x86-64 (stripped to external PDB),
for MS Windows



As for the not-executable error message, have you checked,
as suggested elsewhere, whether or not you have some cheap
anti-virus installed that blocks programs that are not viruses
like 'nc'?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple