Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #86067 > unrolled thread

Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Aurelien Jarno <aurel32@debian.org> - 2025-02-22 12:10 +0100
    Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-23 22:30 +0100
      Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Aurelien Jarno <aurel32@debian.org> - 2025-02-23 22:50 +0100
        Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-24 20:30 +0100
    Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-24 22:40 +0100
    Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault "Diederik de Haas" <didi.debian@cknow.org> - 2025-02-26 13:20 +0100
    Processed: Re: Bug#1098661: linux: fails to boot on VisionFive 2:  Unhandled exception: Store/AMO access fault "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-02-26 21:50 +0100
    Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault Bastian Blank <waldi@debian.org> - 2025-02-26 21:50 +0100
    Bug#1098661: fixed in linux 6.13.5-1~exp1 Salvatore Bonaccorso <carnil@debian.org> - 2025-02-28 21:20 +0100

#86067 — Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault

Package: src:linux
Version: 6.13.3-1~exp1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-riscv@lists.debian.org

Hi,

Starting with version 6.13.3-1~exp1, the riscv64 kernel is shipped as a
EFI binary with the payload compressed with zstd (using the EFI_ZBOOT
config option). In addition to breaking non-EFI systems, this change
simply prevents the kernel to boot on a VisionFive 2 board:

| Loading Linux 6.13-riscv64 ...
| Loading initial ramdisk ...
| EFI stub: Decompressing Linux Kernel...
| Unhandled exception: Store/AMO access fault
| EPC: 00000000fb64a6ea RA: 00000000fb64a6da TVAL: 0000000040020020
| EPC: 000000003b9046ea RA: 000000003b9046da reloc adjusted
| 
| Code: 0506 9526 4783 0015 4703 0005 3583 ed84 (0e23 fef9)
| UEFI image [0x00000000fe6aa000:0x00000000fe6d0fff] '/efi\boot\bootriscv64.efi'
| UEFI image [0x00000000fb646000:0x00000000fbe933ff] pc=0x46ea
| 
| 
| resetting ...
| reset not supported yet
| ### ERROR ### Please RESET the board ###

Regards
Aurelien


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
Device Tree model: StarFive VisionFive 2 v1.2A

** PCI devices:
0000:00:00.0 PCI bridge [0604]: PLDA XpressRich-AXI Ref Design [1556:1111] (rev 02) (prog-if 00 [Normal decode])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 38
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: 30000000-300fffff [size=1M] [32-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

0000:01:00.0 USB controller [0c03]: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller [1106:3483] (rev 01) (prog-if 30 [XHCI])
	Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller [1106:3483]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 67
	Region 0: Memory at 30000000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

0001:00:00.0 PCI bridge [0604]: PLDA XpressRich-AXI Ref Design [1556:1111] (rev 02) (prog-if 00 [Normal decode])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 53
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: 38000000-380fffff [size=1M] [32-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

0001:01:00.0 Non-Volatile memory controller [0108]: Silicon Motion, Inc. SM2263EN/SM2263XT (DRAM-less) NVMe SSD Controllers [126f:2263] (rev 03) (prog-if 02 [NVM Express])
	Subsystem: Silicon Motion, Inc. SM2263EN/SM2263XT (DRAM-less) NVMe SSD Controllers [126f:2263]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 52
	Region 0: Memory at 38000000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: nvme
	Kernel modules: nvme


** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 0951:1666 Kingston Technology DataTraveler 100 G3/G4/SE9 G2/50 Kyson


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: riscv64

Kernel: Linux 6.13-rc7-riscv64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.13-riscv64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.145
ii  kmod                                    33+20240816-2
ii  linux-base                              4.11

Versions of packages linux-image-6.13-riscv64 recommends:
ii  apparmor  3.1.7-1+b3

Versions of packages linux-image-6.13-riscv64 suggests:
pn  debian-kernel-handbook  <none>
pn  firmware-linux-free     <none>
pn  linux-doc-6.13          <none>

Versions of packages linux-image-6.13-riscv64 is related to:
pn  firmware-amd-graphics      <none>
pn  firmware-atheros           <none>
pn  firmware-bnx2              <none>
pn  firmware-bnx2x             <none>
pn  firmware-brcm80211         <none>
pn  firmware-cavium            <none>
pn  firmware-cirrus            <none>
pn  firmware-intel-graphics    <none>
pn  firmware-intel-misc        <none>
pn  firmware-intel-sound       <none>
pn  firmware-ipw2x00           <none>
pn  firmware-ivtv              <none>
pn  firmware-iwlwifi           <none>
pn  firmware-libertas          <none>
pn  firmware-marvell-prestera  <none>
pn  firmware-mediatek          <none>
pn  firmware-misc-nonfree      <none>
pn  firmware-myricom           <none>
pn  firmware-netronome         <none>
pn  firmware-netxen            <none>
pn  firmware-nvidia-graphics   <none>
pn  firmware-qcom-soc          <none>
pn  firmware-qlogic            <none>
pn  firmware-realtek           <none>
pn  firmware-samsung           <none>
pn  firmware-siano             <none>
pn  firmware-ti-connectivity   <none>
pn  xen-hypervisor             <none>

-- no debconf information

[toc] | [next] | [standalone]

#86105

On Sun, Feb 23, 2025 at 10:07:33PM +0100, Aurelien Jarno wrote:
> On 2025-02-23 21:45, Bastian Blank wrote:
> > On Sat, Feb 22, 2025 at 11:59:38AM +0100, Aurelien Jarno wrote:
> > > Starting with version 6.13.3-1~exp1, the riscv64 kernel is shipped as a
> > > EFI binary with the payload compressed with zstd (using the EFI_ZBOOT
> > > config option). In addition to breaking non-EFI systems, this change
> > > simply prevents the kernel to boot on a VisionFive 2 board:
> > Please re-assign to the bootloader package.
> I disagree. The bootloader is u-boot and while it might be fixable at
> this level, debian should be bootable on the original firmware.

It needs to be fixed nevertheless.  What do you mean with "original
firmware"?  What is this setup anyway?

> BTW, you never explained the reason for your changes. It only brings
> smaller kernel nothing more. And a working kernel is better than a
> smaller kernel that does not work.

Smaller images, so often faster load times.  Feature parity between
architectures.  Fullfils the interface (U)EFI and works fine in edk2.

As I currently try to assemble a list of all the interfaces the kernel
fullfils:  How would you define this?  Running this in u-boot is not
(U)EFI, but something more strict, or there is a bug in the kernel
decompressor.

Bastian

-- 
Immortality consists largely of boredom.
		-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8

[toc] | [prev] | [next] | [standalone]

#86106

On 2025-02-23 22:24, Bastian Blank wrote:
> On Sun, Feb 23, 2025 at 10:07:33PM +0100, Aurelien Jarno wrote:
> > On 2025-02-23 21:45, Bastian Blank wrote:
> > > On Sat, Feb 22, 2025 at 11:59:38AM +0100, Aurelien Jarno wrote:
> > > > Starting with version 6.13.3-1~exp1, the riscv64 kernel is shipped as a
> > > > EFI binary with the payload compressed with zstd (using the EFI_ZBOOT
> > > > config option). In addition to breaking non-EFI systems, this change
> > > > simply prevents the kernel to boot on a VisionFive 2 board:
> > > Please re-assign to the bootloader package.
> > I disagree. The bootloader is u-boot and while it might be fixable at
> > this level, debian should be bootable on the original firmware.
> 
> It needs to be fixed nevertheless.  What do you mean with "original
> firmware"?  What is this setup anyway?

The setup is:
- Vision Five 2 board: https://www.starfivetech.com/en/site/boards
- Using U-Boot as the firmware
- Booting is done through grub (grub-efi-riscv64 package)
- Installed with debian-installer

> > BTW, you never explained the reason for your changes. It only brings
> > smaller kernel nothing more. And a working kernel is better than a
> > smaller kernel that does not work.
> 
> Smaller images, so often faster load times. 

Smaller image is nice, but not mandatory. Other architectures also use
uncompressed kernel.

> Feature parity between
> architectures.  

Feature parity, do you mean only with arm64 and loong64? EFI_ZBOOT is
not enabled on other architectures.

> Fullfils the interface (U)EFI and works fine in edk2.

Just like the kernel before your change.

> As I currently try to assemble a list of all the interfaces the kernel
> fullfils:  How would you define this?  Running this in u-boot is not
> (U)EFI, but something more strict, or there is a bug in the kernel
> decompressor.

The uncompressed kernel is a perfectly valid EFI binary that can be run
under U-Boot with either Distro Boot and Grub or with the loadefi
command. It can also be run under EDK2 either directly or also through
Grub.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

[toc] | [prev] | [next] | [standalone]

#86124

On Sun, Feb 23, 2025 at 10:41:44PM +0100, Aurelien Jarno wrote:
> > As I currently try to assemble a list of all the interfaces the kernel
> > fullfils:  How would you define this?  Running this in u-boot is not
> > (U)EFI, but something more strict, or there is a bug in the kernel
> > decompressor.
> 
> The uncompressed kernel is a perfectly valid EFI binary that can be run
> under U-Boot with either Distro Boot and Grub or with the loadefi
> command. It can also be run under EDK2 either directly or also through
> Grub.

Linux both with zboot and without zboot are valid EFI binary.  But zboot
seems to uncover a bug in u-boot.

So, now we have the options:

- We target EFI, the decompressor is correct, then u-boot is broken.
- We target EFI, the decompressor is invalue, then the kernel is broken.
- We target u-boot restricted EFI, then we have to revert that for all
  three architectures.

What we still can do is workaround this bug.  But this is a defined
state and requires both sides.

Bastian

-- 
Bones: "The man's DEAD, Jim!"

[toc] | [prev] | [next] | [standalone]

#86125

On Sat, Feb 22, 2025 at 11:59:38AM +0100, Aurelien Jarno wrote:
> | Loading Linux 6.13-riscv64 ...
> | Loading initial ramdisk ...
> | EFI stub: Decompressing Linux Kernel...
> | Unhandled exception: Store/AMO access fault
> | EPC: 00000000fb64a6ea RA: 00000000fb64a6da TVAL: 0000000040020020
> | EPC: 000000003b9046ea RA: 000000003b9046da reloc adjusted
> | 
> | Code: 0506 9526 4783 0015 4703 0005 3583 ed84 (0e23 fef9)
> | UEFI image [0x00000000fe6aa000:0x00000000fe6d0fff] '/efi\boot\bootriscv64.efi'
> | UEFI image [0x00000000fb646000:0x00000000fbe933ff] pc=0x46ea

I digged a bit.  Yes, this is the file from
linux-image-6.13-riscv64_6.13.3-1~exp1_riscv64.deb.  It contains the
mentioned instructions:

|     46da:       0506                    slli    a0,a0,0x1
|     46dc:       9526                    add     a0,a0,s1
|     46de:       00154783                lbu     a5,1(a0)
|     46e2:       00054703                lbu     a4,0(a0)
|     46e6:       ed843583                ld      a1,-296(s0)
|     46ea:       fef90e23                sb      a5,-4(s2)

I did not manage to get the crash you mentioned.  The u-boot out of
u-boot-qemu_2024.01+dfsg-7_all.deb can start both the uncompressed EFI
file and the zboot compressed one. Sadly it fails unrelated shortly
after that in both cases.

Using the uncompressed file:

| % qemu-system-riscv64 -m 1024 -nographic -machine virt -device virtio-rng-pci -bios ../qemu-riscv64/u-boot.bin -device loader,file=../../../../boot/plain,addr=0x84000000
| U-Boot 2024.01+dfsg-7 (Jan 09 2025 - 19:14:04 +0000)
| CPU:   rv64imafdch_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_zicntr_zicsr_zifencei_zihintntl_zihintpause_zihpm_zmmul_za64rs_zaamo_zalrsc_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_ssccptr_sscounterenw_sstc_sstvala_sstvecd_svadu_svvptc
| Model: riscv-virtio,qemu
| DRAM:  1 GiB
| Core:  25 devices, 12 uclasses, devicetree: board
| Flash: 32 MiB
| Loading Environment from nowhere... OK
| In:    serial,usbkbd
| Out:   serial,vidconsole
| Err:   serial,vidconsole
| No working controllers found
| Net:   No ethernet found.
[…]
| => bootefi 0x84000000:0x1a61000
| No EFI system partition
| No EFI system partition
| Failed to persist EFI variables
| Booting /MemoryMapped(0x0,0x84000000,0x1a61000)
| EFI stub: Booting Linux Kernel...
| EFI stub: Using DTB from configuration table
| EFI stub: Exiting boot services...
| Unhandled exception: Environment call from M-mode
| EPC: 00000000baa1bd6c RA: 00000000baa1be9c TVAL: 0000000000000000
| EPC: 000000007b2ddd6c RA: 000000007b2dde9c reloc adjusted
| 
| Code: 8562 85de 865a 86d6 8752 87ce 8866 88a6 (0073 0000)
| UEFI image [0x00000000bc488000:0x00000000bdee8fff]

Using the zboot compressed file:

|  % qemu-system-riscv64 -m 1024 -nographic -machine virt -device virtio-rng-pci -bios ../qemu-riscv64/u-boot.bin -device loader,addr=0x84000000,file=../../../../boot/vmlinux-6.13-riscv64
| U-Boot 2024.01+dfsg-7 (Jan 09 2025 - 19:14:04 +0000)
[…]
| => bootefi 0x84000000:0x80d200
| No EFI system partition
| No EFI system partition
| Failed to persist EFI variables
| Booting /MemoryMapped(0x0,0x84000000,0x80d200)
| EFI stub: Decompressing Linux Kernel...
| EFI stub: Using DTB from configuration table
| EFI stub: Exiting boot services...
| Unhandled exception: Environment call from M-mode
| EPC: 000000008001bd6c RA: 000000008001be9c TVAL: 0000000000000000
| EPC: 00000000408ddd6c RA: 00000000408dde9c reloc adjusted
| 
| Code: 8562 85de 865a 86d6 8752 87ce 8866 88a6 (0073 0000)
| UEFI image [0x00000000bd69b000:0x00000000bdee83ff]

The executed code is bogus, but identical both times.  It lives at
different adresses.

Bastian

-- 
Killing is wrong.
		-- Losira, "That Which Survives", stardate unknown

[toc] | [prev] | [next] | [standalone]

#86153

[Multipart message — attachments visible in raw view] — view raw

On Sat Feb 22, 2025 at 11:59 AM CET, Aurelien Jarno wrote:
> Starting with version 6.13.3-1~exp1, the riscv64 kernel is shipped as a
> EFI binary with the payload compressed with zstd (using the EFI_ZBOOT
> config option). In addition to breaking non-EFI systems, this change

Breaks non-EFI systems. Isn't that like 95+% of arm64 boards?

On Mon Feb 24, 2025 at 7:18 PM CET, Aurelien Jarno wrote:
> Let me summarize the situation for external reviewers.
> ...
> I was told ... Debian Installer does not support non-UEFI

Wrong.

> The situation worsened when I realized that the changes do not even work
> on a real riscv64 board installed using the standard Debian installer:

Testing on real hardware seems useful ...

> Sure this has been tested as mentioned in the MR [2], but it appears

The MR indicates it has been tested with QEMU.
Someone said: "arm64 build *looks* good to me" (emphasis mine)

If it was tested on real hardware it would have said so and mentioned
on which hardware. It doesn't, so it's safe to assume it was NOT tested
on real hardware.

> that booting a kernel with QEMU + EDK2 is not comparable to booting a
> kernel with a real board + U-Boot + Grub.

Indeed. You can configure QEMU to have the features you want/need. That
does not mean that all real boards support that.

> At this stage I have not seen a strong arguments for the original
> commit. The reason that have been given a posteriori are:
> - Smaller images, so often faster load times. 

That's due to compression. You can have compression without EFI.

> - Feature parity between architectures.
> - Fullfils the interface (U)EFI and works fine in edk2.

Right. EDK2. This is a joke, right?

Looking at https://github.com/edk2-porting I see the following repos:
- edk2-rk3588 ("EDK2 UEFI firmware for Rockchip RK3588 platforms")
- edk2-msm ("Broken edk2 port for Qualcomm platforms xD")

So there is *partial* support for some rk3588 based devices and broken
support for (some?) Qualcomm based devices. That's it.
Looking at the contributors for edk2-rk3588 I see there are *3* people
with more then 10 commits ... and one indicates he's inactive.
I haven't found any other indication it has some real momentum.

> I don't believe the above reasons are  enough to enforce UEFI only
> kernel and break the boot on existing boards. In addition the "forky

So I *actually* tested it on my Pine64 Quartz64 Model A board (rk3566)
by upgrading Debian's 6.13.2 kernel (which works) to the 6.13.4 kernel.
FWIW/FTR: My Q64-A board has a self-compiled U-Boot 2024.10-rc6.

Aurelien indicated he wanted this bug to be about RISC-V, so I'll just
attach my serial log in case ppl want to see that.

TL;DR: My U-Boot found out that it CAN'T load Debian's 6.13.4 kernel and
tries the next one till it finds one which it can boot ...
which was my 6.13 kernel (without EFI_ZBOOT).

On Sun Feb 23, 2025 at 10:07 PM CET, Aurelien Jarno wrote:
> On 2025-02-23 21:45, Bastian Blank wrote:
>> Please re-assign to the bootloader package.
>
> I disagree. The bootloader is u-boot and while it might be fixable at
> this level, debian should be bootable on the original firmware.

Most people use the bootloader/U-Boot that was shipped with the product
and never update it. I can understand why as the goal of the bootloader
is to boot the device, so when it does that ... why upgrade?

https://bugs.debian.org/1095745 is about broken backward compatibility
and that is a *kernel* bug.

My 0.02

> [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1362

[toc] | [prev] | [next] | [standalone]

#86168 — Processed: Re: Bug#1098661: linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault

Processing control commands:

> clone -1 -2
Bug #1098661 [src:linux] linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault
Bug 1098661 cloned as bug 1098973
> reassign -2 src:grub
Bug #1098973 [src:linux] linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault
Bug reassigned from package 'src:linux' to 'src:grub'.
No longer marked as found in versions linux/6.13.3-1~exp1.
Ignoring request to alter fixed versions of bug #1098973 to the same values previously set
> retitle -2 grub - fails to start zboot linux on risvc64: Unhandled exception: Store/AMO access fault
Bug #1098973 [src:grub] linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault
Changed Bug title to 'grub - fails to start zboot linux on risvc64: Unhandled exception: Store/AMO access fault' from 'linux: fails to boot on VisionFive 2: Unhandled exception: Store/AMO access fault'.
> severity -2 important
Bug #1098973 [src:grub] grub - fails to start zboot linux on risvc64: Unhandled exception: Store/AMO access fault
Severity set to 'important' from 'grave'

-- 
1098661: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098661
1098973: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098973
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#86169

Control: clone -1 -2
Control: reassign -2 src:grub
Control: retitle -2 grub - fails to start zboot linux on risvc64: Unhandled exception: Store/AMO access fault
Control: severity -2 important

On Mon, Feb 24, 2025 at 10:50:58PM +0100, Aurelien Jarno wrote:
> It works fine when the kernel is directly started from U-Boot with
> bootefi. It only fails when U-Boot launches Grub and Grub launches the
> EFI file.

So cloning the bug accordingly to grub.

The kernel team intents to change riscv64 to zboot for forky, so this
bug needs to be identified.

Bastian

-- 
Is truth not truth for all?
		-- Natira, "For the World is Hollow and I have Touched
		   the Sky", stardate 5476.4.

[toc] | [prev] | [next] | [standalone]

#86218 — Bug#1098661: fixed in linux 6.13.5-1~exp1

Hi Josua,

On Fri, Feb 28, 2025 at 01:45:14PM +0000, Josua Mayer wrote:
> Dear Maintainers,
> 
> Thank you for reverting the ZBOOT option.
> I just found this issue while investigating why the 6.13.0 from experimental on the arm64 SolidRun CN9130 based Clearfog Pro board did not boot, when 6.12.12 was perfectly fine:
> 
> In the future please take into account also that arm64 boards can still boot using a boot.scr script generated by flash-kernel package.
> That script uses "booti" command, meaning the kernel image must match the u-boot hard-coded magic:
> 
> #define LINUX_ARM64_IMAGE_MAGIC 0x644d5241
> 
> Otherwise boot will fail:
> 
> Scanning scsi 0:2...
> Found U-Boot script /boot.scr
> 2900 bytes read in 2 ms (1.4 MiB/s)
> ## Executing script at 06d00000
> 10700736 bytes read in 168 ms (60.7 MiB/s)
> 27372 bytes read in 9 ms (2.9 MiB/s)
> 35823093 bytes read in 558 ms (61.2 MiB/s)
> Booting Debian 6.13-arm64 from scsi 0:2...
> Bad Linux ARM64 Image magic!
> 
> I suggest that "flash-kernel" should be updated if zboot is to be enabled again in the future.

Can you please fill a bug aainst frash-kernel as well (as Bastian
cloned this one for grub as well?)

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web