si_band member of struct siginfo_t is not available
Hi. One more thing that I have noticed, the `si_band` member of `struct siginfo_t` is not available. See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html. -- VH -- 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: Shares with strange ACL settings
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 Core i5-3320M 0x80083024 0x801e0007 0340 0340 Regards, Achim. -- 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
FindFirstFile fails for some network directories
Hi,
I have 2 network shares with similar contents:
\\netapp1\CM\CompilationResults
\\aclnas01\versions\CompilationResults
Trying to list all the files within these directories using Ruby
succeeds for netapp1, but fails for aclnas01.
The failing ruby command is:
ruby -e print Dir.glob('//aclnas01/versions/CompilationResults/*')
The exact same command succeeds when executed from a normal command
prompt, or when the directory is on netapp1 (on both shells).
After debugging Ruby, I found out that FindFirstFile returns an
INVALID_HANDLE when invoked from cygwin environment.
The following application succeeds on command prompt and fails on cygwin:
#include stdio.h
#include windows.h
int main()
{
const TCHAR *aclnas = TEXT(//aclnas01/versions/CompilationResults);
const TCHAR *netapp = TEXT(//netapp1/CM/CompilationResults);
WIN32_FIND_DATA fd;
printf(%d\n, FindFirstFile(aclnas, fd) !=
INVALID_HANDLE_VALUE); // Fails on cygwin
printf(%d\n, FindFirstFile(netapp, fd) !=
INVALID_HANDLE_VALUE); // Always succeeds
return 0;
}
Output on cmd is 1 1, on cygwin it is 0 1.
Process Monitor shows that when executed from cygwin, CreateFile is
called with Open for Backup flag. I can't say for sure if this causes
the failure, but that's the only difference I could find between these
executions.
This bug was previously reported on github/msys2[1], but it wasn't solved.
I only have read access to these servers, but I might have cooperation
of the sys admin (can't promise though).
Any help will be appreciated.
Thanks,
- Orgad
[1] https://github.com/Alexpux/MSYS2-packages/issues/242
--
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: Shares with strange ACL settings
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 0x80083030 5007 0x801e0021 0100 0100 Regards, Achim. -- 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: Shares with strange ACL settings
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 178bfbff 0x800100600f20 3000 01ebbfff 2fd3fbff 0x80083030 5007 0x801e0021 0100 0100 Thank you, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpC4wi73fnX_.pgp Description: PGP signature
Re: Shares with strange ACL settings
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 Piledriver Opteron 6328 in the 2012R2 server, Cygwin
reports 8 cores. Linux on the other hand would report 8 processors on 4
cores (SMT, like HT on Intel). I don't know where you get the topology
information from,
The code is loosly based on what the Linux kernel does, combined with
the information given in
http://wiki.osdev.org/Detecting_CPU_Topology_%2880x86%29
So on AMD the topo is taken from cpuids 0x8008 and 0x0001,
but I may have made a mistake there.
[...digging...]
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:
#include stdio.h
#include stdint.h
static inline void __attribute ((always_inline))
cpuid (uint32_t *a, uint32_t *b, uint32_t *c, uint32_t *d,
uint32_t ain, uint32_t cin)
{
asm volatile (cpuid
: =a (*a), =b (*b), =c (*c), =d (*d)
: a (ain), c (cin));
}
int
main ()
{
uint32_t eax, ebx, ecx, edx;
cpuid (eax, ebx, ecx, edx, 0x8008, 0);
printf (0x8008%08x %08x %08x %08x\n, eax, ebx, ecx, edx);
}
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp4iQ2eAymVF.pgp
Description: PGP signature
Re: Shares with strange ACL settings
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 0x80083030 5007 For reference: i5-3320M 0x80083024 Regards, Achim. -- 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: Cygwin version detection at run time
On 14 August 2015 at 17:44, Corinna Vinschen wrote: On Aug 14 17:08, Václav Haisman wrote: On 14 August 2015 at 16:11, Eliot Moss wrote: On 8/14/2015 9:56 AM, Václav Haisman wrote: Hi. I am trying to find out Cygwin version at run time. I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API for this. However, it seems that the `cygwin_version_info` structure this call is supposed to fill in is not publicly available and is only declared internally in `winsup/cygwin/cygwin_version.h`. Am I right that my only option is either to copy the internal declaration of the structure or to use `/proc/version` and parse the version string out of that? There's uname, whose options allow getting various parts of what /proc/version gives you. uname is also somewhat portable across different flavors of linux ... Never mind, I have figured it out. The `cygwin_internal (CW_GETVERSIONINFO)` actually returns a pointer to string which can be parsed reliably. I have used it. cygwin_internal(CW_GETVERSIONINFO) is an API for non-Cygwin tools like cygcheck, not for general consumption. For a Cygwin executable, better use uname(2) instead. Thanks. Uname call's utsname structure is much easier to parse. -- VH -- 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: si_band member of struct siginfo_t is not available
Hi Václav, On Aug 17 12:36, Václav Haisman wrote: Hi. One more thing that I have noticed, the `si_band` member of `struct siginfo_t` is not available. See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html. si_band is optional and requires support for SIGPOLL, which isn't implemented in Cygwin. Patches absolutely welcome. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2R3Xhif3q_.pgp Description: PGP signature
Re: ucontext_t is not available from signal.h
On Aug 17 12:28, Václav Haisman wrote: Hi. I have just noticed, while porting my stuff from Linux to Cygwin, that signal.h does not provide `ucontext_t`. It should be available from signal.h. From http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html: The ucontext_t and mcontext_t structures are added here from the obsolescent ucontext.h header. That's a bit tricky, given the split of signal.h between newlib and Cygwin. Any suggestions how to fix it? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpuAVFpR6IL0.pgp Description: PGP signature
Re: [PATCH] mkglobals: Fix EOL detection
On Aug 17 10:41, Orgad Shaneh wrote: When globals.cc has CRLF line endings, winsup.h is not removed, and compilation fails for duplicate definitions. Applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpsnOBFpWLDP.pgp Description: PGP signature
ucontext_t is not available from signal.h
Hi. I have just noticed, while porting my stuff from Linux to Cygwin, that signal.h does not provide `ucontext_t`. It should be available from signal.h. From http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html: The ucontext_t and mcontext_t structures are added here from the obsolescent ucontext.h header. -- VH -- 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
[newlib-cygwin] mkglobals_h: Handle CRLF earlier.
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ede983934cd75d8149e9fcd1b8419c1db6ada1fa
commit ede983934cd75d8149e9fcd1b8419c1db6ada1fa
Author: Orgad Shaneh org...@gmail.com
Date: Mon Aug 17 11:05:20 2015 +0200
mkglobals_h: Handle CRLF earlier.
When globals.cc has CRLF line endings, winsup.h is not removed, and
compilation fails for duplicate definitions.
Signed-off-by: Corinna Vinschen cori...@vinschen.de
Diff:
---
winsup/cygwin/ChangeLog | 4
winsup/cygwin/mkglobals_h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 3a2f981..03a850a 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,7 @@
+2015-08-17 Orgad Shaneh org...@gmail.com
+
+ * mkglobals_h: Handle CRLF earlier.
+
2015-08-17 Corinna Vinschen cori...@vinschen.de
* fhandler_proc.cc (format_proc_cpuinfo): Print cpb and eff_freq_ro
diff --git a/winsup/cygwin/mkglobals_h b/winsup/cygwin/mkglobals_h
index ea4a582..2d185f2 100755
--- a/winsup/cygwin/mkglobals_h
+++ b/winsup/cygwin/mkglobals_h
@@ -1,6 +1,7 @@
#!/usr/bin/perl
my @argv = @ARGV;
$_ = join('', );
+s/\s+\n/\n/sog;
s/\n[^\n]*!globals.h[^\n]*\n/\n/sog;
s%/\*.*?\*/%%sog;
s/(enum\s.*?{.*?})/munge($1)/soge;
@@ -12,7 +13,6 @@ s/^\n+//sog;
s/#include winsup\.h\n//so;
s/-NL-/\n/sog;
s/-EQ-/=/sog;
-s/\s+\n/\n/sog;
s/\n{2,}/\n/sog;
print PRELUDE,$_;
/* $target - Autogenerated from @argv. Look there for comments. */
Re: Shares with strange ACL settings
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 0x801e0025 0102 0101 Sorry, forgot one :(. What's the output of cpuid 0x0001? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptl7gEv9sPO.pgp Description: PGP signature
Re: Shares with strange ACL settings
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 :) Opteron 6328 0x000100600f20 01080800 3e98320b 178bfbff 0x800100600f20 3000 01ebbfff 2fd3fbff 0x80083030 5007 0x801e0021 0100 0100 Uhm... one last question? What's the output of `lscpu'? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpuVj0u3rWT9.pgp Description: PGP signature
X Windows disappearing/unmapping (Win10 + 3rd party virtual desktops)
ENVIRONMENT: OS: Windows 10 Pro 64-bit Cygwin: setup 2.871 X11 1.17.2 (x86_64-unknown-cygwin); package version 1.17.2-1 built 2015-07-09 xterm 318-1 OTHER: 3rd party virtual desktop managers - have tried with - dexpot 1.6 - virtuawin 4.3 WHAT HAPPENS: 1. I start mintty, which starts bash. 2. I start an X server; DISPLAY=:0 3. I start an xterm on the local host, to $DISPLAY. 4. I switch to another desktop on the desktop manager. 5. I return to that window, and the xterm window vanishes. - the processes bound to the window are still running, as is the xterm itself. 6. I see no way to access or return the window to the desktop. * even winlister no longer can access the window handle. The window just hops off the deep end, never to be seen again, but everything connected with that window remains present. The only desktop manager it works with is the one that comes with Win10, but that lacks some features; notably, the ability to directly access a desktop with a keystroke. It is just not a viable alternative. WHY I AM SUBMITTING THIS AS A CYGWIN BUG: Because this happens as a result of using at least two different non-microsoft desktop managers, and ONLY X11-based applications are vanishing (xterm plus, as a test, xfd). --*greywolf; -- 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: Shares with strange ACL settings
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 0x8008: Opteron 6328 0x80083030 5007 Thanks. Can you please also show me the output of cpuid 0x801e? Looks like newer AMDs provide additional topology info... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNJeVzU4T0W.pgp Description: PGP signature
Re: commands spends time in cygheap_user
Attached my console log ( cygwin-time-lag.txt http://cygwin.1069669.n5.nabble.com/file/n120585/cygwin-time-lag.txt ) to shorten this message. nsswitch.conf contains only files entries. The time lag can be reproduced and is now shown at the cygheap_user log entry as described previously. I added the alias definition of 'ls' and the cygcheck info about the used cygwin1.dll. -- View this message in context: http://cygwin.1069669.n5.nabble.com/commands-spends-time-in-cygheap-user-tp119766p120585.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Shares with strange ACL settings
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: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: cmake-3.3.1-1
Version 3.3.1-1 of packages cmake cmake-gui cmake-doc cmake-debuginfo emacs-cmake are available in the Cygwin distribution. CHANGES - For 3.2 release notes, see http://www.cmake.org/cmake/help/v3.2/release/3.2.html - For 3.3 release notes, see http://www.cmake.org/cmake/help/v3.3/release/3.3.html - The cmake-gui package is now built using Qt5, cherry-picking a patch from ports DESCRIPTION CMake is a cross-platform makefile generation system, used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. HOMEPAGE http://www.cmake.org Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
[ANNOUNCEMENT] Updated: cmake-3.3.1-1
Version 3.3.1-1 of packages cmake cmake-gui cmake-doc cmake-debuginfo emacs-cmake are available in the Cygwin distribution. CHANGES - For 3.2 release notes, see http://www.cmake.org/cmake/help/v3.2/release/3.2.html - For 3.3 release notes, see http://www.cmake.org/cmake/help/v3.3/release/3.3.html - The cmake-gui package is now built using Qt5, cherry-picking a patch from ports DESCRIPTION CMake is a cross-platform makefile generation system, used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. HOMEPAGE http://www.cmake.org Best, Tony Kelman If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
[PATCH] sys/signal.h: include sys/ucontext.h on Cygwin per POSIX.1-2008
* libc/include/sys/signal.h [__CYGWIN__]: include sys/ucontext.h if compiling for POSIX.1-2008. Signed-off-by: Yaakov Selkowitz yselk...@redhat.com --- How about this? Other places I tried didn't compile. newlib/libc/include/sys/signal.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/newlib/libc/include/sys/signal.h b/newlib/libc/include/sys/signal.h index af5a489..e9aba7c 100644 --- a/newlib/libc/include/sys/signal.h +++ b/newlib/libc/include/sys/signal.h @@ -352,6 +352,12 @@ int _EXFUN(sigqueue, (pid_t pid, int signo, const union sigval value)); } #endif +#if defined(__CYGWIN__) +#if __POSIX_VISIBLE = 200809 +#include sys/ucontext.h +#endif +#endif + #ifndef _SIGNAL_H_ /* Some applications take advantage of the fact that sys/signal.h * and signal.h are equivalent in glibc. Allow for that here. */ -- 2.4.3 -- 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: Shares with strange ACL settings
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, but it'll take some time. No Linux on bare metal with Bulldozer/Piledriver, only an older K10 MagnyCours / Opteron 6174: Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):24 On-line CPU(s) list: 0-23 Thread(s) per core:1 Core(s) per socket:12 Socket(s): 2 NUMA node(s): 4 Vendor ID: AuthenticAMD CPU family:16 Model: 9 Stepping: 1 CPU MHz: 2200.091 BogoMIPS: 4400.10 Virtualization:AMD-V L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 5118K NUMA node0 CPU(s): 0,2,4,6,8,10 NUMA node1 CPU(s): 12,14,16,18,20,22 NUMA node2 CPU(s): 1,3,5,7,9,11 NUMA node3 CPU(s): 13,15,17,19,21,23 I don't have access to that system, so unfortunately I can't run your program. No worries and thank you. I just don't quite understand the stuff returned by 801e and what I see above. Do I understand this correctly that a single CPU has 2 NUMA nodes? Does that mean a single HW socket consists of two independent 6 core CPUs? Well, anyway, I just got remote access to a 2 socket systems with Opteron 6386SE CPUs. It's installing rhel7 right now so I might get another clue from there. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYfOJmWbfA2.pgp Description: PGP signature
Failed to activate core devices
I've been running Xwin Server for a long time and today it started failing with the cannot compile keymap error. To start, I made sure I had the latest version of all the packages. After updating everything it didn't help. I ran the various commands suggested by the topics I found on this error. They all returned the output expected. I then ran though the list of incompatible software and noticed that I have several however, as I said, this was all working until today. I've attached the log file FWIW but I don't know where to go from here to troubleshoot this. Any advice would be greatly appreciated. [ 7477.845] Welcome to the XWin X Server [ 7477.845] Vendor: The Cygwin/X Project [ 7477.845] Release: 1.17.2.0 [ 7477.861] OS: CYGWIN_NT-6.1 DAP001 2.2.0(0.289/5/3) 2015-08-03 12:51 x86_64 [ 7477.861] OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) [ 7477.861] Package: version 1.17.2-2 built 2015-08-11 [ 7477.861] [ 7477.876] winInitializeScreenDefaults - primary monitor w 1600 h 900 [ 7477.876] winInitializeScreenDefaults - native DPI x 96 y 96 [ 7477.892] XWin was started with the following command line: XWin [ 7477.907] (II) xorg.conf is not supported [ 7477.907] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 7477.907] LoadPreferences: /home/Dennis Putnam/.XWinrc not found [ 7477.907] LoadPreferences: Loading /etc/X11/system.XWinrc [ 7477.907] LoadPreferences: Done parsing the configuration file... [ 7477.954] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 7477.985] winDetectSupportedEngines - Returning, supported engines 0005 [ 7477.985] winSetEngine - Using Shadow DirectDraw NonLocking [ 7477.985] winScreenInit - Using Windows display depth of 32 bits per pixel [ 7478.017] winWindowProc - WM_SIZE - new client area w: 1584 h: 861 [ 7478.095] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 7479.327] MIT-SHM extension disabled due to lack of kernel support [ 7479.327] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 7479.327] (EE) AIGLX: No native OpenGL in modes with a root window [ 7479.483] (II) AIGLX: enabled GLX_EXT_texture_from_pixmap [ 7479.499] (II) AIGLX: Loaded and initialized swrast [ 7479.499] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 7497.080] (EE) Error compiling keymap (server-0) [ 7497.080] (EE) xkbcomp exit status 32512 [ 7497.080] (EE) XKB: Couldn't compile keymap [ 7497.080] (EE) XKB: Failed to load keymap. Loading default keymap instead. [ 7509.747] (EE) Error compiling keymap (server-0) [ 7509.747] (EE) xkbcomp exit status 32512 [ 7509.747] (EE) XKB: Couldn't compile keymap [ 7509.747] XKB: Failed to compile keymap [ 7509.747] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [ 7509.747] (EE) Fatal server error: [ 7509.747] (EE) Failed to activate core devices.(EE) [ 7509.763] (EE) Server terminated with error (1). Closing log file. signature.asc Description: OpenPGP digital signature
Re: Shares with strange ACL settings
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 nodes? Does that mean a single HW socket consists of two independent 6 core CPUs? In the case above, yes. MagnyCours is two Istanbul dies in one package. Well, anyway, I just got remote access to a 2 socket systems with Opteron 6386SE CPUs. It's installing rhel7 right now so I might get another clue from there. Yes, that should help. That's again two dies per package, each with 8 processors paired inside 4 modules. Each of the two die should be more or less identical to the 6328, save for clock frequency. Regards, Achim. -- 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: do package updates automatically kill running exes?
On 8/14/2015 2:28 PM, Achim Gratz wrote: Jon TURNEY writes: I don't understand why you need to do anything over and above what setup already does. Read on. Setup cannot replace /usr/bin/fish.exe while there is a running process with it loaded, and will request permission to kill those processes before trying to replace it (and if denied, schedule a replacement for the next reboot) His problem is that the process he wants to have killed has its executable deleted, not replaced (/usr/bin/fishd.exe). I haven't tested it, but I would guess that setup would need to kill it anyway because it could not be deleted while it was running. The opened EXE file can be marked for deletion and then renamed allowing the new file to be copied. The side effect would be a shutdown at a later time would delete the renamed file and the new process would start with the changed file. -- cyg Simple
[newlib-cygwin] Fix /proc/cpuinfo topology info on newer AMD CPUs
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=37b6936f8b6860cda5881127b8ac272ed528ac34
commit 37b6936f8b6860cda5881127b8ac272ed528ac34
Author: Corinna Vinschen cori...@vinschen.de
Date: Mon Aug 17 16:35:41 2015 +0200
Fix /proc/cpuinfo topology info on newer AMD CPUs
* fhandler_proc.cc (format_proc_cpuinfo): Handle AMDs providing
extended topology info in CPUID leaf 0x801e. Fix handling of
AMD CPUs providing extended legacy core info in CPUID leaf
0x8008.
Signed-off-by: Corinna Vinschen cori...@vinschen.de
Diff:
---
winsup/cygwin/ChangeLog| 6 ++
winsup/cygwin/fhandler_proc.cc | 30 +++---
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 03a850a..b026b0e 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,3 +1,9 @@
+2015-08-17 Corinna Vinschen cori...@vinschen.de
+
+ * fhandler_proc.cc (format_proc_cpuinfo): Handle AMDs providing
+ extended topology info in CPUID leaf 0x801e. Fix handling of
+ AMD CPUs providing extended legacy core info in CPUID leaf 0x8008.
+
2015-08-17 Orgad Shaneh org...@gmail.com
* mkglobals_h: Handle CRLF earlier.
diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc
index 55e13cd..5d05757 100644
--- a/winsup/cygwin/fhandler_proc.cc
+++ b/winsup/cygwin/fhandler_proc.cc
@@ -896,21 +896,37 @@ format_proc_cpuinfo (void *, char *destbuf)
}
else if (is_amd)
{
- if (maxe = 0x8008)
+ if (maxe = 0x801e)
+ {
+ uint32_t cus, core_info;
+
+ cpuid (unused, unused, core_info, unused, 0x8008);
+ cpuid (unused, cus, unused, unused, 0x801e);
+ siblings = (core_info 0xff) + 1;
+ logical_bits = (core_info 12) 0xf;
+ cus = ((cus 8) 0x3) + 1;
+ ht_bits = mask_bits (cus);
+ cpu_cores = siblings ht_bits;
+ }
+ else if (maxe = 0x8008)
{
uint32_t core_info;
cpuid (unused, unused, core_info, unused, 0x8008);
- cpu_cores = (core_info 0xff) + 1;
- siblings = cpu_cores;
+ siblings = (core_info 0xff) + 1;
+ cpu_cores = siblings;
+ logical_bits = (core_info 12) 0xf;
+ if (!logical_bits)
+ logical_bits = mask_bits (siblings);
+ ht_bits = 0;
}
else
{
- cpu_cores = (extra_info 16) 0xff;
- siblings = cpu_cores;
+ siblings = (extra_info 16) 0xff;
+ cpu_cores = siblings;
+ logical_bits = mask_bits (siblings);
+ ht_bits = 0;
}
- logical_bits = mask_bits (cpu_cores);
- ht_bits = 0;
}
phys_id = initial_apic_id logical_bits;
core_id = (initial_apic_id ((1 logical_bits) - 1)) ht_bits;
Cygwin R usability
Hi there, I read that there were issues (mainly with the BLAS library) in the Cygwin port of R (http://r.789695.n4.nabble.com/cygwin-R-2-14-0-build-fail-td4035136.html). And till today the official R site has not been supportive of the Cygwin version of R (https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Cygwin), while there are number of people using this unofficial port regardless of the caveats showed in the official R site (http://stackoverflow.com/search?q=R+cygwin). A thread on Stack Overflow was posted asking about this chaos (http://stackoverflow.com/questions/31962159/cygwin-r-usability) but nobody seemed to be able to address it fully as they are not Cygwin developers. Therefore I send this mail to the insiders and ask specifically for the current situation of the Cygwin port of R: -) Has the BLAS issue been addressed in the current Cygwin port of R? -) Beside the BLAS issue, is there any additional problem? Can it pass the building test? -) In short, is current Cygwin port of R (v3.1.3, 64-bit) usable in serious sense? Thanks to the efforts for porting R to Cygwin and more thanks in advance to anybody responding to this mail, Foehn
Re: Shares with strange ACL settings
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 metal with Bulldozer/Piledriver, only an older K10 MagnyCours / Opteron 6174: Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):24 On-line CPU(s) list: 0-23 Thread(s) per core:1 Core(s) per socket:12 Socket(s): 2 NUMA node(s): 4 Vendor ID: AuthenticAMD CPU family:16 Model: 9 Stepping: 1 CPU MHz: 2200.091 BogoMIPS: 4400.10 Virtualization:AMD-V L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 5118K NUMA node0 CPU(s): 0,2,4,6,8,10 NUMA node1 CPU(s): 12,14,16,18,20,22 NUMA node2 CPU(s): 1,3,5,7,9,11 NUMA node3 CPU(s): 13,15,17,19,21,23 I don't have access to that system, so unfortunately I can't run your program. Regards, Achim. -- 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
perl-Win32-GUI package doesn't appear in latest cygwin.
I have an application that is using perl-Win32-GUI and I have just checked that this package cannot be installed with latest setup-x86.exe and it doesn't appear in the list. Can you help me with this ?, is it maybe automatically included in any other package I have to install ?. Thanks a lot in advance.
Re: Failed to activate core devices
On 17/08/2015 14:05, Dennis Putnam wrote: I've been running Xwin Server for a long time and today it started failing with the cannot compile keymap error. To start, I made sure I had the latest version of all the packages. After updating everything it didn't help. I ran the various commands suggested by the topics I found on this error. They all returned the output expected. I then ran though the list of incompatible software and noticed that I have several however, as I said, this was all working until today. Unfortunately, it's the nature of these poorly understood incompatibilities that things appear to work, until one day something is different, and they don't. I've attached the log file FWIW but I don't know where to go from here to troubleshoot this. Any advice would be greatly appreciated. Perhaps you can run 'strace -o log XWin' and attach the resulting log file? This is similar to the problem reported in [1] [1] https://www.cygwin.com/ml/cygwin/2015-06/msg00149.html -- Jon TURNEY Volunteer Cygwin/X X Server 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
Re: Cygwin R usability
On 17/08/2015 15:41, foehn wrote: Hi there, I read that there were issues (mainly with the BLAS library) in the Cygwin port of R (http://r.789695.n4.nabble.com/cygwin-R-2-14-0-build-fail-td4035136.html). And till today the official R site has not been supportive of the Cygwin version of R (https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Cygwin), while there are number of people using this unofficial port regardless of the caveats showed in the official R site (http://stackoverflow.com/search?q=R+cygwin). A thread on Stack Overflow was posted asking about this chaos (http://stackoverflow.com/questions/31962159/cygwin-r-usability) but nobody seemed to be able to address it fully as they are not Cygwin developers. Therefore I send this mail to the insiders and ask specifically for the current situation of the Cygwin port of R: R developers have a peculiar view on Cygwin. For them what is not build by them is unsupported. In this view almost all cygwin software is unsupported. -) Has the BLAS issue been addressed in the current Cygwin port of R? Cygwin build use the integrated R BLAS patched, not Lapack one. So handling of NaN is as expected by R. -) Beside the BLAS issue, is there any additional problem? Can it pass the building test? It pass most of tests. There are some failures on IO formatting, but I never investigated the root cause. -) In short, is current Cygwin port of R (v3.1.3, 64-bit) usable in serious sense? I expect so. If you find any serious issue, let me know. Thanks to the efforts for porting R to Cygwin and more thanks in advance to anybody responding to this mail, Foehn Regards Marco -- 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: Shares with strange ACL settings
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 Opteron(tm) Processor 6328 stepping: 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping: 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 2 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping: 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 3 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping: 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 1 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 4 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping: 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 5 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping: 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0
Re: X Windows disappearing/unmapping (Win10 + 3rd party virtual desktops)
I had this same problem with Dexpot and found a solution. Please see these posts: https://cygwin.com/ml/cygwin/2015-08/msg00137.html https://cygwin.com/ml/cygwin/2015-08/msg00148.html On Mon, Aug 17, 2015 at 4:07 AM, Greywolf greyw...@starwolf.com wrote: ENVIRONMENT: OS: Windows 10 Pro 64-bit Cygwin: setup 2.871 X11 1.17.2 (x86_64-unknown-cygwin); package version 1.17.2-1 built 2015-07-09 xterm 318-1 OTHER: 3rd party virtual desktop managers - have tried with - dexpot 1.6 - virtuawin 4.3 WHAT HAPPENS: 1. I start mintty, which starts bash. 2. I start an X server; DISPLAY=:0 3. I start an xterm on the local host, to $DISPLAY. 4. I switch to another desktop on the desktop manager. 5. I return to that window, and the xterm window vanishes. - the processes bound to the window are still running, as is the xterm itself. 6. I see no way to access or return the window to the desktop. * even winlister no longer can access the window handle. The window just hops off the deep end, never to be seen again, but everything connected with that window remains present. The only desktop manager it works with is the one that comes with Win10, but that lacks some features; notably, the ability to directly access a desktop with a keystroke. It is just not a viable alternative. WHY I AM SUBMITTING THIS AS A CYGWIN BUG: Because this happens as a result of using at least two different non-microsoft desktop managers, and ONLY X11-based applications are vanishing (xterm plus, as a test, xfd). --*greywolf; -- 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 -- Nem W Schlecht Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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: perl-Win32-GUI package doesn't appear in latest cygwin.
On 17/08/2015 16:44, Javier Martin wrote: I have an application that is using perl-Win32-GUI and I have just checked that this package cannot be installed with latest setup-x86.exe and it doesn't appear in the list. Can you help me with this ?, is it maybe automatically included in any other package I have to install ?. Thanks a lot in advance. Removed during the last Perl 5.22 update https://cygwin.com/ml/cygwin-apps/2015-05/msg00048.html Regards Marco
Re: Shares with strange ACL settings
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 that. I referred to the cpuid output you provided and the matching info from your OP starting this subthread. Do I understand this correctly that a single CPU has 2 NUMA nodes? Does that mean a single HW socket consists of two independent 6 core CPUs? In the case above, yes. MagnyCours is two Istanbul dies in one package. Well, anyway, I just got remote access to a 2 socket systems with Opteron 6386SE CPUs. It's installing rhel7 right now so I might get another clue from there. Yes, that should help. That's again two dies per package, each with 8 processors paired inside 4 modules. Each of the two die should be more or less identical to the 6328, save for clock frequency. Indeed, looking into the output provided by the 6328SE and some 12 core MagnyCours CPU I forgot the number of, was helpful. I *think* I fixed the cpuinfo now for new AMDs which provide 0x81e topology info. Please give the latest snapshot from https://cygwin.com/snapshots/ a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp96xWkWRhiZ.pgp Description: PGP signature
Re: Shares with strange ACL settings
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 model : 2 model name : AMD Opteron(tm) Processor 6328 stepping: 0 cpu MHz : 3200.000 cache size : 2048 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs sse5 skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro ^^^ And those work too, cool. Thanks for testing, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPaK0YUtwdb.pgp Description: PGP signature
[newlib-cygwin] Try harder to avoid LDAP access for RFC2307 mapping
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=88dce3abd82c49ef879e6babcd91c1977dc212d9
commit 88dce3abd82c49ef879e6babcd91c1977dc212d9
Author: Corinna Vinschen cori...@vinschen.de
Date: Mon Aug 17 20:24:49 2015 +0200
Try harder to avoid LDAP access for RFC2307 mapping
* fhandler_disk_file.cc (fhandler_base::fstat_by_nfs_ea): Rearrange
to fall back to myself uid/gid in case we don't utilize Windows
account DBs, just as prior to 1.7.34.
* sec_helper.cc (cygpsid::get_id): Disable Samba user/group mapping
per
RFC2307 if we're not utilizing Windows account DBs.
* security.cc (convert_samba_sd): Revert previous patch.
Signed-off-by: Corinna Vinschen cori...@vinschen.de
Diff:
---
winsup/cygwin/ChangeLog | 9 +
winsup/cygwin/fhandler_disk_file.cc | 69 +
winsup/cygwin/sec_helper.cc | 4 +--
winsup/cygwin/security.cc | 10 +++---
4 files changed, 55 insertions(+), 37 deletions(-)
diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index b026b0e..6696d50 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,5 +1,14 @@
2015-08-17 Corinna Vinschen cori...@vinschen.de
+ * fhandler_disk_file.cc (fhandler_base::fstat_by_nfs_ea): Rearrange
+ to fall back to myself uid/gid in case we don't utilize Windows
+ account DBs, just as prior to 1.7.34.
+ * sec_helper.cc (cygpsid::get_id): Disable Samba user/group mapping per
+ RFC2307 if we're not utilizing Windows account DBs.
+ * security.cc (convert_samba_sd): Revert previous patch.
+
+2015-08-17 Corinna Vinschen cori...@vinschen.de
+
* fhandler_proc.cc (format_proc_cpuinfo): Handle AMDs providing
extended topology info in CPUID leaf 0x801e. Fix handling of
AMD CPUs providing extended legacy core info in CPUID leaf 0x8008.
diff --git a/winsup/cygwin/fhandler_disk_file.cc
b/winsup/cygwin/fhandler_disk_file.cc
index 08ce81f..455c478 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -343,36 +343,47 @@ fhandler_base::fstat_by_nfs_ea (struct stat *buf)
buf-st_mode = (nfs_attr-mode 0xfff)
| nfs_type_mapping[nfs_attr-type 7];
buf-st_nlink = nfs_attr-nlink;
- /* Try to map UNIX uid/gid to Cygwin uid/gid. If there's no mapping in
- the cache, try to fetch it from the configured RFC 2307 domain (see
- last comment in cygheap_domain_info::init() for more information) and
- add it to the mapping cache. */
- buf-st_uid = cygheap-ugid_cache.get_uid (nfs_attr-uid);
- buf-st_gid = cygheap-ugid_cache.get_gid (nfs_attr-gid);
- if (buf-st_uid == ILLEGAL_UID cygheap-pg.nss_pwd_db ())
-{
- uid_t map_uid = ILLEGAL_UID;
-
- domain = cygheap-dom.get_rfc2307_domain ();
- if ((ldap_open = (cldap.open (domain) == NO_ERROR)))
- map_uid = cldap.remap_uid (nfs_attr-uid);
- if (map_uid == ILLEGAL_UID)
- map_uid = MAP_UNIX_TO_CYGWIN_ID (nfs_attr-uid);
- cygheap-ugid_cache.add_uid (nfs_attr-uid, map_uid);
- buf-st_uid = map_uid;
-}
- if (buf-st_gid == ILLEGAL_GID cygheap-pg.nss_grp_db ())
-{
- gid_t map_gid = ILLEGAL_GID;
-
- domain = cygheap-dom.get_rfc2307_domain ();
- if ((ldap_open || cldap.open (domain) == NO_ERROR))
- map_gid = cldap.remap_gid (nfs_attr-gid);
- if (map_gid == ILLEGAL_GID)
- map_gid = MAP_UNIX_TO_CYGWIN_ID (nfs_attr-gid);
- cygheap-ugid_cache.add_gid (nfs_attr-gid, map_gid);
- buf-st_gid = map_gid;
+ if (cygheap-pg.nss_pwd_db ())
+{
+ /* Try to map UNIX uid/gid to Cygwin uid/gid. If there's no mapping in
+the cache, try to fetch it from the configured RFC 2307 domain (see
+last comment in cygheap_domain_info::init() for more information) and
+add it to the mapping cache. */
+ buf-st_uid = cygheap-ugid_cache.get_uid (nfs_attr-uid);
+ if (buf-st_uid == ILLEGAL_UID)
+ {
+ uid_t map_uid = ILLEGAL_UID;
+
+ domain = cygheap-dom.get_rfc2307_domain ();
+ if ((ldap_open = (cldap.open (domain) == NO_ERROR)))
+ map_uid = cldap.remap_uid (nfs_attr-uid);
+ if (map_uid == ILLEGAL_UID)
+ map_uid = MAP_UNIX_TO_CYGWIN_ID (nfs_attr-uid);
+ cygheap-ugid_cache.add_uid (nfs_attr-uid, map_uid);
+ buf-st_uid = map_uid;
+ }
+}
+ else /* fake files being owned by current user. */
+buf-st_uid = myself-uid;
+ if (cygheap-pg.nss_grp_db ())
+{
+ /* See above */
+ buf-st_gid = cygheap-ugid_cache.get_gid (nfs_attr-gid);
+ if (buf-st_gid == ILLEGAL_GID)
+ {
+ gid_t map_gid = ILLEGAL_GID;
+
+ domain = cygheap-dom.get_rfc2307_domain ();
+ if ((ldap_open || cldap.open (domain) == NO_ERROR))
+ map_gid = cldap.remap_gid (nfs_attr-gid);
+ if (map_gid ==
[PATCH] mkglobals: Fix EOL detection
When globals.cc has CRLF line endings, winsup.h is not removed, and
compilation fails for duplicate definitions.
---
winsup/cygwin/mkglobals_h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/mkglobals_h b/winsup/cygwin/mkglobals_h
index ea4a582..2d185f2 100755
--- a/winsup/cygwin/mkglobals_h
+++ b/winsup/cygwin/mkglobals_h
@@ -1,6 +1,7 @@
#!/usr/bin/perl
my @argv = @ARGV;
$_ = join('', );
+s/\s+\n/\n/sog;
s/\n[^\n]*!globals.h[^\n]*\n/\n/sog;
s%/\*.*?\*/%%sog;
s/(enum\s.*?{.*?})/munge($1)/soge;
@@ -12,7 +13,6 @@ s/^\n+//sog;
s/#include winsup\.h\n//so;
s/-NL-/\n/sog;
s/-EQ-/=/sog;
-s/\s+\n/\n/sog;
s/\n{2,}/\n/sog;
print PRELUDE,$_;
/* $target - Autogenerated from @argv. Look there for comments. */
--
2.4.6.windows.1
Re: [PATCH] mkglobals: Fix EOL detection
On Aug 17 10:41, Orgad Shaneh wrote: When globals.cc has CRLF line endings, winsup.h is not removed, and compilation fails for duplicate definitions. Why on earth should globals.h get CRLF line endings? It's stored with LF line endings in git. There's no reason to convert the file. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBSGWLMtDQn.pgp Description: PGP signature
Re: [PATCH] mkglobals: Fix EOL detection
On Mon, Aug 17, 2015 at 10:59 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 17 10:41, Orgad Shaneh wrote: When globals.cc has CRLF line endings, winsup.h is not removed, and compilation fails for duplicate definitions. Why on earth should globals.h get CRLF line endings? It's stored with LF line endings in git. There's no reason to convert the file. globals.h is generated, I guess you refer to globals.cc. Well, git has a setting named core.autocrlf which converts line-endings to CRLF on Windows. This is very commonly used with msysGit and Git for Windows. If the cygwin repository is cloned with autocrlf set, then all the source files will have CRLF line endings, including globals.cc... - Orgad
[newlib-cygwin] Support cpb and eff_freq_ro power mgmt flags in /proc/cpuinfo
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=861a27db66fa86e3c745a5b4234063037c67ddf9 commit 861a27db66fa86e3c745a5b4234063037c67ddf9 Author: Corinna Vinschen cori...@vinschen.de Date: Mon Aug 17 10:04:33 2015 +0200 Support cpb and eff_freq_ro power mgmt flags in /proc/cpuinfo * fhandler_proc.cc (format_proc_cpuinfo): Print cpb and eff_freq_ro power management flags. Signed-off-by: Corinna Vinschen cori...@vinschen.de Diff: --- winsup/cygwin/ChangeLog| 5 + winsup/cygwin/fhandler_proc.cc | 4 2 files changed, 9 insertions(+) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index 6b82e32..3a2f981 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,3 +1,8 @@ +2015-08-17 Corinna Vinschen cori...@vinschen.de + + * fhandler_proc.cc (format_proc_cpuinfo): Print cpb and eff_freq_ro + power management flags. + 2015-08-15 Corinna Vinschen cori...@vinschen.de * fhandler.cc (fhandler_base_overlapped::raw_write): When performing diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc index 13311b8..55e13cd 100644 --- a/winsup/cygwin/fhandler_proc.cc +++ b/winsup/cygwin/fhandler_proc.cc @@ -1256,6 +1256,10 @@ format_proc_cpuinfo (void *, char *destbuf) print ( 100mhzsteps); if (features1 (1 7)) print ( hwpstate); + if (features1 (1 9)) + print ( cpb); + if (features1 (1 10)) + print ( eff_freq_ro); } if (orig_affinity_mask != 0)
Re: commands spends time in cygheap_user
On Aug 16 05:35, mku wrote: I changed cygwin1.dll to Version 2.2.1 and got the results shown in the attached log file ( cygwin-time-lag.txt http://cygwin.1069669.n5.nabble.com/file/n120553/cygwin-time-lag.txt ). I'm sorry to say that the problem has not disappeared with that patch. Too bad, I thought skipping the SID-uid mapping per RFC 2307 is the culprit. Are you sure your /etc/nsswitch.conf is set to passwd: files group: files Can you print it out, please? I'll try to reproduce this again in the next few days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJaZmj3yuQc.pgp Description: PGP signature
js185 package problem (was Re: Seg Fault in strftime)
On Aug 16 20:00, Michael Enright wrote: On Wed, Aug 5, 2015 at 1:02 AM, Corinna Vinschen wrote: On Aug 3 23:33, Michael Enright wrote: On Mon, Aug 3, 2015 at 9:52 AM, Michael Enright wrote: I'm interested in a solution at the libmozjs level Is there anything I can do to advance a solution in libmozjs? You could report the problem upstream, ideally. Since the behaviour is not restricted to Cygwin (at least glibc and OpenBSD both use the same way to handle tm_zone/tm_gmtoff in strftime), they should be interested in a fix. Looking at the upstream source it seems that they (mozilla.org) have done something to allow their configure script to detect tm_zone's presence. If the related configure variable HAVE_TM_ZONE_TM_GMTOFF is defined as a result of configure's testing, then some code is enabled that has the goal of getting those fields populated in the struct tm that is passed to strftime. The steps are to transfer values from the pseudo-tm struct they use to a temporary struct tm, call mktime with that to get a time_t, pass the time_t to localtime_r, and then use the resulting tm_zone and tm_gmtoffset values in the struct tm that they pass to strftime. To me this all means that mozilla.org has the proper code available and machinery to activate it. I think the only reason there's a crash is because this mozilla.org code is not enabled in cygwin's libmozjs185 for some reason. I cloned the git repo that mozilla.org makes available and ran the configure script. I was not able to build from the resulting setup, but I was able to confirm that the HAVE_TM_ZONE_TM_GMTOFF macro is defined. So the mozilla.org configure script does detect the members on current Cygwin headers. Since that is the case the next step is to look specifically at how libmozjs185 is built for distribution within Cygwin. Is there a possibility that the maintainer of Cygwin's library uses hand-modified configure output to get around some problem, and that stuff needs to be tweaked? Maybe the package just needs rebuilding. Yaakov? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpl8Js5hkEND.pgp Description: PGP signature
Re: OpenSSH client defaults
On Aug 16 17:24, Max Polk wrote: On a new 64-bit Cygwin install, no /etc/ssh* files or dirs exist, That's what /usr/bin/ssh-host-config is for. I copied over id_dsa and id_dsa.pub into my ~/.ssh, nothing else, and got the directory and file permissions right. Kept running into this failure connecting: debug1: Skipping ssh-dss key /MYPATH/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes If that's the new OpenSSH 7.0, then the deprecation information in the announcement probably explains the problem: https://cygwin.com/ml/cygwin-announce/2015-08/msg00021.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpXW5Ccuz_vg.pgp Description: PGP signature
Cygwin64: openssl target arch mismatch
Hi Everybody It seems that the Cygwin-X86_64 setup is installing the cygwin32 openssl package as show in the below window capture and the find command result. Did I miss something? FrancisANDRE@idefix /usr find . -name *ssl.a ./i686-pc-cygwin/sys-root/usr/lib/libssl.a ./lib/w32api/libw3ssl.a no libssl.a found in usr/x86_64-pc-cygwin/sys-root/usr/lib/ Regards FA Le 14/07/2015 09:39, Corinna Vinschen a écrit : Hi folks, I've updated the version of OpenSSL to 1.0.2d-1. This is a security bugfix release. OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References == URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html Peace, Corinna Le 14/07/2015 09:39, Corinna Vinschen a écrit : Hi folks, I've updated the version of OpenSSL to 1.0.2d-1. This is a security bugfix release. OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References == URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html Peace, Corinna This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx Cygwin Configuration Diagnostics Current System Time: Mon Aug 17 07:53:06 2015 Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 Path: C:\ASF\apache-ant-1.9.3\bin C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Program Files (x86)\GALITT\Common C:\ProgramData\Oracle\Java\javapath C:\Python33 C:\Windows\system32 C:\Windows
Problems with ssh connection
I have Cygwin installed on a couple of servers in a domain environment. Of all machines regular user accounts can ssh to only one box. Once installed I configured Cygwin using the following in a .bat file. c:\cygwin\bin\bash --login -c chmod +r /etc/passwd c:\cygwin\bin\bash --login -c chmod u+w /etc/passwd c:\cygwin\bin\bash --login -c chmod +r /etc/group c:\cygwin\bin\bash --login -c chmod u+w /etc/group c:\cygwin\bin\bash --login -c chown -R domain_account /var/empty c:\cygwin\bin\bash --login -c chmod 755 /var/empty c:\cygwin\bin\bash --login -c chown domain_account /etc/ssh* c:\cygwin\bin\bash --login -c chmod 755 /var/ c:\cygwin\bin\bash --login -c touch /var/log/sshd.log c:\cygwin\bin\bash --login -c chown domain_account /var/log/sshd.log c:\cygwin\bin\bash --login -c chmod 664 /var/log/sshd.log c:\cygwin\bin\bash --login -c editrights -l -u domain_account c:\cygwin\bin\bash --login -c editrights -a SeAssignPrimaryTokenPrivilege -u domain_account c:\cygwin\bin\bash --login -c editrights -a SeCreateTokenPrivilege -u domain_account c:\cygwin\bin\bash --login -c editrights -a SeTcbPrivilege -u domain_account c:\cygwin\bin\bash --login -c editrights -a SeServiceLogonRight -u domain_account c:\cygwin\bin\bash --login -c editrights -l -u domain_account c:\cygwin\bin\bash --login -c /bin/ssh-host-config -y -c ntsec -u domain_account -w “password Somehow the permissions on the sshd_config file are diferent on the box where the sftp connection works -rw-r--r-- 1 my_domain_account root 3679 Jul 24 12:44 /etc/sshd_config where on all others I see -rw-r--r-- 1 domain_account Administrators 3584 Jul 26 20:51 /etc/sshd_config where the domain_account is the account under which the Cygwin service is running. When checking NTFS permissions I see in both cases the domain_account as the owner. I read somewhere that I need to run chown root:system /etc/password to fix the permissions but the account reports as invalid. Same if I try just root or just system. Am I even close focusing on the permissions of sshd_config? No idea why they're different. I think I used the same method on all servers but there were not installed at the same time so it's possible I messed something up. I don't want to break the working box keeping it as a reference. On others I noticed that a regular domain user can connect when their accounts get added to local admins which is what I would like to avoid. -- 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: Please upgrade cygwin cmake to 3.3.0
Sorry for sending the first copy of my earlier message off-list accidentally (I keep doing that). Hi Tony, cmake 3.3.0 has the visual studio generator which is very handy on Windows system. I have tried the separated version on Windows with visual studio 14 generator, and it works well. Thanks, David The build of 3.3.1 is going smoothly so far, just checking unit tests now and should be able to upload soon. But I don't think the cygwin build of cmake includes the Visual Studio generator. It may have done so some time in the past, but none of the 3.x or 2.8.x versions I've run any time recently have done so. Did you see something in the release notes that led you to believe otherwise? I think you need to use a native build, like from CMake's website, to get the Visual Studio generator working. -Tony -- 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: perl-Win32-GUI package doesn't appear in latest cygwin.
Javier Martin writes: I have an application that is using perl-Win32-GUI and I have just checked that this package cannot be installed with latest setup-x86.exe and it doesn't appear in the list. Can you help me with this ?, is it maybe automatically included in any other package I have to install ?. No, this package simply doesn't build, on both architectures and all version from 1.06 to 1.12. There's some missing rules in makefiles and when you're past that you're getting compile errors someplace else. I've not followed it down that rabbit hole any further. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: Cygwin64: openssl target arch mismatch
On 8/17/2015 3:17 PM, zosrothko wrote: Hi Everybody It seems that the Cygwin-X86_64 setup is installing the cygwin32 openssl package as show in the below window capture and the find command result. Did I miss something? FrancisANDRE@idefix /usr find . -name *ssl.a ./i686-pc-cygwin/sys-root/usr/lib/libssl.a This is from the cygwin32-openssl package, which is intended for building 32-bit packages on 64-bit Cygwin. no libssl.a found in usr/x86_64-pc-cygwin/sys-root/usr/lib/ The directory /usr/x86_64-pc-cygwin/sys-root doesn't exist on 64-bit Cygwin. What you're looking for is /usr/lib/libssl.a, which is provided by the openssl-devel package. Ken -- 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
[newlib-cygwin] Don't call LsaLookupSids if we're not utilizing Windows account DBs
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=4cb24051f4dc5080dfc7f5cf4acb778a79744f45
commit 4cb24051f4dc5080dfc7f5cf4acb778a79744f45
Author: Corinna Vinschen cori...@vinschen.de
Date: Mon Aug 17 22:45:02 2015 +0200
Don't call LsaLookupSids if we're not utilizing Windows account DBs
* grp.cc (internal_getgrfull): Drop asking caches. Explain why.
(internal_getgroups): In case we're not utilizing the Windows
account
DBs, don't call LsaLookupSids but iterate over the group SIDs in the
token and call internal_getgrsid for each of them. Explain why.
Signed-off-by: Corinna Vinschen cori...@vinschen.de
Diff:
---
winsup/cygwin/ChangeLog | 7 +++
winsup/cygwin/grp.cc| 49 +
winsup/cygwin/release/2.2.1 | 5 +++--
3 files changed, 42 insertions(+), 19 deletions(-)
diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog
index 6696d50..a4d68b2 100644
--- a/winsup/cygwin/ChangeLog
+++ b/winsup/cygwin/ChangeLog
@@ -1,5 +1,12 @@
2015-08-17 Corinna Vinschen cori...@vinschen.de
+ * grp.cc (internal_getgrfull): Drop asking caches. Explain why.
+ (internal_getgroups): In case we're not utilizing the Windows account
+ DBs, don't call LsaLookupSids but iterate over the group SIDs in the
+ token and call internal_getgrsid for each of them. Explain why.
+
+2015-08-17 Corinna Vinschen cori...@vinschen.de
+
* fhandler_disk_file.cc (fhandler_base::fstat_by_nfs_ea): Rearrange
to fall back to myself uid/gid in case we don't utilize Windows
account DBs, just as prior to 1.7.34.
diff --git a/winsup/cygwin/grp.cc b/winsup/cygwin/grp.cc
index f850210..501db1a 100644
--- a/winsup/cygwin/grp.cc
+++ b/winsup/cygwin/grp.cc
@@ -152,17 +152,8 @@ internal_getgrfull (fetch_acc_t full_acc, cyg_ldap *pldap)
struct group *ret;
cygheap-pg.nss_init ();
- /* Check caches first. */
- if (cygheap-pg.nss_cygserver_caching ()
- (ret = cygheap-pg.grp_cache.cygserver.find_group (full_acc.sid)))
-return ret;
- if (cygheap-pg.nss_grp_files ()
- (ret = cygheap-pg.grp_cache.file.find_group (full_acc.sid)))
-return ret;
- if (cygheap-pg.nss_grp_db ()
- (ret = cygheap-pg.grp_cache.win.find_group (full_acc.sid)))
-return ret;
- /* Ask sources afterwards. */
+ /* Skip local caches, internal_getgroups already called
+ internal_getgrsid_cachedonly. */
if (cygheap-pg.nss_cygserver_caching ()
(ret = cygheap-pg.grp_cache.cygserver.add_group_from_cygserver
(full_acc.sid)))
@@ -598,7 +589,7 @@ internal_getgroups (int gidsetsize, gid_t *grouplist,
cyg_ldap *pldap)
size);
if (!NT_SUCCESS (status))
{
- system_printf (token group list 64K? status = %u, status);
+ debug_printf (NtQueryInformationToken(TokenGroups) %y, status);
goto out;
}
/* Iterate over the group list and check which of them are already cached.
@@ -627,16 +618,40 @@ internal_getgroups (int gidsetsize, gid_t *grouplist,
cyg_ldap *pldap)
else
sidp_buf[scnt++] = sid;
}
- /* If there are non-cached groups left, call LsaLookupSids and call
- internal_getgrfull on the returned groups. This performs a lot
- better than calling internal_getgrsid on each group. */
+ /* If there are non-cached groups left, try to fetch them. */
if (scnt 0)
{
+ /* Don't call LsaLookupSids if we're not utilizing the Windows account
+DBs. If we don't have access to the AD, which is one good reason to
+disable passwd/group: db in nsswitch.conf, then the subsequent call
+to LsaLookupSids will take 5 - 10 seconds in some environments. */
+ if (!cygheap-pg.nss_grp_db ())
+ {
+ for (DWORD pg = 0; pg scnt; ++pg)
+ {
+ cygpsid sid = sidp_buf[pg];
+ if ((grp = internal_getgrsid (sid, NULL)))
+ {
+ if (cnt gidsetsize)
+ grouplist[cnt] = grp-gr_gid;
+ ++cnt;
+ if (gidsetsize cnt gidsetsize)
+ {
+ cnt = -1;
+ break;
+ }
+ }
+ }
+ goto out;
+ }
+ /* Otherwise call LsaLookupSids and call internal_getgrfull on the
+returned groups. This performs a lot better than calling
+internal_getgrsid on each group. */
status = STATUS_ACCESS_DENIED;
HANDLE lsa = lsa_open_policy (NULL, POLICY_LOOKUP_NAMES);
if (!lsa)
{
- system_printf (POLICY_LOOKUP_NAMES not given?);
+ debug_printf (POLICY_LOOKUP_NAMES right not given?);
goto out;
}
status = LsaLookupSids (lsa, scnt, sidp_buf, dlst, nlst);
@@ -664,7 +679,7 @@ internal_getgroups (int gidsetsize, gid_t
Re: commands spends time in cygheap_user
On Aug 17 10:13, Corinna Vinschen wrote: On Aug 17 10:07, Corinna Vinschen wrote: On Aug 16 05:35, mku wrote: I changed cygwin1.dll to Version 2.2.1 and got the results shown in the attached log file ( cygwin-time-lag.txt http://cygwin.1069669.n5.nabble.com/file/n120553/cygwin-time-lag.txt ). I'm sorry to say that the problem has not disappeared with that patch. Too bad, I thought skipping the SID-uid mapping per RFC 2307 is the culprit. s/is the culprit/fixes the problem. Are you sure your /etc/nsswitch.conf is set to passwd: files group: files Can you print it out, please? I'll try to reproduce this again in the next few days. I managed to reproduce the issue and I think I found the actual problem here. When trying to create the supplementary group list of the current user, Cygwin called LookupAccountSids indiscriminately. If you don't have access to your AD, this call is bound to take some time, 5 to 10 secs in my testing. I changed the code so that when group: db is set in /etc/nsswitch.conf it will only utilize /etc/group to fetch group information. I uploaded a new developer snapshot containing this patch to https://cygwin.com/snapshots/ Please give it a try. For testing, just replace your current DLL with the snapshot DLL temporarily. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3om2pVrYot.pgp Description: PGP signature
Re: commands spends time in cygheap_user
On Aug 17 22:55, Corinna Vinschen wrote: On Aug 17 10:13, Corinna Vinschen wrote: On Aug 17 10:07, Corinna Vinschen wrote: On Aug 16 05:35, mku wrote: I changed cygwin1.dll to Version 2.2.1 and got the results shown in the attached log file ( cygwin-time-lag.txt http://cygwin.1069669.n5.nabble.com/file/n120553/cygwin-time-lag.txt ). I'm sorry to say that the problem has not disappeared with that patch. Too bad, I thought skipping the SID-uid mapping per RFC 2307 is the culprit. s/is the culprit/fixes the problem. Are you sure your /etc/nsswitch.conf is set to passwd: files group: files Can you print it out, please? I'll try to reproduce this again in the next few days. I managed to reproduce the issue and I think I found the actual problem here. When trying to create the supplementary group list of the current user, Cygwin called LookupAccountSids indiscriminately. If you don't have access to your AD, this call is bound to take some time, 5 to 10 secs in my testing. I changed the code so that when group: db is set in /etc/nsswitch.conf uhm, make that ...when group: files is set... it will only utilize /etc/group to fetch group information. I uploaded a new developer snapshot containing this patch to https://cygwin.com/snapshots/ Please give it a try. For testing, just replace your current DLL with the snapshot DLL temporarily. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9QOXZR1hdt.pgp Description: PGP signature
Re: commands spends time in cygheap_user
On Aug 17 10:07, Corinna Vinschen wrote: On Aug 16 05:35, mku wrote: I changed cygwin1.dll to Version 2.2.1 and got the results shown in the attached log file ( cygwin-time-lag.txt http://cygwin.1069669.n5.nabble.com/file/n120553/cygwin-time-lag.txt ). I'm sorry to say that the problem has not disappeared with that patch. Too bad, I thought skipping the SID-uid mapping per RFC 2307 is the culprit. s/is the culprit/fixes the problem. Are you sure your /etc/nsswitch.conf is set to passwd: files group: files Can you print it out, please? I'll try to reproduce this again in the next few days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfesIVmv_Af.pgp Description: PGP signature
Re: [PATCH] mkglobals: Fix EOL detection
On Aug 17 11:02, Orgad Shaneh wrote: On Mon, Aug 17, 2015 at 10:59 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 17 10:41, Orgad Shaneh wrote: When globals.cc has CRLF line endings, winsup.h is not removed, and compilation fails for duplicate definitions. Why on earth should globals.h get CRLF line endings? It's stored with LF line endings in git. There's no reason to convert the file. globals.h is generated, I guess you refer to globals.cc. Well, git has a setting named core.autocrlf which converts line-endings to CRLF on Windows. This is very commonly used with msysGit and Git for Windows. If the cygwin repository is cloned with autocrlf set, then all the source files will have CRLF line endings, including globals.cc... You should set core.autocrlf to no in Cygwin's local git config. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4CDRHseo10.pgp Description: PGP signature
Re: Shares with strange ACL settings
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 in correct POSIX permission evaluation for any current user and any file ACL. However, from some preliminary testing it seems the generic solution has at least two downsides: - It's slow (AuthZ code, setting up and breaking down user/group contexts for each checked file...) - It would always contact the AD when trying to fetch info for AD users, which is bad for remote machines not or slowly connected to the AD server. I think we've came to the same conclusion (modulo the question of whether AuthZ would be usable for this) some time ago. My personal take on this is that the kludge is likely better than both what we had before and the result of the pre-snapshot ACL evaluation. FYI, I revamped my AuthZ tests over the weekend and it's not *that* slow, especially if the application caches and reuses AuthZ user contexts fetched previosly. I have POC code in my local sandbox, and I'm planning to apply this to Cygwin after the 2.2.1 release. I have some hopes that the AuthZ code was the puzzle piece missing in the unified POSIX ACL handling code we tested and then had to drop again earlier this year. Stay tuned for another round of this unified POSIX ACL handling tests later this year. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpLen915_6QY.pgp Description: PGP signature
Re: Shares with strange ACL settings
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 reports 8 cores. Linux on the other hand would report 8 processors on 4 cores (SMT, like HT on Intel). I don't know where you get the topology information from, but Windows' task manager reports 4 cores with 8 logical processors and two NUMA nodes on this machine. Regards, Achim. -- 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
