"Hyperthreading" problems
Hi, 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. I used the following test (found on this mailing list archive, posted 6 Apr 2004 by Chuck McDevitt): #! /bin/ksh mypath=$(pwd) while [[ ! -z $mypath ]] do mypath=$(pwd) if [[ -z $mypath ]] then echo "Test Failed..Path is empty" fi done in one shell, while running a large make in another, it will fail in a variety of ways. Under pdksh, it sometimes exits the test because "mypath" is empty, or it core dumps, or hangs, or gives error messages. Under bash, it hangs, crashes, or gives error messages (haven't seen it exit the loop, but I didn't try long with bash). By "hang", I mean the shell stops using CPU time, and become non-responsive, and can only be stopped by killing the process. The problem does not occur if hyperthreading is turned off. When booting the server in single CPU (/ONECPU in boot.ini) the problem does not appear. More interesting, if I lock my bash session on a particular CPU by using SetProcessAffinityMask, so that all child processes created by this shell are locked on one CPU, the problem does not appear. It seems that the bug has something to do with a same Cygwin process being swapped from one CPU to another when running a piece of code that is not locked properly (i.e. missing EnterCriticalSection or something like that). Regards, Stephane cygcheck.out Description: Binary data -- 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): > > > >#! /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" 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. > 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. > > 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
-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
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. 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. -- 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: >> >> >>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. > > >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/