Hi
We're trying to get a SMC serial port on a8280 to work.
I cannot find any ecxamples on the binding, so we've tried to make one.
is this anywhere close to workable?
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8280-smc-uart",
> From: Scott Wood
> Sent: Wednesday, January 09, 2008 1:46 PM
> > We're trying to get a SMC serial port on a8280 to work.
> > I cannot find any ecxamples on the binding, so we've tried
> to make one.
> >
> > is this anywhere close to workable?
> >
> > [EMAIL PROTECTED] {
> > device_type =
> From: Scott Wood
> Don't forget to exclude the SMC parameter RAM from the muram
> data area
> in /soc/cpm/muram/data/reg. If you have an older device tree binding
> that has no /soc/cpm/muram node, but instead has two resources in
> /soc/cpm/reg, you need to move to head-of-tree to get this
> From: Scott Wood [mailto:[EMAIL PROTECTED]
> Rune Torgersen wrote:
> >> From: Scott Wood
> >> Don't forget to exclude the SMC parameter RAM from the muram
> >> data area
> >> in /soc/cpm/muram/data/reg. If you have an older device
> tree
> From: Scott Wood
>
> The tree looks OK. The checkstop may be from erratum SIU18;
> I had this issue on the ep8248e board.
>
> Try clearing BCR[PLDP].
Not sure what was wrong. We took a step back, and redid some stuff, and
now we have serial output from the boot-wrapper.
THe checkstop came fro
> From: Scott Wood [
> Rune Torgersen wrote:
> > Not sure what was wrong. We took a step back, and redid
> some stuff, and
> > now we have serial output from the boot-wrapper.
> > THe checkstop came from the wrapper grying to access the
> bcsr and doing
> > t
> From: Rune Torgersen
> Finally got it (sort-of) working.
> Turned out that for some reason the console init is setting
> the baudrate
> to 9600
> the options string passed in to the console init fuunction is NULL.
>
> Any idea oon how this should be passed in from u-b
> From: Scott Wood
>
> You could add something to the cuboot code to fill in current-speed
> based on the value in the bd_t.
>
Ahh.. That was what I'm missing.
Where in the devicetree is that supposed to be at?
___
Linuxppc-dev mailing list
Linuxppc-
Hi.
We're trying to port 2.6.24-rc7 to a board.
Right now wr're battling with the device tree and PCI.
Our board is somewhat loosely based on a 8266ADS/pq2fads board
We have a PCI interrupt mux in a fpga.
We have a disk controller and a pci bridge on the primary side, and four
TI dsp's on the sec
>From: Scott Wood
>Sent: Fri 1/11/2008 1:02 PM
>To: Rune Torgersen
>Cc: linuxppc-dev@ozlabs.org
>Subject: Re: Device Tree & PCI
>
>On Fri, Jan 11, 2008 at 12:17:41PM -0600, Rune Torgersen wrote:
>> PCI_INT: [EMAIL PROTECTED],10 {
>>
Hi
We're doing a port to 2.6.24-rc7, and we need to set up two ethernets with
fixed phy's as they have phyless interfaces to a switch.
WE cannot find any good examples on how to do this. We've found the fixed speed
PHY emulation in the configuration, but are unsure on how to set the PHY's up
in
Hi.
We have e 8280 bioard with PCI. We have three memory ranges set up;
0x8000_ to 0x8fff_ is prefetchable memory
0x9000_ to 0x97ff_ is non-prefetchable memory
0x9800_ to 0x9800_ is IO.
our device tree has
ranges = <4200 0 8000 8000 0 1000// Pre-fetch m
From: Scott Wood
>Hmm... that suggests that something in u-boot's setup is either
>incorrect, or (more likely in this case) doesn't match the device tree.
Turns out u-boot was not setting u the inbound window size correctly.
It was hardcoded to 512MB and we have a gig of ram. Set it correctly,
>From: Scott Wood
>Are you using cuImage, or a regular uImage with a device-tree-aware u-boot
cuImage for now.
>If the former, try commenting out the call to fixup_pci() in
>arch/powerpc/boot/cuboot-pq2.c and let me know if that changes anything.
Did that, That made our PCI bus fail completely
Hi
I get the following kernel core while a user program I have is dumping
core.
Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on
a 8280)
When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11
and dumps core.
On 2.6.24, I ghet the kernel oops, and then the pro
Nathan Lynch wrote:
> Hmm, this is the second report of 2.6.24 crashing in
> __flush_dcache_icache during a core dump; see:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html
>
> Is this easily recreatable?
Yes. I have a binary that will do this every time it is started (on this
Rune Torgersen wrote:
> I was going to test HEAD of powerpc.git to see if it is still there.
Still there. Also used GDB on the vmlinux image to get source and
dissasembly of the ooops:
Unable to handle kernel paging request for data at address 0x48024000
Faulting instruction address: 0xc000f
Kumar Gala wrote:
> This doesn't look like ppc disasm to me :)
>
Helps if i use the cross-compiler gdb instead of the x86 native one...
here is the disasembly dump for NIP
(gdb) disassemble 0xc000f0a0
Dump of assembler code for function __flush_dcache_icache:
0xc000f08c <__flush_dcache_icache+0>
Kumar Gala wrote:
> Can you git-bisect to narrow this down further.
Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7
and up.
Is there an somewhat esy way in git to apply the differences from master
branch to our board branch to a branch created by bisect?
And I don't even kno
Scott Wood wrote:
> Does it happen without preempt?
Will try shortly, just updated my git to HEAD of Linus's tree
>
>> Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
>> drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
>> NIP: c000f0a0 LR: c0011fec CTR: 0080
>> R
Scott Wood wrote:
> Does it happen without preempt?
Yes
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Nathan Lynch wrote:
> Scott Wood wrote:
>> Do you have a simple test case that we could try to reproduce? I
>> tried a simple core dump on an 8280, and it worked.
>
> Is the crashing program multithreaded? The first report had firefox
> triggering the oops.
The crashing program has 10 threads.
Scott Wood wrote:
> Scott Wood wrote:
>> Nathan Lynch wrote:
>>> Is the crashing program multithreaded? The first report had firefox
>>> triggering the oops.
>>
>> OK, I've got a test program that triggers it now. I'll see if I can
>> figure out what's going on.
>
> The problem seems to be that
I hit the following WARN_ON when using mii-tools agains a ethernet
interface using a bit-banged mii interface
It is only diplayed once, and does not seem to impact usage at all
Does somebody know what is wrong, and how to fix it?
The PHY is an Intel LXT973
Badness at kernel/softirq.c:139
NIP: c00
Scott Wood wrote:
> Rune Torgersen wrote:
>> I hit the following WARN_ON when using mii-tools agains a ethernet
>> interface using a bit-banged mii interface
>
> It looks like the kernel thinks it's in an interrupt, even though it
> clearly isn't from the backtra
p;fep->lock, flags);
> - return rc;
> + return phy_mii_ioctl(fep->phydev, mii, cmd);
> }
>
> extern int fs_mii_connect(struct net_device *dev);
Acked-by: Rune Torgersen <[EMAIL PROTECTED]>
Tested it and it does indeed take care of the bug.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi
I upgraded my board-port from 2.6.18 (8280 in arch/ppc) to 2.6.23 (Yes,
I know, arch/powerpc. I am planning on doing that, I just wanted the old
stuff working first).
On any kernel newer than 2.6.20, settimeofday does not work.
I try to set the current date, but when I read back the time, it i
> From: Rune Torgersen
> Sent: Thursday, October 25, 2007 2:40 PM
> On any kernel newer than 2.6.20, settimeofday does not work.
> I try to set the current date, but when I read back the time, it is
> still the old date (in our case, Jan 1 1970)
Eventually the date actually got
> -Original Message-
> From: Scott Wood
> Sent: Monday, September 17, 2007 11:58 AM
>
> The 8272 (and presumably other PCI PQ2 chips) appear to have the
> same issue as the 83xx regarding PCI streaming DMA.
>
Can you explain what this isssue is? We're using a 8280 and have had
some PCI b
Is there an easy way to use something other than the decrementer for the
timer interrupt?
Reason i'm asking is tha t on our board, the decrementer cannot be
divided to 1khz evenly, so we have rounding errors for time, but we do
have a 1KHz timer interrupt from an FPGA that is source of a T1 clock.
> From: Mark A. Greer
> > Is there an easy way to use something other than the decrementer for
the
> > timer interrupt?
> Check out the clocksource stuff. It let's you set up numerous clock
> sources and set the rating of each one. You can start looking in
> arch/powerpc/kernel/time.c for examp
> From: Benjamin Herrenschmidt
> In fact, I'm not sure what is your problem with the DEC
> proper as the TB
> will be used ultimately and thus it shouldn't drift more than the TB
> does. Can your part use an externally clocked TB ?
>
> If not, and you still have a drift despite calibration, you c
> From: Benjamin Herrenschmidt>
> > The TB register is only ued for offsets from the last
> jiffie, not as a
> > continous offset, so then it works out pretty good.
>
> The date is derived from the absolute TB value though...
Huh? Not in 2.6.18/arch/ppc at least, unless I'm completely
misundrsta
> From: Benjamin Herrenschmidt
> > Things have changed a lot since I last delved deep into
> > this to try to
> > ge an accurate freerunning clock (2.6.12).
>
> Hrm... 2.6.18 doesn't have clock sources in the first place,
> what kernel
> are you using ?
>
2.6.18
And I'm starting at the clock
Hi
I get the following oops when trying to boot a arch/powerpc kernel with
preempt-rt installed (v2.6.25.4-rt1)
The board is using a Freescale 8280 as the main CPU and a Silicon Image
SII3124 SATA controller. The oops seems to happen on fileaccess right
after init starts.
I need ideas what to loo
Scott Wood wrote:
> Rune Torgersen wrote:
>> Hi
>> I get the following oops when trying to boot a arch/powerpc kernel
>> with preempt-rt installed (v2.6.25.4-rt1)
>> The board is using a Freescale 8280 as the main CPU and a Silicon
>> Image SII3124 SATA contro
Scott Wood wrote:
> Almost certainly the latter. Is the disk interrupt shared with any
> other interrupts, that are marked IRQF_NODELAY? The -rt
> patch doesn't seem to handle mixing the two well.
Disk is on a muxed PCI interrupt. None of the other interrupts on the
mux is fireing at the time.
I
Scott Wood wrote:
> Try calling irq_set_chip_and_handler() with handle_level_irq, rather
> than irq_set_chip(). The -rt patch doesn't seem to have threadified
> the __do_IRQ() path.
The demuxer is setting itself up with set_irq_chained handler(), any
pointers on how to change to irq_set_chip_an
Scott Wood wrote:
> Rune Torgersen wrote:
>> Scott Wood wrote:
>>> Try calling irq_set_chip_and_handler() with handle_level_irq, rather
>>> than irq_set_chip(). The -rt patch doesn't seem to have threadified
>>> the __do_IRQ() path.
>>
>>
Rune Torgersen wrote:> Scott Wood wrote:
> Of course I then ran headfirst into another one
> This one seems to happen when I attempt to read flash through an mtd
> driver.
Both if these is hitting a BUG_ON in kmap_atomic
(include/asm-powerpc/highmem.h)
>
> Oops: Except
Hi
I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
8280 CPU (arch/powerpc)
I get the follwing oops when trying to enable ethernet:
(looks like a null pointer dereference in
drivers/net/fs_enet/fs_enet-main.c:106)
Unable to handle kernel paging request for data at address 0x00
Hi
When booting v2.6.25.4-rt1 (PREEMPT-RT) on my 8280 CPU with 1 GB RAM, I
get the following oopses.
They both are caused by a BUG_ON in kmap_atomic
(include/asm-powerpc/highmem.h).
If I boot with mem=512M or mem=768M they do not appear.
Any help is greatly appreciated.
Oops: Exception in kerne
Rune Torgersen wrote:
> Hi
> I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
> 8280 CPU (arch/powerpc)
>
> I get the follwing oops when trying to enable ethernet:
> (looks like a null pointer dereference in
> drivers/net/fs_enet/fs_enet-main.c:106)
An
Scott Wood wrote:
> Rune Torgersen wrote:
>> 0xc0196d84 is in fs_enet_interrupt
>> (drivers/net/fs_enet/fs_enet-main.c:473).
>> 468 if (fpi->use_napi)
>> 469 int_clr_events &= ~fep->ev_napi_rx;
>
Scott Wood wrote:
> Rune Torgersen wrote:
>> 0xc0196d84 is in fs_enet_interrupt
>> (drivers/net/fs_enet/fs_enet-main.c:473).
>> 468 if (fpi->use_napi)
>> 469 int_clr_events &= ~fep->ev_napi_rx;
>
Scott Wood wrote:
> Rune Torgersen wrote:
>> Hmm ttyCPM1 output seems to be kinda garbled... Any ideas?
>> Incomplete locking between printk and userland use of ttyCPM1 as
>> console?
>
> s/incomplete/nonexistent/ :-P
>
> Try acquiring port->lock in cpm_u
Kumar Gala wrote:
>> Rune Torgersen wrote:
>> That worked. Console output is sane again.
>
> I'm hoping to see some patches related to these fixes :)
Working on it.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
htt
Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others
toes.
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_
Fix interrupt threading issue on pq2fads when running with CONFIG_PREEMPT_RT
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index a801381..9876d7e 100644
--- a/arch/powerpc/platform
Scott Wood wrote:
> On Tue, May 20, 2008 at 02:28:16PM -0500, Rune Torgersen wrote:
>> Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
>> Userland usage of console, and kernel printf's were stepping on each
>> others toes.
>>
>
Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others
toes.
Also only take lock if not in an oops.
Signed-off-by: Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/drivers/serial/cpm_uart/cpm_uar
Hi
I am trying to enable 1 GB of lowmem on a Freescale 8280.
In arch/ppc this was easilly done by:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x4000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa000
This does not work in arch
[EMAIL PROTECTED] wrote:
> Hi
>
> I am trying to enable 1 GB of lowmem on a Freescale 8280.
> In arch/ppc this was easilly done by:
> CONFIG_ADVANCED_OPTIONS=y
> CONFIG_HIGHMEM_START=0xfe00
> CONFIG_LOWMEM_SIZE_BOOL=y
> CONFIG_LOWMEM_SIZE=0x4000
> CONFIG_KERNEL_START_BOOL=y
> CONFIG_KERNEL
Rune Torgersen wrote:
> [EMAIL PROTECTED] wrote:
>> Hi
>>
>> I am trying to enable 1 GB of lowmem on a Freescale 8280.
>> In arch/ppc this was easilly done by:
>> CONFIG_ADVANCED_OPTIONS=y
>> CONFIG_HIGHMEM_START=0xfe00
>> CONFIG_LOWMEM
Kumar Gala wrote:
> On May 21, 2008, at 3:55 PM, Rune Torgersen wrote:
>> Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it
>> works in both vaniulla an d RT kernel.
>
> We should really add some sanity check on CONFIG_TASK_SIZE vs
> KERNEL_START.
Some
Kumar Gala wrote:
> On May 21, 2008, at 4:24 PM, Rune Torgersen wrote:
>
>> Kumar Gala wrote:
>>> On May 21, 2008, at 3:55 PM, Rune Torgersen wrote:
>>>> Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it
>>>> works in both vaniulla
Kumar Gala wrote:
> On May 21, 2008, at 4:24 PM, Rune Torgersen wrote:
>
>> Kumar Gala wrote:
>>> On May 21, 2008, at 3:55 PM, Rune Torgersen wrote:
>>>> Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it
>>>> works in both vaniulla
Kumar Gala wrote:
> something like that would be good. is there really anything PPC32
> specific about it?
Apparently. The Kconfig option is only available for arch/powerpc and
arch/ppc, and the only place in the whole codetree where
CONFIG_TASK_SIZE is used is that particular spot in
asm-powerp
Make sure CONFIG_TASK_SIZE does not overlap CONFIG_KERNEL_START
This could happen when overriding settings to get 1GB lowmem, and would lead
to userland mysteriousely hanging.
This setting is only used by PPC32.
Signed-off-by Rune Torgersen <[EMAIL PROTECTED]>
diff --git a/include/asm-p
Hi
We are looking into switching kernels from 2.6.18 (ppc) to 2.6.25
(powerpc).
I have been trying to run some benchmarks to see how the new kernel
compares to the old one.
So far it is performing worse.
One test I ran was just compiling a 2.6.18 kernel on the system.
The .25 performed 5 to 7 %
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
While tryiong to figure out what it was, I saw some mention of trying
LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
lockdep patches from BenH.
Benjamin Herrenschmidt wrote:
> On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote:
>> Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel,
> What core is in the 8280 ? At this stage, I wouldn't rule out a bug in
> the lockdep patches, I need to do more work
> From: Benjamin Herrenschmidt
> In fact, I remember working on 64 bits lockdep, based on patches from
> Johannes, but I didn't do 32 bits. I think somebody worked on it, but
> now I can't find the patches...
http://patchwork.ozlabs.org/linuxppc/patch?id=16652
> Whoever did it can bounce them bac
[EMAIL PROTECTED] wrote:
> Now I get an "inconsistent locking state", but I need help in
> trying to
> fiure out what I should look for.
I did figure out htat lockdep only complains about inonsistent locking
state when PREEMPT_RT paches are applied.
Now I just need some help interpreting this outp
Hi
While trying to find what is causing some hickups on our Freescale 8280
based system
(ppc 603e core), i've found that pdflush is causing us some grief.
The system is runnign at 450MHz, have 1GB of memory, and we see the same
issue on 2.6.18 (arch/ppc) and 2.6.24.3 (arch/powerpc)
Filesystem i
[EMAIL PROTECTED] wrote:
> Hi everybody,
>
> as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> looking for an
> OpenFirmware compatible way to handle a RAM-based MTD device.
>
> On the platform_device based ppc architecture, the
> drivers/mtd/maps/plat-ram.c
> driver handled "mtd-ram
David Gibson wrote:
> On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
>> We ran ito the same issue.
>> We did option 3, as it was efinetly the easiest,
>
> I think this is the best option in principle.
>
>> here is the sram entry in our dts:
>
>Laurent Pinchart wrote:
> On Tuesday 25 March 2008 17:03, Scott Wood wrote:
>> Yes, I've answered questions on the lists from at least one person
>> using a custom board with cpm2 smc.
>
> Are you sure it wasn't me ? ;-)
>
Probably me, actually. We have a 8280 with SMC's in use (SMC1 and 2)
___
Laurent Pinchart wrote:
> On Tuesday 25 March 2008 17:27, Rune Torgersen wrote:
>>> Laurent Pinchart wrote:
>>> On Tuesday 25 March 2008 17:03, Scott Wood wrote:
>>>> Yes, I've answered questions on the lists from at least one person
>>>> using a
Laurent Pinchart wrote:
> On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:
>> Laurent Pinchart wrote:
>>
> Regarding non-volatility nothing prevents a user from using a
> volatile RAM as an MTD device, but there's little point in doing so.
> Would it be acceptable for the "linear-nvram" spe
Laurent Pinchart wrote:
> Hi everybody,
>
> these two patches add support for memory-mapped RAM & ROM chips to the
> physmap_of MTD driver.
Whole series
acked-by: Rune Torgersen <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
L
Scott Wood wrote:
> 0x2000 minus sizeof(...) would be a good default for CPM1 and CPM2
> (8280 has its first chunk go up to 0x4000, but for some reason that
> didn't get reflected in the dts for the one 8280 board in-tree).
Except that last time I tested it, it is not from 0 - 0x4000, but the
extr
Scott Wood wrote:
> Rune Torgersen wrote:
>> Scott Wood wrote:
>>> 0x2000 minus sizeof(...) would be a good default for CPM1 and CPM2
>>> (8280 has its first chunk go up to 0x4000, but for some reason that
>>> didn't get reflected in the dts for the one 828
Laurent Pinchart wrote:
> Last thing I heard was that the device tree should not encode
> a device's
> expected usage, so memory nodes should not have any
> compatible property that
> would automatically associated them to an MTD driver. I've
> been adviced to
> add platform-specific code to instan
> This is certainly significant, but a lot has happened between the two
> versions. I few ideas:
>
> * compare some of the key configuration options:
> # CONFIG_DEBUG_*
> # CONFIG_PREEMPT*
> # CONFIG_NO_HZ
> # CONFIG_HZ
2.6.25:
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not
> 9919_unit Linux 2.6.25 powerpc-linux-gnu 4343232
> > 1. 1
> > 9919_unit Linux 2.6.18 powerpc-linux-gnu 4453232
> > 1.0100 1
>
> Hmm, processor MHz is off by 11/445
I noticed that.
> And memory latency is off 13/500.
>
> That sounds like it will be 16/66
> * Maybe there is a kernel version that supports your hardware in both
> arch/ppc/ and arch/powerpc. In that case, you could see if
> the platform
> change had an impact.
Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
test I did is almost identical (within 1%) of what the a
Trying to cross-compile arch/powerpc for an freescale 8280:
Gcc 4.1.2
Binutils 2.17
BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps
previous sections
BFD: ./vmlinux.strip.7812: section .ref.text lma 0xc024f000 overlaps
previous sections
BFD: ./vmlinux.strip.7812: section .rodata
Segher Boessenkool wrote:
>> Trying to cross-compile arch/powerpc for an freescale 8280:
>>
>> Gcc 4.1.2
>> Binutils 2.17
>>
>> BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps
>> previous sections
>
> [etc]
>
> Could you try with binutils 2.18?
Not easilly, I would have to re
Arnd Bergmann wrote:
> On Tuesday 15 July 2008, Rune Torgersen wrote:
>> Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
>> test I did is almost identical (within 1%) of what the arch/powerpc
>> 2.6.25 did, so it seems to be a difference between 2.6.18 an
Arnd Bergmann wrote:
> Ok, I think this could be related mostly to two changes:
>
> * In 2.6.23, the process scheduler was replaced, the new one
> is the CFS,
> the 'completely fair scheduler'. This has changed a lot of data.
> To verify this, you could check out a git version just before and
> ju
Arnd Bergmann wrote:
> If you can't get it to work, readprofile(1) is a much simpler
> tool, both in what it can do and what it requires you to do.
One thing that pops out is that handle_mm_fault uses twice as many ticks
in arch/powerpc.
Top 20 calls from readprofile
2.6.25 arch/ppc
305993 total
Arnd Bergmann wrote:
> Seeing more hits in handle_mm_fault suggests that you have
> a higher page fault rate. A trivial reason for this might
> be that the amount of memory was misdetected in the new
> code (maybe broken device tree). What is the content of
> /proc/meminfo after a fresh boot?
I al
Arnd Bergmann wrote:
> Seeing more hits in handle_mm_fault suggests that you have
> a higher page fault rate. A trivial reason for this might
> be that the amount of memory was misdetected in the new
> code (maybe broken device tree). What is the content of
> /proc/meminfo after a fresh boot?
Power
Arnd Bergmann wrote:
> So again, nothing conclusive. I'm running out of ideas.
Is the syscall path different or the same on ppc and powerpc?
Any differences in the task switching, irq handling or page fault
handling?
___
Linuxppc-dev mailing list
Linux
> From: Segher Boessenkool
> > Previous threads have mentioned that binutil-2.17 is broken for
> > building powerpc kernels. It is fixed in binutils-2.18.
>
> I have a working (tested! thanks Milton) workaround for the current
> problem, will send it later today. This problem funnily is hidden
>
> From: Arnd Bergmann [mailto:[EMAIL PROTECTED]
> On Thursday 17 July 2008, Rune Torgersen wrote:
> > Arnd Bergmann wrote:
> > > So again, nothing conclusive. I'm running out of ideas.
> >
> > Is the syscall path different or the same on ppc and powerpc?
>
87 matches
Mail list logo
