Hi Mark. On Fri, Jul 03, 2020 at 10:25:41PM +0100, Mark Cave-Ayland wrote: > On 03/07/2020 17:08, Mark Cave-Ayland wrote: > > > 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. > > And the winner is: > > $ git bisect bad > 7a0483ac4ffca4998945c159b28afdde8353cc84 is the first bad commit > commit 7a0483ac4ffca4998945c159b28afdde8353cc84 > Author: Gerd Hoffmann <kra...@redhat.com> > Date: Fri Jan 11 06:37:50 2019 +0100 > > drm/bochs: switch to generic drm fbdev emulation > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch> > Link: > http://patchwork.freedesktop.org/patch/msgid/20190111053752.4004-15-kra...@redhat.com > > :040000 040000 1917943277034f620af03ac1a2fa5db48b7b224c > 6d7a3c316a68efbffd398d6c2b7eebefb47bc92d M drivers > > Can I ask you to submit a mail to dri-de...@lists.freedesktop.org where you capture the above info and also a link to the old fix. Whoever did this did not break sparc64 on purpose - and mistakes happens.
If you submit such mail then we can hopefully get this sorted out. If you or someone else can provide a simple HOWTO so one can try out a fix with qemu that would be appreciated. Thanks in advance, Sam