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

[Mark Cave-Ayland]

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 using a 
hme NIC
by default in version 2.11 (see
https://wiki.qemu.org/Documentation/Platforms/SPARC#Changes_to_sun4u_machine_from_2.11_onwards)
which is well over 2 years ago...


ATB,

Mark.

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

[Mark Cave-Ayland]

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 only relevant arguments.  Even dd if=/dev/sda of=/dev/null 
>> bs=64m
>> is often enough to hang it, so I rather doubt that networking (e1000 on pciB,
>> FWIW, with tap for backend) has anything to do with that.
> 
>   FWIW, virtio-blk-pci does appear to be much more resilent; I hadn't been
> able to reproduce hangs on that, while mounting identical fs from pata_cmd64x
> and doing the same aptitude dist-upgrade --download-only ended up with
> 
> ...
> Note: Using 'Download Only' mode, no other actions will be performed.
> Do you want to continue? [Y/n/?] y
> Get: 1 http://ftp.ports.debian.org/debian-ports sid/main sparc64 
> perl-modules-5.30 all 5.30.2-1 [2,806 kB]
> Get: 2 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libperl5.30 
> sparc64 5.30.2-1 [3,388 kB]
> Get: 3 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl sparc64 
> 5.30.2-1 [290 kB]
> Get: 4 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl-base 
> sparc64 5.30.2-1 [1,427 kB]
> Get: 5 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libsystemd0 
> sparc64 245.5-3 [309 kB]
> Get: 6 http://ftp.ports.debian.org/debian-ports sid/main sparc64 udev sparc64 
> 245.5-3 [1,356 kB]
> Get: 7 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libudev1 
> sparc64 245.5-3 [153 kB]
> [ 1472.613660] ata2: lost interrupt (Status 0x58)
> [ 1472.615124] ata1: lost interrupt (Status 0x50)
> [ 1472.615812] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 
> frozen
> [ 1472.616515] ata1.00: failed command: WRITE DMA
> [ 1472.617145] ata1.00: cmd ca/00:60:0c:9b:23/00:00:00:00:00/e0 tag 0 dma 
> 49152 out
> [ 1472.617145]  res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4 
> (timeout)
> [ 1472.618229] ata1.00: status: { DRDY }
> [ 1472.618743] ata1: soft resetting link
> [ 1472.779489] ata1.00: configured for UDMA/33
> [ 1472.781211] ata1: EH complete
> [ 1477.977424] ata2.00: qc timeout (cmd 0xa0)
> [ 1477.977897] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1483.353324] ata2.00: qc timeout (cmd 0xa0)
> [ 1483.353697] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1483.354453] ata2.00: limiting speed to UDMA/33:PIO3
> [ 1488.729323] ata2.00: qc timeout (cmd 0xa0)
> [ 1488.730255] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1488.731320] ata2.00: disabled
> [ 1503.88] ata1: lost interrupt (Status 0x50)

(lots cut)

Well it certainly looks like there's an IRQ going missing somewhere, but glad 
to hear
the virtio-blk-pci is working much better for you. Presumably the 
virtio-net-pci NIC
also works?

> ... at which point I killed the damn thing.  Unpingable, doesn't react to 
> serial
> console (the output is obviously there, the input doesn't reach shell, at the
> very least).  That was on current debian kernel (5.6.0-based), but the 
> mainline
> 5.7-rc1 behaves the same way.  qemu is (yesterday) mainline:
> 
> commit debe78ce14bf8f8940c2bdf3ef387505e9e035a9 (HEAD -> master, 
> origin/master, origin/HEAD)
> Merge: 66706192de 9ecaf5ccec
> Author: Peter Maydell 
> Date:   Fri May 15 19:51:16 2020 +0100
> 
> Merge remote-tracking branch 'remotes/rth/tags/pull-fpu-20200515' into 
> staging
> 
> and anything since bcf9e2c2f2 exhibits that behaviour.  qemu arguments:
> ../qemu1/build/sparc64-softmmu/qemu-system-sparc64 \
> -hda sid.img \
> -drive id=hd,if=none,file=foo.raw,format=raw \
> -device virtio-blk-pci,bus=pciB,drive=hd \
> -netdev tap,ifname=tap4,script=no,downscript=no,id=net \
> -device e1000,bus=pciB,netdev=net \
> -nographic -m 1024
> foo.raw and sid.img have the same contents (sid.img is qcow2 - might or might 
> not
> cause enough timing differences to trigger whatever's happening).
> 
> Looks like something got screwed in PCI interrupt routing in that sun4u 
> branch back in
> 2017.  If you have any suggestions on debugging that, I'd be glad to help; 
> I'm not
> familiar with openbios guts, though ;-/

I've had one other report of a cmd646 hang on Linux several years ago and that 
was on
some pretty high end hardware; however when tracing was enabled everything 
worked as
it should. Despite my best attempts I can't seem to reproduce it here on my 
normal i7
laptop which is quite frustrating.

Before bcf9e2c2f2 the on-board NIC (sunhme) and cmd646 were wired to sabre's 
PCI IRQ
lines directly onto a single PCI bus, and after that commit they were rewired 
via
simba PCI bridges to legacy OBIO IRQs since some OSs like NetBSD hard-coded the
legacy IRQ numbers for on-board devices. I'm not sure whether this is relevant 
to the
kernel or not, or perhaps there is some magic register somewhere missing from
emulation that 

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

[Mark Cave-Ayland]

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 a little recording
>>> https://asciinema.org/a/329510 ).
>>
>> Can you show how you put this environment together and also what
>> compilation tools you used?  Looks great.
> 
> Sorry for the delay. That mail somehow got lost in my inbox.
> 
> So in general, I used qemu-system-sparc64 which is available in Universe
> with either Debian or Ubuntu and that's what I've been using as host
> distro. So you need a 
> 
> deb http://us.archive.ubuntu.com/ubuntu/  universe
> deb-src http://us.archive.ubuntu.com/ubuntu/  universe
> deb http://us.archive.ubuntu.com/ubuntu/ -updates universe
> deb-src http://us.archive.ubuntu.com/ubuntu/ -updates universe
> 
> int /etc/apt/sources.list
> 
> So after this, you should be able to install
> 
> apt install qemu-system-sparc
> 
> Now we need an image and believe it or not there's a guy who lives in
> Berlin too who builds Debian images for all crazy architectures. You can
> download them from:
> 
> https://cdimage.debian.org/cdimage/ports/
> 
> They're built quite frequently. Sometimes you get unlucky because a new
> kernel won't boot anymore then going a couple of months back usually
> helps. So for this experiment I downloaded:
> 
> https://cdimage.debian.org/cdimage/ports/9.0/sparc64/iso-cd/debian-9.0-sparc64-NETINST-1.iso
> 
> then I did:
> 
> cd .local/share/qemu
> truncate -s 15GB sparc64.img
> 
> And then to _install_:
> 
> qemu-system-sparc64 \
> -m 4096 \
>   -device virtio-blk-pci,bus=pciB,drive=hd \
>   -drive 
> file=/home/brauner/Downloads/debian-9.0-sparc64-NETINST-1.iso,format=raw,if=ide,bus=1,unit=0,media=cdrom,readonly=on
>  \
>   -drive 
> file=/home/brauner/.local/share/qemu/sparc64.img,format=raw,if=none,id=hd \
>   -boot order=d \
> -net nic \
>   -net user \
>   -nographic \
> 
> Then the Debian install will run after it finishes you can boot with:
> 
> qemu-system-sparc64 \
>   -name debian-unstable-sparc64 -machine sun4u,accel=tcg,usb=off -m 4096 \
>   -smp 1,sockets=1,cores=1,threads=1 \
>   -uuid ccd8b5c2-b8e4-4d5e-af19-9322cd8e55bf -rtc base=utc -no-reboot 
> -no-shutdown \
>   -boot strict=on \
>   -drive 
> file=/home/brauner/.local/share/qemu/sparc64.img,if=none,id=drive-ide0-0-1,format=raw,cache=none,aio=native
>  \
>   -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-1,id=ide0-0-1 \
>   -msg timestamp=on -nographic
> 
> If the install isn't setting up the repos right and you can't install
> stuff the correct url is:
> http://ftp.ports.debian.org/debian-ports/
> to put into sources.list

FWIW if you're running a more recent version of QEMU (>=3.1) then you can also 
boot
from the virtio-blk-pci device directly instead of having to switch back to the 
IDE
device after installation as you have done above. Should be something like:

qemu-system-sparc64 \
 -m 4096 \
-device virtio-blk-pci,bus=pciB,drive=hd \
-drive
file=/home/brauner/.local/share/qemu/sparc64.img,format=raw,if=none,id=hd,bootindex=0
 \
-net nic \
-net user \
-nographic

Note the removal of the legacy -boot argument and the addition of "bootindex=0" 
to
the -drive argument.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 be asked here:
>>>>
>>>> 1) Why were these bits removed from the original bitmask in the first 
>>>> place without
>>>> it being documented in the commit message?
>>>>
>>>> 2) Is this the right fix? I'm told that MacOS guests already run without 
>>>> this patch
>>>> on a G5 under 64-bit KVM-PR which may suggest that this is a workaround 
>>>> for another
>>>> bug elsewhere in the 32-bit powerpc code.
>>>>
>>>>
>>>> If you think that these points don't matter, then I'm happy to resubmit 
>>>> the patch
>>>> as-is based upon your comments above.
>>>
>>> We should write a test case to verify that FE0/FE1 are properly
>>> preserved/context-switched etc... I bet if we accidentally wiped them,
>>> we wouldn't notice 99.9% of the time.
>>
>> Right I guess it's more likely to cause in issue in the KVM PR case because 
>> the guest
>> can alter the flags in a way that doesn't go through the normal process 
>> switch mechanism.
>>
>> The original patchset at
>> https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg98326.html 
>> does include
>> some tests in the first few patches, but AFAICT they are concerned with the 
>> contents
>> of the FP registers rather than the related MSRs.
> 
> fpu_preempt.c should be able to be adapted to also check the MSR bits.
> 
>> Who is the right person to ask about fixing issues related to context 
>> switching with
>> KVM PR?
> 
> KVM PR doesn't really have a maintainer TBH. Feel like volunteering? :)

Well I only have a 32-bit Mac Mini here which I'm using to help flush out bugs 
in
QEMU's emulation, so I can keep an occasional eye on the 32-bit side of things 
but as
it's a hobby project time is quite limited.

As/when time allows I'd be interested to figure out what MacOS 9 does that 
causes KVM
PR to bail, and if it's possible to run KVM PR on an SMP kernel but certainly 
I'd
need some help from the very knowledgable people on these lists.

>> I did add the original author's email address to my first few emails but have
>> had no response back :/
> 
> Cyril who wrote the original FPU patch has moved on to other things.

Ah okay then.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 ability to save FPU without giving 
>>>> it up"
>>>
>>> Expected format for the above is:
>>>
>>> Commit 123456789abc ("text")
>>
>> Hi Christophe,
>>
>> Apologies - I'm fairly new at submitting kernel patches, but I can re-send 
>> it in the
>> correct format later if required.
>>
>>>> unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to
>>>> update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR 
>>>> MacOS
>>>> guest to lockup and panic the kernel.
> 
> Which kernel is panicking? The guest or the host?

It's the host kernel. As long as you occasionally tap a few keys to keep the 
screen
blanking disabled then you can see the panic on the physical console.

I've uploaded a photo I took during the bisection containing the panic when 
booting
MacOS X 10.2 under qemu-system-ppc to
https://www.ilande.co.uk/tmp/qemu/macmini-kvm.jpg in case you find it useful.

Given that it's really easy to recreate, let me know if you want me to do a git
pull/rebuild and/or if you need any debugging information as it's easy for me to
reproduce.

>>>> Reinstate 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 
>>>
>>> Should include a Fixes: and a Cc to stable ?
>>>
>>> Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving 
>>> it up")
>>> Cc: sta...@vger.kernel.org
>>
>> 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 
>> without
>> it being documented in the commit message?
> 
> It was almost certainly an accident.

Heh, okay :)

>> 2) Is this the right fix? I'm told that MacOS guests already run without 
>> this patch
>> on a G5 under 64-bit KVM-PR which may suggest that this is a workaround for 
>> another
>> bug elsewhere in the 32-bit powerpc code.
> 
> That's slightly worrying. It's hard to say without more detail on why
> the guest is crashing.
> 
> I think your patch looks OK based just on the fact that it restores the
> previous behaviour, so I'll pick it up and pass it through my usual
> testing. If nothing breaks I'll merge it.

That would be great! Does it need a CC to stable too? It would be great if this 
would
get picked up in the next set of Debian ports kernels, for example.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 
>> without
>> it being documented in the commit message?
>>
>> 2) Is this the right fix? I'm told that MacOS guests already run without 
>> this patch
>> on a G5 under 64-bit KVM-PR which may suggest that this is a workaround for 
>> another
>> bug elsewhere in the 32-bit powerpc code.
>>
>>
>> If you think that these points don't matter, then I'm happy to resubmit the 
>> patch
>> as-is based upon your comments above.
> 
> We should write a test case to verify that FE0/FE1 are properly
> preserved/context-switched etc... I bet if we accidentally wiped them,
> we wouldn't notice 99.9% of the time.

Right I guess it's more likely to cause in issue in the KVM PR case because the 
guest
can alter the flags in a way that doesn't go through the normal process switch 
mechanism.

The original patchset at
https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg98326.html does 
include
some tests in the first few patches, but AFAICT they are concerned with the 
contents
of the FP registers rather than the related MSRs.

Who is the right person to ask about fixing issues related to context switching 
with
KVM PR? I did add the original author's email address to my first few emails 
but have
had no response back :/


ATB,

Mark.

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

[Mark Cave-Ayland]

Commit 8792468da5e1 "powerpc: Add the ability to save FPU without giving it up"
unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to
update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR MacOS
guest to lockup and panic the kernel.

Reinstate 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/process.c
index ce393df243aa..71bad4b6f80d 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -176,7 +176,7 @@ static void __giveup_fpu(struct task_struct *tsk)
 
save_fpu(tsk);
msr = tsk->thread.regs->msr;
-   msr &= ~MSR_FP;
+   msr &= ~(MSR_FP|MSR_FE0|MSR_FE1);
 #ifdef CONFIG_VSX
if (cpu_has_feature(CPU_FTR_VSX))
msr &= ~MSR_VSX;
-- 
2.11.0

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

[Mark Cave-Ayland]

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")

Hi Christophe,

Apologies - I'm fairly new at submitting kernel patches, but I can re-send it 
in the
correct format later if required.

>> unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to
>> update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR 
>> MacOS
>> guest to lockup and panic the kernel.
>>
>> Reinstate 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 
> 
> Should include a Fixes: and a Cc to stable ?
> 
> Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it 
> up")
> Cc: sta...@vger.kernel.org

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 
without
it being documented in the commit message?

2) Is this the right fix? I'm told that MacOS guests already run without this 
patch
on a G5 under 64-bit KVM-PR which may suggest that this is a workaround for 
another
bug elsewhere in the 32-bit powerpc code.


If you think that these points don't matter, then I'm happy to resubmit the 
patch
as-is based upon your comments above.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 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 outside
>>>> users.
>>>>
>>>> This also gets us one step closer to removing the asm/prom.h dependency on
>>>> Sparc.
>>
>> Just for the record: you say "any FDT and modern implementation should
>> have explicit properties", however the default values of these
>> properties when missing are clearly defined in the IEEE-1275
>> specification (Annex A):
> 
> The spec may define defaults, but best practice is to be explicit. For
> FDT, dtc doesn't allow defaults (and never has). No arch added in the
> last 10 years has relied on the defaults.
> 
>> "#address-cells"
>> Standard property name to define the package’s address format.
>> ...
>> In a package with a "decode-unit" method, a missing "#address-cells"
>> property signifies that the number of
>> address cells is two.
> 
> So only Sparc is compliant as the default for everyone else is 1.
> 
>> "#size-cells"
>> Standard property name to define the package’s address size format.
>> ...
>> A missing "#size-cells" property signifies the default value of one.
>>
>> I can't speak for FDT but it isn't completely unreasonable for a guest
>> parsing a DT without these properties to assume these default values.
> 
> I'm not removing the defaults. Just not allowing for code outside of
> drivers/of/ to use the defaults.

Got it - if dtc requires explicit properties, then I agree there should
be no issues with this patch. Sorry for the noise.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 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 outside
>>>> users.
>>>>
>>>> This also gets us one step closer to removing the asm/prom.h dependency on
>>>> Sparc.
>>
>> Just for the record: you say "any FDT and modern implementation should
>> have explicit properties", however the default values of these
>> properties when missing are clearly defined in the IEEE-1275
>> specification (Annex A):
> 
> The spec may define defaults, but best practice is to be explicit. For
> FDT, dtc doesn't allow defaults (and never has). No arch added in the
> last 10 years has relied on the defaults.
> 
>> "#address-cells"
>> Standard property name to define the package’s address format.
>> ...
>> In a package with a "decode-unit" method, a missing "#address-cells"
>> property signifies that the number of
>> address cells is two.
> 
> So only Sparc is compliant as the default for everyone else is 1.
> 
>> "#size-cells"
>> Standard property name to define the package’s address size format.
>> ...
>> A missing "#size-cells" property signifies the default value of one.
>>
>> I can't speak for FDT but it isn't completely unreasonable for a guest
>> parsing a DT without these properties to assume these default values.
> 
> I'm not removing the defaults. Just not allowing for code outside of
> drivers/of/ to use the defaults.

Got it - if dtc requires explicit properties, then I agree there should
be no issues with this patch. Sorry for the noise.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 outside
>> users.
>>
>> This also gets us one step closer to removing the asm/prom.h dependency on
>> Sparc.

Just for the record: you say "any FDT and modern implementation should
have explicit properties", however the default values of these
properties when missing are clearly defined in the IEEE-1275
specification (Annex A):

"#address-cells"
Standard property name to define the package’s address format.
...
In a package with a "decode-unit" method, a missing "#address-cells"
property signifies that the number of
address cells is two.

"#size-cells"
Standard property name to define the package’s address size format.
...
A missing "#size-cells" property signifies the default value of one.

I can't speak for FDT but it isn't completely unreasonable for a guest
parsing a DT without these properties to assume these default values.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 outside
>> users.
>>
>> This also gets us one step closer to removing the asm/prom.h dependency on
>> Sparc.

Just for the record: you say "any FDT and modern implementation should
have explicit properties", however the default values of these
properties when missing are clearly defined in the IEEE-1275
specification (Annex A):

"#address-cells"
Standard property name to define the package’s address format.
...
In a package with a "decode-unit" method, a missing "#address-cells"
property signifies that the number of
address cells is two.

"#size-cells"
Standard property name to define the package’s address size format.
...
A missing "#size-cells" property signifies the default value of one.

I can't speak for FDT but it isn't completely unreasonable for a guest
parsing a DT without these properties to assume these default values.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 instead of cfb is probably a leftover from cirrus, where the
> framebuffer actually in a shadow copy in system ram, due to the low
> amout of (pci) video memory.

Great, thanks a lot! Whilst investigating this I noticed that there are
quite a few reports of having to blacklist bochs_drm (particularly on
Xen HVM) so it would be interesting to know if this fix improves things
there too.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 instead of cfb is probably a leftover from cirrus, where the
> framebuffer actually in a shadow copy in system ram, due to the low
> amout of (pci) video memory.

Great, thanks a lot! Whilst investigating this I noticed that there are
quite a few reports of having to blacklist bochs_drm (particularly on
Xen HVM) so it would be interesting to know if this fix improves things
there too.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 
>> direct
>> physical memory accesses for IO memory and causes the bochs_drm module to 
>> panic
>> immediately upon startup as it tries to initialise 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>
> 
> So is this generally true for bochs, or is this now going to broken
> platforms where the bochs framebuffer is in system memory?
> 
> I'm not entirely clear on that from your commit message ...

Here's my original analysis on the problem:
http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04745.html where you
can see the issue is that on sparc you can't just assume that address
returned from ioremap() is a virtual address.

Most of the context for this change comes from commit 68648ed which has
this initial paragraph:


fbdev: add drawing functions for framebuffers in system RAM

The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect)
assume that the framebuffer is in IO memory.  However, we have 3 drivers
(hecubafb, arcfb, and vfb) where the framebuffer is allocated from
system RAM (via vmalloc). Using _raw_read/write and family for these
drivers (as used in the cfb* functions) is illegal, especially in other
platforms.


Given that bochs_drm is a PCI device which supports both memory and IO
accesses then I would think that the above comment about using
_raw_read/write isn't relevant here and this is the correct fix (for
reference I do see that nouveau/radeon/i915 which are also PCI-based are
already using the cfb helper functions).

Hopefully Gerd has experience using bochs_drm with other non-x86 systems
and can comment further.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 
>> direct
>> physical memory accesses for IO memory and causes the bochs_drm module to 
>> panic
>> immediately upon startup as it tries to initialise 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 
> 
> So is this generally true for bochs, or is this now going to broken
> platforms where the bochs framebuffer is in system memory?
> 
> I'm not entirely clear on that from your commit message ...

Here's my original analysis on the problem:
http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04745.html where you
can see the issue is that on sparc you can't just assume that address
returned from ioremap() is a virtual address.

Most of the context for this change comes from commit 68648ed which has
this initial paragraph:


fbdev: add drawing functions for framebuffers in system RAM

The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect)
assume that the framebuffer is in IO memory.  However, we have 3 drivers
(hecubafb, arcfb, and vfb) where the framebuffer is allocated from
system RAM (via vmalloc). Using _raw_read/write and family for these
drivers (as used in the cfb* functions) is illegal, especially in other
platforms.


Given that bochs_drm is a PCI device which supports both memory and IO
accesses then I would think that the above comment about using
_raw_read/write isn't relevant here and this is the correct fix (for
reference I do see that nouveau/radeon/i915 which are also PCI-based are
already using the cfb helper functions).

Hopefully Gerd has experience using bochs_drm with other non-x86 systems
and can comment further.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 direct
physical memory accesses for IO memory and causes the bochs_drm module to panic
immediately upon startup as it tries to initialise 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/bochs/bochs_fbdev.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 932a769..d3a75c2 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -23,9 +23,9 @@ static int bochsfb_mmap(struct fb_info *info,
 static struct fb_ops bochsfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_fillrect = drm_fb_helper_sys_fillrect,
-   .fb_copyarea = drm_fb_helper_sys_copyarea,
-   .fb_imageblit = drm_fb_helper_sys_imageblit,
+   .fb_fillrect = drm_fb_helper_cfb_fillrect,
+   .fb_copyarea = drm_fb_helper_cfb_copyarea,
+   .fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_mmap = bochsfb_mmap,
 };
 
-- 
1.7.10.4

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

[Mark Cave-Ayland]

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 direct
physical memory accesses for IO memory and causes the bochs_drm module to panic
immediately upon startup as it tries to initialise 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 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 932a769..d3a75c2 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -23,9 +23,9 @@ static int bochsfb_mmap(struct fb_info *info,
 static struct fb_ops bochsfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_fillrect = drm_fb_helper_sys_fillrect,
-   .fb_copyarea = drm_fb_helper_sys_copyarea,
-   .fb_imageblit = drm_fb_helper_sys_imageblit,
+   .fb_fillrect = drm_fb_helper_cfb_fillrect,
+   .fb_copyarea = drm_fb_helper_cfb_copyarea,
+   .fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_mmap = bochsfb_mmap,
 };
 
-- 
1.7.10.4

Panic with bochs_drm module on qemu-system-sparc64

[Mark Cave-Ayland]

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 gives the following panic on the serial console:

[   14.759388] [drm] Found bochs VGA, ID 0xb0c5.
[   14.760018] [drm] Framebuffer size 16384 kB @ 0x1ff0100, mmio @
0x1ff0200.
[   14.763370] [TTM] Zone  kernel: Available graphics memory: 252808 kiB
[   14.764240] [TTM] Initializing pool allocator
[   14.894178] Unable to handle kernel paging request at virtual address
01ff0100
[   14.894247] tsk->{mm,active_mm}->context = 
[   14.894308] tsk->{mm,active_mm}->pgd = f8402000
[   14.894372]   \|/  \|/
[   14.894372]   "@'/ .. \`@"
[   14.894372]   /_| \__/ |_\
[   14.894372]  \__U_/
[   14.894435] swapper/0(1): Oops [#1]
[   14.895400] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc7+ #45
[   14.895634] task: f8001c097800 task.stack: f8001c09c000
[   14.895722] TSTATE: 80001607 TPC: 006f3c24 TNPC:
006f3c30 Y: Not tainted
[   14.896697] TPC: 
[   14.896916] g0: 0080 g1: f8001c36 g2:
 g3: 0007
[   14.896976] g4: f8001c097800 g5: f8001ecea000 g6:
f8001c09c000 g7: 0090dfc0
[   14.897036] o0: 0026 o1: 0001 o2:
000f o3: 01ff0100
[   14.897094] o4: 0007 o5: 0008 sp:
f8001c09e0a1 ret_pc: 0001
[   14.897551] RPC: <0x1>
[   14.897715] l0: 0020 l1: 00a43800 l2:
0080 l3: 0001
[   14.897773] l4: 00b93800 l5: 0080 l6:
0030 l7: 
[   14.897830] i0: f8001c32c000 i1: f8001c36 i2:
 i3: 
[   14.897887] i4: 0001 i5: 01ff0100 i6:
f8001c09e151 i7: 007381d4
[   14.897984] I7: 
[   14.898166] Call Trace:
[   14.898442]  [007381d4] drm_fb_helper_sys_imageblit+0x14/0x34
[   14.898561]  [006e6c9c] soft_cursor+0x174/0x19c
[   14.898601]  [006e6744] bit_cursor+0x45c/0x490
[   14.898641]  [006e324c] fbcon_cursor+0x16c/0x17c
[   14.898685]  [00710f60] hide_cursor+0x2c/0xa8
[   14.898724]  [007120fc] redraw_screen+0xc4/0x208
[   14.898765]  [006e2328] fbcon_prepare_logo+0x288/0x358
[   14.898803]  [006e27cc] fbcon_init+0x3d4/0x448
[   14.898844]  [007113e4] visual_init+0xa4/0x100
[   14.898884]  [00712ba0] do_bind_con_driver+0x1c8/0x300
[   14.898925]  [0071304c] do_take_over_console+0x170/0x198
[   14.898965]  [006e28c4] do_fbcon_takeover+0x84/0xe8
[   14.899017]  [004747dc] notifier_call_chain+0x38/0x74
[   14.899061]  [00474a5c] __blocking_notifier_call_chain+0x28/0x44
[   14.899104]  [006ec214] register_framebuffer+0x2b8/0x2ec
[   14.899147]  [007399f0] drm_fb_helper_initial_config+0x2d0/0x36c
[   14.899294] Disabling lock debugging due to kernel taint
[   14.899551] Caller[007381d4]:
drm_fb_helper_sys_imageblit+0x14/0x34
[   14.899656] Caller[006e6c9c]: soft_cursor+0x174/0x19c
[   14.899696] Caller[006e6744]: bit_cursor+0x45c/0x490
[   14.899735] Caller[006e324c]: fbcon_cursor+0x16c/0x17c
[   14.899774] Caller[00710f60]: hide_cursor+0x2c/0xa8
[   14.899812] Caller[007120fc]: redraw_screen+0xc4/0x208
[   14.899852] Caller[006e2328]: fbcon_prepare_logo+0x288/0x358
[   14.899891] Caller[006e27cc]: fbcon_init+0x3d4/0x448
[   14.899930] Caller[007113e4]: visual_init+0xa4/0x100
[   14.899970] Caller[00712ba0]: do_bind_con_driver+0x1c8/0x300
[   14.900018] Caller[0071304c]: do_take_over_console+0x170/0x198
[   14.900061] Caller[006e28c4]: do_fbcon_takeover+0x84/0xe8
[   14.900132] Caller[004747dc]: notifier_call_chain+0x38/0x74
[   14.900218] Caller[00474a5c]:
__blocking_notifier_call_chain+0x28/0x44
[   14.900263] Caller[006ec214]: register_framebuffer+0x2b8/0x2ec
[   14.900306] Caller[007399f0]:
drm_fb_helper_initial_config+0x2d0/0x36c
[   14.900351] Caller[00761e60]: bochs_fbdev_init+0x6c/0xb0
[   14.900389] Caller[00760b2c]: bochs_load+0x84/0xa8
[   14.900439] Caller[00741c88]: drm_dev_register+0x114/0x1e8
[   14.900628] Caller[00742a10]: drm_get_pci_dev+0xa8/0x118
[   14.900672] Caller[006c8364]: pci_device_probe+0x70/0xdc
[   14.900713] Caller[00768cf0]: driver_probe_device+0x148/0x2a4
[   14.900752] Caller[00768ec4]: __driver_attach+0x78/0xa8
[   14.900790] Caller[007674ec]: bus_for_each_dev+0x58/0x7c
[   

Panic with bochs_drm module on qemu-system-sparc64

[Mark Cave-Ayland]

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 gives the following panic on the serial console:

[   14.759388] [drm] Found bochs VGA, ID 0xb0c5.
[   14.760018] [drm] Framebuffer size 16384 kB @ 0x1ff0100, mmio @
0x1ff0200.
[   14.763370] [TTM] Zone  kernel: Available graphics memory: 252808 kiB
[   14.764240] [TTM] Initializing pool allocator
[   14.894178] Unable to handle kernel paging request at virtual address
01ff0100
[   14.894247] tsk->{mm,active_mm}->context = 
[   14.894308] tsk->{mm,active_mm}->pgd = f8402000
[   14.894372]   \|/  \|/
[   14.894372]   "@'/ .. \`@"
[   14.894372]   /_| \__/ |_\
[   14.894372]  \__U_/
[   14.894435] swapper/0(1): Oops [#1]
[   14.895400] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc7+ #45
[   14.895634] task: f8001c097800 task.stack: f8001c09c000
[   14.895722] TSTATE: 80001607 TPC: 006f3c24 TNPC:
006f3c30 Y: Not tainted
[   14.896697] TPC: 
[   14.896916] g0: 0080 g1: f8001c36 g2:
 g3: 0007
[   14.896976] g4: f8001c097800 g5: f8001ecea000 g6:
f8001c09c000 g7: 0090dfc0
[   14.897036] o0: 0026 o1: 0001 o2:
000f o3: 01ff0100
[   14.897094] o4: 0007 o5: 0008 sp:
f8001c09e0a1 ret_pc: 0001
[   14.897551] RPC: <0x1>
[   14.897715] l0: 0020 l1: 00a43800 l2:
0080 l3: 0001
[   14.897773] l4: 00b93800 l5: 0080 l6:
0030 l7: 
[   14.897830] i0: f8001c32c000 i1: f8001c36 i2:
 i3: 
[   14.897887] i4: 0001 i5: 01ff0100 i6:
f8001c09e151 i7: 007381d4
[   14.897984] I7: 
[   14.898166] Call Trace:
[   14.898442]  [007381d4] drm_fb_helper_sys_imageblit+0x14/0x34
[   14.898561]  [006e6c9c] soft_cursor+0x174/0x19c
[   14.898601]  [006e6744] bit_cursor+0x45c/0x490
[   14.898641]  [006e324c] fbcon_cursor+0x16c/0x17c
[   14.898685]  [00710f60] hide_cursor+0x2c/0xa8
[   14.898724]  [007120fc] redraw_screen+0xc4/0x208
[   14.898765]  [006e2328] fbcon_prepare_logo+0x288/0x358
[   14.898803]  [006e27cc] fbcon_init+0x3d4/0x448
[   14.898844]  [007113e4] visual_init+0xa4/0x100
[   14.898884]  [00712ba0] do_bind_con_driver+0x1c8/0x300
[   14.898925]  [0071304c] do_take_over_console+0x170/0x198
[   14.898965]  [006e28c4] do_fbcon_takeover+0x84/0xe8
[   14.899017]  [004747dc] notifier_call_chain+0x38/0x74
[   14.899061]  [00474a5c] __blocking_notifier_call_chain+0x28/0x44
[   14.899104]  [006ec214] register_framebuffer+0x2b8/0x2ec
[   14.899147]  [007399f0] drm_fb_helper_initial_config+0x2d0/0x36c
[   14.899294] Disabling lock debugging due to kernel taint
[   14.899551] Caller[007381d4]:
drm_fb_helper_sys_imageblit+0x14/0x34
[   14.899656] Caller[006e6c9c]: soft_cursor+0x174/0x19c
[   14.899696] Caller[006e6744]: bit_cursor+0x45c/0x490
[   14.899735] Caller[006e324c]: fbcon_cursor+0x16c/0x17c
[   14.899774] Caller[00710f60]: hide_cursor+0x2c/0xa8
[   14.899812] Caller[007120fc]: redraw_screen+0xc4/0x208
[   14.899852] Caller[006e2328]: fbcon_prepare_logo+0x288/0x358
[   14.899891] Caller[006e27cc]: fbcon_init+0x3d4/0x448
[   14.899930] Caller[007113e4]: visual_init+0xa4/0x100
[   14.899970] Caller[00712ba0]: do_bind_con_driver+0x1c8/0x300
[   14.900018] Caller[0071304c]: do_take_over_console+0x170/0x198
[   14.900061] Caller[006e28c4]: do_fbcon_takeover+0x84/0xe8
[   14.900132] Caller[004747dc]: notifier_call_chain+0x38/0x74
[   14.900218] Caller[00474a5c]:
__blocking_notifier_call_chain+0x28/0x44
[   14.900263] Caller[006ec214]: register_framebuffer+0x2b8/0x2ec
[   14.900306] Caller[007399f0]:
drm_fb_helper_initial_config+0x2d0/0x36c
[   14.900351] Caller[00761e60]: bochs_fbdev_init+0x6c/0xb0
[   14.900389] Caller[00760b2c]: bochs_load+0x84/0xa8
[   14.900439] Caller[00741c88]: drm_dev_register+0x114/0x1e8
[   14.900628] Caller[00742a10]: drm_get_pci_dev+0xa8/0x118
[   14.900672] Caller[006c8364]: pci_device_probe+0x70/0xdc
[   14.900713] Caller[00768cf0]: driver_probe_device+0x148/0x2a4
[   14.900752] Caller[00768ec4]: __driver_attach+0x78/0xa8
[   14.900790] Caller[007674ec]: bus_for_each_dev+0x58/0x7c
[   14.900830] Caller[007683bc]: bus_add_driver+0xd0/0x1fc
[   

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

[Mark Cave-Ayland]

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 years
>> with no issues to report. All of my PATA machines have ALI controllers, not
>> sure if any other controllers were ever used in sparc gear.
> 
> The Ultra 5 uses a CMD64x controller.
> 
> That said, last time I tried to get that machine working, I couldn't
> partition the disk due to bugs in that driver.
> 
> I believe the Ultra 10 uses the same motherboard so it's likely also
> affected. I believe these were in the first generation of "PC" like
> SPARC workstations.

FWIW QEMU's qemu-system-sparc64 emulator also uses the cmd646 controller
and can boot vmlinuz/initrd binaries directly for testing.


ATB,

Mark.

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

[Mark Cave-Ayland]

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 years
>> with no issues to report. All of my PATA machines have ALI controllers, not
>> sure if any other controllers were ever used in sparc gear.
> 
> The Ultra 5 uses a CMD64x controller.
> 
> That said, last time I tried to get that machine working, I couldn't
> partition the disk due to bugs in that driver.
> 
> I believe the Ultra 10 uses the same motherboard so it's likely also
> affected. I believe these were in the first generation of "PC" like
> SPARC workstations.

FWIW QEMU's qemu-system-sparc64 emulator also uses the cmd646 controller
and can boot vmlinuz/initrd binaries directly for testing.


ATB,

Mark.

Re: Question on compiler warning

[Mark Cave-Ayland]

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:

+ /scratch/kisskb/src/drivers/net/wireless/b43/phy_n.c: warning:
'val_addr' may be used uninitialized in this function [-Wuninitialized]:
=> 178:21

This warning does not show up on any of my compilers, and it should not
as the initialization and usage of that variable both take place in
conditional branches that are testing exactly the same pointer.


Hi Larry,

Could it be that you don't see the issue the locally because you've got 
different compiler optimisation settings? I've seen a similar bug 
recently on another project where the "may be used uninitialized" 
warning appears with -O0 and -O1 but magically disappears with the 
default -O2 setting (presumably because the optimiser performs some kind 
of inlining/reordering that makes the issue go away).



HTH,

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Question on compiler warning

[Mark Cave-Ayland]

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:

+ /scratch/kisskb/src/drivers/net/wireless/b43/phy_n.c: warning:
'val_addr' may be used uninitialized in this function [-Wuninitialized]:
= 178:21

This warning does not show up on any of my compilers, and it should not
as the initialization and usage of that variable both take place in
conditional branches that are testing exactly the same pointer.


Hi Larry,

Could it be that you don't see the issue the locally because you've got 
different compiler optimisation settings? I've seen a similar bug 
recently on another project where the may be used uninitialized 
warning appears with -O0 and -O1 but magically disappears with the 
default -O2 setting (presumably because the optimiser performs some kind 
of inlining/reordering that makes the issue go away).



HTH,

Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/