Re: qemu-system-sparc64 not booting install of debian sparc64
On 03/07/2020 22:56, Sam Ravnborg wrote: > 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. 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.
Re: qemu-system-sparc64 not booting install of debian sparc64
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 @ 0x1ff2200, mmio @
> > 0x1ff2300.
> > [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 :01:02.0
> > on minor 0
> > [9.336819] Unable to handle kernel paging request at virtual address
> > 01ff221d
> > [9.337177] tsk->{mm,active_mm}->context =
> > [9.337283] tsk->{mm,active_mm}->pgd = f8402000
> > [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: 80001605 TPC: 0077441c TNPC:
> > 00774420
> > Y: Not tainted
> > [9.341894] TPC:
> > [9.342015] g0: g1: g2:
> > g3:
> > f800043d2c00
> > [9.342094] g4: f8000410eac0 g5: f800064cc000 g6:
> > f80004124000 g7:
> > 0010
> > [9.342173] o0: 01ff221d o1: 00010022 o2:
> > o3:
> > 01fe21fb
> > [9.342254] o4: 01ff221d o5: sp:
> > f800041273d1 ret_pc:
> > 00805b18
> > [9.342325] RPC:
> > [9.342591] l0: f80007819cc0 l1: f800043df8cc l2:
> > 01356200 l3:
> > f800064cc000
> > [9.342670] l4: f80004004200 l5: l6:
> > 0025 l7:
> > f80004002500
> > [9.342750] i0: f800043df8d0 i1: f800040106b0 i2:
> > 0020 i3:
> > f800043e5500
> > [9.342829] i4: 01d1 i5: 00010022 i6:
> > f80004127491 i7:
> > 00481fec
> > [9.342960] I7:
> > [9.343308] Call Trace:
> > [9.344077] [<00481fec>] process_one_work+0x18c/0x540
> > [9.344267] [<004824c4>] worker_thread+0x124/0x580
> > [9.344310] [<00489758>] kthread+0xf8/0x120
> > [9.344357] [<004060a4>] ret_from_fork+0x1c/0x2c
> > [9.344714] [<>] 0x0
> > [9.344982] Disabling lock debugging due to kernel taint
> > [9.345454] Caller[00481fec]: process_one_work+0x18c/0x540
> > [9.345661] Caller[004824c4]: worker_thread+0x124/0x580
> > [9.345702] Caller[00489758]: kthread+0xf8/0x120
> > [9.345743] Caller[004060a4]: ret_from_fork+0x1c/0x2c
> > [9.345779] Caller[]: 0x0
> > [9.345909] Instruction DUMP:
> > [9.346012] da5a6000
> > [9.346170] c25a6008
> > [9.346188] 8ea1e010
> > [9.346205]
> > [9.346221] 92026008
> > [9.346238] c272400b
> > [9.346254] 186a
> > [9.346271] 92026008
> > [9.346287] 808aa008
> > [9.346429]
> > [9.397204] Console: switching to colour frame buffer device 128x48
> > [ 10.010529] bochs-drm :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
> Date: Fri Jan 11 06:37:50 2019 +0100
>
> drm/bochs: switch to generic drm fbdev emulation
>
> Signed-off-by: Gerd Hoffmann
> Acked-by: Daniel Vetter
> Link:
> http://patchwork.freedesktop.org/patch/msgid/20190111053752.4004-15-kra...@redhat.com
>
> :04 04 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
Re: qemu-system-sparc64 not booting install of debian sparc64
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 @ 0x1ff2200, mmio @
> 0x1ff2300.
> [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 :01:02.0 on
> minor 0
> [9.336819] Unable to handle kernel paging request at virtual address
> 01ff221d
> [9.337177] tsk->{mm,active_mm}->context =
> [9.337283] tsk->{mm,active_mm}->pgd = f8402000
> [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: 80001605 TPC: 0077441c TNPC:
> 00774420
> Y: Not tainted
> [9.341894] TPC:
> [9.342015] g0: g1: g2:
> g3:
> f800043d2c00
> [9.342094] g4: f8000410eac0 g5: f800064cc000 g6: f80004124000
> g7:
> 0010
> [9.342173] o0: 01ff221d o1: 00010022 o2:
> o3:
> 01fe21fb
> [9.342254] o4: 01ff221d o5: sp: f800041273d1
> ret_pc:
> 00805b18
> [9.342325] RPC:
> [9.342591] l0: f80007819cc0 l1: f800043df8cc l2: 01356200
> l3:
> f800064cc000
> [9.342670] l4: f80004004200 l5: l6: 0025
> l7:
> f80004002500
> [9.342750] i0: f800043df8d0 i1: f800040106b0 i2: 0020
> i3:
> f800043e5500
> [9.342829] i4: 01d1 i5: 00010022 i6: f80004127491
> i7:
> 00481fec
> [9.342960] I7:
> [9.343308] Call Trace:
> [9.344077] [<00481fec>] process_one_work+0x18c/0x540
> [9.344267] [<004824c4>] worker_thread+0x124/0x580
> [9.344310] [<00489758>] kthread+0xf8/0x120
> [9.344357] [<004060a4>] ret_from_fork+0x1c/0x2c
> [9.344714] [<>] 0x0
> [9.344982] Disabling lock debugging due to kernel taint
> [9.345454] Caller[00481fec]: process_one_work+0x18c/0x540
> [9.345661] Caller[004824c4]: worker_thread+0x124/0x580
> [9.345702] Caller[00489758]: kthread+0xf8/0x120
> [9.345743] Caller[004060a4]: ret_from_fork+0x1c/0x2c
> [9.345779] Caller[]: 0x0
> [9.345909] Instruction DUMP:
> [9.346012] da5a6000
> [9.346170] c25a6008
> [9.346188] 8ea1e010
> [9.346205]
> [9.346221] 92026008
> [9.346238] c272400b
> [9.346254] 186a
> [9.346271] 92026008
> [9.346287] 808aa008
> [9.346429]
> [9.397204] Console: switching to colour frame buffer device 128x48
> [ 10.010529] bochs-drm :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
Date: Fri Jan 11 06:37:50 2019 +0100
drm/bochs: switch to generic drm fbdev emulation
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
Link:
http://patchwork.freedesktop.org/patch/msgid/20190111053752.4004-15-kra...@redhat.com
:04 04 1917943277034f620af03ac1a2fa5db48b7b224c
6d7a3c316a68efbffd398d6c2b7eebefb47bc92d M drivers
ATB,
Mark.
Re: qemu-system-sparc64 not booting install of debian sparc64
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 @ 0x1ff2200, mmio @
0x1ff2300.
[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 :01:02.0 on
minor 0
[9.336819] Unable to handle kernel paging request at virtual address
01ff221d
[9.337177] tsk->{mm,active_mm}->context =
[9.337283] tsk->{mm,active_mm}->pgd = f8402000
[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: 80001605 TPC: 0077441c TNPC:
00774420
Y: Not tainted
[9.341894] TPC:
[9.342015] g0: g1: g2:
g3:
f800043d2c00
[9.342094] g4: f8000410eac0 g5: f800064cc000 g6: f80004124000
g7:
0010
[9.342173] o0: 01ff221d o1: 00010022 o2:
o3:
01fe21fb
[9.342254] o4: 01ff221d o5: sp: f800041273d1
ret_pc:
00805b18
[9.342325] RPC:
[9.342591] l0: f80007819cc0 l1: f800043df8cc l2: 01356200
l3:
f800064cc000
[9.342670] l4: f80004004200 l5: l6: 0025
l7:
f80004002500
[9.342750] i0: f800043df8d0 i1: f800040106b0 i2: 0020
i3:
f800043e5500
[9.342829] i4: 01d1 i5: 00010022 i6: f80004127491
i7:
00481fec
[9.342960] I7:
[9.343308] Call Trace:
[9.344077] [<00481fec>] process_one_work+0x18c/0x540
[9.344267] [<004824c4>] worker_thread+0x124/0x580
[9.344310] [<00489758>] kthread+0xf8/0x120
[9.344357] [<004060a4>] ret_from_fork+0x1c/0x2c
[9.344714] [<>] 0x0
[9.344982] Disabling lock debugging due to kernel taint
[9.345454] Caller[00481fec]: process_one_work+0x18c/0x540
[9.345661] Caller[004824c4]: worker_thread+0x124/0x580
[9.345702] Caller[00489758]: kthread+0xf8/0x120
[9.345743] Caller[004060a4]: ret_from_fork+0x1c/0x2c
[9.345779] Caller[]: 0x0
[9.345909] Instruction DUMP:
[9.346012] da5a6000
[9.346170] c25a6008
[9.346188] 8ea1e010
[9.346205]
[9.346221] 92026008
[9.346238] c272400b
[9.346254] 186a
[9.346271] 92026008
[9.346287] 808aa008
[9.346429]
[9.397204] Console: switching to colour frame buffer device 128x48
[ 10.010529] bochs-drm :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.
Re: qemu-system-sparc64 not booting install of debian sparc64
On 30/06/2020 16:13, Connor McLaughlan wrote: > On Tue, Jun 30, 2020 at 5:07 PM Adrian Davey wrote: >>> Now it crashes after some VGA init: >>> >>> [ 84.672537] [drm] Found bochs VGA, ID 0xb0c5. >>> [ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff2200, mmio @ >>> 0x1ff2300. >>> [ 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: 00405618 npc: 0040561c >>> ... >>> pstate: 0015 ccr: 00 (icc: xcc: ) asi: 11 tl: 5 pil: 0 >>> gl: 2 tbr: 0042 hpstate: htba: >>> cansave: 5 canrestore: 1 otherwin: 0 wstate: 8 >>> cleanwin: 7 cwp: 7 fsr: y: fprs: >>> 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.
Re: qemu-system-sparc64 not booting install of debian sparc64
On Tue, Jun 30, 2020 at 5:43 PM Mark Cave-Ayland wrote: > > On 30/06/2020 16:13, Connor McLaughlan wrote: > > > On Tue, Jun 30, 2020 at 5:07 PM Adrian Davey wrote: > >>> Now it crashes after some VGA init: > >>> > >>> [ 84.672537] [drm] Found bochs VGA, ID 0xb0c5. > >>> [ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff2200, mmio @ > >>> 0x1ff2300. > >>> [ 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: 00405618 npc: 0040561c > >>> ... > >>> pstate: 0015 ccr: 00 (icc: xcc: ) asi: 11 tl: 5 pil: 0 > >>> gl: 2 tbr: 0042 hpstate: htba: > >>> cansave: 5 canrestore: 1 otherwin: 0 wstate: 8 > >>> cleanwin: 7 cwp: 7 fsr: y: fprs: > >>> 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
Re: qemu-system-sparc64 not booting install of debian sparc64
On Tue, Jun 30, 2020 at 5:07 PM Adrian Davey wrote: > > Now it crashes after some VGA init: > > > > [ 84.672537] [drm] Found bochs VGA, ID 0xb0c5. > > [ 84.673255][drm] Framebuffer size 16384 kB @ 0x1ff2200, mmio @ > > 0x1ff2300. > > [ 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: 00405618 npc: 0040561c > > ... > > pstate: 0015 ccr: 00 (icc: xcc: ) asi: 11 tl: 5 pil: 0 > > gl: 2 tbr: 0042 hpstate: htba: > > cansave: 5 canrestore: 1 otherwin: 0 wstate: 8 > > cleanwin: 7 cwp: 7 fsr: y: fprs: > > 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
Re: qemu-system-sparc64 not booting install of debian sparc64
On 2020-06-30 15:30, Connor McLaughlan wrote: On Tue, Jun 30, 2020 at 4:10 PM John Paul Adrian Glaubitz 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 @ 0x1ff2200, mmio @ 0x1ff2300. [ 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: 00405618 npc: 0040561c ... pstate: 0015 ccr: 00 (icc: xcc: ) asi: 11 tl: 5 pil: 0 gl: 2 tbr: 0042 hpstate: htba: cansave: 5 canrestore: 1 otherwin: 0 wstate: 8 cleanwin: 7 cwp: 7 fsr: y: fprs: 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
Re: qemu-system-sparc64 not booting install of debian sparc64
On Tue, Jun 30, 2020 at 4:10 PM John Paul Adrian Glaubitz 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 @ 0x1ff2200, mmio @ 0x1ff2300. [ 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: 00405618 npc: 0040561c ... pstate: 0015 ccr: 00 (icc: xcc: ) asi: 11 tl: 5 pil: 0 gl: 2 tbr: 0042 hpstate: htba: cansave: 5 canrestore: 1 otherwin: 0 wstate: 8 cleanwin: 7 cwp: 7 fsr: y: fprs: Aborted I guess i will have to try some framebuffer kernel settings and stuff. Regards, Connor
Re: qemu-system-sparc64 not booting install of debian sparc64
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 > 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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: qemu-system-sparc64 not booting install of debian sparc64
On Tue, Jun 30, 2020 at 3:53 PM John Paul Adrian Glaubitz 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
Re: qemu-system-sparc64 not booting install of debian sparc64
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 0x0030 PC = 0xffd0f16c NPC = > 0xffd0f170 Stopping execution > > Also within the grub console i am unable to execute "ls" to list > attached drives: > > grub> ls > Unhandled Exception 0x0030 PC = 0xffd0f16c NPC = > 0xffd0f170 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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
