Fwd: CPU features

Fwd: CPU features

[Benjamin Herrenschmidt]

I finally finished my cpu table & features stuff. It's in my rsync
kernel at penguinppc::linux-2.4-benh. It may still need some fixes
for 4xx/8xx and power3/4, so please, look at it and send me patches ;)

Basically, every CPU calls identify_cpu (head.S) during startup.
Each CPU is matched via a table (cputable.c), and a pointer to
it's table entry stored in an array. The table contains a few
things (and can be extended as offsets for the asm code are
computed my mk_defs.c):

 - PVR mask/value (used to match the CPU model/rev)
 - the CPU name
 - the i/d cache line sizes (well, maybe not needed)]
 - the CPU features bit mask
 - the CPU "setup" function

The call to enable_caches is replaced by a call to the CPU
setup function provided by the table entry.

C code can just get the pointer to the table entry to get the
CPU features and test them. For assembly code, I added an
additional trick to avoid the overhead of reading from memory,
testing the bit, etc.. Mostly because I wanted to avoid
an unpredictable branch in code path such as transfer_to_handler
and because such asm code may run with either MMU translation on
or off, making the retreival of the CPU features potentially
tricky.

Basically, if you have a bit of asm code that depends on a
given CPU feature, enclose it with a couple of macros defined
in cputable.h. The second macro takes a couple of feature
masks as a parameter (matched by the usual (ftr&mask)==value
so you can test for either the presence or absence of the
feature).

The macros will add references to the enclosed code in a
table stored in the __ftr_fixup section. head.S will parse
this table after identifying CPU0 and will replace the code
with nop's if the required features are not matched.

I mostly use this for altivec so no need to test for
it dynamically in head.S or entry.S.

If we end up nop'ing out larger bits of code, it's easy to
modify the fixup routine to replace the first nop with a branch
to after the code section, avoiding the execution of all the nops.
For now, I didn't feel the need for it since it never replace more
than 2 instructions with nop's in real life.

It could also be used for the 601-only SYNCs to avoid a compile
option: those syncs would be nop'ed out automagically when running
on a non-601 CPU. Other candidates I didn't touch yet are the
cache flush/inval routines (split/non-split caches), etc..

For larger chunks of code, it would be wiser to add function
pointers to the cpu table entries.

Please, don't hesitate to comment, send patches, etc... I plan
to push all this by the end of next week, once it's tested
enough on various hardware and missing bits for embedded CPUs
and power3/4 are added.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Kaoru Fukui]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: <linuxppc-dev@lists.linuxppc.org>
Subject: Fwd: CPU features
Date: Sat, 31 Mar 2001 11:16:15 +0200

>
> I finally finished my cpu table & features stuff. It's in my rsync
> kernel at penguinppc::linux-2.4-benh. It may still need some fixes
> for 4xx/8xx and power3/4, so please, look at it and send me patches ;)

great your works.

Does this kernel work SMP mode?

I got the source now.
looking the source ,but almost same for SMP.

I'm goting to compile this using my patch


Thanks a lot
Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Kaoru Fukui]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: <linuxppc-dev@lists.linuxppc.org>
Subject: Fwd: CPU features
Date: Sat, 31 Mar 2001 11:16:15 +0200

>
> I finally finished my cpu table & features stuff. It's in my rsync
> kernel at penguinppc::linux-2.4-benh. It may still need some fixes
> for 4xx/8xx and power3/4, so please, look at it and send me patches ;)
>

Please fix your typo in arch/ppc/kernel/feature.c
it's in void feature_core99_kick_cpu(int cpu_nr)


void
feature_core99_kick_cpu(int cpu_nr)
<snip>
     if (!keylargo_base || nr > 3 )    <-- cpu_nr ?


I guess, that nr is your typo.
Is it cpu_nr   ?

Please fix it where compile stop.


Thanks
Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>
>
>Please fix your typo in arch/ppc/kernel/feature.c
>it's in void feature_core99_kick_cpu(int cpu_nr)
>
>
>void
>feature_core99_kick_cpu(int cpu_nr)
><snip>
>     if (!keylargo_base || nr > 3 )    <-- cpu_nr ?
>
>
>I guess, that nr is your typo.
>Is it cpu_nr   ?
>
>Please fix it where compile stop.

Right, I didn't test it on SMP yet. I've pushed that fix to my
devel tree along with a few other stuffs & updated to 2.4.3.
The rsync should be up-to-date in a few minutes.

Please tell me if the dual G4 kicks properly the other CPU as
I changed the way it's done but didn't have a chance to test my
new code yet.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Kaoru Fukui]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

> Please tell me if the dual G4 kicks properly the other CPU as
> I changed the way it's done but didn't have a chance to test my
> new code yet.

I tried your tree as SMP-kernel which has also spin_lock problem.
All recent kernel sources have spin_lock problem.

When I used the patch,The kernel boot stop displaying
at "smp_core99_kick_cpu".

The patch here is
http://lists.linuxppc.org/listarcs/linuxppc-dev/200103/msg00259.html

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>
>When I used the patch,The kernel boot stop displaying
>at "smp_core99_kick_cpu".

Ok. I'm not too surprised as I wrote this new version more or less
blinldy. I'll get that fixed next week when I have access to the
dual G4 at work.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Kaoru Fukui]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kaoru Fukui <k_fukui@highway.ne.jp>
Subject: Re: Fwd: CPU features
Date: Sun, 1 Apr 2001 17:03:48 +0200

> >I tried your tree as SMP-kernel which has also spin_lock problem.
> >All recent kernel sources have spin_lock problem.
> >
> BTW, Can you email paulus (paulus@samba.org) and cort (cort@fsmlabs.com)
> about this spinlock problem ?
>

Hi
Thanks your great kernel works.
Recently kernel source has spin_lock problem.

I  needed the patch for kernel-2.4.3.pre8-SMP on Dual G4.

Kernel Guys, Please look the patch or
Please Look this problem.


Kaoru
-------- this patch is needed for SMP kernel-2.4.3.pre8  ---------

diff -urN base/arch/ppc/mm/init.c fixed/arch/ppc/mm/init.c
--- base/arch/ppc/mm/init.c	Thu Mar 29 06:02:35 2001
+++ fixed/arch/ppc/mm/init.c	Fri Mar 30 05:51:16 2001
@@ -437,12 +437,15 @@
 	/*
 	 * Should check if it is a candidate for a BAT mapping
 	 */
-
+#ifndef CONFIG_SMP
 	spin_lock(&init_mm.page_table_lock);
+#endif
 	err = 0;
 	for (i = 0; i < size && err == 0; i += PAGE_SIZE)
 		err = map_page(v+i, p+i, flags);
+#ifndef CONFIG_SMP
 	spin_unlock(&init_mm.page_table_lock);
+#endif
 	if (err) {
 		if (mem_init_done)
 			vfree((void *)v);
diff -urN base/mm/memory.c fixed/mm/memory.c
--- base/mm/memory.c	Thu Mar 29 09:22:35 2001
+++ fixed/mm/memory.c	Fri Mar 30 05:52:17 2001
@@ -1320,9 +1320,13 @@
 		/* "fast" allocation can happen without dropping the lock.. */
 		new = pte_alloc_one_fast(address);
 		if (!new) {
+#ifndef CONFIG_SMP
 			spin_unlock(&mm->page_table_lock);
+#endif
 			new = pte_alloc_one(address);
+#ifndef CONFIG_SMP
 			spin_lock(&mm->page_table_lock);
+#endif
 			if (!new)
 				return NULL;

---------- END -------------

> > This is booing message when kernel-2.4.3pre8-SMP.
> >
> > <snip>
> > TCP: Hash tables configured (established 8192 bind 8192)
> > ip_conntrack(2048 buckets,16384 max)
> > _spin_lock(c02cc470) CPU# 1 NIP c0033404 holder: cpu 1 pc C002B384
> > _spin_lock(c02ce740) CPU# 0 NIP c0015890 holder: cpu 1 pc C0015890

>   Can you look at your system.map for that kernel and tell me what is at
> addresses:

> This is getton  data from system.map

> c00153b0 T schedule_tail
> <C001589>
> c0015a4c T __wake_up
> <snip>
> c002b28c T pte_alloc
> <C002b384>
> c002b3d8 T make_pages_present
> <snip>
> c02cc42c D init_mm
> <c02cc470>
> c02cc4d0 D init_task_union
> <snip>
> c02ce738 d null_pci_ops
> <c02ce740>
> c02ce750 D kernel_flag
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Holger Bettag]

BTW, availability of preliminary MPC7450 User Manual has been announced on
the AltiVec mailinglist:

http://e-www.motorola.com/brdata/PDFDB/MICROPROCESSORS/32_BIT/POWERPC/MPC7XX/MPC7450UM.pdf

(Just in case anyone already wants to look into it.)

  Holger

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>
>Hi
>Thanks your great kernel works.
>Recently kernel source has spin_lock problem.
>
>I  needed the patch for kernel-2.4.3.pre8-SMP on Dual G4.
>
>Kernel Guys, Please look the patch or
>Please Look this problem.

Hrm.. your patch isn't good. I think I found the problem (but didn't
yet test. My proposed fix is in my rsync, please test and report).

Basically, pte_alloc() is meant to be called with the page table lock
held. It may itself unlock & re-lock it.

There are places in arch/ppc/mm/init.c where we call it (via map_page())
without the lock. That mean that we can go out of mapin_ram and paging_init
with a dangling page table lock held init init_mm, causing further calls
to __ioremap (or other things) to lockup as soon as they try to grab that
lock.

The fix would be to enclose those calls to map_page() with a
spin_lock(&init_mm.page_table_lock);
and
spin_unlock(&init_mm.page_table_lock);

Tell me what result you get with that.

ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Tony Mantler]

At 12:04 PM -0500 4/1/2001, Benjamin Herrenschmidt wrote:
[...]
>Tell me what result you get with that.

I got the linux-2.4-benh from rsync.penguinppc.org (I assume this is the
up-to-date one) around noontime today, and got a crash after arch:exit on
my 9600/200mp.

xmon sez:

cpu 0: vector: 300 at pc = c0006c18, lr = c01c3518, msr = 1032, sp =
c01a3320 [c01a3270]
dar = cc000000, dsisr = 40000000
current = c01a14a0, pid = 0, comm = swapper
0:mon> t
backtrace c01c33ec c01c0a40 c01c06b4 36b0

One sec while I reboot and check the System.map...

c0006c18 (pc) is in flush_icache_range
c01c3518 (lr) is in pmac_pic_init
co1a14a0 (current) is init_task_union
c01c33ec (bt) is in pmac_pic_init
c01c0a40 (bt) is in init_IRQ
c01c06b4 (bt) is in start_kernel


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Kaoru Fukui]

Hi!

Thanks,
Your fix  is very nice.
I could run fine smp-kernel-2.4.3 which your patch to penguinppc's 2.4-bk.

Last one is a problem of "smp_core99_kick_cpu" on your tree.

Thanks again

Kaoru

--------------------------
diff -urN base/arch/ppc/mm/init.c fixed/arch/ppc/mm/init.c
--- base/arch/ppc/mm/init.c	Mon Apr  2 02:46:43 2001
+++ fixed/arch/ppc/mm/init.c	Mon Apr  2 01:56:16 2001
@@ -778,7 +778,9 @@
 			f |= _PAGE_USER;
 #endif /* CONFIG_8xx */
 #endif /* CONFIG_KGDB */
+		spin_lock(&init_mm.page_table_lock);
 		map_page(v, p, f);
+		spin_unlock(&init_mm.page_table_lock);
 		v += PAGE_SIZE;
 		p += PAGE_SIZE;
 	}
@@ -1098,11 +1100,13 @@
 	unsigned long zones_size[MAX_NR_ZONES], i;

 #ifdef CONFIG_HIGHMEM
+	spin_lock(&init_mm.page_table_lock);
 	map_page(PKMAP_BASE, 0, 0);	/* XXX gross */
 	pkmap_page_table = pte_offset(pmd_offset(pgd_offset_k(PKMAP_BASE), PKMAP_
BASE), PKMAP_BASE);
 	map_page(KMAP_FIX_BEGIN, 0, 0);	/* XXX gross */
 	kmap_pte = pte_offset(pmd_offset(pgd_offset_k(KMAP_FIX_BEGIN), KMAP_FIX_BEGIN),
 KMAP_FIX_BEGIN);
 	kmap_prot = PAGE_KERNEL;
+	spin_unlock(&init_mm.page_table_lock);
 #endif /* CONFIG_HIGHMEM */

 	/*

--------------------------


From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kaoru Fukui <k_fukui@highway.ne.jp>
Subject: Re: Fwd: CPU features
Date: Sun, 1 Apr 2001 19:04:18 +0200
Cc: <linuxppc-dev@lists.linuxppc.org>, <paulus@samba.org>, <cort@fsmlabs.com>

>
> >
> >Hi
> >Thanks your great kernel works.
> >Recently kernel source has spin_lock problem.
> >
> >I  needed the patch for kernel-2.4.3.pre8-SMP on Dual G4.
> >
> >Kernel Guys, Please look the patch or
> >Please Look this problem.
>
> Hrm.. your patch isn't good. I think I found the problem (but didn't
> yet test. My proposed fix is in my rsync, please test and report).
>
> Basically, pte_alloc() is meant to be called with the page table lock
> held. It may itself unlock & re-lock it.
>
> There are places in arch/ppc/mm/init.c where we call it (via map_page())
> without the lock. That mean that we can go out of mapin_ram and paging_init
> with a dangling page table lock held init init_mm, causing further calls
> to __ioremap (or other things) to lockup as soon as they try to grab that
> lock.
>
> The fix would be to enclose those calls to map_page() with a
> spin_lock(&init_mm.page_table_lock);
> and
> spin_unlock(&init_mm.page_table_lock);
>
> Tell me what result you get with that.
>
> ben.
>
>
>
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>
>I got the linux-2.4-benh from rsync.penguinppc.org (I assume this is the
>up-to-date one) around noontime today, and got a crash after arch:exit on
>my 9600/200mp.

I fixed that. Maybe the rsync is not fully up-to-date, I'll check that asap.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>Your fix  is very nice.
>I could run fine smp-kernel-2.4.3 which your patch to penguinppc's 2.4-bk.
>
>Last one is a problem of "smp_core99_kick_cpu" on your tree.

I reverted that change until I can test it on the dual G4.

ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Tony Mantler]

At 3:09 PM -0500 4/1/2001, Benjamin Herrenschmidt wrote:
>>
>>I got the linux-2.4-benh from rsync.penguinppc.org (I assume this is the
>>up-to-date one) around noontime today, and got a crash after arch:exit on
>>my 9600/200mp.
>
>I fixed that. Maybe the rsync is not fully up-to-date, I'll check that asap.

Ok, that crash appears to be fixed now.

Now after arch:exit, it just... stops. Cmd-power doesn't bring up xmon, so
I have no idea where it's died.

The sti replacement code still looked kinda weird, but I have no idea what
it's supposed to look like, so I guess that's ok...


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>not fully up-to-date, I'll check that asap.
>
>Ok, that crash appears to be fixed now.
>
>Now after arch:exit, it just... stops. Cmd-power doesn't bring up xmon, so
>I have no idea where it's died.
>
>The sti replacement code still looked kinda weird, but I have no idea what
>it's supposed to look like, so I guess that's ok...

I'll have to look at this more closely. The problem may come from the
spinlock problem (my fix might not be enough) or from another issue
with my devel kernel as some of the new things in there have not yet
been fully tested, especially on SMP.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Tony Mantler]

At 5:07 PM -0500 4/1/2001, Benjamin Herrenschmidt wrote:
>>not fully up-to-date, I'll check that asap.
>>
>>Ok, that crash appears to be fixed now.
>>
>>Now after arch:exit, it just... stops. Cmd-power doesn't bring up xmon, so
>>I have no idea where it's died.
>>
>>The sti replacement code still looked kinda weird, but I have no idea what
>>it's supposed to look like, so I guess that's ok...
>
>I'll have to look at this more closely. The problem may come from the
>spinlock problem (my fix might not be enough) or from another issue
>with my devel kernel as some of the new things in there have not yet
>been fully tested, especially on SMP.

I just booted with the second CPU wedged (that is to say, bootx from MacOS
9) with the same kernel to see what it would do with only 1 cpu, and it
still stops at the same place, so I'm guessing the problem should be
reproducable on a single-cpu system running an SMP kernel, if that helps
any.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>I just booted with the second CPU wedged (that is to say, bootx from MacOS
>9) with the same kernel to see what it would do with only 1 cpu, and it
>still stops at the same place, so I'm guessing the problem should be
>reproducable on a single-cpu system running an SMP kernel, if that helps
>any.

Well, I booted succesfully the Pismo (which doesn't use the lost_interrupts
stuff) with an SMP kernel. So either this is broken, or something else
related to powersurge is broken.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Dan Malek]

Benjamin Herrenschmidt wrote:

> Please, don't hesitate to comment, send patches, etc...


Is anyone else working on 7450 besides me?  I was holding out
all of these CPU updates when Ben promised these changes :-).
Now that this is done, I'll start checking in my changes.  If
someone else has code, let me know and I will merge it together
and test it.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Fwd: CPU features

[Benjamin Herrenschmidt]

>
>Is anyone else working on 7450 besides me?  I was holding out
>all of these CPU updates when Ben promised these changes :-).
>Now that this is done, I'll start checking in my changes.  If
>someone else has code, let me know and I will merge it together
>and test it.

Well, I didn't commit the CPU features yet. It needs to be better
tested and I still need Cort's ack before pushing. I also need your
8xx/4xx version of it ;)

Send me any patch you want for my rsync tree, I can push them as
a batch along with the feature stuff when it's ready.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/