Re: [PATCH] sparc: sparc64_defconfig: add necessary configs for qemu

On 02/07/2020 14:02, Corentin Labbe wrote: > The sparc64 qemu machines uses pcnet32 network hardware by default, so for > simple boot testing using qemu, having PCNET32 is useful. > Same for its storage which is a PATA_CMD64. Which version of QEMU are you using? qemu-system-sparc64 switched to

Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args

On 18/05/2020 19:18, Al Viro wrote: >> I hadn't looked into details (the branch itself is only two commits long, >> but it >> incorporates an openbios update - 35 commits there, some obviously pci- and >> sun4u-related), but it's really easy to reproduce - -m 1024 and -hda >> are probably the

Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args

On 17/05/2020 16:01, Christian Brauner wrote: > On Tue, May 12, 2020 at 01:06:33PM -0700, David Miller wrote: >> From: Christian Brauner >> Date: Tue, 12 May 2020 19:15:24 +0200 >> >>> I've tested this series with qemu-system-sparc64 and a Debian Sid image >>> and it comes up no problem (Here's

Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest

On 19/02/2019 04:55, Michael Ellerman wrote: > Mark Cave-Ayland writes: >> On 11/02/2019 00:30, Benjamin Herrenschmidt wrote: >> >>> On Fri, 2019-02-08 at 14:51 +, Mark Cave-Ayland wrote: >>>> >>>> Indeed, but there are still some questions to

Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest

On 19/02/2019 04:20, Michael Ellerman wrote: Hi Michael, > Mark Cave-Ayland writes: >> On 08/02/2019 14:45, Christophe Leroy wrote: >> >>> Le 08/02/2019 à 15:33, Mark Cave-Ayland a écrit : >>>> Commit 8792468da5e1 "powerpc: Add the abili

Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest

On 11/02/2019 00:30, Benjamin Herrenschmidt wrote: > On Fri, 2019-02-08 at 14:51 +0000, Mark Cave-Ayland wrote: >> >> Indeed, but there are still some questions to be asked here: >> >> 1) Why were these bits removed from the original bitmask in the first place >&g

[PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest

these bits to the MSR bitmask to enable MacOS guests to run under 32-bit KVM-PR once again without issue. Signed-off-by: Mark Cave-Ayland --- arch/powerpc/kernel/process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/proce

Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest

On 08/02/2019 14:45, Christophe Leroy wrote: > Le 08/02/2019 à 15:33, Mark Cave-Ayland a écrit : >> Commit 8792468da5e1 "powerpc: Add the ability to save FPU without giving it >> up" > > Expected format for the above is: > > Commit 123456789abc ("text

Re: [PATCH 3/3] of: make default address and size cells sizes private

On 05/09/18 13:12, Rob Herring wrote: > On Tue, Sep 4, 2018 at 11:59 PM Mark Cave-Ayland > wrote: >> >> On 05/09/18 02:55, Frank Rowand wrote: >> >>> On 08/30/18 12:05, Rob Herring wrote: >>>> Only some old OpenFirmware implementations r

Re: [PATCH 3/3] of: make default address and size cells sizes private

On 05/09/18 13:12, Rob Herring wrote: > On Tue, Sep 4, 2018 at 11:59 PM Mark Cave-Ayland > wrote: >> >> On 05/09/18 02:55, Frank Rowand wrote: >> >>> On 08/30/18 12:05, Rob Herring wrote: >>>> Only some old OpenFirmware implementations r

Re: [PATCH 3/3] of: make default address and size cells sizes private

On 05/09/18 02:55, Frank Rowand wrote: > On 08/30/18 12:05, Rob Herring wrote: >> Only some old OpenFirmware implementations rely on default sizes. Any >> FDT and modern implementation should have explicit properties. Make the >> OF_ROOT_NODE_*_CELLS_DEFAULT defines private so we don't get any

Re: [PATCH 3/3] of: make default address and size cells sizes private

On 05/09/18 02:55, Frank Rowand wrote: > On 08/30/18 12:05, Rob Herring wrote: >> Only some old OpenFirmware implementations rely on default sizes. Any >> FDT and modern implementation should have explicit properties. Make the >> OF_ROOT_NODE_*_CELLS_DEFAULT defines private so we don't get any

Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

On 03/07/17 09:55, Gerd Hoffmann wrote: > Hi, > >> Hopefully Gerd has experience using bochs_drm with other non-x86 >> systems >> and can comment further. > > Just pushed to drm-misc-next, fix is correct. bochs video memory is a > pci bar, and the framebuffer is stored there. > > Using sys

Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

On 03/07/17 09:55, Gerd Hoffmann wrote: > Hi, > >> Hopefully Gerd has experience using bochs_drm with other non-x86 >> systems >> and can comment further. > > Just pushed to drm-misc-next, fix is correct. bochs video memory is a > pci bar, and the framebuffer is stored there. > > Using sys

Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

On 03/07/17 09:11, Daniel Vetter wrote: > On Sun, Jul 02, 2017 at 10:52:43PM +0100, Mark Cave-Ayland wrote: >> The current drm_fb_helper_sys helpers referenced in fb_ops assume that the >> video memory is in system RAM. This is not the case for sparc which uses >> dire

Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

On 03/07/17 09:11, Daniel Vetter wrote: > On Sun, Jul 02, 2017 at 10:52:43PM +0100, Mark Cave-Ayland wrote: >> The current drm_fb_helper_sys helpers referenced in fb_ops assume that the >> video memory is in system RAM. This is not the case for sparc which uses >> dire

[PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

the framebuffer. Switching fb_ops over to use the drm_fb_helper_cfb helpers ensures that the correct accesses are used on sparc, fixing the panic and allowing the bochs_drm module to function under qemu-system-sparc64. Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> --- drivers/gpu/drm

[PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

the framebuffer. Switching fb_ops over to use the drm_fb_helper_cfb helpers ensures that the correct accesses are used on sparc, fixing the panic and allowing the bochs_drm module to function under qemu-system-sparc64. Signed-off-by: Mark Cave-Ayland --- drivers/gpu/drm/bochs/bochs_fbdev.c |6 +++--- 1

Panic with bochs_drm module on qemu-system-sparc64

Hi all, I'm one of the QEMU SPARC maintainers and I've been investigating why enabling the fb console via the bochs_drm module causes a panic on startup. The reproducer with QEMU 2.9 is easy: $ ./qemu-system-sparc64 -m 512 -kernel rel-sparc/vmlinux -append 'console=ttyS0' -serial stdio This

Panic with bochs_drm module on qemu-system-sparc64

Hi all, I'm one of the QEMU SPARC maintainers and I've been investigating why enabling the fb console via the bochs_drm module causes a panic on startup. The reproducer with QEMU 2.9 is easy: $ ./qemu-system-sparc64 -m 512 -kernel rel-sparc/vmlinux -append 'console=ttyS0' -serial stdio This

Re: [PATCH] sparc64: sparc64_defconfig: convert to use libata PATA drivers

On 28/06/16 00:18, Julian Calaby wrote: > Hi Alex, > > On Tue, Jun 28, 2016 at 2:38 AM, wrote: >> On 2016-06-27 08:23, Bartlomiej Zolnierkiewicz wrote: >> >>> If you have affected hardware please test. Thank you. >> >> >> For what it's worth, I've been using libata

Re: [PATCH] sparc64: sparc64_defconfig: convert to use libata PATA drivers

On 28/06/16 00:18, Julian Calaby wrote: > Hi Alex, > > On Tue, Jun 28, 2016 at 2:38 AM, wrote: >> On 2016-06-27 08:23, Bartlomiej Zolnierkiewicz wrote: >> >>> If you have affected hardware please test. Thank you. >> >> >> For what it's worth, I've been using libata on sparc64 for roughly two

Re: Question on compiler warning

On 31/12/13 01:24, Larry Finger wrote: In his regular article entitled Build regressions/improvements in v3.13-rc6" (http://lkml.indiana.edu/hypermail/linux/kernel/1312.3/01550.html), Geert Uytterhoeven reports the following warning regression: +

Re: Question on compiler warning

On 31/12/13 01:24, Larry Finger wrote: In his regular article entitled Build regressions/improvements in v3.13-rc6 (http://lkml.indiana.edu/hypermail/linux/kernel/1312.3/01550.html), Geert Uytterhoeven reports the following warning regression: +