Quoting Michal Simek :
Hi Edgar and Guenter,
2014-02-08 Edgar E. Iglesias :
On Fri, Feb 07, 2014 at 03:17:31PM -0800, Guenter Roeck wrote:
> Michal,
>
> commit 34b9c07a3 (microblaze: Disable stack protection from bootloader)
results
> in the following qemu crash in 3.14-rc1.
>
> /opt/buildbo
From: Prasad Joshi
Signed-off-by: Prasad Joshi
---
target-i386/cpu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e2302d8..540e450 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -455,7 +455,7 @@ static x86_def_t bu
From: Prasad Joshi
Signed-off-by: Prasad Joshi
---
target-i386/cpu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e2302d8..540e450 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -455,7 +455,7 @@ static x86_def_t bu
i m using following configuration..
vikas@vikas-ThinkCentre-A70:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.04
DISTRIB_CODENAME=natty
DISTRIB_DESCRIPTION="Ubuntu 11.04"
vikas@vikas-ThinkCentre-A70:~$ uname -a
Linux vikas-ThinkCentre-A70 2.6.38-8-generic #42-Ubuntu SMP Mo
DISTRIB_RELEASE=11.04
DISTRIB_CODENAME=natty
DISTRIB_DESCRIPTION="Ubuntu 11.04"
==>uname -a
Linux vikas-ThinkCentre-A70 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50
UTC 2011 i686 i686 i386 GNU/Linux
QEMU emulator version 1.0,1, Copyright (c) 2003-2008 Fabrice Bellard
fist i
Hi All
I am launching an x86 debian system as guest on my x86 host machine. The
host is an 8-core, 2-socket machine booted with RHEL7 with KVM enabled. 2
PCI devices are being emulated on the guest.
-I need to verify the concurrent operation of these PCI devices. PCI device
A is designed in such a
Public bug reported:
This test program:
# compile with: gcc -nostartfiles -nostdlib
_start: .globl _start
mov %ss,%eax
push%rax
push%rsp
pushf
mov %cs,%eax
push%rax
# qemu-system-x86_64 --version
QEMU emulator version 2.6.92(qemu-2.7.0-0.1.rc2.fc26), Copyright (c) 2003-2008
Fabrice Bellard
Running it like this:
qemu-system-x86_64 -no-reboot -kernel "$bzImage" -initrd initramfs.cpio
-append "panic=1"
(i.e. no KVM, no unusual options)
--
You received this
** Description changed:
This test program:
# compile with: gcc -nostartfiles -nostdlib
_start: .globl _start
- mov %ss,%eax
- push%rax
- push%rsp
- pushf
- mov %cs,%eax
-
sorry i couldnt do with git. i am founder and developer of Milis Linux
can you consider this patch please:
it is :
* Milis: `mps kur qemu-all`
best regards
QEMU is packaged by most Linux distributions:
* Arch: `pacman -S qemu`
* Debian/Ubuntu: `apt-get install qemu`
* Fedora: `dnf install
Still happens with qemu 5.1.92
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1613817
Title:
x86: ret, lret and iret with noncanonical IP saves
I imagine the fix should be inserted here:
static inline void helper_ret_protected(CPUX86State *env, int shift,
int is_iret, int addend,
uintptr_t retaddr)
{
uint32_t new_cs, new_eflags, new_ss;
uint32_t new_es
by the
> >>>>> guest kernel, but this would rely on the vmgenid ACPI notification to
> >>>>> trigger the counter update, which is inherently racy. Exposing this
> >>>>> through the monitor allows the updated value to be in-place before
> >
We're seeing this error on Ubuntu 20.04 amd64 host and aarch64
qemu-aarch64-static chroot when executing 'aptitude':
qemu:handle_cpu_signal received signal outside vCPU context
qemu:handle_cpu_signal received signal outside vCPU context
Research led us to an identical issue report against qemu-m6
user --static builds are apparently resulting in dynamically linked
executables (to the glibc library, not other shared objects )
Concise summary:
$ file ../qemu-aarch64_v*
../qemu-aarch64_v4.2.1: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), statically linked,
BuildID[sha1
On 16/12/2020 11:39, Paolo Bonzini wrote:
> On 16/12/20 12:07, Peter Maydell wrote:
>> Something has definitely changed here. What you had with 4.2.1
>> is what you should be getting. The obvious suspect is that
>> something weird happened in the meson conversion...
Ubuntu/Debian maintainer reprod
On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote:
> On 12 August 2013 01:40, Guenter Roeck wrote:
> > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote:
> >> It could be that it's qemu's PCI routing is wrong - it's not the first
> >&
31) and slot B = 19. So
why do we apparantly have a card in a non-existent slot at 13?
Now, it looks to me like we have the rotation in the right direction,
it's just a matter of ensuring that we have the right starting point.
That's where we need to know what slot number Linux believes slot A
and slot B actually are.
On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote:
> On 12 August 2013 21:06, Russell King - ARM Linux
> wrote:
> > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote:
> >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane
> >>
On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote:
> On this point, yes. Equivalent bit from the PB926 TRM:
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html
>
> (There are differences between the PCI controllers on
> the different boards. Differences I know of
On Tue, Aug 13, 2013 at 03:37:31AM -0500, Rob Landley wrote:
> Because working with old and new qemu, like it used to before everybody
> fiddled with it to not actually match hardware nobody _has_, is
> definitely not an interesting goal.
It appears that people *do* have the hardware.
What is
On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
> Hacked diff is below. Can I write that up as clean patch and submit it,
> or do we need a test on real hardware ?
Well, if we want to ensure that it is really correct, the sensible thing
to do is to try it on real hardware, otherwise
On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote:
> On 14 August 2013 11:33, Russell King - ARM Linux
> wrote:
> > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
> >> Hacked diff is below. Can I write that up as clean patch and submit it,
> &g
On Wed, Apr 16, 2014 at 05:08:35PM -0400, Christopher Covington wrote:
> What I meant to ask about was variance from one kernel version and build to
> the next, given a single platform. Platform-to-platform variation can probably
> be abstracted where needed by the scripts controlling the external
On Wed, Apr 16, 2014 at 10:36:11PM +0100, Peter Maydell wrote:
> On 16 April 2014 22:08, Christopher Covington wrote:
> > On 04/16/2014 03:14 PM, Nicolas Pitre wrote:
> >> But both QEMU and the boot-wrapper should deal with zImage. That's the
> >> only image format with documented load offset is g
On Thu, Apr 17, 2014 at 04:06:16PM -0400, Nicolas Pitre wrote:
> On Thu, 17 Apr 2014, Rob Herring wrote:
> > Better yet, we should adopt the arm64 Image header which has this and
> > other fields for arm Image files. We're going to have to deal with raw
> > Image (and Image.gz) in bootloaders for a
simple issue is you are now wasting 2MB of low memory on every
> platform. Not such a big deal I guess. But what if more is needed?
Why do you think it's wasted in the general case? Do you think the
first 16K is ignored by Linux? All memory will be freed to the Linux
page allocator unless
On Thu, Apr 17, 2014 at 09:53:23PM -0500, Rob Herring wrote:
> On Thu, Apr 17, 2014 at 4:35 PM, Russell King - ARM Linux
> wrote:
> > No. You simply can't eliminate any of the above - each one has been
> > negotiated through quite an amount of discussion with relevant pa
On Tue, Apr 22, 2014 at 10:53:07AM +0100, Daniel Thompson wrote:
> On 17/04/14 22:35, Russell King - ARM Linux wrote:
> > On Thu, Apr 17, 2014 at 04:18:45PM -0500, Rob Herring wrote:
> >> The problem here is more than just the TEXT_OFFSET changed. From what
> >> I'v
On Tue, Apr 22, 2014 at 11:26:53AM +0100, Daniel Thompson wrote:
> On 18/04/14 05:34, Nicolas Pitre wrote:
> >> I'm not suggesting to break anything or changing existing platforms,
> >> > but how do we improve the Image format in a compatible way. If
> >> > bootloaders want to support booting Image
On Tue, Apr 22, 2014 at 04:50:12PM +0200, Michal Simek wrote:
> On 04/17/2014 10:35 PM, Jason Gunthorpe wrote:
> > +/* If we have a known, fixed physical load address then set LOAD_OFFSET
> > + and generate an ELF that has the physical load address in the program
> > + headers. */
> > +#ifndef
On Tue, Apr 22, 2014 at 11:53:25AM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 22, 2014 at 06:11:42PM +0100, Russell King - ARM Linux wrote:
>
> > Put another way, if your platform is part of the multi-platform kernel
> > then you are *excluded* from being able to use this.
On Tue, Apr 22, 2014 at 08:32:10PM +0200, Arnd Bergmann wrote:
> @@ -1943,6 +1953,7 @@ config DEPRECATED_PARAM_STRUCT
> # TEXT and BSS so we preserve their values in the config files.
> config ZBOOT_ROM_TEXT
> hex "Compressed ROM boot loader base address"
> + depends on BROKEN_MULTIPLAT
nk this is useful
> upstream.
Also, let's not forget that it the ELF file can be modified after the
kernel build:
$ vmlinux=your-vmlinux-file
$ newlma=lma-for-your-platform
$ arm-linux-objcopy $(
arm-linux-objdump -h ${vmlinux} |
grep -B1 'LOAD' | \
sed -nr 's/^[ 0-9
On Fri, Nov 11, 2016 at 09:23:43PM +, David Woodhouse wrote:
> It's also *fairly* unlikely that the kernel in the guest has developed
> a bug and isn't setting gso_size sanely. I'm more inclined to suspect
> that qemu isn't properly emulating those bits. But at first glance at
> the code, it lo
On Fri, Nov 11, 2016 at 09:23:43PM +, David Woodhouse wrote:
> On Fri, 2016-11-11 at 21:05 +, Russell King - ARM Linux wrote:
> >
> > 18:59:38.782818 IP (tos 0x0, ttl 52, id 35619, offset 0, flags [DF], proto
> > TCP (6), length 60)
> > 84.xx.xxx.196.61236
Hello:
This patch was applied to riscv/linux.git (fixes)
by Greg Kroah-Hartman :
On Tue, 12 Nov 2024 09:35:20 +0100 you wrote:
> After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
> return void") .remove() is (again) the right callback to implement for
> platform drivers.
>
> C
[TLDR: This mail in primarily relevant for Linux regression tracking. A
change or fix related to the regression discussed in this thread was
posted or applied, but it did not use a Link: tag to point to the
report, as Linus and the documentation call for. Things happen, no
worries -- but now the
38 matches
Mail list logo
