Re: Hyperthreading problem creates a hang
On 11/18/2010 2:25 AM, paritosh chandragupta wrote: Hi folks , I am hitting the following problem while using gmake :- 617 [exiting thread] gmake 9576 cygthread::stub: erroneous thread activation , name is NULL . Now I am indeed using an old cygwin version and can not update it due to dependency issues . Do you have a workaround for this problem ? As per my understanding this problem will not be seen if we limit the maximum number of threads for a process on cygwin (this will of course make it slower , but that is fine ) . Am I Correct ? If yes , how can we do it for cygwin ? I have been using make -j 4 in cygwin for 10 years on the 4 hyperthread Pentium D. Is that not a solution for you? I never expected a performance improvement beyond that number of threads. If you don't mean make which comes with cygwin, I don't see how you will get help without explaining your question. -- Tim Prince -- 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: Hyperthreading problem creates a hang
On Thu, Nov 18, 2010 at 03:55:50PM +0530, paritosh chandragupta wrote: Hi folks , I am hitting the following problem while using gmake :- 617 [exiting thread] gmake 9576 cygthread::stub: erroneous thread activation , name is NULL . Now I am indeed using an old cygwin version and can not update it due to dependency issues . Do you have a workaround for this problem ? As per my understanding this problem will not be seen if we limit the maximum number of threads for a process on cygwin (this will of course make it slower , but that is fine ) . Am I Correct ? If yes , how can we do it for cygwin ? So, 1) You're using a version of make that wasn't distributed with Cygwin (there is no gmake in the distribution). and 2) You're using an old version of Cygwin. Given that, I'd say the odds are slim to none that you'll be able to find a fix for this problem. Time to upgrade. -- 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: hyperthreading fix try #2
On Sun, Feb 13, 2005 at 12:09:21PM -0500, Christopher Faylor wrote: On Mon, Feb 14, 2005 at 01:17:03AM +1000, Nick Coghlan wrote: Nick Coghlan wrote: Command lines looked like (with thread and file counts filled in): $ python /lib/python2.4/test/test_threadedtempfile.py -t threads -f files The results weren't particularly deterministic, beyond a general 'more threads, more files' - 'more likely to hang'. 10 10 seemed to do it fairly effectively although even that would occasionally succeed (the default is 20 20). When it *did* hang, it was with a number of threads successfully opening their files on an iteration, with the remainder of the threads locking up attempting to open a new temporary file. The next time around, the remaining threads would hang while attempting to open the temporary file. The main script hangs because it is waiting for the threads to terminate. Is this a regression? I don't know. Was this also problem with 1.5.12? AFAICT, no. However, another threaded regression test hung in 1.5.12 as indicated in the README: Under XP Pro SP1, Cygwin 1.5.12-1, ntsec, and NTFS, Cygwin Python passes all tests except for following: ... test_threaded_import (occasionally hangs) So, maybe I was just lucky test_threadedtempfile did not hang when I ran the regression test especially since it hung under 1.5.10-3. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix try #2
Christopher Faylor wrote: To help preserve my tenuous grasp on sanity, please reply to *this thread* when reporting problems. Please don't start a new thread. Just reply here so that mailing list threading is preserved and I can easily check for all success or error reports. As before, any kind of report is welcome but it is unlikely that I'm going to spend a lot of time debugging problems that I can't reproduce. It looks somewhat promising here. My main use case is building Python from CVS, and previously it tended to die somewhere in the autoconf script. With the latest snapshot, ./configure and make both worked, and it made it at least part of the way through the Python regression tests. It made it through Python's test_subprocess.py which should be giving the pipe handling a decent workout, but appears to have died in test_threadedtempfile.py (the shell stops using any CPU time, which is rarely a good sign). The bash shell also won't respond to any of Ctrl-C, Ctrl-Z or Ctrl-Break. The close button works, but I figure Windows is taking care of that one. This seems to happen even running that test from the bash shell with the standard Cygwin python 2.4: $ /usr/lib/python2.4/test/regrtest.py test_threadedtempfile test_threadedtempfile hangs here until I close the window Using the windows Python 2.4, the test completes inside a couple of seconds: C:\\python24\Lib\test\regrtest.py test_threadedtempfile test_threadedtempfile 1 test OK. Of course, I don't actually know if this is a related problem or not. I'm hoping Chris can check it easily, since it happens with the standard Cygwin Python, not just with the version I built from Python's current CVS. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix try #2
Nick Coghlan wrote: Christopher Faylor wrote: Of course, I don't actually know if this is a related problem or not. I'm hoping Chris can check it easily, since it happens with the standard Cygwin Python, not just with the version I built from Python's current CVS. I took the obvious step of running that test script directly, playing with the number of threads spawned, and the number of files created by each thread, as well as adding some more print statements to the script to see where it was hanging. Command lines looked like (with thread and file counts filled in): $ python /lib/python2.4/test/test_threadedtempfile.py -t threads -f files The results weren't particularly deterministic, beyond a general 'more threads, more files' - 'more likely to hang'. 10 10 seemed to do it fairly effectively although even that would occasionally succeed (the default is 20 20). When it *did* hang, it was with a number of threads successfully opening their files on an iteration, with the remainder of the threads locking up attempting to open a new temporary file. The next time around, the remaining threads would hang while attempting to open the temporary file. The main script hangs because it is waiting for the threads to terminate. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix try #2
On Mon, Feb 14, 2005 at 01:17:03AM +1000, Nick Coghlan wrote: Nick Coghlan wrote: Christopher Faylor wrote: Of course, I don't actually know if this is a related problem or not. I'm hoping Chris can check it easily, since it happens with the standard Cygwin Python, not just with the version I built from Python's current CVS. I took the obvious step of running that test script directly, playing with the number of threads spawned, and the number of files created by each thread, as well as adding some more print statements to the script to see where it was hanging. Command lines looked like (with thread and file counts filled in): $ python /lib/python2.4/test/test_threadedtempfile.py -t threads -f files The results weren't particularly deterministic, beyond a general 'more threads, more files' - 'more likely to hang'. 10 10 seemed to do it fairly effectively although even that would occasionally succeed (the default is 20 20). When it *did* hang, it was with a number of threads successfully opening their files on an iteration, with the remainder of the threads locking up attempting to open a new temporary file. The next time around, the remaining threads would hang while attempting to open the temporary file. The main script hangs because it is waiting for the threads to terminate. Is this a regression? Was this also problem with 1.5.12? Unless there are pipes involved in this test, I don't see how it could be related to the problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Python 2.4's test_threadedtempfile failing (was Re: hyperthreading fix try #2)
Christopher Faylor wrote: On Mon, Feb 14, 2005 at 01:17:03AM +1000, Nick Coghlan wrote: Command lines looked like (with thread and file counts filled in): $ python /lib/python2.4/test/test_threadedtempfile.py -t threads -f files Is this a regression? Was this also problem with 1.5.12? Unless there are pipes involved in this test, I don't see how it could be related to the problem. I can't say for sure if it's a regression, since I never got 1.5.12 to work properly at all (and hence didn't back up the bin directory before dropping the snapshot binaries into it). At the moment, I'm curious if the test passes on non-hyperthreaded machines. I've changed the subject and cc'ed Jason though, to see if he has anything to add. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Python 2.4's test_threadedtempfile failing (was Re: hyperthreading fix try #2)
On Mon, Feb 14, 2005 at 01:12:53PM +1000, Nick Coghlan wrote: Christopher Faylor wrote: On Mon, Feb 14, 2005 at 01:17:03AM +1000, Nick Coghlan wrote: Command lines looked like (with thread and file counts filled in): $ python /lib/python2.4/test/test_threadedtempfile.py -t threads -f files Is this a regression? Was this also problem with 1.5.12? Unless there are pipes involved in this test, I don't see how it could be related to the problem. I can't say for sure if it's a regression, since I never got 1.5.12 to work properly at all (and hence didn't back up the bin directory before dropping the snapshot binaries into it). At the moment, I'm curious if the test passes on non-hyperthreaded machines. The test passes on this hyperthreaded machine or at least it doesn't hang. I have been running it repeatedly. I do occasionally get a 'bad file descriptor' error but the test keeps on running. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Python 2.4's test_threadedtempfile failing (was Re: hyperthreading fix try #2)
Christopher Faylor wrote: On Mon, Feb 14, 2005 at 01:12:53PM +1000, Nick Coghlan wrote: I can't say for sure if it's a regression, since I never got 1.5.12 to work properly at all (and hence didn't back up the bin directory before dropping the snapshot binaries into it). At the moment, I'm curious if the test passes on non-hyperthreaded machines. The test passes on this hyperthreaded machine or at least it doesn't hang. I have been running it repeatedly. I do occasionally get a 'bad file descriptor' error but the test keeps on running. Most odd. Anyway, I'm far more comfortable hacking Python than I am Cygwin, so I'll get back to the list once I've taken some more time to dig into the guts of the failing test. For the pipe-handling issue, I take the fact that Python's test_subprocess passed as a very good sign, since I understand that uses pipes for its inter-process communication. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix try #2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On my machine my own test case, and the make -j2 test case, have been running now for more than an hour, no problem so far. You seem to be on the right track :) Thanks for your efforts With kind Regards|\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;, Volker Bandke |,4- ) )-,_. ,\ ( `'-' (BSP GmbH)'---''(_/--' `-'\_) Lesser known machine instructions - SDLI: Shift Disk Left Immediate (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: PGP 8.0.1 iQA/AwUBQg3Lax5trGyhAF0wEQIkRACeOEFBg5fg9uexTMbuuks2T8Tc6qYAnAoB 12qf6LJ7bKUWGMv8s/51fbKg =/+0S -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix try #2
Christopher Faylor wrote: I'm not claiming that it is right now. I haven't tried a make -j test yet. I just thought it was time to release another try on the world again: http://cygwin.com/snapshots/ To help preserve my tenuous grasp on sanity, please reply to *this thread* when reporting problems. Please don't start a new thread. Just reply here so that mailing list threading is preserved and I can easily check for all success or error reports. As before, any kind of report is welcome but it is unlikely that I'm going to spend a lot of time debugging problems that I can't reproduce. cgf My make -j test has been running for a while with no failures, and beyond that, this seems to fix a long-standing problem for me having to do with more excessive parallelization make -j100 issues. -Rolf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
20050208 snapshot = yay! (Was: Re: hyperthreading fix, try #1)
Rolf Campbell wrote: This test does fail (in the same way) on non-hyperthreaded machines (Win2000Pro on a PIII). But, this is a regression from 1.5.12 (that test runs fine on the non-HT machine with 1.5.12. There was (maybe still is) a problem with running make -j without the max task counter, but make -j2 has always worked very well on non-ht machines. I will try out some other snapshots and see if I can narrow down the time when this showed up later today. -Rolf I've tried yesterday's snapshot with my test-case, and with my real build system. So far, things look very good. -Rolf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 20050208 snapshot = yay! (Was: Re: hyperthreading fix, try #1)
On Wed, Feb 09, 2005 at 12:27:34PM -0500, Rolf Campbell wrote: Rolf Campbell wrote: This test does fail (in the same way) on non-hyperthreaded machines (Win2000Pro on a PIII). But, this is a regression from 1.5.12 (that test runs fine on the non-HT machine with 1.5.12. There was (maybe still is) a problem with running make -j without the max task counter, but make -j2 has always worked very well on non-ht machines. I will try out some other snapshots and see if I can narrow down the time when this showed up later today. -Rolf I've tried yesterday's snapshot with my test-case, and with my real build system. So far, things look very good. If that's the case, then you can thank Corinna. She found a bug in my code. In my defense, however, causing the problem required her to go to the tremdous effort of running something that she called a cygwin test suite. Duh. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix, try #1
Brian Gallew wrote on Monday, February 07, 2005 2:18 PM: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. IMHO Chris needs more something like a life-time award :) - Jörg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
On Feb 8 09:31, J?rg Schaible wrote: Brian Gallew wrote on Monday, February 07, 2005 2:18 PM: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. IMHO Chris needs more something like a life-time award :) We could ask the Queen to bestow the OM upon Chris. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix, try #1
-Original Message- From: cygwin-owner On Behalf Of Corinna Vinschen Sent: 08 February 2005 08:48 On Feb 8 09:31, J?rg Schaible wrote: Brian Gallew wrote on Monday, February 07, 2005 2:18 PM: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. IMHO Chris needs more something like a life-time award :) We could ask the Queen to bestow the OM upon Chris. We could ask the Buddha to bestow the AUM upon him too! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
On Feb 7 08:17, Brian Gallew wrote: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. Igor? Ready to polish a gold star for cgf? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
On Mon, 7 Feb 2005, Corinna Vinschen wrote: On Feb 7 08:17, Brian Gallew wrote: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. Igor? Ready to polish a gold star for cgf? Always. Regular ones I have a-plenty, just don't ask me for the flashing ones. ;-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
Volker Bandke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rolf, a) Your test case fails on my machine as well, right at the beginning b) I seem to remember that there was/is a separate problem with make - -j, even on non-hyperthreasd machines. Unfortunately I cannot search the mailing list right now due to some error (that possibly has to do with cygwin.com's earlier breakdown. I do remember a sentence somewhere like We don't recommend that you use 'make -j' as it seems to be broken c) Running your testcase with '-j1' instead of '-j2' does not fail on my machine Thanks for you info Volker. Here's what I've figured out: This test does fail (in the same way) on non-hyperthreaded machines (Win2000Pro on a PIII). But, this is a regression from 1.5.12 (that test runs fine on the non-HT machine with 1.5.12. There was (maybe still is) a problem with running make -j without the max task counter, but make -j2 has always worked very well on non-ht machines. I will try out some other snapshots and see if I can narrow down the time when this showed up later today. -Rolf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes: I'm not naive enough to think that I've solved all of the hyperthreading problems but I would like people to try today's snapshot (or any snapshot newer than today's) and report on whether it solves the problem or not. If it doesn't, please provide as simple a test case as possible so that I can duplicate the problem. Working well here: HP Pavilion with P4HT3.2G. I only ran into the hyperthreading bug the other day when trying to chown a large directory tree. It would bomb out after a minute or two (a few hundred to maybe a thousand files). With the new build (whether stripped with --strip-debug or unstripped) the command completes as expected. Another vote for the silver star ! Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
CV or254498 at hotmail.com writes: Another vote for the silver star ! Oops, I meant the gold star of course ! Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix, try #1
-Original Message- From: cygwin-owner On Behalf Of CV Sent: 07 February 2005 18:54 CV or254498 at hotmail.com writes: Another vote for the silver star ! Oops, I meant the gold star of course ! Cheers CV I thought you meant CGF should be promoted to Sherriff! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
On Mon, 7 Feb 2005, Christopher Faylor wrote: On Mon, Feb 07, 2005 at 09:32:09AM -0500, Igor Pechtchanski wrote: On Mon, 7 Feb 2005, Corinna Vinschen wrote: On Feb 7 08:17, Brian Gallew wrote: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. Igor? Ready to polish a gold star for cgf? Always. Regular ones I have a-plenty, just don't ask me for the flashing ones. ;-) Let's wait until a fix has been fully confirmed. That hasn't happened yet. http://cygwin.com/ml/cygwin/2005-02/msg00147.html and http://cygwin.com/ml/cygwin/2005-02/msg00172.html look like confirmations to me. Besides, if you get one gold star per fixed bug they will all be well-deserved. :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
On Mon, Feb 07, 2005 at 08:17:52AM +0100, Volker Bandke wrote: Which system configuration did you use to recreate the problem? I got enough donations to purchase the following: Motherboard:ASUS P4P800SE Memory: 1G CPU:CPU P4/3.0EGHz 800M 478P/1MB HT RT HD: Samsung 120GB Case: ASPIRE XINFINITY BL 350W RTL I purchased this from Newegg. I love that company. I put the system together in one night, turned it on, and it worked. All of the lights came on correctly, the system booted with a CD, and transferring data from my old system proceeded without a hitch, thanks to my knoppix CD -- love that knoppix, too. The one thing that took me forever to fix was getting XP running. Somehow my XP CD got cracked with a big chunk taken out of it, so I had to get a new CD, and I ended up transferring data from my old system multiple times as I attempted to install the new CD without overwriting all of my existing data. The way I usually do this is to copy raw partitions over, since my windows box is multi-boot and represents years of work. Sometimes the OS figures out how to reconfigure itself, sometimes it needs a nudge. In this case, it needed to be whacked with a large branch. I couldn't get W2K working but I've held off further investigations in that for another time. also, can you describe (in _short_ terms) the cause of the error? Cygwin has a problem because normal pipe I/O on windows is not interruptible (generically speaking - you could kludge it on NT). So, to work around this problem, it starts up pipe i/o in a thread and kills the thread when a signal comes in. It's a sledge hammer approach to interrupting pipe I/O. The pipe thread uses a synchronization event to tell the initiating reader when the pipe is all set, has grabbed its arguments and is ready to go. This event was also used to tell the reader that there was a successful read. Previous to my fix, cygwin did not reliably wait for both events to happen so, after the first read on a pipe, it would become out of sync. This would present a problem on any kind of SMP-like system but it wouldn't be as noticeable on a non-SMP system. Once I ran the test case twenty times or so, I went back and looked at the code I'd previously stared at for hours and saw a few synchronization issues. For once the back trace from gdb showed that something was clearly amiss. So, the fix was to try much harder to ensure that we've correctly waited for notification events, even in the scenario when cygwin thinks it has to terminate a thread due to the arrival of a signal. It is possible that the read has completed in that case and cygwin should not throw the data away since the read really *wasn't* terminated by a signal. Unfortunately, there is still a race here. I have an idea about how to fix the race but it would introduce a destabilizing change that I'd rather not chance before 1.5.13 is released. Given that I can't reproduce the problem with the test script anymore, I think I'll release cygwin with this change plus any other potential fixes required to handle the make -j problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
Dave Korn wrote: I thought you meant CGF should be promoted to Sherriff! Oh no! He's much to mean for being promoted to Sherriff. Think of the children! But those gold stars are more then well deserved. Thanks cgf! Regards mks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix, try #1
Um... I say Gold Star for this explanation alone, which somehow is completely free from any hint of sarcasm, WJMness, and passive aggression. Bad day Chris? ;-) Oh, and double-gold stars to any and all who coughed up the dough. -- Gary R. Van Sickle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Monday, February 07, 2005 2:44 PM To: cygwin@cygwin.com Subject: Re: hyperthreading fix, try #1 On Mon, Feb 07, 2005 at 08:17:52AM +0100, Volker Bandke wrote: Which system configuration did you use to recreate the problem? I got enough donations to purchase the following: Motherboard: ASUS P4P800SE Memory: 1G CPU: CPU P4/3.0EGHz 800M 478P/1MB HT RT HD: Samsung 120GB Case: ASPIRE XINFINITY BL 350W RTL I purchased this from Newegg. I love that company. I put the system together in one night, turned it on, and it worked. All of the lights came on correctly, the system booted with a CD, and transferring data from my old system proceeded without a hitch, thanks to my knoppix CD -- love that knoppix, too. The one thing that took me forever to fix was getting XP running. Somehow my XP CD got cracked with a big chunk taken out of it, so I had to get a new CD, and I ended up transferring data from my old system multiple times as I attempted to install the new CD without overwriting all of my existing data. The way I usually do this is to copy raw partitions over, since my windows box is multi-boot and represents years of work. Sometimes the OS figures out how to reconfigure itself, sometimes it needs a nudge. In this case, it needed to be whacked with a large branch. I couldn't get W2K working but I've held off further investigations in that for another time. also, can you describe (in _short_ terms) the cause of the error? Cygwin has a problem because normal pipe I/O on windows is not interruptible (generically speaking - you could kludge it on NT). So, to work around this problem, it starts up pipe i/o in a thread and kills the thread when a signal comes in. It's a sledge hammer approach to interrupting pipe I/O. The pipe thread uses a synchronization event to tell the initiating reader when the pipe is all set, has grabbed its arguments and is ready to go. This event was also used to tell the reader that there was a successful read. Previous to my fix, cygwin did not reliably wait for both events to happen so, after the first read on a pipe, it would become out of sync. This would present a problem on any kind of SMP-like system but it wouldn't be as noticeable on a non-SMP system. Once I ran the test case twenty times or so, I went back and looked at the code I'd previously stared at for hours and saw a few synchronization issues. For once the back trace from gdb showed that something was clearly amiss. So, the fix was to try much harder to ensure that we've correctly waited for notification events, even in the scenario when cygwin thinks it has to terminate a thread due to the arrival of a signal. It is possible that the read has completed in that case and cygwin should not throw the data away since the read really *wasn't* terminated by a signal. Unfortunately, there is still a race here. I have an idea about how to fix the race but it would introduce a destabilizing change that I'd rather not chance before 1.5.13 is released. Given that I can't reproduce the problem with the test script anymore, I think I'll release cygwin with this change plus any other potential fixes required to handle the make -j problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix, try #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher, thanks for the explanation (I read, and even understood it) Good job (Explanation and partial fix). With kind Regards|\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;, Volker Bandke |,4- ) )-,_. ,\ ( `'-' (BSP GmbH)'---''(_/--' `-'\_) It is easier for a camel to pass through the eye of a needle if it is lightly greased. -- Kehlog Albran, The Profit (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: PGP 8.0.1 iQA/AwUBQghuWh5trGyhAF0wEQJd0QCeK2FJNuk6z0zogcKLd5rJv75tmWMAn3ZT XV7i3W4/0DjRAss0uJ2BqTf4 =xKB+ -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix, try #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have started my test script about half an hour ago, and it is still running. It never managed to do that before. This could be a good sign. Now, the snapshot DLL is far larger than the standard dll (I would ASSume because of debug info). Can the debugging info/additional baggage that is being carried around influence the normal runtime behaviour? Should I run strip against the snapshot DLL and rerun my test? With kind Regards|\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;, Volker Bandke |,4- ) )-,_. ,\ ( `'-' (BSP GmbH)'---''(_/--' `-'\_) Steinbach's Guideline for Systems Programming: Never test for an error condition you don't know how to handle. (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: PGP 8.0.1 iQA/AwUBQgZgdx5trGyhAF0wEQKc5QCg51wnZdW5KOEQDiqtplfglygArXAAoJeH D4bXQSMUfTHe58WMpuIs1M96 =pPmL -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
On Sun, Feb 06, 2005 at 07:22:48PM +0100, Volker Bandke wrote: I have started my test script about half an hour ago, and it is still running. It never managed to do that before. This could be a good sign. Now, the snapshot DLL is far larger than the standard dll (I would ASSume because of debug info). Can the debugging info/additional baggage that is being carried around influence the normal runtime behaviour? Should I run strip against the snapshot DLL and rerun my test? I've been building snapshots with debugging turned on lately, yes. I don't think it is possible for this to impact this problem. I certainly saw it with a non-stripped DLL. However, in the interests of science, it probably would be a good idea to strip the DLL and try again if you have time. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
Christopher Faylor wrote:
[...]
Anyway, I took a look at the pipe handling code for the 457th time and
this time I saw a couple of obvious flaws in my logic. The
synchronization was all off.
Fixing that seems to have fixed my hyperthreading problems. I have run
three invocations of the scripts for four days without a hiccup.
Previously, I had problems within minutes.
I'm not naive enough to think that I've solved all of the hyperthreading
problems but I would like people to try today's snapshot (or any
snapshot newer than today's) and report on whether it solves the problem
or not. If it doesn't, please provide as simple a test case as possible
so that I can duplicate the problem.
Using the new snapshot (Feb 6th), the problem is still present, and in
fact, occurs much more quickly and reliably on my system. This is a
modified test case from my original report. Just put makefile and t.sh
in the same dir, run ./t.sh. On my 2.8GHz HT P4, it locks up within
the first second very consistantly. My output look like this:
==output===
$ ./t.sh
Loop 1
: Begin 0.pp 1
: Begin 1.pp 1
$ ./t.sh
: Begin 0.pp
: Begin 1.pp
CYGWIN_NT-5.1
SHELL = /bin/sh
testuname: 0.pp 1.pp 2.pp 3.pp 4.pp 5.pp 6.pp 7.pp 8.pp 9.pp 10.pp 11.pp 12.pp
13.pp 14.pp 15.pp 16.pp 17.pp 18.pp 19.pp 20.pp 21.pp 22.pp 23.pp 24.pp 25.pp
26.pp 27.pp 28.pp 29.pp 30.pp 31.pp 32.pp 33.pp 34.pp 35.pp 36.pp 37.pp 38.pp
39.pp 40.pp 41.pp 42.pp 43.pp 44.pp 45.pp 46.pp 47.pp 48.pp 49.pp 50.pp 51.pp
52.pp 53.pp 54.pp 55.pp 56.pp 57.pp 58.pp 59.pp 60.pp 61.pp 62.pp 63.pp 64.pp
65.pp 66.pp 67.pp 68.pp 69.pp 70.pp 71.pp 72.pp 73.pp 74.pp 75.pp 76.pp 77.pp
78.pp 79.pp 80.pp 81.pp 82.pp 83.pp 84.pp 85.pp 86.pp 87.pp 88.pp 89.pp 90.pp
91.pp 92.pp 93.pp 94.pp 95.pp 96.pp 97.pp 98.pp 99.pp 100.pp 101.pp 102.pp
103.pp 104.pp 105.pp 106.pp 107.pp 108.pp 109.pp 110.pp 111.pp 112.pp 113.pp
114.pp 115.pp 116.pp 117.pp 118.pp 119.pp 120.pp 121.pp 122.pp 123.pp 124.pp
125.pp 126.pp 127.pp 128.pp 129.pp 130.pp 131.pp 132.pp 133.pp 134.pp 135.pp
136.pp 137.pp 138.pp 139.pp 140.pp 141.pp 142.pp 143.pp 144.pp 145.pp 146.pp
147.pp 148.pp 149.pp 150.pp 151.pp 152.pp 153.pp 154.pp 155.pp 156.pp 157.pp
158.pp 159.pp 160.pp 161.pp 162.pp 163.pp 164.pp 165.pp 166.pp 167.pp 168.pp
169.pp 170.pp 171.pp 172.pp 173.pp 174.pp 175.pp 176.pp 177.pp 178.pp 179.pp
180.pp 181.pp 182.pp 183.pp 184.pp 185.pp 186.pp 187.pp 188.pp 189.pp 190.pp
191.pp 192.pp 193.pp 194.pp 195.pp 196.pp 197.pp 198.pp 199.pp 200.pp 201.pp
202.pp 203.pp 204.pp 205.pp 206.pp 207.pp 208.pp 209.pp 210.pp 211.pp 212.pp
213.pp 214.pp 215.pp 216.pp 217.pp 218.pp 219.pp 220.pp 221.pp 222.pp 223.pp
224.pp 225.pp 226.pp 227.pp 228.pp 229.pp 230.pp 231.pp 232.pp 233.pp 234.pp
235.pp 236.pp 237.pp 238.pp 239.pp 240.pp 241.pp 242.pp 243.pp 244.pp 245.pp
246.pp 247.pp 248.pp 249.pp 250.pp 251.pp 252.pp 253.pp 254.pp 255.pp 256.pp
257.pp 258.pp 259.pp 260.pp 261.pp 262.pp 263.pp 264.pp 265.pp 266.pp 267.pp
268.pp 269.pp 270.pp 271.pp 272.pp 273.pp 274.pp 275.pp 276.pp 277.pp 278.pp
279.pp 280.pp 281.pp 282.pp 283.pp 284.pp 285.pp 286.pp 287.pp 288.pp 289.pp
290.pp 291.pp 292.pp 293.pp 294.pp 295.pp 296.pp 297.pp 298.pp 299.pp 300.pp
%.pp::
: Begin $@ ${C}
@uname
: End $@ ${C}
#!/bin/bash
while true; do
make -rRj2
C=$(($C+1))
done
Cygwin Configuration Diagnostics
Current System Time: Mon Feb 07 00:59:22 2005
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
544(Administrators) 545(Users) 10513(Domain Users)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp/make'
USER = `rcampbell'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DESK-RCAMPBELL2'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
COSMIC = `t'
CVS_RSH = `/bin/ssh'
DISPLAY = `:0'
FP_NO_HOST_CHECK = `NO'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\rcampbell'
HOSTNAME = `desk-rcampbell2'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\EXCHANGE'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/home/rcampbell'
OS = `Windows_NT'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PRINTER = `135MC-4th on SPOOLER (from PCRCAMPBELL3)'
RE: hyperthreading fix, try #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FWIW, the test case I have been using is now running for 12 ours, and has done several million iterations. From that point of view the problem seems to be fixed. Now to run the real test case - building Hercules Which system configuration did you use to recreate the problem? And also, can you describe (in _short_ terms) the cause of the error? With kind Regards|\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;, Volker Bandke |,4- ) )-,_. ,\ ( `'-' (BSP GmbH)'---''(_/--' `-'\_) An ounce of application is worth a ton of abstraction. (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: PGP 8.0.1 iQA/AwUBQgcWIB5trGyhAF0wEQI+GQCfSnofdphyi5TRlWO8G18zUui5QesAoOMt I/0glQ56wlb3qTTgU4hh5DmM =mLgN -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hyperthreading fix, try #1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rolf, a) Your test case fails on my machine as well, right at the beginning b) I seem to remember that there was/is a separate problem with make - -j, even on non-hyperthreasd machines. Unfortunately I cannot search the mailing list right now due to some error (that possibly has to do with cygwin.com's earlier breakdown. I do remember a sentence somewhere like We don't recommend that you use 'make -j' as it seems to be broken c) Running your testcase with '-j1' instead of '-j2' does not fail on my machine With kind Regards|\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;, Volker Bandke |,4- ) )-,_. ,\ ( `'-' (BSP GmbH)'---''(_/--' `-'\_) Hidden I/O Functions instructions: SCL SET CURSER TO LOUD (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: PGP 8.0.1 iQA/AwUBQgcbZB5trGyhAF0wEQISUwCfQqCl5HAa7QjMMkrtJp8uzek1CCkAn3NJ 43wgJOBeQRchfoSz7h/dNGsn =AJOY -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problem: remote access
Christopher Faylor wrote: However, here is one of the times I repeated that I don't want to do this over the internet: [...] Fixing this problem will be difficult. Dealing with race conditions like this always is difficult. Indeed, as an embedded software designer I know this first hand. I don't want to do this over the internet. It would be too painful and there is no guarantee that I could even do it at all. It could involve machine reboots Fair enough. It is already amazing how much effort you and other volunteers put into cygwin. Obviously it is your own choice whether you want to put up with the hassle of remote debugging and possibly many re-logins. I can't imagine why this would be a useful thing to discuss here. I just assumed there was a technical reason why remote debugging would not work, that I had overlooked. The offer still stands in case another developer likes to give it a try. /Joris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problem: remote access
Larry Hall wrote: Chris has already answered that question earlier in the discussion. He needs physical access to the machine to resolve this problem. Remote access isn't enough. Forgive my ignorance, but I read the archives back to 1 jan 2004 but found no explanation why remote access doesn't help the developers to track down the problem. Could someone please point me to the relevant postings? /Joris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problem: remote access
On Tue, 1 Feb 2005, Joris van der Sande wrote: Larry Hall wrote: Chris has already answered that question earlier in the discussion. He needs physical access to the machine to resolve this problem. Remote access isn't enough. Forgive my ignorance, but I read the archives back to 1 jan 2004 but found no explanation why remote access doesn't help the developers to track down the problem. Could someone please point me to the relevant postings? http://sources.redhat.com/ml/cygwin/2005-01/msg00521.html Specifically, cgf wrote: Fixing this problem will be difficult. Dealing with race conditions like this always is difficult. I don't want to do this over the internet. It would be too painful and there is no guarantee that I could even do it at all. It could involve machine reboots (I just had to do one of these yesterday while debugging a non-thread race condition). Mostly, this is a case of a volunteer not wanting to deal with that sort of hassle. YMMV. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problem: remote access
On Tue, Feb 01, 2005 at 11:01:11PM +0100, Joris van der Sande wrote: Larry Hall wrote: Chris has already answered that question earlier in the discussion. He needs physical access to the machine to resolve this problem. Remote access isn't enough. Forgive my ignorance, but I read the archives back to 1 jan 2004 but found no explanation why remote access doesn't help the developers to track down the problem. Could someone please point me to the relevant postings? I can't imagine why this would be a useful thing to discuss here. However, here is one of the times I repeated that I don't want to do this over the internet: http://sources.redhat.com/ml/cygwin/2005-01/msg00521.html cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problem: remote access
At 07:45 PM 1/30/2005, you wrote: The hyperthreading problem reproduces perfectly on my Hush ATX 2.8 GHz P4 (www.hush-pc.com): building my application fails consistent (within 1 minute) with hyperthreading enabled. Since my machine is on-line 24/7, would it help if I gave Christopher (or another motivated developer) remote access (via ssh/vnc/x or whatever)? Chris has already answered that question earlier in the discussion. He needs physical access to the machine to resolve this problem. Remote access isn't enough. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Hyperthreading Problem - suggestion
This just caught my attention this morning, don't know if it has been a continuing discussion of not but let me contribute the following: a: Someone (close by to cfg) demonstrates that the bug/problem/issue appears on his machine I have many annoying problems ( erroneous thread activation from scripts seems to be common ) and I have debuggers available. I could attach a stuck cygwin window and send stacks or dumps to anyone interested. If I chose this route who should I send the stuff to? Please respond to me ( and optionally the whole list ) since our spam filter is less likely to delete it and I've been ignoring most of the cygwin list posts. Thanks. -Original Message- From: Volker Bandke [mailto:[EMAIL PROTECTED] Sent: Monday, January 10, 2005 3:54 AM To: Cygwin Subject: Hyperthreading Problem - suggestion -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I really want that hyperthreading problem with Cygwin resolved. Does the following suggestion make any sense: (I assume cfg is in the US, if not, make the necessary changes) a: Someone (close by to cfg) demonstrates that the bug/problem/issue appears on his machine b: This someone determines what an identical replacement machine would cost now c: CFG (or the someone from a) sets up a paypal account for HT Machine Donations d: When the required amount is reached, the Someone from a: sends his machine to CFG and buys a replacement out of the paypal account I am willing to pay 100 USD into that account. Knowing that my machine has cost about Euro 1000 I believe it should take a real short time to provide cfg with a machine to test / debug the hyperthreading issue . Any comments are welcome With kind Regards|\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;, Volker Bandke |,4- ) )-,_. ,\ ( `'-' (BSP GmbH)'---''(_/--' `-'\_) Life's a bitch and then you die. (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: PGP Personal Security 7.0.3 iQA/AwUBQeJCoh5trGyhAF0wEQKktACeN15g4FyLBC30ziZSo8UH+m56zSMAnRh8 yj/KMcCi16U6uxV3+07giini =t5s5 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Hyperthreading Problem - suggestion
Hello all, I have tried lots of different machines to reproduce the bug (hyperthreaded workstations and dual-processor servers). I was able to reproduce the problem on *every* Windows XP (XP Pro, XP Home and 2003 Server) machines I tried, but *not* on Windows 2000 (Pro and Server) machines. To demonstrate the bug, just run simultaneously 2 or 3 instances of the ksh script I posted in my previous message, and you will get shortly one of the following problems: 1) the shell script stops because `pwd` returned the empty string 2) the shell crashes with the 'erroneous thread activation' error. Regards, Stephane Donze -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mike Marchywka Sent: lundi 10 janvier 2005 12:42 To: Volker Bandke; Cygwin Subject: RE: Hyperthreading Problem - suggestion This just caught my attention this morning, don't know if it has been a continuing discussion of not but let me contribute the following: a: Someone (close by to cfg) demonstrates that the bug/problem/issue appears on his machine I have many annoying problems (erroneous thread activation from scripts seems to be common ) and I have debuggers available. I could attach a stuck cygwin window and send stacks or dumps to anyone interested. If I chose this route who should I send the stuff to? Please respond to me ( and optionally the whole list ) since our spam filter is less likely to delete it and I've been ignoring most of the cygwin list posts. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Hyperthreading Problem - suggestion
I've been on XP for a while but IIRC I was seeing it with hyperthread on 2000. -Original Message- From: Stéphane Donzé [mailto:[EMAIL PROTECTED] Sent: Monday, January 10, 2005 8:41 AM To: Mike Marchywka; Volker Bandke; Cygwin Subject: RE: Hyperthreading Problem - suggestion Hello all, I have tried lots of different machines to reproduce the bug (hyperthreaded workstations and dual-processor servers). I was able to reproduce the problem on *every* Windows XP (XP Pro, XP Home and 2003 Server) machines I tried, but *not* on Windows 2000 (Pro and Server) machines. To demonstrate the bug, just run simultaneously 2 or 3 instances of the ksh script I posted in my previous message, and you will get shortly one of the following problems: 1) the shell script stops because `pwd` returned the empty string 2) the shell crashes with the 'erroneous thread activation' error. Regards, Stephane Donze -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mike Marchywka Sent: lundi 10 janvier 2005 12:42 To: Volker Bandke; Cygwin Subject: RE: Hyperthreading Problem - suggestion This just caught my attention this morning, don't know if it has been a continuing discussion of not but let me contribute the following: a: Someone (close by to cfg) demonstrates that the bug/problem/issue appears on his machine I have many annoying problems (erroneous thread activation from scripts seems to be common ) and I have debuggers available. I could attach a stuck cygwin window and send stacks or dumps to anyone interested. If I chose this route who should I send the stuff to? Please respond to me ( and optionally the whole list ) since our spam filter is less likely to delete it and I've been ignoring most of the cygwin list posts. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading Problem - suggestion
On Mon, Jan 10, 2005 at 09:53:55AM +0100, Volker Bandke wrote: I really want that hyperthreading problem with Cygwin resolved. Does the following suggestion make any sense: (I assume cfg is in the US, if not, make the necessary changes) a: Someone (close by to cfg) demonstrates that the bug/problem/issue appears on his machine b: This someone determines what an identical replacement machine would cost now c: CFG (or the someone from a) sets up a paypal account for HT Machine Donations d: When the required amount is reached, the Someone from a: sends his machine to CFG and buys a replacement out of the paypal account I am willing to pay 100 USD into that account. Knowing that my machine has cost about Euro 1000 I believe it should take a real short time to provide cfg with a machine to test / debug the hyperthreading issue . http://www.cygwin.com/ml/cygwin/2004-09/msg00084.html I was going to say that this was YA repeat observation, in keeping with the need for people to send the same observations about hyperthreaded behavior here. The repeated observations are as follows: 1) I just got a hang by doing X (where X is some variation of previously reported problems)! 2) I just got this problem as reported in the mailing list thread here: *show a URL where someone is reporting hyperthread problems* (bonus points for showing URL with an entry from me talking about how I can't duplicate the problem) 3) I can provide a system over the internet for use in debugging. 4) I just noticed a hang on Windows 95! This must mean that hyperthreading is not the problem! Let me try to state this very clearly. The last time I tried to duplicate the problem, I ran a test for three days, tying up a machine that I use for other purposes. I'd previously tried other variations as well. The system is an SMP system so there should have been a good chance of duplicating the bug. I'm not going to try every variation of this problem when it shows up on the list. Fixing this problem will be difficult. Dealing with race conditions like this always is difficult. I don't want to do this over the internet. It would be too painful and there is no guarantee that I could even do it at all. It could involve machine reboots (I just had to do one of these yesterday while debugging a non-thread race condition). No one has said that cygwin is bug free. So, there is undoubtedly more than one way to make it hang. A hang that shows up on Windows 95 does not necessarily translate to the same problem that people on hyperthreading machines are seeing. It may, but since the only Windows 9x type system that I have available for extended use is a vmware emulation, it isn't likely that I'll be able to duplicate the problem in Windows 9x. I have seven machines in my office right now and don't really need another one (I never thought I'd hear myself say that) but I will somehow make room if I can get another hyperthreaded machine here. If I do, I will dedicate it to cygwin and cygwin testing and try to make sure that this problem never crops up again. Someone else has previously raised the issue of a paypal account and the thread in the quoted URL above shows how to make donations. However, I am heartened to see that Volker is thinking like a scientist and has noted a problem with the get a new hyperthreaded system to cgf problem. There is no guarantee that any *new* machine that I get will evidence the problem. Rather than do some complicated swap game on systems, however, I'd be willing to chance that a system which is sufficiently similar to a problem system will show the problem. If/when I get enough money to purchase one, I will check such a system out. If I can't duplicate the problem on that system, I'll be glad to then swap with someone else. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading Problem - suggestion
On Mon, 2005-01-10 at 12:20 -0500, Christopher Faylor wrote: The last time I tried to duplicate the problem, I ran a test for three days, tying up a machine that I use for other purposes. I'd previously tried other variations as well. The system is an SMP system so there should have been a good chance of duplicating the bug. I'm not going to try every variation of this problem when it shows up on the list. Just a quick observation and a question. Hyperthreading exposed a race condition in an NT driver of mine that had run for a long time on an SMP system. The timing is different. Is there anybody out there who has Windows XP and hyperthreading and _can't_ reproduce the problem? This is making me nervous about a project I'm planning, as most of the target machines will be P4s with hyperthreading running XP. -- Adrian Cox [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading Problem - suggestion
On Mon, Jan 10, 2005 at 12:20:23PM -0500, Christopher Faylor wrote: On Mon, Jan 10, 2005 at 09:53:55AM +0100, Volker Bandke wrote: I really want that hyperthreading problem with Cygwin resolved. Does the following suggestion make any sense: (I assume cfg is in the US, if not, make the necessary changes) a: Someone (close by to cfg) demonstrates that the bug/problem/issue appears on his machine b: This someone determines what an identical replacement machine would cost now c: CFG (or the someone from a) sets up a paypal account for HT Machine Donations d: When the required amount is reached, the Someone from a: sends his machine to CFG and buys a replacement out of the paypal account I am willing to pay 100 USD into that account. Knowing that my machine has cost about Euro 1000 I believe it should take a real short time to provide cfg with a machine to test / debug the hyperthreading issue . http://www.cygwin.com/ml/cygwin/2004-09/msg00084.html I have, with some misgivings, set up a donations page: http://cygwin.com/donations.html This is something that I've wanted to do for a while and, IIRC, I've even previously gotten buy-in from other developers and package maintainers. If other package maintainers want to add their links, please send me private email with the appropriate info and I'll do so post-haste. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
At 04:08 PM 1/1/2005, you wrote: Brian Bruns wrote: rant I think you really really really need to reevaluate what you say before you hit send. The open source/free software developers that I communicate with/work with wrote the stuff they did because they needed an application/library/script for a specific need, and decided to release the software to the public in the hope that someone else might find it useful, and the hope that other people might contribute back. That's exactly my point: what I was trying to say is that Cygwin wants and deserves to be more than a project developped for a specific need and released to the public as is. An to be more than that, it needs to have an active technical support, that cannot expect users to fix bugs by themselves. snip In fact, Cygwin *does* sell licenses: http://www.redhat.com/software/cygwin/ . Ah good. So you have seen that there is already at least one response to your assertion above. Obviously, if one expects to be able to demand action on a particular issue, one has to have bought such a right. The link you provide above is one method of buying the right to demand. I expect there are others folks on this list that would entertain the notion of fixing problems for compensation too, so that's another option for anyone interested. I don't think anyone here would argue that there isn't some need for such fee-based support avenues. And you can see by the link you provide that Red Hat is one such avenue. The thing to remember is that this list is not a fee-based services, which has it's benefits and it's detriments. One detriment is there's really no leverage that a user has to demand support. But one can ask. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
Brian Bruns wrote: If you guys want cygwin to be used by real people, in real life production or development environments, you should go a bit further than I don't have the problem on my computer, so fix it yourself. If you don't want to or are not able to pay attention to real world bugs, cygwin will probably never be more than an almost working program that runs on your computer the time to take nice screenshots, but fails miserably when users try to make it work in the real life. rant I think you really really really need to reevaluate what you say before you hit send. The open source/free software developers that I communicate with/work with wrote the stuff they did because they needed an application/library/script for a specific need, and decided to release the software to the public in the hope that someone else might find it useful, and the hope that other people might contribute back. That's exactly my point: what I was trying to say is that Cygwin wants and deserves to be more than a project developped for a specific need and released to the public as is. An to be more than that, it needs to have an active technical support, that cannot expect users to fix bugs by themselves. I feel the same way myself, and anytime someone tells me that what I work on is crap or sucks and they will never use it because it sucks, I never, *never* said that Cygwin was crap. Cygwin is a really ambitious project that provides a generic solution to all portablity problems between Windows and *nix. And the fact that Cygwin is a wonderful tool is the very reason why lots of people complain about the bugs: it is so frustrating to have a perfect solution to a problem and to be unable to use it because of a spurious, non deterministic bug. I'm not at all opposed to help fixing this bug, and I'm already working at gathering more information for a more complete bug report. I've had my own load of 'mysterious' bugs and nights of bug hunting, so I understand how hard and frustrating it can be to fix such a problem. I tell them this: You got the program from me for free. You are not my customer. You do not have a support contract with me. As such, I work on the projects when I can, and at the rate which I can afford. If you have a specific request, you can either fix it yourself, or you can compensate me for the time I spend making the changes you want if I don't have the ability to spare some free time. In fact, Cygwin *does* sell licenses: http://www.redhat.com/software/cygwin/ . What you consider 'real people' is obviously not the same type of people I consider 'real people'. I consider these 'real people' to be the individuals who are on this list, who work on the project, and who actively contribute to the project. You may use Cygwin, but until you start actively contributing to it, and helping the developers fix the bugs and such, you have no right to complain. I may not be an active contributor to Cygwin, but I do work alot with other OSS projects, and they get this same type of response from people too, and frankly, I'm sick of it. /rant -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Hyperthreading problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sitting in Germany makes it difficult for me to physically send you a machine. What I can do, though, is to virtually hand over the machine to you via the net. I have an ADSL connection with 3 megabits/sec download and 512 kilobit/sec download. I can easily attach a 100 GB drive for your use, and leave the machine to you for some time. I'll give you an administrator user id on the machine. This is the machine on which I can unfailingly reproduce the error/problem/whatever situation With kind Regards|\ _,,,---,,_ ZZZzz /,`.-'`'-. ;-;;, Volker Bandke |,4- ) )-,_. ,\ ( `'-' (BSP GmbH)'---''(_/--' `-'\_) Machine-independent: Does not run on any existing machine. (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: PGP Personal Security 7.0.3 iQA/AwUBQdLOKR5trGyhAF0wEQL5/ACfWZNo9AZvV32zW/IUezrxuPs2VFIAn0LC 830Cp2XKkZQNFZ2m39PoZhuP =+8/r -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
Hi, Thank you for your reply. You are right, I did not look at the code, and I certainly do not pretend to be able to fix this problem. I am sorry to have to say that, but your message is a very good example of the fundamental difference between a project that is useable and reliable, and a project that almost works and will never do more that that. The problem I reported is known for almost 2 years (posted by Henrik Wist, 20 Mar 2003, subject was cygwin commands sometime hang on dual-processor (WinNT-SP5)). I don't care if it is the same bug or not, the fact is that cygwin has a critical problem (i.e. something that prevent users to use even simple commands like 'ls' !!) on multiprocessor machines and nobody seems to care about it. You cannot just expect people to wait until you someday have a system that shows the problem everytime they encounter a bug. If you guys want cygwin to be used by real people, in real life production or development environments, you should go a bit further than I don't have the problem on my computer, so fix it yourself. If you don't want to or are not able to pay attention to real world bugs, cygwin will probably never be more than an almost working program that runs on your computer the time to take nice screenshots, but fails miserably when users try to make it work in the real life. Regards, Stephane NB: this post is not at all about commercial software versus OSS, there are lots of industrial quality open source projects like Apache, MySQL, etc. Christopher Faylor wrote: On Fri, Dec 24, 2004 at 09:01:17AM +0100, St?phane Donz? wrote: we have encountered random hangs and crashes in cygwin (see output of cygcheck attached to this message) on a dual-processor server running Windows Server 2003. IMHO, the so-called hyperthreading problems reported recently on this mailing list just have nothing to do with hyperthreading, but are more generally related to multi-processor issues. If you have followed the thread, then you know that I have a multi-processor system and I don't have the problem. There is no point in reposting scripts. There is no point in recapitulating the problem. There is no point in making obvious observations about what one would suspect the cause would be without bothering to look at the code. Your options are to fix the problem yourself or wait until I someday have a system which demonstrates the problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Hyperthreading problems
multiprocessor machines and nobody seems to care about it. You cannot just expect people to wait until you someday have a system that shows the problem everytime they encounter a bug. Actually since Cygwin is a free project this is a reasonable expectation. If you want this fixed send the Cygwin developers a system that reproduces this problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Hyperthreading problems
If you guys want cygwin to be used by real people, in real life production or development environments, you should go a bit further than I don't have the problem on my computer, so fix it yourself. OK. So, if he's unable to reproduce the problem, you want him to... do what? Make random changes to try and fix things? How is he supposed to know when he's fixed the problem if he can't even manage to reproduce it in the first place? If you don't want to or are not able to pay attention to real world bugs, cygwin will probably never be more than an almost working program that runs on your computer the time to take nice screenshots, but fails miserably when users try to make it work in the real life. I've been working for a company for three years now that relies heavily on Cygwin as a foundation for commercial software. Our internal build system is capable of compiling various products under either Cygwin or Linux, all from the same set of makefiles and scripts. We'd hardly be able to do any of that if Cygwin was an almost working program not ready for use in real life. It is not without it's problems - you've pointed out one. But overall, Cygwin works, and it works well. Why not get into the spirit of the season? 'Tis better to give than to receive... PTC. If you're unable to solve the problem yourself, then put a cash value on your need to fix this bug, and hire someone to do it. There are a lot of people that would *love* to pick up some extra money around this time of year. -Samrobb -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
On Tue, Dec 28, 2004 at 11:31:00PM +0100, Stephane Donze wrote: I am sorry to have to say that, but your message is a very good example of the fundamental difference between a project that is useable and reliable, and a project that almost works and will never do more that that. [snip] If you guys want cygwin to be used by real people, in real life production or development environments, you should go a bit further than I don't have the problem on my computer, so fix it yourself. If you don't want to or are not able to pay attention to real world bugs, cygwin will probably never be more than an almost working program that runs on your computer the time to take nice screenshots, but fails miserably when users try to make it work in the real life. You know, if you'd just waited *a week*, you probably could have laid claim to being the first posting of this type in 2005 rather than (hopefully) the last of 2004. I think that being first is usually much more auspicious. So close... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
On Tuesday, December 28, 2004 5:31 PM [EST], Stephane Donze wrote: Hi, Thank you for your reply. You are right, I did not look at the code, and I certainly do not pretend to be able to fix this problem. I am sorry to have to say that, but your message is a very good example of the fundamental difference between a project that is useable and reliable, and a project that almost works and will never do more that that. Funny, Cygwin is usable and reliable here for the stuff I use it for. Yeah, its got bugs, but every program in existance has bugs. The problem I reported is known for almost 2 years (posted by Henrik Wist, 20 Mar 2003, subject was cygwin commands sometime hang on dual-processor (WinNT-SP5)). I don't care if it is the same bug or not, the fact is that cygwin has a critical problem (i.e. something that prevent users to use even simple commands like 'ls' !!) on multiprocessor machines and nobody seems to care about it. You cannot just expect people to wait until you someday have a system that shows the problem everytime they encounter a bug. Frankly, unless the developers can reproduce these bugs, they won't get fixed. Its the stuck up attitudes of users like yourself that make trying to fix bugs all the harder. If you guys want cygwin to be used by real people, in real life production or development environments, you should go a bit further than I don't have the problem on my computer, so fix it yourself. If you don't want to or are not able to pay attention to real world bugs, cygwin will probably never be more than an almost working program that runs on your computer the time to take nice screenshots, but fails miserably when users try to make it work in the real life. rant I think you really really really need to reevaluate what you say before you hit send. The open source/free software developers that I communicate with/work with wrote the stuff they did because they needed an application/library/script for a specific need, and decided to release the software to the public in the hope that someone else might find it useful, and the hope that other people might contribute back. I feel the same way myself, and anytime someone tells me that what I work on is crap or sucks and they will never use it because it sucks, I tell them this: You got the program from me for free. You are not my customer. You do not have a support contract with me. As such, I work on the projects when I can, and at the rate which I can afford. If you have a specific request, you can either fix it yourself, or you can compensate me for the time I spend making the changes you want if I don't have the ability to spare some free time. When people want me to port an app to say, MacOS or similar, I tell them similar things: I can't afford a Mac right now. Provide me with a system that I can use to make it work, and I'll do my best to make it work. What you consider 'real people' is obviously not the same type of people I consider 'real people'. I consider these 'real people' to be the individuals who are on this list, who work on the project, and who actively contribute to the project. You may use Cygwin, but until you start actively contributing to it, and helping the developers fix the bugs and such, you have no right to complain. I may not be an active contributor to Cygwin, but I do work alot with other OSS projects, and they get this same type of response from people too, and frankly, I'm sick of it. /rant NB: this post is not at all about commercial software versus OSS, there are lots of industrial quality open source projects like Apache, MySQL, etc. Yes, and those do well because people contribute to them to make them better. *hint hint* -- Brian Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
Stephane Donze wrote: If you guys want cygwin to be used by real people, in real life production or development environments, you should go a bit further than I don't have the problem on my computer, so fix it yourself. If you don't want to or are not able to pay attention to real world bugs, cygwin will probably never be more than an almost working program that runs on your computer the time to take nice screenshots, but fails miserably when users try to make it work in the real life. The real problem here is as follows: Chris and the other core developers cannot reproduce the bug on their systems. The people reporting the bug can neither create a simple test case that demonstrates it, nor debug the Cygwin internals and point to a specific defect. So until one side of this equation changes nothing is going to get fixed, no matter how hard people beg, whine, and plead. It's not about being uncaring or whatever, it's just the way software development works. You can't even start to try to fix something that you cannot see or reproduce and have nothing to work with. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
On Tue, Dec 28, 2004 at 05:29:10PM -0800, Brian Dessent wrote: Stephane Donze wrote: If you guys want cygwin to be used by real people, in real life production or development environments, you should go a bit further than I don't have the problem on my computer, so fix it yourself. If you don't want to or are not able to pay attention to real world bugs, cygwin will probably never be more than an almost working program that runs on your computer the time to take nice screenshots, but fails miserably when users try to make it work in the real life. The real problem here is as follows: Chris and the other core developers cannot reproduce the bug on their systems. The people reporting the bug can neither create a simple test case that demonstrates it, nor debug the Cygwin internals and point to a specific defect. So until one side of this equation changes nothing is going to get fixed, no matter how hard people beg, whine, and plead. It's not about being uncaring or whatever, it's just the way software development works. You can't even start to try to fix something that you cannot see or reproduce and have nothing to work with. I think the thing that is perhaps missing from the equation here, is that I have tried to take stabs in the dark and fix it a few times but I've never been successful. I've also laid awake at nights thinking about the problem. I've studied code at various random times in the hopes that something would jump out at me. So far, no luck. It's interesting that the developer has to go a little further to fix this bug while nearly everyone who reports the problem (with at least one notable exception) is content to just regurgitate the same complaints and wait. It doesn't seem like this technique is working very well but people keep trying it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Hyperthreading problems
On Fri, Dec 24, 2004 at 09:01:17AM +0100, St?phane Donz? wrote: we have encountered random hangs and crashes in cygwin (see output of cygcheck attached to this message) on a dual-processor server running Windows Server 2003. IMHO, the so-called hyperthreading problems reported recently on this mailing list just have nothing to do with hyperthreading, but are more generally related to multi-processor issues. If you have followed the thread, then you know that I have a multi-processor system and I don't have the problem. I used the following test (found on this mailing list archive, posted 6 Apr 2004 by Chuck McDevitt): QUOTE #! /bin/ksh mypath=$(pwd) while [[ ! -z $mypath ]] do mypath=$(pwd) if [[ -z $mypath ]] then echo Test Failed..Path is empty fi done There is no point in reposting scripts. There is no point in recapitulating the problem. There is no point in making obvious observations about what one would suspect the cause would be without bothering to look at the code. Your options are to fix the problem yourself or wait until I someday have a system which demonstrates the problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: HyperThreading
AFAIK there was some kind of problem with hyperthreading on cygwin, do anyone know if this problems has been fixed? No. And they won't be fixed until someone sends a system or enough money to buy a system with to CGF. http://www.cygwin.com/ml/cygwin/2004-09/msg00082.html http://www.cygwin.com/ml/cygwin/2004-09/msg00091.html -Richard Campbell. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HyperThreading
On Wed, 27 Oct 2004, Pablo Ruiz Garcia wrote: I'm having some problems with hyperthreading machines and cygwin. AFAIK there was some kind of problem with hyperthreading on cygwin, do anyone know if this problems has been fixed? It'd be much more helpful if you actually tried to describe the problems you're having. It'd also be helpful if you followed the Cygwin problem reporting guidelines here: Problem reports: http://cygwin.com/problems.html That said, Richard Campbell's reply is probably still valid. FWIW, we use hyperthreaded and dual processor hyperthreaded machines daily without issue (Cygwin 1.5.10). Maybe we're just lucky... -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HyperThreading
Well I found a minor workaround.. set Affinity of proccess to only use one CPU (Thread). -- Pablo Ruiz Garcia (Pci) Security Consultancy - Tiger Team Enterasys ESE/CISSP/CISA Certified Meet just your security needs [EMAIL PROTECTED] - Original Message - From: Richard Campbell [EMAIL PROTECTED] To: Pablo Ruiz Garcia [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 3:38 PM Subject: RE: HyperThreading AFAIK there was some kind of problem with hyperthreading on cygwin, do anyone know if this problems has been fixed? No. And they won't be fixed until someone sends a system or enough money to buy a system with to CGF. http://www.cygwin.com/ml/cygwin/2004-09/msg00082.html http://www.cygwin.com/ml/cygwin/2004-09/msg00091.html -Richard Campbell. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HyperThreading
On Wed, 27 Oct 2004, Pablo Ruiz Garcia wrote: Well I found a minor workaround.. set Affinity of proccess to only use one CPU (Thread). Threads and CPUs are not remotely the same things, so I don't know why you have that in parenthesis. But, I guess it's nice to know that you found a workaround for a problem only known to you. How do you expect it to ever be fixed if you don't actually report it, or at least confirm that it has already been reported? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HyperThreading
- Original Message - From: Brian Ford [EMAIL PROTECTED] To: Pablo Ruiz Garcia [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 8:47 PM Subject: Re: HyperThreading On Wed, 27 Oct 2004, Pablo Ruiz Garcia wrote: Well I found a minor workaround.. set Affinity of proccess to only use one CPU (Thread). Threads and CPUs are not remotely the same things, so I don't know why you have that in parenthesis. I have it in parenthesis, because *I* know that CPUs and Threads are not the same, but as I'm talking about a problem with hyper-THREADING, I thought this way it would be easier to understand what i was talking about. I´m Sorry if this is a problem for you, but, in fact, I dont care anyway. But, I guess it's nice to know that you found a workaround for a problem only known to you. How do you expect it to ever be fixed if you don't actually report it, or at least confirm that it has already been reported? This problem has been reported in the past.. and I append a mail from another list member who includes references about this problem. -- Brian Ford --- Forwarded Mail --- AFAIK there was some kind of problem with hyperthreading on cygwin, do anyone know if this problems has been fixed? No. And they won't be fixed until someone sends a system or enough money to buy a system with to CGF. http://www.cygwin.com/ml/cygwin/2004-09/msg00082.html http://www.cygwin.com/ml/cygwin/2004-09/msg00091.html -Richard Campbell. --- End Forwarded Mail --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HyperThreading
On Wed, 27 Oct 2004, Pablo Ruiz Garcia wrote: - Original Message - From: Brian Ford snip To: Pablo Ruiz Garcia snip Cc: snip I'm sure you don't care, but... http://cygwin.com/acronyms/index.html#PCYMTNQREAIYR Sent: Wednesday, October 27, 2004 8:47 PM Subject: Re: HyperThreading On Wed, 27 Oct 2004, Pablo Ruiz Garcia wrote: Well I found a minor workaround.. set Affinity of proccess to only use one CPU (Thread). Threads and CPUs are not remotely the same things, so I don't know why you have that in parenthesis. I have it in parenthesis, because *I* know that CPUs and Threads are not the same, but as I'm talking about a problem with hyper-THREADING, I thought this way it would be easier to understand what i was talking about. I´m Sorry if this is a problem for you, but, in fact, I dont care anyway. Ok. But, I guess it's nice to know that you found a workaround for a problem only known to you. How do you expect it to ever be fixed if you don't actually report it, or at least confirm that it has already been reported? and exactly where... This problem has been reported in the past.. and I append a mail from another list member who includes references about this problem. Oh yeah, right! The HYPERTHREADED problem. I should have known! Please excuse my attempt to clarify so that I could actually try to debug it. Just curious if you read this part of: http://cygwin.com/problems.html Do not assume that your problem is so trivial or so well known that it does not require any details or background from you. Many (most?) people who report problems fall into the trap of assuming that people are clued into their mental state when, in most cases, this is not the case. As a rule of thumb, if you find yourself referring to your problem as the problem with XYZ rather than a problem with XYZ then your message is suspect. Using the in this context means that you are assuming that your problem is well known. Unless you can point to an email message thread or FAQ entry (either of which is a good idea, btw) please do not assume that the readers of your message will be familiar with your problem. as I suggested. --- Forwarded Mail --- AFAIK there was some kind of problem with hyperthreading on cygwin, do anyone know if this problems has been fixed? No. And they won't be fixed until someone sends a system or enough money to buy a system with to CGF. http://www.cygwin.com/ml/cygwin/2004-09/msg00082.html http://www.cygwin.com/ml/cygwin/2004-09/msg00091.html -Richard Campbell. I have tried tracing both of these threads back to a: http://cygwin.com/acronyms/index.html#STC without success. So, I have no idea what *your* HYPERTHREADED problem actually is. I rather doubt that anyone else does either. The test cases for this issue that I could find all appear to use pipes in bash, which have recently been shown to be buggy (PID reuse and exit status issues). If anyone still has a failing STC that doesn't use pipes in bash, please send it to me as I'd like to take a look. Personal email is fine as I'm sure CGF doesn't want to hear about this issue any more. I'm just wondering if there are really many left that haven't been explained, since I never see any. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HyperThreading
The test case I originally sent in to demonstrate the problem was using pdksh, not bash, so the problem isn't isolated to bash P.s. Sorry about the top post -- Lotus notes seems to force it to be that way. Brian Ford [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/27/2004 05:11 PM Please respond to [EMAIL PROTECTED] To Pablo Ruiz Garcia [EMAIL PROTECTED] cc [EMAIL PROTECTED] Subject Re: HyperThreading On Wed, 27 Oct 2004, Pablo Ruiz Garcia wrote: - Original Message - From: Brian Ford snip To: Pablo Ruiz Garcia snip Cc: snip I'm sure you don't care, but... http://cygwin.com/acronyms/index.html#PCYMTNQREAIYR Sent: Wednesday, October 27, 2004 8:47 PM Subject: Re: HyperThreading On Wed, 27 Oct 2004, Pablo Ruiz Garcia wrote: Well I found a minor workaround.. set Affinity of proccess to only use one CPU (Thread). Threads and CPUs are not remotely the same things, so I don't know why you have that in parenthesis. I have it in parenthesis, because *I* know that CPUs and Threads are not the same, but as I'm talking about a problem with hyper-THREADING, I thought this way it would be easier to understand what i was talking about. I´m Sorry if this is a problem for you, but, in fact, I dont care anyway. Ok. But, I guess it's nice to know that you found a workaround for a problem only known to you. How do you expect it to ever be fixed if you don't actually report it, or at least confirm that it has already been reported? and exactly where... This problem has been reported in the past.. and I append a mail from another list member who includes references about this problem. Oh yeah, right! The HYPERTHREADED problem. I should have known! Please excuse my attempt to clarify so that I could actually try to debug it. Just curious if you read this part of: http://cygwin.com/problems.html Do not assume that your problem is so trivial or so well known that it does not require any details or background from you. Many (most?) people who report problems fall into the trap of assuming that people are clued into their mental state when, in most cases, this is not the case. As a rule of thumb, if you find yourself referring to your problem as the problem with XYZ rather than a problem with XYZ then your message is suspect. Using the in this context means that you are assuming that your problem is well known. Unless you can point to an email message thread or FAQ entry (either of which is a good idea, btw) please do not assume that the readers of your message will be familiar with your problem. as I suggested. --- Forwarded Mail --- AFAIK there was some kind of problem with hyperthreading on cygwin, do anyone know if this problems has been fixed? No. And they won't be fixed until someone sends a system or enough money to buy a system with to CGF. http://www.cygwin.com/ml/cygwin/2004-09/msg00082.html http://www.cygwin.com/ml/cygwin/2004-09/msg00091.html -Richard Campbell. I have tried tracing both of these threads back to a: http://cygwin.com/acronyms/index.html#STC without success. So, I have no idea what *your* HYPERTHREADED problem actually is. I rather doubt that anyone else does either. The test cases for this issue that I could find all appear to use pipes in bash, which have recently been shown to be buggy (PID reuse and exit status issues). If anyone still has a failing STC that doesn't use pipes in bash, please send it to me as I'd like to take a look. Personal email is fine as I'm sure CGF doesn't want to hear about this issue any more. I'm just wondering if there are really many left that haven't been explained, since I never see any. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... ForwardSourceID:NT00034952 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
