LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] ppc32: platform-specific functions missing from kallsyms.
From: David Woodhouse @ 2005-05-02  8:28 UTC (permalink / raw)
  To: akpm; +Cc: linuxppc-dev
In-Reply-To: <1115020651.3287.0.camel@localhost.localdomain>

On Mon, 2005-05-02 at 08:57 +0100, David Woodhouse wrote:
> The PPC32 kernel puts platform-specific functions into separate sections
> so that unneeded parts of it can be freed when we've booted and actually
> worked out what we're running on today. 
> 
> This makes kallsyms ignore those functions, because they're not between
> _[se]text or _[se]inittext. Rather than teaching kallsyms about the
> various pmac/chrp/etc sections, this patch adds '_[se]extratext' markers
> for kallsyms.
> 
> Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
> 
> --- linux-2.6.11/arch/ppc/kernel/vmlinux.lds~	2005-05-01 10:43:10.000000000 +0100
> +++ linux-2.6.11/arch/ppc/kernel/vmlinux.lds	2005-05-02 08:06:52.000000000 +0100

Bah. s/vmlinux.lds/vmlinux.lds.S/

--- linux-2.6.11/arch/ppc/kernel/vmlinux.lds.S~	2005-05-01 10:43:10.000000000 +0100
+++ linux-2.6.11/arch/ppc/kernel/vmlinux.lds.S	2005-05-02 08:06:52.000000000 +0100
@@ -147,6 +147,7 @@ SECTIONS
   __init_end = .;
 
   . = ALIGN(4096);
+  _sextratext = .;
   __pmac_begin = .;
   .pmac.text : { *(.pmac.text) }
   .pmac.data : { *(.pmac.data) }
@@ -173,6 +174,7 @@ SECTIONS
   .openfirmware.data : { *(.openfirmware.data) }
   . = ALIGN(4096);
   __openfirmware_end = .;
+  _eextratext = .;
 
   __bss_start = .;
   .bss :
--- linux-2.6.11/include/asm-generic/sections.h~	2005-03-02 07:37:31.000000000 +0000
+++ linux-2.6.11/include/asm-generic/sections.h	2005-05-02 08:43:04.000000000 +0100
@@ -8,6 +8,8 @@ extern char _data[], _sdata[], _edata[];
 extern char __bss_start[], __bss_stop[];
 extern char __init_begin[], __init_end[];
 extern char _sinittext[], _einittext[];
+extern char _sextratext[] __attribute__((weak));
+extern char _eextratext[] __attribute__((weak));
 extern char _end[];
 
 #endif /* _ASM_GENERIC_SECTIONS_H_ */
--- linux-2.6.11/scripts/kallsyms.c~	2005-03-02 07:38:33.000000000 +0000
+++ linux-2.6.11/scripts/kallsyms.c	2005-05-02 08:09:11.000000000 +0100
@@ -67,7 +67,7 @@ struct sym_entry {
 
 static struct sym_entry *table;
 static int size, cnt;
-static unsigned long long _stext, _etext, _sinittext, _einittext;
+static unsigned long long _stext, _etext, _sinittext, _einittext, _sextratext, _eextratext;
 static int all_symbols = 0;
 
 struct token {
@@ -132,6 +132,10 @@ read_symbol(FILE *in, struct sym_entry *
 		_sinittext = s->addr;
 	else if (strcmp(str, "_einittext") == 0)
 		_einittext = s->addr;
+	else if (strcmp(str, "_sextratext") == 0)
+		_sextratext = s->addr;
+	else if (strcmp(str, "_eextratext") == 0)
+		_eextratext = s->addr;
 	else if (toupper(s->type) == 'A')
 	{
 		/* Keep these useful absolute symbols */
@@ -182,16 +186,18 @@ symbol_valid(struct sym_entry *s)
 	 * and inittext sections are discarded */
 	if (!all_symbols) {
 		if ((s->addr < _stext || s->addr > _etext)
-		    && (s->addr < _sinittext || s->addr > _einittext))
+		    && (s->addr < _sinittext || s->addr > _einittext) 
+		    && (s->addr < _sextratext || s->addr > _eextratext))
 			return 0;
 		/* Corner case.  Discard any symbols with the same value as
-		 * _etext or _einittext, they can move between pass 1 and 2
-		 * when the kallsyms data is added.  If these symbols move then
-		 * they may get dropped in pass 2, which breaks the kallsyms
-		 * rules.
+		 * _etext _einittext or _eextratext; they can move between pass 
+		 * 1 and 2 when the kallsyms data is added.  If these symbols 
+		 * move then they may get dropped in pass 2, which breaks the
+		 * kallsyms rules.
 		 */
 		if ((s->addr == _etext && strcmp(s->sym + 1, "_etext")) ||
-		    (s->addr == _einittext && strcmp(s->sym + 1, "_einittext")))
+		    (s->addr == _einittext && strcmp(s->sym + 1, "_einittext")) ||
+		    (s->addr == _eextratext && strcmp(s->sym + 1, "_eextratext")))
 			return 0;
 	}
 
--- linux-2.6.11/kernel/kallsyms.c~	2005-05-01 10:37:45.000000000 +0100
+++ linux-2.6.11/kernel/kallsyms.c	2005-05-02 08:42:59.000000000 +0100
@@ -46,6 +46,14 @@ static inline int is_kernel_inittext(uns
 	return 0;
 }
 
+static inline int is_kernel_extratext(unsigned long addr)
+{
+	if (addr >= (unsigned long)_sextratext
+	    && addr <= (unsigned long)_eextratext)
+		return 1;
+	return 0;
+}
+
 static inline int is_kernel_text(unsigned long addr)
 {
 	if (addr >= (unsigned long)_stext && addr <= (unsigned long)_etext)
@@ -169,7 +177,7 @@ const char *kallsyms_lookup(unsigned lon
 	namebuf[0] = 0;
 
 	if ((all_var && is_kernel(addr)) ||
-	    (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr)))) {
+	    (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr) || is_kernel_extratext(addr)))) {
 		unsigned long symbol_end=0;
 
 		/* do a binary search on the sorted kallsyms_addresses array */

-- 
dwmw2

^ permalink raw reply

* RE: Performance issue - VoIP application on Linux 2.4.22
From: Fillod Stephane @ 2005-05-02  8:36 UTC (permalink / raw)
  To: bobys, linuxppc-embedded

bobys wrote:
>Hello everybody,
>I have a multithreaded VoIP application in user space and a kernel
driver
>module on MPC 8248 based board.
>During media data transfer( Video Call) I have observed one strange
>behavior
>that at specific interval, cpu utilization is reaching to 100 % and
then
>rolls back to 0 %.  This behavior repeats at regular intervals of time
>during the call.
>During this time, data rate and memory utilization is constant
throughout
>the Call. Also number of interrupts received and processed in the
kernel
>driver is constant.  We have checked the code many times, but couldn't
find
>any of the threads/driver hogging the processor time.
>We are using Linux kernel 2.4.22  with kernel preemption enabled and
low
>latency patch added. Please let me know anybody have seen same behavior
and
>how to sort this out.

I have no idea with 2.4.x. However, if you have OProfile[1] support
available in your kernel (look for custom module on 2.4), that's quite
easy=20
to spot the cpu utilization burst.

[1] http://oprofile.sf.net


Best Regards
--=20
Stephane

PS: OProfile is a neat tool. We won't thank enough the OProfile team.

^ permalink raw reply

* Ethernet bridging on MPC8248
From: Ole Andreas Torvmark @ 2005-05-02  9:28 UTC (permalink / raw)
  To: linuxppc-embedded

Hi !

I've a custom board with a MPC8248 with two LXT972 10/100MBit ethernet phys.

The board is running 2.6.9-rc1, and I'm using the FCC ENET Version 0.3 
driver with some modifications.

My question is :

I've tried to get ethernet briding between the two ethernet ports to work.

I've set up the following :

ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 192.168.0.222 netmask 255.255.255.0

If I connect a machine to port 0 (eth0) then I can ping the bridge from 
that machine,
If I connect a machine to port 1 (eth1) I cannot ping the bridge.
If I connect machines to both ports, I cannot ping one machine from the 
other, the only thing i can successfully ping is from port 0 to bridge 
and from bridge to port 0

Is this a known problem with the FCC ENET driver or does it support 
bridging fully ?

best regards

Ole Andreas Torvmark
R & D Engineer
Radionor Communications AS

^ permalink raw reply

* Re: 2.6.12-rc3-mm2: ppc pte_offset_map()
From: Hugh Dickins @ 2005-05-02 10:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: rbrito, linuxppc-dev, Jesper Juhl, linux-kernel
In-Reply-To: <20050501154654.2bf7606d.akpm@osdl.org>

On Sun, 1 May 2005, Andrew Morton wrote:
> Jesper Juhl <juhl-lkml@dif.dk> wrote:
> > 
> > --- linux-2.6.12-rc3-mm2-orig/fs/proc/task_mmu.c	2005-05-01 04:04:25.000000000 +0200
> > +++ linux-2.6.12-rc3-mm2/fs/proc/task_mmu.c	2005-05-01 17:49:14.000000000 +0200
> > @@ -2,6 +2,7 @@
> >  #include <linux/hugetlb.h>
> >  #include <linux/mount.h>
> >  #include <linux/seq_file.h>
> > +#include <linux/highmem.h>
> >  
> >  #include <asm/elf.h>
> >  #include <asm/uaccess.h>
> > @@ -204,7 +205,7 @@ static void smaps_pte_range(pmd_t *pmd,
> >  			}
> >  		}
> >  	} while (address < end);
> > -	pte_unmap(pte);
> > +	pte_unmap((void *)pte);
> >  }
> 
> Should be
> 
> 	pte_unmap(ptep);

Almost.  Should be

	pte_unmap(ptep - 1);

^ permalink raw reply

* Re: Memory Usage Growth in File access
From: Wolfgang Denk @ 2005-05-02 10:28 UTC (permalink / raw)
  To: s.deepak; +Cc: linuxppc-embedded
In-Reply-To: <02cb01c54ee3$87e93ec0$4000a8c0@DeepakS>

In message <02cb01c54ee3$87e93ec0$4000a8c0@DeepakS> you wrote:
>
> I am  facing an issue in file operation, when we read/write continuously
> to  a large file in our  ppc 405 based device , memory usage shown in
> /proc/meminfo   increases by the number of bytes accessed.And after
> closing the application also the memory used is not released and  it
> goes to cached memory .

Welcome to the world of efficient use of resources.

What you see is perfectly normal behaviour and  one  of  the  reasons
that LInux provides excellent performance.

> Can anyone suggest me some idea how to trace out the problem.

There is no problem. What you see is normal the way it  was  designed
to work.

> When i run the below given code first time the memory grows,when  i run
> succesively it doesn't grow again , may be using the already taken
> memory.

Indeed. Also if you have a way to  trace  accesses  to  your  storage
media  you  will see that the secondrun needs much less accesses, and
is faster, too.

Welcome to Unix.

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
Today is the yesterday you worried about tomorrow.

^ permalink raw reply

* Linux 2.4.25 from ELDK 3.1 won't compile
From: Peter Asemann @ 2005-05-02 13:25 UTC (permalink / raw)
  To: linuxppc-embedded

I still didn't manage to compile a kernel. Though I unselected as much 
features as I could, the compiler still isn't happy. Any ideas?

Peter Asemann


make[1]: Entering directory 
`/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/arch/ppc/kernel'

(...)

ppc_8xx-gcc -D__KERNEL__ 
-I/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer 
-I/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/arch/ppc -fsigned-char 
-msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring 
-nostdinc -I /opt/asemann/eldk/usr/lib/gcc-lib/ppc-linux/3.3.3/include 
-DKBUILD_BASENAME=m8xx_setup  -c -o m8xx_setup.o m8xx_setup.c
m8xx_setup.c:64: error: `bd_t' undeclared here (not in a function)
m8xx_setup.c: In function `m8xx_calibrate_decr':
m8xx_setup.c:192: error: `bd_t' undeclared (first use in this function)
m8xx_setup.c:192: error: (Each undeclared identifier is reported only once
m8xx_setup.c:192: error: for each function it appears in.)
m8xx_setup.c:192: error: `binfo' undeclared (first use in this function)
m8xx_setup.c:192: error: parse error before ')' token
m8xx_setup.c:196: error: `IMAP_ADDR' undeclared (first use in this function)
m8xx_setup.c: In function `m8xx_set_rtc_time':
m8xx_setup.c:269: error: `IMAP_ADDR' undeclared (first use in this function)
m8xx_setup.c: In function `m8xx_get_rtc_time':
m8xx_setup.c:279: error: `IMAP_ADDR' undeclared (first use in this function)
m8xx_setup.c: In function `m8xx_restart':
m8xx_setup.c:288: error: `IMAP_ADDR' undeclared (first use in this function)
m8xx_setup.c: In function `m8xx_show_percpuinfo':
m8xx_setup.c:317: error: `bd_t' undeclared (first use in this function)
m8xx_setup.c:317: error: `bp' undeclared (first use in this function)
m8xx_setup.c:319: error: parse error before ')' token
m8xx_setup.c: In function `m8xx_find_end_of_memory':
m8xx_setup.c:377: error: `bd_t' undeclared (first use in this function)
m8xx_setup.c:377: error: `binfo' undeclared (first use in this function)
m8xx_setup.c:380: error: parse error before ')' token
m8xx_setup.c:378: warning: unused variable `__res'
m8xx_setup.c: In function `m8xx_map_io':
m8xx_setup.c:394: error: `IMAP_ADDR' undeclared (first use in this function)
m8xx_setup.c:394: error: `IMAP_SIZE' undeclared (first use in this function)
m8xx_setup.c: In function `platform_init':
m8xx_setup.c:441: error: `bd_t' undeclared (first use in this function)
make[1]: *** [m8xx_setup.o] Error 1
make[1]: Leaving directory 
`/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/arch/ppc/kernel'
make: *** [_dir_arch/ppc/kernel] Error 2

^ permalink raw reply

* Re: Linux 2.4.25 from ELDK 3.1 won't compile
From: Frank @ 2005-05-02 14:18 UTC (permalink / raw)
  To: Peter Asemann, linuxppc-embedded


--- Peter Asemann <peter.asemann@web.de> wrote:
> I still didn't manage to compile a kernel. Though I unselected
> as much 
> features as I could, the compiler still isn't happy. Any
> ideas?
> 
> Peter Asemann
> 
> 
> make[1]: Entering directory 
>
`/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/arch/ppc/kernel'
> 
> (...)
> 
> ppc_8xx-gcc -D__KERNEL__ 
> -I/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/include -Wall
> 
> -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
> -fno-common 
> -fomit-frame-pointer 
> -I/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/arch/ppc
> -fsigned-char 
> -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple
> -mstring 
> -nostdinc -I
> /opt/asemann/eldk/usr/lib/gcc-lib/ppc-linux/3.3.3/include 
> -DKBUILD_BASENAME=m8xx_setup  -c -o m8xx_setup.o m8xx_setup.c
> m8xx_setup.c:64: error: `bd_t' undeclared here (not in a
> function)
> m8xx_setup.c: In function `m8xx_calibrate_decr':
> m8xx_setup.c:192: error: `bd_t' undeclared (first use in this
> function)
> m8xx_setup.c:192: error: (Each undeclared identifier is
> reported only once
> m8xx_setup.c:192: error: for each function it appears in.)
> m8xx_setup.c:192: error: `binfo' undeclared (first use in this
> function)
> m8xx_setup.c:192: error: parse error before ')' token
> m8xx_setup.c:196: error: `IMAP_ADDR' undeclared (first use in

You have to define IMAP_ADDR in your platform header file. Take
a look at arch/ppc/platforms/tqm8xx.h


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply

* Re: Linux 2.4.25 from ELDK 3.1 won't compile
From: Wolfgang Denk @ 2005-05-02 14:40 UTC (permalink / raw)
  To: Peter Asemann; +Cc: linuxppc-embedded
In-Reply-To: <42762A58.7090104@web.de>

In message <42762A58.7090104@web.de> you wrote:
> I still didn't manage to compile a kernel. Though I unselected as much 
> features as I could, the compiler still isn't happy. Any ideas?

Which board are you using? Are you sure that  the  board  support  is
complete  and  working?  Is  there  a  default configuration for your
board? Does this one work?

Did you RTFM (the DULG, to be precise) ?

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
Status quo. Latin for "the mess we're in."

^ permalink raw reply

* MPC5200 I2S Driver -- where?
From: roger blofeld @ 2005-05-02 14:53 UTC (permalink / raw)
  To: linuxppc-embedded

Hi,
 A few weeks ago a simple I2S driver was discussed on this list. Is
that driver available for download anywhere? I'd like to try it out
with a simple DAC I have connected to an IceCube board.

Thanks
-roger


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply

* Re: MPC5200 I2S Driver -- where?
From: White_Angel @ 2005-05-02 15:11 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20050502145326.80965.qmail@web53504.mail.yahoo.com>

I see it in the Metrowerks BSP included Kernel...

Would be fine to report, if you get it working...

Am Mon, 2 May 2005 07:53:25 -0700 (PDT) schrieb roger blofeld
<blofeldus@yahoo.com> :

> Hi,
>  A few weeks ago a simple I2S driver was discussed on this list. Is
> that driver available for download anywhere? I'd like to try it out
> with a simple DAC I have connected to an IceCube board.
> 
> Thanks
> -roger

^ permalink raw reply

* Endian Issue?
From: Sanjay Bajaj @ 2005-05-02 21:27 UTC (permalink / raw)
  To: linuxppc-dev

We have linux (lk2.4.27-pre3) running on PPC440GX processor. The =
processor is connected to the Local PCI bus and to our custom device on =
this PCI bus. When we perform the DMA (or for that matter do =
memcpy_fromio()) from PCI bus memory to processor local memory, the data =
in the processor local memory is flipped (4 bytes at a time). Has anyone =
confronted this issue? Any ideas...

Thanks,
Sanjay

^ permalink raw reply

* Re: Endian Issue?
From: Benjamin Herrenschmidt @ 2005-05-02 22:07 UTC (permalink / raw)
  To: Sanjay Bajaj; +Cc: linuxppc-dev
In-Reply-To: <0007F077BB3476449151699150E8FEA20592DE@exchange.tsi-telsys.com>

On Mon, 2005-05-02 at 17:27 -0400, Sanjay Bajaj wrote:
> We have linux (lk2.4.27-pre3) running on PPC440GX processor. The processor is connected to the Local PCI bus and to our custom device on this PCI bus. When we perform the DMA (or for that matter do memcpy_fromio()) from PCI bus memory to processor local memory, the data in the processor local memory is flipped (4 bytes at a time). Has anyone confronted this issue? Any ideas...

Using your device own DMA capabilities ? could be your device beeing
bogus, or your PCI bus incorrectly wired ...

Ben.

^ permalink raw reply

* Laptop sleep & current "git" tree
From: Benjamin Herrenschmidt @ 2005-05-02 22:15 UTC (permalink / raw)
  To: linuxppc-dev list, DebianPPC

Hi folks !

All my pending patches regarding power management are now upstream in
Linus "git" repository. That means I expect those to fix all known
issues (with the notable exception of the USB related problems, all of
these things aren't yet there but they aren't under my control, so still
unplug USB devices).

I would appreciate extensive testing, provided you figure out how to
retreive the "git" repository from kernel.org :) There must be some
howto somewhere, but I'm afraid I don't have a link at hand.

For those who can't dare experimenting with that new git toy, best may
be for you to wait for 2.6.12-rc4 which will contain all of these.

Cheers,
Ben.

^ permalink raw reply

* CONFIG_PIN_TLB experiments
From: Marcelo Tosatti @ 2005-05-02 20:42 UTC (permalink / raw)
  To: Dan Malek, linux-ppc-embedded


Hi 8xx folks,

I've been testing the CONFIG_PIN_TLB option under v2.6, results are not good. 

The 8Mbyte TLB entries do not seem to work as expected, they do not 
cover the regions which they claim to. Accesses inside the region 
covered by pinned 8Mb TLB result in pagefaults and 4kb entries getting
created.

Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only 
28 usable TLB's instead of 32).


v2.6 CONFIG_PIN_TLB:
I-TLB userspace misses: 162113
I-TLB kernel misses: 135911
D-TLB userspace misses: 289452
D-TLB kernel misses: 257039

v2.6 without CONFIG_PIN_TLB:
I-TLB userspace misses: 160828
I-TLB kernel misses: 134746
D-TLB userspace misses: 253557
D-TLB kernel misses: 227383


The following BDI output shows the pinned, 8MByte data page mapping present,
at 0xc0000000.

BDI>rds 826
SPR  826 : 0x00007f00        32512
BDI>rms 792 0x0c001C00
BDI>rms 824 1
BDI>rds 824
SPR  824 : 0xc00000f0  -1073741584
BDI>rds 825
SPR  825 : 0x00000fe0         4064
BDI>rds 826
SPR  826 : 0x00007fff        32767       <- "0x00007fff" was 0x00007f00" initially. 
				             I tried enabling usermode access without
					     success.

There are several 4Kb mappings inside the range covered by this 8Mb TLB entry, 
for example: 

BDI>rms 792 0x0c000200
BDI>rms 824 1
BDI>rds 824
SPR  824 : 0xc0224f17  -1071493353
BDI>rds 825
SPR  825 : 0x002241e0      2245088
BDI>rds 826
SPR  826 : 0x00007f00        32512

And more, without so much detail:
SPR  824 : 0xc0224f17  -1071493353
SPR  824 : 0xc01fbf17  -1071661289
SPR  824 : 0xc0246f17  -1071354089
SPR  824 : 0xc023ff17  -1071382761
SPR  824 : 0xc7e35f17  - 941400297
SPR  824 : 0xc0244f17  -1071362281
SPR  824 : 0xc023ef17  -1071386857

Note that protection (SPR 826) is exactly the same as the 8Mbyte page protection. 

Why is the translation mechanism rejection the pinned mappings? 

Dan, have you ever seen this work? Am I misunderstanding how the pinned
entries are supposed to work? 

^ permalink raw reply

* Re: [PATCH] ppc32: platform-specific functions missing from kallsyms.
From: Andrew Morton @ 2005-05-03  1:37 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1115020651.3287.0.camel@localhost.localdomain>

David Woodhouse <dwmw2@infradead.org> wrote:
>
> The PPC32 kernel puts platform-specific functions into separate sections
>  so that unneeded parts of it can be freed when we've booted and actually
>  worked out what we're running on today. 
> 
>  This makes kallsyms ignore those functions, because they're not between
>  _[se]text or _[se]inittext. Rather than teaching kallsyms about the
>  various pmac/chrp/etc sections, this patch adds '_[se]extratext' markers
>  for kallsyms.
> 

Current kernels have fixes in exactly this area.  Please redo, retest, resend.

> 
>  --- linux-2.6.11/arch/ppc/kernel/vmlinux.lds~	2005-05-01 10:43:10.000000000 +0100
>  +++ linux-2.6.11/arch/ppc/kernel/vmlinux.lds	2005-05-02 08:06:52.000000000 +0100

2.6.11?  Wow.

^ permalink raw reply

* Re: Ethernet bridging on MPC8248
From: jbi130 @ 2005-05-03  6:15 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <4275F2BB.9050100@radionor.no>

Ole Andreas Torvmark <ole.torvmark@radionor.no> writes:

> ifconfig eth0 0.0.0.0
> ifconfig eth1 0.0.0.0
> brctl addbr br0
> brctl addif br0 eth0
> brctl addif br0 eth1
> ifconfig br0 192.168.0.222 netmask 255.255.255.0
> 
> If I connect a machine to port 0 (eth0) then I can ping the bridge
> from that machine,
> 
> If I connect a machine to port 1 (eth1) I cannot ping the bridge.
> If I connect machines to both ports, I cannot ping one machine from
> the other, the only thing i can successfully ping is from port 0 to
> bridge and from bridge to port 0
> 
> Is this a known problem with the FCC ENET driver or does it support
> bridging fully ?

Have you made sure that eth0 and eth1 are 'up'?  eg) ifconfig eth0 up.
I'm not sure, but br0 may need to be up as well.

^ permalink raw reply

* RE: Ethernet bridging on MPC8248
From: Bastos Fernandez Alexandre @ 2005-05-03  6:24 UTC (permalink / raw)
  To: 'Ole Andreas Torvmark'; +Cc: linuxppc-embedded

Hi Ole,

Maybe those mails from archives would answer your questions. As long as
I know this is still present in kernel:

http://ozlabs.org/pipermail/linuxppc-embedded/2004-October/015617.html
http://ozlabs.org/pipermail/linuxppc-embedded/2004-October/015620.html

So, you have to change set_multicast_list to support the promiscous mode
needed by your bridge.

Best regards,

Alex.

> -----Original Message-----
> From:	Ole Andreas Torvmark [SMTP:ole.torvmark@radionor.no]
> Sent:	Monday, May 02, 2005 11:28 AM
> To:	linuxppc-embedded@ozlabs.org
> Subject:	Ethernet bridging on MPC8248
> 
> Hi !
> 
> I've a custom board with a MPC8248 with two LXT972 10/100MBit ethernet
> phys.
> 
> The board is running 2.6.9-rc1, and I'm using the FCC ENET Version 0.3 
> driver with some modifications.
> 
> My question is :
> 
> I've tried to get ethernet briding between the two ethernet ports to work.
> 
> I've set up the following :
> 
> ifconfig eth0 0.0.0.0
> ifconfig eth1 0.0.0.0
> brctl addbr br0
> brctl addif br0 eth0
> brctl addif br0 eth1
> ifconfig br0 192.168.0.222 netmask 255.255.255.0
> 
> If I connect a machine to port 0 (eth0) then I can ping the bridge from 
> that machine,
> If I connect a machine to port 1 (eth1) I cannot ping the bridge.
> If I connect machines to both ports, I cannot ping one machine from the 
> other, the only thing i can successfully ping is from port 0 to bridge 
> and from bridge to port 0
> 
> Is this a known problem with the FCC ENET driver or does it support 
> bridging fully ?
> 
> best regards
> 
> Ole Andreas Torvmark
> R & D Engineer
> Radionor Communications AS
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: [PATCH] ppc32: platform-specific functions missing from kallsyms.
From: David Woodhouse @ 2005-05-03  7:59 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20050502183733.52db7703.akpm@osdl.org>

On Mon, 2005-05-02 at 18:37 -0700, Andrew Morton wrote:
> 2.6.11?  Wow.

Actually 2.6.11-1.1283_FC4; the Fedora kernel. It's at least 2.6.12-rc3,
and Dave had been tracking Linus' tree fairly actively -- but I suspect
he may have fallen behind in the absence of nightly git snapshots. Must
fix that now we have tags.

Here it is updated to the current git tree and compile-tested.

Index: arch/ppc/kernel/vmlinux.lds.S
===================================================================
--- 226896c455d8a4996527c4a0ec5699956c657ec3/arch/ppc/kernel/vmlinux.lds.S  (mode:100644 sha1:0c0e714b84de74febf1f4dcb59eb1a859902deac)
+++ uncommitted/arch/ppc/kernel/vmlinux.lds.S  (mode:100644)
@@ -145,6 +145,7 @@
   __init_end = .;
 
   . = ALIGN(4096);
+  _sextratext = .;
   __pmac_begin = .;
   .pmac.text : { *(.pmac.text) }
   .pmac.data : { *(.pmac.data) }
@@ -171,6 +172,7 @@
   .openfirmware.data : { *(.openfirmware.data) }
   . = ALIGN(4096);
   __openfirmware_end = .;
+  _eextratext = .;
 
   __bss_start = .;
   .bss       :
Index: include/asm-generic/sections.h
===================================================================
--- 226896c455d8a4996527c4a0ec5699956c657ec3/include/asm-generic/sections.h  (mode:100644 sha1:976ac29598b78d0b2c0c90516480e93434d8f506)
+++ uncommitted/include/asm-generic/sections.h  (mode:100644)
@@ -8,6 +8,8 @@
 extern char __bss_start[], __bss_stop[];
 extern char __init_begin[], __init_end[];
 extern char _sinittext[], _einittext[];
+extern char _sextratext[] __attribute__((weak));
+extern char _eextratext[] __attribute__((weak));
 extern char _end[];
 
 #endif /* _ASM_GENERIC_SECTIONS_H_ */
Index: kernel/kallsyms.c
===================================================================
--- 226896c455d8a4996527c4a0ec5699956c657ec3/kernel/kallsyms.c  (mode:100644 sha1:1627f8d6e0cdd5f918c30666f4434407df25c293)
+++ uncommitted/kernel/kallsyms.c  (mode:100644)
@@ -46,6 +46,14 @@
 	return 0;
 }
 
+static inline int is_kernel_extratext(unsigned long addr)
+{
+	if (addr >= (unsigned long)_sextratext
+	    && addr <= (unsigned long)_eextratext)
+		return 1;
+	return 0;
+}
+
 static inline int is_kernel_text(unsigned long addr)
 {
 	if (addr >= (unsigned long)_stext && addr <= (unsigned long)_etext)
@@ -169,7 +177,7 @@
 	namebuf[0] = 0;
 
 	if ((all_var && is_kernel(addr)) ||
-	    (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr)))) {
+	    (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr) || is_kernel_extratext(addr)))) {
 		unsigned long symbol_end=0;
 
 		/* do a binary search on the sorted kallsyms_addresses array */
Index: scripts/kallsyms.c
===================================================================
--- 226896c455d8a4996527c4a0ec5699956c657ec3/scripts/kallsyms.c  (mode:100644 sha1:fe11df83d1fc91b3e6de8a7bdc4a06e25f3d0e2f)
+++ uncommitted/scripts/kallsyms.c  (mode:100644)
@@ -67,7 +67,7 @@
 
 static struct sym_entry *table;
 static int size, cnt;
-static unsigned long long _stext, _etext, _sinittext, _einittext;
+static unsigned long long _stext, _etext, _sinittext, _einittext, _sextratext, _eextratext;
 static int all_symbols = 0;
 static char symbol_prefix_char = '\0';
 
@@ -139,6 +139,10 @@
 		_sinittext = s->addr;
 	else if (strcmp(sym, "_einittext") == 0)
 		_einittext = s->addr;
+	else if (strcmp(sym, "_sextratext") == 0)
+		_sextratext = s->addr;
+	else if (strcmp(sym, "_eextratext") == 0)
+		_eextratext = s->addr;
 	else if (toupper(s->type) == 'A')
 	{
 		/* Keep these useful absolute symbols */
@@ -194,16 +198,18 @@
 	 * and inittext sections are discarded */
 	if (!all_symbols) {
 		if ((s->addr < _stext || s->addr > _etext)
-		    && (s->addr < _sinittext || s->addr > _einittext))
+		    && (s->addr < _sinittext || s->addr > _einittext)
+		    && (s->addr < _sextratext || s->addr > _eextratext))
 			return 0;
 		/* Corner case.  Discard any symbols with the same value as
-		 * _etext or _einittext, they can move between pass 1 and 2
-		 * when the kallsyms data is added.  If these symbols move then
-		 * they may get dropped in pass 2, which breaks the kallsyms
-		 * rules.
+		 * _etext _einittext or _eextratext; they can move between pass
+		 * 1 and 2 when the kallsyms data are added.  If these symbols
+		 * move then they may get dropped in pass 2, which breaks the
+		 * kallsyms rules.
 		 */
 		if ((s->addr == _etext && strcmp(s->sym + offset, "_etext")) ||
-		    (s->addr == _einittext && strcmp(s->sym + offset, "_einittext")))
+		    (s->addr == _einittext && strcmp(s->sym + offset, "_einittext")) ||
+		    (s->addr == _eextratext && strcmp(s->sym + offset, "_eextratext")))
 			return 0;
 	}
 


-- 
dwmw2

^ permalink raw reply

* Re: Laptop sleep & current "git" tree
From: David Woodhouse @ 2005-05-03  8:36 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1115072133.6031.33.camel@gaston>

On Tue, 2005-05-03 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> For those who can't dare experimenting with that new git toy, best may
> be for you to wait for 2.6.12-rc4 which will contain all of these.

The latest Fedora Core kernel from
http://people.redhat.com/davej/kernels/Fedora/FC4/RPMS.kernel/ ought to
contain them all too, along with a fix for the EHCI port power switching
problem.

-- 
dwmw2

^ permalink raw reply

* Re: Laptop sleep & current "git" tree
From: Colin Leroy @ 2005-05-03  6:37 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, DebianPPC
In-Reply-To: <1115072133.6031.33.camel@gaston>

On Tue, 03 May 2005 08:15:33 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

Hi Ben,

> All my pending patches regarding power management are now upstream in
> Linus "git" repository. That means I expect those to fix all known
> issues (with the notable exception of the USB related problems, all of
> these things aren't yet there but they aren't under my control, so
> still unplug USB devices).

All the USB patches from David Brownell that I tracked are in
git too, including the ehci repower stuff I sent him. I don't have
issues with these patches applied. Do you?

-- 
Colin

^ permalink raw reply

* Re: CONFIG_PIN_TLB experiments
From: Conn Clark @ 2005-05-03 18:14 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050502204259.GB4065@logos.cnet>

Marcelo Tosatti wrote:
> Hi 8xx folks,

<SNIP>

> 
> Actually, CONFIG_PIN_TLB slowdowns the system, as expected (there are only 
> 28 usable TLB's instead of 32).
> 
> 
> v2.6 CONFIG_PIN_TLB:
> I-TLB userspace misses: 162113
> I-TLB kernel misses: 135911
> D-TLB userspace misses: 289452
> D-TLB kernel misses: 257039
> 
> v2.6 without CONFIG_PIN_TLB:
> I-TLB userspace misses: 160828
> I-TLB kernel misses: 134746
> D-TLB userspace misses: 253557
> D-TLB kernel misses: 227383
> 
> 

Considering that the TLB kernel misses are higher with tlb pinning it 
appears as though the pinned TLBs are not marked as valid.


> The following BDI output shows the pinned, 8MByte data page mapping present,
> at 0xc0000000.
> 
> BDI>rds 826
> SPR  826 : 0x00007f00        32512
> BDI>rms 792 0x0c001C00
> BDI>rms 824 1
> BDI>rds 824
> SPR  824 : 0xc00000f0  -1073741584
> BDI>rds 825
> SPR  825 : 0x00000fe0         4064
> BDI>rds 826
> SPR  826 : 0x00007fff        32767       <- "0x00007fff" was 0x00007f00" initially. 
> 				             I tried enabling usermode access without
> 					     success.
> 
> There are several 4Kb mappings inside the range covered by this 8Mb TLB entry, 
> for example: 
> 
> BDI>rms 792 0x0c000200
> BDI>rms 824 1
> BDI>rds 824
> SPR  824 : 0xc0224f17  -1071493353
> BDI>rds 825
> SPR  825 : 0x002241e0      2245088
> BDI>rds 826
> SPR  826 : 0x00007f00        32512
> 
> And more, without so much detail:
> SPR  824 : 0xc0224f17  -1071493353
> SPR  824 : 0xc01fbf17  -1071661289
> SPR  824 : 0xc0246f17  -1071354089
> SPR  824 : 0xc023ff17  -1071382761
> SPR  824 : 0xc7e35f17  - 941400297
> SPR  824 : 0xc0244f17  -1071362281
> SPR  824 : 0xc023ef17  -1071386857
> 
> Note that protection (SPR 826) is exactly the same as the 8Mbyte page protection. 
> 
> Why is the translation mechanism rejection the pinned mappings? 
> 
> Dan, have you ever seen this work? Am I misunderstanding how the pinned
> entries are supposed to work? 

When you load the Mx_EPN of the pinned area is the EV bit being set?


> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 


-- Conn

*****************************************************************
Blessed be the heretic, for he causes some to think and unites
the rest against him.
*****************************************************************

Conn Clark
Engineering Assistant                clark@esteem.com
Electronic Systems Technology Inc.        www.esteem.com

Stock Ticker Symbol                ELST

^ permalink raw reply

* Re: CONFIG_PIN_TLB experiments
From: Dan Malek @ 2005-05-03 18:47 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050502204259.GB4065@logos.cnet>


On May 2, 2005, at 4:42 PM, Marcelo Tosatti wrote:

> I've been testing the CONFIG_PIN_TLB option under v2.6, results are 
> not good.

As you pointed out before, the implementation looks incorrect,
so I'll take a look at it and verify with tests.  I'm currently 
debugging
some hardware problems with a new 8xx board, when I get over
that I'll look at it.

Thanks.


	-- Dan

^ permalink raw reply

* Re: MPC8245 custom board, disabling SDRAM burst mode
From: Kishore Devireddy @ 2005-05-03 19:59 UTC (permalink / raw)
  To: Sam Song; +Cc: Atit_Shah, linuxppc-embedded

SGkKCldoYXQgc2hvdWxkIEkgY2hhbmdlIHJlbGF0ZWQgdG8gTUNDUiB0byBkaXNhYmxlIFNEUkFN
IGJ1cnN0IG1vZGUgb24gTVBDODI0NT8KClRoYW5rcwpLaXNob3JlCgoKT24gNC8yMS8wNSwgU2Ft
IFNvbmcgPHNhbWxpbnV4cHBjQHlhaG9vLmNvbS5jbj4gd3JvdGU6Cj4gQXRpdF9TaGFoIDxBdGl0
X1NoYWhAc2F0eWFtLmNvbT4gd3JvdGWjugo+ID4gV2hhdCB3ZSBkaWQgd2FzIHZlcmlmaWVkIHRo
ZSB2YWx1ZSBvZiBQU0RNUiByZWdpc3Rlcgo+ID4gdmFsdWUgZm91bmQgaW4geW91ciBib2FyZCBz
cGVjaWZpYyBoZWFkZXIgZmlsZSBpbgo+ID4gaW5jbHVkZS9jb25maWdzLzxib2FyZG5hbWUuaD4K
PiAKPiBVbW1tLCBQU0RNUiByZWdpc3RlciBpcyBmb3IgODI2MCBwZXJoYXBzPyBJIGV2ZW4KPiBk
aWRuJ3QgZmluZCBpdCBpbiA4MjQ1VU0uIERvIHlvdSBtZWFuIE1DQ1Igb2YgODI0NT8KPiAKPiBU
aGFua3MsCj4gCj4gU2FtCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gRG8gWW91IFlhaG9vIT8KPiAxNTDN8sf6TVAzt+i/8cvR
o6y0+MT6tLPI69L0wNa17szDCj4gaHR0cDovL211c2ljLnlpc291LmNvbS8KPiDDwMWuw/fQx9Om
09C+odPQo6zL0bHpw8DNvKGi0d7NvLrNv+HNvAo+IGh0dHA6Ly9pbWFnZS55aXNvdS5jb20KPiAx
R77NyscxMDAw1dejrNHFu6K159PK19TW+sCpyN2joQo+IGh0dHA6Ly9jbi5yZC55YWhvby5jb20v
bWFpbF9jbi90YWcvMWcvKmh0dHA6Ly9jbi5tYWlsLnlhaG9vLmNvbS9ldmVudC9tYWlsXzFnLwo+
IApIaQoKSSBhbSB0cnlpbmcgdG8gcnVuIEVtYmVkZGVkIGxpbnV4IChFTERLKSAoMi40IGtlcmVu
bCkgb24gYSBjdXN0b20gcG93ZXJwYyBib2FyZCwKd2hpY2ggaXMgc2ltaWxhciB0byBBcnRpcyBB
MzAwMCBib2FyZC4gVGhpcyBib2FyZCBoYXMKbXBjODI0NShYUEM4MjQ1TFpZMjY2QiksIG5hdHNl
bWkgODM4MTUgZXRoZXJuZXQsIDRNQiBpbnRlbCBlMjhmMzIwCmZsYXNoLCAxNk1CIHdpbmJvbmQg
dzk4NjQzMkRILTYgU0RSQU0uIFNvIEkgY29uZmlndXJlZCBhbmQgY29tcGlsZWQKVS1ib290IGZv
ciBBMzAwMCBib3JhZC4gVS1ib290IHdvcmtlZCBvbiBteSBib2FyZCBhbHNvLiBOZXh0IEkKY29t
cGlsZWQgRUxESyAzLjAgZm9yIFNhbmRwb2ludCA4MjQ1IGJvYXJkIGFuZCBjb3BpZWQgdG8gZmxh
c2guIEJ1dApsaW51eCBoYW5ncyBhZnRlciB1bmNvbXByZXNzaW5nCgpVLUJvb3QgMS4xLjIgKEFw
ciAxNCAyMDA1IC0gMDA6MDI6MjkpCgpDUFU6ICAgTVBDODI0NSBSZXZpc2lvbiAxLjIgYXQgMjQ5
Ljk5OSBNSHo6IDE2IGtCIEktQ2FjaGUgMTYga0IgRC1DYWNoZQpCb2FyZDogQTMwMDAgTG9jYWwg
QnVzIGF0IDk5Ljk5OSBNSHoKSTJDOiAgIHJlYWR5CkRSQU06ICAxNiBNQgpGTEFTSDogR2V0IGZs
YXNoIGJhbmsgMCBAIDB4ZmZjMDAwMDAKTWFudWYuIElEIEAgMHhmZjgwMDAwMDogMHgwMDAwMDA4
OQpEZXZpY2UgSUQgQCAweGZmODAwMDAxOiAweDAwMDAwMDE2CiMjIEZsYXNoIGJhbmsgMCBhdCAw
eGZmYzAwMDAwIHNpemVzOiAweDAwNDAwMDAwCnByb3RlY3QgbW9uaXRvciBmZmYwMDAwMCBAIDQw
MDAwCnByb3RlY3QgZW52aXJvbnRtZW50IGZmZmMwMDAwIEAgMjAwMDAKIyMgRmluYWwgRmxhc2gg
YmFuayBzaXplczogMDA0MDAwMDAKNCBNQgogICAgIDAwICAxMyAgMTAwYiAgMDAyMCAgMDIwMCAg
ZmYKSW46ICAgIHNlcmlhbApPdXQ6ICAgc2VyaWFsCkVycjogICBzZXJpYWwKTmV0OiAgIG5hdHNl
bWk6IEVFUFJPTSBjb250ZW50czoKZmZmZiBmZmZmIGZmZmYgZmZmZiBmZmZmIGZmZmYgZmZmZiBm
ZmZmIGZmZmYgZmZmZiBmZmZmIGZmZmYKZHA4MzgxNSMwCldhcm5pbmc6IGRwODM4MTUjMCBNQUMg
YWRkcmVzc2VzIGRvbid0IG1hdGNoOgpBZGRyZXNzIGluIFNST00gaXMgICAgICAgICBGRjpGRjpG
RjpGRjpGRjpGRgpBZGRyZXNzIGluIGVudmlyb25tZW50IGlzICAwMDo0MDowNTpCMDpGMTpCQQoK
QTMwMDA+IHRmdHBib290IDQwMDAwMCB1SW1hZ2UuZWxkawpVc2luZyBkcDgzODE1IzAgZGV2aWNl
ClRGVFAgZnJvbSBzZXJ2ZXIgMTkyLjE2OC4xLjEyNDsgb3VyIElQIGFkZHJlc3MgaXMgMTkyLjE2
OC4xLjU0CkZpbGVuYW1lICd1SW1hZ2UuZWxkaycuCkxvYWQgYWRkcmVzczogMHg0MDAwMDAKTG9h
ZGluZzogIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMKICAgICAgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKICAgICAgIyMjIyMjIyMjIyMjIyMjIyMjIwpk
b25lCkJ5dGVzIHRyYW5zZmVycmVkID0gNzU3OTI2IChiOTBhNiBoZXgpCkEzMDAwPiBib290bQoj
IyBCb290aW5nIGltYWdlIGF0IDAwNDAwMDAwIC4uLgpJbWFnZSBOYW1lOiAgIExpbnV4LTIuNC4y
NQpJbWFnZSBUeXBlOiAgIFBvd2VyUEMgTGludXggS2VybmVsIEltYWdlIChnemlwIGNvbXByZXNz
ZWQpCkRhdGEgU2l6ZTogICAgNzU3ODYyIEJ5dGVzID0gNzQwLjEga0IKTG9hZCBBZGRyZXNzOiAw
MDAwMDAwMApFbnRyeSBQb2ludDogIDAwMDAwMDAwClZlcmlmeWluZyBDaGVja3N1bSAuLi4gT0sK
VW5jb21wcmVzc2luZyBLZXJuZWwgSW1hZ2UgLi4uIE9LCgpub3RoaW5nIGhhcHBlbnMgYWZ0ZXIg
dGhpcyB1bnRpbCBJIHJlYm9vdCB0aGUgYm9hcmQuIEkgcmVhZCB1LWJvb3QgRkFRCmFuZCBjb25m
aWd1cmVkIGJkX2luZm8gc3RydWN0dXJlIHNhbWUgZm9yIGJvdGggdS1ib290IGFuZCBMaW51eC4g
SQpmb3VuZCB0aGF0IENGR19JTU1SIGlzIG5vdCBhcHBsaWNhYmxlIHRvIE1QQzgyNDUuIEkgYWxz
byB1c2VkCmNsb2Nrc19pbl9taHogdmFyaWFibGUgYWxzbyBiZWZvcmUgbG9hZGluZyBMaW51eC4g
SSBhbSBzdHVjayBoZXJlLgpDb3VsZCB5b3UgcGxlYXNlIGxldCBtZSBrbm93IHdoYXQgc2hvdWxk
IEkgZG8gbmV4dD8KClRoYW5rcwpLaXNob3JlCg==

^ permalink raw reply

* Re: 2.6.12-rc3-mm2: ppc pte_offset_map()
From: cliff white @ 2005-05-03 22:04 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Andrew Morton, linux-kernel, ério Brito, linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0505020054351.2488@dragon.hyggekrogen.localhost>

On Mon, 2 May 2005 01:01:11 +0200 (CEST)
Jesper Juhl <juhl-lkml@dif.dk> wrote:

> On Sun, 1 May 2005, Andrew Morton wrote:
> 
> > Jesper Juhl <juhl-lkml@dif.dk> wrote:
> > >
> > > On Sun, 1 May 2005, Sean Neakums wrote:
> > > 
> > > > On my Mackertosh (PowerBook5.4), build fails with the following:
> > > > 
> > > >   fs/proc/task_mmu.c: In function `smaps_pte_range':
> > > >   fs/proc/task_mmu.c:177: warning: implicit declaration of function `kmap_atomic'
> > > >   fs/proc/task_mmu.c:177: error: `KM_PTE0' undeclared (first use in this function)
> > > >   fs/proc/task_mmu.c:177: error: (Each undeclared identifier is reported only once
> > > >   fs/proc/task_mmu.c:177: error: for each function it appears in.)
> > > >   fs/proc/task_mmu.c:207: warning: implicit declaration of function `kunmap_atomic'
> > > > 
> > > > With the naive patch below, it builds with this warning and everything works.
> > > > 
> > > >   fs/proc/task_mmu.c: In function `smaps_pte_range':
> > > >   fs/proc/task_mmu.c:208: warning: passing arg 1 of `kunmap_atomic' makes pointer from integer without a cast
> > > > 
> > > 
> > > Try this patch :
> > > 
> > > Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
> > > 
> > > --- linux-2.6.12-rc3-mm2-orig/fs/proc/task_mmu.c	2005-05-01 04:04:25.000000000 +0200
> > > +++ linux-2.6.12-rc3-mm2/fs/proc/task_mmu.c	2005-05-01 17:49:14.000000000 +0200
> > > @@ -2,6 +2,7 @@
> > >  #include <linux/hugetlb.h>
> > >  #include <linux/mount.h>
> > >  #include <linux/seq_file.h>
> > > +#include <linux/highmem.h>
> > >  
> > >  #include <asm/elf.h>
> > >  #include <asm/uaccess.h>
> > > @@ -204,7 +205,7 @@ static void smaps_pte_range(pmd_t *pmd,
> > >  			}
> > >  		}
> > >  	} while (address < end);
> > > -	pte_unmap(pte);
> > > +	pte_unmap((void *)pte);
> > >  }
> > 
> > Should be
> > 
> > 	pte_unmap(ptep);
> > 
> Of course, stupid me. I should have seen the 
> 	[...]
>         ptep = pte_offset_map(pmd, address);
> 	[...]
>             pte = *ptep;
>             address += PAGE_SIZE;
>             ptep++;
> 	[...]
> bit a few lines above. Guess I should have spend more than 2min creating 
> the patch.
> 
> Thanks.
> 
> Here's an updated patch.

Works for me on iBook, G4. Compiles fine and boots. No performance info yet.
Thanks bunches 
cliffw

> 
> Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
> 
> --- linux-2.6.12-rc3-mm2-orig/fs/proc/task_mmu.c	2005-05-01 04:04:25.000000000 +0200
> +++ linux-2.6.12-rc3-mm2/fs/proc/task_mmu.c	2005-05-02 00:59:11.000000000 +0200
> @@ -2,6 +2,7 @@
>  #include <linux/hugetlb.h>
>  #include <linux/mount.h>
>  #include <linux/seq_file.h>
> +#include <linux/highmem.h>
>  
>  #include <asm/elf.h>
>  #include <asm/uaccess.h>
> @@ -204,7 +205,7 @@ static void smaps_pte_range(pmd_t *pmd,
>  			}
>  		}
>  	} while (address < end);
> -	pte_unmap(pte);
> +	pte_unmap(ptep);
>  }
>  
>  static void smaps_pmd_range(pud_t *pud,
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
"Ive always gone through periods where I bolt upright at four in the morning; 
now at least theres a reason." -Michael Feldman

^ permalink raw reply

* Re: Laptop sleep & current "git" tree
From: Ian Wienand @ 2005-05-03 22:22 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, DebianPPC
In-Reply-To: <1115072133.6031.33.camel@gaston>

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, May 03, 2005 at 08:15:33AM +1000, Benjamin Herrenschmidt wrote:
> I would appreciate extensive testing, provided you figure out how to
> retreive the "git" repository from kernel.org :) There must be some
> howto somewhere, but I'm afraid I don't have a link at hand.

It's so far working well for me on an 800Mhz iBook (750fx) after quite
a few sleep and resume cycles.

Is there a fix in the works for the Radeon timing thing that makes the
screen go a little weird on wakeup?

FWIW, the two step way to get the git tree I followed was

wget http://www.kernel.org/pub/software/scm/cogito/cogito-0.8.tar.bz2
(install, modify path in Makefile if you want)

cd /usr/src
mkdir linux-2.6-git
cd linux-2.6-git
cg-init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

-i
ianw@gelato.unsw.edu.au
http://www.gelato.unsw.edu.au

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox