From: Sam Ravnborg <sam@ravnborg.org>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Gerd Hoffmann <kraxel@redhat.com>, dri-devel@lists.freedesktop.org
Subject: Re: Panic booting qemu-system-sparc64 with bochs_drm
Date: Sat, 4 Jul 2020 15:41:15 +0200 [thread overview]
Message-ID: <20200704134115.GA755192@ravnborg.org> (raw)
In-Reply-To: <485ded46-c1a3-1eab-eb95-1a771543fbaf@ilande.co.uk>
Hi Mark.
On Sat, Jul 04, 2020 at 02:09:38PM +0100, Mark Cave-Ayland wrote:
> On 04/07/2020 12:11, Mark Cave-Ayland wrote:
>
> > According to gdbstub the destination address in $g3 looks like this:
> >
> > Breakpoint 1, 0x00000000007ad8e4 in cfb_imageblit ()
> > (gdb) i r $g3
> > g3 0x100220000 4297195520
> >
> >
> > The 0x100220000 address still isn't right. On sun4u the PCI address space is mapped
> > at physical address 0x1fe00000000 and adding these two together gives 0x1ff00220000
> > which seems closer, but still not the correct framebuffer address 0x1ff22000000 which
> > is reported at boot:
> >
> > [ 9.007161] [drm] Found bochs VGA, ID 0xb0c5.
> > [ 9.007840] [drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @ 0x1ff23000000.
>
> As a comparison, I took the last known good commit 7a0483ac4ffc~1: "drm/bochs: add
> basic prime support" and added some debug in cfb_imageblit() to allow me to pick out
> p->screen_base:
>
> (gdb) i r $o1
> o1 0x1ff22000000 2195298713600
>
> When running git master with your patch in the same way I get a completely different
> value:
>
> (gdb) i r $o1
> o1 0x100050000 4295294976
>
> Does p->screen_base need to be initialised differently when using the cfb helpers?
I think what is happening is that the bochs driver request a shadow copy
for the frambuffer. And with the change to fbops we now use the cfb_
functions to write to the shadow framebuffer - which is not in any IO
space. So this does not work.
So maybe all we need is the fix in drm_fb_helper_dirty_blit_real().
If you try to undo the change so fbops is set to &drm_fbdev_fb_ops,
but keep the fix in drm_fb_helper_dirty_blit_real() how does it then
behave?
I did not find time to follow your instructions to test this myself with
qemu - sorry.
Sam
>
>
> ATB,
>
> Mark.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-07-04 13:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-03 21:57 Panic booting qemu-system-sparc64 with bochs_drm Mark Cave-Ayland
2020-07-03 22:54 ` Mark Cave-Ayland
2020-07-04 7:23 ` Sam Ravnborg
2020-07-04 11:11 ` Mark Cave-Ayland
2020-07-04 13:09 ` Mark Cave-Ayland
2020-07-04 13:41 ` Sam Ravnborg [this message]
2020-07-04 14:16 ` Mark Cave-Ayland
2020-07-04 14:52 ` Sam Ravnborg
2020-07-06 19:36 ` Mark Cave-Ayland
2020-07-07 7:03 ` Gerd Hoffmann
2020-07-07 16:17 ` Mark Cave-Ayland
2020-07-07 17:38 ` Gerd Hoffmann
2020-07-07 19:52 ` Sam Ravnborg
2020-07-07 21:06 ` Mark Cave-Ayland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200704134115.GA755192@ravnborg.org \
--to=sam@ravnborg.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).