* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-13 19:05 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1160764895.11239.14.camel@farscape>
On Fri, 13 Oct 2006, Will Schmidt wrote:
> Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> tree. It's fairly early during boot, so I've included the whole log
> below. This partition has 8 procs, (shared, including threads), and
> 512M RAM.
This looks like slab bootstrap. You are bootstrapping while having
zonelists build with zones that are only going to be populated later?
This will lead to incorrect NUMA placement of lots of slab structures on
bootup.
Check if the patch below may cure the oops. Your memory is likely
still placed on the wrong numa nodes since we have to fallback from
the intended node.
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c 2006-10-13 11:59:55.000000000 -0700
+++ linux-2.6/mm/slab.c 2006-10-13 12:03:15.000000000 -0700
@@ -3154,7 +3154,8 @@ void *fallback_alloc(struct kmem_cache *
for (z = zonelist->zones; *z && !obj; z++)
if (zone_idx(*z) <= ZONE_NORMAL &&
- cpuset_zone_allowed(*z, flags))
+ cpuset_zone_allowed(*z, flags) &&
+ (*z)->free_pages)
obj = __cache_alloc_node(cache,
flags | __GFP_THISNODE,
zone_to_nid(*z));
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-13 19:53 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610131158270.26311@schroedinger.engr.sgi.com>
On Fri, 2006-13-10 at 12:05 -0700, Christoph Lameter wrote:
> On Fri, 13 Oct 2006, Will Schmidt wrote:
>
> > Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> > tree. It's fairly early during boot, so I've included the whole log
> > below. This partition has 8 procs, (shared, including threads), and
> > 512M RAM.
>
> This looks like slab bootstrap. You are bootstrapping while having
> zonelists build with zones that are only going to be populated later?
> This will lead to incorrect NUMA placement of lots of slab structures on
> bootup.
I dont think so.. but it's not an area I'm very familiar with. one
of the other PPC folks might chime in with something here.
>
> Check if the patch below may cure the oops. Your memory is likely
> still placed on the wrong numa nodes since we have to fallback from
> the intended node.
Nope, no change with this patch.
>
> Index: linux-2.6/mm/slab.c
> ===================================================================
> --- linux-2.6.orig/mm/slab.c 2006-10-13 11:59:55.000000000 -0700
> +++ linux-2.6/mm/slab.c 2006-10-13 12:03:15.000000000 -0700
> @@ -3154,7 +3154,8 @@ void *fallback_alloc(struct kmem_cache *
>
> for (z = zonelist->zones; *z && !obj; z++)
> if (zone_idx(*z) <= ZONE_NORMAL &&
> - cpuset_zone_allowed(*z, flags))
> + cpuset_zone_allowed(*z, flags) &&
> + (*z)->free_pages)
> obj = __cache_alloc_node(cache,
> flags | __GFP_THISNODE,
> zone_to_nid(*z));
^ permalink raw reply
* uartlite with 2.6.17 kernel and kernel early text messages
From: Robert Corley @ 2006-10-13 20:44 UTC (permalink / raw)
To: linux linuxppc-embedded
I am still trying to get the UARTLITE to work with 2.6 and a plb_temac desi=
gn. I am using EDK 7.1. I have generated the edk files and copied xparame=
ters_ml300.h to arch/ppc/platforms/4xx/xparameters.xparameters_ml403.h=0A=
=0AIn an effort to get past the "Rebooting to System ACE Configuration Addr=
ess 6..." message, I have selected "support for early boot texts over seria=
l port" in kernel debugging.=0A=0AFYI, I'm using Peter's patches to create =
the uartlite.c and associated files and have selected the uartlite using ma=
ke menuconfig.=0A=0AThe first error is as follows:=0Aathena startup_network=
# make ARCH=3Dppc zImage.initrd=0A CHK include/linux/version.h=0A CH=
K include/linux/compile.h=0Adnsdomainname: Unknown host=0A CC arc=
h/ppc/syslib/gen550_dbg.o=0Aarch/ppc/syslib/gen550_dbg.c:36: error: `RS_TAB=
LE_SIZE' undeclared here (not in a function)=0Aarch/ppc/syslib/gen550_dbg.c=
:38: error: empty scalar initializer=0Aarch/ppc/syslib/gen550_dbg.c:38: err=
or: (near initialization for `rs_table')=0Aarch/ppc/syslib/gen550_dbg.c:36:=
error: storage size of `rs_table' isn't known=0Aarch/ppc/syslib/gen550_dbg=
.c:36: warning: 'rs_table' defined but not used=0Amake[1]: *** [arch/ppc/sy=
slib/gen550_dbg.o] Error 1=0Amake: *** [arch/ppc/syslib] Error 2=0A=0Aso, I=
modified the gen550_dbg.c file to #include the xparameters.h, where the RS=
_TABLE_SIZE is defined=0A but still get more errors. Here they are:=0A=0A =
CHK include/linux/version.h=0A CHK include/linux/compile.h=0Adnsd=
omainname: Unknown host=0A CC arch/ppc/syslib/gen550_dbg.o=0Aarch/ppc=
/syslib/gen550_dbg.c:37: error: `XPAR_UARTNS550_0_CLOCK_FREQ_HZ' undeclared=
here (not in a function)=0Aarch/ppc/syslib/gen550_dbg.c:37: error: initial=
izer element is not constant=0Aarch/ppc/syslib/gen550_dbg.c:37: error: (nea=
r initialization for `rs_table[0].baud_base')=0Aarch/ppc/syslib/gen550_dbg.=
c:37: error: `XPAR_INTC_0_UARTNS550_0_VEC_ID' undeclared here (not in a fun=
ction)=0Aarch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not=
constant=0Aarch/ppc/syslib/gen550_dbg.c:37: error: (near initialization fo=
r `rs_table[0].irq')=0Aarch/ppc/syslib/gen550_dbg.c:37: error: `XPAR_UARTNS=
550_0_BASEADDR' undeclared here (not in a function)=0Aarch/ppc/syslib/gen55=
0_dbg.c:37: error: initializer element is not constant=0Aarch/ppc/syslib/ge=
n550_dbg.c:37: error: (near initialization for `rs_table[0].iomem_base')=0A=
arch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not constant=
=0Aarch/ppc/syslib/gen550_dbg.c:37: error: (near initialization for `rs_tab=
le[0]')=0Amake[1]: *** [arch/ppc/syslib/gen550_dbg.o] Error 1=0Amake: *** [=
arch/ppc/syslib] Error 2=0A=0AQuestions:=0A=0A1. Now, is this an issue w=
ith the UARTLITE driver or is it just not supported for early messaging?=0A=
2. What am I missing w.r.t. getting something out of the serial port?=0A3=
. I am assuming that the boot args for a initrd boot are: "console=3Dtt=
yUL0 ip=3Doff root=3D/dev/ram rw", correct?=0A=0A-corley=0A=0A
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-13 20:57 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1160769226.11239.22.camel@farscape>
On Fri, 2006-13-10 at 14:53 -0500, Will Schmidt wrote:
> On Fri, 2006-13-10 at 12:05 -0700, Christoph Lameter wrote:
> > On Fri, 13 Oct 2006, Will Schmidt wrote:
> >
> > > Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> > > tree. It's fairly early during boot, so I've included the whole log
> > > below. This partition has 8 procs, (shared, including threads), and
> > > 512M RAM.
> >
> > This looks like slab bootstrap. You are bootstrapping while having
> > zonelists build with zones that are only going to be populated later?
> > This will lead to incorrect NUMA placement of lots of slab structures on
> > bootup.
>
> I dont think so.. but it's not an area I'm very familiar with. one
> of the other PPC folks might chime in with something here.
>
> >
> > Check if the patch below may cure the oops. Your memory is likely
> > still placed on the wrong numa nodes since we have to fallback from
> > the intended node.
>
> Nope, no change with this patch.
>
Here is another boot log, with that patch applied, and with a numa=debug
parm.
-----------------------------------------------------
ppc64_pft_size = 0x18
physicalMemorySize = 0x22000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0x0000000000000000
htab_hash_mask = 0x1ffff
-----------------------------------------------------
Linux version 2.6.19-rc1-gb8a3ad5b-dirty (willschm@airbag2) (gcc version
4.1.0 (SUSE Linux)) #60 SMP Fri Oct 13 14:48:20 CDT 2006
[boot]0012 Setup Arch
NUMA associativity depth for CPU/Memory: 3
adding cpu 0 to node 0
node 0
NODE_DATA() = c000000015ffee80
start_paddr = 8000000
end_paddr = 16000000
bootmap_paddr = 15ffc000
reserve_bootmem ffc0000 40000
reserve_bootmem 15ffc000 2000
reserve_bootmem 15ffee80 1180
node 1
NODE_DATA() = c000000021ff7c80
start_paddr = 0
end_paddr = 22000000
bootmap_paddr = 21ff2000
reserve_bootmem 0 847000
reserve_bootmem 264b000 9000
reserve_bootmem 77b2000 84e000
reserve_bootmem 21ff2000 5000
reserve_bootmem 21ff7c80 1180
reserve_bootmem 21ff8e58 71a4
No ramdisk, default root is /dev/sda2
EEH: No capable adapters found
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0 -> 139264
Normal 139264 -> 139264
early_node_map[3] active PFN ranges
1: 0 -> 32768
0: 32768 -> 90112
1: 90112 -> 139264
[boot]0015 Setup Done
Built 2 zonelists. Total pages: 136576
Kernel command line: root=/dev/sda3 xmon=on numa=debug
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
freeing bootmem node 0
freeing bootmem node 1
Memory: 530256k/557056k available (5508k kernel code, 30468k reserved,
2224k data, 543k bss, 244k init)
kernel BUG in __cache_alloc_node
at /development/kernels/linux-2.6.git/mm/slab.c:3178!
cpu 0x0: Vector: 700 (Program Check) at [c0000000007938d0]
pc: c0000000000b3c78: .__cache_alloc_node+0x44/0x1e8
lr: c0000000000b3ed4: .fallback_alloc+0xb8/0xfc
sp: c000000000793b50
msr: 8000000000021032
current = 0xc000000000583a90
paca = 0xc000000000584300
pid = 0, comm = swapper
kernel BUG in __cache_alloc_node
at /development/kernels/linux-2.6.git/mm/slab.c:3178!
enter ? for help
[c000000000793c00] c0000000000b3ed4 .fallback_alloc+0xb8/0xfc
[c000000000793ca0] c0000000000b4484 .kmem_cache_zalloc+0xc8/0x11c
[c000000000793d40] c0000000000b6630 .kmem_cache_create+0x1e8/0x5e0
[c000000000793e30] c00000000053e834 .kmem_cache_init+0x1d8/0x4b0
[c000000000793ef0] c000000000524748 .start_kernel+0x244/0x328
[c000000000793f90] c0000000000084f8 .start_here_common+0x54/0x5c
0:mon>
^ permalink raw reply
* Re: preempt crash in 2.6.18
From: Vitaly Bordug @ 2006-10-13 21:21 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B07B397@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Fri, 13 Oct 2006 09:16:52 -0500
Rune Torgersen wrote:
>
> This is from a Freescale 8265 running 2.6.18
> Anyone have any idea what this is and how to fix it?
>
Yes. Actually, I recall alike thing and used to fix with proper spin-locking if the
cascade PCI irq, which apparently does do_irq that seems to confuse preempt counters.
Just a pure guess.
Hope it helps.
-Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Nathan Lynch @ 2006-10-13 21:22 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, linux-kernel, Christoph Lameter
In-Reply-To: <1160773040.11239.28.camel@farscape>
Will Schmidt wrote:
> On Fri, 2006-13-10 at 14:53 -0500, Will Schmidt wrote:
> > On Fri, 2006-13-10 at 12:05 -0700, Christoph Lameter wrote:
> > > On Fri, 13 Oct 2006, Will Schmidt wrote:
> > >
> > > > Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> > > > tree. It's fairly early during boot, so I've included the whole log
> > > > below. This partition has 8 procs, (shared, including threads), and
> > > > 512M RAM.
> > >
> > > This looks like slab bootstrap. You are bootstrapping while having
> > > zonelists build with zones that are only going to be populated later?
> > > This will lead to incorrect NUMA placement of lots of slab structures on
> > > bootup.
> >
> > I dont think so.. but it's not an area I'm very familiar with. one
> > of the other PPC folks might chime in with something here.
> >
> > >
> > > Check if the patch below may cure the oops. Your memory is likely
> > > still placed on the wrong numa nodes since we have to fallback from
> > > the intended node.
> >
> > Nope, no change with this patch.
> >
>
> Here is another boot log, with that patch applied, and with a numa=debug
> parm.
>
> -----------------------------------------------------
> ppc64_pft_size = 0x18
> physicalMemorySize = 0x22000000
> ppc64_caches.dcache_line_size = 0x80
> ppc64_caches.icache_line_size = 0x80
> htab_address = 0x0000000000000000
> htab_hash_mask = 0x1ffff
> -----------------------------------------------------
> Linux version 2.6.19-rc1-gb8a3ad5b-dirty (willschm@airbag2) (gcc version
> 4.1.0 (SUSE Linux)) #60 SMP Fri Oct 13 14:48:20 CDT 2006
> [boot]0012 Setup Arch
> NUMA associativity depth for CPU/Memory: 3
> adding cpu 0 to node 0
> node 0
> NODE_DATA() = c000000015ffee80
> start_paddr = 8000000
> end_paddr = 16000000
> bootmap_paddr = 15ffc000
> reserve_bootmem ffc0000 40000
> reserve_bootmem 15ffc000 2000
> reserve_bootmem 15ffee80 1180
> node 1
> NODE_DATA() = c000000021ff7c80
> start_paddr = 0
> end_paddr = 22000000
Strange, node 0 appears to be in the middle of node 1.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Anton Blanchard @ 2006-10-13 21:34 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, linux-kernel, Christoph Lameter
In-Reply-To: <20061013212202.GG28620@localdomain>
Hi,
> Strange, node 0 appears to be in the middle of node 1.
Its an odd setup and may be a firmware issue but Ive seen it a number of
times on POWER5 boxes.
Anton
^ permalink raw reply
* Eeek! page_mapcount(page) went negative! (-1) -2.6.16.2 kernel
From: agnel juni @ 2006-10-13 21:48 UTC (permalink / raw)
To: linux linuxppc-embedded
In-Reply-To: <20061013204442.52818.qmail@web56308.mail.re3.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]
Hello all,
We are working on System ACE driver ported for AMCC44x based custom platform, on linux kernel-2.6.16.2
We have formatted the flash with FAT16 filesystem as System ACE supports only that.
We are able to run all the filessytem commands except that 'mount' shows inconsisten behaviour.
I have turned off the "Use full SLAB allocator" option under kernel configuration.
With this, when mount fails I see Kernel throwing Oops sometimes.
Any suggestions to debug this are greatly appreciated.
################# Kernel Oops #######################
# mount -t msdos /dev/xsysace /mnt/
Bad pte = df452f3cdf452f3c, process = exe, vm_flags = 75, vaddr = fe11a64
Call Trace:
[DFF97DE8] [C000958C] show_stack+0x48/0x194 (unreliable)
[DFF97E18] [C00470CC] print_bad_pte+0x44/0x54
[DFF97E20] [C0049694] __handle_mm_fault+0x900/0x930
[DFF97E78] [C000A174] do_page_fault+0x268/0x4fc
[DFF97F40] [C0001FE0] handle_page_fault+0xc/0x80
VM: killing process exe
swap_free: Bad swap file entry 62696e2f
swap_free: Bad swap file entry 026f7800
swap_free: Bad swap file entry 30c070c3
swap_free: Bad swap file entry b8df44b2
swap_free: Bad swap file entry c0df44b2
Bad pte = 5800000001, process = ???, vm_flags = 75, vaddr = fe12000
Call Trace:
[DFF97D28] [C000958C] show_stack+0x48/0x194 (unreliable)
[DFF97D58] [C00470CC] print_bad_pte+0x44/0x54
[DFF97D60] [C0047168] vm_normal_page+0x8c/0x94
[DFF97D68] [C004794C] unmap_vmas+0x424/0x5c8
[DFF97DF8] [C004CAC8] exit_mmap+0x60/0xec
[DFF97E18] [C0016C3C] mmput+0x50/0xd4
[DFF97E28] [C001B228] exit_mm+0x120/0x1a0
[DFF97E40] [C001B864] do_exit+0x11c/0x77c
[DFF97E78] [C000A2A4] do_page_fault+0x398/0x4fc
[DFF97F40] [C0001FE0] handle_page_fault+0xc/0x80
Eeek! page_mapcount(page) went negative! (-1)
page->flags = 400
page->count = 1
page->mapping = 00000000
kernel BUG in page_remove_rmap at mm/rmap.c:560!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C004E620 LR: C004E698 CTR: 00000000
REGS: dff97ca8 TRAP: 0700 Not tainted (2.6.16.2)
MSR: 00029000 <EE,ME> CR: 24022022 XER: 00000000
TASK = df463000[610] 'exe' THREAD: dff96000
GPR00: C004E698 DFF97D58 DF463000 0000001E 00000FBC FFFFFFFF C0240000 C01F0C0C
GPR08: C01F0000 00000001 00000000 C0240000 00000000 10065ABC DFC46D10 0FF08FFF
GPR16: C0243C18 00000000 FFFFFFFF FFFFFFFF 00000000 0FF09000 DFD2AA50 DF4821FC
GPR24: 00000000 DFF97D74 A1FF0000 00000001 0FF09000 C0259000 0FE13000 C0259000
NIP [C004E620] page_remove_rmap+0x68/0xe4
LR [C004E698] page_remove_rmap+0xe0/0xe4
Call Trace:
[DFF97D58] [C004E698] page_remove_rmap+0xe0/0xe4 (unreliable)
[DFF97D68] [C004799C] unmap_vmas+0x474/0x5c8
[DFF97DF8] [C004CAC8] exit_mmap+0x60/0xec
[DFF97E18] [C0016C3C] mmput+0x50/0xd4
[DFF97E28] [C001B228] exit_mm+0x120/0x1a0
[DFF97E40] [C001B864] do_exit+0x11c/0x77c
[DFF97E78] [C000A2A4] do_page_fault+0x398/0x4fc
[DFF97F40] [C0001FE0] handle_page_fault+0xc/0x80
Instruction dump:
83e1000c 38210010 7c0803a6 4e800020 801f0008 3c60c01c 3863d5e0 35200001
41800034 813f0008 39290001 55290ffe <0f090000> 38600010 3880ffff 4bff07b1
Fixing recursive fault but reboot is needed!
Thanks
Junita
---------------------------------
Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW
[-- Attachment #2: Type: text/html, Size: 3833 bytes --]
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Mike Kravetz @ 2006-10-13 22:01 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, linux-kernel, Christoph Lameter
In-Reply-To: <20061013212202.GG28620@localdomain>
On Fri, Oct 13, 2006 at 04:22:02PM -0500, Nathan Lynch wrote:
> Will Schmidt wrote:
> > NUMA associativity depth for CPU/Memory: 3
> > adding cpu 0 to node 0
> > node 0
> > NODE_DATA() = c000000015ffee80
> > start_paddr = 8000000
> > end_paddr = 16000000
> > bootmap_paddr = 15ffc000
> > reserve_bootmem ffc0000 40000
> > reserve_bootmem 15ffc000 2000
> > reserve_bootmem 15ffee80 1180
> > node 1
> > NODE_DATA() = c000000021ff7c80
> > start_paddr = 0
> > end_paddr = 22000000
>
> Strange, node 0 appears to be in the middle of node 1.
IIRC, this is fairly common. Or, it was on the system/LPAR I had access
to. I'd check again, but I lost easy access to that system. :(
--
Mike
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-13 22:22 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1160773040.11239.28.camel@farscape>
Here is another fall back fix checking if the slab has already been setup
for this node. MPOL_INTERLEAVE could redirect the allocation.
Index: linux-2.6.19-rc1-mm1/mm/slab.c
===================================================================
--- linux-2.6.19-rc1-mm1.orig/mm/slab.c 2006-10-10 21:47:12.949563383 -0500
+++ linux-2.6.19-rc1-mm1/mm/slab.c 2006-10-13 17:21:31.937863714 -0500
@@ -3158,12 +3158,15 @@ void *fallback_alloc(struct kmem_cache *
struct zone **z;
void *obj = NULL;
- for (z = zonelist->zones; *z && !obj; z++)
+ for (z = zonelist->zones; *z && !obj; z++) {
+ int nid = zone_to_nid(*z);
+
if (zone_idx(*z) <= ZONE_NORMAL &&
- cpuset_zone_allowed(*z, flags))
+ cpuset_zone_allowed(*z, flags) &&
+ cache->nodelists[nid])
obj = __cache_alloc_node(cache,
- flags | __GFP_THISNODE,
- zone_to_nid(*z));
+ flags | __GFP_THISNODE, nid);
+ }
return obj;
}
^ permalink raw reply
* Re: uartlite with 2.6.17 kernel and kernel early text messages
From: Michael Galassi @ 2006-10-13 22:26 UTC (permalink / raw)
To: Robert Corley; +Cc: linux linuxppc-embedded
In-Reply-To: <20061013204442.52818.qmail@web56308.mail.re3.yahoo.com>
>In an effort to get past the "Rebooting to System ACE Configuration
>Address 6..." message, I have selected "support for early boot texts
>over serial port" in kernel debugging.
This will not work. Unfortunately linux here shows its roots as PS OS,
there is a vast amount of hardcoded NS8250/NS16550 knowledge in there.
I'd started modularizing this so we could use a UART lite but the more I
dug the lower my motivation. This is really ugly code in an area that
is of virtually no interest. For now get rid of support for early boot
texts over serial port" and use your JTAG to read the buffers if you
panic before the console is up and running.
-michael
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Benjamin Herrenschmidt @ 2006-10-13 22:36 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061013115457.7b36a7c3@localhost.localdomain>
> You can advance the pointer with L1_CACHE_BYTES/sizeof(int) per
> iteration in the second loop here.
Yeah, I suppose so. Though I'm not 100% confident we get L1_CACHE_BYTES
on all cpus, for example, PA6T is 64 bytes ;) We could use
cur_cpu_spec->icache_bsize but that would involve ugly RELOC's to get it
right on 32 bits. I decided not to care for now.
Ben.
^ permalink raw reply
* Re: preempt crash in 2.6.18
From: Benjamin Herrenschmidt @ 2006-10-13 23:14 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20061014012105.6ca4ff05@localhost.localdomain>
On Sat, 2006-10-14 at 01:21 +0400, Vitaly Bordug wrote:
> On Fri, 13 Oct 2006 09:16:52 -0500
> Rune Torgersen wrote:
>
> >
> > This is from a Freescale 8265 running 2.6.18
> > Anyone have any idea what this is and how to fix it?
> >
> Yes. Actually, I recall alike thing and used to fix with proper spin-locking if the
> cascade PCI irq, which apparently does do_irq that seems to confuse preempt counters.
>
> Just a pure guess.
How so ? Cascades shouldn't do do_IRQ with the new irq code anyway
unless this is still arch/ppc, they should do either __do_IRQ or better,
generic_handle_irq().
Ben.
^ permalink raw reply
* Re: Recently removed io accessors
From: Paul Mackerras @ 2006-10-13 23:20 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, sfr
In-Reply-To: <87slhstxlk.fsf@sleipner.barco.com>
Peter Korsgaard writes:
> We're using the smsc9117
> (http://www.smsc.com/main/datasheets/9117.pdf) connected over a 16bit
> EMC bus (together with a spansion 29PL127 flash) to a Xilinx V4FX FPGA
> with a 405 core in it.
>
> LSB of the processor is connected to LSB of of the 9117 (and same for
> the flash) and so on.
>
> Reading the byte test register of the 9117 (supposed to contain
> 0x87654321) gives:
>
> Endian register set to little endian (default at powerup):
> RedBoot> x -b 0x8e000064 -2 -l 4
> 8E000064: 4321 8765
> RedBoot> x -b 0x8e000064 -4 -l 4
> 8E000064: 43218765
Which is neither big-endian nor little-endian, but something more like
vax-endian (or pdp11-endian), but not exactly that either - vax-endian
would be 65872143. What a mess.
> And with it set to big endian:
> RedBoot> x -b 0x8e000064 -2 -l 4
> 8E000064: 8765 4321
> RedBoot> x -b 0x8e000064 -4 -l 4
> 8E000064: 87654321
Clearly the "big endian" bit on the chip doesn't actually switch
between little-endian and big-endian at all, but just acts to invert
the 0x2 bit of the address...
So the two hardware bogosities taken together leave you with only one
combination that is anything like usable. I suggest that you code up
a loop of readw (or equivalent) in the driver with a big comment
explaining why you need to do it that way.
Paul.
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Stephen Rothwell @ 2006-10-14 1:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20061013115457.7b36a7c3@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
Hi Olof,
On Fri, 13 Oct 2006 11:54:57 -0500 Olof Johansson <olof@lixom.net> wrote:
>
... lots of stuff deleted ...
Could you please trim your replies to just areasonable amount of context,
please. You are not the only one who is at fault here, but yours was the
example that came my way just as I needed to point out the problem.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-14 1:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20061014114259.0cf258ed.sfr@canb.auug.org.au>
On Sat, 14 Oct 2006 11:42:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Olof,
>
> On Fri, 13 Oct 2006 11:54:57 -0500 Olof Johansson <olof@lixom.net> wrote:
> >
> ... lots of stuff deleted ...
>
> Could you please trim your replies to just areasonable amount of context,
> please. You are not the only one who is at fault here, but yours was the
> example that came my way just as I needed to point out the problem.
I normally try to do it, I think I might have been sloppy lately.
Thanks for the reminder.
-Olof
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-14 2:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160779006.4792.269.camel@localhost.localdomain>
On Sat, 14 Oct 2006 08:36:46 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > You can advance the pointer with L1_CACHE_BYTES/sizeof(int) per
> > iteration in the second loop here.
>
> Yeah, I suppose so. Though I'm not 100% confident we get L1_CACHE_BYTES
> on all cpus, for example, PA6T is 64 bytes ;) We could use
> cur_cpu_spec->icache_bsize but that would involve ugly RELOC's to get it
> right on 32 bits. I decided not to care for now.
Ugh, yeah, I remember this when I did the patches but forgot about it
now. L1_CACHE_BYTES is used in a number of places, but overall used as
the largest value needed to bump between lines to avoid false sharing.
The other early places seems to have used hardcoded constants. I guess
it's better to just loop over every word like you're already doing. It
still avoids a barrier on every iteration.
-Olof
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-14 2:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160726663.4792.222.camel@localhost.localdomain>
On Fri, 13 Oct 2006 18:04:22 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> There are currently two versions of the functions for applying the
> feature fixups, one for CPU features and one for firmware features. In
> addition, they are both in assembly and with separate implementations
> for 32 and 64 bits. identify_cpu() is also implemented in assembly and
> separately for 32 and 64 bits.
>
> This patch replaces them with a pair of C functions. The call sites are
> slightly moved on ppc64 as well to be called from C instead of from
> assembly, though it's a very small change, and thus shouldn't cause any
> problem.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Joel Schopp @ 2006-10-14 2:12 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <20061010212324.GR4381@austin.ibm.com>
Linas Vepstas wrote:
> The current driver code performs 512 DMA mappns of a bunch of
> 32-byte structures. This is silly, as they are all in contiguous
> memory. Ths patch changes the code to DMA map the entie area
> with just one call.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: James K Lewis <jklewis@us.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
While this patch wasn't useful in the current cell implementation of pci_map_single
it sounds like people are going to be making changes to that sometime. In light of
that new information (new to me anyway) this should probably go in after all. Sorry
for causing trouble.
Acked-by: Joel Schopp <jschopp@austin.ibm.com>
^ permalink raw reply
* Re: [PATCH 2/5] powerpc: support nested cpu features
From: Olof Johansson @ 2006-10-14 2:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160726664.4792.223.camel@localhost.localdomain>
On Fri, 13 Oct 2006 18:04:24 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This patch adds some macros that can be used with an explicit label in
> order to nest cpu features. This should be used very careful but is
> necessary for the upcoming cell TB fixup.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH 5/5] powerpc: Cell timebase bug workaround
From: Olof Johansson @ 2006-10-14 2:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160726676.4792.226.camel@localhost.localdomain>
On Fri, 13 Oct 2006 18:04:36 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Better this way :-)
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* problem in running pthread application
From: Ratheesh @ 2006-10-14 6:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
Hello everybody,
I have a problem in running a pthread based
application whose source is given below.
//sample.c
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
void *thread1_function(void *);
void *thread2_function(void *);
int main(void)
{
pthread_t thread1,thread2;
char *message1 = "Thread 1";
char *message2 = "Thread 2";
int iret1,iret2;
iret1 = pthread_create(&thread1,NULL,thread1_function,(void*)message1);
iret2 = pthread_create(&thread2,NULL,thread2_function,(void*)message2);
pthread_join(thread1,iret1);
pthread_join(thread2,iret2);
printf("Thread 1 returns: %d\n",iret1);
printf("Thread 2 returns: %d\n",iret2);
exit(0);
}
void *thread1_function(void *ptr)
{
char *message;
message = (char *) ptr;
while(1)
{
printf("%s\n",message);
sleep(5);
}
}
void *thread2_function(void *ptr)
{
char *message;
message = (char *) ptr;
while(1)
{
printf("%s\n",message);
sleep(8);
}
}
//end of sample.c
I compiled using the command $powerpc-linux-uclibc-gcc -lpthread -o sample
sample.c
when I run on my target board(MPC850 based custom board), I find multiple
copies of the same program(I am invoking only once) is running. ps -e
command show the following output.
PID Uid VmSize Stat Command
1 root 392 S init
2 root SW [keventd]
3 root SWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
7 root SW [rpciod]
36 root 1284 S /bin/snmpd -Dagentx
41 root 1024 S /bin/bash
42 root 372 S /sbin/syslogd -n -m 0
43 root 348 S /sbin/klogd -n
51 root 296 S sample
52 root 296 S sample
53 root 296 S sample
54 root 296 S sample
56 root 372 R ps
Why is this program is running multiple copies in the memory? How to avoid
this.If I compile
the same program in PC(x86 with glibc) It is running fine(no multiple
copies). So how to avoid this what is wrong with my program? Please help me.
Regards,
Ratheesh
[-- Attachment #2: Type: text/html, Size: 3718 bytes --]
^ permalink raw reply
* Re: Recently removed io accessors
From: Peter Korsgaard @ 2006-10-14 11:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, sfr
In-Reply-To: <17712.7972.493547.357685@cargo.ozlabs.ibm.com>
>>>>> "PM" == Paul Mackerras <paulus@samba.org> writes:
Hi,
>> Endian register set to little endian (default at powerup):
RedBoot> x -b 0x8e000064 -2 -l 4
>> 8E000064: 4321 8765
RedBoot> x -b 0x8e000064 -4 -l 4
>> 8E000064: 43218765
PM> Which is neither big-endian nor little-endian, but something more
PM> like vax-endian (or pdp11-endian), but not exactly that either -
PM> vax-endian would be 65872143. What a mess.
Yes :/
PM> Clearly the "big endian" bit on the chip doesn't actually switch
PM> between little-endian and big-endian at all, but just acts to
PM> invert the 0x2 bit of the address...
Exactly.
PM> So the two hardware bogosities taken together leave you with only
PM> one combination that is anything like usable. I suggest that you
PM> code up a loop of readw (or equivalent) in the driver with a big
PM> comment explaining why you need to do it that way.
It doesn't have to be readw (16bit accesses). Enabling the BE mode and
using _outsl/_insl (32bit access with byteswap) works fine.
Let me repeat my question:
Could I get _outsl/_insl re-added to kernel/misc.S or do I have to
reimplement it somewhere else (platform file or smc911x.h)?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Handling machine check exception
From: ganesh subramonian @ 2006-10-14 14:04 UTC (permalink / raw)
To: Segher Boessenkool, Benjamin Herrenschmidt
Cc: ganesh subramonian, linuxppc-dev
In-Reply-To: <1924CA98-A7C7-4FD2-9709-58EC9DD6BEB6@kernel.crashing.org>
hi
the g2core manual does not say that DAR gets updated
for a machine check exception, but the mpc866um.pdf
manual says so, and it actually does work on my target
board with mpc852t. but no such reference is made in
mpc8272rm.pdf(and dar doesnt get updated on my 8247
based board).
if i cannot find out which address caused the
exception, is there any way by which i can disable
machine check for a particular range of addresses.
thanks
ganesh
--- Segher Boessenkool <segher@kernel.crashing.org>
wrote:
> >> The G2 core definitely has a DAR register (SPR
> 19).
> >>
> >> Look on the Freescale site for G2CORERM.pdf -
> this is
> >> your reference manual, not the one specifically
> for the
> >> 8247.
> >
> > Is DAR set for a machine check ?
>
> Not on these old cores.
>
>
> Segher
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Inquiring about your Linux 2.6.17.1 port to XUP
From: Ameet Patil @ 2006-10-14 17:35 UTC (permalink / raw)
To: Neil Steiner; +Cc: Dr. Neil Audsley, Ameet Patil, linuxppc-embedded
In-Reply-To: <45300A50.2010000@vt.edu>
Hi Neil,
Please help yourself! Everything in
http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/ is for public
access! And yes! You are right...
http://www.cs.york.ac.uk/rtslab/demos/amos/ is not for public.
Do post your comments or bugs (if any) on the linux embedded ppc mailing
list (linuxppc-embedded@ozlabs.org).
cheers,
-Ameet
Neil Steiner wrote:
> Dear Sirs:
>
> I came across a link to
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/ on comp.arch.fpga,
> but noticed that http://www.cs.york.ac.uk/rtslab/demos/amos/ requires
> login access, and so I wasn't sure whether or not your Linux 2.6.17.1
> files where intended for public consumption.
>
> I don't have a pressing need for a 2.6 kernel, and have instead been
> following directions from the University of Washington
> (http://www.cs.washington.edu/research/lis/empart/xup_ppc_linux.shtml)
> and Brigham Young University
> (http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm) for a 2.4
> kernel, but seeing the link to your site did pique my curiosity.
>
> My question then is simply whether I may refer to your files if they
> prove to be useful, or if they were supposed to be restricted.
>
> Neil
^ 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