Re: [Qemu-devel] Crash: When Host HDD is full
>From a usability perspective, I also would expect this to be the correct behaviour. Non-technical users using, say, Windows (in full-screen mode) on a GNU/Linux desktop need to know that their HDD is full and they must free up space - not have the guest complain about cryptic HDD errors and failed writes (assuming the guest OS can even be trusted to do this). Pausing the VM and notifying the user of no free host storage space is also the same behaviour as other virtualization products, so this might already be the expected behaviour from the user's POV. At the very least, I feel a switch to enable this behaviour would be appropriate. -Adam On Thu, 2007-07-12 at 23:39 +0300, Alexey Eremenko wrote: > Pause VMs is the only realistic option. This is the correct option, > because it ensures that guest is still alive. > Other options might crash the guest, like Windows BSOD. Worse yet is > that guest may think that it's hard disk is bad, and will start > marking it's sectors as bad-blocks. > > When the VM is paused, the user may take action to free some disk > space and unpause guest manually. >
Re: [Qemu-devel] Crash: When Host HDD is full
Am 19.07.2007 um 09:25 schrieb Adam Bolte: >From a usability perspective, I also would expect this to be the correct behaviour. Non-technical users using, say, Windows (in full-screen mode) on a GNU/Linux desktop need to know that their HDD is full and they must free up space - not have the guest complain about cryptic HDD errors and failed writes (assuming the guest OS can even be trusted to do this). Pausing the VM and notifying the user of no free host storage space is also the same behaviour as other virtualization products, so this might already be the expected behaviour from the user's POV. At the very least, I feel a switch to enable this behaviour would be appropriate. Having developed applications for memory-limited devices I agree that an application must handle any cases, whether assumed common or not, including out-of-memory situations. So qemu should always detect this and handle it in some way. Regarding the user's point of view described above, I concur that a switch would be a good compromise. However given that someone using CVS head is likely to read the mailing list and all other users upgrading should read the release notes, this option should be the default or otherwise exactly those users the feature is targeted at will not use the switch! It's also more frontend-friendly not needing an additional switch for mainstream users. Andreas
Re: [Qemu-devel] Crash: When Host HDD is full
On 7/19/07, Andreas Färber <[EMAIL PROTECTED]> wrote: Regarding the user's point of view described above, I concur that a switch would be a good compromise. However given that someone using CVS head is likely to read the mailing list and all other users upgrading should read the release notes, this option should be the default or otherwise exactly those users the feature is targeted at will not use the switch! It's also more frontend-friendly not needing an additional switch for mainstream users. Agreed. This bug is critical in both senses - from developer's point of view - that's a crash - something should be prevented at all costs, and from user point of view, where user should not need to run after the crash/exception number and read tons of logs to understand why Qemu crash or his guest crashed. As Adam wrote, other virtualization vendors already provide a fix for such a situation, so why re-invert the wheel ? Let's just follow them, and pause the VM, with displaying a warning message to the user. -- -Alexey Eremenko "Technologov"
[Qemu-devel] =?ISO-8859-2?Q?Re: What is the current support state for Sparc=09emulation??=
As promised, I tried today to launch Solaris 9 (CD version for Sparc, downloaded from http://www.sun.com/software/solaris/9/) on fresh CVS version checked out today. I built it using the manual on this page: http://maiux.com/qemu-windows-binaries-compile-howto but with sparc-softmmu switch in configure's options. The build went well and I tried to start the image the following way: qemu-system-sparc -L . -m 256 -hda hda.img -cdrom sol-9-905hw-install-ga-sparc.iso -boot d -no-acpi -g 800x600 -localltime (with different variations of three last switches). The result: [sparc] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... Unhandled Exception 0x0007 PC = 0xffd0a55c NPC = 0xffd09374 Stopping execution So this is my report, I hope it can be of some use. I'll try to boot sparc version of OpenSolaris soon and I'l let you know how it went. Regards, Grzegorz Galezowski
Re : [Qemu-devel] [PATCH] Implement ACPI specs 3.0, 4.7.2.5
Maybe nobody had a look on it, like these 3 others. I added their links on the qemu-devel archives. Implement ACPI specs 3.0, 4.7.2.5 Add support for VDI images ipc endianness and ipc_64 fixes Netlink broken if endianness is wrong Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com - Message d'origine De : Michael Hanselmann <[EMAIL PROTECTED]> À : qemu-devel@nongnu.org Envoyé le : Mercredi, 18 Juillet 2007, 23h32mn 11s Objet : Re: [Qemu-devel] [PATCH] Implement ACPI specs 3.0, 4.7.2.5 On Tue, Jun 26, 2007 at 10:32:23PM +0200, Michael Hanselmann wrote: > The patch below implements ACPI_ENABLE and ACPI_DISABLE as described in > section 4.7.2.5 of the ACPI 3.0 specs. Has this patch been ignored by accident or is there something wrong with it? Thanks, Michael -- http://hansmi.ch/
[Qemu-devel] qemu 0.9.0 win32 PXE boot can't work
I am using tftpd32 on xp as server. qemu 0.9.0-win32 can't boot from nic. I have tried use vmware .It is OK. so I download etherboot iso image from rom-o-matic use the pcnet32 nic card. this iso can boot vmware use PXE. but when I boot qemu-win32 use this iso.It tell me "No Ip Address". The qemu use -net nic,model=pcnet -net tap. I have used ethereal capture the packets on tap device. The DHCP offer packet is sent. who can help me?
Re: [Qemu-devel] qemu 0.9.0 win32 PXE boot can't work
??? wrote: I am using tftpd32 on xp as server. qemu 0.9.0-win32 can't boot from nic. I have tried use vmware .It is OK. so I download etherboot iso image from rom-o-matic use the pcnet32 nic card. this iso can boot vmware use PXE. but when I boot qemu-win32 use this iso.It tell me "No Ip Address". The qemu use -net nic,model=pcnet -net tap. I have used ethereal capture the packets on tap device. The DHCP offer packet is sent. who can help me? Can you try using the other nic types? I'm most interested in the results with the rtl8139 model. Regards, Anthony Liguori
Re: [Qemu-devel] Re: What is the current support state for Sparc emulation
OpenSolaris requires sparcv9, so it's unlikely that the OS will boot using qemu-system-sparc. However, if you can get the kernel to load and tell you that you need 64-bit, that's probably progress. jonathan On 7/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: As promised, I tried today to launch Solaris 9 (CD version for Sparc, downloaded from http://www.sun.com/software/solaris/9/) on fresh CVS version checked out today. I built it using the manual on this page: http://maiux.com/qemu-windows-binaries-compile-howto but with sparc-softmmu switch in configure's options. The build went well and I tried to start the image the following way: qemu-system-sparc -L . -m 256 -hda hda.img -cdrom sol-9-905hw-install-ga-sparc.iso -boot d -no-acpi -g 800x600 -localltime (with different variations of three last switches). The result: [sparc] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... Unhandled Exception 0x0007 PC = 0xffd0a55c NPC = 0xffd09374 Stopping execution So this is my report, I hope it can be of some use. I'll try to boot sparc version of OpenSolaris soon and I'l let you know how it went. Regards, Grzegorz Galezowski -- -- Jonathan Kalbfeld +1 323 620 6682
Re: [Qemu-devel] Re: What is the current support state for Sparc emulation
Am 19.07.2007 um 17:58 schrieb Jonathan Kalbfeld: if you can get the kernel to load and tell you that you need 64- bit, that's probably progress. When booting Solaris 10 some while ago it did tell me that without such exception. Will check if a regression was introduced. Andreas
Re: [Qemu-devel] What is the current support state for, Sparc emulation
OpenSolaris requires sparcv9, so it's unlikely that the OS will boot using qemu-system-sparc. However, if you can get the kernel to load and tell you that you need 64-bit, that's probably progress. Well, yes, you're right, OpenSolaris did not work, but it booted long enough to tell me that it does not support sun4m architecture. Then it shut down. Regards, Grzegorz Galezowski
Re: [Qemu-devel] =?ISO-8859-2?Q?Re: What is the current support state for Sparc=09emulation ??=
Am 19.07.2007 um 14:41 schrieb [EMAIL PROTECTED]: qemu-system-sparc -L . -m 256 -hda hda.img -cdrom sol-9-905hw- install-ga-sparc.iso -boot d -no-acpi -g 800x600 -localltime (with different variations of three last switches). The result: [sparc] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... Unhandled Exception 0x0007 PC = 0xffd0a55c NPC = 0xffd09374 Stopping execution With Solaris 10: qemu-system-sparc -boot d -cdrom sol-10-u3-ga-sparc-dvd.iso I get the following: [sparc] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable ELF image Not a Linux kernel image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point... This hardware platform is not supported by this release of Solaris. halt, power off power off failed Unfortunately this *is* a regression because earlier on power-off did work! (In Q 0.9.0 this worked so well that I wasn't able to read the error because it closed the window. ;-) Andreas
Re: [Qemu-devel] Re: What is the current support state for Sparc emulation
On 7/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Unhandled Exception 0x0007
PC = 0xffd0a55c NPC = 0xffd09374
Stopping execution
So this is my report, I hope it can be of some use. I'll try to boot sparc
version of OpenSolaris soon and I'l let you know how it went.
Thanks for the report. Exception 7 is unaligned access, support for
detection of unaligned accesses in QEMU was improved recently.
The exception happens inside OpenBIOS:
0xffd0a55c is in lstore (kernel/forth.c:649).
644
645 static void lstore(void)
646 {
647 const u32 *aaddr = (u32 *)cell2pointer(POP());
648 const u32 longval = POP();
649 write_long(aaddr, longval);
650 }
Maybe write_long should handle unaligned addresses?
[Qemu-devel] Booting Linux with Qemu-PPC prep
What is current condition of Qemu-PPC prep? I tried running debian sarge image from Freeoszoo but it doesnt boot(freezes when figuring out PTYs). 0.9.0 seems to boot this ok. Also there is a problem with Little endian mode since 0.9.0 boots OS/2 PPC edition over LE change and CVS version crashes with unsupported Opcode right after changing to LE. Tero
[Qemu-devel] Tracing function calls
Hi, is it possible to log some values from memory every time the instruction counter hits a certain value? Effectively, I want to achieve what would be called a tracepoint in GDB. Since tracepoints seem not to be implemented with QEMU, I would like to do a quick hack that just logs the variables that I would like to trace. Unfortunately, I'm having problems: I tried to add a printf() into the gen_intermediate_code_internal() function in target-i386/translate.c, right before the breakpoint handling code. The code logs the correct values, but it gets called by far not as often as it should be. If I connect GDB through the network interface and set a breakpoint at the position that I'd like to trace, the breakpoint (and suddenly, also my logging code) is hit far more often. How can I get my code getting called as often as it should be? What am I doing wrong? Thanks a lot! Simon
Re: [Qemu-devel] qemu 0.9.0 win32 PXE boot can't work
Can you try using the other nic types? I'm most interested in the results with the rtl8139 model. I have used rtl8139 the first time.Does not work. I think the etherboot is OK. because I can use it to boot from vmware. and the ethereal captured the DHCP offer packet on tap nic. How the tap-win32 and qemu deal with this packet? I can't trace it.
Re: [Qemu-devel] qemu 0.9.0 win32 PXE boot can't work
??? wrote: Can you try using the other nic types? I'm most interested in the results with the rtl8139 model. I have used rtl8139 the first time.Does not work. I think the etherboot is OK. because I can use it to boot from vmware. and the ethereal captured the DHCP offer packet on tap nic. How the tap-win32 and qemu deal with this packet? I can't trace it. You're using tap-win32? I have no idea how well tap-win32 works with PXE... That would be my suspicion. Regards, Anthony Liguori
