[Qemu-devel] Re: Latest CVS build of qemu-system-ppc no longer seems to work on FC3 x86_64

2005-06-15 Thread Ronald
Le Mon, 13 Jun 2005 15:17:01 +0200, Bob Deblier a écrit :

 Hi,
 
 As of the latest cvs update, qemu-system-ppc no longer seems to function
 properly. I've tried:
 
 - MacOS X 10.3 used to boot up to a grey screen with the Apple logo - now
 shows a black screen at 100% cpu usage. - Fedora Core development ISO ppc
 (mac), used to boot up to a certain point - same story.
 - Debian Sarge, same story.
 

I have problems too with latest cvs (on x86 for me), the mac partition
table is not recognized at all and I am unable to have more than a primary
partition with dos scheme.
With mac partition table , I get 'lost interrupt' message , when I try to
write the table (in a qemu session) or when I try to read one created
outside. Booting/running with a floppy image is the only way I can have it
works (-M prep).

 Always prepared to help test/debug this issue.
 
 Sincerely,
 
 Bob Deblier




___
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.

2005-06-15 Thread Jernej Simončič
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.

2005-06-15 Thread Henrik Nordstrom

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.

2005-06-15 Thread Henrik Nordstrom

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] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

2005-06-15 Thread Henrik Nordstrom

On Tue, 14 Jun 2005, Jim C. Brown wrote:


Because in active mode, the ftp server attempts to connect to a port on the
ftp client, in the guest. Due to the limitations of slirp, this is not possible
(in theory one could use redir support to work around this, but this is not
an easy task).


slirp is supposed to automatically NAT this on FTP connections on port 
21, but perhaps there is something fishy with the version embedded in 
qemu..


When you FTP to the virtual address then this tranlation is required both 
ways (both PORT  PASV). The difference is mainly when you FTP to the real 
host address.


Regards
Henrik


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] O/2 Warp 4 and eComStation

2005-06-15 Thread ecs user
There are problems booting Warp4 and eComtation. 
System hangs while loading certain drivers (IDE, DASD,
Diskette). By repeatedly booting, sometimes can get a
successful boot. Might be some type of timing issue.
 
I have some small test images that demonstrate the
problem. Are there any developers here familiar with
OS/2 that could look at this issue?

Is there a place I can upload the images (15MB)?





__ 
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruct

2005-06-15 Thread ecs user
 Tero Kaarlela wrote:
 Could this be because OS/2 can't handle this much
 ram(128mb).
 
eComStation can do at least 2GB and with updates 4GB
OS/2 Warp4 should be able to handle 256MB

 OS/2 has always been very specific about maximum
 memory(ie. versions 1.x can't boot on machines
 that report more than 16mb ram. this is one of the
 reasons 1.x versions dont boot under Qemu and
 thats why many BIOSES have option boot to OS/2). 
 
Don't use those motherboard BIOS settings with
eComStation or OS/2 Warp4. Leave the BIOS setting at
default - OS/2 use greater than 64MB = No




__ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruct

2005-06-15 Thread Tero Kaarlela

ecs user wrote:


Tero Kaarlela wrote:
Could this be because OS/2 can't handle this much
ram(128mb).
   



eComStation can do at least 2GB and with updates 4GB
OS/2 Warp4 should be able to handle 256MB



 Well I was talking about OS/2 PowerPC edition (Released december 1995)
  During that time Warp V3 could handle 64mb maximum. This was 
mentioned somewhere in my earlier post.


 


OS/2 has always been very specific about maximum
memory(ie. versions 1.x can't boot on machines
that report more than 16mb ram. this is one of the
reasons 1.x versions dont boot under Qemu and
thats why many BIOSES have option boot to OS/2). 
   



Don't use those motherboard BIOS settings with
eComStation or OS/2 Warp4. Leave the BIOS setting at
default - OS/2 use greater than 64MB = No

 


Yes I knew this already(This option is for 1.x OS/2)


Tero



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Re: Norton Ghost crashes with page fault for me too.

2005-06-15 Thread jeebs
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.

From http://www.gimp.org/win32/  I downloaded the recommended versions of:

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 compilergcc
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.)




___
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.

2005-06-15 Thread jeebs
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


[Qemu-devel] Re: Norton Ghost crashes with page fault for me too.

2005-06-15 Thread Heike C. Zimmerer
Jim C. Brown [EMAIL PROTECTED] writes:

 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



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] O/2 Warp 4 and eComStation

2005-06-15 Thread Tero Kaarlela

Natalia Portillo wrote:


Try to boot it with less than 64Mb (48Mb for example).

OS/2 hangs when 64Mb are informed in the standard way they seems to  
check that in some strange way.


No matter it is 4.0, 4.5, eCS or whatever. 



   Could this be because of OS/2 memory handling differs from many 
others in this way:


Memory filling is started from top to bottom 
?(highest address first)




Tero Kaarlela



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Re: Norton Ghost crashes with page fault for me too.

2005-06-15 Thread Jim C. Brown
On Wed, Jun 15, 2005 at 12:28:35PM -0500, [EMAIL PROTECTED] wrote:
 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.
 
 From http://www.gimp.org/win32/  I downloaded the recommended versions of:
 
 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.

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

No.

 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 compilergcc
 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.
/* TODO: figure out how to handle linux framebuffer case - need to call the 
gdk-fb specific handle_mouse_movement() function in gdkmouse-fb.c ... that gets 
ugly fast .. */

#ifndef _WIN32

#include gdk/gdk.h
#include gdk/gdkx.h
#include X11/X.h

 GdkWindow*
gdk_window_set_pointer (GdkWindow   *window,
   gintx,
   ginty)
{
  GdkWindow *return_val;

  return_val = NULL;
  XWarpPointer (GDK_WINDOW_XDISPLAY(window), None, GDK_WINDOW_XID(window), 0, 
0, 0, 0, x, y);

  return return_val;
}

#else

/* untested code based on MSDN library code... URL is :

  http://msdn.microsoft.com/library/default.asp?url=/library/
  en-us/winui/winui/windowsuserinterface/resources/cursors/
  usingcursors.asp 

Someone who codes on Windows want to tell me how to actually make this work??

*/

#include gdk/gdk.h
#include gdk/gdkwin32.h
#include windows.h

 GdkWindow*
gdk_window_set_pointer (GdkWindow   *window,
   gintx,
   ginty)
{
GdkWindow *return_val;
POINT pt;
pt.x = x;
pt.y = y;
ClientToScreen(GDK_WINDOW_HWND(window), pt);
SetCursorPos(pt.x, pt.y);
return_val = NULL;
return return_val;
}

#endif

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] O/2 Warp 4 and eComStation

2005-06-15 Thread Natalia Portillo

Surely.

There is also a problem in OS/2 16-bit with the 15-16Mb portion,  
seems that the OS/2 pretends to put there something (the BIOS,  
surely, as this version was able of loading a disk-based protected  
mode BIOS' based ROM and had one for AT and one for PS/2 machines,  
the ABIOS was called, see old OS/2 books) in RAM and maybe is making  
that portion of RAM to appear at that location, and if that portion  
isn't empty (has real memory) the system hangs.


El 15/06/2005, a las 19:21, Tero Kaarlela escribió:


Natalia Portillo wrote:



Try to boot it with less than 64Mb (48Mb for example).

OS/2 hangs when 64Mb are informed in the standard way they seems  
to  check that in some strange way.


No matter it is 4.0, 4.5, eCS or whatever.



   Could this be because of OS/2 memory handling differs from many  
others in this way:


Memory filling is started from top to bottom ? 
(highest address first)




Tero Kaarlela



___
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


[Qemu-devel] [PATCH] cirrus_vga.c and win95, another one

2005-06-15 Thread Magnus Damm
Hello,

Here comes another small fix for the cirrus code. This makes win95
(swedish version) behave correctly. I am not sure if the patch breaks
something else though. 

Have a look at the attached pictures, compare the funny looking striped
background behind the text with the correct checkered background.

Please apply.

/ magnus

attachment: without_patch.pngattachment: with_patch.pngIndex: hw/cirrus_vga_rop2.h
===
RCS file: /cvsroot/qemu/qemu/hw/cirrus_vga_rop2.h,v
retrieving revision 1.6
diff -u -r1.6 cirrus_vga_rop2.h
--- hw/cirrus_vga_rop2.h	26 Apr 2005 20:49:17 -	1.6
+++ hw/cirrus_vga_rop2.h	16 Jun 2005 02:02:23 -
@@ -61,8 +61,8 @@
 pattern_pitch = 32;
 #endif
 pattern_y = s-cirrus_blt_srcaddr  7;
-pattern_x = skipleft;
 for(y = 0; y  bltheight; y++) {
+pattern_x = skipleft;
 d = dst + skipleft;
 src1 = src + pattern_y * pattern_pitch;
 for (x = skipleft; x  bltwidth; x += (DEPTH / 8)) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] Server down ?

2005-06-15 Thread Jens Arm
Hi

Looks like the Server is down, or?

Service Unavailable 
Apache/ProXad [Dec 22 2004 18:41:28] Server at fabrice.bellard.free.fr Port 80


Jens


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] Re: xen is not working with qemu0.7/kqemu

2005-06-15 Thread John R. Hogerhuis
On Mon, 2005-06-13 at 10:28 -0400, Ishwar Rattan wrote:
 Why would anyone want run an emulator in another emulator..
 
 -ishwar

Well at least it's hard to argue with the fact that it's an excellent
'pathological case' to test QEMU.

-- John.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel