Hi all,
I've been experimenting with adding virtio-blk support to the QEMU
PPC/SPARC64 machines and have found that it is possible for a guest to
program a virtio-blk-pci device such that the qemu-system-ppc process on
the host gets stuck at 100% CPU and requires a "kill -9" to remove it.
The eas
On 23/07/18 00:06, Andrew Randrianasulu wrote:
Hello!
Currently I'm trying pre-releases of qemu, for avoiding situation when release
was too bugged (2.12, for my taste ..qemu-system-alpha was broken,
qemu-system-x86_64 -M q35 was broken ..)
using
qemu-system-ppc --version
QEMU emulator version
Hello!
Currently I'm trying pre-releases of qemu, for avoiding situation when release
was too bugged (2.12, for my taste ..qemu-system-alpha was broken,
qemu-system-x86_64 -M q35 was broken ..)
using
qemu-system-ppc --version
QEMU emulator version 2.12.91 (v3.0.0-rc1-17-g5b3ecd3d94-dirty)
Cop
On Tue, 2017-11-21 at 09:55 +, Alex Bennée wrote:
> Richard Purdie writes:
> > At this point I therefore wanted to seek advice on what the real
> > issue
> > is here and how to fix it!
> Code should be using cpu_interrupt() to change things but we have
> plenty
> of examples in the code of mes
Richard Purdie writes:
> Hi,
>
> I work on the Yocto Project and we use qemu to test boot our Linux
> images and run tests against them. We've been noticing some instability
> for ppc where the images sometimes hang, usually around udevd bring up
> time so just after booting into userspace.
>
>
On Tue, 2017-11-21 at 07:50 +, Mark Cave-Ayland wrote:
> On 21/11/17 00:00, Richard Purdie wrote:
> > I work on the Yocto Project and we use qemu to test boot our Linux
> > images and run tests against them. We've been noticing some
> > instability
> > for ppc where the images sometimes hang, u
On 21/11/17 00:00, Richard Purdie wrote:
> Hi,
>
> I work on the Yocto Project and we use qemu to test boot our Linux
> images and run tests against them. We've been noticing some instability
> for ppc where the images sometimes hang, usually around udevd bring up
> time so just after booting int
Hi,
I work on the Yocto Project and we use qemu to test boot our Linux
images and run tests against them. We've been noticing some instability
for ppc where the images sometimes hang, usually around udevd bring up
time so just after booting into userspace.
To cut a long story short, I've tracked
On 14/03/17 10:00, Alex Bennée wrote:
> Mark Cave-Ayland writes:
>
>> I've recently noticed some video artifacts appearing in the form of
>> horizontal lines whilst testing OpenBIOS boot on some qemu-system-ppc
>> images (see https://www.ilande.co.uk/tmp/qemu/macos9-stripe.png for an
>> example)
On 13/03/17 21:25, Mark Cave-Ayland wrote:
> I've recently noticed some video artifacts appearing in the form of
> horizontal lines whilst testing OpenBIOS boot on some qemu-system-ppc
> images (see https://www.ilande.co.uk/tmp/qemu/macos9-stripe.png for an
> example) which I've finally bisected d
Hi Mark,
Mark Cave-Ayland writes:
> Hi Nikunj,
>
> Testing git master locally I see the following segfault when trying to
> boot my test MacOS 9.2.1 image:
>
>
> $ gdb --args ./qemu-system-ppc -bios
> /home/build/src/openbios/openbios.git/openbios/obj-ppc/openbios-qemu.elf.nostrip
> -cdrom /home/
Hi Nikunj,
Testing git master locally I see the following segfault when trying to
boot my test MacOS 9.2.1 image:
$ gdb --args ./qemu-system-ppc -bios
/home/build/src/openbios/openbios.git/openbios/obj-ppc/openbios-qemu.elf.nostrip
-cdrom /home/build/src/qemu/image/ppc/MacOS921.iso -boot d -m 51
On 03/12/2015 04:38 PM, Mark Cave-Ayland wrote:
> Ah great, you're able to reproduce the same issue locally. Hopefully
> this will give you both enough information to figure out what is
> happening in the optimiser...
Yep, just sent a simple fix.
r~
On Mar 12, 2015 4:34 PM, Mark Cave-Ayland wrote:
> Yes indeed, this fixes the issue in my tests here. But from what you're
> saying this is more of a workaround rather than a fix?
Correct. It simply shows a bug in tcg/optimize.c. At least we have a
workaround if a fix proves difficult before
On 12/03/15 16:51, Bastian Koppelmann wrote:
Hi Bastian,
> On 03/12/2015 03:41 PM, Richard Henderson wrote:
>> On 03/12/2015 01:41 AM, Mark Cave-Ayland wrote:
>>> Whilst testing git master in preparation for some OpenBIOS updates, I'm
>>> seeing the following TCG assert in one of my older test im
On 12/03/15 14:55, Bastian Koppelmann wrote:
Hi Bastian,
> Hi Mark, sorry I forgot to cc qemu-devel :/
>
> On 03/12/2015 08:41 AM, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> Whilst testing git master in preparation for some OpenBIOS updates, I'm
>> seeing the following TCG assert in one of my olde
On 03/12/2015 03:41 PM, Richard Henderson wrote:
On 03/12/2015 01:41 AM, Mark Cave-Ayland wrote:
Whilst testing git master in preparation for some OpenBIOS updates, I'm
seeing the following TCG assert in one of my older test images:
$ gdb --args ./qemu-system-ppc -cdrom
/home/build/src/qemu/
On 03/12/2015 01:41 AM, Mark Cave-Ayland wrote:
> Whilst testing git master in preparation for some OpenBIOS updates, I'm
> seeing the following TCG assert in one of my older test images:
>
>
> $ gdb --args ./qemu-system-ppc -cdrom
> /home/build/src/qemu/image/ppc/ubuntu-5.10-live-powerpc.iso -bo
Hi Mark, sorry I forgot to cc qemu-devel :/
On 03/12/2015 08:41 AM, Mark Cave-Ayland wrote:
Hi all,
Whilst testing git master in preparation for some OpenBIOS updates, I'm
seeing the following TCG assert in one of my older test images:
$ gdb --args ./qemu-system-ppc -cdrom
/home/build/src/qem
On 12/03/15 08:41, Mark Cave-Ayland wrote:
> Hi all,
>
> Whilst testing git master in preparation for some OpenBIOS updates, I'm
> seeing the following TCG assert in one of my older test images:
>
>
> $ gdb --args ./qemu-system-ppc -cdrom
> /home/build/src/qemu/image/ppc/ubuntu-5.10-live-powerp
Hi all,
Whilst testing git master in preparation for some OpenBIOS updates, I'm
seeing the following TCG assert in one of my older test images:
$ gdb --args ./qemu-system-ppc -cdrom
/home/build/src/qemu/image/ppc/ubuntu-5.10-live-powerpc.iso -boot d -g
800x600x8
GNU gdb (GDB) 7.4.1-debian
Copyri
Am Sat 13 Feb 2010 07:29:33 PM CET schrieb Rob Landley :
On Saturday 13 February 2010 06:04:03 Alexander Graf wrote:
> Exactly, that's the issue to fix here, make DBDMA work with CD-ROM so we
> can get rid of the cmd64x controller.
Speaking of which - in my PPC64 enabling series I use MacIO fo
Am Sat 13 Feb 2010 07:27:21 PM CET schrieb Rob Landley :
On Saturday 13 February 2010 04:28:44 Alexander Graf wrote:
On 13.02.2010, at 09:02, Rob Landley wrote:
> The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't
> match the order the kernel assigns the drives.
>
> The reaso
On Saturday 13 February 2010 06:04:03 Alexander Graf wrote:
> > Exactly, that's the issue to fix here, make DBDMA work with CD-ROM so we
> > can get rid of the cmd64x controller.
>
> Speaking of which - in my PPC64 enabling series I use MacIO for all 4 IDE
> devices. At least with recent kernels, L
On Saturday 13 February 2010 04:28:44 Alexander Graf wrote:
> On 13.02.2010, at 09:02, Rob Landley wrote:
> > The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't
> > match the order the kernel assigns the drives.
> >
> > The reason is that the Linux kernel always initializes the
On Sat, Feb 13, 2010 at 01:04:03PM +0100, Alexander Graf wrote:
>
> On 13.02.2010, at 12:58, Aurelien Jarno wrote:
>
> > On Sat, Feb 13, 2010 at 11:28:44AM +0100, Alexander Graf wrote:
> >>
> >> On 13.02.2010, at 09:02, Rob Landley wrote:
> >>
> >>> The -hda, -hdb, -hdc, and -hdd command line o
On 13.02.2010, at 12:58, Aurelien Jarno wrote:
> On Sat, Feb 13, 2010 at 11:28:44AM +0100, Alexander Graf wrote:
>>
>> On 13.02.2010, at 09:02, Rob Landley wrote:
>>
>>> The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't match
>>> the order the kernel assigns the drives.
>>>
On Sat, Feb 13, 2010 at 11:28:44AM +0100, Alexander Graf wrote:
>
> On 13.02.2010, at 09:02, Rob Landley wrote:
>
> > The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't match
> > the order the kernel assigns the drives.
> >
> > The reason is that the Linux kernel always init
On 13.02.2010, at 09:02, Rob Landley wrote:
> The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't match
> the order the kernel assigns the drives.
>
> The reason is that the Linux kernel always initializes the cmd646 driver
> before the pmac driver, thus if there's a cmd646
The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't match
the order the kernel assigns the drives.
The reason is that the Linux kernel always initializes the cmd646 driver
before the pmac driver, thus if there's a cmd646 it gets /dev/hda and
/dev/hdb, and the pmac gets /dev/h
On Fri, 2007-11-02 at 16:46 -0400, Daniel Jacobowitz wrote:
> On Fri, Nov 02, 2007 at 05:23:59PM +0100, Jocelyn Mayer wrote:
> > No, it's not accidental. An application accessing priviledged SPR,
> > including the PVR, is likely to be buggy. I checked in the kernel
> > (2.6.23), trapping the mfpvr
On Fri, Nov 02, 2007 at 05:23:59PM +0100, Jocelyn Mayer wrote:
> No, it's not accidental. An application accessing priviledged SPR,
> including the PVR, is likely to be buggy. I checked in the kernel
> (2.6.23), trapping the mfpvr instruction is a huge bug because it breaks
> the virtualisation fea
On Fri, 2007-11-02 at 08:57 -0500, Jason Wessel wrote:
> J. Mayer wrote:
> > On Fri, 2007-11-02 at 08:04 -0500, Jason Wessel wrote:
> >
> >> The typical kernel + user space I boot on the prep machine no longer
> >> boots due to an issue accessing the PVR special purpose register. When
> >> the
J. Mayer wrote:
> On Fri, 2007-11-02 at 08:04 -0500, Jason Wessel wrote:
>
>> The typical kernel + user space I boot on the prep machine no longer
>> boots due to an issue accessing the PVR special purpose register. When
>> the PVR is accessed from user space, it should generate an exception
>>
On Fri, 2007-11-02 at 08:04 -0500, Jason Wessel wrote:
> The typical kernel + user space I boot on the prep machine no longer
> boots due to an issue accessing the PVR special purpose register. When
> the PVR is accessed from user space, it should generate an exception
> with the PC set to the in
The typical kernel + user space I boot on the prep machine no longer
boots due to an issue accessing the PVR special purpose register. When
the PVR is accessed from user space, it should generate an exception
with the PC set to the instruction that it occurred at when it saves to
the stack. In th
Tilman Sauerbeck <[EMAIL PROTECTED]> [2005-06-30 20:37]:
> Next, I tried to install a real Linux distro (CRUX PPC,
> cruxppc.sunsite.dk):
>
> I created a disk image (crux-ppc-2.0.img) and started qemu like this:
>
> qemu-system-ppc -M prep -kernel zImage.prep -cdrom crux-ppc-2.0.iso
> -boot d -hd
Hi,
Just a clarification about the state of the QEMU PowerPC system emulator
in the CVS head: I commited important changes in order to be able to
launch Mac OS X, but important changes are needed in the PPC BIOS too
and they are not yet commited because some merging is necessary. Sorry
for th
Jim C. Brown <[EMAIL PROTECTED]> [2005-06-30 15:35]:
> On Thu, Jun 30, 2005 at 08:37:36PM +0200, Tilman Sauerbeck wrote:
> > Sweet, with that command line switch and Jim's patch, qemu (cvs HEAD) will
> > start up and boot linux-ppc.img just fine :)
> >
> > Next, I tried to install a real Linux dis
On Thu, Jun 30, 2005 at 08:37:36PM +0200, Tilman Sauerbeck wrote:
> Sweet, with that command line switch and Jim's patch, qemu (cvs HEAD) will
> start up and boot linux-ppc.img just fine :)
>
> Next, I tried to install a real Linux distro (CRUX PPC,
> cruxppc.sunsite.dk):
>
> I created a disk ima
Tero Kaarlela <[EMAIL PROTECTED]> [2005-06-30 19:45]:
> >I'm trying to run qemu-system-ppc on a x86 box (Linux 2.6.12, gcc
> >3.4.3), but the SDL window that qemu opens just stays black, there's no
> >output at all (nothing on stdout either).
> >For example, I tried to run qemu-system-ppc with the
Tilman Sauerbeck wrote:
Hi,
I'm trying to run qemu-system-ppc on a x86 box (Linux 2.6.12, gcc
3.4.3), but the SDL window that qemu opens just stays black, there's no
output at all (nothing on stdout either).
For example, I tried to run qemu-system-ppc with the linux-ppc image
from freeoszoo.org
Hi,
I'm trying to run qemu-system-ppc on a x86 box (Linux 2.6.12, gcc
3.4.3), but the SDL window that qemu opens just stays black, there's no
output at all (nothing on stdout either).
For example, I tried to run qemu-system-ppc with the linux-ppc image
from freeoszoo.org.
I launched qemu like this
43 matches
Mail list logo
