Discussion:
Norton Ghost crashes with page fault for me too.
(too old to reply)
Jeff Wiegley
2005-06-13 17:49:08 UTC
Permalink
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=ffffab00 ebx=1a001000 ecx=00000004 edx=ffffbbb0 esi=00281cb1
edi=00001031
ebp=ffffab7f esp=00003ffc 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, PhD http://www.csun.edu/~jeffw
Computer Science Assistant Professor EA1407 Engineering Addition
California State University Northridge email ***@csun.edu
18111 Nordhoff Street office phone 818.677.3887
Northridge CA 91330-8281 CS Dept. phone 818.677.3398
USA (ignore:cea2d3a38843531c7def1deff59114de)
j***@yango.us
2005-06-14 02:37:54 UTC
Permalink
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" <***@csun.edu>
To: <qemu-***@nongnu.org>
Sent: Monday, June 13, 2005 12:49 PM
Subject: [Qemu-devel] Norton Ghost crashes with page fault for me too.
Post by Jeff Wiegley
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
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=ffffab00 ebx=1a001000 ecx=00000004 edx=ffffbbb0 esi=00281cb1
edi=00001031
ebp=ffffab7f esp=00003ffc 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, PhD http://www.csun.edu/~jeffw
Computer Science Assistant Professor EA1407 Engineering Addition
18111 Nordhoff Street office phone 818.677.3887
Northridge CA 91330-8281 CS Dept. phone 818.677.3398
USA (ignore:cea2d3a38843531c7def1deff59114de)
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Ishwar Rattan
2005-06-14 13:43:14 UTC
Permalink
A points to note:

It is free software, doesn't work for you, do not use it.

-ishwar
Post by j***@yango.us
As near as I can tell, they haven't done a thing, and weren't the slightest
bit interested in the bug report.
Henrik Nordstrom
2005-06-14 16:39:00 UTC
Permalink
Post by Ishwar Rattan
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.

Regards
Henrik
j***@yango.us
2005-06-14 17:14:05 UTC
Permalink
Post by Henrik Nordstrom
Post by Ishwar Rattan
It is free software, doesn't work for you, do not use it.
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.
Henrik Nordstrom
2005-06-14 17:40:41 UTC
Permalink
Post by j***@yango.us
Post by Henrik Nordstrom
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..
Post by j***@yango.us
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.
Post by j***@yango.us
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
j***@yango.us
2005-06-14 18:51:10 UTC
Permalink
From: "Henrik Nordstrom"
Post by Henrik Nordstrom
Post by j***@yango.us
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.)
Post by Henrik Nordstrom
Post by j***@yango.us
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.
Post by Henrik Nordstrom
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.

(I"m 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.)
Post by Henrik Nordstrom
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.
Herbert Poetzl
2005-06-15 04:08:54 UTC
Permalink
Post by j***@yango.us
From: "Henrik Nordstrom"
Post by Henrik Nordstrom
Post by j***@yango.us
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.)
well, sounds sane to me, or do you fix your
neighbors broken kitchen sink, just because
you heard him complain about it, instead of
fixing your own?
Post by j***@yango.us
Post by Henrik Nordstrom
Post by j***@yango.us
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.
if there _are_ good reasons for them to do
so, they'll probably do it ...
Post by j***@yango.us
After a couple days, people just forget about reported bugs.
and real bugs pop up again and again ... which
is a very good method to filter real bugs from
coincidential issues ...
Post by j***@yango.us
Post by Henrik Nordstrom
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.
so?
Post by j***@yango.us
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.
(I"m 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.)
if somebody cares enough, s/he will fix it or
make sure that it gets fixed ... whining is
probably the worst way to achieve this ...
Post by j***@yango.us
Post by Henrik Nordstrom
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.
you are free to collect and prepare the bug
reports for them, just create your own page
with a list of (for you or others) relevant
bugs and possible fixes/workarounds. I'm pretty
confident the developers will make good use of
this page (if you do the collecting part) and
a bunch of issues will get fixed pretty fast ...

ah, and don't forget to announce it on the ML

best,
Herbert
Post by j***@yango.us
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Jim C. Brown
2005-06-14 20:27:12 UTC
Permalink
Post by j***@yango.us
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.
Post by j***@yango.us
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.
Ronald
2005-06-14 20:54:41 UTC
Permalink
Post by Jim C. Brown
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.
If I can get gtk2 to work on windows , be sure I'll report/share , but
at this time I have had no success with gtk-2.4 (something about
mms-bitfields and gtk_box) on win98 (that's all I have), at least I can
build but can't run it with -use-gtk.
j***@yango.us
2005-06-14 21:15:41 UTC
Permalink
"Jim C. Brown"
Post by Jim C. Brown
Post by j***@yango.us
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.
That's not really practical, because most of us would have no idea who to
contact.
Post by Jim C. Brown
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.
I do use the Windows builds...

I'm willing to do some testing. But you'll have to tell me how to do the
gtk2 interface under windows.....

The only interface I know of is the regular SDL interface in the windows
version.

But yes, if you really do want somebody to test it, and do want feedback,
then I am willing to try. It wont be a major test for hours and hours kind
of thing. But I can play around with it for a while and see if there are
any obvious problems.


Contrary to what some might suspect, I *am* willing to test qemu and report
bugs. But only for as long as I think it might do any good, and that I'm
not being ignored.

Even the acknowledgement of a bug can be a major encouragement to find and
report new problems.
Post by Jim C. Brown
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.
I have been willing to do that.

But it gets significantly frustrating when you see the same problems month
after month after month, etc.

Bug reporting tends to feel a lot like shouting in a room full of deaf
people...

And bug reports get lost so easily.

If you aren't the developer of that piece of code, what are the odds that
you are actually going to remember the bug in a few days?
Post by Jim C. Brown
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.
I have thought about it.

I've even started to do it a few times. Come to think of it, I even did
that a few times in the past year.

But since it's not used, and none of the developers suggest it being used, I
tend to get the feeling that it'd be a waste of time.

Right now, there are 50 bugs reported, and 50 bugs open.

http://savannah.nongnu.org/bugs/?group=qemu
Post by Jim C. Brown
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.
The qemu user forum does get regular comments about bugs etc.

About the best we can tell them is something like "Yes, that looks like a
bug. No, it probaly isn't going to get fixed any time soon. No, most of
the qemu developers don't visit here."
Jim C. Brown
2005-06-14 22:18:50 UTC
Permalink
Post by j***@yango.us
"Jim C. Brown"
Post by Jim C. Brown
Post by j***@yango.us
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.
That's not really practical, because most of us would have no idea who to
contact.
I didn't think about that. I generally ask that on the irc channel, and get
my answer there. Or I search the archives to see who was working on the code.

But if there is no developer, it may take a lot of work just to find that out.
Post by j***@yango.us
Post by Jim C. Brown
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.
I do use the Windows builds...
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).

Let me know if you need clearer instructions.
Post by j***@yango.us
The only interface I know of is the regular SDL interface in the windows
version.
They should look identical. Fabrice mentioned some SDL keyboard bugs,
presumably you won't see those in the GTK version.

I'll let you know now: Fullscreen mode won't work. The mouse will be grabbed
(and made ungrabbable until you exit "fullscreen" mode) and the window will
be moved to the top left corner of the screen. Otherwise, no difference (if
my code works). Everything else should work identically between the two.
Post by j***@yango.us
But yes, if you really do want somebody to test it, and do want feedback,
then I am willing to try. It wont be a major test for hours and hours kind
of thing. But I can play around with it for a while and see if there are
any obvious problems.
That would be great.
Post by j***@yango.us
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.
Post by j***@yango.us
Bug reporting tends to feel a lot like shouting in a room full of deaf
people...
And bug reports get lost so easily.
If you aren't the developer of that piece of code, what are the odds that
you are actually going to remember the bug in a few days?
If you are the developer, you will remember the bug. Otherwise, it doesn't
really matter if you remember or not (in the sense that forgetting will hurt
things).
Post by j***@yango.us
Post by Jim C. Brown
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.
I have thought about it.
I've even started to do it a few times. Come to think of it, I even did
that a few times in the past year.
But since it's not used, and none of the developers suggest it being used, I
tend to get the feeling that it'd be a waste of time.
Right now, there are 50 bugs reported, and 50 bugs open.
http://savannah.nongnu.org/bugs/?group=qemu
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.

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.

Still, not enough developers have had issues with the way Fabrice runs things,
so thats not likely to change.
Post by j***@yango.us
Post by Jim C. Brown
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.
The qemu user forum does get regular comments about bugs etc.
About the best we can tell them is something like "Yes, that looks like a
bug. No, it probaly isn't going to get fixed any time soon. No, most of
the qemu developers don't visit here."
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
worked around, and users should be able to find the answers to this easily.
But I am not entirely sure why this is not the case right now, so I have no
bright idea to suggest. Someone else will have to fill the void here.


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).
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
j***@yango.us
2005-06-14 23:02:45 UTC
Permalink
"Jim C. Brown"
Post by Jim C. Brown
Post by j***@yango.us
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.
Post by Jim C. Brown
Post by j***@yango.us
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]
Post by Jim C. Brown
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.
Post by Jim C. Brown
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.)
Post by Jim C. Brown
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.
Post by Jim C. Brown
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.
Jernej Simončič
2005-06-15 09:23:25 UTC
Permalink
Post by j***@yango.us
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
j***@yango.us
2005-06-15 17:30:02 UTC
Permalink
From: "Jernej Simonèiè"
Post by Jernej Simončič
Post by j***@yango.us
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...
Henrik Nordstrom
2005-06-15 13:36:33 UTC
Permalink
Post by j***@yango.us
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.
Post by j***@yango.us
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
Heike C. Zimmerer
2005-06-14 21:46:32 UTC
Permalink
Post by Jim C. Brown
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.
I'm using the snapshots from dad-answers.com/qemu/, and from time to
time did a grep for gtk through the entire source tree, but didn't
find any mention of it there.

Maybe I've missed something, so could you explain how to get hold of
the gtk code? Thanks.

- Heike
Jim C. Brown
2005-06-14 22:43:08 UTC
Permalink
Post by Heike C. Zimmerer
Post by Jim C. Brown
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.
I'm using the snapshots from dad-answers.com/qemu/, and from time to
time did a grep for gtk through the entire source tree, but didn't
find any mention of it there.
Maybe I've missed something, so could you explain how to get hold of
the gtk code? Thanks.
- Heike
They weren't committed to the CVS tree yet. You'll need to get it in patch
form. I'm reattaching all the necessary patches and files here, so you can get
it all in one place. (The .c files I've attached should be dropped in the main qemu
directory).
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
j***@yango.us
2005-06-15 17:28:35 UTC
Permalink
"Jim C. Brown"
Post by Jim C. Brown
They weren't committed to the CVS tree yet. You'll need to get it in patch
form. I'm reattaching all the necessary patches and files here, so you can get
it all in one place. (The .c files I've attached should be dropped in the main qemu
directory).
Here are the steps I did.

I follwed the mingw compilation instructions posted in the qemu-user's
forum. Just to make sure that my setup was working.
atk-1.8.0.zip
atk-dev-1.8.0.zip
gettext-runtime-0.13.1.zip
glib-2.4.7.zip
glib-dev-2.4.7.zip
gtk+-2.4.14.zip
gtk+-dev-2.4.14.zip
libiconv-1.9.1.bin.woe32.zip
pango-1.4.1.zip
pango-dev-1.4.1.zip
pkgconfig-0.15.zip

I unzipped those in the msys/mingw directory.

I then ran the msys program to get a 'linux shell'.

I did a make clean in qemu.

I copied all your files to the qemu directory.

I did "patch <qemu-gtk-patch.diff" and "patch <vl.c.diff" Was I supposed to
use any options?

I did:

./configure --target-list=i386-softmmu --static --enable-gtk

and got:

Install prefix /c/Program Files/Qemu
BIOS directory /c/Program Files/Qemu
binary directory /c/Program Files/Qemu
Source path /home/Admin/qemu
C compiler gcc
make make
host CPU i386
host big endian no
target list i386-softmmu
gprof enabled no
static build yes
SDL support yes
SDL static link yes
GTK support yes
GTK FS driver null_fs.c
mingw32 support yes
Adlib support no
FMOD support no
kqemu support no

Then 'make' and I got this error right at the end...

H:/MSys/home/Admin/qemu/gdk_set_window_pointer.c:45: undefined reference to
`GDK_WINDOW_HWND'

(Plus, the usual assortment of warnings in a typical qemu build.)
Jim C. Brown
2005-06-15 18:54:58 UTC
Permalink
Post by j***@yango.us
Here are the steps I did.
I follwed the mingw compilation instructions posted in the qemu-user's
forum. Just to make sure that my setup was working.
atk-1.8.0.zip
atk-dev-1.8.0.zip
gettext-runtime-0.13.1.zip
glib-2.4.7.zip
glib-dev-2.4.7.zip
gtk+-2.4.14.zip
gtk+-dev-2.4.14.zip
libiconv-1.9.1.bin.woe32.zip
pango-1.4.1.zip
pango-dev-1.4.1.zip
pkgconfig-0.15.zip
I unzipped those in the msys/mingw directory.
I then ran the msys program to get a 'linux shell'.
I did a make clean in qemu.
I copied all your files to the qemu directory.
Looks like you did everything correctly.
Post by j***@yango.us
I did "patch <qemu-gtk-patch.diff" and "patch <vl.c.diff" Was I supposed to
use any options?
No.
Post by j***@yango.us
./configure --target-list=i386-softmmu --static --enable-gtk
Install prefix /c/Program Files/Qemu
BIOS directory /c/Program Files/Qemu
binary directory /c/Program Files/Qemu
Source path /home/Admin/qemu
C compiler gcc
make make
host CPU i386
host big endian no
target list i386-softmmu
gprof enabled no
static build yes
SDL support yes
SDL static link yes
GTK support yes
GTK FS driver null_fs.c
mingw32 support yes
Adlib support no
FMOD support no
kqemu support no
Then 'make' and I got this error right at the end...
H:/MSys/home/Admin/qemu/gdk_set_window_pointer.c:45: undefined reference to
`GDK_WINDOW_HWND'
(Plus, the usual assortment of warnings in a typical qemu build.)
I don't know how to fix that. GDK_WINDOW_HWND() is defined in a file called
gdkwin32.h

I've attached a modified version that includes gdkwin32.h directly. Just put
this file in qemu's directory (overwriting the old file). If you have gdkwin32.h
in your gdk include directory this should fix the error.

If this version doesn't work I'll try to write a replacement marco (gtk uses many
internal macros - sometimes it can get real ugly).
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
Heike C. Zimmerer
2005-06-15 18:11:04 UTC
Permalink
Post by Jim C. Brown
Post by Heike C. Zimmerer
Maybe I've missed something, so could you explain how to get hold of
the gtk code? Thanks.
I'm reattaching all the necessary patches and files here, so you can get
it all in one place. (The .c files I've attached should be dropped in the main qemu
directory).
Thanks. Though I'm not familiar with gtk2 internals, I hope to be
able to provide some useful feedback within the next few days.

- Heike
Henrik Nordstrom
2005-06-14 16:30:54 UTC
Permalink
Post by j***@yango.us
If a developer has a problem, then they can check into it themselves, of
course.
Yes.
Post by j***@yango.us
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
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.

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.

Regards
Henrik
j***@yango.us
2005-06-14 17:11:25 UTC
Permalink
"Henrik Nordstrom"
Post by Henrik Nordstrom
Post by j***@yango.us
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.
Post by Henrik Nordstrom
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.
Post by Henrik Nordstrom
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.
Henrik Nordstrom
2005-06-15 13:20:15 UTC
Permalink
Post by j***@yango.us
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
Elefterios Stamatogiannakis
2005-06-14 13:54:48 UTC
Permalink
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.
Post by Jeff Wiegley
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
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=ffffab00 ebx=1a001000 ecx=00000004 edx=ffffbbb0 esi=00281cb1
edi=00001031
ebp=ffffab7f esp=00003ffc 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?
Andreas Bollhalder
2005-06-14 15:45:53 UTC
Permalink
I suspect that kernel acceleration (qvm86/kqemu) doesn't work with DOS
(16bit) on a QEMU supported OS (32/64bit).

Andreas
-----Original Message-----
Behalf Of Elefterios Stamatogiannakis
Sent: Tuesday, June 14, 2005 3:55 PM
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.
Post by Jeff Wiegley
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
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=ffffab00 ebx=1a001000 ecx=00000004 edx=ffffbbb0 esi=00281cb1
edi=00001031
ebp=ffffab7f esp=00003ffc cs=af ds=b7 es=b7 fs=a7 gs=0
ss=a7 error=0004
Post by Jeff Wiegley
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
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Continue reading on narkive:
Loading...