Reading the last bytes of memory (sometimes) SErrors
See original GitHub issueThis is a bit of a weird one, but I’m using vanilla m1n1 and can reproduce this at will. Here’s a log that demonstrates what’s going on:
TTY> CPU init... CPU: M1 Icestorm
TTY>
TTY> boot_args at 0x807f38000
TTY> revision: 2
TTY> version: 2
TTY> virt_base: 0xfffffe0007f44000
TTY> phys_base: 0x801f44000
TTY> mem_size: 0x3d7554000
TTY> top_of_kdata: 0x807f3c000
TTY> video:
TTY> base: 0xbdf438000
TTY> display: 0x0
TTY> stride: 0x2800
TTY> width: 2560
TTY> height: 1600
TTY> depth: 65566bpp
TTY> machine_type: 0
TTY> devtree: 0xfffffe00096a0000
TTY> devtree_size: 0x5c000
TTY> cmdline: -v
TTY> boot_flags: 0x0
TTY> mem_size_act: 0x400000000
TTY>
TTY>
TTY>
TTY> m1n1 v7c54aa3-dirty
TTY> Copyright (C) 2021 The Asahi Linux Contributors
TTY> Licensed under the MIT license
TTY>
TTY> Running in EL2
TTY>
TTY> Heap base: 0x807f3c000
TTY> MMU: Initializing...
TTY> MMU: SCTLR_EL1: 30100180 -> 30901085
TTY> MMU: running with MMU and caches enabled!
TTY> fb init: 2560x1600 (30) [s=2560] @0xbdf438000
TTY> fb console: max rows 46, max cols 64
TTY> fb: display logo
TTY> Device info:
TTY> Model: MacBookPro17,1
TTY> Target: J293
TTY> Board-ID: 0x24
TTY> Chip-ID: 0x8103
TTY>
TTY> WDT registers @ 0x23d2b0000
TTY> WDT disabled
TTY> pmgr: initialized, 272 devices found.
TTY> Initialization complete.
TTY> Checking for payloads...
TTY> No more payloads at 0x803854000
TTY> No valid payload found
TTY> i2c: want to read 1 bytes from addr 63 but can only read 0
TTY> usb: tps6598x_powerup failed for /arm-io/i2c0/hpmBusManager/hpm1.
TTY> usb: failed to init hpm1
TTY> USB0: initialized at 0x807f3c030
TTY> USB1: initialized at 0x807f3c440
TTY> Running proxy...
m1n1 base: 0x80375c000
Have fun!
>>> get_bootargs()
0x807f38000
>>> read64(get_bootargs()+16)
0x801f44000
>>> read64(get_bootargs()+24)
0x3d7554000
>>> top_of_mem = 0x801f44000 + 0x3d7554000
>>> readmem(top_of_mem-8, 8)
Traceback (most recent call last):
File "/usr/lib/python3.9/code.py", line 90, in runcode
exec(code, self.locals)
File "<console>", line 1, in <module>
File "/home/pip/metalinux/m1n1/proxyclient/m1n1/proxy.py", line 400, in readmem
raise UartChecksumError(f"Reply data sentinel error: Expected "
m1n1.proxy.UartChecksumError: Reply data sentinel error: Expected 0xb0cacc10, got 0x45cacc10
What happens on the console is an SError with ESR 0xbe000000 and L2C_ERR_ADR 0x300000bd9498000, which is the top_of_mem
address.
(The “65566 bpp” thing and the i2c error are real, too, I’m afraid)
I guess this all makes sense since we did create a “normal” mapping for the poisoned page that starts unavailable “memory”, but I’m not sure how best to fix it. I think what happens is the CPU speculatively prefetches from the mapped-but-inaccessible page. The ringbuffer read code, which is where the SError hits, does look like it would trigger such a prefetch by reading bytes sequentially (which is why it might not be possible to reproduce this using a UART, come to think of it).
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (8 by maintainers)
Is this directly booted from iboot without any other code running before?
Then just keep whatever is required above that mapped as well.