Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
On Wednesday, June 15, 2005, 1:02:45, [EMAIL PROTECTED] wrote: I'll have to hunt around. I'm not familiar with gtk2. http://www.gimp.org/win32/ has the development headers and libraries for GTK+ 2.4 and 2.6 (compiling GTK+ on Windows is a PITA). -- Jernej Simoncic http://deepthought.ena.si/ If you're feeling good, don't worry, you'll get over it. -- Law of mental health ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote: Seperate patches aren't necessarily the right thing to do It is without question. It really hurts a project in long term is if users by default run something else than the main version. A good way to help this area would be a compile farm doing nightly builds! This has been suggested before. Setting up a build farm (or scripts for an existing farm if there is one suitable) is a very good task for a user wanting to contribute to the project. Having developers time spent on configuring a build farm is waste of resources. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote: But it gets more than a little darn frustrating when you are enthused about the project, you try to help the devlopers and project by deliberately doing the testing to find bugs and problems, you report the bugs and problems. And nothing happens. Not an acknowledgement. Not a fix. Nothing. Not that week. Not that month. Not the next month. Basically, the effort you deliberately put into finding bugs and reporting the bugs has disappeared. This I buy. But I am not that convinced a bug reporting tool automatically helps the situation. A (open) bug reporting tool is only meaningful if there is developer resources to keep active track of the open bugs. If there isn't developer resources to actively monitor and work with the bug reporting tool the bugs just accumulate to the point that the reports looses their value. This can be seen in quite many of the projects on savanna where the number of bug reports is huge, and noone actively manages them so you don't really know if a bug still exists or if it will get acted upon.. but it is true that the reports doesn't get lost and sometimes it actually results in the bug being fixed years later provided the bug report has the relevant information to identify the problem. But from experience being the Squid HTTP Proxy release maintainer on an estimate about 20-30% of my time is spent on monitoring bug reports which doesn't really get anywhere (usually the reporter never comes back with requested additional information, or the problem is an old problen fixed in the current version). Another 20% is spent on invalid bug reports (configuration errors, bad builds, incorrect patching, not Squid being the cause to the problems etc). Levaing about 50% of my available time for real bug reports and development. While we do have (and use) a bug tracking tool most of the important bugs is discovered either from mailinglist discussions or internal testing. The perhaps most important benefit we have from the bug reporting tools is as a scratchpad for preleminary versions of the patches and to track forward porting of patches from the stable version to the development version. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
From: Jernej Simonèiè I'll have to hunt around. I'm not familiar with gtk2. http://www.gimp.org/win32/ has the development headers and libraries for GTK+ 2.4 and 2.6 (compiling GTK+ on Windows is a PITA). Thanks for the link It was starting to look a bit more complicated than I could deal with... ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
If you are using Windows: Try qvm86 + qemu (there was an old build of these two in freeoszoo) Linux: Try kqemu + qemu There are some problems that the combination of qemu + kqemu or qvm86 solve. lefteris. Jeff Wiegley wrote: I noticed that one other person a long time back had this same problem. http://lists.gnu.org/archive/html/qemu-devel/2005-02/msg00345.html Basically, when I boot from an original boot/rescue disk created by Norton Ghost 2003 I also get: Microsoft (R) Mouse Driver Version 8.20 Copyright (C) Microsoft Corp. 1983-1992 Copyright (C) IBM Corp. 1992-1993 Mouse Driver Installed Loading... Page Fault cr2=0fffbbb0 at eip-214; flags=3283 eax=ab00 ebx=1a001000 ecx=0004 edx=bbb0 esi=00281cb1 edi=1031 ebp=ab7f esp=3ffc cs=af ds=b7 es=b7 fs=a7 gs=0 ss=a7 error=0004 A:\GHOST Which is exactly the same as the original author. I was wondering if anybody fixed it and if so how? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
A points to note: It is free software, doesn't work for you, do not use it. -ishwar On Mon, 13 Jun 2005 [EMAIL PROTECTED] wrote: As near as I can tell, they haven't done a thing, and weren't the slightest bit interested in the bug report. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Norton Ghost crashes with page fault for me too.
I suspect that kernel acceleration (qvm86/kqemu) doesn't work with DOS (16bit) on a QEMU supported OS (32/64bit). Andreas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elefterios Stamatogiannakis Sent: Tuesday, June 14, 2005 3:55 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] Norton Ghost crashes with page fault for me too. If you are using Windows: Try qvm86 + qemu (there was an old build of these two in freeoszoo) Linux: Try kqemu + qemu There are some problems that the combination of qemu + kqemu or qvm86 solve. lefteris. Jeff Wiegley wrote: I noticed that one other person a long time back had this same problem. http://lists.gnu.org/archive/html/qemu-devel/2005-02/msg00345.html Basically, when I boot from an original boot/rescue disk created by Norton Ghost 2003 I also get: Microsoft (R) Mouse Driver Version 8.20 Copyright (C) Microsoft Corp. 1983-1992 Copyright (C) IBM Corp. 1992-1993 Mouse Driver Installed Loading... Page Fault cr2=0fffbbb0 at eip-214; flags=3283 eax=ab00 ebx=1a001000 ecx=0004 edx=bbb0 esi=00281cb1 edi=1031 ebp=ab7f esp=3ffc cs=af ds=b7 es=b7 fs=a7 gs=0 ss=a7 error=0004 A:\GHOST Which is exactly the same as the original author. I was wondering if anybody fixed it and if so how? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
From: Henrik Nordstrom [EMAIL PROTECTED] A points to note: It is free software, doesn't work for you, do not use it. I would put it in slightly different words: It's free software (as in free speech, not gratis), if it doesn't work for you fix it or have it fixed for you by whatever means you find suitable. If you do not want to have it fixed find an alternative which suits you better. Not all of us are developers. The best that many can do is test qemu and report problems when they are found. Some of us do a bit more, by deliberately testing qemu with lots of software, looking for bugs. And reporting bugs when they are found. But that's no excuse for bug reports to just vanish into the void. Without an awknowledgement or somebody writting it down as a bug in qemu that needs to get fixed eventually. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
Henrik Nordstrom All us users can do is make a report and sit back and wait to see if anything happens. Sometimes it can be a long wait. Or you could go the open-source approach and hire a developer (there is That's more than a little extreme. Frankly, it'd be a heck of a lot cheaper to buy and use vmware Oh wait... I *do* use vmware. I'm not silly enough to actually depend on qemu. Qemu is an opensource project that I hope I will be able to use someday. Until that time, I'm helping the development as best I can. plenty on the market if one cares to look) to fix the problems you may have. Certainly several (but perhaps not all) of the quirks you mentioned doesn't even require any qemu specifik knowledge. They would require at least some knowledge. Some of them more than a little amount. Only relying on the existing qemu developers pride may work in some cases, but it should be taken for what it is, not a warranty that things do get fixed in the line you want or when. No, I know there's no warranty. But it gets more than a little darn frustrating when you are enthused about the project, you try to help the devlopers and project by deliberately doing the testing to find bugs and problems, you report the bugs and problems. And nothing happens. Not an acknowledgement. Not a fix. Nothing. Not that week. Not that month. Not the next month. Basically, the effort you deliberately put into finding bugs and reporting the bugs has disappeared. I don't expect bugs to get fixed in 36 hours. No, of course not. Or even in a week or so. But it would be nice if the bug reports didn't just disappear into the void. As I said in my other message, Savanah has facilities for helping users and developers alike. Ways to report bugs (so they don't get lost) (Really... Do you know what bugs still exist in qemu??? No. Nobody does. Because they get forgotten about in a few days. Or the interested parties may miss the messages due to spam filtering.) Ways for bugs to be confirmed. Ways for developers to submit patches (so they don't get lost in spam filtering.) And so on. Qem is outgrowing the 'mailing list' approach. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote: It's free software (as in free speech, not gratis), if it doesn't work for you fix it or have it fixed for you by whatever means you find suitable. If you do not want to have it fixed find an alternative which suits you better. Not all of us are developers. And is why I said .. or have it fixed for you by whatever means you find suitable.. With a little imagination you will realize there is many options a) Politely tell the current developers about the bug and hope they eventually fix it. b) Try to fix it yourself. c) Convince someone more knowledgeable in programming than you to fix the problem for you. d) Hire a qemu developer to have the problem fixed for you. d) Hire a independent developer to have the problem fixed for you. e) Wine about the problem to make sure it won't get fixed for you, or if you are lucky pisses someone off to the point that they acually fixes the problem just to get you silent. and many more.. The best that many can do is test qemu and report problems when they are found. Then you have to accept that the developers do the best they can in their interest for the benefit of all. But that's no excuse for bug reports to just vanish into the void. Without an awknowledgement or somebody writting it down as a bug in qemu that needs to get fixed eventually. There rarely is a void these days. If you send a bug report to a public mailinglist then it a) Gets archived b) Other people later having the same problem quite likely finds it in the archives and refers to it when reporting the same issue again if it still isn't fixed. So even if there is no official bugtracking tool (which depending on the developer situation can be good or bad) the report isn't really lost. If you send bug reports in private directly to one developer then there may be a void if that developer decides the bug is not interesting for him to work on at that time. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
From: Henrik Nordstrom The best that many can do is test qemu and report problems when they are found. Then you have to accept that the developers do the best they can in their interest for the benefit of all. Generally, the way open source works is that a bug that directly effects a developer, gets fixed. They get annoyed enough they stop what they are doing and fix it. A bug that directly effects code they have written, might get checked into. If it's a bug they can live with or work around, it doesn't get fixed. And probably not reported, for that matter. If it's a bug that effects an OS that they don't use, it gets ignored. (Hence, the Windows builds were broken for a long time and nobody noticed it or if they did notice, didn't bother to fix it.) But that's no excuse for bug reports to just vanish into the void. Without an awknowledgement or somebody writting it down as a bug in qemu that needs to get fixed eventually. There rarely is a void these days. If you send a bug report to a public mailinglist then it That makes the very very large assumption that the developers deliberately go looking through the back message archives for bugs that haven't been fixed. After a couple days, people just forget about reported bugs. b) Other people later having the same problem quite likely finds it in the archives and refers to it when reporting the same issue again if it still isn't fixed. Similar bugs can show up in different ways. Even when a bug does show up repeatedly, and effects many people, doesn't mean anybody cares to look into it. It just turns into one of those consistant bugs that everybody knows about but no longer think of as a bug. It becomes a 'feature' or a 'quirk'. It's just the way qemu does things kind of mental shift. The cd changing bugs are excellent examples. They've been around for so long that most people in here no longer even think of them as bugs. They are just simply quirks in qemu. And because they are no longer 'bugs' but 'quirks', nobody even thinks to look into it. Never mind whether they would find the bug or be able to fix it. It's been around so long that they don't even *think* of it as a bug anymore, so they don't even *think* to look at it. (Im not saying the cd changing bugs are absolutely critical. Yes, it does prevent some OS's from being installed! But it doesn't crash qemu, etc. It does show how a bug can stop being thought of as a bug.) So even if there is no official bugtracking tool (which depending on the developer situation can be good or bad) the report isn't really lost. Technically, yes, it does get archived. But effectively it gets lost because it's no longer immediately visible as a bug. You have to specifically go looking for bug reports through the archives. And then go looking through the messages again to see if it's been fixed. (Either partially or fully.) Mailing lists can be very convenient. But they also make it easy for things to get essentially lost. If something isn't in a recent message, then your brain just tends to forget about it after a few days. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
On Tue, Jun 14, 2005 at 12:14:05PM -0500, [EMAIL PROTECTED] wrote: Not all of us are developers. The best that many can do is test qemu and report problems when they are found. Some of us do a bit more, by deliberately testing qemu with lots of software, looking for bugs. And reporting bugs when they are found. If you really want a bug to be fixed badly, and you have no idea of how to fix it, what you need to do is contact the developer of that code and let that person know about the bug. E.g. I'm the developer of the gtk2 interface for qemu, and I have no idea about what bugs it may have as no one has reported any to me. In fact, I have no idea if anyone is even using it because I get no direct feedback. This is especially true for using the gtk2 interface under Windows, because I am unable to test the code there. If someone who could test it did, and told me about the bug, I'd fix it right away. The only problem with this approach is that the section of code you are interested in having fixed may not have an active developer (person left a while ago or it was a section written by Fabrice himself that he doesn't have time to go over anymore). In that case, there isn't much you can do. Documenting bugs is still good because a) we can let other users know its a known bug and b) when a new maintainer for that section of code comes along, they'll be able to get started on the fixes right away. But this is only satisfactory if you are a very patient person. But that's no excuse for bug reports to just vanish into the void. Without an awknowledgement or somebody writting it down as a bug in qemu that needs to get fixed eventually. No one looks at the Savanah bug tracker because its never been used. If you were to say submit every unfixed bug you found there, just maybe those of us who bother to look every once in a while will see it and fix it. Do this often enough and others will use it, etc... the qemu user forum and the qemu irc channel developed in much the same way. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
Jim C. Brown I'm willing to do some testing. But you'll have to tell me how to do the gtk2 interface under windows. Well, you will need to apply the patches and compile from source yourself. Not to mention, you'll have to download the windows versions of the GTK2 libraries (you can probably get binaries). I'll have to hunt around. I'm not familiar with gtk2. But it gets significantly frustrating when you see the same problems month after month after month, etc. Only report it the first time you see it. And then sit back and wait for it to be forgotten[grimace] Some one of those bugs have actually been fixed. A patch was sent a while ago that got rid of bug #9441 IDE multimode failure. (Long before the bug itself was submitted.) So was the gcc 3.4 bug (which includes a link to the patch). Etc. Yes, I'm sure some of them are fixed... Nobody is even looking there. Except for the occasional user trying to be helpful, it's been ignored. Meanwhile, all those possibly helpful bug reports by users have gone to waste. I have to take that back. Savannah bug tracker is not a good way to go, as e.g. even if the bugs are fixed none of the developers can say so or close the bug. Only Fabrice has access. Also, only he has commit access so good patches, such as the graphics patch, don't always make it in right away. I can't comment about how to close bugs... I've never done that. As for submitting patches, Savanah has a facility to do that, too. They can be submitted seperately. I would expect the most that would be needed would be registration. (The qemu page doesn't have it enabled, but Savanah has that ability. I've seen it on other projects.) Yes, more communication is needed. We shouldnt be bothered by bugs which have patches to fix them or bugs that are a non issue or bugs that are easily Seperate patches aren't necessarily the right thing to do Most are *users*. They aren't going to build their own. They will download one of the pre-made binaries, which is likely to be just CVS. Maybe with one or two critical patches, but maybe not. A good way to help this area would be a compile farm doing nightly builds! This has been suggested before. That way, everybody can get up to date cvs builds. With the important patches applied. As a side note, I have a hackish patch that will allow you to change the cdrom in the monitor to a filename that includes spaces. It was not a difficult change to implement. I don't see why you couldn't have fixed that yourself (if it hasn't already been fixed in main CVS). I don't think it's been fixed in cvs. Although I admit I haven't checked with the last couple cvs builds. As for fixing it myself... I'm not really a developer. I used to write some C code. Nothing really fancy. But that's been a while. I haven't even had a compiler installed for about two years. I only recently did one when somebody in the qemu-user's forum explained how to compile the cvs version under windows. Until then, I didn't even know how to compile qemu. Qemu does it in the linux style, and I wasn't familiar with that. Getting back up to speed in C would take me a little while. Getting up to speed with qemu, and familiar with the style that Fabrice uses, etc. would take more time. And although I might be able to fix one or two trivial bugs, I seriously doubt I'd be able to do the others. They require significant knowledge of qemu, and of how the hardware is supposed to work and how it's being emulated. Not everybody can just 'jump in' and do that kind of work. It's not time that I want to waste. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Norton Ghost crashes with page fault for me too.
I noticed that one other person a long time back had this same problem. http://lists.gnu.org/archive/html/qemu-devel/2005-02/msg00345.html Basically, when I boot from an original boot/rescue disk created by Norton Ghost 2003 I also get: Microsoft (R) Mouse Driver Version 8.20 Copyright (C) Microsoft Corp. 1983-1992 Copyright (C) IBM Corp. 1992-1993 Mouse Driver Installed Loading... Page Fault cr2=0fffbbb0 at eip-214; flags=3283 eax=ab00 ebx=1a001000 ecx=0004 edx=bbb0 esi=00281cb1 edi=1031 ebp=ab7f esp=3ffc cs=af ds=b7 es=b7 fs=a7 gs=0 ss=a7 error=0004 A:\GHOST Which is exactly the same as the original author. I was wondering if anybody fixed it and if so how? -- Jeff Wiegley, PhDhttp://www.csun.edu/~jeffw Computer Science Assistant ProfessorEA1407 Engineering Addition California State University Northridge email [EMAIL PROTECTED] 18111 Nordhoff Street office phone 818.677.3887 Northridge CA 91330-8281CS Dept. phone 818.677.3398 USA (ignore:cea2d3a38843531c7def1deff59114de) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.
As near as I can tell, they haven't done a thing, and weren't the slightest bit interested in the bug report. They don't even seem to keep track of reported bugs. If a developer happens to see a bug report about something he worked on, he might check into it. But otherwise it gets forgotten in a day or two. I'd think that the bug tracker at Savanah would be very useful for a project, but apparently it doesn't get used. I don't think any of the devlopers or Fabrice have even suggested it get used to track bugs. Savanah has a number of useful tools bug tracking, file download areas (for executables, etc.), task manager. Even a patch manager, so people can submit patches easily. Lots of things to help developers and users alike. But none of that gets used. Everything gets done though a mailing list, where it's easy to forget about stuff. (Or in my case, not even get the message, due to spam filtering.) FreeDOS mouse, various cd changing bugs, and qemu-img raw with 2g+ images are three other significant items that have never been fixed. Plus there are times when qemu effects the host's mouse, even after qemu shuts down. (Might be a Windows / SDL problem. Dunno.) One minor one (but relatively easy to work on) is spaces in filenames. Qemu can't do it in the monitor. Can make it impossible to change floppies or cd's, some times. I'm not even sure if anybody has investigated the problems. If a developer has a problem, then they can check into it themselves, of course. All us users can do is make a report and sit back and wait to see if anything happens. Sometimes it can be a long wait. - Original Message - From: Jeff Wiegley [EMAIL PROTECTED] To: qemu-devel@nongnu.org Sent: Monday, June 13, 2005 12:49 PM Subject: [Qemu-devel] Norton Ghost crashes with page fault for me too. I noticed that one other person a long time back had this same problem. http://lists.gnu.org/archive/html/qemu-devel/2005-02/msg00345.html Basically, when I boot from an original boot/rescue disk created by Norton Ghost 2003 I also get: Microsoft (R) Mouse Driver Version 8.20 Copyright (C) Microsoft Corp. 1983-1992 Copyright (C) IBM Corp. 1992-1993 Mouse Driver Installed Loading... Page Fault cr2=0fffbbb0 at eip-214; flags=3283 eax=ab00 ebx=1a001000 ecx=0004 edx=bbb0 esi=00281cb1 edi=1031 ebp=ab7f esp=3ffc cs=af ds=b7 es=b7 fs=a7 gs=0 ss=a7 error=0004 A:\GHOST Which is exactly the same as the original author. I was wondering if anybody fixed it and if so how? -- Jeff Wiegley, PhDhttp://www.csun.edu/~jeffw Computer Science Assistant ProfessorEA1407 Engineering Addition California State University Northridge email [EMAIL PROTECTED] 18111 Nordhoff Street office phone 818.677.3887 Northridge CA 91330-8281CS Dept. phone 818.677.3398 USA (ignore:cea2d3a38843531c7def1deff59114de) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
