Corinna Vinschen cygwin.com> writes:
> - Improve fork/exec performance on 64 bit systems.
If fork/exec became faster, something else has slowed down noticeably on my
64-bit Vista system. Using a fairly fork-heavy build script as the benchmark
(and running it when nothing needs to be re-built), 1
Hi,
Seems like Microsoft's driver IntelliPoint 8.15 64-bit for Windows Vista can
cause frequent STATUS_ACCESS_VIOLATION errors. Version 8.0 works fine though.
Just thought I should mention it, in case someone else sees a sudden rash of
STATUS_ACCESS_VIOLATION.
Magnus
--
Problem reports:
Eric Blake redhat.com> writes:
> >> I did some testing on my 64-bit Vista system, and it appears that
> >> CreateThread is the main cause.
> >
> > To test this, I removed the call to sigproc_init in dll_crt0_0 and made sure
> > it was always called in dll_crt0_1 instead. Suddenly the sigp thread
Magnus Holmgren gmail.com> writes:
> I did some testing on my 64-bit Vista system, and it appears that
> CreateThread is the main cause.
I think I've found the reason for the slow CreateThread. It seems like
the following remark in the MSDN documentation is relevant, at l
Sagi Ben-Akiva graphtech.co.il> writes:
> For the last couple of weeks I'm trying to identify the cause for cygwin
> slowdown on x64 machines which was reported by David Morgan about 6
> months ago.
<...>
> Any help will be appreciated.
I did some testing on my 64-bit Vista system, and it ap
Christopher Faylor cygwin.com> writes:
> Here's what I'm saying: It makes absolutely no sense that moving the
> call would have any effect. The code is the way it is for a reason
> so we're not going to just revert the change.
I think it makes sense, if the signal thread initialization takes t
Dr. Volker Zell oracle.com> writes:
> New versions of 'neon/libneon27/libneon-devel' have been uploaded to a server
near you.
>
> o Update to latest upstream
When running setup.exe, I noticed that this package includes a lot of new
dependencies, for Gnome (libORBit2_0, libglib2.0_0...), X (lib
Vince Indriolo gmail.com> writes:
> There is definitely something not right with my setup. I have 64-bit Windows
> 7
>
> e:\>echo foo > foo
> e:\>c:\cygwin\bin\ls.exe -l foo
> --+ 1 vince None 6 Sep 2 17:28 foo
>
> $ ls -l foo
> --+ 1 vince None 6 Sep 2 17:28 foo
Interestin
Corinna Vinschen cygwin.com> writes:
> Yes, it is definitely a bug. AFAICS this occurs when a process forks
> too deeply (child forks, grandchild forks again, etc, without execing).
> The fork() setjmp/longjmp magic accidentally skipped the cleanup
> destructor which is supposed to free the temp
When running configure scripts, I sometimes see this error message repeated
several times, for different lines of the configure script:
bin\sh.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small.
I saw this when building libsdl 1.2.13 on Cygwin 1.7 (uname -v reports
2009-07-13 10:28) o
Matthias Andree gmx.de> writes:
> > By the way, I don't like that setup maximizes the window when on the
> > package
> > selection step. An option somewhere to disable it would be nice. :)
>
> But that's actually a useful feature. The default size used to be way too
> small.
It's just that
Corinna Vinschen cygwin.com> writes:
> This -47 release is accompanied by a new setup-1.7.exe installer,
> version number is 2.617.
I get consistent crashes sometimes after install (and before running postinstall
scripts?). Exception code is 0xc0fd (stack overflow? Fault offset is
0x000430ac
Aaron Gray writes:
> > The #if statement starting on that line is just for the three second
> > clearance. I use it on a local build of Make and it seems to work
> > well.
>
> The " has modification time 0.0096 s in the future" were harmless.
>
> But the "Clock skew detected. Your build may b
Aaron Gray writes:
> > The code for this is available in standard Make, but it isn't enabled in
> > the current build on Cygwin. (The code can be found in remake.c, at line
> > 1277. It's currently enabled if WINDOWS32 or __MSDOS__ is defined.)
>
> Is this just the three second clearance or some
Pedro Alves writes:
> No, but I'm on FAT32 on this machine. Problem is described here:
>
> http://www.delorie.com/djgpp/v2faq/faq22_18.html
>
> According to that same page, DJGPP has a local hack^Wpatch to
> suppress that warning:
>
> "DJGPP ports of GNU Make v3.77 and later allow for up to
>
Christian Franke wrote:
The root of the problem is the "host intrusion prevention system" driver
khips.sys.
Even if this feature is turned off (or unavailable in the free version),
the driver keeps running and slows down fork() considerably.
(It probably hooks somewhere into Read/WriteProces
Magnus Holmgren wrote:
I'm trying to figure out why Cygwin build things so much slower on one
computer I have. We're talking about more than 3 times slower on a
computer that ought to be a bit faster (Athlon64 at 2.2-2.4 GHz,
compared to a Pentium M at 1.8 GHz).
This i
Magnus Holmgren wrote:
> I'm trying to figure out why Cygwin build things so much slower on one
> computer I have. We're talking about more than 3 times slower on a
> computer that ought to be a bit faster (Athlon64 at 2.2-2.4 GHz,
> compared to a Pentium M at 1.8 GHz).
A
Hugh McMaster wrote:
Have you tried enabling the large Windows memory cache option? This
should increase your Cygwin compile time immensely. The build time is
also related, as you know, to what else is taking CPU time.
No, I haven't, as the test isn't (or shouldn't be) I/O bound. The first
Mike Knope wrote:
191 [main] xterm 3256 child_copy: linked dll data write copy failed,
0x2AB000..0x2AB440, done 0, windows pid 2273236, Win32 error 487
AFAIK, you need to be a member of the debugger users group (or be an
admin) for child_copy to work.
Magnus
--
Unsubscribe info:
Hi,
I'm trying to figure out why Cygwin build things so much slower on one
computer I have. We're talking about more than 3 times slower on a
computer that ought to be a bit faster (Athlon64 at 2.2-2.4 GHz,
compared to a Pentium M at 1.8 GHz).
After digging into strace logs a bit, it seems
>
> Mangus,
>
> At 16:12 2003-01-13, Magnus Holmgren wrote:
> > > -Original Message-----
> > > From: Magnus Holmgren [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, January 13, 2003 7:51 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: T
> -Original Message-
> From: Magnus Holmgren [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 13, 2003 7:51 PM
> To: [EMAIL PROTECTED]
> Subject: Tab completion list takes enormously long time to generate from
> empty string
>
>
> Greetings.
>
> When I
Greetings.
When I press tab in bash without having typed anything at all (which is somewhat
abusive but it easily happens), bash works for 15 minutes, going through $PATH looking
for executables (and in the end producing nothing) on a 2x450 MHz PIII. Is that normal?
My $PATH contains the usual
possibly HKEY_CURRENT_USER\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2).
Setup.exe demands that the cygwin root directory, which is asked for on its
third screen, is absolute, i.e. begins with :\, so that's not a
problem.
Regards,
Magnus Holmgren
--
Unsubscribe info: http://cygwin.
25 matches
Mail list logo
