From: Daniel Jacobowitz <drow@false.org>
To: linuxppc-dev@lists.linuxppc.org
Subject: Re: controlfb.c bug in VRAM bank2 check if bank1
Date: Fri, 10 Sep 1999 16:13:22 -0400 [thread overview]
Message-ID: <19990910161322.A1674@them.org> (raw)
In-Reply-To: <199909111051.DAA22465@marcus.pants.nu>; from Brad Boyer on Sat, Sep 11, 1999 at 03:51:25AM -0700
On Sat, Sep 11, 1999 at 03:51:25AM -0700, Brad Boyer wrote:
>
> Lou Langholtz wrote:
> > I've posted before about this problem but to a different audience. As
> > I'm hoping to get this resolved (fixed) though in the main source tree
> > but don't have the chance to test this entirely myself I'm resending
> > here hoping someone else can test things out...
> >
> > After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> > 2MB were still being recognized (despite having just added the 2MB to
> > total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> > 2.2.12 and made the following changes to get all 4MB VRAM recognized:
>
> Just remember when making changes like this that the old code works fine
> for some people. I've had 4M in my 7600 for a long time, and never once
> had a problem with Linux saying I only had 2M. I don't often have the
> time to do kernel hacking, but I'll try to get a kernel with this patch
> up and running on my computer to see if it breaks things. I suspect it
> will, since it seems that the old way of detecting is removed.
>
> Hopefully I can get back to you on this in a few days.
I have a bunch of information on this lying around, and most of my
other kernel problems seem to be resolved now. I'm in the process of
upgrading to current vger; if it succeeds, I'll try to merge all
pending controlfb stuff tomorrow.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~1999-09-10 20:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-10 15:55 controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
1999-09-10 17:08 ` Lou Langholtz
1999-09-10 18:33 ` Michel Lanners
1999-09-12 16:58 ` Lou Langholtz
1999-09-13 18:13 ` Michel Lanners
1999-09-15 15:14 ` Lou Langholtz
1999-10-12 7:07 ` Lou Langholtz
1999-10-12 7:23 ` Bizarre g++ problem Patrik Jonsson
1999-10-12 6:49 ` controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
1999-10-12 14:50 ` Daniel Jacobowitz
1999-10-12 15:36 ` Lou Langholtz
1999-10-13 6:30 ` Geert Uytterhoeven
1999-09-11 10:51 ` Brad Boyer
1999-09-10 20:13 ` Daniel Jacobowitz [this message]
1999-09-11 9:23 ` Benjamin Herrenschmidt
1999-09-12 18:10 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
1999-09-15 17:05 Kevin_Hendricks
1999-09-15 18:26 ` Kevin Puetz
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=19990910161322.A1674@them.org \
--to=drow@false.org \
--cc=linuxppc-dev@lists.linuxppc.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.