On Tue, Jun 30, 2020 at 3:53 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

Might be a partioning issue as it seems GRUB works fine when booting
from CD, doesn't it?

In any case, it should be possible to boot kernel and initrd of the
installed system directly using QEMU, bypassing GRUB.

Can you please tell me how would i execute this bypassing of GRUB?

I am using a standard partioning scheme with three partitions:

1. /boot ext2 500mb (default size)
2. / ext4 60GB
3. swap 4GB


Regards,
Connor

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

i am trying to run debian sparc64 on qemu to have another possibility
to test, run and compile stuff.
However i can not get the recent iso to create a running debian
installation on qemu.

I am using an x86_64 machine with debian buster.
Qemu version is:
EMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u5) Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

I am doing pretty standard stuff, that works for other systems:

First, i create an image file:
qemu-img create -f qcow2 debian-sparc64.qcow2 60G

Then i run qemu with the debian iso to boot, partition and install debian: qemu-system-sparc64 -nographic -m 4G -hda ./debian-sparc64.qcow2
-cdrom ./debian-10.0.0-sparc64-NETINST-1.iso

This works how it should right to the end, at which the first strange
thing happens:

The system is going down NOW!
Sent SIGTERM to all processes ? [16300.898259] twice on console to
return to the boot prom [16300.899563] ---[ end Kernel panic - not
syncing: Reboot failed! ]---

But as this is right at the end, i think it should be ok.

Then when i try to boot the freshly installed system, grub comes up
and tries to boot which leads directly to this exception:
error: canonicalise devname failed.
Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd0f16c NPC = 0x00000000ffd0f170 Stopping execution

Also within the grub console i am unable to execute "ls" to list
attached drives:

grub> ls
Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd0f16c NPC = 0x00000000ffd0f170 Stopping execution


Has anyone actually got it running and some idea what is wrong?

Regards,
Connor

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/30/20 3:37 PM, Connor McLaughlan wrote:

Then when i try to boot the freshly installed system, grub comes up
and tries to boot which leads directly to this exception:
error: canonicalise devname failed.
Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd0f16c NPC = 0x00000000ffd0f170 Stopping execution

Also within the grub console i am unable to execute "ls" to list
attached drives:

grub> ls
Unhandled Exception 0x0000000000000030 PC = 0x00000000ffd0f16c NPC = 0x00000000ffd0f170 Stopping execution

Might be a partioning issue as it seems GRUB works fine when booting
from CD, doesn't it?

In any case, it should be possible to boot kernel and initrd of the
installed system directly using QEMU, bypassing GRUB.

Adrian

--
.''`. 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jun 30, 2020 at 4:10 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

You can specify both kernel and initrd on the command line using "-kernel" and "-initrd" respectively. You just need to extract them from the virtual machine disk image.

Adria

Hi Adrian,

i am almost up and running, i provided -initrd, -kernel and -append root.

Booting up looks good. Also systemd is coming up.

Now it crashes after some VGA init:

[ 84.672537] [drm] Found bochs VGA, ID 0xb0c5.
[ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @ 0x1ff23000000.
[ 84.711815] [TTM] Zone kernel: Available graphics memory: 2067220 KiB
[ 84.712821] [TTM] Initializing pool allocator
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
pc: 0000000000405618 npc: 000000000040561c
...
pstate: 00000015 ccr: 00 (icc: ---- xcc: ----) asi: 11 tl: 5 pil: 0
gl: 2 tbr: 0000000000420000 hpstate: 0000000000000000 htba:
0000000000000000 cansave: 5 canrestore: 1 otherwin: 0 wstate: 8
cleanwin: 7 cwp: 7 fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 Aborted

I guess i will have to try some framebuffer kernel settings and stuff.

Regards,
Connor

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Connor!

On 6/30/20 4:07 PM, Connor McLaughlan wrote:

On Tue, Jun 30, 2020 at 3:53 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

Might be a partioning issue as it seems GRUB works fine when booting
from CD, doesn't it?

In any case, it should be possible to boot kernel and initrd of the
installed system directly using QEMU, bypassing GRUB.

Can you please tell me how would i execute this bypassing of GRUB?

I am using a standard partioning scheme with three partitions:

1. /boot ext2 500mb (default size)
2. / ext4 60GB
3. swap 4GB

You can specify both kernel and initrd on the command line using "-kernel"
and "-initrd" respectively. You just need to extract them from the virtual machine disk image.

Adria

--
.''`. 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2020-06-30 15:30, Connor McLaughlan wrote:

On Tue, Jun 30, 2020 at 4:10 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

You can specify both kernel and initrd on the command line using
"-kernel"
and "-initrd" respectively. You just need to extract them from the
virtual
machine disk image.

Adria

Hi Adrian,

i am almost up and running, i provided -initrd, -kernel and -append
root.

Booting up looks good. Also systemd is coming up.

Now it crashes after some VGA init:

[ 84.672537] [drm] Found bochs VGA, ID 0xb0c5.
[ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @ 0x1ff23000000.
[ 84.711815] [TTM] Zone kernel: Available graphics memory: 2067220 KiB
[ 84.712821] [TTM] Initializing pool allocator
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
pc: 0000000000405618 npc: 000000000040561c
...
pstate: 00000015 ccr: 00 (icc: ---- xcc: ----) asi: 11 tl: 5 pil: 0
gl: 2 tbr: 0000000000420000 hpstate: 0000000000000000 htba:
0000000000000000 cansave: 5 canrestore: 1 otherwin: 0 wstate: 8
cleanwin: 7 cwp: 7 fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 Aborted

I guess i will have to try some framebuffer kernel settings and stuff.

Regards,
Connor

Hi Connor,

Taken from https://wiki.debian.org/Sparc64Qemu

Create/edit /etc/modprobe.d/drm-blacklist.conf

# blacklist of DRM modules that do not load on qemu-system-sparc64 sun4u blacklist drm
blacklist bochs-drm
blacklist ttm


May help you here.

Cheers,

Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jun 30, 2020 at 5:43 PM Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:

On 30/06/2020 16:13, Connor McLaughlan wrote:

On Tue, Jun 30, 2020 at 5:07 PM Adrian Davey <adrian@beth2.org> wrote:

Now it crashes after some VGA init:

[ 84.672537] [drm] Found bochs VGA, ID 0xb0c5.
[ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @
0x1ff23000000.
[ 84.711815] [TTM] Zone kernel: Available graphics memory: 2067220 KiB >>> [ 84.712821] [TTM] Initializing pool allocator
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state >>> pc: 0000000000405618 npc: 000000000040561c
...
pstate: 00000015 ccr: 00 (icc: ---- xcc: ----) asi: 11 tl: 5 pil: 0
gl: 2 tbr: 0000000000420000 hpstate: 0000000000000000 htba:
0000000000000000 cansave: 5 canrestore: 1 otherwin: 0 wstate: 8
cleanwin: 7 cwp: 7 fsr: 0000000000000000 y: 0000000000000000 fprs:
0000000000000000 Aborted

I guess i will have to try some framebuffer kernel settings and stuff. >>>
Regards,
Connor

Hi Connor,

Taken from https://wiki.debian.org/Sparc64Qemu

Create/edit /etc/modprobe.d/drm-blacklist.conf

# blacklist of DRM modules that do not load on qemu-system-sparc64 sun4u >> blacklist drm
blacklist bochs-drm
blacklist ttm


May help you here.

Cheers,

Adrian

I ended up passing the additional kernel parameter "modprobe.blacklist=bochs_drm"
System is up and running in text mode as expected.

Thank you!

That's annoying as I submitted a patch a couple of years ago to fix this, and it was
working (see https://github.com/torvalds/linux/commit/931e8c661a2d85e6bdfe145cfc52dffaf4a60516).

What version of the kernel are you using? Did someone manage to break it again?

ATB,

Mark.

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)

Regards,
Connor

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jun 30, 2020 at 5:07 PM Adrian Davey <adrian@beth2.org> wrote:

Now it crashes after some VGA init:

[ 84.672537] [drm] Found bochs VGA, ID 0xb0c5.
[ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @ 0x1ff23000000.
[ 84.711815] [TTM] Zone kernel: Available graphics memory: 2067220 KiB
[ 84.712821] [TTM] Initializing pool allocator
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
pc: 0000000000405618 npc: 000000000040561c
...
pstate: 00000015 ccr: 00 (icc: ---- xcc: ----) asi: 11 tl: 5 pil: 0
gl: 2 tbr: 0000000000420000 hpstate: 0000000000000000 htba: 0000000000000000 cansave: 5 canrestore: 1 otherwin: 0 wstate: 8
cleanwin: 7 cwp: 7 fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 Aborted

I guess i will have to try some framebuffer kernel settings and stuff.

Regards,
Connor

Hi Connor,

Taken from https://wiki.debian.org/Sparc64Qemu

Create/edit /etc/modprobe.d/drm-blacklist.conf

# blacklist of DRM modules that do not load on qemu-system-sparc64 sun4u blacklist drm
blacklist bochs-drm
blacklist ttm

May help you here.

Cheers,

Adrian

I ended up passing the additional kernel parameter "modprobe.blacklist=bochs_drm"
System is up and running in text mode as expected.

Thank you!

Regards,
Connor

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/06/2020 16:13, Connor McLaughlan wrote:

On Tue, Jun 30, 2020 at 5:07 PM Adrian Davey <adrian@beth2.org> wrote:

Now it crashes after some VGA init:

[ 84.672537] [drm] Found bochs VGA, ID 0xb0c5.
[ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @
0x1ff23000000.
[ 84.711815] [TTM] Zone kernel: Available graphics memory: 2067220 KiB
[ 84.712821] [TTM] Initializing pool allocator
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
pc: 0000000000405618 npc: 000000000040561c
...
pstate: 00000015 ccr: 00 (icc: ---- xcc: ----) asi: 11 tl: 5 pil: 0
gl: 2 tbr: 0000000000420000 hpstate: 0000000000000000 htba:
0000000000000000 cansave: 5 canrestore: 1 otherwin: 0 wstate: 8
cleanwin: 7 cwp: 7 fsr: 0000000000000000 y: 0000000000000000 fprs:
0000000000000000 Aborted

I guess i will have to try some framebuffer kernel settings and stuff.

Regards,
Connor

Hi Connor,

Taken from https://wiki.debian.org/Sparc64Qemu

Create/edit /etc/modprobe.d/drm-blacklist.conf

# blacklist of DRM modules that do not load on qemu-system-sparc64 sun4u
blacklist drm
blacklist bochs-drm
blacklist ttm


May help you here.

Cheers,

Adrian

I ended up passing the additional kernel parameter "modprobe.blacklist=bochs_drm"
System is up and running in text mode as expected.

Thank you!

That's annoying as I submitted a patch a couple of years ago to fix this, and it was
working (see https://github.com/torvalds/linux/commit/931e8c661a2d85e6bdfe145cfc52dffaf4a60516).

What version of the kernel are you using? Did someone manage to break it again?


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <kraxel@redhat.com>
Date: Fri Jan 11 06:37:50 2019 +0100

drm/bochs: switch to generic drm fbdev emulation

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20190111053752.4004-15-kraxel@redhat.com

:040000 040000 1917943277034f620af03ac1a2fa5db48b7b224c 6d7a3c316a68efbffd398d6c2b7eebefb47bc92d M drivers


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <kraxel@redhat.com>
Date: Fri Jan 11 06:37:50 2019 +0100

drm/bochs: switch to generic drm fbdev emulation

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20190111053752.4004-15-kraxel@redhat.com

:040000 040000 1917943277034f620af03ac1a2fa5db48b7b224c 6d7a3c316a68efbffd398d6c2b7eebefb47bc92d M drivers

Can I ask you to submit a mail to dri-devel@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/07/2020 22:56, Sam Ravnborg wrote:

Can I ask you to submit a mail to dri-devel@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.

Thanks Sam, I've just done that: https://lists.freedesktop.org/archives/dri-devel/2020-July/271440.html.

I do appreciate that developers don't go out of their way to break things on purpose
- certainly it is frustrating that it's a similar bug to the one I fixed before, but
then with less popular architectures such as SPARC these things just have to be expected.

If you or someone else can provide a simple HOWTO so one can try out a
fix with qemu that would be appreciated.

Ah okay. Let me follow up with my dri-devel@ email with more detail on how I built
both QEMU and the kernel.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)