* booting linux on IBM750 evaluation board
From: sharath kumar @ 2006-05-15 10:41 UTC (permalink / raw)
To: linuxppc-embedded
HI
i am working on IBM750 evaluation baord from IBM. It
has Marvel chipset.
I only have pibs running on this board.
I want to boot linux on this baord.
can anyone tell the procedure
Thanks and Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: KAMEZAWA Hiroyuki @ 2006-05-15 10:47 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: akpm, nickpiggin, tony.luck, davej, mel, linux-kernel, bob.picco,
ak, linuxppc-dev, linux-mm
In-Reply-To: <20060515192918.c3e2e895.kamezawa.hiroyu@jp.fujitsu.com>
On Mon, 15 May 2006 19:29:18 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Mon, 15 May 2006 11:19:27 +0100
> Andy Whitcroft <apw@shadowen.org> wrote:
>
> > Nick Piggin wrote:
> > > Andy Whitcroft wrote:
> > >
> > >> Interesting. You are correct there was no config component, at the time
> > >> I didn't have direct evidence that any architecture needed it, only that
> > >> we had an unchecked requirement on zones, a requirement that had only
> > >> recently arrived with the changes to free buddy detection. I note that
> > >
> > >
> > > Recently arrived? Over a year ago with the no-buddy-bitmap patches,
> > > right? Just checking because I that's what I'm assuming broke it...
> >
> > Yep, sorry I forget I was out of the game for 6 months! And yes that
> > was when the requirements were altered.
> >
> When no-bitmap-buddy patches was included,
>
> 1. bad_range() is not covered by CONFIG_VM_DEBUG. It always worked.
> ==
> static int bad_range(struct zone *zone, struct page *page)
> {
> if (page_to_pfn(page) >= zone->zone_start_pfn + zone->spanned_pages)
> return 1;
> if (page_to_pfn(page) < zone->zone_start_pfn)
> return 1;
> ==
> And , this code
> ==
> buddy = __page_find_buddy(page, page_idx, order);
>
> if (bad_range(zone, buddy))
> break;
> ==
>
> checked whether buddy is in zone and guarantees it to have page struct.
>
>
> But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
> Sorry for misses these things.
>
One more point
When above no-bitmap patches was included, the user of not-aligned zones
are only ia64, I think. Because ia64 used virtual mem_map, page_to_pfn(page)
on CONFIG_DISCONTIG_MEM doesn't access page struct itself.
#define page_to_pfn(page) (page - vmemmap)
So, it didn't panic. ia64/vmemmap was safe.
If other archs used not-aligned zone + CONFIG_DISCONTIGMEM,
not-aligned-zones problem would come out earlier.
-Kame
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: KAMEZAWA Hiroyuki @ 2006-05-15 10:29 UTC (permalink / raw)
To: Andy Whitcroft
Cc: akpm, nickpiggin, tony.luck, davej, mel, linux-kernel, bob.picco,
ak, linuxppc-dev, linux-mm
In-Reply-To: <446855AF.1090100@shadowen.org>
On Mon, 15 May 2006 11:19:27 +0100
Andy Whitcroft <apw@shadowen.org> wrote:
> Nick Piggin wrote:
> > Andy Whitcroft wrote:
> >
> >> Interesting. You are correct there was no config component, at the time
> >> I didn't have direct evidence that any architecture needed it, only that
> >> we had an unchecked requirement on zones, a requirement that had only
> >> recently arrived with the changes to free buddy detection. I note that
> >
> >
> > Recently arrived? Over a year ago with the no-buddy-bitmap patches,
> > right? Just checking because I that's what I'm assuming broke it...
>
> Yep, sorry I forget I was out of the game for 6 months! And yes that
> was when the requirements were altered.
>
When no-bitmap-buddy patches was included,
1. bad_range() is not covered by CONFIG_VM_DEBUG. It always worked.
==
static int bad_range(struct zone *zone, struct page *page)
{
if (page_to_pfn(page) >= zone->zone_start_pfn + zone->spanned_pages)
return 1;
if (page_to_pfn(page) < zone->zone_start_pfn)
return 1;
==
And , this code
==
buddy = __page_find_buddy(page, page_idx, order);
if (bad_range(zone, buddy))
break;
==
checked whether buddy is in zone and guarantees it to have page struct.
But clean-up/speed-up codes vanished these checks. (I don't know when this occurs)
Sorry for misses these things.
-Kame
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andy Whitcroft @ 2006-05-15 10:19 UTC (permalink / raw)
To: Nick Piggin
Cc: Andrew Morton, davej, tony.luck, linuxppc-dev, Mel Gorman,
linux-kernel, bob.picco, ak, linux-mm
In-Reply-To: <44685123.7040501@yahoo.com.au>
Nick Piggin wrote:
> Andy Whitcroft wrote:
>
>> Interesting. You are correct there was no config component, at the time
>> I didn't have direct evidence that any architecture needed it, only that
>> we had an unchecked requirement on zones, a requirement that had only
>> recently arrived with the changes to free buddy detection. I note that
>
>
> Recently arrived? Over a year ago with the no-buddy-bitmap patches,
> right? Just checking because I that's what I'm assuming broke it...
Yep, sorry I forget I was out of the game for 6 months! And yes that
was when the requirements were altered.
-apw
^ permalink raw reply
* Page fault when debugging a 2.6.16 kernel on MPC8248
From: Laurent Pinchart @ 2006-05-15 10:10 UTC (permalink / raw)
To: linuxppc-embedded
Hello everybody,
I'm trying to bring up Linux on a custom MPC8248 board.
I've been able to setup U-Boot correctly up to the point where I boot the
Linux kernel using bootm. The kernel doesn't print anything on the serial
console and hangs.
Thanks to a BDI2000, I've been able to get the following backtrace.
#0 cpm_uart_console_write (co=0xd,
s=0xc0203e4b "x version 2.6.16-dirty (laurent@pclaurent) (gcc version
3.4.1) #422 Thu May 11 13:30:44 CEST 2006\n<6>Technotrade S.A.",
count=1) at drivers/serial/cpm_uart/cpm_uart_core.c:1023
#1 0xc0014144 in __call_console_drivers (start=3, end=105) at
kernel/printk.c:368
#2 0xc00144f4 in release_console_sem () at kernel/printk.c:430
#3 0xc0014ce4 in register_console (console=0xc01c2e60) at kernel/printk.c:946
#4 0xc01f7308 in cpm_uart_console_init () at
drivers/serial/cpm_uart/cpm_uart_core.c:1149
#5 0xc01f673c in console_init () at drivers/char/tty_io.c:3181
#6 0xc01e85b8 in start_kernel () at init/main.c:495
#7 0x00000000 in ?? ()
At that point, all the memory read with the BDI2000 (internal memory, SDRAM,
SRAM, flash, ...) reads as 0.
Knowing that something was wrong with the memory, I tried to execute the
kernel step by step. Unfortunately, after breaking in start_kernel, the first
gdb "next" command to step over the call to printk(KERN_NOTICE) hung. Hitting
Ctrl-C in gdb returned the following backtrace.
#0 0xc0005f4c in __delay ()
#1 0xc0013b18 in panic (fmt=0x487ab0 <Address 0x487ab0 out of bounds>) at
include/asm/delay.h:42
#2 0xc001679c in do_exit (code=11) at kernel/exit.c:809
#3 0x2400c022 in ?? ()
#4 0xc0004b8c in die (str=0x3ff <Address 0x3ff out of bounds>, fp=0xc01e7c60,
err=11) at arch/ppc/kernel/traps.c:101
#5 0xc000bf3c in bad_page_fault (regs=0xc01e7c60, address=0, sig=11) at
arch/ppc/mm/fault.c:336
#6 0xc00046d0 in handle_page_fault ()
#7 0xc00046d0 in handle_page_fault ()
I'm lost here. Why does Linux page faults when executed step by step (or
rather using "next") but doesn't when running normally ? I suspect that this
could be related to the memory reading as 0 in cpm_uart_console_write.
Thanks in advance for all the help you can provide.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Re: how to mount /dev/ram0 to /
From: tony @ 2006-05-15 9:45 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
SSByZWJ1aWxkIHRoZSBidXp5Ym94LGFuZCBhZGRlZCBzb21lIHRvb2xzKGxpa2UgZG9zMnVuaXgs
c3R0eSx1bml4MmRvcyxkYyxsb2Fka21wKSAsdGhlbiBpdCB3b3Jrcyhtb3VudCAvZGV2L3JhbTAg
YXV0b21hdGljYWxseSksbWF5YmUgaXQncyBzb21ldGhpbmcgYWJvdXQgdGhlIHRvb2xzIGFib3Zl
Lg0KDQp0aGFuayBXb2xmZ2FuZyBEZW5rIGFuZCBhbGwuLg0KDQqhoaGhoaGhoaGhoaGhoaGhdG9u
eQ0KoaGhoaGhoaGhoaGhoaGhoWhhbmd0b29AMTYzLmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEy
MDA2LTA1LTE1DQo=
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Nick Piggin @ 2006-05-15 10:00 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Andrew Morton, davej, tony.luck, linuxppc-dev, Mel Gorman,
linux-kernel, bob.picco, ak, linux-mm
In-Reply-To: <44683A09.2060404@shadowen.org>
Andy Whitcroft wrote:
> Interesting. You are correct there was no config component, at the time
> I didn't have direct evidence that any architecture needed it, only that
> we had an unchecked requirement on zones, a requirement that had only
> recently arrived with the changes to free buddy detection. I note that
Recently arrived? Over a year ago with the no-buddy-bitmap patches,
right? Just checking because I that's what I'm assuming broke it...
> MAX_ORDER is 17 for ia64 so that probabally accounts for the
> missalignment. It is clear that the reporting is slightly over-zelous
> as I am reporting zero-sized zones. I'll get that fixed and patch to
> you. I'll also have a look at the patch as added to -mm and try and get
> the rest of the spelling sorted :-/.
>
> I'll go see if we currently have a machine to test this config on.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [PATCH] Fix pSeries identification in prom_init.c
From: segher @ 2006-05-15 9:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147671963.21291.91.camel@localhost.localdomain>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Paul, if you are happy with that, please send upsteam ASAP.
>
> Index: linux-work/arch/powerpc/kernel/prom_init.c
> =================================================================== ---
> linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-05-02
> 10:51:33.000000000 +1000 +++
> linux-work/arch/powerpc/kernel/prom_init.c 2006-05-15 15:37:03.000000000
> +1000 @@ -1636,7 +1636,7 @@
> compat, sizeof(compat)-1);
> if (len <= 0)
> return PLATFORM_GENERIC;
> - if (strncmp(compat, RELOC("chrp"), 4))
> + if (strcmp(compat, RELOC("chrp")))
> return PLATFORM_GENERIC;
>
> /* Default to pSeries. We need to know if we are running LPAR */
Confirmed it works correctly on affected systems. Thanks Ben.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Benjamin Herrenschmidt @ 2006-05-15 8:52 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Andrew Morton, Pete Popov, B.Zolnierkiewicz, linuxppc-dev, paulus,
Alan Cox
In-Reply-To: <20060515083847.GA5229@iram.es>
> Actually I have one of these, and regularly use it and update
> the kernel to the latest git once or twice per month, but I
> typically have two batteries and have not swapped in the
> media bay under Linux for a long time.
>
> If you are interested, I could test the patch when I find
> some time (not today: my 8 year old son went to the hospital
> for an emergency last Thursday, he is cured now and should
> come out today).
Any test is welcome, glad to know your son is well !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Gabriel Paubert @ 2006-05-15 8:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Pete Popov, B.Zolnierkiewicz, linuxppc-dev, paulus,
Alan Cox
In-Reply-To: <1147677830.21291.114.camel@localhost.localdomain>
On Mon, May 15, 2006 at 05:23:50PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2006-05-15 at 00:08 -0700, Andrew Morton wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > >
> > > It looks like the generic ide code now wants ide_init_hwif_ports() to
> > > set the parent struct device into the ide_hw structure (new field ?).
> > > Without this, the mac ide code can cause the ide probing code to explode
> > > in flames in sysfs registration due to what looks like a stale pointer
> > > in there (happens when removing/re-inserting one of the hotswap media
> > > bays on some laptops).
> > >
> >
> > You don't sound very confident.
>
> Well, the problem is fixed with my change, I'd like to have Bart
> confirmation that's its the right approach. It looks like it is but that
> code is fairly intricated :)
>
> > afaict things went bad in October last year. hw_regs_t.dev was added here:
> >
> > http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=26a940e21752e0de8f068f77dad606a7d1986937
> >
> > but that only converted one driver to initialse ->dev.
> >
> > How come things didn't break then? Did some later change cause the
> > problems?
>
> Well, for one, very few drivers cause ide_unregister nor rely on those
> old mecanism... it seems that the way I initialize things at boot works
> fine, it's when I unregister/re-register via the hotswap bay that things
> go bunk.
>
> It's possible that it got broken back then and not noticed since ... or
> another change actually made _use_ of that field... not sure, Bart might
> confirm. The Mac laptops with those hotswap bays are fairly old and I
> haven't tested for some time. I just did after getting user reports, and
> users of old machines like that tend to use stable distro kernels which
> tend to be fairly old...
Actually I have one of these, and regularly use it and update
the kernel to the latest git once or twice per month, but I
typically have two batteries and have not swapped in the
media bay under Linux for a long time.
If you are interested, I could test the patch when I find
some time (not today: my 8 year old son went to the hospital
for an emergency last Thursday, he is cured now and should
come out today).
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andy Whitcroft @ 2006-05-15 8:21 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linuxppc-dev, Mel Gorman, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <20060514203158.216a966e.akpm@osdl.org>
Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>
>>Size zones and holes in an architecture independent manner for ia64.
>>
>
>
> This one makes my ia64 die very early in boot. The trace is pretty useless.
>
> config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
>
> EFI v1.10 by INTEL: SALsystab=0x3fe4c8c0 ACPI=0x3ff84000 ACPI 2.0=0x3ff83000 MP0
> Early serial console at I/O port 0x2f8 (options '9600n8')
> SAL 3.1: Intel Corp SR870BN4 vers0
> SAL Platform features: BusLock IRQ_Redirection
> SAL: AP wakeup using external interrupt vector 0xf0
> No logical to physical processor mapping available
> iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
> ACPI: Local APIC address c0000000fee00000
> PLATFORM int CPEI (0x3): GSI 22 (level, low) -> CPU 0 (0xc618) vector 30
> register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
> 4 CPUs available, 4 CPUs total
> MCA related initialization done
> node 0 zone DMA missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> node 0 zone DMA32 missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> node 0 zone Normal missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> node 0 zone HighMem missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
> SMP: Allowing 4 CPUs, 0 hotplug CPUs
> Built 1 zonelists
> Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.17-rc4-mm1 root=/o
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 6, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 5, 524288 bytes)
> Placing software IO TLB between 0x4a30000 - 0x8a30000
> Unable to handle kernel NULL pointer dereference (address 0000000000000008)
> swapper[0]: Oops 8813272891392 [1]
> Modules linked in:
>
> Pid: 0, CPU 0, comm: swapper
> psr : 00001010084a6010 ifs : 800000000000060f ip : [<a0000001000e6750>] Notd
> ip is at __free_pages_ok+0x190/0x3c0
> unat: 0000000000000000 pfs : 000000000000060f rsc : 0000000000000003
> rnat: 0000000000ffffff bsps: 00000000000002f9 pr : 80000000afb5956b
> ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
> csd : 0930ffff00090000 ssd : 0930ffff00090000
> b0 : a0000001000e6660 b6 : e00000003fe52940 b7 : a000000100790120
> f6 : 1003e6db6db6db6db6db7 f7 : 1003e000000000006dec0
> f8 : 1003e000000000000fb80 f9 : 1003e000000000006e080
> f10 : 1003e000000000000fb40 f11 : 1003e000000000006dec0
> r1 : a000000100af2db0 r2 : 0000000000000001 r3 : 0000000000000000
> r8 : a0000001008f3d38 r9 : 0000000000004000 r10 : 0000000000370400
> r11 : 0000000000004000 r12 : a0000001007b7e10 r13 : a0000001007b0000
> r14 : 0000000000000001 r15 : 0000000100000001 r16 : 0000000100000001
> r17 : 0000000100000001 r18 : 0000000000001041 r19 : 0000000000000000
> r20 : e00000000149df00 r21 : 0000000100000000 r22 : 0000000055555155
> r23 : 00000000ffffffff r24 : e00000000149df08 r25 : 1555555555555155
> r26 : 0000000000000032 r27 : 0000000000000000 r28 : 0000000000000008
> r29 : 0000000000001041 r30 : 0000000000001041 r31 : 0000000000000001
> Unable to handle kernel NULL pointer dereference (address 0000000000000000)
> swapper[0]: Oops 8813272891392 [2]
> Modules linked in:
>
> Pid: 0, CPU 0, comm: swapper
> psr : 0000101008022018 ifs : 8000000000000287 ip : [<a0000001001236c0>] Notd
> ip is at kmem_cache_alloc+0x40/0x100
> unat: 0000000000000000 pfs : 0000000000000712 rsc : 0000000000000003
> rnat: 0000000000000000 bsps: 0000000000000000 pr : 80000000afb59967
> ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
> csd : 0930ffff00090000 ssd : 0930ffff00090000
> b0 : a00000010003e450 b6 : a000000100001b50 b7 : a00000010003f320
> f6 : 1003e9e3779b97f4a7c16 f7 : 0ffdb8000000000000000
> f8 : 1003e000000000000007f f9 : 1003e0000000000000379
> f10 : 1003e6db6db6db6db6db7 f11 : 1003e000000000000007f
> r1 : a000000100af2db0 r2 : 0000000000000000 r3 : 0000000000000000
> r8 : 0000000000000000 r9 : 0000000000000000 r10 : a0000001007b0f24
> r11 : 0000000000000000 r12 : a0000001007b7280 r13 : a0000001007b0000
> r14 : 0000000000000000 r15 : 0000000000000000 r16 : a0000001007b7310
> r17 : 0000000000000000 r18 : a0000001007b7478 r19 : 0000000000000000
> r20 : 0000000000000000 r21 : 0000000000000018 r22 : 0000000000000000
> r23 : 0000000000000000 r24 : 0000000000000000 r25 : a0000001007b7308
> r26 : 000000007fffffff r27 : a000000100825520 r28 : a0000001008f3c40
> r29 : a000000100816ca8 r30 : 0000000000000018 r31 : 0000000000000018
>
>
>
> (gdb) l *0xa0000001000e6750
> 0xa0000001000e6750 is in __free_pages_ok (mm.h:324).
> 319 extern void FASTCALL(__page_cache_release(struct page *));
> 320
> 321 static inline int page_count(struct page *page)
> 322 {
> 323 if (unlikely(PageCompound(page)))
> 324 page = (struct page *)page_private(page);
> 325 return atomic_read(&page->_count);
> 326 }
> 327
> 328 static inline void get_page(struct page *page)
>
>
> Note the misaligned pfns.
>
> Andy's (misspelled) CONFIG_UNALIGNED_ZONE_BOUNDRIES patch didn't actually
> include an update to any Kconfig files. But hacking that in by hand didn't
> help.
Interesting. You are correct there was no config component, at the time
I didn't have direct evidence that any architecture needed it, only that
we had an unchecked requirement on zones, a requirement that had only
recently arrived with the changes to free buddy detection. I note that
MAX_ORDER is 17 for ia64 so that probabally accounts for the
missalignment. It is clear that the reporting is slightly over-zelous
as I am reporting zero-sized zones. I'll get that fixed and patch to
you. I'll also have a look at the patch as added to -mm and try and get
the rest of the spelling sorted :-/.
I'll go see if we currently have a machine to test this config on.
-apw
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Benjamin Herrenschmidt @ 2006-05-15 7:23 UTC (permalink / raw)
To: Andrew Morton
Cc: B.Zolnierkiewicz, linuxppc-dev, paulus, Pete Popov, Alan Cox
In-Reply-To: <20060515000810.487b834e.akpm@osdl.org>
On Mon, 2006-05-15 at 00:08 -0700, Andrew Morton wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > It looks like the generic ide code now wants ide_init_hwif_ports() to
> > set the parent struct device into the ide_hw structure (new field ?).
> > Without this, the mac ide code can cause the ide probing code to explode
> > in flames in sysfs registration due to what looks like a stale pointer
> > in there (happens when removing/re-inserting one of the hotswap media
> > bays on some laptops).
> >
>
> You don't sound very confident.
Well, the problem is fixed with my change, I'd like to have Bart
confirmation that's its the right approach. It looks like it is but that
code is fairly intricated :)
> afaict things went bad in October last year. hw_regs_t.dev was added here:
>
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=26a940e21752e0de8f068f77dad606a7d1986937
>
> but that only converted one driver to initialse ->dev.
>
> How come things didn't break then? Did some later change cause the
> problems?
Well, for one, very few drivers cause ide_unregister nor rely on those
old mecanism... it seems that the way I initialize things at boot works
fine, it's when I unregister/re-register via the hotswap bay that things
go bunk.
It's possible that it got broken back then and not noticed since ... or
another change actually made _use_ of that field... not sure, Bart might
confirm. The Mac laptops with those hotswap bays are fairly old and I
haven't tested for some time. I just did after getting user reports, and
users of old machines like that tend to use stable distro kernels which
tend to be fairly old...
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Andrew Morton @ 2006-05-15 7:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: B.Zolnierkiewicz, linuxppc-dev, paulus, Pete Popov, Alan Cox
In-Reply-To: <1147676318.21291.105.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> It looks like the generic ide code now wants ide_init_hwif_ports() to
> set the parent struct device into the ide_hw structure (new field ?).
> Without this, the mac ide code can cause the ide probing code to explode
> in flames in sysfs registration due to what looks like a stale pointer
> in there (happens when removing/re-inserting one of the hotswap media
> bays on some laptops).
>
You don't sound very confident.
> ---
>
> Andew: That's a 2.6.17 candidate
>
> Index: linux-work/drivers/ide/ppc/pmac.c
> ===================================================================
> --- linux-work.orig/drivers/ide/ppc/pmac.c 2006-04-19 15:04:47.000000000 +1000
> +++ linux-work/drivers/ide/ppc/pmac.c 2006-05-15 16:43:20.000000000 +1000
> @@ -553,6 +553,8 @@
>
> if (irq != NULL)
> *irq = pmac_ide[ix].irq;
> +
> + hw->dev = &pmac_ide[ix].mdev->ofdev.dev;
> }
>
> #define PMAC_IDE_REG(x) ((void __iomem *)(IDE_DATA_REG+(x)))
>
afaict things went bad in October last year. hw_regs_t.dev was added here:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=26a940e21752e0de8f068f77dad606a7d1986937
but that only converted one driver to initialse ->dev.
How come things didn't break then? Did some later change cause the
problems?
^ permalink raw reply
* [PATCH] powerpc: Fix ide-pmac sysfs entry
From: Benjamin Herrenschmidt @ 2006-05-15 6:58 UTC (permalink / raw)
To: Paul Mackerras
Cc: Bartlomiej Zolnierkiewicz, Andrew Morton, linuxppc-dev list
It looks like the generic ide code now wants ide_init_hwif_ports() to
set the parent struct device into the ide_hw structure (new field ?).
Without this, the mac ide code can cause the ide probing code to explode
in flames in sysfs registration due to what looks like a stale pointer
in there (happens when removing/re-inserting one of the hotswap media
bays on some laptops).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Andew: That's a 2.6.17 candidate
Index: linux-work/drivers/ide/ppc/pmac.c
===================================================================
--- linux-work.orig/drivers/ide/ppc/pmac.c 2006-04-19 15:04:47.000000000 +1000
+++ linux-work/drivers/ide/ppc/pmac.c 2006-05-15 16:43:20.000000000 +1000
@@ -553,6 +553,8 @@
if (irq != NULL)
*irq = pmac_ide[ix].irq;
+
+ hw->dev = &pmac_ide[ix].mdev->ofdev.dev;
}
#define PMAC_IDE_REG(x) ((void __iomem *)(IDE_DATA_REG+(x)))
^ permalink raw reply
* Re: Bigphysarea vs. kernel 2.4.32 and PPC405GPr
From: Arno Geissel @ 2006-05-15 6:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e435rv$62q$1@sea.gmane.org>
Try
rc = remap_page_range(vma->vm_start,
virt_to_phys(heap_map_base),
npages*PAGE_SIZE,
vma->vm_page_prot);
Arno
> I'm trying to use the bigphysarea patch to help me allocate big
> physical chunks of memory for use by some custom embedded devices.
> I've applied the bigphysarea-2.4.20 patch and built, no trouble,
> and I've got it to config for my PPC. I can see at boot time that
> the bigphysarea is getting its pages.
>
> I'm trying to use a mmap call to the driver to map a chunk of this
> memory into the process. The mmap for the driver has this:
>
> pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
> vma->vm_flags |= VM_RESERVED;
>
> npages = (vma->vm_end - vma->vm_start) / PAGE_SIZE;
> heap_map_base = bigphysarea_alloc_pages(npages, 1, GFP_KERNEL);
>
> printk("XXXX Map base=%p, %ld pages\n", heap_map_base, npages);
>
> rc = remap_page_range(vma->vm_start,
> (unsigned long)heap_map_base,
> npages*PAGE_SIZE,
> vma->vm_page_prot);
>
> The mmap returns without an error, but any access to the mapped
> region gets me an immediate "Oops: machine check, sig: 7". I don't
> see it. Where is the stupid mistake that I'm invariably making?
^ permalink raw reply
* Re: Load average 1.0 on idle machine
From: Benjamin Herrenschmidt @ 2006-05-15 6:23 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Brian D. Carlstrom
In-Reply-To: <D0930F4F-DF46-47FF-B33C-0BE313CC81DB@embeddedalley.com>
On Mon, 2006-05-15 at 02:08 -0400, Dan Malek wrote:
> On May 14, 2006, at 9:45 PM, Benjamin Herrenschmidt wrote:
>
> > .... For now, consider
> > the load avergage value bogus :)
>
> It's not bogus :-) If you happen to schedule periodic
> tasks that are sampled with load average computes,
> or sleep them "uninterrupible", they are counted in
> the load average.
The thermal control runs every second and sleeps with "interruptible"...
so it should not have such a laod average imho :) Now it's possible that
what it does during that "second" is long enough to end up not sleeping
that much (though it's also sleeping while doing i2c accesses, but that
is uninterruptible for obvious reasons at the i2c driver level).
Ben
^ permalink raw reply
* Re: Load average 1.0 on idle machine
From: Dan Malek @ 2006-05-15 6:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Brian D. Carlstrom
In-Reply-To: <1147657558.21291.65.camel@localhost.localdomain>
On May 14, 2006, at 9:45 PM, Benjamin Herrenschmidt wrote:
> .... For now, consider
> the load avergage value bogus :)
It's not bogus :-) If you happen to schedule periodic
tasks that are sampled with load average computes,
or sleep them "uninterrupible", they are counted in
the load average.
-- Dan
^ permalink raw reply
* Re: [PATCH] Fix pSeries identification in prom_init.c
From: Benjamin Herrenschmidt @ 2006-05-15 5:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Michael Neuling
In-Reply-To: <1147671963.21291.91.camel@localhost.localdomain>
On Mon, 2006-05-15 at 15:46 +1000, Benjamin Herrenschmidt wrote:
> The OF trampoline code prom_init.c still needs to identify IBM pSeries
> (PAPR) machines in order to run some platform specific code on them like
> instanciating the TCE tables. The code doing that detection was changed
> recently in 2.6.17 early stages but was done slightly incorrectly. It
> should be testing for an exact match of "chrp" and it currently tests
> for anything that begins with "chrp". That means it will incorrectly
> match with platforms using Maple-like device-trees and have open
> firmware. This fixes it by using strcmp instead of strncmp to match what
> the actual platform detection code does.
Michael, I noticed you changed strcmp to strncmp, any reason why you did
that ?
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Paul, if you are happy with that, please send upsteam ASAP.
>
> Index: linux-work/arch/powerpc/kernel/prom_init.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-05-02 10:51:33.000000000 +1000
> +++ linux-work/arch/powerpc/kernel/prom_init.c 2006-05-15 15:37:03.000000000 +1000
> @@ -1636,7 +1636,7 @@
> compat, sizeof(compat)-1);
> if (len <= 0)
> return PLATFORM_GENERIC;
> - if (strncmp(compat, RELOC("chrp"), 4))
> + if (strcmp(compat, RELOC("chrp")))
> return PLATFORM_GENERIC;
>
> /* Default to pSeries. We need to know if we are running LPAR */
>
^ permalink raw reply
* [PATCH] Fix pSeries identification in prom_init.c
From: Benjamin Herrenschmidt @ 2006-05-15 5:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The OF trampoline code prom_init.c still needs to identify IBM pSeries
(PAPR) machines in order to run some platform specific code on them like
instanciating the TCE tables. The code doing that detection was changed
recently in 2.6.17 early stages but was done slightly incorrectly. It
should be testing for an exact match of "chrp" and it currently tests
for anything that begins with "chrp". That means it will incorrectly
match with platforms using Maple-like device-trees and have open
firmware. This fixes it by using strcmp instead of strncmp to match what
the actual platform detection code does.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Paul, if you are happy with that, please send upsteam ASAP.
Index: linux-work/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-05-02 10:51:33.000000000 +1000
+++ linux-work/arch/powerpc/kernel/prom_init.c 2006-05-15 15:37:03.000000000 +1000
@@ -1636,7 +1636,7 @@
compat, sizeof(compat)-1);
if (len <= 0)
return PLATFORM_GENERIC;
- if (strncmp(compat, RELOC("chrp"), 4))
+ if (strcmp(compat, RELOC("chrp")))
return PLATFORM_GENERIC;
/* Default to pSeries. We need to know if we are running LPAR */
^ permalink raw reply
* Re: windfarm for PM72/PM73/RM31
From: Robin H. Johnson @ 2006-05-15 3:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1147446923.5147.29.camel@celebrad>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
On Fri, May 12, 2006 at 05:15:23PM +0200, ?tienne Bersac wrote:
> > The PID params portion will come together a bit later, please bug me by
> > Wednesday next week if I haven't posted anything.
> Now we are Friday, what can we test ? ;) Sadly, my iMac G5 is under
> repair for quite some times (it crashes during compilation of mesa
> packages and never woke up).
Unfortunately I got a nasty cold, so I've been sick and need to catch up
on work stuff first.
In terms of progress, I'm still working on the windfarm_ad7417_sensor
portion, and the windfarm_pm* portions come after that.
I'll try to get a git repo up this evening, for other folk to test stuff
from.
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]
^ permalink raw reply
* [PATCH 2/4] powerpc: update iSeries viodasd device-tree entries
From: Stephen Rothwell @ 2006-05-15 3:41 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060515133947.626e10dc.sfr@canb.auug.org.au>
These devices should have device_type block and a unique compatible entry.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 4 ++--
drivers/block/viodasd.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
def2bd59c3c1891f626a4cea9ac47e5fc8b64118
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 0a08257..285f2b2 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -971,8 +971,8 @@ void dt_vdevices(struct iseries_flat_dt
for (i = 0; i < HVMAXARCHITECTEDVIRTUALDISKS; i++) {
snprintf(buf, 32, "viodasd@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "viodasd");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "block");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-viodasd");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
dt_end_node(dt);
diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c
index f63e07b..b0df4f5 100644
--- a/drivers/block/viodasd.c
+++ b/drivers/block/viodasd.c
@@ -747,7 +747,7 @@ static int viodasd_remove(struct vio_dev
* support.
*/
static struct vio_device_id viodasd_device_table[] __devinitdata = {
- { "viodasd", "" },
+ { "block", "IBM,iSeries-viodasd" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, viodasd_device_table);
--
1.3.1.ge923
^ permalink raw reply related
* [PATCH 4/4] powerpc: update iSeries viocd and viotape device-tree
From: Stephen Rothwell @ 2006-05-15 3:44 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060515133947.626e10dc.sfr@canb.auug.org.au>
Make their device_type entries more generic and their compatible entries
more specific.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 8 ++++----
drivers/cdrom/viocd.c | 2 +-
drivers/char/viotape.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
c9249bed9c2383b360272b9384e5ca258d523e24
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index d3f94b4..074d1d9 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -982,8 +982,8 @@ void dt_vdevices(struct iseries_flat_dt
for (i = 0; i < HVMAXARCHITECTEDVIRTUALCDROMS; i++) {
snprintf(buf, 32, "viocd@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "viocd");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "block");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-viocd");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
dt_end_node(dt);
@@ -992,8 +992,8 @@ void dt_vdevices(struct iseries_flat_dt
for (i = 0; i < HVMAXARCHITECTEDVIRTUALTAPES; i++) {
snprintf(buf, 32, "viotape@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "viotape");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "byte");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-viotape");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
dt_end_node(dt);
diff --git a/drivers/cdrom/viocd.c b/drivers/cdrom/viocd.c
index c0f817b..af6b3bf 100644
--- a/drivers/cdrom/viocd.c
+++ b/drivers/cdrom/viocd.c
@@ -731,7 +731,7 @@ static int viocd_remove(struct vio_dev *
* support.
*/
static struct vio_device_id viocd_device_table[] __devinitdata = {
- { "viocd", "" },
+ { "block", "IBM,iSeries-viocd" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, viocd_device_table);
diff --git a/drivers/char/viotape.c b/drivers/char/viotape.c
index 60aabdb..11c7e9d 100644
--- a/drivers/char/viotape.c
+++ b/drivers/char/viotape.c
@@ -989,7 +989,7 @@ static int viotape_remove(struct vio_dev
* support.
*/
static struct vio_device_id viotape_device_table[] __devinitdata = {
- { "viotape", "" },
+ { "byte", "IBM,iSeries-viotape" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, viotape_device_table);
--
1.3.1.ge923
^ permalink raw reply related
* [PATCH 3/4] powerpc: update iSeries vdevice
From: Stephen Rothwell @ 2006-05-15 3:42 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20060515133947.626e10dc.sfr@canb.auug.org.au>
Make it look more like the pSeries vdevice tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
a8b78e46b1b998769fb45fbd9e37fc6ceebf06b1
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 285f2b2..d3f94b4 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -921,13 +921,14 @@ void dt_vdevices(struct iseries_flat_dt
char buf[32];
dt_start_node(dt, "vdevice");
+ dt_prop_str(dt, "device_type", "vdevice");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-vdevice");
dt_prop_u32(dt, "#address-cells", 1);
dt_prop_u32(dt, "#size-cells", 0);
- snprintf(buf, sizeof(buf), "viocons@%08x", reg);
+ snprintf(buf, sizeof(buf), "vty@%08x", reg);
dt_start_node(dt, buf);
dt_prop_str(dt, "device_type", "serial");
- dt_prop_str(dt, "compatible", "");
dt_prop_u32(dt, "reg", reg);
dt_end_node(dt);
reg++;
--
1.3.1.ge923
^ permalink raw reply related
* [PATCH 1/4] powerpc: update iseries_veth device-tree information
From: Stephen Rothwell @ 2006-05-15 3:39 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Make the device-tree information more generic and more
like the pSeries virtual lan device. Also use the MAC
address from the device tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 8 +++++---
drivers/net/iseries_veth.c | 27 +++++++++++++++++----------
2 files changed, 22 insertions(+), 13 deletions(-)
These patches are relative to the current powerpc kernel tree and have
been built and run on an iSeries 270. They should be suitable for 2.6.18.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
6f393cd3fd10e4ee54a3cc4cf0cfff391d5be555
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index befd36a..0a08257 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -946,10 +946,10 @@ void dt_vdevices(struct iseries_flat_dt
if ((vlan_map & (0x8000 >> i)) == 0)
continue;
- snprintf(buf, 32, "vlan@%08x", reg + i);
+ snprintf(buf, 32, "l-lan@%08x", reg + i);
dt_start_node(dt, buf);
- dt_prop_str(dt, "device_type", "vlan");
- dt_prop_str(dt, "compatible", "");
+ dt_prop_str(dt, "device_type", "network");
+ dt_prop_str(dt, "compatible", "IBM,iSeries-l-lan");
dt_prop_u32(dt, "reg", reg + i);
dt_prop_u32(dt, "linux,unit_address", i);
@@ -961,6 +961,8 @@ void dt_vdevices(struct iseries_flat_dt
mac_addr[5] = HvLpConfig_getLpIndex_outline();
dt_prop(dt, "local-mac-address", (char *)mac_addr, ETH_ALEN);
dt_prop(dt, "mac-address", (char *)mac_addr, ETH_ALEN);
+ dt_prop_u32(dt, "max-frame-size", 9000);
+ dt_prop_u32(dt, "address-bits", 48);
dt_end_node(dt);
}
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index f0f04be..93394d7 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -69,6 +69,7 @@ #include <linux/init.h>
#include <linux/delay.h>
#include <linux/mm.h>
#include <linux/ethtool.h>
+#include <linux/if_ether.h>
#include <asm/abs_addr.h>
#include <asm/iseries/mf.h>
@@ -1035,11 +1036,22 @@ static struct ethtool_ops ops = {
.get_link = veth_get_link,
};
-static struct net_device * __init veth_probe_one(int vlan, struct device *vdev)
+static struct net_device * __init veth_probe_one(int vlan,
+ struct vio_dev *vio_dev)
{
struct net_device *dev;
struct veth_port *port;
+ struct device *vdev = &vio_dev->dev;
int i, rc;
+ const unsigned char *mac_addr;
+
+ mac_addr = vio_get_attribute(vio_dev, "local-mac-address", NULL);
+ if (mac_addr == NULL)
+ mac_addr = vio_get_attribute(vio_dev, "mac-address", NULL);
+ if (mac_addr == NULL) {
+ veth_error("Unable to fetch MAC address from device tree.\n");
+ return NULL;
+ }
dev = alloc_etherdev(sizeof (struct veth_port));
if (! dev) {
@@ -1064,16 +1076,11 @@ static struct net_device * __init veth_p
}
port->dev = vdev;
- dev->dev_addr[0] = 0x02;
- dev->dev_addr[1] = 0x01;
- dev->dev_addr[2] = 0xff;
- dev->dev_addr[3] = vlan;
- dev->dev_addr[4] = 0xff;
- dev->dev_addr[5] = this_lp;
+ memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
dev->mtu = VETH_MAX_MTU;
- memcpy(&port->mac_addr, dev->dev_addr, 6);
+ memcpy(&port->mac_addr, mac_addr, ETH_ALEN);
dev->open = veth_open;
dev->hard_start_xmit = veth_start_xmit;
@@ -1608,7 +1615,7 @@ static int veth_probe(struct vio_dev *vd
struct net_device *dev;
struct veth_port *port;
- dev = veth_probe_one(i, &vdev->dev);
+ dev = veth_probe_one(i, vdev);
if (dev == NULL) {
veth_remove(vdev);
return 1;
@@ -1641,7 +1648,7 @@ static int veth_probe(struct vio_dev *vd
* support.
*/
static struct vio_device_id veth_device_table[] __devinitdata = {
- { "vlan", "" },
+ { "network", "IBM,iSeries-l-lan" },
{ "", "" }
};
MODULE_DEVICE_TABLE(vio, veth_device_table);
--
1.3.1.ge923
^ permalink raw reply related
* Re: [PATCH 5/6] Have ia64 use add_active_range() and free_area_init_nodes
From: Andrew Morton @ 2006-05-15 3:31 UTC (permalink / raw)
To: Mel Gorman, Andy Whitcroft
Cc: davej, tony.luck, linuxppc-dev, mel, linux-kernel, bob.picco, ak,
linux-mm
In-Reply-To: <20060508141211.26912.48278.sendpatchset@skynet>
Mel Gorman <mel@csn.ul.ie> wrote:
>
> Size zones and holes in an architecture independent manner for ia64.
>
This one makes my ia64 die very early in boot. The trace is pretty useless.
config at http://www.zip.com.au/~akpm/linux/patches/stuff/config-ia64
EFI v1.10 by INTEL: SALsystab=0x3fe4c8c0 ACPI=0x3ff84000 ACPI 2.0=0x3ff83000 MP0
Early serial console at I/O port 0x2f8 (options '9600n8')
SAL 3.1: Intel Corp SR870BN4 vers0
SAL Platform features: BusLock IRQ_Redirection
SAL: AP wakeup using external interrupt vector 0xf0
No logical to physical processor mapping available
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
PLATFORM int CPEI (0x3): GSI 22 (level, low) -> CPU 0 (0xc618) vector 30
register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
4 CPUs available, 4 CPUs total
MCA related initialization done
node 0 zone DMA missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
node 0 zone DMA32 missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
node 0 zone Normal missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
node 0 zone HighMem missaligned start pfn, enable UNALIGNED_ZONE_BOUNDRIES
SMP: Allowing 4 CPUs, 0 hotplug CPUs
Built 1 zonelists
Kernel command line: BOOT_IMAGE=scsi0:\EFI\redhat\vmlinuz-2.6.17-rc4-mm1 root=/o
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 6, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 5, 524288 bytes)
Placing software IO TLB between 0x4a30000 - 0x8a30000
Unable to handle kernel NULL pointer dereference (address 0000000000000008)
swapper[0]: Oops 8813272891392 [1]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 00001010084a6010 ifs : 800000000000060f ip : [<a0000001000e6750>] Notd
ip is at __free_pages_ok+0x190/0x3c0
unat: 0000000000000000 pfs : 000000000000060f rsc : 0000000000000003
rnat: 0000000000ffffff bsps: 00000000000002f9 pr : 80000000afb5956b
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0930ffff00090000 ssd : 0930ffff00090000
b0 : a0000001000e6660 b6 : e00000003fe52940 b7 : a000000100790120
f6 : 1003e6db6db6db6db6db7 f7 : 1003e000000000006dec0
f8 : 1003e000000000000fb80 f9 : 1003e000000000006e080
f10 : 1003e000000000000fb40 f11 : 1003e000000000006dec0
r1 : a000000100af2db0 r2 : 0000000000000001 r3 : 0000000000000000
r8 : a0000001008f3d38 r9 : 0000000000004000 r10 : 0000000000370400
r11 : 0000000000004000 r12 : a0000001007b7e10 r13 : a0000001007b0000
r14 : 0000000000000001 r15 : 0000000100000001 r16 : 0000000100000001
r17 : 0000000100000001 r18 : 0000000000001041 r19 : 0000000000000000
r20 : e00000000149df00 r21 : 0000000100000000 r22 : 0000000055555155
r23 : 00000000ffffffff r24 : e00000000149df08 r25 : 1555555555555155
r26 : 0000000000000032 r27 : 0000000000000000 r28 : 0000000000000008
r29 : 0000000000001041 r30 : 0000000000001041 r31 : 0000000000000001
Unable to handle kernel NULL pointer dereference (address 0000000000000000)
swapper[0]: Oops 8813272891392 [2]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 0000101008022018 ifs : 8000000000000287 ip : [<a0000001001236c0>] Notd
ip is at kmem_cache_alloc+0x40/0x100
unat: 0000000000000000 pfs : 0000000000000712 rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 80000000afb59967
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0930ffff00090000 ssd : 0930ffff00090000
b0 : a00000010003e450 b6 : a000000100001b50 b7 : a00000010003f320
f6 : 1003e9e3779b97f4a7c16 f7 : 0ffdb8000000000000000
f8 : 1003e000000000000007f f9 : 1003e0000000000000379
f10 : 1003e6db6db6db6db6db7 f11 : 1003e000000000000007f
r1 : a000000100af2db0 r2 : 0000000000000000 r3 : 0000000000000000
r8 : 0000000000000000 r9 : 0000000000000000 r10 : a0000001007b0f24
r11 : 0000000000000000 r12 : a0000001007b7280 r13 : a0000001007b0000
r14 : 0000000000000000 r15 : 0000000000000000 r16 : a0000001007b7310
r17 : 0000000000000000 r18 : a0000001007b7478 r19 : 0000000000000000
r20 : 0000000000000000 r21 : 0000000000000018 r22 : 0000000000000000
r23 : 0000000000000000 r24 : 0000000000000000 r25 : a0000001007b7308
r26 : 000000007fffffff r27 : a000000100825520 r28 : a0000001008f3c40
r29 : a000000100816ca8 r30 : 0000000000000018 r31 : 0000000000000018
(gdb) l *0xa0000001000e6750
0xa0000001000e6750 is in __free_pages_ok (mm.h:324).
319 extern void FASTCALL(__page_cache_release(struct page *));
320
321 static inline int page_count(struct page *page)
322 {
323 if (unlikely(PageCompound(page)))
324 page = (struct page *)page_private(page);
325 return atomic_read(&page->_count);
326 }
327
328 static inline void get_page(struct page *page)
Note the misaligned pfns.
Andy's (misspelled) CONFIG_UNALIGNED_ZONE_BOUNDRIES patch didn't actually
include an update to any Kconfig files. But hacking that in by hand didn't
help.
^ 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