Linux SH kernel currently broken on qemu-system

Linux SH kernel currently broken on qemu-system

[John Paul Adrian Glaubitz]

Hi!

Booting the Linux SH kernel in qemu-system currently doesn't work, the screen
just stays black. Previously, the kernel suffered another regression where it
booted but crashed very early.

The first regression came with the following commit:

205e1b7f51e4af2643eb1d61a6503e415cd1e014 is the first bad commit
commit 205e1b7f51e4af2643eb1d61a6503e415cd1e014
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Dec 22 14:50:47 2017 +0100

    dma-mapping: warn when there is no coherent_dma_mask
    
    These days all devices should have a DMA coherent mask, and most dma_ops
    implementations rely on that fact.  But just to be sure add an assert to
    ring the warning bell if that is not the case.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

:040000 040000 e0c021952944b917e5055be573140b11fc02134d aa01f012af1cad3af647b04aa12ee701ac0e1f6e M      include

I haven't found the commit yet which caused the second regression but Michael
Karcher (CC'ed) has found out that the kernel already crashing while trying
to decompress the compressed zImage.

To test, I used the current debian-installer netboot image for sh4 which
I built and uploaded at [1].

I'm booting with:

$ qemu-system-sh4 -M r2d -kernel installer-sh4/current/images/sh7751r/netboot/vmlinuz-4.19.0-5-sh7751r \
  -initrd installer-sh4/current/images/sh7751r/netboot/initrd.gz -hda debian.qcow \
  -append "root=/dev/sda1 console=tty0"

The qcow image was created with:

$ qemu-img create -f qcow2 debian.qcow 10G

Adrian

> [1] https://cdimage.debian.org/cdimage/ports/debian-installer/sh4/debian-installer-images_20190411_sh4.tar.gz

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Linux SH kernel currently broken on qemu-system

[John Paul Adrian Glaubitz]

Hi!

On 6/10/19 3:36 PM, John Paul Adrian Glaubitz wrote:
> Booting the Linux SH kernel in qemu-system currently doesn't work, the screen
> just stays black. Previously, the kernel suffered another regression where it
> booted but crashed very early.
Michael Karcher found out that the second issue is that the kernel is too big and
overwrites the decompression code while being uncompressed.

Raising the the value for CONFIG_BOOT_LINK_OFFSET fixes the problem and lets the
kernel boot but we still have the problem that qemu probably needs to be adjusted
in order to accommodate for the larger kernel, see [1].

Any suggestions how to resolve this problem?

Adrian

> [1] https://github.com/qemu/qemu/blob/master/hw/sh4/r2d.c#L55

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Linux SH kernel currently broken on qemu-system

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On 6/10/19 8:36 AM, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> Booting the Linux SH kernel in qemu-system currently doesn't work, the screen
> just stays black. Previously, the kernel suffered another regression where it
> booted but crashed very early.

I booted 5.1 to a shell prompt when it came out and you're pointing at a commit
from 2017? Sigh, let's see...

Nope, I just built current git -master (commit e01e060fe00d) and it booted just
fine. (Well, the stupid ___slab_alloc.constprop stack dump it's been doing
forever but I've complained about that here before. I get the shell prompt anyway.)

Could you attach your .config? Here's the one I built, and how I'm launching it.

Hmmm... I checked my notes on the sh7760 hardware and the newest kernel I ran on
that (with dma working, memory to memory with dmaengine and the dmatest plumbing
passed) 4.14, which is just older than  your commit. (But I didn't stop moving
the version forward because of a DMA issue, I stopped because jffs2 on the NOR
flash went flaky in a way that took 10 minutes of hammering to reliably
reproduce and was thus a pain to bisect, and we had a ship deadline, so I stayed
with the last stable one which was less than a year old at the time...)

Rob

[-- Attachment #2: qemu-sh4.sh --]
[-- Type: application/x-shellscript, Size: 190 bytes --]

[-- Attachment #3: sh4.miniconf --]
[-- Type: text/plain, Size: 1260 bytes --]

# make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=sh4.miniconf
# make ARCH=sh -j $(nproc)
# boot arch/sh/boot/zImage


CONFIG_CPU_SUBTYPE_SH7751R=y
CONFIG_MMU=y
CONFIG_MEMORY_START=0x0c000000
CONFIG_VSYSCALL=y
CONFIG_SH_FPU=y
CONFIG_SH_RTS7751R2D=y
CONFIG_RTS7751R2D_PLUS=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_CONSOLE=y

CONFIG_PCI=y
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=y

CONFIG_PCI=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_PATA_PLATFORM=y

#CONFIG_SPI=y
#CONFIG_SPI_SH_SCI=y
#CONFIG_MFD_SM501=y

#CONFIG_RTC_CLASS=y
#CONFIG_RTC_DRV_R9701=y
#CONFIG_RTC_DRV_SH=y
#CONFIG_RTC_HCTOSYS=y


# CONFIG_EMBEDDED is not set
CONFIG_EARLY_PRINTK=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y

CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y

CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
#CONFIG_NET_CORE=y
#CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y

Re: Linux SH kernel currently broken on qemu-system

[John Paul Adrian Glaubitz]

On 6/16/19 11:38 AM, Rob Landley wrote:
> I booted 5.1 to a shell prompt when it came out and you're pointing at a commit
> from 2017? Sigh, let's see...
> 
> Nope, I just built current git -master (commit e01e060fe00d) and it booted just
> fine. (Well, the stupid ___slab_alloc.constprop stack dump it's been doing
> forever but I've complained about that here before. I get the shell prompt anyway.)

This has already been tracked down. It's kprobes that's broken [1] 

> Could you attach your .config? Here's the one I built, and how I'm launching it.

You need to enable kernel probes which are enabled in Debian by default.

> Hmmm... I checked my notes on the sh7760 hardware and the newest kernel I ran on
> that (with dma working, memory to memory with dmaengine and the dmatest plumbing
> passed) 4.14, which is just older than  your commit. (But I didn't stop moving
> the version forward because of a DMA issue, I stopped because jffs2 on the NOR
> flash went flaky in a way that took 10 minutes of hammering to reliably
> reproduce and was thus a pain to bisect, and we had a ship deadline, so I stayed
> with the last stable one which was less than a year old at the time...)

The second issue we had was with the resulting kernel being larger than 8 MiB
which is not supported by QEMU. So, we have to move drivers out of the kernel
into modules.

Adrian

> [1] https://marc.info/?l=linux-sh&m\x156034655921917&w=2

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913