I got a new Haswell based system a few days ago. It has been running
fine without warnings but today I started a VirtualBox VM and got a MCE
soon afterwards. "MCA: Internal parity error" like everyone else. From
reading this bug and the vmware link in the first post it seems like
this problem occur
Did you implemented the support for stm32l in qemu?
Patch 06b12970174 ("virtio-net: fix network stall under load")
added double-check to test whether the available buffer size
can satisfy the request or not, in case the guest has added
some buffers to the avail ring simultaneously after the first
check.
It will be lucky if the available buffer size
Fixes: 06b12970174 ("virtio-net: fix network stall under load")
If guest has made some buffers available during double check,
but the total buffer size available is lower than @bufsize,
notify the guest with the latest available idx(event idx)
seen by the host.
---
hw/net/virtio-net.c | 1 +
1 fi
If guest has made some buffers available during double check,
but the total buffer size available is lower than @bufsize,
notify the guest with the latest available idx(event idx)
seen by the host.
Fixes: 06b12970174 ("virtio-net: fix network stall under load")
Signed-off-by: wencheng Yang
---
h
Public bug reported:
Running qemu with tracing (-D ~/qemu_trace -d trace:\*) will result in a
trace file with unprintable characters.
example: usb_port_attach bus 0, port 1, devspeed <90>l.U,
portspeed full+high
The problem is in hw/usb/bus.c usb_mask_to_str. If speedmask doesn't
match any of th
Yes. I was using a 4.20.x kernel. But i guess the bug can be closed
because the vm does not exist anymore and the new one does not show this
behaviour.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/18
Public bug reported:
Hello Devs.
Having problems getting VM to run with qemu 3.1.0.
2019-01-24 13:46:08.648+: starting up libvirt version: 4.10.0, qemu
version: 3.1.0, kernel: 4.14.94, hostname: one
LC_ALL=C
PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bi
** Description changed:
Hello Devs.
Having problems getting VM to run with qemu 3.1.0.
- 2019-01-24 13:46:08.648+: starting up libvirt version: 4.10.0, qemu
version: 3.1.0, kernel: 4.14.94, hostname: one.lordcritical.de
+ 2019-01-24 13:46:08.648+: starting up libvirt version: 4.
Hi,
I'm trying to emulate Rpi with QEMU.
I found
[url=https://www.raspberry-pi-geek.de/ausgaben/rpg/2014/04/raspberry-pi-emulieren/]this[/url]
arcticle in Raspberry Pi Geek documenting the steps including persistent
storage on host.
However when starting the emulation with command
qemu-system-arm
Hello!
Many thanks for your support.
I managed to get emulated RPi starting.
However there's one question I want to ask:
How can I accelerate the startup sequence?
I mean booting the emulated RPi takes more than 3 minutes.
Regards
Thomas
Am 06.10.20 um 11:58 schrieb Alex Bennée:
>
▒
0,52% qemu-system-arm qemu-system-arm [.]
qemu_set_irq
▒
However the absolute time is 3-4 minutes.
And I don't know where I should start optimization now.
Am 07.10.20 um 14:02 schrieb Alex Bennée:
>
,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -usb -vnc
0.0.0.0:80 -vga cirrus
Signed-off-by: Thomas Higdon
---
hw/scsi-disk.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 5d8bf53..71fe2a3 100644
--- a/hw/scsi-disk.c
+
On Mon, Jan 23, 2012 at 12:47:54PM -0500, Paolo Bonzini wrote:
> On 01/23/2012 06:15 PM, Thomas Higdon wrote:
> > This prevents the emulated SCSI device from trying to DMA more bytes to the
> > initiator than are expected. Without this, the SCRIPTS code in the emulated
>
On Tue, Jan 24, 2012 at 08:53:03AM -0500, Kevin Wolf wrote:
> Am 23.01.2012 18:15, schrieb Thomas Higdon:
> > This prevents the emulated SCSI device from trying to DMA more bytes to the
> > initiator than are expected. Without this, the SCRIPTS code in the emulated
> > LSI
Am Wed, 8 Feb 2012 21:48:40 +1100
schrieb David Gibson :
> On Wed, Feb 08, 2012 at 10:54:21AM +0400, malc wrote:
> > On Wed, 8 Feb 2012, David Gibson wrote:
> >
> > > From: Thomas Huth
> > >
> > > These instructions for loading and storing byte-swappe
Am Thu, 9 Feb 2012 11:26:09 +1100
schrieb David Gibson :
> On Wed, Feb 08, 2012 at 02:27:35PM +0100, Thomas Huth wrote:
> > Am Wed, 8 Feb 2012 21:48:40 +1100
> > schrieb David Gibson :
> >
> > > On Wed, Feb 08, 2012 at 10:54:21AM +0400, malc wrote:
> > > &
On Tue, 2012-10-23 at 12:33 +0200, Kevin Wolf wrote:
> Am 22.10.2012 13:09, schrieb n...@bytemark.co.uk:
> >
> > This is unlikely to come up now, but is a necessary prerequisite for
> > reconnection
> > behaviour.
> >
> > Signed-off-by: Nick
On Tue, 2012-10-23 at 16:02 +0100, Jamie Lokier wrote:
> Nicholas Thomas wrote:
> > On Tue, 2012-10-23 at 12:33 +0200, Kevin Wolf wrote:
> > > Am 22.10.2012 13:09, schrieb n...@bytemark.co.uk:
> > > >
> > > > This is unlikely to come u
On Wed, 2012-10-24 at 16:10 +0200, Paolo Bonzini wrote:
> Il 24/10/2012 16:03, Paolo Bonzini ha scritto:
> > Il 24/10/2012 14:16, Nicholas Thomas ha scritto:
> >>
> >> I've also just noticed that flush & discard don't take the send_mutex
> >> befor
Public bug reported:
Here the steps to reproduce:
1. qemu-img create -f qcow2 test.qcow2 100M
2. qemu-system-ppc -m 1024 -hda test.qcow2
3. change to the console via Ctrl-Alt-2 and save a snapshot: "savevm test"
4. quit
5. start again and go to the console
6. load the snapshot via "loadvm test"
7
en yes, that's even better.
At least SLOF already contains the code to initialize the PAPR-style
NVRAM partitions from scratch. So as soon as SLOF can work with this
new NVRAM devices, it should be able to initialize the required layout.
Thomas
this possible at all? Can anyone suggest
alternative ways of tracking which pages of pc.ram are accessed?
Thanks for your help,
Thomas.
_device_iommu_address_space(
> + pbdev->pdev)->root, entry);
> +
> +setcc(cpu, 0);
> +return 0;
> +}
> +
> +int kvm_sic_service_call(S390CPU *cpu, struct kvm_run *run)
> +{
> +DPRINTF("sic\n");
> +return 0;
> +}
> +
> +int kvm_pcistb_service_call(S390CPU *cpu, struct kvm_run *run)
> +{
> +CPUS390XState *env = &cpu->env;
> +uint8_t r1 = (run->s390_sieic.ipa & 0x00f0) >> 4;
> +uint8_t r3 = run->s390_sieic.ipa & 0x000f;
> +PciStb *rp;
> +uint64_t gaddr;
> +uint64_t *uaddr, *pu;
> +hwaddr len;
> +S390PCIBusDevice *pbdev;
> +MemoryRegion *mr;
> +int i;
> +
> +cpu_synchronize_state(CPU(cpu));
> +
> +rp = (PciStb *)&env->regs[r1];
> +gaddr = get_base_disp_rsy(cpu, run);
> +len = rp->len;
Not sure, but don't you also have to check the length and offset here
for valid ranges?
At least you should check for problem state again.
> +pbdev = s390_pci_find_dev_by_fh(rp->fh);
> +if (!pbdev) {
> +DPRINTF("pcistb no pci dev fh 0x%x\n", rp->fh);
> +return -EIO;
User cc3 instead?
> +}
> +
> +uaddr = cpu_physical_memory_map(gaddr, &len, 0);
> +mr = pbdev->pdev->io_regions[rp->pcias].memory;
> +
> +pu = uaddr;
> +for (i = 0; i < rp->len / 8; i++) {
> +io_mem_write(mr, env->regs[r3] + i * 8, *pu, 8);
> +pu++;
> +}
> +
> +cpu_physical_memory_unmap(uaddr, len, 0, len);
> +setcc(cpu, 0);
> +return 0;
> +}
[...]
Thomas
Public bug reported:
I try to compile qemu-2.1.1 (Gentoo/x86), but the i386-softmmu fails to
compile:
CPP i386-softmmu/q35-acpi-dsdt.dsl.i.orig
ACPI_PREPROCESS i386-softmmu/q35-acpi-dsdt.dsl.i
IASL i386-softmmu/q35-acpi-dsdt.dsl.i
ACPI_EXTRACT i386-softmmu/q35-acpi-dsdt.off
CAT i386-sof
sorry, but this has nothing to do with gentoo patches.
Just to prove it, I did the following:
cd /var/tmp
git clone git://git.qemu.org/qemu.git
mkdir qemu-build
cd qemu-build
../qemu/configure --target-list=i386-softmmu
make 2>&1 | tee ../qemu-build.log
xz ../qemu-build.log
rm -Rf *
../qemu/confi
** Attachment added: "make log with "make -d" (lots of debug info)"
https://bugs.launchpad.net/qemu/+bug/1373362/+attachment/4214389/+files/qemu-build-debug.log.xz
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launc
I retried it on another machine, running Kubuntu 14.10 (x86_64) -> fails
at exactly the same point !
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1373362
Title:
qemu-2.1.1 i386-softmmu compile err
update: I found out that the latest version on the stable-1.7 branch builds
fine, but all stable-2.0 and later fail.
I did some binary search on all versions on the stable-2.0 branch and found out
that the problem occurs after this commit:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=15bce1b7c
which is not the case for the old
one). Maybe it is worth writing some version check in the configure
script ?
IMO we can close this bug.
thanks a lot for your help,
Thomas
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://b
On Mon, 2013-04-15 at 16:14 +0200, Stefan Hajnoczi wrote:
> The nbd block driver should use TCP_NODELAY. Nick Thomas
>
> measured a 40 millisecond latency added by the Naggle algorithm.
>
> This series turns on TCP_NODELAY. This requires that we use TCP_CORK to
> efficiently
static void handle_arg_argv0(const char *arg)
Grüße,
Thomas
pgprkIUQqLlNd.pgp
Description: PGP signature
nux-user/qemu-x86_64 [some options] -env [more options]
> a=b,c d=e,f=a /usr/bin/printenv
> a=b,c
> d=e,f=a
>
> I think I might prefer that solution. As it is a new option, it also
> won't interfere with anyone's usage/expectations of the
Signed-off-by: Thomas Schwinge
---
linux-user/main.c | 18 --
util/envlist.c|4 ++--
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git linux-user/main.c linux-user/main.c
index 4e92a0b..7f81821 100644
--- linux-user/main.c
+++ linux-user/main.c
@@ -3204,26
Revert the change in behavior that had been introducecd in commit
fc9c54124d134dbd76338a92a91804dab2df8166 for the -E and -U command-line
options, but keep the comma-splitting for the QEMU_SET_ENV and QEMU_UNSET_ENV
environment variables.
Signed-off-by: Thomas Schwinge
---
linux-user/main.c
Signed-off-by: Thomas Schwinge
---
linux-user/main.c | 47 ++-
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git linux-user/main.c linux-user/main.c
index 7f81821..50bbadf 100644
--- linux-user/main.c
+++ linux-user/main.c
@@ -3180,12
Signed-off-by: Thomas Schwinge
---
util/envlist.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git util/envlist.c util/envlist.c
index ebc06cf..cbbf7e5 100644
--- util/envlist.c
+++ util/envlist.c
@@ -109,9 +109,10 @@ envlist_parse(envlist_t *envlist, const char *env
Hi!
On Thu, 25 Apr 2013 16:52:28 +0100, Peter Maydell
wrote:
> On 25 April 2013 16:06, Thomas Schwinge wrote:
> > Revert the change in behavior that had been introducecd in commit
> > fc9c54124d134dbd76338a92a91804dab2df8166 for the -E and -U command-line
> > option
Revert the change in behavior that had been introducecd in commit
fc9c54124d134dbd76338a92a91804dab2df8166 for the -E and -U command-line
options, but keep the comma-splitting for the QEMU_SET_ENV and QEMU_UNSET_ENV
environment variables.
Signed-off-by: Thomas Schwinge
---
linux-user/main.c
Has been removed in commit fc9c54124d134dbd76338a92a91804dab2df8166.
Signed-off-by: Thomas Schwinge
---
qemu-doc.texi |3 ---
1 file changed, 3 deletions(-)
diff --git qemu-doc.texi qemu-doc.texi
index dfea4d3..64493eb 100644
--- qemu-doc.texi
+++ qemu-doc.texi
@@ -2683,9 +2683,6 @@ Set
s,
<http://news.gmane.org/find-root.php?message_id=%3Calpine.DEB.1.10.1306091926470.16287%40tp.orcam.me.uk%3E>,
which I have not yet managed to allocate the time to do, and can't tell
when it's going to happen -- but I still have it on my TODO list.
Grüße,
Thomas
pgp4PEVCIW
> processors, which PAPR inherits largely from. Thus this naming scheme
> should apply to all PowerPC processors when a device-tree is involved.
Well, I think it should be used when an Open Firmware environment is
used. When you boot via ePAPR device tree, the name should be "cpu"
instead, according to the ePAPR specification.
Thomas
> >>
> >>
> >
> Any help, please?
You could try to attach a GDB to see where it is hanging (start qemu
with the -s option, see http://wiki.qemu.org/Documentation/Debugging).
Thomas
add a proper
comment here (or somebody will fix it back in the future when reading
the code), ... or would it also work to type-cast the result of
ARRAY_SIZE to "int"? Something like this:
for (i = 0; i < (int)ARRAY_SIZE(args_tmp) && \
i < (int)ARRAY_SIZE(cap.args); i++)
Thomas
ison of unsigned expression < 0 is
> always false [-Werror=type-limits]
>
> However - thanks to Thomas Huth for the suggestion - we can just cast the
> offending potentially 0 value to a signed type, making the comparison signed.
>
> Signed-off-by: Alexander Graf
&g
On Thu, 9 Oct 2014 17:28:57 +0100
Peter Maydell wrote:
> On 9 October 2014 14:36, Cornelia Huck wrote:
> > From: Thomas Huth
> >
> > This patch provides the cpu save information for dumps and later life
> > migration and enables migration of the CPU state. The code i
n the past and thus got listed with the
"Reviewed-by:" tag. I would not expect that behaviour when I run a
"get_maintainers" script (it's not called "get_reviewers", is it?).
Maybe you could at least remove the "Reviewed-by:" and "Acked-by:" from
the --git-fallback option so that it only checks for the SOBs?
Thomas
irkin" (commit_signer:1/1=100%)
> > >
> > > Maybe --git-fallback is broken?
> >
> > I tried on master (i.e. without my patch, clean tree, with and without
> > --git-fallback. Just tried it again, same result.
>
> Well ... I don't know why.
> It's clearly a bug.
> Different perl version? Different git version?
>
> Can you try tracing it?
> Does it exec git?
I've got the same behaviour as Markus (i.e. no output), and I think
this is due to get_maintainer.pl using $email_git_since = "1-year-ago"
... since there wasn't a commit to that file in the last year, git-log
simply does not output any entry at all.
Do you have a non-upstream commit in your git tree that changes that
file? That would explain why you get some output here.
Thomas
are
> touching now.
Maybe you could at least also add "--git-blame" to the message that is
printed out here - so in case --git-fallback does not print anything at
all due to the 1-year limitation, the user has at least another thing to
try?
Thomas
anged, 21 insertions(+), 31 deletions(-)
I think these are good patches ... but while you're at it, I wonder
whether you should/could also replace the entry for "penguin_chief" in
that file. It still points to Linus Torvalds - but I assume he does not
like to be bothered with patches related to QEMU... ?
Thomas
Linus likely does not want to get e-mails about QEMU, so let's
just remove this option.
Suggested-by: Michael S. Tsirkin
Signed-off-by: Thomas Huth
---
scripts/get_maintainer.pl | 45 +
1 files changed, 1 insertions(+), 44 deletions(-)
diff
, r1, 20ul);
> +return 0;
> +}
> +
> +switch (rp->len) {
> +case 16:
> +case 32:
> +case 64:
> +case 128:
> +break;
> +default:
> +program_interrupt(env, PGM_SPECIFICATION, 6);
> +return 0;
> +}
> +
> +gaddr = get_base_disp_rsy(cpu, run);
> +len = rp->len;
> +
> +pbdev = s390_pci_find_dev_by_fh(rp->fh);
> +if (!pbdev) {
> +DPRINTF("pcistb no pci dev fh 0x%x\n", rp->fh);
> +setcc(cpu, 3);
> +return 0;
> +}
> +
> +uaddr = cpu_physical_memory_map(gaddr, &len, 0);
> +mr = pbdev->pdev->io_regions[rp->pcias].memory;
> +if (!memory_region_access_valid(mr, env->regs[r3], rp->len, true)) {
> +cpu_physical_memory_unmap(uaddr, len, 0, len);
> +program_interrupt(env, PGM_OPERAND, 6);
PGM_ADDRESSING might be the better choice in this case.
> +return 0;
> +}
> +
> +pu = uaddr;
> +for (i = 0; i < rp->len / 8; i++) {
> +io_mem_write(mr, env->regs[r3] + i * 8, *pu, 8);
> +pu++;
> +}
> +
> +cpu_physical_memory_unmap(uaddr, len, 0, len);
> +setcc(cpu, 0);
> +return 0;
> +}
...
> +int kvm_mpcifc_service_call(S390CPU *cpu, struct kvm_run *run)
> +{
> +CPUS390XState *env = &cpu->env;
> +uint8_t r1 = (run->s390_sieic.ipa & 0x00f0) >> 4;
> +uint8_t oc;
> +uint32_t fh;
> +uint64_t fiba;
> +ZpciFib fib;
> +S390PCIBusDevice *pbdev;
> +
> +cpu_synchronize_state(CPU(cpu));
> +
> +if (env->psw.mask & PSW_MASK_PSTATE) {
> +program_interrupt(env, PGM_PRIVILEGED, 6);
> +return 0;
> +}
> +
> +oc = env->regs[r1] & 0xff;
> +fh = env->regs[r1] >> 32;
> +fiba = get_base_disp_rxy(cpu, run);
> +
> +if (fiba & 0x7) {
> +program_interrupt(env, PGM_SPECIFICATION, 6);
> +return 0;
> +}
> +
> +pbdev = s390_pci_find_dev_by_fh(fh);
> +if (!pbdev) {
> +DPRINTF("mpcifc no pci dev fh 0x%x\n", fh);
> +setcc(cpu, 3);
> +return 0;
> +}
> +
> +cpu_physical_memory_rw(fiba, (uint8_t *)&fib, sizeof(fib), 0);
> +
> +switch (oc) {
> +case ZPCI_MOD_FC_REG_INT: {
> +pbdev->isc = FIB_DATA_ISC(fib.data);
> +reg_irqs(env, pbdev, fib);
> +break;
> +}
> +case ZPCI_MOD_FC_DEREG_INT:
> +dereg_irqs(pbdev);
> +break;
> +case ZPCI_MOD_FC_REG_IOAT:
> +if (fib.pba > fib.pal) {
> +program_interrupt(&cpu->env, PGM_OPERAND, 6);
> +return 0;
> +}
> +pbdev->g_iota = fib.iota & ~ZPCI_IOTA_RTTO_FLAG;
> +break;
> +case ZPCI_MOD_FC_DEREG_IOAT:
> +break;
> +case ZPCI_MOD_FC_REREG_IOAT:
> +break;
> +case ZPCI_MOD_FC_RESET_ERROR:
> +break;
> +case ZPCI_MOD_FC_RESET_BLOCK:
> +break;
> +case ZPCI_MOD_FC_SET_MEASURE:
> +break;
> +default:
> +program_interrupt(&cpu->env, PGM_OPERAND, 6);
> +return 0;
> +}
> +
> +setcc(cpu, 0);
> +return 0;
> +}
> +
> +int kvm_stpcifc_service_call(S390CPU *cpu, struct kvm_run *run)
> +{
> +DPRINTF("stpcifc\n");
As with SIC, I wonder whether it might be better to inject an exception
by default?
> +return 0;
> +}
Thomas
the same page. */
> #ifdef ALIGNED_ONLY
> if ((addr & (DATA_SIZE - 1)) != 0) {
> -cpu_unaligned_access(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
> +cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
> + mmu_idx, retaddr);
> }
> #endif
>
I very much like the idea to get rid of these "magic" numbers!
Reviewed-by: Thomas Huth
On Sun, May 1, 2011 at 6:35 PM, Stefan Hajnoczi wrote:
> On Thu, Apr 28, 2011 at 3:11 PM, Arun Thomas wrote:
>> The multiboot info struct's 'boot_device' field has 'part1' set to 0x01,
>> which
>> maps to the second primary partition. To specify the
ISO out of the way and attempt
to read some data - you should see behaviour matching the above.
Signed-off-by: Nick Thomas
---
block/curl.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index 407f095..52c6463 100644
--- a
-cancelling code does
work in this revision, however.
Read and write requests are now split up to fit into 1MiB blocks.
This is a limit that seems to be imposed by most (all?) NBD servers,
including the one shipped with QEMU.
Signed-off-by: Nick Thomas
---
Makefile.objs |4 +-
block/nbd.c | 1064
ound
This happens with real /dev/sr1 and with an ISO image in a regular file.
-----
Have a nice day :)
Thomas
recorded session.
The qemu-0.15.1 process and its guest system are still well and
alive. (Different than with DVD+RW and SET STREAMING.)
--
Have a nice day :)
Thomas
t 'QEMU DVD-ROM' from file=/dev/sg2,if=scsi behaves like
the drives from the other file=...,if=scsi makes me think that it is
an emulated SCSI drive.
GET CONFIGURATION could tell, if it would deliver feature 0x01.
The 'CDDVDW SH-S223B' reports Physical Interface 7 = "Serial ATAPI".
But the 'QEMU DVD-ROM' does not report feature 0x01.
--
Have a nice day :)
Thomas
ive (Mode Page 5).
Without it, you have no control and depend on the existence of a
suitable default.
Actually i cannot spot in my experiments a single successful command
with transfer direction to the drive.
READ(10), on the other hand, works well.
Have a nice day :)
Thomas
get2:0:0
$ cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices
hostchanid lun typeopens qdepth busyonline
0 0 0 0 0 1 1 0 1
1 0 0 0 5 1 1 0 1
2 0 0
IDE drive emulation emits a Mode Data
Length of 0x22. With Page Length 0x12 it should have been 0x1a.
8 too many.
Have a nice day :)
Thomas
ed number as Allocation
Length of the commands MODE SENSE(6) or MODE SENSE(10).
Have a nice day :)
Thomas
scsi_disk_emulate_mode_sense()
It distinguishes between MODE_SENSE, which gets 4 bytes of header,
and MODE_SENSE_10, which gets 8. This looks correct.
Have a nice day :)
Thomas
of this assumption to fail, is
Linux 2.4 with USB attached drives.
ATAPI via ide-scsi kernel module did tolerate oversized requests
back in 2007. Since then i did not challenge OSes that way.
---
Have a nice day :)
Thomas
: ret= %ld\n", (long int)
ret);
+if(ret)
+ printf("posix-aio-compat.c: qemu_paio_error: returning %ld\n", (long
int) ret);
+if(ret)
+ printf("posix-aio-compat.c: posix_aio_process_queue:
ret= %d -> %d\n", ret, -ret);
+if(ret)
+ printf("posix-aio-compat.c: posix_aio_process_queue: calling
acb->common.cb(,%d)\n", ret);
-
Have a nice day :)
Thomas
the reason, because on the guest, the
third command succeeds with 2052 bytes of payload data (as on the host):
READ DISC STRUCTURE
ad 00 00 00 00 00 00 00 08 04 00 00
From drive: 2052b
...
-
Have a nice day :)
Thomas
ODE SELECT(10), WRITE(10)
which work fine on the guest.
---
Have a nice day :)
Thomas
7d a7
0 ms
READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00
>From drive: 20b
00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7
0 ms
START/STOP UNIT
1b 01 00 00 00 00
4 ms
TEST UNIT READY
00 00 00 00 00 00
560 ms
Have a nice day :)
Thomas
hen i will lose my
naivity skills as unbiased tester. :))
Have a nice day :)
Thomas
UNIT already ends with failure
indication.
Have a nice day :)
Thomas
ser.
-
Have a nice day :)
Thomas
8 00 80 05 ea
0 ms
So that xorriso can report:
xorriso : UPDATE : Blanking ( 3.3% done in 25 seconds )
The BLANK command can be performed without special preparations.
The medium should not already be blank, though.
--------
Have a nice day :)
Thomas
libburn write models of CD, DVD, and BD.
Write a summary of all results.
I plan to check DVD+R tonight. BD-R and BD-RE tomorrow.
Have a nice day :)
Thomas
option -multi.
Works well. Passes all read checks.
---
Since BD-R are very similar to DVD+R, but much more expensive,
i will tomorrow only test the case without RESERVE TRACK.
Have a nice day :)
Thomas
3d ]---
Then come lines from the reboot:
Nov 6 08:56:19 debian2 kernel: imklog 4.6.4, log source = /proc/kmsg started.
------
I will now try to attach the drive via eSATA.
Have a nice day :)
Thomas
1.693623] ata5.00: ATAPI: Optiarc BD RW
BD-5300S, 1.04, max UDMA/100
On Debian 5, the internal drive was run with 3.0 Gbps and worked fine.
Miracles of system administration ...
----
Have a nice day :)
Thomas
ve by mistake of the user.
-----
Have a nice day :)
Thomas
------
Have a nice day :)
Thomas
I would like to read it and contribute my experiences.
---
Have a nice day :)
Thomas
dresses and how to
perform SCSI transactions from userspace. And help with installing
the guest system, of course.
Have a nice day :)
Thomas
:))
But i understand that GNU/Hurd will not offer the guest support
for virtio. So i will have to resort to -cdrom for development
and an old PC for burn testing, if ever an RPC for userspace
SCSI transactions gets approved.
(Inside gnumach, there sit transaction calls for ATAPI and SCSI.
But there is no way to use them directly from Hurd.)
Have a nice day :)
Thomas
sicd,logical_block_size=2048,physical_block_size=2048
with some of the re-usable media types.
Have a nice day :)
Thomas
uot;
> -"%ldM guest RAM\n", MIN_RAM_SLOF);
> +"%ldM guest RAM\n", MIN_RMA_SLOF);
Maybe it's more helpful for the unexperienced users when we change the
term "guest RAM" to "real mode area (RMA) memory" here? What do you
think?
Thomas
Hi,
the test results on CD-RW, DVD-RW, DVD+RW, BD-RE are flawless with
Paolo Bonzini's most recent proposal
-drive file=/dev/sr2,if=none,id=scsicd
-device
virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048
libburn works fine via SG_IO. dd and other unaware readers work fi
tf("block/raw-posix.c: /dev/sr O_EXCL test : s->open_flags is now
0x%x\n", s->open_flags);
+ }
+
s->fd = -1;
fd = qemu_open(filename, s->open_flags, 0644);
---
Have a nice day :)
Thomas
te to myself: disable udev hack before if=scsi test.)
Have a nice day :)
Thomas
from CDs
It was a good stumble stone for my own code.
Have a nice day :)
Thomas
CD-RW.
With empty tray it still refuses with
qemu-system-x86_64: -device
virtio-blk-pci,drive=scsicd,logical_block_size=2048,physical_block_size=2048:
Device needs media, but drive is empty
Have a nice day :)
Thomas
hink it's best if these patches wait until Thomas can give a
> shot at testing them. If that means missing 1.0, so be it.
libburn does not use mode page 1 "Read/Write Error Recovery Parameters".
So can only judge by theory and not by test.
MMC-1 says it has 8 bytes (beginning a
On Fri, 2011-09-09 at 12:29 +0200, Paolo Bonzini wrote:
> On 09/09/2011 11:00 AM, Kevin Wolf wrote:
> > There is anonther patch enabling AIO for NBD on the list [1], by
> > Nicholas Thomas (CCed), that lacked review so far. Can you guys please
> > review each others approach a
On 09/09/11 12:04, Kevin Wolf wrote:
> Good to see agreement here. Do you think that Paolo's patches need to be
> changed or can we do everything else on top?
A few things have come up on a third read, actually. I'll respond in due
course to the appropriate patch.
> We do have some timer stubs i
On 08/09/11 16:25, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
> ---
> block/nbd.c | 167 ++
> nbd.c |8 +++
> 2 files changed, 117 insertions(+), 58 deletions(-)
>
> diff --git a/block/nbd.c b/block/nbd.c
> index 964caa8
On 08/09/11 16:25, Paolo Bonzini wrote:
> qemu-nbd has a limit of slightly less than 1M per request. Work
> around this in the nbd block driver.
>
> Signed-off-by: Paolo Bonzini
> ---
> block/nbd.c | 52 ++--
> 1 files changed, 46 insertions(+),
Currently, it is possible that a live migration never finishes, when the dirty
page rate is high compared to the scan/transfer rate. The exact values for
MAX_MEMORY_ITERATIONS and MAX_TOTAL_MEMORY_TRANSFER_FACTOR are arguable, but
there should be *some* limit to force the final iteration of a li
Am 14.09.2011 17:45, schrieb Anthony Liguori:
On 09/14/2011 08:18 AM, Thomas Treutner wrote:
Currently, it is possible that a live migration never finishes, when
the dirty page rate is high compared to the scan/transfer rate. The
exact values for MAX_MEMORY_ITERATIONS and
g method" that SLOF currently uses - and
the "Logical unit addressing method" sounds more reasonable to me when
looking at the places where SLOF tries to fill in the target ID.
So I suggest that I change SLOF to also use the "Logical unit
addressing method" like Linux does, which should result in the fact that
SLOF tries to scan the target IDs instead of the channels/bus IDs.
What do you think, does that sound ok?
Regards,
Thomas
Ds and bus numbers instead of the
"Flat space addressing method" for vscsi ... according to
drivers/scsi/ibmvscsi/ibmvscsi.c :
static inline u16 lun_from_dev(struct scsi_device *dev)
{
return (0x2 << 14) | (dev->id << 8) | (dev->channel << 5) | dev->lun;
}
In case there's really only one device per vscsi instance, shouldn't
that code use addressing method 0x1 instead of 0x2 here?
Thomas
this bit defined. Any suggestions how to fix this problem
in a proper way?
Thomas
On Fri, 28 Mar 2014 18:25:02 +0800
Alexander Graf wrote:
>
>
> > Am 28.03.2014 um 16:16 schrieb Thomas Huth :
> >
> >
> > Hi all!
> >
> > There seems to be a problem with the emulation of the mtmsr instruction:
> > According to the PowerISA sp
1 - 100 of 20891 matches
Mail list logo
