linux-kernel - Re: Problems with framebuffer in 2.6.22-git17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 28 Jul 2007 01:32:37 +0100
From:	"Adrian McMenamin" <adrianmcmenamin@...il.com>
To:	"Antonino A. Daplas" <adaplas@...il.com>
Cc:	"Adrian McMenamin" <lkmladrian@...il.com>,
	linux-kernel@...r.kernel.org, lethal@...rs.sourceforge.net
Subject: Re: Problems with framebuffer in 2.6.22-git17

On 28/07/07, Antonino A. Daplas <adaplas@...il.com> wrote:
> On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote:
> > On 27/07/07, Antonino A. Daplas <adaplas@...il.com> wrote:
> > > On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote:
> > > > On 27/07/07, Adrian McMenamin <adrianmcmenamin@...il.com> wrote:
> > > >
> > > > > With the patch reverted and 24bpp, it oopses before freezing (with two
> > > > > odd looking boot logos on the screen):
> > > > >
> > > > Tested this further and it fails on:
> > > >
> > > > rev = fb_readl(par->mmio_base + 0x04);
> > >
> > > Doubtful if this line is the point of failure, this line is executed
> > > only once, on initialization.
> >
> >
> > par->mmio_base is corrupted in some way during the call to
> > register_framebuffer - still investigating how/why.
>
> Possible, par->mmio_base is the last field in struct pvr2fb_par,
> after that is the pseudo_palette. The oops did not manifest when the
> pseudo_palette was written as u16, but oops'ed when written as u32.
> Memory alignment problems?
>
> Try the patch I posted before, might help.
>
Apologies, missed the patch before.

With the patch applied the Dreamcast no longer crashes or locks with
either 16, 24 or 32 bpp, so that's good.

With 24bpp everything is doubled up (eg two boot logos on screen) and
about twice (?) the size it should be - though with a black screen.

With 32 bpp everything is about 4 (?) times the size it should be and
all on a yellow background.

With 16bpp then everything is on a blue background as before, but is
also the correct size (as before).

So, it's better certainly, but there are still a few issues with the
driver, though nothing that takes down the box.

So thanks!

Adrian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/