On Tue, Feb 05, 2002 at 01:52:56PM +0100, benh@kernel.crashing.org wrote:
quoted
What's the current state of highmem on the G4? Does it work, not
work, kinda work, only work on UP... ?
I hope to have a dual 7450 G4 with 1 GB RAM within a week, at which
point I'll be able to work on highmem seriously.
It's supposed to work. However, I'm having reports of dual 7450 with
1G or 1.5G of RAM locking up, I haven't been able to track those down.
Is this an Apple machine ? The 7450 has a bug that prevents use on
SMP with HW hash table walk. Apple is supposed to implement a HW
workaround for this on their machines, but if it's not an Apple machine,
then you may have to implement software TLB load.
The dual 7450 is an apple machine. I also have one of our beta
boards, a dual 7410 with 1 GB RAM, and we're planning on having a dual
7450 with 1 GB RAM just as soon as we get the chips.
What's your philosophy about highmem? We map all lowmem with BATs on
SMP in order to avoid trashing SRR0/SRR1 according to your new comment
in entry.S, but it also mentions "other cpus" without saying which cpu
you're talking about. :) How are you avoiding recursive TLB faults on
the highmem pages themselves? What cpus did you have in mind when you
wrote the SMP stuff?
I'm currently getting hard crashes on the dual 7410 with highmem. Not
even the SMI starts xmon. I'm not sure that it's a software bug,
which is why I'm getting the dual 7450.
-VAL
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
The dual 7450 is an apple machine. I also have one of our beta
boards, a dual 7410 with 1 GB RAM, and we're planning on having a dual
7450 with 1 GB RAM just as soon as we get the chips.
What's your philosophy about highmem? We map all lowmem with BATs on
SMP in order to avoid trashing SRR0/SRR1 according to your new comment
in entry.S, but it also mentions "other cpus" without saying which cpu
you're talking about. :) How are you avoiding recursive TLB faults on
the highmem pages themselves? What cpus did you have in mind when you
wrote the SMP stuff?
By "other CPUs", I'm thinking about CPUs that have no BATs. However,
currently, and except for the Power4 which is handled differently, those
are the embedded (4xx, 8xx) which don't do SMP, at least not now.
I don't think kernel stacks & code can ever be in highmem pages, so there
should be no risk taking a fault on highmem page in the return from
exception path.
I'm currently getting hard crashes on the dual 7410 with highmem. Not
even the SMI starts xmon. I'm not sure that it's a software bug,
which is why I'm getting the dual 7450.
Interesting. I have similar reports about dual 800s with 1.5G of RAM.
I don't personally have a machine with that much RAM, so it makes things
a bit difficult to debug. All I noticed so far is that
enabling interrupt distribution will cause occasional lockups on my
dual 7400 at work (not related to highmem). So if you plan to chase
this highmem bug, start by disabling that option to avoid mixing
problems.
Just in case it's a spinlock bug (who knows...) you may want to hack
the spinlock debug output to use the btext engine (basically #define
printf to xmon_printf in the spinlock code and hack xmon/start.c to
force use_screen).
And let me know if you find something ;)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, 5 Feb 2002, Benjamin Herrenschmidt wrote:
Interesting. I have similar reports about dual 800s with 1.5G of RAM. I
don't personally have a machine with that much RAM, so it makes things a
bit difficult to debug.
Hi Ben,
When I get back from holidays I'm going to try those fixes you
recommended (using 2.4.18pre7 or later and with SUNGEM). I'm going to try
it on my Dual450 first because my Dual800 is currently in production and I
don't have another machine to replace it with at the moment. FWIW, the
Dual800 is very stable running 2.4.18pre1 (1GB) in single CPU mode, only
when I enable SMP does it lock up.
If there is any particular thing you want me to do to test this thing
(run particular progs, etc.) let me know.
And let me know if you find something ;)
Will do.
Cheers,
Chris
--
Christopher Murtagh
Webmaster / Sysadmin
Web Communications Group
McGill University
Montreal, Quebec
Canada
Tel.: (514) 398-3122
Fax: (514) 398-2017
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/