Re: qemu-system-sparc64 not booting install of debian sparc64
- To: Connor McLaughlan <cont6pro3@gmail.com>
- Cc: Adrian Davey <adrian@beth2.org>, debian-sparc@lists.debian.org
- Subject: Re: qemu-system-sparc64 not booting install of debian sparc64
- From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
- Date: Fri, 3 Jul 2020 17:08:54 +0100
- Message-id: <[🔎] a2a716aa-2d76-d97e-04b4-7b591f3c18ae@ilande.co.uk>
- In-reply-to: <CABo1Du6gQyQ38EzyP86DFgSeCtzyHe_tjJ9uqv2eK8dskSzddQ@mail.gmail.com>
- References: <CABo1Du6jJXJPUuWQoShHwzBEJZSqYZCUw2y=1r0KVYwborM_Dg@mail.gmail.com> <6afae93f-1b50-440e-6ae5-e036a0f1aaa0@physik.fu-berlin.de> <CABo1Du5eNBpstw7+ypYbkM0MU=T_KDaB4c8yeAsD401g3LtjJQ@mail.gmail.com> <396bcc61-a70e-cbe1-6d70-d6952d472d59@physik.fu-berlin.de> <CABo1Du5y4xBKHcvO6319cyT=o5CTFxXE18ZKt52Tqs8i5sj-5w@mail.gmail.com> <9afb08f9c70fb1b2c6fd1d7013713205@beth2.org> <CABo1Du4Ld+QxTsQ=rZUsSzPd25BUsbzKCdnFSed3ZhH52cKOkw@mail.gmail.com> <120dc2c6-0884-6ffe-1c16-e5ce173bbb11@ilande.co.uk> <CABo1Du6gQyQ38EzyP86DFgSeCtzyHe_tjJ9uqv2eK8dskSzddQ@mail.gmail.com>
On 30/06/2020 16:56, Connor McLaughlan wrote:
> For setting it up I used the current iso
> debian-10.0.0-sparc64-NETINST-1.iso with standard parameters in qemu
> -nographic mode.
>
> I had two problems:
>
> - System was not booting beyond grub
> - Qemu crashed at bochs_drm
>
> The iso seems to use kernel 5.6.0-2
> During installation the kernel gets updated to 5.7.0-1 Debian 5.7.6-1
> (2020-06-24)
I just built latest git master to test this, and sure enough it has been broken again:
[ 9.007161] [drm] Found bochs VGA, ID 0xb0c5.
[ 9.007840] [drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @ 0x1ff23000000.
[ 9.012567] [TTM] Zone kernel: Available graphics memory: 51496 KiB
[ 9.013551] [TTM] Initializing pool allocator
[ 9.032757] [drm] Found EDID data blob.
[ 9.061904] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:01:02.0 on minor 0
[ 9.336819] Unable to handle kernel paging request at virtual address 000001ff221d0000
[ 9.337177] tsk->{mm,active_mm}->context = 0000000000000000
[ 9.337283] tsk->{mm,active_mm}->pgd = fffff80000402000
[ 9.337372] \|/ ____ \|/
[ 9.337372] "@'/ .. \`@"
[ 9.337372] /_| \__/ |_\
[ 9.337372] \__U_/
[ 9.337468] kworker/0:0(5): Oops [#1]
[ 9.339359] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.8.0-rc3+ #55
[ 9.341360] Workqueue: events drm_fb_helper_dirty_work
[ 9.341775] TSTATE: 0000000080001605 TPC: 000000000077441c TNPC: 0000000000774420
Y: 00000000 Not tainted
[ 9.341894] TPC: <memcpy+0x121c/0x13c0>
[ 9.342015] g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000000000 g3:
fffff800043d2c00
[ 9.342094] g4: fffff8000410eac0 g5: fffff800064cc000 g6: fffff80004124000 g7:
0000000000000010
[ 9.342173] o0: 000001ff221d0000 o1: 0000000100220000 o2: 0000000000000000 o3:
000001fe21fb0000
[ 9.342254] o4: 000001ff221d0000 o5: 0000000000000000 sp: fffff800041273d1 ret_pc:
0000000000805b18
[ 9.342325] RPC: <drm_fb_helper_dirty_work+0xf8/0x180>
[ 9.342591] l0: fffff80007819cc0 l1: fffff800043df8cc l2: 0000000001356200 l3:
fffff800064cc000
[ 9.342670] l4: fffff80004004200 l5: 0000000000000000 l6: 0000000000000025 l7:
fffff80004002500
[ 9.342750] i0: fffff800043df8d0 i1: fffff800040106b0 i2: 0000000000000020 i3:
fffff800043e5500
[ 9.342829] i4: 00000000000001d1 i5: 0000000100220000 i6: fffff80004127491 i7:
0000000000481fec
[ 9.342960] I7: <process_one_work+0x18c/0x540>
[ 9.343308] Call Trace:
[ 9.344077] [<0000000000481fec>] process_one_work+0x18c/0x540
[ 9.344267] [<00000000004824c4>] worker_thread+0x124/0x580
[ 9.344310] [<0000000000489758>] kthread+0xf8/0x120
[ 9.344357] [<00000000004060a4>] ret_from_fork+0x1c/0x2c
[ 9.344714] [<0000000000000000>] 0x0
[ 9.344982] Disabling lock debugging due to kernel taint
[ 9.345454] Caller[0000000000481fec]: process_one_work+0x18c/0x540
[ 9.345661] Caller[00000000004824c4]: worker_thread+0x124/0x580
[ 9.345702] Caller[0000000000489758]: kthread+0xf8/0x120
[ 9.345743] Caller[00000000004060a4]: ret_from_fork+0x1c/0x2c
[ 9.345779] Caller[0000000000000000]: 0x0
[ 9.345909] Instruction DUMP:
[ 9.346012] da5a6000
[ 9.346170] c25a6008
[ 9.346188] 8ea1e010
[ 9.346205] <da72400b>
[ 9.346221] 92026008
[ 9.346238] c272400b
[ 9.346254] 186ffffa
[ 9.346271] 92026008
[ 9.346287] 808aa008
[ 9.346429]
[ 9.397204] Console: switching to colour frame buffer device 128x48
[ 10.010529] bochs-drm 0000:01:02.0: fb0: bochs-drmdrmfb frame buffer device
It looks to be similar to the previous bug I fixed: someone has again assumed that
they can access the framebuffer directly using a virtual address rather than using an
IO function that uses the appropriate ASI_PHYS access on SPARC.
A quick glance at git blame points towards a couple of commits that are likely to
have caused this - I'll see if I can pin it down exactly and see if I can figure out
with upstream how to get it working again.
ATB,
Mark.
Reply to: