Re: 2.6.12-rc4-mm2

Re: 2.6.12-rc4-mm2

[Andrew Morton]

(cc's added)

"Richard Purdie" <rpurdie@rpsys.net> wrote:
>
> Russell King:
> > On Mon, May 16, 2005 at 01:00:48PM -0700, Andrew Morton wrote:
> >> Any idea why init is trying to exit?
> >
> > I was hoping you weren't going to ask me.
> >
> > Not really.  My initial thoughts would be maybe init getting a SEGV
> > or ILL, but normally when that happens the system is thrown into an
> > infinite loop because of the "init is specal and doesn't get any
> > signals it hasn't claimed" rule.  Or at least that's what happens
> > with conventional sysvinit.  However, I've no idea what or how the
> > embedded init program behaves in this respect - never had that
> > experience yet.
> >
> > I guess Richard needs to work through the patch sets between the
> > last version which worked and the next which didn't.
> 
> After some investigation, the guilty patch is:
> avoiding-mmap-fragmentation.patch
> (and hence) avoiding-mmap-fragmentation-tidy.patch
> 
> For reference, whilst debugging the error from init changed to: 
> "inconsistency detected by ld.so: ../sysdeps/generic/dl-cache.c: 235: 
> _dl_load_cache_lookup: Assertion `cache != ((void *)0)` failed!" which would 
> agree with some kind of memory corruption.
> 
> Its a bit late for me to try and debug this further and I'm not sure I know 
> the mm layer well enough to do so anyway. With these patches removed, -mm1 
> boots fine. I'm confident the same will apply to -mm2.

Great, thanks.

Wolfgang, we broke ARM.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Wolfgang Wander]

Thanks Richard for the debugging.

Can you try the following patch that fixes a stupid typo of mine:

Signed-off-by: Wolfgang Wander <wwc@rentec.com>

--- linux-2.6.12-rc4-wwc/arch/arm/mm/mmap.c~    2005-05-10 16:33:34.000000000 -0400
+++ linux-2.6.12-rc4-wwc/arch/arm/mm/mmap.c     2005-05-16 20:10:05.000000000 -0400
@@ -76,7 +76,7 @@ arch_get_unmapped_area(struct file *filp
        if( len > mm->cached_hole_size )
                start_addr = addr = mm->free_area_cache;
        else {
-               start_addr = TASK_UNMAPPED_BASE;
+               start_addr = addr = TASK_UNMAPPED_BASE;
                mm->cached_hole_size = 0;
        }
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Richard Purdie]

Wolfgang Wander:
> > > Its a bit late for me to try and debug this further and I'm not sure I 
> > > know
> > > the mm layer well enough to do so anyway. With these patches 
> > > removed, -mm1
> > > boots fine. I'm confident the same will apply to -mm2.
> >
> > Great, thanks.
> >
> > Wolfgang, we broke ARM.
>
> Thanks Richard for the debugging.
>
> Can you try the following patch that fixes a stupid typo of mine:

I applied this against -mm2 and can comfirm it fixes the problem.

Thanks,

Richard


> Signed-off-by: Wolfgang Wander <wwc@rentec.com>
>
> --- linux-2.6.12-rc4-wwc/arch/arm/mm/mmap.c~    2005-05-10 
> 16:33:34.000000000 -0400
> +++ linux-2.6.12-rc4-wwc/arch/arm/mm/mmap.c     2005-05-16 
> 20:10:05.000000000 -0400
> @@ -76,7 +76,7 @@ arch_get_unmapped_area(struct file *filp
>        if( len > mm->cached_hole_size )
>                start_addr = addr = mm->free_area_cache;
>        else {
> -               start_addr = TASK_UNMAPPED_BASE;
> +               start_addr = addr = TASK_UNMAPPED_BASE;
>                mm->cached_hole_size = 0;
>        }
>
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Russell King]

On Mon, May 16, 2005 at 04:39:00PM -0700, Andrew Morton wrote:
> (cc's added)
> 
> "Richard Purdie" <rpurdie@rpsys.net> wrote:
> >
> > Russell King:
> > > On Mon, May 16, 2005 at 01:00:48PM -0700, Andrew Morton wrote:
> > >> Any idea why init is trying to exit?
> > >
> > > I was hoping you weren't going to ask me.
> > >
> > > Not really.  My initial thoughts would be maybe init getting a SEGV
> > > or ILL, but normally when that happens the system is thrown into an
> > > infinite loop because of the "init is specal and doesn't get any
> > > signals it hasn't claimed" rule.  Or at least that's what happens
> > > with conventional sysvinit.  However, I've no idea what or how the
> > > embedded init program behaves in this respect - never had that
> > > experience yet.
> > >
> > > I guess Richard needs to work through the patch sets between the
> > > last version which worked and the next which didn't.
> > 
> > After some investigation, the guilty patch is:
> > avoiding-mmap-fragmentation.patch
> > (and hence) avoiding-mmap-fragmentation-tidy.patch
> > 
> > For reference, whilst debugging the error from init changed to: 
> > "inconsistency detected by ld.so: ../sysdeps/generic/dl-cache.c: 235: 
> > _dl_load_cache_lookup: Assertion `cache != ((void *)0)` failed!" which would 
> > agree with some kind of memory corruption.
> > 
> > Its a bit late for me to try and debug this further and I'm not sure I know 
> > the mm layer well enough to do so anyway. With these patches removed, -mm1 
> > boots fine. I'm confident the same will apply to -mm2.
> 
> Great, thanks.
> 
> Wolfgang, we broke ARM.

I'm not sure what happened with this, but there's someone reporting that
-rc5-mm1 doesn't work.  Unfortunately, there's not a lot to go on:

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-May/029188.html

Could be unrelated for all I know.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Wolfgang Wander]

Russell King writes:
 > > Great, thanks.
 > > 
 > > Wolfgang, we broke ARM.
 > 
 > I'm not sure what happened with this, but there's someone reporting that
 > -rc5-mm1 doesn't work.  Unfortunately, there's not a lot to go on:
 > 
 > http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-May/029188.html
 > 
 > Could be unrelated for all I know.

It probably wasn't (the message you point is a little sparse on information) - 
however -mm2 already contains a fix for a two little bugs in -mm1, 
thanks to Ken.

        Wolfgang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Richard Purdie]

Russell King:
>> > After some investigation, the guilty patch is:
>> > avoiding-mmap-fragmentation.patch
>> > (and hence) avoiding-mmap-fragmentation-tidy.patch
>
>> Wolfgang, we broke ARM.
>
> I'm not sure what happened with this, but there's someone reporting that
> -rc5-mm1 doesn't work.  Unfortunately, there's not a lot to go on:
>
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-May/029188.html
>
> Could be unrelated for all I know.

I found the above patch at fault, Wolfgang gave me a fix which I tested, 
confirmed working and that was going into future -mm releases last I heard. 
I've not had a chance to test -rc5 onwards myself yet due to the Nokia 
whirlwind but I doubt its the above problem.

I have heard comment that recent arm kernels on collie (sa1100) fail to boot 
for unknown reasons. The collie maintainer was looking into it - I only have 
pxa hardware to test with myself (which was working as of the last -rc4-mm 
release).

I'll update with the results of -rc5 on the pxa once I've tested it.

Cheers,

Richard 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Richard Purdie]

Russell King:
>
> I'm not sure what happened with this, but there's someone reporting that
> -rc5-mm1 doesn't work.  Unfortunately, there's not a lot to go on:
>
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-May/029188.html
>
> Could be unrelated for all I know.

I've just tried 2.6.12-rc5-mm2 on the Zaurus (arm pxa) and its "not happy". 
I'm seeing segfaults as it boots, particularly around udev and hotplug 
initilisation but in other places as well. Over three different bootups, I 
saw the segfaults move around to different scripts so something fundamental 
is wrong. On the last attempt, it looked up solid and failed to boot. No 
oops or any interesting debug information.

I'll roll back to 2.6.12-rc5-mm1 and see how that works next. I guess I'll 
just have to start a binary search after that (again :-/) unless anyone has 
any ideas of what changed that might cause this?

(2.6.12-rc4-mm2 and 2.6.12-rc5 are known good)

Richard 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Richard Purdie]

Russell King:
> I'm not sure what happened with this, but there's someone reporting that
> -rc5-mm1 doesn't work.  Unfortunately, there's not a lot to go on:
>
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-May/029188.html
>
> Could be unrelated for all I know.

One more data point. Booting 2.6.12-rc5-mm1 shows:

Linux version 2.6.12-rc5-mm1-3.5.3-snapshot-20050604 (richard@tim) (gcc 
version 3.4.3) #1 Sat Jun 4 15:32:28 BST 2005
CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE)
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Machine: SHARP Husky
Ignoring unrecognised tag 0x00000000
Memory policy: ECC disabled, Data cache writeback
Memory clock: 99.53MHz (*27)
Run Mode clock: 199.07MHz (*2)
Turbo Mode clock: 398.13MHz (*2.0, active)
Built 1 zonelists
Kernel command line: console=ttyS0,115200n8 console=tty1 noinitrd 
root=/dev/mtdblock2 rootfstype=jffs2
PID hash table entries: 512 (order: 9, 8192 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 64MB = 64MB total
Memory: 62208KB available (2104K code, 410K data, 76K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok

Then stops dead (have to pull the battery to reset).

This will probably be what's referred to in the above email.

Richard 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Richard Purdie]

Russell King:
> I'm not sure what happened with this, but there's someone reporting that
> -rc5-mm1 doesn't work.  Unfortunately, there's not a lot to go on:
>
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-May/029188.html
>
> Could be unrelated for all I know.

I've been going around in circles chasing the previously mentioned memory 
corruption type bug. It causes random(ish) segfaults as the system boots. 
Sometimes they're serious and stop the system dead sometimes they're not. I 
have also see alignment errors and floating point errors.

I've traced this back to 2.6.12-rc4-git1. 2.6.12-rc4 works fine. The -git1 
release has these random segfaults. I'd previously said 2.6.12-rc5 was ok - 
it isn't, it was just more subtlety broken :-(. This may or may not by why 
2.6.12-rc5-mm1 stops dead and certainly looks similar to the random 
segfaults under 2.6.12-rc5-mm2.

2.6.12-rc4-git1 contains the following patches:

    [PATCH] Fix root hole in pktcdvd
    [PATCH] Fix root hole in raw device
    [PATCH] fix Linux kernel ELF core dump privilege elevation
    [PATCH] ARM: Fix build error
    [PATCH] wireless: 3CRWE154G72 Kconfig help fix
    [PATCH] Typo in tulip driver
    [PATCH] {PATCH] Fix IBM EMAC driver ioctl bug
    [PATCH] drivers/net/wireless enabled by wrong option
    [PATCH] ARM: 2678/1: S3C2440 - cpu fixes, hdiv divisors and nand dev 
name
    [PATCH] ARM: 2676/1: S3C2440 - NAND register additions
    [PATCH] ARM: 2677/1: S3C2440 - UPLL frequency doubled
    [PATCH] ARM: 2680/1: refine TLS reg availability some more again
    [PATCH] ARM: 2666/1: i.MX pwm controller defines
    [PATCH] ARM: 2663/2: I can't type
    [PATCH] ARM: Add V6 aliasing cache flush
    [PATCH] ARM: Use top_pmd for V6 copy/clear user_page
    [PATCH] ARM: Move copy/clear user_page locking into implementation
    [PATCH] ARM: Add top_pmd, which points at the top-most page table
    [PATCH] Serial: Add uart_insert_char()
    [PATCH] ARM: Add inline functions to find the pmd from virtual address
    [PATCH] MMC: wbsd update

There are some farily serious mm changes on arm there and I suspect one of 
them is at fault.

Russell: Any idea which one it might be offhand?

Richard 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Russell King]

On Sun, Jun 05, 2005 at 12:39:36PM +0100, Richard Purdie wrote:
> 2.6.12-rc4-git1 contains the following patches:
> 
>     [PATCH] Fix root hole in pktcdvd
>     [PATCH] Fix root hole in raw device
>     [PATCH] fix Linux kernel ELF core dump privilege elevation
>     [PATCH] ARM: Fix build error
>     [PATCH] wireless: 3CRWE154G72 Kconfig help fix
>     [PATCH] Typo in tulip driver
>     [PATCH] {PATCH] Fix IBM EMAC driver ioctl bug
>     [PATCH] drivers/net/wireless enabled by wrong option
>     [PATCH] ARM: 2678/1: S3C2440 - cpu fixes, hdiv divisors and nand dev 
> name
>     [PATCH] ARM: 2676/1: S3C2440 - NAND register additions
>     [PATCH] ARM: 2677/1: S3C2440 - UPLL frequency doubled
>     [PATCH] ARM: 2680/1: refine TLS reg availability some more again
>     [PATCH] ARM: 2666/1: i.MX pwm controller defines
>     [PATCH] ARM: 2663/2: I can't type
>     [PATCH] ARM: Add V6 aliasing cache flush
>     [PATCH] ARM: Use top_pmd for V6 copy/clear user_page
>     [PATCH] ARM: Move copy/clear user_page locking into implementation

This one changes the way we do these operations on SA1100, but it got
tested prior to submission on the Assabet which didn't show anything
up.  However, if I had to pick one, it'd be this.

>     [PATCH] ARM: Add top_pmd, which points at the top-most page table
>     [PATCH] Serial: Add uart_insert_char()
>     [PATCH] ARM: Add inline functions to find the pmd from virtual address
>     [PATCH] MMC: wbsd update

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Richard Purdie]

Russell King:
>>     [PATCH] ARM: Move copy/clear user_page locking into implementation
>
> This one changes the way we do these operations on SA1100, but it got
> tested prior to submission on the Assabet which didn't show anything
> up.  However, if I had to pick one, it'd be this.

And testing confirms this patch is indeed at fault. Adding/removing the code 
below stabilises/destabilises the system (I'm defining instability as random 
segfaults, floating point errors, illegal instructions and alignment 
errors).

The test system is ARM PXA255 based (v5te core, preempt enabled) and its 
using copypage-xscale.S. I suspect the locking below is needed on the xscale 
for some reason.

Does that make sense and highlight a problem?

Richard


--- a/include/asm-arm/page.h
+++ b/include/asm-arm/page.h
@@ -114,19 +114,8 @@ extern void __cpu_copy_user_page(void *t
      unsigned long user);
 #endif

-#define clear_user_page(addr,vaddr,pg)   \
- do {      \
-  preempt_disable();   \
-  __cpu_clear_user_page(addr, vaddr); \
-  preempt_enable();   \
- } while (0)
-
-#define copy_user_page(to,from,vaddr,pg)  \
- do {      \
-  preempt_disable();   \
-  __cpu_copy_user_page(to, from, vaddr); \
-  preempt_enable();   \
- } while (0)
+#define clear_user_page(addr,vaddr,pg)  __cpu_clear_user_page(addr, vaddr)
+#define copy_user_page(to,from,vaddr,pg) __cpu_copy_user_page(to, from, 
vaddr)

 #define clear_page(page) memzero((void *)(page), PAGE_SIZE)
 extern void copy_page(void *to, const void *from); 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: 2.6.12-rc4-mm2

[Russell King]

On Sun, Jun 05, 2005 at 07:43:38PM +0100, Richard Purdie wrote:
> Russell King:
> >>     [PATCH] ARM: Move copy/clear user_page locking into implementation
> >
> > This one changes the way we do these operations on SA1100, but it got
> > tested prior to submission on the Assabet which didn't show anything
> > up.  However, if I had to pick one, it'd be this.
> 
> The test system is ARM PXA255 based (v5te core, preempt enabled) and its 
> using copypage-xscale.S. I suspect the locking below is needed on the xscale 
> for some reason.
> 
> Does that make sense and highlight a problem?

You must be running with preemption enabled then, and it looks like
I forgot to update the Xscale copypage functions for this change.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>