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
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: 0xc000f0a0
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
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
REGS:
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. (NPTL
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:
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 backtrace. Presumably, something
slept from
-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 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 on them.
Should
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 back to
[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 output
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
[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 platform
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:
Except that your implementation
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 custom board with cpm2 smc.
Are you sure it wasn't me
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
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
Linuxppc-dev@ozlabs.org
https
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
extra
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 8280 board in-tree).
Except that last time I tested
-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
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 can
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
misundrstanding
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 clocksource code
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
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 updated. Before
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 instantiate
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
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 controller. The oops seems to happen on
fileaccess
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.
Is
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
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.
The demuxer is setting itself up with set_irq_chained handler(), any
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: Exception in kernel mode, sig: 5
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
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
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)
And if I disable NAPI I get
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;
470 471 (*fep-ops-clear_int_events)(dev
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_uart_console_write.
-Scott
That worked
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
https://ozlabs.org/mailman/listinfo
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_uart_core.c
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/platforms/82xx
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.
We should bypass the lock when oops_in_progress is set
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_uart_core.c
b
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
[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
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_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x4000
CONFIG_KERNEL_START_BOOL=y
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.
Something like this?
Wording sould
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 an d RT kernel.
We should really add some sanity check
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 an d RT kernel.
We should really add some sanity check
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
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-powerpc
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/666.
Are
* 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
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 rebuild the cross
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 and 2.6.25
(I'll see if I can
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
just
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 also
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?
Powerpc
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
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
by the
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?
Any differences in the task switching, irq
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 = serial;
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 to
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 binding
that has no /soc/cpm/muram node, but instead has two
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 from the
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-boot?
Ok, needed a valid console
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
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
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 {
#interrupt-cells = 1
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
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
78 matches
Mail list logo
