Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). Even the lowly ds10 has two hoses. I'll admit I hadn't considered engineering the second hose to be present but always appear empty. It's something to consider. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Yes, Linux is the primary goal. But I suspect that if I implemented enough of CALL_PAL CSERVE, you could boot Tru64, or at least one of the BSDs. BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. The palcode with milo was a subset of the tru64 palcode, I think. Looking at the arch reference manual and assuming that the calls take the same parameters, the only difference is that tru64 has urti - return from user mode trap and linux doesn't.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
On Thu, 2011-04-21 at 15:43 +0200, Tristan Gingold wrote: On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote: On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote: On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote: On 04/20/2011 08:46 AM, Tristan Gingold wrote: Right, but you could create an ev67 machine with a single PCI controller (or put all the devices on the same PCI controller). Even the lowly ds10 has two hoses. I'll admit I hadn't considered engineering the second hose to be present but always appear empty. It's something to consider. Ah, ok I understand. I fear that if you implement your own ISR, you will only be able to boot linux... which I suppose is your primary target. OTOH, it will be much faster than a native ISR. Yes, Linux is the primary goal. But I suspect that if I implemented enough of CALL_PAL CSERVE, you could boot Tru64, or at least one of the BSDs. BSD should be doable, but I doubt for Tru64. Do you have technical doc about the SRM ? IIRC, the SRM uses its own palcode and SRM specific pal calls. The palcode with milo was a subset of the tru64 palcode, I think. Looking at the arch reference manual and assuming that the calls take the same parameters, the only difference is that tru64 has urti - return from user mode trap and linux doesn't. Yes, Linux runs on Tru64 palcode. But the issue is booting the Tru64 kernel. Tristan. Ah, gotcha. It almost seems like the console could actually be implemented in qemu itself, rather than a guest side thing, as long as it looks like part III of the ARM :) It might simplify things quite a bit: the console callbacks look like they can be translated into qemu calls and the bootstrapping looks like its a read block zero of selected device + other blocks specified, setup hwrpb and start emulation. It looks like its standard across all OSes, with the possible exception of NT. *shrug* I'm just an innocent bystander, though.
Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2
I'd like to second Tristan in saying that I'm glad someone is working on alpha system emulation -- its long overdue! Brian On Wed, 2011-04-20 at 11:06 +0200, Tristan Gingold wrote: On Apr 19, 2011, at 5:04 PM, Richard Henderson wrote: Changes from v1 to v2: - Split patch 5 up into little pieces. These pieces were compile tested by applying patch 23 (Enable alpha-softmmu) out of sequence so that both softmmu and linux-user targets were built. But in the end I chickened out and re-ordered the enable patch to last. - The TB-FLAGS patch is more comprehensive. In doing the split I noticed that we were doing funny things with AMASK that really ought to have belonged in the TB in the first place. - The patch for unassigned addresses is more comprehensive. I had previously failed to do the if-deffing dance in the generic part of QEMU. - The PALcode source is added as a submodule. Richard, it looks like I miss the v1. Anyway, some random comments: * thank you for working on that! * sx164 is ev56 based, isn't it ? It would be nice if cpu version specific code is clearly marked. In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to ev5. Don't know about ev7. It would be nice if we could easily support both ev5 and ev6. * Yes, executive and supervisor are used only by VMS (well AFAIK). I'd like to support it. Did you try to also support the windows mmu mode ? * Again, thank you for working on that. Tristan.
[Qemu-devel] Questions about chardev (and ps/2 mouse)
I'm trying to disable the ps/2 mouse in favor of the serial mouse
provided by -chardev msmouse since the ps/2 mouse has had lots of
problems with older OSes (OpenStep, OS/2, Win 3.1, etc). I've got a
couple of questions:
1) If I change a VMState something by appending a field (i.e.
unplugged), do I have to update version_id? How do the
minimum_version_id{,_old} fields fit in?
2) I've had to hardcode the unplugged value in ps2_mouse_reset since the
call is pretty deep in the call stack, 8042-pckbd-ps2. Ideally, I'd
like to set (*PS2MouseState)-unplugged from qemu_chr_open_msmouse() so
that if the serial mouse is set up the ps/2 mouse would be disabled.
3) When I enable the msmouse (via -chardev msmouse,id=mouse) qemu
segfaults. I've traced it back to the CharDriverSTate for msmouse not
having a valid handler_opaque (it is null). How would I connect that to
the serial port (any of them, but ideally the 2nd one)
Thanks for any hints!
Brian
Re: [Qemu-devel] Questions about chardev (and ps/2 mouse)
On Tue, 2011-04-05 at 14:55 -0400, Brian Wheeler wrote:
I'm trying to disable the ps/2 mouse in favor of the serial mouse
provided by -chardev msmouse since the ps/2 mouse has had lots of
problems with older OSes (OpenStep, OS/2, Win 3.1, etc). I've got a
couple of questions:
1) If I change a VMState something by appending a field (i.e.
unplugged), do I have to update version_id? How do the
minimum_version_id{,_old} fields fit in?
2) I've had to hardcode the unplugged value in ps2_mouse_reset since the
call is pretty deep in the call stack, 8042-pckbd-ps2. Ideally, I'd
like to set (*PS2MouseState)-unplugged from qemu_chr_open_msmouse() so
that if the serial mouse is set up the ps/2 mouse would be disabled.
3) When I enable the msmouse (via -chardev msmouse,id=mouse) qemu
segfaults. I've traced it back to the CharDriverSTate for msmouse not
having a valid handler_opaque (it is null). How would I connect that to
the serial port (any of them, but ideally the 2nd one)
Ignore the last question. I realized I had to use:
-chardev msmouse,id=msmouse -device isa-serial,chardev=msmouse
to connect them :)
Thanks for any hints!
Brian
Re: [Qemu-devel] Help Debugging AIX boot on qemu-system-ppc (it reads bootfile.exe now)
Out of curiosity, what command line did you use for this? On Sat, 2011-04-02 at 20:09 -0700, Kenneth Salerno wrote: Hi, I have been using QEMU for a few years and periodically tested AIX V6.1 with qemu-system-ppc and read the various threads in the mailing list knowing not to expect it to work just yet. However, with OpenBIOS v1.0 I was surprised to find how far it gets now. Please see below and I would appreciate any advice on how to debug further: = OpenBIOS 1.0 [Jan 30 2011 08:46] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 2047M UUID: 17202d0a-45f8-4159-a8e1-78b866f50aa7 CPU type PowerPC,750 Welcome to OpenBIOS v1.0 built on Jan 30 2011 08:46 Trying cd:,\\:tbxi... Trying cd:,\ppc\bootinfo.txt... --- Welcome to AIX. boot image timestamp: 00:39 35/2D The current time and date: 23:00:50 04/02/2011 processor count: 1; memory size: 2047MB; kernel size: 2293829 boot device: cd:\ppc\chrp\bootfile.exe qemu info cpus * CPU #0: nip=0xfff0fcdc thread_id=2527 info registers NIP fff0fcec LR fff0fcc4 CTR fff11558 XER 2000 MSR 3032 HID0 HF 2000 idx 1 TB 1542797983 DECR 2752169338 GPR00 7fb9f0d0 7fcf7790 7fba29e4 GPR04 fffb403c 00044200 fff02464 00044200 GPR08 7fba29e4 000c 0820 GPR12 88ac fff305f5 fff30dac GPR16 fff2f14e 0400 fffb36c4 fffb3ec4 GPR20 30ec fff2ef4a fff2ef38 fff2eeb8 GPR24 fff2ef40 fffb3628 00044204 fff8 GPR28 0036 fffb fffb 7fb9f0d8 CR 4884 [ G L - - - - L G ] RES FPR00 FPR04 FPR08 FPR12 FPR16 FPR20 FPR24 FPR28 FPSCR SRR0 42c0 SRR1 3032 SDR1 7fd0 x/20i $pc-10 0xfff0fcd2: fnmadd. f31,f24,f4,f18 0xfff0fcd6: .long 0xfff84800 0xfff0fcda: .long 0x87d23 0xfff0fcde: bla 0xff788120 0xfff0fce2: .long 0x2f89 0xfff0fce6: .long 0x419e 0xfff0fcea: .long 0x148149 0xfff0fcee: .long 0x4817f 0xfff0fcf2: .long 0xfffc7f8a 0xfff0fcf6: rlmir0,r2,r8,6,14 0xfff0fcfa: fnmadd. f31,f4,f4,f18 0xfff0fcfe: .long 0xfff89003 0xfff0fd02: .long 0x3961 0xfff0fd06: .long 0x104801 0xfff0fd0a: ori r24,r11,37921 0xfff0fd0e: .long 0xffe07c08 0xfff0fd12: .long 0x2a6bfa1 0xfff0fd16: .long 0x147c7e 0xfff0fd1a: .long 0x1b799001 0xfff0fd1e: .long 0x247c9d last entry from out_asm: OUT: [size=256] 0x4157ae90: mov0x100(%r14),%ebp 0x4157ae97: mov0x4(%r14),%ebx 0x4157ae9b: lea-0x10(%rbx),%r12d 0x4157ae9f: mov%ebp,(%r14) 0x4157aea2: mov$0x20,%ebp 0x4157aea7: mov%ebp,0x260(%r14) 0x4157aeae: mov%r12d,%esi 0x4157aeb1: mov%r12d,%edi 0x4157aeb4: shr$0x7,%esi 0x4157aeb7: and$0xf003,%edi 0x4157aebd: and$0x1fe0,%esi 0x4157aec3: lea0x228c(%r14,%rsi,1),%rsi 0x4157aecb: cmp(%rsi),%edi 0x4157aecd: mov%r12d,%edi 0x4157aed0: jne0x4157aede 0x4157aed2: add0xc(%rsi),%rdi 0x4157aed6: mov%ebx,%esi 0x4157aed8: bswap %esi 0x4157aeda: mov%esi,(%rdi) 0x4157aedc: jmp0x4157aeea 0x4157aede: mov%ebx,%esi 0x4157aee0: mov$0x1,%edx 0x4157aee5: callq 0x57f0f5 0x4157aeea: lea0x14(%r12),%ebp 0x4157aeef: mov(%r14),%ebx 0x4157aef2: mov%r12d,0x4(%r14) 0x4157aef6: mov%ebp,%esi 0x4157aef8: mov%ebp,%edi 0x4157aefa: shr$0x7,%esi 0x4157aefd: and$0xf003,%edi 0x4157af03: and$0x1fe0,%esi 0x4157af09: lea0x228c(%r14,%rsi,1),%rsi 0x4157af11: cmp(%rsi),%edi 0x4157af13: mov%ebp,%edi 0x4157af15: jne0x4157af23 0x4157af17: add0xc(%rsi),%rdi 0x4157af1b: mov%ebx,%esi 0x4157af1d: bswap %esi 0x4157af1f: mov%esi,(%rdi) 0x4157af21: jmp0x4157af2f 0x4157af23: mov%ebx,%esi 0x4157af25: mov$0x1,%edx 0x4157af2a: callq 0x57f0f5 0x4157af2f: mov0xc(%r14),%ebp 0x4157af33: lea0x18(%rbp),%ebx 0x4157af36: mov%ebx,%esi 0x4157af38:
Re: [Qemu-devel] Help Debugging AIX boot on qemu-system-ppc (it reads bootfile.exe now)
Booting AIX 5.2 gives me --- Welcome to AIX. boot image timestamp: 70:80 15/C0 The current time and date: 20:40:45 04/04/2011 number of processors: 1size of memory: 2047Mb boot device: cd:\ppc\chrp\bootfile.exe Validation failed: the /rtas device node does not exist. EXIT So at least for earlier versions of AIX there are still missing firmware bits. Brian On Mon, 2011-04-04 at 13:28 -0700, Kenneth Salerno wrote: --- On Mon, 04 Apr 2011 08:59:37 -0400, Brian Wheeler wrote: Out of curiosity, what command line did you use for this? ./qemu/ppc-softmmu/qemu-system-ppc \ -net none \ -m 2047 \ -nographic \ -bios ./qemu/pc-bios/openbios-ppc \ -hda aix.img \ -cdrom ibmvios.iso \ -boot d \ -rtc base=localtime,clock=host \ -uuid xx... -monitor tcp:127.0.0.1:9979,server,nowait \ -serial tcp:127.0.0.1:9980,server,nowait \ -d in_asm,out_asm,op,op_opt
[Qemu-devel] [PATCH v5] PING: Fix ATA SMART and CHECK POWER MODE
This patch fixes two things:
1) CHECK POWER MODE
The error return value wasn't always zero, so it would show up as
offline. Error is now explicitly set to zero.
2) SMART
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output. The data has been fixed up and raw value support
was added. Tools like skdump and palimpsest work as expected.
v5 changes: rebase
v4 changes: incorporate changes from Ryan Harper
v3 changes: don't reformat code I didn't change
v2 changes: use single structure instead of one for thresholds and one
for data.
Signed-off-by: bdwhe...@indiana.edu
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 9c91a49..1ffca56 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
#include hw/ide/internal.h
-static const int smart_attributes[][5] = {
-/* id, flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were based on a Seagate ST3500418AS but have been modified
+ to make more sense in QEMU */
+static const int smart_attributes[][12] = {
+/* id, flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190, 0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
};
/* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_CHECKPOWERMODE1:
case WIN_CHECKPOWERMODE2:
+s-error = 0;
s-nsector = 0xff; /* device active or idle */
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+ s-io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n511; n++) /* checksum */
s-io_buffer[511] += s-io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
+ if (smart_attributes[n][0] == 0) {
break;
- s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][1];
- s-io_buffer[2+3+(n*12)] = smart_attributes[n][2];
- s-io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+ }
+ int i;
+ for(i = 0; i 11; i++) {
+ s-io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+ }
}
s-io_buffer[362] = 0x02 | (s-smart_autosave?0x80:0x00);
if (s-smart_selftest_count == 0) {
[Qemu-devel] [PATCH v5] Fix ATA SMART and CHECK POWER MODE
This patch fixes two things:
1) CHECK POWER MODE
The error return value wasn't always zero, so it would show up as
offline. Error is now explicitly set to zero.
2) SMART
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output. The data has been fixed up and raw value support
was added. Tools like skdump and palimpsest work as expected.
v5 changes: rebase
v4 changes: incorporate changes from Ryan Harper
v3 changes: don't reformat code I didn't change
v2 changes: use single structure instead of one for thresholds and one
for data.
Signed-off-by: bdwhe...@indiana.edu
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 9c91a49..1ffca56 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
#include hw/ide/internal.h
-static const int smart_attributes[][5] = {
-/* id, flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were based on a Seagate ST3500418AS but have been modified
+ to make more sense in QEMU */
+static const int smart_attributes[][12] = {
+/* id, flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190, 0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
};
/* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_CHECKPOWERMODE1:
case WIN_CHECKPOWERMODE2:
+s-error = 0;
s-nsector = 0xff; /* device active or idle */
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+ s-io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n511; n++) /* checksum */
s-io_buffer[511] += s-io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
+ if (smart_attributes[n][0] == 0) {
break;
- s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][1];
- s-io_buffer[2+3+(n*12)] = smart_attributes[n][2];
- s-io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+ }
+ int i;
+ for(i = 0; i 11; i++) {
+ s-io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+ }
}
s-io_buffer[362] = 0x02 | (s-smart_autosave?0x80:0x00);
if (s-smart_selftest_count == 0) {
Re: [Qemu-devel] [PATCH v3] Fix ATA SMART and CHECK POWER MODE
On Wed, 2011-02-09 at 17:22 -0600, Ryan Harper wrote:
* Brian Wheeler bdwhe...@indiana.edu [2011-02-09 16:13]:
This patch fixes two things:
1) CHECK POWER MODE
The error return value wasn't always zero, so it would show up as
offline. Error is now explicitly set to zero.
2) SMART
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output. The data has been fixed up and raw value support
was added. Tools like skdump and palimpsest work as expected.
v3 changes: don't reformat code I didn't change
v2 changes: use single structure instead of one for thresholds and one
for data.
Signed-off-by: bdwhe...@indiana.edu
diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..b0b0b35 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
#include hw/ide/internal.h
-static const int smart_attributes[][5] = {
-/* id, flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were taking from a running system, specifically a
+ Seagate ST3500418AS */
These values ought to have meaning for your hardware, but won't for either the
virtual disk, nor the underlying storage that the virtual disk is
running on. Since we're not attempting to pass any of that info, nor
keep it in-sync, it probably doesn't matter that much that we're just
copying device specific data. I'm open to discussion on how much we
care about the attribute values[1].
1.
https://secure.wikimedia.org/wikipedia/en/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
The main reason for this patch was to make sure the disk tools and
smartd on linux were happy and returned reasonable values. At some
point I may add on the ability to trigger a smart failure (by jumping
the sectors remapped or something) but for now its read only and not
really meaningful.
+static const int smart_attributes[][12] = {
+/* id, flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d, 0x00, 0x00,
0x06},
probably fine, but this is vendor hardware specific. I can't think of a
better number other than 0.
I've set it to zero.
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x61, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00},
default is probably fine as well, though it's dependent upon the
hardware as well. Could be zero as well.
I've set it to 16ms so skdump returns something other than 'n/a'
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00,
0x14},
depends on hardware and power mgmt, any count is probably fine.
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x24},
Probably should be zero.
When dumping it via skdump or smartctl out it reads as 0 sectors
remapped (as indicated by the raw value). The value looks like its a
countdown of sectors remaining, so setting it to the 'worst' value is
equivalent to no sectors remapped.
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a, 0x00, 0x00, 0x00, 0x00,
0x00},
Zero.
I'm going to set it to 1 (hour) so skdump returns something other than
'n/a'
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00},
Zero
I've set it to zero.
+/* airflow-temperature-celsius */
+{ 190, 0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22, 0x00, 0x00,
0x32},
Something resonably ambient 20-30C, current value is probably fine.
it reads at 31.0C. I've set the value (and worst)so it matches the raw
value. (100C - 31C = 69C (0x45)). I've also adjusted the raw value so
it shows the Min/Max is 31C
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00}
};
/* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_CHECKPOWERMODE1:
case WIN_CHECKPOWERMODE2:
+s-error = 0;
s-nsector = 0xff; /* device active or idle */
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+ s-io_buffer[2+1+(n*12)] = smart_attributes[n][11
[Qemu-devel] [PATCH v4] Fix ATA SMART and CHECK POWER MODE
This patch fixes two things:
1) CHECK POWER MODE
The error return value wasn't always zero, so it would show up as
offline. Error is now explicitly set to zero.
2) SMART
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output. The data has been fixed up and raw value support
was added. Tools like skdump and palimpsest work as expected.
v4 changes: incorporate changes from Ryan Harper
v3 changes: don't reformat code I didn't change
v2 changes: use single structure instead of one for thresholds and one
for data.
Signed-off-by: bdwhe...@indiana.edu
diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..c806f31 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
#include hw/ide/internal.h
-static const int smart_attributes[][5] = {
-/* id, flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were based on a Seagate ST3500418AS but have been modified
+ to make more sense in QEMU */
+static const int smart_attributes[][12] = {
+/* id, flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x64, 0x64, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x64, 0x64, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190, 0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
};
/* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_CHECKPOWERMODE1:
case WIN_CHECKPOWERMODE2:
+s-error = 0;
s-nsector = 0xff; /* device active or idle */
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+ s-io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n511; n++) /* checksum */
s-io_buffer[511] += s-io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
+ if (smart_attributes[n][0] == 0) {
break;
- s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][1];
- s-io_buffer[2+3+(n*12)] = smart_attributes[n][2];
- s-io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+ }
+ int i;
+ for(i = 0; i 11; i++) {
+ s-io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+ }
}
s-io_buffer[362] = 0x02 | (s-smart_autosave?0x80:0x00);
if (s-smart_selftest_count == 0) {
[Qemu-devel] [PATCH v2] Fix ATA SMART and CHECK POWER MODE
This patch fixes two things:
1) CHECK POWER MODE
The error return value wasn't always zero, so it would show up as
offline. Error is now explicitly set to zero.
2) SMART
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output. The data has been fixed up and raw value support was
added. Tools like skdump and palimpsest work as expected.
Changes from v1:
* combined the thresholds and attributes into a single structure.
Signed-of-by: Brian Wheeler bdwhe...@indiana.edu
diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..3a9793b 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,15 +34,29 @@
#include hw/ide/internal.h
-static const int smart_attributes[][5] = {
-/* id, flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were taking from a running system. */
+static const int smart_attributes[][12] = {
+/* id, flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x61, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190, 0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
};
+
+
/* XXX: DVDs that could fit on a CD will be reported as a CD */
static inline int media_present(IDEState *s)
{
@@ -1843,6 +1857,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_CHECKPOWERMODE1:
case WIN_CHECKPOWERMODE2:
+s-error = 0;
s-nsector = 0xff; /* device active or idle */
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2068,24 +2083,24 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
case SMART_ATTR_AUTOSAVE:
switch (s-sector) {
case 0x00:
- s-smart_autosave = 0;
- break;
+ s-smart_autosave = 0;
+ break;
case 0xf1:
- s-smart_autosave = 1;
- break;
+ s-smart_autosave = 1;
+ break;
default:
- goto abort_cmd;
+ goto abort_cmd;
}
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
break;
case SMART_STATUS:
if (!s-smart_errors) {
- s-hcyl = 0xc2;
- s-lcyl = 0x4f;
+ s-hcyl = 0xc2;
+ s-lcyl = 0x4f;
} else {
- s-hcyl = 0x2c;
- s-lcyl = 0xf4;
+ s-hcyl = 0x2c;
+ s-lcyl = 0xf4;
}
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2094,13 +2109,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
+ if (smart_attributes[n][0] == 0)
break;
- s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+ s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
+ s-io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n511; n++) /* checksum */
- s-io_buffer[511] += s-io_buffer[n];
+ s-io_buffer[511] += s-io_buffer[n];
s-io_buffer[511] = 0x100 - s-io_buffer[511];
s-status = READY_STAT | SEEK_STAT;
ide_transfer_start(s, s-io_buffer, 0x200, ide_transfer_stop);
@@ -2110,21 +2125,22 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0
[Qemu-devel] [PATCH v3] Fix ATA SMART and CHECK POWER MODE
This patch fixes two things:
1) CHECK POWER MODE
The error return value wasn't always zero, so it would show up as
offline. Error is now explicitly set to zero.
2) SMART
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output. The data has been fixed up and raw value support
was added. Tools like skdump and palimpsest work as expected.
v3 changes: don't reformat code I didn't change
v2 changes: use single structure instead of one for thresholds and one
for data.
Signed-off-by: bdwhe...@indiana.edu
diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..b0b0b35 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,13 +34,26 @@
#include hw/ide/internal.h
-static const int smart_attributes[][5] = {
-/* id, flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were taking from a running system, specifically a
+ Seagate ST3500418AS */
+static const int smart_attributes[][12] = {
+/* id, flags, hflags, val, wrst, raw (6 bytes), threshold */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d, 0x00, 0x00, 0x06},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x61, 0x61, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+/* airflow-temperature-celsius */
+{ 190, 0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22, 0x00, 0x00, 0x32},
+/* end of list */
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
};
/* XXX: DVDs that could fit on a CD will be reported as a CD */
@@ -1843,6 +1856,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_CHECKPOWERMODE1:
case WIN_CHECKPOWERMODE2:
+s-error = 0;
s-nsector = 0xff; /* device active or idle */
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2097,7 +2111,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (smart_attributes[n][0] == 0)
break;
s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+ s-io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
for (n=0; n511; n++) /* checksum */
s-io_buffer[511] += s-io_buffer[n];
@@ -2110,12 +2124,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
+ if (smart_attributes[n][0] == 0) {
break;
- s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][1];
- s-io_buffer[2+3+(n*12)] = smart_attributes[n][2];
- s-io_buffer[2+4+(n*12)] = smart_attributes[n][3];
+ }
+ int i;
+ for(i = 0; i 11; i++) {
+ s-io_buffer[2+i+(n*12)] = smart_attributes[n][i];
+ }
}
s-io_buffer[362] = 0x02 | (s-smart_autosave?0x80:0x00);
if (s-smart_selftest_count == 0) {
[Qemu-devel] [PATCH] Fix ATA SMART and CHECK POWER MODE
This patch fixes two things:
1) CHECK POWER MODE
The error return value wasn't always zero, so it would show up as
offline. Error is now explicitly set to zero.
2) SMART
The smart values that were returned were invalid and tools like skdump
would not recognize that the smart data was actually valid and would
dump weird output. The data has been fixed up and raw value support was
added. Tools like skdump and palimpsest work as expected.
Signed-of-by: Brian Wheeler bdwhe...@indiana.edu
---
diff --git a/hw/ide/core.c b/hw/ide/core.c
index dd63664..4d4ccfa 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -34,15 +34,37 @@
#include hw/ide/internal.h
-static const int smart_attributes[][5] = {
-/* id, flags, val, wrst, thrsh */
-{ 0x01, 0x03, 0x64, 0x64, 0x06}, /* raw read */
-{ 0x03, 0x03, 0x64, 0x64, 0x46}, /* spin up */
-{ 0x04, 0x02, 0x64, 0x64, 0x14}, /* start stop count */
-{ 0x05, 0x03, 0x64, 0x64, 0x36}, /* remapped sectors */
-{ 0x00, 0x00, 0x00, 0x00, 0x00}
+/* These values were taking from a running system. */
+static const int smart_attributes[][12] = {
+/* id, flags, hflags, val, wrst, raw (up to 6 bytes) */
+/* raw read error rate*/
+{ 0x01, 0x03, 0x00, 0x74, 0x63, 0x31, 0x6d, 0x3f, 0x0d},
+/* spin up */
+{ 0x03, 0x03, 0x00, 0x61, 0x61},
+/* start stop count */
+{ 0x04, 0x02, 0x00, 0x64, 0x64, 0x64},
+/* remapped sectors */
+{ 0x05, 0x03, 0x00, 0x64, 0x64},
+/* power on hours */
+{ 0x09, 0x03, 0x00, 0x61, 0x61, 0x68, 0x0a},
+/* power cycle count */
+{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x32},
+/* airflow-temperature-celsius */
+{ 190, 0x03, 0x00, 0x64, 0x64, 0x1f, 0x00, 0x16, 0x22},
+{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
};
+static const int smart_thresholds[][2] = {
+{ 0x01, 0x06},
+{ 0x03, 0x00},
+{ 0x04, 0x14},
+{ 0x05, 0x24},
+{ 0x09, 0x00},
+{ 190, 0x32},
+{ 0x00, 0x00}
+};
+
+
/* XXX: DVDs that could fit on a CD will be reported as a CD */
static inline int media_present(IDEState *s)
{
@@ -1843,6 +1865,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_CHECKPOWERMODE1:
case WIN_CHECKPOWERMODE2:
+s-error = 0;
s-nsector = 0xff; /* device active or idle */
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2068,24 +2091,24 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
case SMART_ATTR_AUTOSAVE:
switch (s-sector) {
case 0x00:
- s-smart_autosave = 0;
- break;
+ s-smart_autosave = 0;
+ break;
case 0xf1:
- s-smart_autosave = 1;
- break;
+ s-smart_autosave = 1;
+ break;
default:
- goto abort_cmd;
+ goto abort_cmd;
}
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
break;
case SMART_STATUS:
if (!s-smart_errors) {
- s-hcyl = 0xc2;
- s-lcyl = 0x4f;
+ s-hcyl = 0xc2;
+ s-lcyl = 0x4f;
} else {
- s-hcyl = 0x2c;
- s-lcyl = 0xf4;
+ s-hcyl = 0x2c;
+ s-lcyl = 0xf4;
}
s-status = READY_STAT | SEEK_STAT;
ide_set_irq(s-bus);
@@ -2094,13 +2117,13 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
+ if (smart_attributes[n][0] == 0)
break;
- s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12)] = smart_attributes[n][4];
+ s-io_buffer[2+0+(n*12)] = smart_thresholds[n][0];
+ s-io_buffer[2+1+(n*12)] = smart_thresholds[n][1];
}
for (n=0; n511; n++) /* checksum */
- s-io_buffer[511] += s-io_buffer[n];
+ s-io_buffer[511] += s-io_buffer[n];
s-io_buffer[511] = 0x100 - s-io_buffer[511];
s-status = READY_STAT | SEEK_STAT;
ide_transfer_start(s, s-io_buffer, 0x200, ide_transfer_stop);
@@ -2110,21 +2133,22 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
+ if (smart_attributes[n][0] == 0)
break;
- s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
- s-io_buffer[2+1+(n*12
Re: [Qemu-devel] PS2 Mouse/Kbd do not work with qemu-0.13.0
On Tue, 2010-11-16 at 13:52 -0800, Adhyas Avasthi wrote: I have issues with both PS2 Mouse and Keyboard working out of the box with virgin qemu-0.13.0 code base. The host is Ubuntu 10.04 x86_64 and I am making a 64-bit build for x86_64-softmmu Sometimes (for some guest environments, e.g. Ubuntu 10.10. x86_64) the mouse does not work within the guest, while the keyboard does. In some other environments, the keyboard does not work as well. Has anyone else witnessed the same issue? Are there any known workarounds I can use to move ahead? USB keyboard/mouse do work, but I cannot use that workaround for the work I am doing as I don't have USB drivers in my BIOS yet. I will appreciate any responses that can help me get unblocked. I don't have any helpful advice, but the PS/2 Mouse has been broken for ages for OpenStep and some other older OSes. I tried to track it down but I never could quite pinpoint what was going on. Brian Thanks, Adhyas Two types have compatible type if their types are the same. — ANSI C Standard, 3.1.2.6.
[Qemu-devel] Can't compile ISA device...
I'm trying to write a busmouse driver and I can't get it to compile. It
seems like there's a header issue of some sort that I can't work out.
Of course, if someone has a working busmouse driver for qemu, that would
be great: OpenStep won't work with the ps/2 emulation and even after
pounding on it for a few days I can't seem to narrow down why it OS
stops paying attention to it. The consensus in 2006 was fix the ps/2
emulation but apparently nobody has been able to figure out how its
broken and this seems like a reasonable solution.
My code is based on the pc98 busmouse driver by TAKEDA, toshiya and the
busmouse patches that floated around the list over the last few years.
Anyway, it seems like a typedef is wrong. Did I miss something obvious?
Thanks
Brian
I'm getting:
==
In file included from /home/bdwheele/Projects/qemu/hw/pc.h:7,
from /home/bdwheele/Projects/qemu/hw/busmouse.c:30:
/home/bdwheele/Projects/qemu/hw/isa.h:33: error: expected ‘=’, ‘,’, ‘;’, ‘asm’
or ‘__attribute__’ before ‘isa_mem_base’
/home/bdwheele/Projects/qemu/hw/isa.h:35: error: expected ‘)’ before ‘base’
In file included from /home/bdwheele/Projects/qemu/hw/pc.h:8,
from /home/bdwheele/Projects/qemu/hw/busmouse.c:30:
/home/bdwheele/Projects/qemu/hw/fdc.h:11: error: expected declaration
specifiers or ‘...’ before ‘target_phys_addr_t’
/home/bdwheele/Projects/qemu/hw/fdc.h:12: error: expected declaration
specifiers or ‘...’ before ‘target_phys_addr_t’
In file included from /home/bdwheele/Projects/qemu/hw/busmouse.c:30:
/home/bdwheele/Projects/qemu/hw/pc.h:15: error: expected ‘)’ before ‘base’
/home/bdwheele/Projects/qemu/hw/pc.h:26: error: expected ‘)’ before ‘base’
/home/bdwheele/Projects/qemu/hw/pc.h:78: error: expected declaration specifiers
or ‘...’ before ‘target_phys_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:78: error: expected declaration specifiers
or ‘...’ before ‘ram_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:79: error: expected declaration specifiers
or ‘...’ before ‘target_phys_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:91: error: expected ‘)’ before ‘ram_size’
/home/bdwheele/Projects/qemu/hw/pc.h:106: error: expected ‘)’ before ‘ram_size’
/home/bdwheele/Projects/qemu/hw/pc.h:141: error: expected declaration
specifiers or ‘...’ before ‘ram_addr_t’
/home/bdwheele/Projects/qemu/hw/pc.h:159: error: expected ‘)’ before ‘vram_base’
=
I've added it to Makefile.objs:
=
diff --git a/Makefile.objs b/Makefile.objs
index 816194a..908c21f 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -81,7 +81,7 @@ common-obj-y += bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o
bt-hci.o bt-hid.o u
common-obj-y += bt-hci-csr.o
common-obj-y += buffered_file.o migration.o migration-tcp.o qemu-sockets.o
common-obj-y += qemu-char.o savevm.o #aio.o
-common-obj-y += msmouse.o ps2.o
+common-obj-y += msmouse.o ps2.o busmouse.o
common-obj-y += qdev.o qdev-properties.o
common-obj-y += block-migration.o
common-obj-y += pflib.o
==
and here's the source:
=
#include hw.h
#include pc.h
#include isa.h
#include qdev.h
#include console.h
struct mouse_t {
int button;
int dx, dy;
uint8_t index;
qemu_irq irq;
int irq_pending;
};
typedef struct mouse_isabus_t {
ISADevice busdev;
struct mouse_t state;
} mouse_isabus_t;
typedef struct mouse_t mouse_t;
/* mouse */
static void mouse_event_handler(void *opaque,
int dx, int dy, int dz, int buttons_state)
{
mouse_t *s = opaque;
s-button = buttons_state;
s-dx += dx;
s-dy += dy;
s-irq_pending = 1;
}
static void busmouse_update_irq(mouse_t *s)
{
if (s-irq_pending) {
qemu_set_irq(s-irq, 1);
} else {
qemu_set_irq(s-irq, 0);
}
}
/* pio */
static void busmouse_pio_write(void *opaque, uint32_t addr, uint32_t val)
{
mouse_t *s = opaque;
switch(addr) {
case 0: //data
break;
case 1: // signature
break;
case 2: // control
s-index = val;
break;
case 3: // config
break;
}
}
static uint32_t busmouse_pio_read(void *opaque, uint32_t addr)
{
mouse_t *s = opaque;
uint32_t val = 0;
static int interrupt_val = 0x01;
s-irq_pending = 0;
switch(addr) {
case 0: // data
s-irq_pending = 0;
val |= (s-button 1)? 0x80 : 0x00;
val |= (s-button 2)? 0x40 : 0x00;
val |= (s-button 4)? 0x20 : 0x00;
val |= ((s-index 0x40? s-dy : s-dx) (s-index 0x20? 4 : 0))
0x0f;
busmouse_update_irq(s);
break;
case 1: // signature
val = 0xa5;
busmouse_update_irq(s);
break;
case 2: // control
val = interrupt_val;
interrupt_val = (interrupt_val 1) 0xff;
if (interrupt_val == 0) interrupt_val = 1;
[Qemu-devel] weird mouse troubles in latest git
I'm trying to run openstep 2.4 on the latest git and the mouse hangs after a few seconds of running. I turned on debugging some debugging flags: ps2.c: DEBUG_MOUSE pckbd.c: DEBUG_KEYBOARD i8259.c: DEBUG_PIC I'm still not sure where the problem is, but here's what I've discovered: If I filter out all messages except ones with irq=12 I get this sequence (when using the sdl ui): * a bunch of set_irq level=1 followed immediately by a level=0 which is what I'd expect. * when the mouse hangs, it hangs with a level=1 * hitting ctrl-alt to release focus gives me a bunch of level=1/level=0 pairs along with a bunch of pic_interrupts for irq 12 When I use the vnc ui, I get 2 pairs of set_irq irq=12 level=1/0 followed by a pic: pic_interrupt: irq=12. When I move the mouse into the vnc window I get the set_irq level = 1 and the mouse is done. So, is the guest not picking up the interrupts correctly or is there some problem with the UI not sending mouse requests through if the guest hasn't handled them? There are mouse troubles with OS/2 4.0 as well which may be related (the button stops working but the mouse would still move. Its not terribly important, but I thought someone should know.
Re: [Qemu-devel] qemu alpha?
On Tue, 2007-10-23 at 00:38 +0200, J. Mayer wrote: On Mon, 2007-10-22 at 09:43 +0200, Oliver Falk wrote: On 10/21/2007 01:06 PM, J. Mayer wrote: On Sun, 2007-10-21 at 05:43 -0500, Rob Landley wrote: On Saturday 20 October 2007 3:56:12 am J. Mayer wrote: On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote: On Sunday 14 October 2007 5:14:27 am J. Mayer wrote: On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote: Hi list! Hi you ! Just wanted to know how far the progress on alpha target is? I would be happy if I have some 'virtual alpha' to test new isos. If I can help some way (I have a few alphas around). Let me know. I'm happy to see someone interresting in improving Alpha support, which is very alpha for now ! I'm interested in testing Alpha too, but I haven't seem a qemu-system-alpha show up yet. Alas, I have no hardware or specific expertise in this platform, I'm just trying to build and boot Linux kernels (and corresponding root filesystems) on as many emulated target platforms as I can. There are a lot of things missing for qemu-system-alpha to be available: - the PALCode emulation is far from being complete or even usable I have no idea what that is. The PALCode is mainly equivalent to the microcode of most CPU architectures. What is different to microcode is that is uses only regular Alpha instructions, just adding 4 instructions to access special hardware registers and access the memory with different priviledge levels. Another main idea is that everyone can write its own PALCode image and switch to it at run-time. Then, for example, the PALCode ABI is not the same one if you run Linux or Windows NT. The PALCode handles all complex operations. For example, the CPU provides only TLB and the MMU tables search is actually implemented in software, in the PALCode. This greatly simplifies the CPU design and allows a high level of flexibility. And if your OS need a specific ABI for example to handle CPU exception, you define your ABI, write the PALCode using Alpha insns and use it ! The Alpha CPU also provide an instruction to do PALCode calls from the OS or applications. There are 3 (4 ?) native PALCode ABIs documented in the Alpha CPUs specifications then those can be emulated at the host side in Qemu. It is in fact needed to emulate a subset of the PALCode even to run user-mode programs. Pretty good explained! Thanks! However, what do you need to make the alpha emulation work? Does ssh to an Alpha help you? I'm quite sure I can offer you access to some ev5 machine very soon and I might give access to some ds10 (ev67 machine). There's also some ds10 (ev6 'only') machine in Australia, that actually works as a builder for the AlphaCore project - but it's not mine and I would need to ask if I can give access to someone else... I actually do not have a lot of time to spend of Alpha emulation, that's why it would be great if some could test and compare the execution of simple programs (then later more complicated one) in order to find the most obvious emulation bugs, with the linux-user mode emulation. For this, an access to any Alpha machine could help a lot. For the full system emulation, a lot of work is to be done, mostly the PALCode emulation and putting together all elements of an actual hardware machine. Note that the PALCode emulation could be avoided if the emulator is able to run native PALCode image but I don't know if those images are easily available... A couple of notes/questions on Alpha emulators: * there is an open source alpha emulator, but it seems to have stalled. It is at: http://www.camicom.com/index.php?option=com_contenttask=blogcategoryid=8Itemid=14 * The palcode is downloadable in one form or another from the old digital site: ftp://ftp.digital.com/pub/digital/Alpha/firmware If the palcode could be emulated directly, it would make the emulation much faster, however during OS boot, most OSes will override the palcode settings. * full-system hardware All of the mid-to-late models used isa/pci, and usually used off-the-shelf hardware. I know the scsi controller that was supported by default was qlogic-based (isp1020), and many systems had bog-standard IDE controllers (cmd 646). Some of the video cards supported directly were generic VGA, matrox millenium, s3 trio, plus several proprietary ones. Ethernet tended to be Digital's 21142/21143 family. Is there a howto for creating new devices and plugging them into an existing system emulation? Since all of these devices are pc compatible, it seems like they could be written and debugged from the PC emulation and then just plugged into the alpha emulation when its ready. * does the alpha userspace emulation support dynamically linked binaries, or does it accept static only? I've never played with it on any architecture. Brian
Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images
On Thu, 2007-08-09 at 15:32 -0500, Anthony Liguori wrote: Avi Kivity wrote: Anthony Liguori wrote: If you're looking for a low-end solution, another possibility would be having a new file format which consisted of: #!/path/to/qemu [args ...] nl standard disk image And then make the appropriate changes to QEMU such that it can skip the first line in a disk image file. This has a few nice side effects. The disk image is directly executable and it makes it very clear to the user that they have to trust the disk image. The other nice thing is that it would work with file formats other than qcow2. Well, it would be nice to align the disk image to a sector boundary (or, better, a page boundary). But yes, a very good idea. That has the very nice side effect of allowing you to edit the command line with a text editor provided you don't cross the sector boundary. Filling with spaces would be pretty nice. Its a bad idea. Either have a line terminated file, or a pure binary file, but don't mix them. Besides firing up an editor to modify it being a royal pain, mystery breakages will occur when someone has their editor set to insert mode (which is the default) vs overwrite mode and doesn't notice those extra spaces moving beyond the 512-byte mark. Brian Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images
On Thu, 2007-08-09 at 23:16 +0300, Avi Kivity wrote: Anthony Liguori wrote: I think it is a bad idea from a security POV to automatically extract use command line args from a disk image like this without the admin explicitly requesting this capability. eg If I grabbed a demo disk image from a vendors' or community website I would certainly not trust whatever args may happen to be embedded in the disk image and thus do not want QEMU to be automatically running using them. I'd recommend having some command line flag to turn this capability on. For example a '--args PATH-TO-DISK' flag, qemu --args $HOME/fedora.qcow That's pretty nasty. How do you specify which disk this is then? I do agree with you that allowing arbitrary command line arguments in an image file is probably a bad idea. I think the general idea of being able to launch a single image is useful but I suspect this is not the right way to do it. What are some people thinking would want to be stored in the file? Most of the command line options are more host specific than guest specific I think. Maybe we can store a pseudo-config instead that only contains a subset of parameters (and therefore, wouldn't pose a security risk)? Memory size, -hdb and -cdrom, processor count, networking setup. The sort of things people push into ad-hoc scripts. I expect this to be the low-end solution; with high end management applications storing configuration options in a database. Why not just save the options to a file and have qemu parse it? That way all of the security issues are taken care of, and it can be cross platform (no need for a shell script and/or batch file) so it'd be portable. If the format was one flag per line (as if the command line got broken up in pairs) as in -hdb myfile.img being on one line and -fda boot.img on another line, then its easy to edit programically as well. All of my shell scripts to start qemu tend to look like this: qemu -hda disk0.img -net nic -net user -m 512 -localtime $* so I can pass one-time parameters as necessary (that's the $* at the end) by specifying args when I invoke the script. If qemu had a default configuration file it looked for, and then you could specify one-or-more configuration files to read in addition (later values overriding earlier ones), then it seems like it'd work out for most if not all situations. Brian
Re: [Qemu-devel] IBM makes AIX 6 beta available for download for everyone
On Wed, 2007-07-18 at 09:15 +0100, Natalia Portillo wrote: Hi, AIX was already tested in QEMU and is not that it does not understand the AIX boot format (it does!), just there is another problem that prevents OHW from working (some say there is a regression in the IDE controller code). http://www.claunia.com/qemu/ Regards Natalia Portillo AIX 4.3.3 starts to boot (well, further than 5.1 5.2 do) The serial console has: - Probe filesystem on unknown PREP partition 'PREP boot' (bootable) 5834080 Fix bootfile Partition is bootable (1) bd_set_boot_part: part 5834080 (0) 1 Boot partition: 5834080 582e400 582e400 0 ERROR: Found boot partition : 5834080 582e400 ERROR: Not a MACH-O file ERROR: Not an Apple CHRP boot file ! dest 10 entry 0230 = 100230 Load raw file into memory at 10 3307448 (003277b8) 0 () Boot: 3004 b8773200 00024149 5820234 Bootinfos at : 50 Now boot it... (0) stack: 5bfff80 malloc_base: 0 0x5800 0x0600 PREP boot... 100230 10 The graphic console has some messages (which I assume are the ones above) and then it goes blank. It may still be doing something, I'll just wait for a while and see. Both 5.1 and 5.2 complain about the return code from the ide controller ERROR: ATAPI READ12 : status 41 != 0x48 (ready | error ) != ( ready | drq) It looks like open hack'ware is pretty much stalled, so its hard telling what progress will be made futurewise. Brian El mié, 18-07-2007 a las 03:32 +0200, Martin escribió: IBM opened up a little bit and makes the beta of AIX 6 available to anyone. Maybe this is an opportunity to get AIX running on QEMU. At the moment QEMU does not yet understand the AIX cd boot format. I tried to boot it using the -kernel option b I tried to boot it in the following ways, but that doesn't work yet (as expected) qemu-system-ppc -m prep -cdrom cd.AIX_6_OpenBeta.0723C1.V1.ISO -boot d sudo mount -o loop cd.AIX_6_OpenBeta.0723C1.V1.ISO /mnt/loop qemu-system-ppc -M prep -kernel /mnt/loop/ppc/chrp/bootfile.exe The -kernel option is meant for linux kernels but I hoped it would take an AIX kernel too. You can download the AIX 6 beta from: http://www-03.ibm.com/servers/aix/6/beta.html (free registration required) Open beta now available The open beta for AIX® 6 is now available. Go to https://www14.software.ibm.com/iwm/web/cc/earlyprograms/ibm/aix6beta/ for more information and to download the beta code. Overview Openness, such as compliance with open standards, has always been an integral part of the AIX operating system (OS). The next release of AIX, Version 6.1, extends this openness to the product release process with the first ever AIX open beta. The open beta will allow a broad set of IBM clients to download and gain experience with AIX 6 before it becomes generally available. An open beta for the next AIX release differs from the traditional beta in three key areas: * Almost anyone who is interested will be able to download and install a pre-release version of AIX 6. By contrast, only a few clients would have the opportunity to test a new AIX release in a traditional beta. * Participants in the open beta will not receive traditional support from IBM. Instead, you access a Web forum to discuss questions and issues. * The only legal document required for participation in the open beta is a click to accept license agreement that clearly states all program conditions.
Re: [Qemu-devel] qemu-system-sparc question?
On Wed, 2006-10-11 at 19:32 +0200, Marco Matthies wrote: Blue Swirl wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. It could be unlike any existing hardware, for example with zero or thousands of registers. The problem would be making a compiler for the CPU, also porting some OS to it. Any GCC and Linux guru volunteers? CS research projects? How about MMIX? http://en.wikipedia.org/wiki/MMIX There is already a simulator/assembler here: http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html Marco It might not be a bad idea, especially since MMIX is well documented and fairly simple. However, since it doesn't have real devices (Just traps to do OS-like things), it'd probably be good to have a simple CPU with some simple devices so newcomers can copy it as a starting point for other projects. Brian ___ 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] AXP guest?
Has anyone looked at doing an Alpha guest? The instruction set seems fairly straightforward and the machine as a whole seems to be an alpha chip + pci, which shouldn't be all that different from the x86 machine setup, from a full system point of view. I've been looking through the qemu documentation and I'm not even sure where one would begin to add this. My C is pretty rusty, but I'd start giving it a shot if someone could give me some pointers on how to get started. At the very least I could contribute some grudge work writing op routines... [I'm curious to know if a qemu-axp on my athlon 64 3200+ would outpace my alpha 1000a/233! I suspect it would give it a run for its money.] Brian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [ot?] Vista Networking
Has anyone gotten this to work? I'm probably missing something obvious. Here's the command line I'm using (on linux with a CVS from today): qemu -hda disk0.img -net nic,model=rtl8139 -net user -m 512 -soundhw sb16 Vista is installed and I manually set the IP to 10.0.2.15 and the gateway to 10.0.2.2. I set the DNS to 10.0.2.3. I can't get any response from the DNS or anything beyond the firewall. Did I mess up something or is there a bug in user-space networking? Thanks! Brian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista
On Fri, 2006-06-09 at 10:20 +0200, René Korthaus wrote: Edit: I think it has something to do with the harddisk image. Error is STOP: d144 Unknown Hard Error. Somebody having an idea? I set the windows 2000 install fix flag (-win2k-hack) and it installed for me. Upon install, it didn't find the ethernet card, but it did run. Brian Am 09.06.2006 um 09:55 schrieb René Korthaus: With CVS from May 28 Vista install boots. But now i got another problem: During extraction of files install stops with an unknown hardware error. Is there a size limit for -cdrom files? The install DVD is about 3,3GB. Am 09.06.2006 um 02:11 schrieb Nigel J. Terry: Christian MICHON wrote: don't you need special acpi features inside qemu/bios, otherwise the iso would not boot ? On 6/8/06, Hetz Ben Hamo [EMAIL PROTECTED] wrote: Hi people, Microsoft has released a free download ISO of Windows Vista Beta 2. This Beta will expire at July 1st 2007. Anyone who want to download it (3.3 GB for 32 bit version, 4.4 GB for 64 bit version) can go to: http://www.microsoft.com/windowsvista/getready/preview.mspx It might be fun to test it :) Thanks, Hetz -- Visit my blog (hebrew) for things that (sometimes) matter: http://wp.dad-answers.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Yes you do need ACPI to get the .iso to boot. I tried it and it failed. You also need 512M of ram and the ability to accept that your PC will BSOD often :-) I'll stick with FC5 Nigel ___ 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 mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Windows Vista
On Fri, 2006-06-09 at 14:25 +0200, René Korthaus wrote: Am 09.06.2006 um 14:08 schrieb Brian Wheeler: On Fri, 2006-06-09 at 10:20 +0200, René Korthaus wrote: Edit: I think it has something to do with the harddisk image. Error is STOP: d144 Unknown Hard Error. Somebody having an idea? I set the windows 2000 install fix flag (-win2k-hack) and it installed for me. Upon install, it didn't find the ethernet card, but it did run. I passed that error by simply upgrading to latest CVS from today. But now I am at the Install is being finished - step and it takes a lot of time. Just trying with -win2k-hack enabled... Let's see. How long did the overall install take for you? I was updated CVS as well yesterday, so that may have done it on its own. The install took ages. So far I'm not terribly impressed being a Linux guy, but then, it is a beta in an emulator and networking isn't working. Brian Brian Am 09.06.2006 um 09:55 schrieb René Korthaus: With CVS from May 28 Vista install boots. But now i got another problem: During extraction of files install stops with an unknown hardware error. Is there a size limit for -cdrom files? The install DVD is about 3,3GB. Am 09.06.2006 um 02:11 schrieb Nigel J. Terry: Christian MICHON wrote: don't you need special acpi features inside qemu/bios, otherwise the iso would not boot ? On 6/8/06, Hetz Ben Hamo [EMAIL PROTECTED] wrote: Hi people, Microsoft has released a free download ISO of Windows Vista Beta 2. This Beta will expire at July 1st 2007. Anyone who want to download it (3.3 GB for 32 bit version, 4.4 GB for 64 bit version) can go to: http://www.microsoft.com/windowsvista/getready/preview.mspx It might be fun to test it :) Thanks, Hetz -- Visit my blog (hebrew) for things that (sometimes) matter: http://wp.dad-answers.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Yes you do need ACPI to get the .iso to boot. I tried it and it failed. You also need 512M of ram and the ability to accept that your PC will BSOD often :-) I'll stick with FC5 Nigel ___ 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 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 mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Printing bogus values in ne2000_asic_ioport_read()/ ne2000_receive()
On Sun, 2006-02-26 at 10:01 -0800, Umamaheswararao Karyampudi wrote:
Hi,
I am using QEMU in one of my research projects. I
landed in a problem where I see bogus numbers being
printed when I printed the packet/each word that is
received from ne2000.
In ne2000_receive(), I copied the packet received to a
static char [] and printed the packet using
static void print_packet(char *s, int len)
{
int i,j;
for (i=0;ilen;i++) {
if (i%20 == 0)
printf(\n);
printf(%02x , s[i]);
}
printf(\n);
}
And some bytes it prints as flast byte
instead of just the last byte.
For eg:
52 54 00 12 34 56 00 4f 0a 46 05 08 00 45 00
00 ff80 00 00
40 00 40 01 ffbc 2b ffc0 ffa8 fffe
fffe ffc0 ffa8 ff
Just guessing, but is it a signed/unsigned thing? All of the ffxx
values are above 0x7f...
Brian
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Open Hack'Ware question
On Wed, 2005-07-20 at 22:49 +0200, J. Mayer wrote: On Thu, 2005-07-14 at 10:32 -0500, Brian Wheeler wrote: All of the websites that are referred to in the docs and source are missing. Is there another place to get it? I'm tinkering with the idea to try to boot aix on qemu. There was a broken link. I just fixed it. Thanks. But, for your information, AIX boot has been tested and does not boot. The reason is it use a specific boot file format (with AIXM magic at start) and I did not spent any time to discover where is stored the code offset (but I know what the offset value is). As reported in OHW README, I did test AIX 4.3.3 5.1. Would booting the bootfile.exe from the CD directly via -kernel be a future option to work around the AIXM magic? The exe looks to be a standard ELF file for powerpc. It might be interesting to see what that file actually does (i.e. if its the kernel or a boot loader) Brian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Open Hack'Ware question
After checking strings it looks like bootfile.exe is a bootloader that pounds openfirmware rather extensively. Hmm. Is there a way to load a real ibm firmware into qemu? Since I have access to machines it might be an interesting experiment. Brian On Thu, 2005-07-21 at 09:30 -0500, Brian Wheeler wrote: On Wed, 2005-07-20 at 22:49 +0200, J. Mayer wrote: On Thu, 2005-07-14 at 10:32 -0500, Brian Wheeler wrote: All of the websites that are referred to in the docs and source are missing. Is there another place to get it? I'm tinkering with the idea to try to boot aix on qemu. There was a broken link. I just fixed it. Thanks. But, for your information, AIX boot has been tested and does not boot. The reason is it use a specific boot file format (with AIXM magic at start) and I did not spent any time to discover where is stored the code offset (but I know what the offset value is). As reported in OHW README, I did test AIX 4.3.3 5.1. Would booting the bootfile.exe from the CD directly via -kernel be a future option to work around the AIXM magic? The exe looks to be a standard ELF file for powerpc. It might be interesting to see what that file actually does (i.e. if its the kernel or a boot loader) Brian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Open Hack'Ware question
That's why I was hoping to find the source so I could tinker with it a bit and see if I could make any progress :) It looks like the test was against AIX 5.2. I've got 4.1 - 5.2 so I can test a bunch of different versions to see if there's a difference in behavior. Brian On Thu, 2005-07-14 at 23:41 +0100, Natalia Portillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AIX won't work, it is tested, check http://www.claunia.com/qemu/, and if you have a correct CD with the correct PReP partition OHW will simply try to boot it with -M prep and -boot d options. Regards, Natalia Portillo El 14/07/2005, a las 17:33, Brian Wheeler escribió: On Thu, 2005-07-14 at 17:52 +0200, Karel Gardas wrote: On Thu, 14 Jul 2005, Brian Wheeler wrote: All of the websites that are referred to in the docs and source are missing. Is there another place to get it? I'm tinkering with the idea to try to boot aix on qemu. The same here! But for RTEMS and Mesquite cPCI (MCP750) BSP. Any idea how to get such code booting? IMHO the best would be to use Qemu's -kernel option, but I don't know what are precise requirement for it and for image booting in this scenario. I think for AIX it is a matter of seeing what the PREP specification says and seeing what OHW does -- and then trying it on something like AIX 4.3.3 and seeing where it fails. For your application, I'm not sure what you'd need to do...but the kernel option does sound like the best bet. Brian Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC1uowSOHwOb87puQRAjziAKCSUVJx1KJdBwPWptYFjXWvz0wQDACfWmks j7uut0iMmgMr5aw7agpzZcE= =Kdp/ -END PGP SIGNATURE- ___ 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] Open Hack'Ware question
All of the websites that are referred to in the docs and source are missing. Is there another place to get it? I'm tinkering with the idea to try to boot aix on qemu. Thanks! Brian Wheeler [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
