[Qemu-devel] [PATCH] Fix a race condition and non-leaf imagesgrowing in VMDK chains.
Hi guys, Somebody look at this patch? I'll appreciate comments? Regards, Igor Lvovsky -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Igor Lvovsky Sent: Sunday, May 20, 2007 2:40 PM To: Thiemo Seufer Cc: qemu-devel@nongnu.org Subject: RE: [Qemu-devel] [PATCH] Fix a race condition and non-leaf imagesgrowing in VMDK chains. Hi Thiemo, Thank you for comments. You probably right about the "child" -> "is_parent" renaming, But the "parent_open" variable (I know, the name is not the best. you can rename it) is not a duplicate of the "is_parent". The only one reason for existence of "parent_open" it's set/reset the "is_parent". I think we can't use the "is_parent" instead, because we need to know at every moment if it's a "parent" or "leaf" image. I mean, if we'll use "is_parent" instead of "parent_open": + s->is_parent = 1; + if (bdrv_open(s->hd->backing_hd, parent_img_name, BDRV_O_RDONLY) < 0) goto failure; + s->is_parent = 0; We'll reset it after the file opening. It's mean, later during the "get_cluster_offset()" we'll not be able to know if it's a "parent" or "leaf" image. So, I attach a new patch with you comments. Regards, Igor Lvovsky -Original Message- From: Thiemo Seufer [mailto:[EMAIL PROTECTED] Sent: Sunday, May 20, 2007 12:42 AM To: Igor Lvovsky Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH] Fix a race condition and non-leaf images growing in VMDK chains. Thiemo Seufer wrote: > Igor Lvovsky wrote: > > > > Hi, > > The bug was in my last patch. > > This is a new one. > > I'll very appreciate any comments. > > Appended is a variant which gets rid of the confusing "child" variable > which means "is_parent", and the duplicate of it (parent_open). > > There was also an uninitialized variable "tmp" which was stored as > offset in m_data. > > I quite possibly missed some bits which broke the patch, please test if > it still works for you. Next try, this time with the latest version of the patch. Thiemo block-vmdk-patch.diff Description: block-vmdk-patch.diff
Re: [Qemu-devel] qemu on mips patch
2007/6/3, Thiemo Seufer <[EMAIL PROTECTED]>:
... I think the current
CVS version does the right thing without relying on on an equivalent
to your op_mips.c tool.
...
On my computer, I do not think so.
in op.o, -fno-PIC -mno-abicalls
004eb0d4 :
...
4eb104: afa50010 sw a1,16(sp)
4eb108: 1463 bnez v1,4eb118
4eb10c: nop
4eb110: 0c140e12 jal 503848
4eb114: nop
4eb118: 8fa30010 lw v1,16(sp)
4eb11c: 2021 move a0,zero
in helper.o, PIC and abicalls
00503848 :
503848: 3c1c000c lui gp,0xc
50384c: 279c0858 addiu gp,gp,2136
503850: 0399e021 addu gp,gp,t9
503854: 8f998db8 lw t9,-29256(gp)
503858: 2821 move a1,zero
50385c: 3021 move a2,zero
503860: 0328 jr t9
503864: 3821 move a3,zero
When op_divb_AL_T0() calls raise_exception(), $t9 is not address of
raise_exception().
in op.h
case INDEX_op_divb_AL_T0: {
...
/* R_MIPS_26 RELOC, offset 0x10d0, name raise_exception */
*(uint32_t *)(gen_code_ptr + 0x3c) = (0xc00 & ~0x3f) |
((0xc00 + (((long)(&raise_exception) - (*(uint32_t *)(gen_code_ptr +
0x3c))) >> 2))& 0x3f);
jal(R_MIPS_26) is a PC-region branch, not PC-relative.
Re: [Qemu-devel] How to debug QEMU with GDB??
Hi... Probably, it doesn't help you much, but have you check Qemu user forum (http://qemu-forum.ipi.fi/)? There, in pending patch section, you can find a patch that makes Qemu more gdb-friendly. Another point is, are you sure you are putting breakpoint in .text segment? Also, it is possible that some memory address range is write protected (via mprotect) so you can't write there. Jasson Wessel is the man I know who works closely with qemu-gdb related stuffs... try to ask him. regards, Mulyadi
[Qemu-devel] qemu + Windows NT (2000, XP, etc)
QEMU developers:
I have been using QEMU off and on for some time. Recently I had a need
for a Windows XP VM to be joined to a domain. I discovered a rather
annoying issue in the form of the key-grab: NT-based Microsoft
operating systems make heavy use of Ctrl-Alt-Delete, i.e. to sign on,
open the task manager, change your password, lock your screen, etc.
I've started using the tablet USB device specifically because I don't
like this grabby behaviour, and it started becoming a real problem for
everyday use.
I wrote a patch that adds a command-line switch to qemu (-alt-grab).
It allows you to remap the keygrab combination to Ctrl-Alt-Shift when
using SDL-based displays. It has only been tested on Linux / AMD64.
Please reply to me off-list, as I am not subscribed. Comments are
appreciated, and I would like to see this make it into the mainline
QEMU branch.
-
Patches below are against kvm-26.
The included patches were written by Michael Mohr.
They are licensed to you under the GNU GPL version 2
or (at your discretion) any later version.
Michael Mohr can be contacted at [EMAIL PROTECTED]
June 06, 2007
diff -urN qemu-org/sdl.c qemu/sdl.c
--- qemu-org/sdl.c 2007-06-06 23:58:13.0 -0700
+++ qemu/sdl.c 2007-06-06 23:57:41.0 -0700
@@ -223,7 +223,11 @@
strcat(buf, " [Stopped]");
}
if (gui_grab) {
-strcat(buf, " - Press Ctrl-Alt to exit grab");
+if (!alt_grab) {
+ strcat(buf, " - Press Ctrl-Alt to exit grab");
+ } else {
+ strcat(buf, " - Press Ctrl-Alt-Shift to exit grab");
+ }
}
SDL_WM_SetCaption(buf, "QEMU");
}
@@ -331,8 +335,13 @@
case SDL_KEYDOWN:
case SDL_KEYUP:
if (ev->type == SDL_KEYDOWN) {
-mod_state = (SDL_GetModState() & gui_grab_code) ==
+ if (!alt_grab) {
+ mod_state = (SDL_GetModState() & gui_grab_code) ==
gui_grab_code;
+ } else {
+ mod_state = (SDL_GetModState() & (gui_grab_code |
KMOD_LSHIFT)) ==
+ (gui_grab_code | KMOD_LSHIFT);
+ }
gui_key_modifier_pressed = mod_state;
if (gui_key_modifier_pressed) {
int keycode;
@@ -392,7 +401,11 @@
}
}
} else if (ev->type == SDL_KEYUP) {
-mod_state = (ev->key.keysym.mod & gui_grab_code);
+ if (!alt_grab) {
+ mod_state = (ev->key.keysym.mod & gui_grab_code);
+ } else {
+ mod_state = (ev->key.keysym.mod & (gui_grab_code |
KMOD_LSHIFT));
+ }
if (!mod_state) {
if (gui_key_modifier_pressed) {
gui_key_modifier_pressed = 0;
diff -urN qemu-org/vl.c qemu/vl.c
--- qemu-org/vl.c 2007-06-06 23:58:13.0 -0700
+++ qemu/vl.c 2007-06-06 23:57:41.0 -0700
@@ -182,6 +182,7 @@
int autostart = 1;
int time_drift_fix = 0;
const char *cpu_vendor_string;
+int alt_grab = 0;
/***/
/* x86 ISA bus support */
@@ -6341,6 +6342,7 @@
"-boot [a|c|d|n] boot on floppy (a), hard disk (c), CD-ROM
(d), or network (n)\n" "-snapshot write to temporary files
instead of disk image files\n" #ifdef CONFIG_SDL
+ "-alt-grab use Ctrl-Alt-Shift to grab mouse (instead
of Ctrl-Alt)\n" "-no-quitdisable SDL window close capability\n"
#endif
#ifdef TARGET_I386
@@ -6541,6 +6543,7 @@
QEMU_OPTION_no_rtc,
#endif
QEMU_OPTION_cpu_vendor,
+QEMU_OPTION_alt_grab
};
typedef struct QEMUOption {
@@ -6638,6 +6641,7 @@
{ "no-rtc", 0, QEMU_OPTION_no_rtc },
#endif
{ "cpu-vendor", HAS_ARG, QEMU_OPTION_cpu_vendor },
+{ "alt-grab", 0, QEMU_OPTION_alt_grab },
{ NULL },
};
@@ -7364,6 +7368,9 @@
case QEMU_OPTION_cpu_vendor:
cpu_vendor_string = optarg;
break;
+ case QEMU_OPTION_alt_grab:
+ alt_grab = 1;
+ break;
}
}
}
diff -urN qemu-org/vl.h qemu/vl.h
--- qemu-org/vl.h 2007-06-06 23:58:13.0 -0700
+++ qemu/vl.h 2007-06-06 23:57:41.0 -0700
@@ -159,6 +159,7 @@
extern int kqemu_allowed;
extern int kvm_allowed;
extern int win2k_install_hack;
+extern int alt_grab;
extern int usb_enabled;
extern int smp_cpus;
extern int no_quit;
Re: [Qemu-devel] Sparc32 network problems
> Using Q 0.9.0d88 on a Mac OS X i386 host I was able to boot into
> debian-40r0-sparc-netinst.iso with qemu-system-sparc, have the NIC
> configured through DHCP and install to about 73% where I
repeatedly
> got a kernel panic "Aiee".
I should add that when I tried the interrupt checking patch proposed
on this list (http://lists.gnu.org/archive/html/qemu-devel/2007-03/
msg00153.html) then instead of the kernel panic I got a qemu crash.
Would this happen to be the same bug as in this report:
http://marc.info/?l=qemu-devel&m=117768736212439&w=2
Yes, a similar one, except that the kernel panic did somehow
mention the code I quoted above.
When using debian-40r0-sparc-DVD-1.iso on PPC, configuring network
manually and selecting the desktop option it crashed at 69%
(python-2.4?) with the following message:
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->contect = 007b
tsk->{mm,active_mm}->pgd = fc054400
Kernel panic - not syncing: Aiee, killing interrupt handler!
It does not say "Illegal Instruction" and it did recognize and
repartition the harddrive.
Andreas
RE: [Qemu-devel] qemu + Windows NT (2000, XP, etc)
>QEMU developers: > >I have been using QEMU off and on for some time. Recently I had a need >for a Windows XP VM to be joined to a domain. I discovered a rather >annoying issue in the form of the key-grab: NT-based Microsoft >operating systems make heavy use of Ctrl-Alt-Delete, i.e. to sign on, >open the task manager, change your password, lock your screen, etc. >I've started using the tablet USB device specifically because I don't >like this grabby behaviour, and it started becoming a real problem for >everyday use. > >I wrote a patch that adds a command-line switch to qemu (-alt-grab). >It allows you to remap the keygrab combination to Ctrl-Alt-Shift when >using SDL-based displays. It has only been tested on Linux / AMD64. > >Please reply to me off-list, as I am not subscribed. Comments are >appreciated, and I would like to see this make it into the mainline >QEMU branch. It bothered us too, it fits us like a globe. Hope that it will be joined to qemu's mainline. We'll anyway add it to kvm.
[Qemu-devel] qemu/hw mips_malta.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 12:17:52 Modified files: hw : mips_malta.c Log message: Fix firmware word endianness for Malta. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.36&r2=1.37
[Qemu-devel] qemu/hw gt64xxx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 12:30:16 Modified files: hw : gt64xxx.c Log message: Fix PCI irq mapping on Malta. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.8&r2=1.9
[Qemu-devel] qemu/hw mips_pica61.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 12:32:29 Modified files: hw : mips_pica61.c Log message: Fix comment. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemu&r1=1.5&r2=1.6
[Qemu-devel] [PATCH] Fix formatting of parallel.c
Hi, This patch fixes the formatting of the file hw/parallel.c, where tabulations have been replaced by 8 spaces. No code change. Hervé parallel_formatting.diff Description: Binary data
[Qemu-devel] qemu/hw gt64xxx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 17:00:37 Modified files: hw : gt64xxx.c Log message: Implement some more Gallileo registers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.9&r2=1.10
[Qemu-devel] qemu/hw gt64xxx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 17:31:35 Modified files: hw : gt64xxx.c Log message: PCI device saving for GT64xxx. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.10&r2=1.11
[Qemu-devel] qemu/hw gt64xxx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 17:38:50 Modified files: hw : gt64xxx.c Log message: Fix some Malta PCI config bits. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.11&r2=1.12
[Qemu-devel] qemu/hw gt64xxx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 18:09:57 Modified files: hw : gt64xxx.c Log message: Initialize more GT64xxx registers on reset. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.12&r2=1.13
Re: [Qemu-devel] qemu/hw gt64xxx.c
This patch breaks the ethernet device for big endian malta on x86 (little endian malta works). Tested with NFS root and Debian 2.6.20 kernel like this: mips-softmmu/qemu-system-mips --kernel /tftpboot/malta/boot/vmlinux \ --append "debug root=/dev/nfs rw ip=malta::dhcp" \ -M malta --net nic --net user >From boot messages, I expect no PCI device will work with big endian: LE: Found :00:0a:0 [8086/7110] 000601 00 BE: Found :00:0a:0 [1071/8680] 00 00 Device and vendor IDs are in wrong order. Stefan Thiemo Seufer schrieb: > CVSROOT: /sources/qemu > Module name: qemu > Changes by: Thiemo Seufer 07/06/07 17:00:37 > > Modified files: > hw : gt64xxx.c > > Log message: > Implement some more Gallileo registers. > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.9&r2=1.10
[Qemu-devel] qemu/hw gt64xxx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 19:45:44 Modified files: hw : gt64xxx.c Log message: Unbreak PCI config register, noticed by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/gt64xxx.c?cvsroot=qemu&r1=1.13&r2=1.14
Re: [Qemu-devel] Sparc32 network problems
On 6/6/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
I also made some local changes to tcx.c today to avoid having a blue-
footed penguin on Intel. There's a TODO in that file saying the RGB
functions should be merged with vga.c (where they are being patched
by Q) - should I provide a qemu patch doing this and fixing the issue
for both? Or is this for some reason restricted to Q?
I made a patch to fix both vga and tcx while also unifying the pixel
operations, does it fix the blue foot disease on PPC?
Index: qemu/hw/pixel_ops.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu/hw/pixel_ops.h 2007-06-07 19:45:57.0 +
@@ -0,0 +1,49 @@
+static inline unsigned int rgb_to_pixel8(unsigned int r, unsigned int g,
+ unsigned int b)
+{
+#ifdef WORDS_BIGENDIAN
+return ((b >> 5) << 5) | ((g >> 5) << 2) | (r >> 6);
+#else
+return ((r >> 5) << 5) | ((g >> 5) << 2) | (b >> 6);
+#endif
+}
+
+static inline unsigned int rgb_to_pixel15(unsigned int r, unsigned int g,
+ unsigned int b)
+{
+#ifdef WORDS_BIGENDIAN
+return ((b >> 3) << 10) | ((g >> 3) << 5) | (r >> 3);
+#else
+return ((r >> 3) << 10) | ((g >> 3) << 5) | (b >> 3);
+#endif
+}
+
+static inline unsigned int rgb_to_pixel16(unsigned int r, unsigned int g,
+ unsigned int b)
+{
+#ifdef WORDS_BIGENDIAN
+return ((b >> 3) << 11) | ((g >> 2) << 5) | (r >> 3);
+#else
+return ((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3);
+#endif
+}
+
+static inline unsigned int rgb_to_pixel32(unsigned int r, unsigned int g,
+ unsigned int b)
+{
+#ifdef WORDS_BIGENDIAN
+return (b << 16) | (g << 8) | r;
+#else
+return (r << 16) | (g << 8) | b;
+#endif
+}
+
+static inline unsigned int rgb_to_pixel32bgr(unsigned int r, unsigned int g,
+ unsigned int b)
+{
+#ifdef WORDS_BIGENDIAN
+return (r << 16) | (g << 8) | b;
+#else
+return (b << 16) | (g << 8) | r;
+#endif
+}
Index: qemu/hw/tcx.c
===
--- qemu.orig/hw/tcx.c 2007-06-07 19:35:27.0 +
+++ qemu/hw/tcx.c 2007-06-07 19:38:28.0 +
@@ -22,6 +22,7 @@
* THE SOFTWARE.
*/
#include "vl.h"
+#include "pixel_ops.h"
#define MAXX 1024
#define MAXY 768
@@ -47,27 +48,6 @@
static void tcx_invalidate_display(void *opaque);
static void tcx24_invalidate_display(void *opaque);
-/* XXX: unify with vga draw line functions */
-static inline unsigned int rgb_to_pixel8(unsigned int r, unsigned int g, unsigned b)
-{
-return ((r >> 5) << 5) | ((g >> 5) << 2) | (b >> 6);
-}
-
-static inline unsigned int rgb_to_pixel15(unsigned int r, unsigned int g, unsigned b)
-{
-return ((r >> 3) << 10) | ((g >> 3) << 5) | (b >> 3);
-}
-
-static inline unsigned int rgb_to_pixel16(unsigned int r, unsigned int g, unsigned b)
-{
-return ((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3);
-}
-
-static inline unsigned int rgb_to_pixel32(unsigned int r, unsigned int g, unsigned b)
-{
-return (r << 16) | (g << 8) | b;
-}
-
static void update_palette_entries(TCXState *s, int start, int end)
{
int i;
Index: qemu/hw/vga.c
===
--- qemu.orig/hw/vga.c 2007-06-07 19:36:38.0 +
+++ qemu/hw/vga.c 2007-06-07 19:41:42.0 +
@@ -23,6 +23,7 @@
*/
#include "vl.h"
#include "vga_int.h"
+#include "pixel_ops.h"
//#define DEBUG_VGA
//#define DEBUG_VGA_MEM
@@ -812,31 +813,6 @@
typedef void vga_draw_line_func(VGAState *s1, uint8_t *d,
const uint8_t *s, int width);
-static inline unsigned int rgb_to_pixel8(unsigned int r, unsigned int g, unsigned b)
-{
-return ((r >> 5) << 5) | ((g >> 5) << 2) | (b >> 6);
-}
-
-static inline unsigned int rgb_to_pixel15(unsigned int r, unsigned int g, unsigned b)
-{
-return ((r >> 3) << 10) | ((g >> 3) << 5) | (b >> 3);
-}
-
-static inline unsigned int rgb_to_pixel16(unsigned int r, unsigned int g, unsigned b)
-{
-return ((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3);
-}
-
-static inline unsigned int rgb_to_pixel32(unsigned int r, unsigned int g, unsigned b)
-{
-return (r << 16) | (g << 8) | b;
-}
-
-static inline unsigned int rgb_to_pixel32bgr(unsigned int r, unsigned int g, unsigned b)
-{
-return (b << 16) | (g << 8) | r;
-}
-
#define DEPTH 8
#include "vga_template.h"
Index: qemu/Makefile.target
===
--- qemu.orig/Makefile.target 2007-06-07 19:47:46.0 +
+++ qemu/Makefile.target 2007-06-07 19:50:35.0 +
@@ -592,6 +592,10 @@
signal.o: signal.c
$(CC) $(HELPER_CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -c -o $@ $<
+vga.o: pixel_ops.h
+
+tcx.o: pixel_ops.h
+
ifeq ($(TARGET_BASE_ARCH), i386)
op.o: op.c opreg_t
Re: [Qemu-devel] Sparc32 network problems
Blue Swirl wrote: > On 6/6/07, Andreas Färber <[EMAIL PROTECTED]> wrote: > >I also made some local changes to tcx.c today to avoid having a blue- > >footed penguin on Intel. There's a TODO in that file saying the RGB > >functions should be merged with vga.c (where they are being patched > >by Q) - should I provide a qemu patch doing this and fixing the issue > >for both? Or is this for some reason restricted to Q? > > I made a patch to fix both vga and tcx while also unifying the pixel > operations, does it fix the blue foot disease on PPC? Hm, _with_ this patch I get (on PPC/Linux, emulating LE MIPS): - a blue-footed penguin when the cirrus FB is started - blue instead of red colour in console output - A general blue-to-red inversion for X11 in 16bit mode. Note that the colours for the last one were already not quite right (e.g. grey became a pale blue), but with your patch it looks even weirder. Thiemo
[Qemu-devel] qemu/hw parallel.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/07 21:07:11 Modified files: hw : parallel.c Log message: Fix code formatting, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/parallel.c?cvsroot=qemu&r1=1.6&r2=1.7
[Qemu-devel] Linux 2.6.21 doesn't work with qemu-arm SCSI controller anymore.
In the 2.6.21 kernel the sym53c8xx_2 SCSI controller changed in a way that QEMU's virtual SCSI controller doesn't handle this properly: Here's what 2.6.20 does during boot: > Loading iSCSI transport class v2.0-724. > PCI: enabling device :00:0c.0 (0140 -> 0143) > sym0: <895a> rev 0x0 at pci :00:0c.0 irq 27 > sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking > sym0: SCSI BUS has been reset. > scsi0 : sym-2.2.3 > scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK0.9. PQ: 0 ANSI: > 3 target0:0:0: tagged command queuing enabled, command queue depth 16. > target0:0:0: Beginning Domain Validation > target0:0:0: Domain Validation skipping write tests > target0:0:0: Ending Domain Validation > scsi 0:0:2:0: CD-ROMQEMU QEMU CD-ROM 0.9. PQ: 0 ANSI: > 3 target0:0:2: tagged command queuing enabled, command queue depth 16. > target0:0:2: Beginning Domain Validation > target0:0:2: Domain Validation skipping write tests > target0:0:2: Ending Domain Validation > SCSI device sda: 524288 512-byte hdwr sectors (268 MB) > sda: Write Protect is off > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support > DPO or FUA SCSI device sda: 524288 512-byte hdwr sectors (268 MB) > sda: Write Protect is off > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support > DPO or FUA sda: unknown partition table > sd 0:0:0:0: Attached scsi disk sda > sr0: scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray > Uniform CD-ROM driver Revision: 3.20 > mice: PS/2 mouse device common for all mice > TCP cubic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > NET: Registered protocol family 15 > 802.1Q VLAN Support v1.8 Ben Greear <[EMAIL PROTECTED]> > All bugs added by David S. Miller <[EMAIL PROTECTED]> > VFS: Mounted root (ext2 filesystem). > Freeing init memory: 100K > sh-2.05b# And here's what 2.6.21 does: > Loading iSCSI transport class v2.0-724. > PCI: enabling device :00:0c.0 (0140 -> 0143) > sym0: <895a> rev 0x0 at pci :00:0c.0 irq 0 > sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking > sym0: SCSI BUS has been reset. > scsi0 : sym-2.2.3 > scsi 0:0:0:0: ABORT operation started. > scsi 0:0:0:0: ABORT operation timed-out. > scsi 0:0:0:0: DEVICE RESET operation started. > scsi 0:0:0:0: DEVICE RESET operation timed-out. > scsi 0:0:0:0: BUS RESET operation started. > scsi 0:0:0:0: BUS RESET operation timed-out. > scsi 0:0:0:0: HOST RESET operation started. > sym0: SCSI BUS has been reset. > scsi 0:0:0:0: HOST RESET operation timed-out. > scsi 0:0:0:0: scsi: Device offlined - not ready after error recovery > scsi 0:0:1:0: ABORT operation started. > scsi 0:0:1:0: ABORT operation timed-out. > scsi 0:0:1:0: DEVICE RESET operation started. > scsi 0:0:1:0: DEVICE RESET operation timed-out. > scsi 0:0:1:0: BUS RESET operation started. > scsi 0:0:1:0: BUS RESET operation timed-out. > scsi 0:0:1:0: HOST RESET operation started. > sym0: SCSI BUS has been reset. [ Skip lots of the same... ] > scsi 0:0:14:0: HOST RESET operation started. > sym0: SCSI BUS has been reset. > scsi 0:0:14:0: HOST RESET operation timed-out. > scsi 0:0:14:0: scsi: Device offlined - not ready after error recovery > scsi 0:0:15:0: ABORT operation started. > scsi 0:0:15:0: ABORT operation timed-out. > scsi 0:0:15:0: DEVICE RESET operation started. > scsi 0:0:15:0: DEVICE RESET operation timed-out. > scsi 0:0:15:0: BUS RESET operation started. > scsi 0:0:15:0: BUS RESET operation timed-out. > scsi 0:0:15:0: HOST RESET operation started. > sym0: SCSI BUS has been reset. > scsi 0:0:15:0: HOST RESET operation timed-out. > scsi 0:0:15:0: scsi: Device offlined - not ready after error recovery > mice: PS/2 mouse device common for all mice > TCP cubic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > NET: Registered protocol family 15 > 802.1Q VLAN Support v1.8 Ben Greear <[EMAIL PROTECTED]> > All bugs added by David S. Miller <[EMAIL PROTECTED]> > VFS: Cannot open root device "sda" or unknown-block(0,0) > Please append a correct "root=" boot option; here are the available > partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(0,0) Rebooting in 1 seconds.. I am _totally_ out of my depth trying to debug this. I continue to poke at it, but it was brought to my attention that the list doesn't know about it... Rob -- The Google cluster became self-aware at 2:14am EDT August 29, 2007...
Re: [Qemu-devel] Sparc32 network problems
Blue Swirl wrote: On 6/6/07, Andreas Färber <[EMAIL PROTECTED]> wrote: I also made some local changes to tcx.c today to avoid having a blue- footed penguin on Intel. There's a TODO in that file saying the RGB functions should be merged with vga.c (where they are being patched by Q) - should I provide a qemu patch doing this and fixing the issue for both? Or is this for some reason restricted to Q? I made a patch to fix both vga and tcx while also unifying the pixel operations, does it fix the blue foot disease on PPC? Hm, _with_ this patch I get (on PPC/Linux, emulating LE MIPS): - a blue-footed penguin when the cirrus FB is started - blue instead of red colour in console output - A general blue-to-red inversion for X11 in 16bit mode. Note that the colours for the last one were already not quite right (e.g. grey became a pale blue), but with your patch it looks even weirder. I haven't been able to test the new patch yet. Q's patch and my adaptation for tcx just reversed the order of the colors, just like BlueSwirl's patch except that they used #if __LITTLE_ENDIAN__ in place of #ifdef WORDS_BIGENDIAN, and this worked for both i386 and sparc32 guests on i386 host (but is not applied for ppc host). http://www.kju-app.org/proj/browser/trunk/patches/q_vga.c_02.diff Andreas
[Qemu-devel] qemu m68k-semi.c osdep.c osdep.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/06/07 23:09:47 Modified files: . : m68k-semi.c osdep.c osdep.h Log message: Windows build fixes. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/m68k-semi.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/osdep.c?cvsroot=qemu&r1=1.16&r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/osdep.h?cvsroot=qemu&r1=1.9&r2=1.10
[Qemu-devel] qemu/hw mcf_fec.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/06/07 23:24:57 Modified files: hw : mcf_fec.c Log message: Fix return type. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mcf_fec.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/06/08 01:57:57 Modified files: . : vl.c vl.h Log message: Don't refresh a graphical screen when it isn't displayed, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.304&r2=1.305 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.249&r2=1.250
