* About MPC8245 software reboot
From: John Zhan @ 2005-07-13 3:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi,all
Most of MPC8245 kernel port are using watchdog reset manner to get software
reboot.
I notice that every implement of whaterverplatform_restart() always enter
dead loop and then wait for WDT reset.. My idea is, if there has possible to
implement a software restart function in kernel. Like Uboot doing reset
command.
Because in my case,the WDT on my customize MPC8245 board has a long timeout
period, about 30 seconds.
So,
I had to try to replace platform_restart() with do_reset() which found in
Uboot.
But I got thease, I guess something wrong in memory map.
sh-2.05a# reboot
INIT: Switching to runlevel: 6
Broadcast message from root (console) Thu Dec 4 00:01:21 2003...
The system is going down for reboot NOW !!
INIT: Sending processes the TERM signal
DEBUG: first run the kill scripts
DEBUG:now run the start scripts
Starting killall: [ OK ]
/etc/rc6.d/S01reboot: enable: kill: not a shell builtin
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting proc file system:
Please stand by while rebooting the system...
Restarting system.
U-Boot 1.1.2 (Jan 25 2005 - 14:55:00) [svm]
CPU: MPC8245 Revision 1.1 at 299.999 MHz: 16 kB I-Cache 16 kB D-Cache
Board: SVM_SC8245 Local Bus at 99.999 MHz
I2C: ready
DRAM: Scan SDRAM memory........................
64 MB
Top of RAM usable for U-Boot at: 04000000
Reserving 460k for U-Boot at: 03f8c000
Reserving 128k for malloc() at: 03f6c000
Reserving 56 Bytes for Board Info at: 03f6bfc8
Reserving 48 Bytes for Global Data at: 03f6bf98
Stack Pointer at: 03f6bf78
New Stack Pointer is: 03f6bf78
Now running in RAM - U-Boot at: 03f8c000
FLASH: 512 kB
PCI Scan: Found Bus 0, Device 22, Function 0
PCI Config: I/O=0x80000000, Memory=0x80000000, Command=0x7
00 16 10ec 8139 0200 0b
PCI Scan: Found Bus 0, Device 23, Function 0
PCI Config: I/O=0x81000000, Memory=0x81000000, Command=0x7
00 17 8086 1209 0200 0c
PCI Scan: Found Bus 0, Device 24, Function 0
00 18 8086 1209 0200 0e
In: serial
Out: serial
Err: serial
U-Boot relocated to 03f8c000
DOC: No DiskOnChip found
Net: Bad trap at PC: fffffffc, SR: 1000, vector=800
NIP: FFFFFFFC XER: 00000000 LR: 00001288 REGS: 03f6bd00 TRAP: 0800 DAR:
00000000
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00000048 03F6BDF0 FFFFFF1F 03F6C1E8 00000000 00000006 00000000
01F3F7E0
GPR08: 03FCF1D8 BFFBF000 03FECC8C 0000000E 00000000 10019924 03FF2000
0408C000
GPR16: 00000000 00000000 00000000 00000000 00009032 00000001 00000000
C0005E28
GPR24: 03F6BF98 03F6BFC8 00000002 00000002 03F6C1E8 03F6BF98 03FF2788
03F6C1E8
Call backtrace:
Exception in kernel pc fffffffc signal 0
Exception in kernel pc fffffffc signal 0
then Uboot restart again.
U-Boot 1.1.2 (Jan 25 2005 - 14:55:00) [svm]
CPU: MPC8245 Revision 1.1 at 299.999 MHz: 16 kB I-Cache 16 kB D-Cache
Board: SVM_SC8245 Local Bus at 99.999 MHz
......................
In the meantime,if I re-power the board,it's running okay. I guess MMU not
fully reset. Platform_restart() maybe needs more jobs to do.
Here is my implement,
static void sc8245_restart(char *cmd){
ulong msr, addr;
/* Interrupts and MMU off */
__asm__ ("mtspr 81, 0");
/* Interrupts and MMU off */
__asm__ __volatile__ ("mfmsr %0":"=r" (msr):);
msr &= ~0x1030;
__asm__ __volatile__ ("mtmsr %0"::"r" (msr));
/*
* Trying to execute the next instruction at a non-existing address
* should cause a machine check, resulting in reset
*/
addr = 0xfff00100;
((void (*)(void)) addr) ();
return 1;
}
I do not have idea to get it settle. I knew you guys are very kind,so
,please help.
Thank you in advanced.
--
John Zhan.
^ permalink raw reply
* help: FCC_ENET OF MPC8250?
From: gqbenjamin @ 2005-07-13 2:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I use a device, like SMARTBITS, to test the Ethernet rate of mpc8250. The kernel is linux-2.4.20 with CONFIG_FCC_LXT971 and CONFIG_USE_MDIO, and do 'cat "1">/proc/sys/net/ipv4/ip_forward'.
If the rate of sending IP packet been set too high, for example 100 Mbps Full Duplex and each packet is 1514 Bytes. Later, the kernel print '... Memory squeeze, dropping packet' on uart. Stop sending IP packet and do 'cat /proc/meminfo', the *MemFree* become small.
Try again, the *MemFree* become smaller, just look like some allocated memory (skbuf) do not be free.
Final, the kernel break down, because all memory have been used.
Q. How can I do to let kernel do not break down? Is it a kernel promblem?
PS:
I use linux-2.6.5 on mpc8250 for the same test, and get the same result.
I change some code in file skbuff.c, use a memory pool that I created instead of allocating *skb* from *MemFree*, and do the same test. Final, the kernel can not transmit any IP packet, beacuse all space in the pool been used, but do not break down.
Thanks for your reading.
e-mail: gqben@sina.com gqbenjamin@163.com gqbenjamin@21cn.com
----------------------------------------------
vgoÌåÑé×ÀÃæ¿ì¸Ð£¬ÏíÊÜ¿íƵÀÖȤ£¡
http://vgo.21cn.com
µãÕâÀïÃâ·ÑÌåÑé·¢ËÍ4G´ó¸½¼þ
http://mail.21cn.com/huodong/0504/mail/
²ÊÆÁÊÖ»ú°×ËÍÀ²!¸Ï¿ìÀ´ÄÃ!
http://qipai.g.21cn.com
Öǻ۴óÌôÕ½¾ÍÔڵͼ۶ᱦ
http://super.21cn.com/
ÌåÑéÁíÀàÔ¼»á£¬¸ÐÊܱðÑùÀËÂþ
http://y.21cn.com/club/
СÁéͨ¶ÌÐÅÖÐÐÄ£¬¶ÌÐÅ÷ÈÁ¦ÎÞ¼«
http://pas.21cn.com/
È«ÄÜÁÄ2005°æÉÁÁÁµÇ³¡£¡
http://callme.21cn.com
^ permalink raw reply
* help: FCC_ENET OF MPC8250
From: gqbenjamin @ 2005-07-13 2:41 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I use a device, like SMARTBITS, to test the Ethernet rate of mpc8250. The kernel is linux-2.4.20 with CONFIG_FCC_LXT971 and CONFIG_USE_MDIO, and do 'cat "1">/proc/sys/net/ipv4/ip_forward'.
If the rate of sending IP packet been set too high, for example 100 Mbps Full Duplex and each packet is 1514 Bytes. Later, the kernel print '... Memory squeeze, dropping packet' on uart. Stop sending IP packet and do 'cat /proc/meminfo', the *MemFree* become small.
Try again, the *MemFree* become smaller, just look like some allocated memory (skbuf) do not be free.
Final, the kernel break down, because all memory have been used.
Q. How can I do to let kernel do not break down? Is it a kernel promblem?
PS:
I use linux-2.6.5 on mpc8250 for the same test, and get the same result.
I change some code in file skbuff.c, use a memory pool that I created instead of allocating *skb* from *MemFree*, and do the same test. Final, the kernel can not transmit any IP packet, beacuse all space in the pool been used, but do not break down.
Thanks for your reading.
e-mail: gqben@sina.com gqbenjamin@163.com gqbenjamin@21cn.com
----------------------------------------------
vgoÌåÑé×ÀÃæ¿ì¸Ð£¬ÏíÊÜ¿íƵÀÖȤ£¡
http://vgo.21cn.com
µãÕâÀïÃâ·ÑÌåÑé·¢ËÍ4G´ó¸½¼þ
http://mail.21cn.com/huodong/0504/mail/
²ÊÆÁÊÖ»ú°×ËÍÀ²!¸Ï¿ìÀ´ÄÃ!
http://qipai.g.21cn.com
Öǻ۴óÌôÕ½¾ÍÔڵͼ۶ᱦ
http://super.21cn.com/
ÌåÑéÁíÀàÔ¼»á£¬¸ÐÊܱðÑùÀËÂþ
http://y.21cn.com/club/
СÁéͨ¶ÌÐÅÖÐÐÄ£¬¶ÌÐÅ÷ÈÁ¦ÎÞ¼«
http://pas.21cn.com/
È«ÄÜÁÄ2005°æÉÁÁÁµÇ³¡£¡
http://callme.21cn.com
^ permalink raw reply
* Re: [PATCH] ppc32: fix destroy_context() race condition
From: Benjamin Herrenschmidt @ 2005-07-13 0:09 UTC (permalink / raw)
To: Guillaume Autran; +Cc: akpm, linuxppc-embedded
In-Reply-To: <42D3D277.106@mrv.com>
On Tue, 2005-07-12 at 10:23 -0400, Guillaume Autran wrote:
> Fix for a race condition when a task gets preempted by another task
> while executing the destroy_context(...) in a FEW_CONTEXTS environment.
> mm->context == NO_CONTEXT but the context_map may indicate all contexts
> are in use.
> The solution to this problem is to disable kernel preemption while
> destroying a MMU context.
>
> Signed-off-by: Guillaume Autran <gautran@mrv.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
>
> diff -Nru a/include/asm-ppc/mmu_context.h b/include/asm-ppc/mmu_context.h
> --- a/include/asm-ppc/mmu_context.h 2005-06-17 15:48:29.000000000 -0400
> +++ b/include/asm-ppc/mmu_context.h 2005-07-05 08:58:46.000000000 -0400
> @@ -149,6 +149,7 @@
> */
> static inline void destroy_context(struct mm_struct *mm)
> {
> + preempt_disable();
> if (mm->context != NO_CONTEXT) {
> clear_bit(mm->context, context_map);
> mm->context = NO_CONTEXT;
> @@ -156,6 +157,7 @@
> atomic_inc(&nr_free_contexts);
> #endif
> }
> + preempt_enable();
> }
>
> static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH] make -j12 all fails in uImage target
From: Tom Rini @ 2005-07-12 21:36 UTC (permalink / raw)
To: Olaf Hering; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20050712212928.GA6717@suse.de>
On Tue, Jul 12, 2005 at 11:29:28PM +0200, Olaf Hering wrote:
> On Sun, Feb 06, Olaf Hering wrote:
>
> >
> > this is what I got with 2.6.11rc3:
> >
> > make ARCH=ppc O=../O-2.6.11-rc3-b50-SMP -j12 all
> > ...
> > LD vmlinux
> > SYSMAP System.map
> > SYSMAP .tmp_System.map
> > OBJCOPY arch/ppc/boot/images/vmlinux.bin
> > HOSTCC arch/ppc/boot/utils/addnote
> > HOSTCC arch/ppc/boot/utils/mknote
> > HOSTCC arch/ppc/boot/utils/mkprep
> > LD arch/ppc/boot/lib/built-in.o
> > HOSTCC arch/ppc/boot/utils/hack-coff
> > HOSTCC arch/ppc/boot/utils/mkbugboot
> > OBJCOPY arch/ppc/boot/images/vmlinux.bin
> > GZIP arch/ppc/boot/images/vmlinux.gz
> > /bin/sh: line 1: arch/ppc/boot/images/vmlinux.bin: No such file or directory
> > make[2]: *** [arch/ppc/boot/images/vmlinux.gz] Error 1
> > make[1]: *** [uImage] Error 2
> > make[1]: *** Waiting for unfinished jobs....
> >
> > also, one time that zImage.chrp was only 570K instead of the expected
> > 1.4M, so netboot failed. But I got no build error.
>
>
> make -j zImage may call if_changed twice at the same time,
> the result is a corrupted vmlinux.gz
> write to a temporary file for the time being until someone with
> make skills fix the serialization properly.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
This is at least functional, so
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH] make -j12 all fails in uImage target
From: Olaf Hering @ 2005-07-12 21:29 UTC (permalink / raw)
To: Tom Rini, linuxppc-dev, Andrew Morton
In-Reply-To: <20050206124014.GA5880@suse.de>
On Sun, Feb 06, Olaf Hering wrote:
>
> this is what I got with 2.6.11rc3:
>
> make ARCH=ppc O=../O-2.6.11-rc3-b50-SMP -j12 all
> ...
> LD vmlinux
> SYSMAP System.map
> SYSMAP .tmp_System.map
> OBJCOPY arch/ppc/boot/images/vmlinux.bin
> HOSTCC arch/ppc/boot/utils/addnote
> HOSTCC arch/ppc/boot/utils/mknote
> HOSTCC arch/ppc/boot/utils/mkprep
> LD arch/ppc/boot/lib/built-in.o
> HOSTCC arch/ppc/boot/utils/hack-coff
> HOSTCC arch/ppc/boot/utils/mkbugboot
> OBJCOPY arch/ppc/boot/images/vmlinux.bin
> GZIP arch/ppc/boot/images/vmlinux.gz
> /bin/sh: line 1: arch/ppc/boot/images/vmlinux.bin: No such file or directory
> make[2]: *** [arch/ppc/boot/images/vmlinux.gz] Error 1
> make[1]: *** [uImage] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> also, one time that zImage.chrp was only 570K instead of the expected
> 1.4M, so netboot failed. But I got no build error.
make -j zImage may call if_changed twice at the same time,
the result is a corrupted vmlinux.gz
write to a temporary file for the time being until someone with
make skills fix the serialization properly.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/ppc/boot/images/Makefile | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6.13-rc2-olh/arch/ppc/boot/images/Makefile
===================================================================
--- linux-2.6.13-rc2-olh.orig/arch/ppc/boot/images/Makefile
+++ linux-2.6.13-rc2-olh/arch/ppc/boot/images/Makefile
@@ -6,12 +6,17 @@ MKIMAGE := $(srctree)/scripts/mkuboot.s
extra-y := vmlinux.bin vmlinux.gz
+# two make processes may write to vmlinux.gz at the same time with make -j
+quiet_cmd_mygzip = GZIP $@
+cmd_mygzip = gzip -f -9 < $< > $@.$$$$ && mv $@.$$$$ $@
+
+
OBJCOPYFLAGS_vmlinux.bin := -O binary
$(obj)/vmlinux.bin: vmlinux FORCE
$(call if_changed,objcopy)
$(obj)/vmlinux.gz: $(obj)/vmlinux.bin FORCE
- $(call if_changed,gzip)
+ $(call if_changed,mygzip)
quiet_cmd_uimage = UIMAGE $@
cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel \
^ permalink raw reply
* Re: MPC5200 Rev. B
From: Wolfgang Denk @ 2005-07-12 20:37 UTC (permalink / raw)
To: Matt_Berry; +Cc: linuxppc-embedded
In-Reply-To: <OF8B3EB35C.277E5E38-ON8525703C.0049B16F-8625703C.0049BF25@mksinst.com>
In message <OF8B3EB35C.277E5E38-ON8525703C.0049B16F-8625703C.0049BF25@mksinst.com> you wrote:
> When you refer to BAPI, are you referring to the BestComm?
Yes.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I am an atheist, thank God!
^ permalink raw reply
* Re: problem of load kernel after uncompressiong kernel Image .... (linuxppc 2.4.27)
From: Wolfgang Denk @ 2005-07-12 20:28 UTC (permalink / raw)
To: FLAMENT David; +Cc: linuxppc-dev
In-Reply-To: <892C3EC180087B4498C69413FCCBB7320159AE59@sof_msg>
In message <892C3EC180087B4498C69413FCCBB7320159AE59@sof_msg> you wrote:
>
> You can see, after uncompressing kernel, there are nothing !!!
And did you read the FAQ?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Question: How does one get fresh air into a Russian church?
Answer: One clicks on an icon, and a window opens!
^ permalink raw reply
* Re: [PATCH] ppc32: fix destroy_context() race condition
From: Eugene Surovegin @ 2005-07-12 18:45 UTC (permalink / raw)
To: Guillaume Autran; +Cc: akpm, linuxppc-embedded
In-Reply-To: <42D40BF0.6040605@mrv.com>
On Tue, Jul 12, 2005 at 02:29:04PM -0400, Guillaume Autran wrote:
> Eugene, destroy_context(..) can be called from other place outside of
> the scheduler and switch_mm(...). See mmdrop(...) for example.
> In many of those cases, the task will run with preemption enable.
Ahh, OK, you're right. Maybe it's worth mentioning in the patch
description :).
--
Eugene
^ permalink raw reply
* Re: [PATCH] ppc32: fix destroy_context() race condition
From: Guillaume Autran @ 2005-07-12 18:29 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: akpm, linuxppc-embedded
In-Reply-To: <20050712163921.GE25918@gate.ebshome.net>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
Eugene, destroy_context(..) can be called from other place outside of
the scheduler and switch_mm(...). See mmdrop(...) for example.
In many of those cases, the task will run with preemption enable.
Guillaume.
Eugene Surovegin wrote:
>On Tue, Jul 12, 2005 at 10:23:51AM -0400, Guillaume Autran wrote:
>
>
>>Fix for a race condition when a task gets preempted by another task
>>while executing the destroy_context(...) in a FEW_CONTEXTS environment.
>>mm->context == NO_CONTEXT but the context_map may indicate all contexts
>>are in use.
>>The solution to this problem is to disable kernel preemption while
>>destroying a MMU context.
>>
>>Signed-off-by: Guillaume Autran <gautran@mrv.com>
>>
>>---
>>
>>diff -Nru a/include/asm-ppc/mmu_context.h b/include/asm-ppc/mmu_context.h
>>--- a/include/asm-ppc/mmu_context.h 2005-06-17 15:48:29.000000000 -0400
>>+++ b/include/asm-ppc/mmu_context.h 2005-07-05 08:58:46.000000000 -0400
>>@@ -149,6 +149,7 @@
>>*/
>>static inline void destroy_context(struct mm_struct *mm)
>>{
>>+ preempt_disable();
>> if (mm->context != NO_CONTEXT) {
>> clear_bit(mm->context, context_map);
>> mm->context = NO_CONTEXT;
>>@@ -156,6 +157,7 @@
>> atomic_inc(&nr_free_contexts);
>>#endif
>> }
>>+ preempt_enable();
>>}
>>
>>static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>>
>>
>>
>
>Could you explain, why this patch is needed?
>
>AFAIK, destroy_context() is only called from switch_mm(), which in
>turn is called from schedule() with preemption already disabled. If
>not, IMHO we have bigger problems, and "fixing" destroy_context() will
>only hide such problems.
>
>
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 2432 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: fix destroy_context() race condition
From: Eugene Surovegin @ 2005-07-12 16:39 UTC (permalink / raw)
To: Guillaume Autran; +Cc: akpm, linuxppc-embedded
In-Reply-To: <42D3D277.106@mrv.com>
On Tue, Jul 12, 2005 at 10:23:51AM -0400, Guillaume Autran wrote:
> Fix for a race condition when a task gets preempted by another task
> while executing the destroy_context(...) in a FEW_CONTEXTS environment.
> mm->context == NO_CONTEXT but the context_map may indicate all contexts
> are in use.
> The solution to this problem is to disable kernel preemption while
> destroying a MMU context.
>
> Signed-off-by: Guillaume Autran <gautran@mrv.com>
>
> ---
>
> diff -Nru a/include/asm-ppc/mmu_context.h b/include/asm-ppc/mmu_context.h
> --- a/include/asm-ppc/mmu_context.h 2005-06-17 15:48:29.000000000 -0400
> +++ b/include/asm-ppc/mmu_context.h 2005-07-05 08:58:46.000000000 -0400
> @@ -149,6 +149,7 @@
> */
> static inline void destroy_context(struct mm_struct *mm)
> {
> + preempt_disable();
> if (mm->context != NO_CONTEXT) {
> clear_bit(mm->context, context_map);
> mm->context = NO_CONTEXT;
> @@ -156,6 +157,7 @@
> atomic_inc(&nr_free_contexts);
> #endif
> }
> + preempt_enable();
> }
>
> static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>
Could you explain, why this patch is needed?
AFAIK, destroy_context() is only called from switch_mm(), which in
turn is called from schedule() with preemption already disabled. If
not, IMHO we have bigger problems, and "fixing" destroy_context() will
only hide such problems.
--
Eugene
^ permalink raw reply
* problem of load kernel after uncompressiong kernel Image .... (linuxppc 2.4.27)
From: FLAMENT David @ 2005-07-12 14:39 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
Dear,
Here is my problems,
OS: kernel 2.4.27 linuxppc-embedded
platform: ppc rattler 8248
When I load a kernel image (uImage) with u-boot, the prompt of kernel is blocking
boot args kernel parameters :
"console=ttyS0,38400n8 nfsroot=/tftpboot/ppc_root rw ip=192.168.1.23:192.168.1.21::::eth0:off"
the screenshot of loading kernel :
TFTP from server 192.168.1.21; our IP address is 192.168.1.23
Filename 'uImage'.
Load address: 0x100000
Loading: #################################################################
#################################################################
############################
done
Bytes transferred = 803951 (c446f hex)
## Booting image at 00100000 ...
Image Name: Linux-2.4.27-pre1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 803887 Bytes = 785 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
You can see, after uncompressing kernel, there are nothing !!!
I try to use another kernel 2.4.26 with the same nfsroot and boot parameters and I can ping my target but not with linuxppc 2.4.27.
If you have an idea about this problem !! thank's.
note : I use a rattler 8248 with a 2.4.27 linuxppc kernel
Help me please !!!
--------------------------------
Flament David
d.flament@sofrel.com
Lacroix Sofrel, 1 rue plessis, 35770 Vern sur seiche (France)
(+33)2.99.04.84.23
[-- Attachment #2: Type: text/html, Size: 6080 bytes --]
^ permalink raw reply
* [PATCH] ppc32: fix destroy_context() race condition
From: Guillaume Autran @ 2005-07-12 14:23 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Fix for a race condition when a task gets preempted by another task
while executing the destroy_context(...) in a FEW_CONTEXTS environment.
mm->context == NO_CONTEXT but the context_map may indicate all contexts
are in use.
The solution to this problem is to disable kernel preemption while
destroying a MMU context.
Signed-off-by: Guillaume Autran <gautran@mrv.com>
---
diff -Nru a/include/asm-ppc/mmu_context.h b/include/asm-ppc/mmu_context.h
--- a/include/asm-ppc/mmu_context.h 2005-06-17 15:48:29.000000000 -0400
+++ b/include/asm-ppc/mmu_context.h 2005-07-05 08:58:46.000000000 -0400
@@ -149,6 +149,7 @@
*/
static inline void destroy_context(struct mm_struct *mm)
{
+ preempt_disable();
if (mm->context != NO_CONTEXT) {
clear_bit(mm->context, context_map);
mm->context = NO_CONTEXT;
@@ -156,6 +157,7 @@
atomic_inc(&nr_free_contexts);
#endif
}
+ preempt_enable();
}
static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
^ permalink raw reply
* Re: OLS 2005
From: Michael Richardson @ 2005-07-12 13:46 UTC (permalink / raw)
To: Greg KH; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <20050712042343.GA2363@kroah.com>
>>>>> "Greg" == Greg KH <greg@kroah.com> writes:
Greg> Sure, grab me, but I'll have just taught 6 hours of tutorials
Greg> and will probably want a beer or three :)
Beer can be provided.
^ permalink raw reply
* MPC5200 Rev. B
From: Matt_Berry @ 2005-07-12 13:25 UTC (permalink / raw)
To: linuxppc-embedded
When you refer to BAPI, are you referring to the BestComm?
Matthew Berry
MKS Instruments, Inc.
1321 Rutherford Lane, Suite 200
Austin, Texas 78753
Office: (512) 719-8048
Main: (512) 719-8000 x8048
Cell: (512) 203-7186
Fax: (512) 719-8096
^ permalink raw reply
* Re: OLS 2005
From: David Ho @ 2005-07-12 13:14 UTC (permalink / raw)
To: Grant Likely; +Cc: Greg KH, David Ho, linuxppc-embedded
In-Reply-To: <528646bc050711213439c1174a@mail.gmail.com>
Heads up for ppl coming to Ottawa next week, it is 34 degrees Celsius
all this week, and the weather has been like that for a few weeks.=20
It's gonna be hot and sweaty...
David
On 7/12/05, Grant Likely <glikely@gmail.com> wrote:
> On 7/11/05, Greg KH <greg@kroah.com> wrote:
> > On Mon, Jul 11, 2005 at 10:04:30PM -0600, Grant Likely wrote:
> > > On 7/6/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> > > > On Jul 6, 2005, at 12:49 PM, Grant Likely wrote:
> > > > > On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> > > > >
> > > > >> I wondering if we can get a PPC BoF together, ...
> > > The schedule is now posted on the OLS website. Thursday and Friday
> > > evenings are set for scheduled BOFs. Why don't we tentatively plan a=
n
> > > unoffical PPCembedded BOF Thursday evening?
> > >
> > > We should try to meet each other during the day Wednesday and choose =
a
> > > good time.
> > >
> > > > > I'd like to discuss the platform bus a bit. As was discussed a m=
onth
> > > > > or so ago, there is no clean way of matching multiple device driv=
ers
> > > > > to a single device type, like with PSCs on the MPC5200.
> > > > >
> > > > We should try to see if we can find GregKH to discuss what changes
> > > > would need to be made to the driver core to allow this.
> > > >
> > > How 'bout it Greg? Can we get some of your time?
> >
> > Sure, grab me, but I'll have just taught 6 hours of tutorials and will
> > probably want a beer or three :)
>=20
> Maybe I'll just need to buy you one of those beers to keep you cooperativ=
e.
>=20
> g.
> >
> > thanks,
> >
> > greg k-h
> >
>=20
>=20
> --
> "Why do musicians compose symphonies and poets write poems? They do it
> because life wouldn't have any meaning for them if they didn't.
> That's why I draw cartoons. It's my life."
>=20
> -- Charles Shultz
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: help me for: Oops: kernel access of bad area, sig: 11 on rattler 8248 (ppc)
From: Eugene Surovegin @ 2005-07-12 9:36 UTC (permalink / raw)
To: FLAMENT David; +Cc: linuxppc-dev
In-Reply-To: <892C3EC180087B4498C69413FCCBB7320159ADF0@sof_msg>
On Tue, Jul 12, 2005 at 10:07:52AM +0200, FLAMENT David wrote:
> Dear,
>
> Here is my problems,
>
> OS: kernel 2.4.26
> platform: ppc rattler 8248
Publicly available Linux PPC trees don't have support for this board.
Please, direct all your questions to the vendor you got this kernel
form, e.g. Arabella.
We cannot help you, sorry.
Also, next time, use linuxppc-embedded for questions like this.
--
Eugene
^ permalink raw reply
* last version of linuxppc-dev
From: FLAMENT David @ 2005-07-12 8:12 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 258 bytes --]
hello,
where it's possible to download the last version of linuxppc-dev to test this ?
thank's
--------------------------------
Flament David
d.flament@sofrel.com
Lacroix Sofrel, 1 rue plessis, 35770 Vern sur seiche (France)
(+33)2.99.04.84.23
[-- Attachment #2: Type: text/html, Size: 1125 bytes --]
^ permalink raw reply
* help me for: Oops: kernel access of bad area, sig: 11 on rattler 8248 (ppc)
From: FLAMENT David @ 2005-07-12 8:07 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]
Dear,
Here is my problems,
OS: kernel 2.4.26
platform: ppc rattler 8248
When we activate MPC82xxPCI in general setup of kernel config the following massages is printed :
Rattler Board Support by Arabella
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.26 (root@linux1.besoft.sofrel.com) (version gcc 3.2.2 20030217 (Yellow Dog Linux 3.0 3.5Rattler setup arch
rattler_setup_arch: bcsr=effff000
MPC82xx PCI bridge initialization
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: nfsroot=/tftpboot/ppc_root rw ip=192.168.1.23:192.168.1.21::::eth0:off
Rattler init IRQ. NR_IRQS=256
PIC: fully preemptible IRQ mode
Rattler time init
Rattler calibrate decrementer. FREQ=100000000, tb_ticks_per_jiffy=250000
Calibrating delay loop... 266.24 BogoMIPS
Memory: 30256k available (1488k kernel code, 520k data, 76k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Oops: kernel access of bad area, sig: 11
NIP: C01D3888 XER: 00000000 LR: C01D3880 SP: C02F1F50 REGS: c02f1ea0 TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000080, DSISR: 22000000
TASK = c02f0000[1] 'swapper' Last syscall: -1
last math 00000000 last altivec 00000000
GPR00: C01D3870 C02F1F50 C02F0000 F0000000 000018C1 C02F1F58 FFFFFFFF 00000000
GPR08: FFFFC4BA 1FFF0000 C01BB85B 00001057 22008022 3FDFF7AF 01FFE000 00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 003FF000 00000000 00000002 01BCA298
GPR24: 00000000 00000000 40000000 007FFF46 00000000 00000000 C01E0000 C01DB88C
Call backtrace:
C01D3870 C01C9474 C01D0CEC C01C66DC C0003970 C00083AC
Kernel panic: Attempted to kill init!
thanks for your suggest !
--------------------------------
Flament David
d.flament@sofrel.com
Lacroix Sofrel, 1 rue plessis, 35770 Vern sur seiche (France)
(+33)2.99.04.84.23
[-- Attachment #2: Type: text/html, Size: 5052 bytes --]
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: Segher Boessenkool @ 2005-07-12 8:02 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20050712020126.GE3945@localhost.localdomain>
>>> and forcing the user to
>>> split up these 64-bit quantities into cells is kind of silly.
>>
>> Hey, I didn't set that up! :-) There wasn't an existing
>> clean way to state 64 bit values, and an arbitrary list of
>> them. So I uh, leveraged the existing cell_t support!
>
> Cells make sense for the actual OF-like data, becayse they're an OF
> concept. For memreserve, which is purely Linux specific, they don't/
No. This is _not_ what is called a cell. "Cell" is a Forth concept.
A cell can be any size. Open Firmware puts the extra restriction on it
to be _at least_ 32 bits.
The thing you are referring to is what is called in OF
"32-bit integer property encoding format".
It is defined to always be 32-bit, and not the cell size of the
firmware,
so that you can use a 64-bit firmware with a 32-bit OS, and vice versa
(of course there could be different reasons why this isn't practical,
but
that's not the point).
In OF words, this format is normally abbreviated as "int".
Btw -- beware of the fact that such an "int" does _not_ have any
alignment restrictions -- so you better read it byte by byte...
Segher
^ permalink raw reply
* MPC5200-B Deep Sleep
From: Susheel Raj @ 2005-07-12 6:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
My name is Susheel, very new to this list. I am here
expecting some help from the members :-).
I am using the MPC5200-B (version 2) processor on
the board and I would like to make it go into "Deep
Sleep Mode"(Lets say DSM). I have been reading the
User Manual for the core and it has some support for
this DSM. If there is so can you guide me how to use
it, if not can anyone give me suggestions how to start
it, I am not an expert in such stuff, i felt life
would be more easier if i can use the suggestions of
some experienced guy :-)
Advance thanks and waiting for the response ..
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.
http://auctions.yahoo.com/
^ permalink raw reply
* Re: OLS 2005
From: Grant Likely @ 2005-07-12 4:34 UTC (permalink / raw)
To: Greg KH; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <20050712042343.GA2363@kroah.com>
On 7/11/05, Greg KH <greg@kroah.com> wrote:
> On Mon, Jul 11, 2005 at 10:04:30PM -0600, Grant Likely wrote:
> > On 7/6/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> > > On Jul 6, 2005, at 12:49 PM, Grant Likely wrote:
> > > > On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> > > >
> > > >> I wondering if we can get a PPC BoF together, ...
> > The schedule is now posted on the OLS website. Thursday and Friday
> > evenings are set for scheduled BOFs. Why don't we tentatively plan an
> > unoffical PPCembedded BOF Thursday evening?
> >
> > We should try to meet each other during the day Wednesday and choose a
> > good time.
> >
> > > > I'd like to discuss the platform bus a bit. As was discussed a mon=
th
> > > > or so ago, there is no clean way of matching multiple device driver=
s
> > > > to a single device type, like with PSCs on the MPC5200.
> > > >
> > > We should try to see if we can find GregKH to discuss what changes
> > > would need to be made to the driver core to allow this.
> > >
> > How 'bout it Greg? Can we get some of your time?
>=20
> Sure, grab me, but I'll have just taught 6 hours of tutorials and will
> probably want a beer or three :)
Maybe I'll just need to buy you one of those beers to keep you cooperative.
g.
>=20
> thanks,
>=20
> greg k-h
>=20
--=20
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life."
-- Charles Shultz
^ permalink raw reply
* Re: OLS 2005
From: Greg KH @ 2005-07-12 4:23 UTC (permalink / raw)
To: Grant Likely; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <528646bc050711210430374802@mail.gmail.com>
On Mon, Jul 11, 2005 at 10:04:30PM -0600, Grant Likely wrote:
> On 7/6/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> > On Jul 6, 2005, at 12:49 PM, Grant Likely wrote:
> > > On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> > >
> > >> I wondering if we can get a PPC BoF together, ...
> The schedule is now posted on the OLS website. Thursday and Friday
> evenings are set for scheduled BOFs. Why don't we tentatively plan an
> unoffical PPCembedded BOF Thursday evening?
>
> We should try to meet each other during the day Wednesday and choose a
> good time.
>
> > > I'd like to discuss the platform bus a bit. As was discussed a month
> > > or so ago, there is no clean way of matching multiple device drivers
> > > to a single device type, like with PSCs on the MPC5200.
> > >
> > We should try to see if we can find GregKH to discuss what changes
> > would need to be made to the driver core to allow this.
> >
> How 'bout it Greg? Can we get some of your time?
Sure, grab me, but I'll have just taught 6 hours of tutorials and will
probably want a beer or three :)
thanks,
greg k-h
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: David Gibson @ 2005-07-12 4:06 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1121116950.15394.14.camel@cashmere.sps.mot.com>
On Mon, Jul 11, 2005 at 04:22:30PM -0500, Jon Loeliger wrote:
> On Sun, 2005-07-10 at 23:55, David Gibson wrote:
> > On Fri, Jul 08, 2005 at 04:44:58PM -0500, Jon Loeliger wrote:
[snip]
> > Biggest thing is that rather than passing the tree itself and the
> > memreserve info about as two parameters all over the place, I'd rather
> > create a new structure which has both (and later can have anything
> > else that might be needed).
>
> If you'd like, I'll do this work.
That would be helpful. You'll need to rediff, though, I merged a
couple of bugfixes from your patch that weren't directly related to
the memreserve stuff.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: OLS 2005
From: Grant Likely @ 2005-07-12 4:04 UTC (permalink / raw)
To: Kumar Gala, greg; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <18C1CAA6-F980-4F8C-8FDD-E5D676D084ED@freescale.com>
On 7/6/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> On Jul 6, 2005, at 12:49 PM, Grant Likely wrote:
> > On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> >
> >> I wondering if we can get a PPC BoF together, ...
The schedule is now posted on the OLS website. Thursday and Friday
evenings are set for scheduled BOFs. Why don't we tentatively plan an
unoffical PPCembedded BOF Thursday evening?
We should try to meet each other during the day Wednesday and choose a
good time.
> > I'd like to discuss the platform bus a bit. As was discussed a month
> > or so ago, there is no clean way of matching multiple device drivers
> > to a single device type, like with PSCs on the MPC5200.
> >
> We should try to see if we can find GregKH to discuss what changes
> would need to be made to the driver core to allow this.
>=20
How 'bout it Greg? Can we get some of your time?
Cheers,
g.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox