* Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
@ 2006-06-21 11:07 ` Michal Piotrowski
2006-06-21 11:17 ` 2.6.17-mm1 Andrew Morton
2006-06-21 11:28 ` 2.6.17-mm1 Andrew Morton
` (29 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Michal Piotrowski @ 2006-06-21 11:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: H. Peter Anvin, linux-kernel
Hi,
On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>
>
> - powerpc is bust (on g5, at least). git-klibc is causing nash to fail on
> startup and some later patch is causing a big crash (I didn't bisect that
> one - later).
>
> - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> toolchain might be implicated).
>
I have the similar problem here
usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
or directory
usr/klibc/syscalls/typesize.c:5: error: '__u32' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:9: error: expected ')' before 'gid_t'
usr/klibc/syscalls/typesize.c:9: warning: type defaults to 'int' in
declaration of 'type name'
usr/klibc/syscalls/typesize.c:10: error: expected ')' before 'sigset_t'
usr/klibc/syscalls/typesize.c:10: warning: type defaults to 'int' in
declaration of 'type name'
usr/klibc/syscalls/typesize.c:21: error: 'dev_t' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:22: error: 'fd_set' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:22: error: expected expression before ')' token
make[4]: *** [usr/klibc/syscalls/typesize.o] Error 1
make[3]: *** [usr/klibc/syscalls] Error 2
make[2]: *** [_usr_klibc] Error 2
make[1]: *** [usr] Error 2
make: *** [_all] Error 2
Linux ltg01-fedora.pl 2.6.17-g25f42b6a #63 SMP PREEMPT Tue Jun 20
14:28:14 CEST 2006 i686 i686 i386 GNU/Linux
Gnu C 4.1.1
Gnu make 3.80
binutils 2.16.91.0.6
util-linux 2.13-pre7
mount 2.13-pre7
module-init-tools 3.2.2
e2fsprogs 1.38
jfsutils 1.1.10
reiserfsprogs 3.6.19
xfsprogs 2.7.3
PPP 2.4.3
Linux C Library > libc.2.4
Dynamic linker (ldd) 2.4
Procps 3.2.6
Net-tools 1.60
Kbd 1.12
Sh-utils 5.96
udev 084
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-21 11:07 ` 2.6.17-mm1 Michal Piotrowski
@ 2006-06-21 11:17 ` Andrew Morton
2006-06-21 11:29 ` 2.6.17-mm1 Michal Piotrowski
0 siblings, 1 reply; 132+ messages in thread
From: Andrew Morton @ 2006-06-21 11:17 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: hpa, linux-kernel
On Wed, 21 Jun 2006 13:07:41 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> >
> >
> > - powerpc is bust (on g5, at least). git-klibc is causing nash to fail on
> > startup and some later patch is causing a big crash (I didn't bisect that
> > one - later).
> >
> > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> > toolchain might be implicated).
> >
>
> I have the similar problem here
>
> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> or directory
That one's probably just a parallel kbuild race. Type `make' again.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 11:17 ` 2.6.17-mm1 Andrew Morton
@ 2006-06-21 11:29 ` Michal Piotrowski
2006-06-21 13:53 ` 2.6.17-mm1 Cedric Le Goater
0 siblings, 1 reply; 132+ messages in thread
From: Michal Piotrowski @ 2006-06-21 11:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: hpa, linux-kernel
On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 21 Jun 2006 13:07:41 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> > On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> > >
> > >
> > > - powerpc is bust (on g5, at least). git-klibc is causing nash to fail on
> > > startup and some later patch is causing a big crash (I didn't bisect that
> > > one - later).
> > >
> > > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> > > toolchain might be implicated).
> > >
> >
> > I have the similar problem here
> >
> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> > or directory
>
> That one's probably just a parallel kbuild race. Type `make' again.
>
"make O=/dir" is culprit.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 11:29 ` 2.6.17-mm1 Michal Piotrowski
@ 2006-06-21 13:53 ` Cedric Le Goater
2006-06-21 14:13 ` 2.6.17-mm1 Michal Piotrowski
2006-06-21 16:44 ` 2.6.17-mm1 H. Peter Anvin
0 siblings, 2 replies; 132+ messages in thread
From: Cedric Le Goater @ 2006-06-21 13:53 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: Andrew Morton, hpa, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
Michal Piotrowski wrote:
>> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
>> > or directory
>>
>> That one's probably just a parallel kbuild race. Type `make' again.
>>
>
> "make O=/dir" is culprit.
>
> Regards,
> Michal
>
That's how i fixed it. Is that the right way to do it ?
Thanks,
C.
[-- Attachment #2: klibc-fix-kbuild-output-issue.patch --]
[-- Type: text/x-patch, Size: 917 bytes --]
From: Cedric Le Goater <clg@fr.ibm.com>
Subject: [KLIBC] fix compile issue when KBUILD_OUTPUT is used
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
---
scripts/Kbuild.klibc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: 2.6.17-mm1/scripts/Kbuild.klibc
===================================================================
--- 2.6.17-mm1.orig/scripts/Kbuild.klibc
+++ 2.6.17-mm1/scripts/Kbuild.klibc
@@ -85,7 +85,7 @@ KLIBCCPPFLAGS := -I$(KLIBCINC)/arch/$
# kernel include paths
KLIBCKERNELSRC ?= $(srctree)/
KLIBCCPPFLAGS += -I$(KLIBCKERNELSRC)include \
- $(if $(KBUILD_SRC),-I$(KLIBCKERNELOBJ)include2 -I$(KLIBCKERNELOBJ)include -I$(srctree)/include) \
+ $(if $(KBUILD_SRC),-I$(KLIBCKERNELOBJ)include2 -I$(KLIBCKERNELOBJ)include -I$(srctree)/include -I$(srctree)/usr/klibc/syscalls) \
$(KLIBCARCHINCFLAGS)
# klibc definitions
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 13:53 ` 2.6.17-mm1 Cedric Le Goater
@ 2006-06-21 14:13 ` Michal Piotrowski
2006-06-21 16:44 ` 2.6.17-mm1 H. Peter Anvin
1 sibling, 0 replies; 132+ messages in thread
From: Michal Piotrowski @ 2006-06-21 14:13 UTC (permalink / raw)
To: Cedric Le Goater; +Cc: Andrew Morton, hpa, linux-kernel
Hi Cedric,
On 21/06/06, Cedric Le Goater <clg@fr.ibm.com> wrote:
> Michal Piotrowski wrote:
>
> >> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> >> > or directory
> >>
> >> That one's probably just a parallel kbuild race. Type `make' again.
> >>
> >
> > "make O=/dir" is culprit.
> >
> > Regards,
> > Michal
> >
>
> That's how i fixed it.
Problem fixed, thanks.
> Is that the right way to do it ?
>
> Thanks,
>
> C.
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 13:53 ` 2.6.17-mm1 Cedric Le Goater
2006-06-21 14:13 ` 2.6.17-mm1 Michal Piotrowski
@ 2006-06-21 16:44 ` H. Peter Anvin
2006-06-21 19:26 ` 2.6.17-mm1 Cedric Le Goater
2006-06-21 21:46 ` 2.6.17-mm1 Michal Piotrowski
1 sibling, 2 replies; 132+ messages in thread
From: H. Peter Anvin @ 2006-06-21 16:44 UTC (permalink / raw)
To: Cedric Le Goater
Cc: Michal Piotrowski, Andrew Morton, linux-kernel, Sam Ravnborg
[-- Attachment #1: Type: text/plain, Size: 448 bytes --]
Cedric Le Goater wrote:
> Michal Piotrowski wrote:
>
>>>> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
>>>> or directory
>>> That one's probably just a parallel kbuild race. Type `make' again.
>>>
>> "make O=/dir" is culprit.
>>
>> Regards,
>> Michal
>>
>
> That's how i fixed it. Is that the right way to do it ?
>
Probably not. I suspect what's needed is the same EXTRA_KLIBCCFLAGS as
in socketcalls/Kbuild.
-hpa
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 424 bytes --]
diff --git a/usr/klibc/syscalls/Kbuild b/usr/klibc/syscalls/Kbuild
index debcd16..e7ae1d2 100644
--- a/usr/klibc/syscalls/Kbuild
+++ b/usr/klibc/syscalls/Kbuild
@@ -28,6 +28,8 @@ clean-files += $(KLIBCINC)/klibc/havesys
# All the syscall stubs
clean-files += *.o *.S *.c *.list *.bin
+EXTRA_KLIBCCFLAGS := -I$(srctree)/$(src)
+
quiet_cmd_makelist = LIST $@
cmd_makelist = echo '$(filter-out FORCE,$^)' > $@
^ permalink raw reply related [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-21 16:44 ` 2.6.17-mm1 H. Peter Anvin
@ 2006-06-21 19:26 ` Cedric Le Goater
2006-06-21 21:46 ` 2.6.17-mm1 Michal Piotrowski
1 sibling, 0 replies; 132+ messages in thread
From: Cedric Le Goater @ 2006-06-21 19:26 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Michal Piotrowski, Andrew Morton, linux-kernel, Sam Ravnborg
H. Peter Anvin wrote:
>> That's how i fixed it. Is that the right way to do it ?
>
> Probably not. I suspect what's needed is the same EXTRA_KLIBCCFLAGS as
> in socketcalls/Kbuild.
it works fine.
thanks !
C.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 16:44 ` 2.6.17-mm1 H. Peter Anvin
2006-06-21 19:26 ` 2.6.17-mm1 Cedric Le Goater
@ 2006-06-21 21:46 ` Michal Piotrowski
1 sibling, 0 replies; 132+ messages in thread
From: Michal Piotrowski @ 2006-06-21 21:46 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Cedric Le Goater, Andrew Morton, linux-kernel, Sam Ravnborg
Hi Peter,
On 21/06/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Cedric Le Goater wrote:
> > Michal Piotrowski wrote:
> >
> >>>> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> >>>> or directory
> >>> That one's probably just a parallel kbuild race. Type `make' again.
> >>>
> >> "make O=/dir" is culprit.
> >>
> >> Regards,
> >> Michal
> >>
> >
> > That's how i fixed it. Is that the right way to do it ?
> >
>
> Probably not. I suspect what's needed is the same EXTRA_KLIBCCFLAGS as
> in socketcalls/Kbuild.
Thanks for fixing that.
>
> -hpa
>
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
2006-06-21 11:07 ` 2.6.17-mm1 Michal Piotrowski
@ 2006-06-21 11:28 ` Andrew Morton
2006-06-21 15:35 ` 2.6.17-mm1 Christoph Lameter
2006-06-21 12:06 ` 2.6.17-mm1 Michal Piotrowski
` (28 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Andrew Morton @ 2006-06-21 11:28 UTC (permalink / raw)
To: linux-kernel
On Wed, 21 Jun 2006 03:48:57 -0700
Andrew Morton <akpm@osdl.org> wrote:
> - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> toolchain might be implicated).
Actually I did do a full ia64 allmodconfig build on a recent distro. So
it's "broken on RHAS 2.1".
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-21 11:28 ` 2.6.17-mm1 Andrew Morton
@ 2006-06-21 15:35 ` Christoph Lameter
0 siblings, 0 replies; 132+ messages in thread
From: Christoph Lameter @ 2006-06-21 15:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Wed, 21 Jun 2006, Andrew Morton wrote:
> On Wed, 21 Jun 2006 03:48:57 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> > toolchain might be implicated).
>
> Actually I did do a full ia64 allmodconfig build on a recent distro. So
> it's "broken on RHAS 2.1".
Builds fine on SLES9.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
2006-06-21 11:07 ` 2.6.17-mm1 Michal Piotrowski
2006-06-21 11:28 ` 2.6.17-mm1 Andrew Morton
@ 2006-06-21 12:06 ` Michal Piotrowski
2006-06-21 15:10 ` [-mm patch] drivers/net/ni5010.c: fix compile error Adrian Bunk
` (27 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Michal Piotrowski @ 2006-06-21 12:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: Len Brown, linux-kernel, linux-acpi
Hi,
On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>
It looks like an ACPI problem.
Setting up standard PCI resources
=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
idle/1 is trying to acquire lock:
(lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
but task is already holding lock:
(lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
other info that might help us debug this:
1 lock held by idle/1:
#0: (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
stack backtrace:
[<c0103e89>] show_trace+0xd/0x10
[<c0104483>] dump_stack+0x19/0x1b
[<c01395fa>] __lock_acquire+0x7d9/0xa50
[<c0139a98>] lock_acquire+0x71/0x91
[<c02f0beb>] _spin_lock_irqsave+0x2c/0x3c
[<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
[<c0222d95>] acpi_ev_gpe_detect+0x4d/0x10e
[<c02215c3>] acpi_ev_sci_xrupt_handler+0x15/0x1d
[<c021c8b1>] acpi_irq+0xe/0x18
[<c014d36e>] request_irq+0xbe/0x10c
[<c021cf33>] acpi_os_install_interrupt_handler+0x59/0x87
[<c02215e7>] acpi_ev_install_sci_handler+0x1c/0x21
[<c0220d41>] acpi_ev_install_xrupt_handlers+0x9/0x50
[<c0231772>] acpi_enable_subsystem+0x7d/0x9a
[<c0416656>] acpi_init+0x3f/0x170
[<c01003ae>] _stext+0x116/0x26c
[<c0101005>] kernel_thread_helper+0x5/0xb
ACPI: Interpreter enabled
Here is a dmesg log http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-dmesg
Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] drivers/net/ni5010.c: fix compile error
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-06-21 12:06 ` 2.6.17-mm1 Michal Piotrowski
@ 2006-06-21 15:10 ` Adrian Bunk
2006-06-22 8:13 ` Andreas Mohr
2006-06-21 18:22 ` [PATCH] pi-futex-rt-mutex-core-merge.patch (was Re: 2.6.17-mm1 Valdis.Kletnieks
` (26 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 15:10 UTC (permalink / raw)
To: Andrew Morton, Andreas Mohr; +Cc: linux-kernel, jgarzik, netdev
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +ni5010-netcard-cleanup.patch
>
> netdev cleanup
>...
This patch fixes the following compile error with CONFIG_NI5010=y:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o:(.init.data+0x2b280): undefined reference to `ni5010_probe'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm1-full/drivers/net/ni5010.c.old 2006-06-21 16:21:26.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/net/ni5010.c 2006-06-21 16:21:46.000000000 +0200
@@ -117,7 +117,7 @@
static int io;
static int irq;
-static struct net_device * __init ni5010_probe(int unit)
+struct net_device * __init ni5010_probe(int unit)
{
struct net_device *dev = alloc_etherdev(sizeof(struct ni5010_local));
int *port;
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [-mm patch] drivers/net/ni5010.c: fix compile error
2006-06-21 15:10 ` [-mm patch] drivers/net/ni5010.c: fix compile error Adrian Bunk
@ 2006-06-22 8:13 ` Andreas Mohr
2006-06-22 8:45 ` Adrian Bunk
0 siblings, 1 reply; 132+ messages in thread
From: Andreas Mohr @ 2006-06-22 8:13 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, jgarzik, netdev
Hi,
On Wed, Jun 21, 2006 at 05:10:57PM +0200, Adrian Bunk wrote:
> On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc6-mm2:
> >...
> > +ni5010-netcard-cleanup.patch
> >
> > netdev cleanup
> >...
>
> This patch fixes the following compile error with CONFIG_NI5010=y:
Doh, thanks!
(that should teach me to do non-module runs, too)
Andreas Mohr
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [-mm patch] drivers/net/ni5010.c: fix compile error
2006-06-22 8:13 ` Andreas Mohr
@ 2006-06-22 8:45 ` Adrian Bunk
0 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-22 8:45 UTC (permalink / raw)
To: Andreas Mohr; +Cc: Andrew Morton, linux-kernel, jgarzik, netdev
On Thu, Jun 22, 2006 at 10:13:16AM +0200, Andreas Mohr wrote:
> Hi,
>
> On Wed, Jun 21, 2006 at 05:10:57PM +0200, Adrian Bunk wrote:
> > On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.17-rc6-mm2:
> > >...
> > > +ni5010-netcard-cleanup.patch
> > >
> > > netdev cleanup
> > >...
> >
> > This patch fixes the following compile error with CONFIG_NI5010=y:
>
> Doh, thanks!
> (that should teach me to do non-module runs, too)
And change the driver to no longer use Space.c? ;-)
> Andreas Mohr
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 132+ messages in thread
* [PATCH] pi-futex-rt-mutex-core-merge.patch (was Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (3 preceding siblings ...)
2006-06-21 15:10 ` [-mm patch] drivers/net/ni5010.c: fix compile error Adrian Bunk
@ 2006-06-21 18:22 ` Valdis.Kletnieks
2006-06-21 21:48 ` swsusp regression [Was: 2.6.17-mm1] Jiri Slaby
` (25 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Valdis.Kletnieks @ 2006-06-21 18:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Wed, 21 Jun 2006 03:48:57 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
pi-futex-rt-mutex-core.patch has what looks like a merge error in it.
Patch to clean it up attached.
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
--- linux-2.6.17-mm1/include/linux/sysctl.h.fix1 2006-06-21 13:24:32.000000000 -0400
+++ linux-2.6.17-mm1/include/linux/sysctl.h 2006-06-21 14:16:46.000000000 -0400
@@ -153,7 +153,7 @@ enum
KERN_NMI_WATCHDOG=74, /* int: enable/disable nmi watchdog */
KERN_PANIC_ON_NMI=75, /* int: whether we will panic on an unrecovered */
KERN_STOP_ON_CPU_LOST=76, /* int: SIGSTOP when a task losts its cpus */
- KERN_MAX_LOCK_DEPTH=76,
+ KERN_MAX_LOCK_DEPTH=77,
};
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 132+ messages in thread* swsusp regression [Was: 2.6.17-mm1]
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (4 preceding siblings ...)
2006-06-21 18:22 ` [PATCH] pi-futex-rt-mutex-core-merge.patch (was Re: 2.6.17-mm1 Valdis.Kletnieks
@ 2006-06-21 21:48 ` Jiri Slaby
2006-06-21 22:14 ` Mattia Dongili
2006-06-21 21:57 ` [-mm patch] drivers/acpi/scan.c: make acpi_bus_type static Adrian Bunk
` (24 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Jiri Slaby @ 2006-06-21 21:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, pavel, linux-pm, pingc
Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
[32512.214000] Suspending device usbdev3.2_ep81
[32512.214040] Suspending device 3-2:1.0
[32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
[32512.214128] Suspending device usbdev3.2_ep00
[32512.214169] Suspending device 3-2
[32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
[32512.214319] Could not suspend device 3-2: error -16
[32512.214361] wacom 3-2:1.0: no resume for driver wacom?
[32512.242552] Some devices failed to suspend
Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2
Wacom messages are not new, but it now causes not suspending.
2.6.17-rc6-mm2 was OK.
Is there any more info needed?
--
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ jirislaby@gmail.com _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: swsusp regression [Was: 2.6.17-mm1]
2006-06-21 21:48 ` swsusp regression [Was: 2.6.17-mm1] Jiri Slaby
@ 2006-06-21 22:14 ` Mattia Dongili
2006-06-21 22:18 ` Mattia Dongili
2006-06-22 6:19 ` [linux-pm] " Greg KH
0 siblings, 2 replies; 132+ messages in thread
From: Mattia Dongili @ 2006-06-21 22:14 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, pavel, linux-pm
On Wed, Jun 21, 2006 at 11:47:46PM +0159, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>
> [32512.214000] Suspending device usbdev3.2_ep81
> [32512.214040] Suspending device 3-2:1.0
> [32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
> [32512.214128] Suspending device usbdev3.2_ep00
> [32512.214169] Suspending device 3-2
> [32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
> [32512.214319] Could not suspend device 3-2: error -16
> [32512.214361] wacom 3-2:1.0: no resume for driver wacom?
> [32512.242552] Some devices failed to suspend
>
> Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2
>
> Wacom messages are not new, but it now causes not suspending.
me too (again!)
[ 95.408000] Suspending device 3-1
[ 95.408000] suspend_device(): usb_generic_suspend+0x0/0x144 [usbcore]() returns -16
[ 95.408000] Could not suspend device 3-1: error -16
[ 95.412000] Some devices failed to suspend
[ 95.412000] Restarting tasks... done
rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
and resume (s2ram).
usbcore tells it is in use (count=1) and can't remove it.
The device is a memory stick reader.
I have the same problems also with suspend to disk. BTW I can't resume
from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
tomorrow, as it seems removing the usb stuff makes it do some more steps
toward resumimg (eg: with usb modules this laptop immediately reboots
after reading all pages, without them I can reach "resuming device.."
stage).
--
mattia
:wq!
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: swsusp regression [Was: 2.6.17-mm1]
2006-06-21 22:14 ` Mattia Dongili
@ 2006-06-21 22:18 ` Mattia Dongili
2006-06-22 6:19 ` [linux-pm] " Greg KH
1 sibling, 0 replies; 132+ messages in thread
From: Mattia Dongili @ 2006-06-21 22:18 UTC (permalink / raw)
To: linux-kernel, Andrew Morton, pavel, linux-pm
On Thu, Jun 22, 2006 at 12:14:45AM +0200, Mattia Dongili wrote:
[...]
> rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
> and resume (s2ram).
doh, sorry. I meant "suspend to ram".
--
mattia
:wq!
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-21 22:14 ` Mattia Dongili
2006-06-21 22:18 ` Mattia Dongili
@ 2006-06-22 6:19 ` Greg KH
2006-06-22 7:46 ` Andrew Morton
1 sibling, 1 reply; 132+ messages in thread
From: Greg KH @ 2006-06-22 6:19 UTC (permalink / raw)
To: linux-kernel, Andrew Morton, pavel, linux-pm, Alan Stern
On Thu, Jun 22, 2006 at 12:14:45AM +0200, Mattia Dongili wrote:
> On Wed, Jun 21, 2006 at 11:47:46PM +0159, Jiri Slaby wrote:
> > Andrew Morton napsal(a):
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> >
> > [32512.214000] Suspending device usbdev3.2_ep81
> > [32512.214040] Suspending device 3-2:1.0
> > [32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
> > [32512.214128] Suspending device usbdev3.2_ep00
> > [32512.214169] Suspending device 3-2
> > [32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
> > [32512.214319] Could not suspend device 3-2: error -16
> > [32512.214361] wacom 3-2:1.0: no resume for driver wacom?
> > [32512.242552] Some devices failed to suspend
> >
> > Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2
> >
> > Wacom messages are not new, but it now causes not suspending.
>
> me too (again!)
>
> [ 95.408000] Suspending device 3-1
> [ 95.408000] suspend_device(): usb_generic_suspend+0x0/0x144 [usbcore]() returns -16
> [ 95.408000] Could not suspend device 3-1: error -16
> [ 95.412000] Some devices failed to suspend
> [ 95.412000] Restarting tasks... done
>
> rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
> and resume (s2ram).
> usbcore tells it is in use (count=1) and can't remove it.
> The device is a memory stick reader.
>
> I have the same problems also with suspend to disk. BTW I can't resume
> from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> tomorrow, as it seems removing the usb stuff makes it do some more steps
> toward resumimg (eg: with usb modules this laptop immediately reboots
> after reading all pages, without them I can reach "resuming device.."
> stage).
Removing uhci-hcd causes all USB devices to be removed from the system.
Alan, you've been working in the "generic usb" section lately, any ideas
why we can't suspend that kind of device now?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 6:19 ` [linux-pm] " Greg KH
@ 2006-06-22 7:46 ` Andrew Morton
2006-06-22 8:25 ` Jeremy Fitzhardinge
` (2 more replies)
0 siblings, 3 replies; 132+ messages in thread
From: Andrew Morton @ 2006-06-22 7:46 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, pavel, linux-pm, stern
On Wed, 21 Jun 2006 23:19:05 -0700
Greg KH <greg@kroah.com> wrote:
> > I have the same problems also with suspend to disk. BTW I can't resume
> > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > toward resumimg (eg: with usb modules this laptop immediately reboots
> > after reading all pages, without them I can reach "resuming device.."
> > stage).
>
> Removing uhci-hcd causes all USB devices to be removed from the system.
>
> Alan, you've been working in the "generic usb" section lately, any ideas
> why we can't suspend that kind of device now?
My laptop has the same problem.
This:
--- a/drivers/usb/core/usb.c~usb-more-suspend-debugging
+++ a/drivers/usb/core/usb.c
@@ -991,7 +991,11 @@ void usb_buffer_unmap_sg (struct usb_dev
static int verify_suspended(struct device *dev, void *unused)
{
- return (dev->power.power_state.event == PM_EVENT_ON) ? -EBUSY : 0;
+ if (dev->power.power_state.event == PM_EVENT_ON) {
+ dev_printk(KERN_ERR, dev, "not suspended\n");
+ return -EBUSY;
+ }
+ return 0;
}
static int usb_generic_suspend(struct device *dev, pm_message_t message)
@@ -1005,13 +1009,18 @@ static int usb_generic_suspend(struct de
* But those semantics are useless, so we equate the two (sigh).
*/
if (dev->driver == &usb_generic_driver) {
+ int ret;
+
if (dev->power.power_state.event == message.event)
return 0;
/* we need to rule out bogus requests through sysfs */
status = device_for_each_child(dev, NULL, verify_suspended);
+ suspend_report_result(verify_suspended, status);
if (status)
return status;
- return usb_suspend_device (to_usb_device(dev));
+ ret = usb_suspend_device(to_usb_device(dev));
+ suspend_report_result(usb_suspend_device, ret);
+ return ret;
}
if ((dev->driver == NULL) ||
@@ -1027,6 +1036,7 @@ static int usb_generic_suspend(struct de
if (driver->suspend && driver->resume) {
status = driver->suspend(intf, message);
+ suspend_report_result(driver->suspend, status);
if (status)
dev_err(dev, "%s error %d\n", "suspend", status);
else
diff -puN drivers/usb/core/hub.c~usb-more-suspend-debugging drivers/usb/core/hub.c
--- a/drivers/usb/core/hub.c~usb-more-suspend-debugging
+++ a/drivers/usb/core/hub.c
@@ -1638,6 +1638,7 @@ static int hub_port_suspend(struct usb_h
USB_DEVICE_REMOTE_WAKEUP, 0,
NULL, 0,
USB_CTRL_SET_TIMEOUT);
+ suspend_report_result(usb_control_msg, status);
if (status)
dev_dbg(&udev->dev,
"won't remote wakeup, status %d\n",
@@ -1646,6 +1647,7 @@ static int hub_port_suspend(struct usb_h
/* see 7.1.7.6 */
status = set_port_feature(hub->hdev, port1, USB_PORT_FEAT_SUSPEND);
+ suspend_report_result(set_port_feature, status);
if (status) {
dev_dbg(hub->intfdev,
"can't suspend port %d, status %d\n",
@@ -1706,6 +1708,8 @@ static int __usb_suspend_device (struct
intf = udev->actconfig->interface[i];
if (is_active(intf)) {
dev_dbg(&intf->dev, "nyet suspended\n");
+ suspend_report_result(__usb_suspend_device,
+ -EBUSY);
return -EBUSY;
}
}
@@ -1714,9 +1718,11 @@ static int __usb_suspend_device (struct
/* we only change a device's upstream USB link.
* root hubs have no upstream USB link.
*/
- if (udev->parent)
+ if (udev->parent) {
status = hub_port_suspend(hdev_to_hub(udev->parent), port1,
udev);
+ suspend_report_result(hub_port_suspend, status);
+ }
if (status == 0)
udev->dev.power.power_state = PMSG_SUSPEND;
_
Says:
Shrinking memory... done (0 pages freed)
hci_usb 3-1:1.1: no suspend for driver hci_usb?
hci_usb 3-1:1.0: no suspend for driver hci_usb?
usbdev3.2_ep00: not suspended
usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
Could not suspend device 3-1: error -16
hci_usb 3-1:1.0: no resume for driver hci_usb?
hci_usb 3-1:1.1: no resume for driver hci_usb?
Some devices failed to suspend
Restarting tasks... done
What's a usbdev3.2_ep00?
sony:/home/akpm> lsusb
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 044e:300c Alps Electric Co., Ltd
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 003: ID 045e:00e1 Microsoft Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
sony:/home/akpm> l /sys/bus/usb/devices
total 0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-1 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.2 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.2
Seems to be this:
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI])
Subsystem: Sony Corporation Unknown device 81b9
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 16
Region 4: I/O ports at 1860 [size=32]
00: 86 80 5a 26 05 00 80 02 03 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 18 00 00 00 00 00 00 00 00 00 00 4d 10 b9 81
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 03 00 00
I don't see anything in this patchpile which would break the bluetooth driver,
and drivers/usb/core/usb.c is effectively unchanged.
I can bisect it if we're stuck, but that'll require beer or something.
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 7:46 ` Andrew Morton
@ 2006-06-22 8:25 ` Jeremy Fitzhardinge
2006-06-22 15:51 ` Alan Stern
2006-06-22 16:04 ` Frederik Deweerdt
2 siblings, 0 replies; 132+ messages in thread
From: Jeremy Fitzhardinge @ 2006-06-22 8:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg KH, linux-kernel, pavel, linux-pm, stern
Andrew Morton wrote:
> My laptop has the same problem.
>
Mine too. I wonder if its related to the (apparently) bluetooth-caused
oops I reported earlier today?
Though I'm seeing the suspend problem on a system with no bluetooth
module loaded; the only USB device on the bus is the fingerprint-reader.
My suspend script removes the uhci_hcd module on suspend. The device
complaining EBUSY is the ehci hub, which has nothing hanging off it.
J
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 7:46 ` Andrew Morton
2006-06-22 8:25 ` Jeremy Fitzhardinge
@ 2006-06-22 15:51 ` Alan Stern
2006-06-22 17:17 ` Jeremy Fitzhardinge
2006-06-22 18:46 ` Greg KH
2006-06-22 16:04 ` Frederik Deweerdt
2 siblings, 2 replies; 132+ messages in thread
From: Alan Stern @ 2006-06-22 15:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg KH, linux-kernel, pavel, linux-pm
On Thu, 22 Jun 2006, Andrew Morton wrote:
> On Wed, 21 Jun 2006 23:19:05 -0700
> Greg KH <greg@kroah.com> wrote:
>
> > > I have the same problems also with suspend to disk. BTW I can't resume
> > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > after reading all pages, without them I can reach "resuming device.."
> > > stage).
> >
> > Removing uhci-hcd causes all USB devices to be removed from the system.
> >
> > Alan, you've been working in the "generic usb" section lately, any ideas
> > why we can't suspend that kind of device now?
See below...
> My laptop has the same problem.
> Shrinking memory... done (0 pages freed)
> hci_usb 3-1:1.1: no suspend for driver hci_usb?
> hci_usb 3-1:1.0: no suspend for driver hci_usb?
> usbdev3.2_ep00: not suspended
> usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> Could not suspend device 3-1: error -16
> hci_usb 3-1:1.0: no resume for driver hci_usb?
> hci_usb 3-1:1.1: no resume for driver hci_usb?
> Some devices failed to suspend
> Restarting tasks... done
>
>
> What's a usbdev3.2_ep00?
Evidently the regression was caused by Greg's patch making endpoints into
real struct devices. usbdev3.2_ep00 is the device corresponding to
endpoint 0 on device 2 of USB bus 3.
Is it really true that this patch has been sitting in -mm for several
months (as stated in the cover message to Linus for the new batch of
changes for 2.6.17 sent in yesterday)?
There are several possible ways to fix this. One is to add suspend and
resume routines to the endpoint-device driver. Another is to change the
code that checks for the children being suspended, to make it check only
for child USB devices and not child endpoints.
Alan Stern
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 15:51 ` Alan Stern
@ 2006-06-22 17:17 ` Jeremy Fitzhardinge
2006-06-22 18:46 ` Greg KH
1 sibling, 0 replies; 132+ messages in thread
From: Jeremy Fitzhardinge @ 2006-06-22 17:17 UTC (permalink / raw)
To: Alan Stern; +Cc: Andrew Morton, Greg KH, linux-kernel, pavel, linux-pm
Alan Stern wrote:
> Is it really true that this patch has been sitting in -mm for several
> months (as stated in the cover message to Linus for the new batch of
> changes for 2.6.17 sent in yesterday)?
>
2.6.17-pre6-mm2 works perfectly for me. 17-mm1 has this problem.
J
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 15:51 ` Alan Stern
2006-06-22 17:17 ` Jeremy Fitzhardinge
@ 2006-06-22 18:46 ` Greg KH
2006-06-22 19:07 ` Greg KH
2006-06-22 19:57 ` Alan Stern
1 sibling, 2 replies; 132+ messages in thread
From: Greg KH @ 2006-06-22 18:46 UTC (permalink / raw)
To: Alan Stern; +Cc: Andrew Morton, linux-kernel, pavel, linux-pm
On Thu, Jun 22, 2006 at 11:51:18AM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Andrew Morton wrote:
>
> > On Wed, 21 Jun 2006 23:19:05 -0700
> > Greg KH <greg@kroah.com> wrote:
> >
> > > > I have the same problems also with suspend to disk. BTW I can't resume
> > > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > > after reading all pages, without them I can reach "resuming device.."
> > > > stage).
> > >
> > > Removing uhci-hcd causes all USB devices to be removed from the system.
> > >
> > > Alan, you've been working in the "generic usb" section lately, any ideas
> > > why we can't suspend that kind of device now?
>
> See below...
>
> > My laptop has the same problem.
>
> > Shrinking memory... done (0 pages freed)
> > hci_usb 3-1:1.1: no suspend for driver hci_usb?
> > hci_usb 3-1:1.0: no suspend for driver hci_usb?
> > usbdev3.2_ep00: not suspended
> > usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> > suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> > Could not suspend device 3-1: error -16
> > hci_usb 3-1:1.0: no resume for driver hci_usb?
> > hci_usb 3-1:1.1: no resume for driver hci_usb?
> > Some devices failed to suspend
> > Restarting tasks... done
> >
> >
> > What's a usbdev3.2_ep00?
>
> Evidently the regression was caused by Greg's patch making endpoints into
> real struct devices. usbdev3.2_ep00 is the device corresponding to
> endpoint 0 on device 2 of USB bus 3.
>
> Is it really true that this patch has been sitting in -mm for several
> months (as stated in the cover message to Linus for the new batch of
> changes for 2.6.17 sent in yesterday)?
Ugh, no, you are right, the endpoint change was not in for that long,
sorry. I thought it did make at least one -mm though.
> There are several possible ways to fix this. One is to add suspend and
> resume routines to the endpoint-device driver. Another is to change the
> code that checks for the children being suspended, to make it check only
> for child USB devices and not child endpoints.
I think it needs to check for _USB_ devices, not just any old device
that could possibly be attached to the main USB device (as this one is.)
What's to stop any other struct device to bind here and cause the same
problem?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 18:46 ` Greg KH
@ 2006-06-22 19:07 ` Greg KH
2006-06-22 19:57 ` Alan Stern
1 sibling, 0 replies; 132+ messages in thread
From: Greg KH @ 2006-06-22 19:07 UTC (permalink / raw)
To: Alan Stern; +Cc: Andrew Morton, linux-kernel, pavel, linux-pm
On Thu, Jun 22, 2006 at 11:46:49AM -0700, Greg KH wrote:
> On Thu, Jun 22, 2006 at 11:51:18AM -0400, Alan Stern wrote:
> > On Thu, 22 Jun 2006, Andrew Morton wrote:
> >
> > > On Wed, 21 Jun 2006 23:19:05 -0700
> > > Greg KH <greg@kroah.com> wrote:
> > >
> > > > > I have the same problems also with suspend to disk. BTW I can't resume
> > > > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > > > after reading all pages, without them I can reach "resuming device.."
> > > > > stage).
> > > >
> > > > Removing uhci-hcd causes all USB devices to be removed from the system.
> > > >
> > > > Alan, you've been working in the "generic usb" section lately, any ideas
> > > > why we can't suspend that kind of device now?
> >
> > See below...
> >
> > > My laptop has the same problem.
> >
> > > Shrinking memory... done (0 pages freed)
> > > hci_usb 3-1:1.1: no suspend for driver hci_usb?
> > > hci_usb 3-1:1.0: no suspend for driver hci_usb?
> > > usbdev3.2_ep00: not suspended
> > > usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> > > suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> > > Could not suspend device 3-1: error -16
> > > hci_usb 3-1:1.0: no resume for driver hci_usb?
> > > hci_usb 3-1:1.1: no resume for driver hci_usb?
> > > Some devices failed to suspend
> > > Restarting tasks... done
> > >
> > >
> > > What's a usbdev3.2_ep00?
> >
> > Evidently the regression was caused by Greg's patch making endpoints into
> > real struct devices. usbdev3.2_ep00 is the device corresponding to
> > endpoint 0 on device 2 of USB bus 3.
> >
> > Is it really true that this patch has been sitting in -mm for several
> > months (as stated in the cover message to Linus for the new batch of
> > changes for 2.6.17 sent in yesterday)?
>
> Ugh, no, you are right, the endpoint change was not in for that long,
> sorry. I thought it did make at least one -mm though.
>
> > There are several possible ways to fix this. One is to add suspend and
> > resume routines to the endpoint-device driver. Another is to change the
> > code that checks for the children being suspended, to make it check only
> > for child USB devices and not child endpoints.
>
> I think it needs to check for _USB_ devices, not just any old device
> that could possibly be attached to the main USB device (as this one is.)
> What's to stop any other struct device to bind here and cause the same
> problem?
Ok, the problem is in verify_suspended(), we are not detecting what type
of device this is.
Alan, what are you trying to check for here? What "bogus requests" were
you seeing from sysfs that you are trying to filter out?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 18:46 ` Greg KH
2006-06-22 19:07 ` Greg KH
@ 2006-06-22 19:57 ` Alan Stern
2006-06-22 20:22 ` Greg KH
2006-06-22 20:38 ` Jiri Slaby
1 sibling, 2 replies; 132+ messages in thread
From: Alan Stern @ 2006-06-22 19:57 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, linux-kernel, pavel, linux-pm
On Thu, 22 Jun 2006, Greg KH wrote:
> > There are several possible ways to fix this. One is to add suspend and
> > resume routines to the endpoint-device driver. Another is to change the
> > code that checks for the children being suspended, to make it check only
> > for child USB devices and not child endpoints.
>
> I think it needs to check for _USB_ devices, not just any old device
> that could possibly be attached to the main USB device (as this one is.)
> What's to stop any other struct device to bind here and cause the same
> problem?
In my upcoming patches for USB core suspend improvements, one of the
changes affects this very piece of code. Instead of looping over all
child devices in the driver-model sense, it loops over all interfaces in
the active configuration, which is all we care about right here.
> Ok, the problem is in verify_suspended(), we are not detecting what type
> of device this is.
>
> Alan, what are you trying to check for here? What "bogus requests" were
> you seeing from sysfs that you are trying to filter out?
I didn't write that routine, Dave Brownell did. It has been there for
ages. The "bogus requests" are attempts by the user to suspend a USB
device (by writing to /sys/devices/.../power/state) without first
suspending all its children and interfaces.
(This can't happen when doing a global suspend because the PM core
iterates through the entire device tree. It matters only for "runtime" or
"selective" suspend.)
The two easiest ways to fix the problem are:
Change the code to look through the interfaces in the active
configuration instead of using device_for_each_child;
or
Revert your "endpoints are devices" patch until my upcoming
changes are in place.
Alan Stern
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 19:57 ` Alan Stern
@ 2006-06-22 20:22 ` Greg KH
2006-06-22 20:38 ` Jiri Slaby
1 sibling, 0 replies; 132+ messages in thread
From: Greg KH @ 2006-06-22 20:22 UTC (permalink / raw)
To: Alan Stern; +Cc: Andrew Morton, linux-kernel, pavel, linux-pm
On Thu, Jun 22, 2006 at 03:57:24PM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Greg KH wrote:
>
> > > There are several possible ways to fix this. One is to add suspend and
> > > resume routines to the endpoint-device driver. Another is to change the
> > > code that checks for the children being suspended, to make it check only
> > > for child USB devices and not child endpoints.
> >
> > I think it needs to check for _USB_ devices, not just any old device
> > that could possibly be attached to the main USB device (as this one is.)
> > What's to stop any other struct device to bind here and cause the same
> > problem?
>
> In my upcoming patches for USB core suspend improvements, one of the
> changes affects this very piece of code. Instead of looping over all
> child devices in the driver-model sense, it loops over all interfaces in
> the active configuration, which is all we care about right here.
>
> > Ok, the problem is in verify_suspended(), we are not detecting what type
> > of device this is.
> >
> > Alan, what are you trying to check for here? What "bogus requests" were
> > you seeing from sysfs that you are trying to filter out?
>
> I didn't write that routine, Dave Brownell did. It has been there for
> ages.
Sorry for the misattribution, I should have checked closer.
> The "bogus requests" are attempts by the user to suspend a USB
> device (by writing to /sys/devices/.../power/state) without first
> suspending all its children and interfaces.
>
> (This can't happen when doing a global suspend because the PM core
> iterates through the entire device tree. It matters only for "runtime" or
> "selective" suspend.)
Then why is people hitting this now? I guess no one had hooked a struct
device to a struct usb_device before, only interfaces.
> The two easiest ways to fix the problem are:
>
> Change the code to look through the interfaces in the active
> configuration instead of using device_for_each_child;
Or at least verify that they are looking at an interface, just blindly
poking at a child device isn't very nice :(
> or
>
> Revert your "endpoints are devices" patch until my upcoming
> changes are in place.
I'll work on a fix-up patch based on the first option :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 19:57 ` Alan Stern
2006-06-22 20:22 ` Greg KH
@ 2006-06-22 20:38 ` Jiri Slaby
2006-06-22 21:09 ` Alan Stern
1 sibling, 1 reply; 132+ messages in thread
From: Jiri Slaby @ 2006-06-22 20:38 UTC (permalink / raw)
To: Alan Stern; +Cc: Greg KH, Andrew Morton, linux-kernel, pavel, linux-pm
Alan Stern napsal(a):
>> Ok, the problem is in verify_suspended(), we are not detecting what type
>> of device this is.
>>
>> Alan, what are you trying to check for here? What "bogus requests" were
>> you seeing from sysfs that you are trying to filter out?
>
> I didn't write that routine, Dave Brownell did. It has been there for
> ages. The "bogus requests" are attempts by the user to suspend a USB
> device (by writing to /sys/devices/.../power/state) without first
> suspending all its children and interfaces.
>
> (This can't happen when doing a global suspend because the PM core
> iterates through the entire device tree. It matters only for "runtime" or
> "selective" suspend.)
But everything I did is:
echo reboot > /sys/power/disk
echo disk > /sys/power/state
No writing anywhere else.
regards,
--
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ jirislaby@gmail.com _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 20:38 ` Jiri Slaby
@ 2006-06-22 21:09 ` Alan Stern
2006-06-22 21:11 ` Greg KH
0 siblings, 1 reply; 132+ messages in thread
From: Alan Stern @ 2006-06-22 21:09 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg KH, Andrew Morton, linux-kernel, pavel, linux-pm
On Thu, 22 Jun 2006, Jiri Slaby wrote:
> > ages. The "bogus requests" are attempts by the user to suspend a USB
> > device (by writing to /sys/devices/.../power/state) without first
> > suspending all its children and interfaces.
> >
> > (This can't happen when doing a global suspend because the PM core
> > iterates through the entire device tree. It matters only for "runtime" or
> > "selective" suspend.)
>
> But everything I did is:
> echo reboot > /sys/power/disk
> echo disk > /sys/power/state
>
> No writing anywhere else.
You misunderstood. I meant that attempts to suspend a USB device without
first suspending all its children and interfaces can't happen when doing a
global suspend. That's still true.
Your problem occurred because even though the PM core did _attempt_ to
suspend the new children added by Greg's patch, it didn't _succeed_
because the patch did not provide suspend or resume methods.
Alan Stern
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 21:09 ` Alan Stern
@ 2006-06-22 21:11 ` Greg KH
0 siblings, 0 replies; 132+ messages in thread
From: Greg KH @ 2006-06-22 21:11 UTC (permalink / raw)
To: Alan Stern; +Cc: Jiri Slaby, Andrew Morton, linux-kernel, pavel, linux-pm
On Thu, Jun 22, 2006 at 05:09:43PM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Jiri Slaby wrote:
>
> > > ages. The "bogus requests" are attempts by the user to suspend a USB
> > > device (by writing to /sys/devices/.../power/state) without first
> > > suspending all its children and interfaces.
> > >
> > > (This can't happen when doing a global suspend because the PM core
> > > iterates through the entire device tree. It matters only for "runtime" or
> > > "selective" suspend.)
> >
> > But everything I did is:
> > echo reboot > /sys/power/disk
> > echo disk > /sys/power/state
> >
> > No writing anywhere else.
>
> You misunderstood. I meant that attempts to suspend a USB device without
> first suspending all its children and interfaces can't happen when doing a
> global suspend. That's still true.
>
> Your problem occurred because even though the PM core did _attempt_ to
> suspend the new children added by Greg's patch, it didn't _succeed_
> because the patch did not provide suspend or resume methods.
Which because they are virtual "devices" they do not need a suspend or
resume method, so not having any is just fine. If we abort because of
something like this, the core logic is quite broken...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 7:46 ` Andrew Morton
2006-06-22 8:25 ` Jeremy Fitzhardinge
2006-06-22 15:51 ` Alan Stern
@ 2006-06-22 16:04 ` Frederik Deweerdt
2006-06-22 16:25 ` Andrew Morton
2 siblings, 1 reply; 132+ messages in thread
From: Frederik Deweerdt @ 2006-06-22 16:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg KH, linux-kernel, pavel, linux-pm, stern
Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> I can bisect it if we're stuck, but that'll require beer or something.
FWIW, my laptop (Dell D610) gave the following results:
2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
2.6.17: oops
2.6.17.1: oops
2.6.17-rc6-mm2: suspends correctly
Regards,
Frederik
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 16:04 ` Frederik Deweerdt
@ 2006-06-22 16:25 ` Andrew Morton
2006-06-22 19:07 ` Frederik Deweerdt
2006-06-23 9:02 ` Frederik Deweerdt
0 siblings, 2 replies; 132+ messages in thread
From: Andrew Morton @ 2006-06-22 16:25 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: greg, linux-kernel, pavel, linux-pm, stern
On Thu, 22 Jun 2006 18:04:03 +0200
Frederik Deweerdt <deweerdt@free.fr> wrote:
> Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > I can bisect it if we're stuck, but that'll require beer or something.
>
> FWIW, my laptop (Dell D610) gave the following results:
> 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
So it's in mainline already - hence it's some recently-written thing which
was not tested in rc6-mm2.
> 2.6.17: oops
> 2.6.17.1: oops
2.6.17 wasn't supposed to oops. Do you have details on this?
> 2.6.17-rc6-mm2: suspends correctly
Good kernel, that.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 16:25 ` Andrew Morton
@ 2006-06-22 19:07 ` Frederik Deweerdt
2006-06-23 9:02 ` Frederik Deweerdt
1 sibling, 0 replies; 132+ messages in thread
From: Frederik Deweerdt @ 2006-06-22 19:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: greg, linux-kernel, pavel, linux-pm, stern
On Thu, Jun 22, 2006 at 09:25:06AM -0700, Andrew Morton wrote:
> On Thu, 22 Jun 2006 18:04:03 +0200
> Frederik Deweerdt <deweerdt@free.fr> wrote:
> > 2.6.17: oops
> > 2.6.17.1: oops
>
> 2.6.17 wasn't supposed to oops. Do you have details on this?
>
No, sorry I didn't have a serial cable handy. I'll post the
.config and the oops tomorrow.
Regards,
Frederik
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-22 16:25 ` Andrew Morton
2006-06-22 19:07 ` Frederik Deweerdt
@ 2006-06-23 9:02 ` Frederik Deweerdt
2006-06-23 9:10 ` Pavel Machek
1 sibling, 1 reply; 132+ messages in thread
From: Frederik Deweerdt @ 2006-06-23 9:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: greg, linux-kernel, pavel, linux-pm, stern
On Thu, Jun 22, 2006 at 09:25:06AM -0700, Andrew Morton wrote:
> On Thu, 22 Jun 2006 18:04:03 +0200
> Frederik Deweerdt <deweerdt@free.fr> wrote:
>
> > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > I can bisect it if we're stuck, but that'll require beer or something.
> >
> > FWIW, my laptop (Dell D610) gave the following results:
> > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
>
> So it's in mainline already - hence it's some recently-written thing which
> was not tested in rc6-mm2.
>
> > 2.6.17: oops
> > 2.6.17.1: oops
>
> 2.6.17 wasn't supposed to oops. Do you have details on this?
>
For some reason, unknown to me, the oops won't display on the serial link :(.
Here's what I could hand copy (I've suppressed printk timing information):
x1b9/0x1be
<c0166e6b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
<3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
in_atomic():0, irqs_disabled():1
<c0103e56> show_trace+0x20/0x22 <c0103f5b> dump_stack+0x1e/0x20
<c011aec7> __might_sleep+0x9e/0xa6 <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
<c011f091> profile_task_exit+0x21/0x23 <c0120946> do_exit+0x1d/0x483
<c0104432> do_divide_error+0x0/0xbf <c0362c76> do_page_fault+0x3c4/0x752
<c0103b2f> error_code+0x4f/0x54 <c013b33a> suspend_enter+0x2f/0x52
<c013b3e0> enter_state+0x4b/0x8d <c013b579> state_store+0xa0/0xa2
<c01a54f1> subsys_attr_store+0x37/0x41 <c01a5772> flush_write_buffer+0x3c/046
<c01a57e3> sysfs_write_file+0x67/0x8b <c0166da6> vfs_write+0x1b9/0x1be
<c0166e6b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
This is triggered on a 2.6.17.1 kernel by:
echo mem > /sys/power/state
.config and dmesg are here:
http://fdeweerdt.free.fr/suspend_oops/
Regards,
Frederik
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 9:02 ` Frederik Deweerdt
@ 2006-06-23 9:10 ` Pavel Machek
2006-06-23 9:31 ` Andrew Morton
` (2 more replies)
0 siblings, 3 replies; 132+ messages in thread
From: Pavel Machek @ 2006-06-23 9:10 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: Andrew Morton, greg, linux-kernel, linux-pm, stern
Hi!
> > Frederik Deweerdt <deweerdt@free.fr> wrote:
> >
> > > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > > I can bisect it if we're stuck, but that'll require beer or something.
> > >
> > > FWIW, my laptop (Dell D610) gave the following results:
> > > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> >
> > So it's in mainline already - hence it's some recently-written thing which
> > was not tested in rc6-mm2.
> >
> > > 2.6.17: oops
> > > 2.6.17.1: oops
> >
> > 2.6.17 wasn't supposed to oops. Do you have details on this?
> >
> For some reason, unknown to me, the oops won't display on the serial
> link :(.
Serial console is currently broken by suspend, resume. _But_ I have a
patch I'd like you to try.... pretty please?
> Here's what I could hand copy (I've suppressed printk timing information):
> x1b9/0x1be
> <c0166e6b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
> Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
> 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
> 9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
> EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
> <3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> in_atomic():0, irqs_disabled():1
> <c0103e56> show_trace+0x20/0x22 <c0103f5b> dump_stack+0x1e/0x20
> <c011aec7> __might_sleep+0x9e/0xa6 <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
> <c011f091> profile_task_exit+0x21/0x23 <c0120946> do_exit+0x1d/0x483
> <c0104432> do_divide_error+0x0/0xbf <c0362c76> do_page_fault+0x3c4/0x752
> <c0103b2f> error_code+0x4f/0x54 <c013b33a> suspend_enter+0x2f/0x52
> <c013b3e0> enter_state+0x4b/0x8d <c013b579> state_store+0xa0/0xa2
> <c01a54f1> subsys_attr_store+0x37/0x41 <c01a5772> flush_write_buffer+0x3c/046
> <c01a57e3> sysfs_write_file+0x67/0x8b <c0166da6> vfs_write+0x1b9/0x1be
> <c0166e6b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
That is not an oops, rather a kernel BUG(). Can you just remove
might_sleep line and see what happens?
Unfortunately, backtrace does not tell me which notifier chain did
that :-(. Are you using audit or something like that?
/*
* lock for reading
*/
static inline void down_read(struct rw_semaphore *sem)
{
might_sleep();
~~~~~~~~~~~~~~~~~~~~~~
rwsemtrace(sem,"Entering down_read");
__down_read(sem);
rwsemtrace(sem,"Leaving down_read");
}
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 9:10 ` Pavel Machek
@ 2006-06-23 9:31 ` Andrew Morton
2006-06-23 12:12 ` Frederik Deweerdt
2006-06-23 19:41 ` Russell King
2 siblings, 0 replies; 132+ messages in thread
From: Andrew Morton @ 2006-06-23 9:31 UTC (permalink / raw)
To: Pavel Machek; +Cc: deweerdt, greg, linux-kernel, linux-pm, stern
On Fri, 23 Jun 2006 11:10:21 +0200
Pavel Machek <pavel@ucw.cz> wrote:
> > Here's what I could hand copy (I've suppressed printk timing information):
> > x1b9/0x1be
> > <c0166e6b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
> > Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
> > 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
> > 9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
> > EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
> > <3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> > in_atomic():0, irqs_disabled():1
> > <c0103e56> show_trace+0x20/0x22 <c0103f5b> dump_stack+0x1e/0x20
> > <c011aec7> __might_sleep+0x9e/0xa6 <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
> > <c011f091> profile_task_exit+0x21/0x23 <c0120946> do_exit+0x1d/0x483
> > <c0104432> do_divide_error+0x0/0xbf <c0362c76> do_page_fault+0x3c4/0x752
> > <c0103b2f> error_code+0x4f/0x54 <c013b33a> suspend_enter+0x2f/0x52
> > <c013b3e0> enter_state+0x4b/0x8d <c013b579> state_store+0xa0/0xa2
> > <c01a54f1> subsys_attr_store+0x37/0x41 <c01a5772> flush_write_buffer+0x3c/046
> > <c01a57e3> sysfs_write_file+0x67/0x8b <c0166da6> vfs_write+0x1b9/0x1be
> > <c0166e6b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
>
> That is not an oops, rather a kernel BUG().
It's not a BUG(). It's a BUG.
IOW, it's just a WARN_ON(). Ingo decided all the scary messages should
start with the text "BUG". That doesn't correlate with BUG(). Confused
yet?
That trace is odd. It kinda looks like we got a segfault when entering the
do_suspend_lowlevel() assembly. Or something.
> Can you just remove
> might_sleep line and see what happens?
>
> Unfortunately, backtrace does not tell me which notifier chain did
> that :-(. Are you using audit or something like that?
No, that's all a consequence of something which happened earlier.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 9:10 ` Pavel Machek
2006-06-23 9:31 ` Andrew Morton
@ 2006-06-23 12:12 ` Frederik Deweerdt
2006-06-23 12:57 ` Pavel Machek
2006-06-23 19:41 ` Russell King
2 siblings, 1 reply; 132+ messages in thread
From: Frederik Deweerdt @ 2006-06-23 12:12 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, greg, linux-kernel, linux-pm, stern
On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> Hi!
>
> > > Frederik Deweerdt <deweerdt@free.fr> wrote:
> > >
> > > > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > > > I can bisect it if we're stuck, but that'll require beer or something.
> > > >
> > > > FWIW, my laptop (Dell D610) gave the following results:
> > > > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > >
> > > So it's in mainline already - hence it's some recently-written thing which
> > > was not tested in rc6-mm2.
> > >
> > > > 2.6.17: oops
> > > > 2.6.17.1: oops
> > >
> > > 2.6.17 wasn't supposed to oops. Do you have details on this?
> > >
> > For some reason, unknown to me, the oops won't display on the serial
> > link :(.
>
> Serial console is currently broken by suspend, resume. _But_ I have a
> patch I'd like you to try.... pretty please?
>
Sure :)... I applied it but the output went to the laptop's screen anyway...
> That is not an oops, rather a kernel BUG(). Can you just remove
> might_sleep line and see what happens?
>
> Unfortunately, backtrace does not tell me which notifier chain did
> that :-(. Are you using audit or something like that?
>
> /*
> * lock for reading
> */
> static inline void down_read(struct rw_semaphore *sem)
> {
> might_sleep();
> ~~~~~~~~~~~~~~~~~~~~~~
> rwsemtrace(sem,"Entering down_read");
> __down_read(sem);
> rwsemtrace(sem,"Leaving down_read");
> }
>
Here's the (hand copied) dump when the might_sleep is removed:
esi: 00000003 edit: 00000000 ebp: f6cb9eb8 esp: f6cb9ea4
ds: 007b es: 007b ss: 0068
Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)
Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
Call Trace:
<c0103eea> show_stack_log_lvl+0x92/0xb7 <c0104100> show_registers+0x1a3/0x21b
<c0104319> die+0x117/0x230 <c03627a6> do_page_fault+0x39c/0x72a
<c0103b2f> error_code+0x4f/0x54 <c013b242> suspend_enter+0x2f/0x52
<c013b2e8> enter_state+0x4b/0x8d <c013b481> state_store+0xa0/0xa2
<c01a5151> subsys_attr_store+0x37/0x41 <c01a53d2> flush_write_buffer+0x3c/0x46
<c01a5443> sysfs_write_file+0x67/0x8b <c0166bb6> vfs_write+0x1b9/0x1be
<c0166c7b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
Regards,
Frederik
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 12:12 ` Frederik Deweerdt
@ 2006-06-23 12:57 ` Pavel Machek
2006-06-23 13:47 ` Frederik Deweerdt
2006-06-23 19:57 ` Andrew Morton
0 siblings, 2 replies; 132+ messages in thread
From: Pavel Machek @ 2006-06-23 12:57 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: Andrew Morton, greg, linux-kernel, linux-pm, stern
Hi!
> > > > 2.6.17 wasn't supposed to oops. Do you have details on this?
> > > >
> > > For some reason, unknown to me, the oops won't display on the serial
> > > link :(.
> >
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
> >
> Sure :)... I applied it but the output went to the laptop's screen anyway...
Do you need some kernel command line options? This is s2ram, do I
recall it correctly?
> > That is not an oops, rather a kernel BUG(). Can you just remove
> > might_sleep line and see what happens?
> >
> > Unfortunately, backtrace does not tell me which notifier chain did
> > that :-(. Are you using audit or something like that?
> >
> > /*
> > * lock for reading
> > */
> > static inline void down_read(struct rw_semaphore *sem)
> > {
> > might_sleep();
> > ~~~~~~~~~~~~~~~~~~~~~~
> > rwsemtrace(sem,"Entering down_read");
> > __down_read(sem);
> > rwsemtrace(sem,"Leaving down_read");
> > }
> >
> Here's the (hand copied) dump when the might_sleep is removed:
>
> esi: 00000003 edit: 00000000 ebp: f6cb9eb8 esp: f6cb9ea4
> ds: 007b es: 007b ss: 0068
> Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)
This stack lines are not really interesting (can you comment them from
sources?) and they make interesting info scroll away :-(. Or maybe
vga=1 can help?
> Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> 00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> Call Trace:
> <c0103eea> show_stack_log_lvl+0x92/0xb7 <c0104100> show_registers+0x1a3/0x21b
> <c0104319> die+0x117/0x230 <c03627a6> do_page_fault+0x39c/0x72a
> <c0103b2f> error_code+0x4f/0x54 <c013b242> suspend_enter+0x2f/0x52
> <c013b2e8> enter_state+0x4b/0x8d <c013b481> state_store+0xa0/0xa2
> <c01a5151> subsys_attr_store+0x37/0x41 <c01a53d2> flush_write_buffer+0x3c/0x46
> <c01a5443> sysfs_write_file+0x67/0x8b <c0166bb6> vfs_write+0x1b9/0x1be
> <c0166c7b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
>
> Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ha, wait a moment, this is interesting line. Can you trace down which
instruction causes this?
We recently changed pagetable handling during swsusp, perhaps thats
it? It went to Linus few minutes ago...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 12:57 ` Pavel Machek
@ 2006-06-23 13:47 ` Frederik Deweerdt
2006-06-23 19:57 ` Andrew Morton
1 sibling, 0 replies; 132+ messages in thread
From: Frederik Deweerdt @ 2006-06-23 13:47 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, greg, linux-kernel, linux-pm, stern
On Fri, Jun 23, 2006 at 02:57:01PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > 2.6.17 wasn't supposed to oops. Do you have details on this?
> > > > >
> > > > For some reason, unknown to me, the oops won't display on the serial
> > > > link :(.
> > >
> > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > patch I'd like you to try.... pretty please?
> > >
> > Sure :)... I applied it but the output went to the laptop's screen anyway...
>
> Do you need some kernel command line options? This is s2ram, do I
> recall it correctly?
I think the options are ok: I'm passing console=tty0 console=ttyS0,9600 and
everything works fine in cu(1). Until the 'echo mem > /sys/power/state', that is :)
> > esi: 00000003 edit: 00000000 ebp: f6cb9eb8 esp: f6cb9ea4
> > ds: 007b es: 007b ss: 0068
> > Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)
>
> This stack lines are not really interesting (can you comment them from
> sources?) and they make interesting info scroll away :-(.
I'll comment them out and send you the trace, but I won't get the time to
do it today, I'll try to get it done by monday.
> Or maybe vga=1 can help?
I've tried it. But somehow, the suspend process resets the resolution to the
lowest one.
>
> > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> > 00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> > c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
c0229b71 is in acpi_pm_enter:
case PM_SUSPEND_MEM:
--> do_suspend_lowlevel();
break;
c013b242 is in suspend_enter:
}
--> error = pm_ops->enter(state);
device_power_up();
c013b2e8 is in enter_state
pr_debug("PM: Entering %s sleep\n", pm_states[state]);
--> error = suspend_enter(state);
c013b481 is in state_store
if (state < PM_SUSPEND_MAX && *s)
--> error = enter_state(state);
else
> > Call Trace:
> > <c0103eea> show_stack_log_lvl+0x92/0xb7 <c0104100> show_registers+0x1a3/0x21b
> > <c0104319> die+0x117/0x230 <c03627a6> do_page_fault+0x39c/0x72a
> > <c0103b2f> error_code+0x4f/0x54 <c013b242> suspend_enter+0x2f/0x52
> > <c013b2e8> enter_state+0x4b/0x8d <c013b481> state_store+0xa0/0xa2
> > <c01a5151> subsys_attr_store+0x37/0x41 <c01a53d2> flush_write_buffer+0x3c/0x46
> > <c01a5443> sysfs_write_file+0x67/0x8b <c0166bb6> vfs_write+0x1b9/0x1be
> > <c0166c7b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
> >
> > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Ha, wait a moment, this is interesting line. Can you trace down which
> instruction causes this?
This disassembles as follows:
c043431c <do_suspend_lowlevel>:
c043431c: e8 6d 38 ea ff call c02d7b8e <save_processor_state>
c0434321: e8 a2 ff ff ff call c04342c8 <save_registers>
c0434326: 6a 03 push $0x3
c0434328: e8 ec b6 de ff call c021fa19 <acpi_enter_sleep_state>
c043432d: 83 c4 04 add $0x4,%esp
c0434330: c3 ret
So it looks like where crashing when calling save_processor_state.
> We recently changed pagetable handling during swsusp, perhaps thats
> it? It went to Linus few minutes ago...
Sorry, I don't understand what you mean: do you want me to try the latest git?
Regards,
Frederik
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 12:57 ` Pavel Machek
2006-06-23 13:47 ` Frederik Deweerdt
@ 2006-06-23 19:57 ` Andrew Morton
2006-06-26 9:00 ` Frederik Deweerdt
1 sibling, 1 reply; 132+ messages in thread
From: Andrew Morton @ 2006-06-23 19:57 UTC (permalink / raw)
To: Pavel Machek; +Cc: deweerdt, greg, linux-kernel, linux-pm, stern
On Fri, 23 Jun 2006 14:57:01 +0200
Pavel Machek <pavel@ucw.cz> wrote:
> > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> > 00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> > c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> > Call Trace:
> > <c0103eea> show_stack_log_lvl+0x92/0xb7 <c0104100> show_registers+0x1a3/0x21b
> > <c0104319> die+0x117/0x230 <c03627a6> do_page_fault+0x39c/0x72a
> > <c0103b2f> error_code+0x4f/0x54 <c013b242> suspend_enter+0x2f/0x52
> > <c013b2e8> enter_state+0x4b/0x8d <c013b481> state_store+0xa0/0xa2
> > <c01a5151> subsys_attr_store+0x37/0x41 <c01a53d2> flush_write_buffer+0x3c/0x46
> > <c01a5443> sysfs_write_file+0x67/0x8b <c0166bb6> vfs_write+0x1b9/0x1be
> > <c0166c7b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
> >
> > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Ha, wait a moment, this is interesting line. Can you trace down which
> instruction causes this?
>
> We recently changed pagetable handling during swsusp, perhaps thats
> it? It went to Linus few minutes ago...
That's a good possibility. It does appear to be oopsing at the first
instruction of arch/i386/kernel/acpi/wakeup.S:do_suspend_lowlevel().
Perhaps there's enough info in that oops trace to tell us whether it was
the instruction fetch which oopsed.
One wonders whether this will help...
--- a/arch/i386/kernel/acpi/wakeup.S~a
+++ a/arch/i386/kernel/acpi/wakeup.S
@@ -270,6 +270,7 @@ ALIGN
ENTRY(saved_magic) .long 0
ENTRY(saved_eip) .long 0
+.text
save_registers:
leal 4(%esp), %eax
movl %eax, saved_context_esp
@@ -304,6 +305,7 @@ ret_point:
call restore_processor_state
ret
+.data
ALIGN
# saved registers
saved_gdt: .long 0,0
_
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 19:57 ` Andrew Morton
@ 2006-06-26 9:00 ` Frederik Deweerdt
0 siblings, 0 replies; 132+ messages in thread
From: Frederik Deweerdt @ 2006-06-26 9:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Pavel Machek, greg, linux-kernel, linux-pm, stern
On Fri, Jun 23, 2006 at 12:57:06PM -0700, Andrew Morton wrote:
> On Fri, 23 Jun 2006 14:57:01 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
>
> > > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> > > 00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> > > c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> > > Call Trace:
> > > <c0103eea> show_stack_log_lvl+0x92/0xb7 <c0104100> show_registers+0x1a3/0x21b
> > > <c0104319> die+0x117/0x230 <c03627a6> do_page_fault+0x39c/0x72a
> > > <c0103b2f> error_code+0x4f/0x54 <c013b242> suspend_enter+0x2f/0x52
> > > <c013b2e8> enter_state+0x4b/0x8d <c013b481> state_store+0xa0/0xa2
> > > <c01a5151> subsys_attr_store+0x37/0x41 <c01a53d2> flush_write_buffer+0x3c/0x46
> > > <c01a5443> sysfs_write_file+0x67/0x8b <c0166bb6> vfs_write+0x1b9/0x1be
> > > <c0166c7b> sys_write+0x4b/0x75 <c010300f> sysenter_past_esp+0x54/0x75
> > >
> > > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Ha, wait a moment, this is interesting line. Can you trace down which
> > instruction causes this?
> >
> > We recently changed pagetable handling during swsusp, perhaps thats
> > it? It went to Linus few minutes ago...
>
> That's a good possibility. It does appear to be oopsing at the first
> instruction of arch/i386/kernel/acpi/wakeup.S:do_suspend_lowlevel().
> Perhaps there's enough info in that oops trace to tell us whether it was
> the instruction fetch which oopsed.
>
> One wonders whether this will help...
>
I've tried 2.6.17-git10 which appears to have the fix and the laptop
suspends correctly. Looks like that was it :).
Thanks,
Frederik
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 9:10 ` Pavel Machek
2006-06-23 9:31 ` Andrew Morton
2006-06-23 12:12 ` Frederik Deweerdt
@ 2006-06-23 19:41 ` Russell King
2006-06-23 20:22 ` Dave Jones
` (2 more replies)
2 siblings, 3 replies; 132+ messages in thread
From: Russell King @ 2006-06-23 19:41 UTC (permalink / raw)
To: Pavel Machek
Cc: Frederik Deweerdt, Andrew Morton, greg, linux-kernel, linux-pm, stern
On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> Serial console is currently broken by suspend, resume. _But_ I have a
> patch I'd like you to try.... pretty please?
Did you bother trying my patch, which was done the Right(tm) way?
There wasn't any feedback on it so I can only assume not.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 19:41 ` Russell King
@ 2006-06-23 20:22 ` Dave Jones
2006-06-23 21:10 ` Rafael J. Wysocki
2006-06-23 22:11 ` Pavel Machek
2 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2006-06-23 20:22 UTC (permalink / raw)
To: Pavel Machek, Frederik Deweerdt, Andrew Morton, greg,
linux-kernel, linux-pm, stern
On Fri, Jun 23, 2006 at 08:41:01PM +0100, Russell King wrote:
> On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
>
> Did you bother trying my patch, which was done the Right(tm) way?
> There wasn't any feedback on it so I can only assume not.
I thought I had replied to that. It didn't make any difference for me.
I recall seeing a posting from someone else saying the same thing.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 19:41 ` Russell King
2006-06-23 20:22 ` Dave Jones
@ 2006-06-23 21:10 ` Rafael J. Wysocki
2006-06-23 22:11 ` Pavel Machek
2 siblings, 0 replies; 132+ messages in thread
From: Rafael J. Wysocki @ 2006-06-23 21:10 UTC (permalink / raw)
To: Russell King
Cc: Pavel Machek, Frederik Deweerdt, Andrew Morton, greg,
linux-kernel, linux-pm, stern
Hi,
On Friday 23 June 2006 21:41, Russell King wrote:
> On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
>
> Did you bother trying my patch, which was done the Right(tm) way?
> There wasn't any feedback on it so I can only assume not.
Sorry for that, I just couldn't test it earlier. Works for me. :-)
Thanks,
Rafael
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 19:41 ` Russell King
2006-06-23 20:22 ` Dave Jones
2006-06-23 21:10 ` Rafael J. Wysocki
@ 2006-06-23 22:11 ` Pavel Machek
2006-06-23 23:53 ` Frederik Deweerdt
2 siblings, 1 reply; 132+ messages in thread
From: Pavel Machek @ 2006-06-23 22:11 UTC (permalink / raw)
To: Frederik Deweerdt, Andrew Morton, greg, linux-kernel, linux-pm, stern
On Fri 2006-06-23 20:41:01, Russell King wrote:
> On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
>
> Did you bother trying my patch, which was done the Right(tm) way?
> There wasn't any feedback on it so I can only assume not.
(I actually forwarded him your patch in private email).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 22:11 ` Pavel Machek
@ 2006-06-23 23:53 ` Frederik Deweerdt
2006-06-24 17:16 ` Rafael J. Wysocki
0 siblings, 1 reply; 132+ messages in thread
From: Frederik Deweerdt @ 2006-06-23 23:53 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, greg, linux-kernel, linux-pm, stern
On Sat, Jun 24, 2006 at 12:11:18AM +0200, Pavel Machek wrote:
> On Fri 2006-06-23 20:41:01, Russell King wrote:
> > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > patch I'd like you to try.... pretty please?
> >
> > Did you bother trying my patch, which was done the Right(tm) way?
> > There wasn't any feedback on it so I can only assume not.
>
> (I actually forwarded him your patch in private email).
And I did try it, but it make no difference: the output would still
appear on the laptop.
Regards,
Frederik
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]
2006-06-23 23:53 ` Frederik Deweerdt
@ 2006-06-24 17:16 ` Rafael J. Wysocki
0 siblings, 0 replies; 132+ messages in thread
From: Rafael J. Wysocki @ 2006-06-24 17:16 UTC (permalink / raw)
To: Frederik Deweerdt
Cc: Pavel Machek, Andrew Morton, greg, linux-kernel, linux-pm, stern
On Saturday 24 June 2006 01:53, Frederik Deweerdt wrote:
> On Sat, Jun 24, 2006 at 12:11:18AM +0200, Pavel Machek wrote:
> > On Fri 2006-06-23 20:41:01, Russell King wrote:
> > > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > > patch I'd like you to try.... pretty please?
> > >
> > > Did you bother trying my patch, which was done the Right(tm) way?
> > > There wasn't any feedback on it so I can only assume not.
> >
> > (I actually forwarded him your patch in private email).
> And I did try it, but it make no difference: the output would still
> appear on the laptop.
You can try to use the hack at
http://www.sisk.pl/kernel/patches/2.6.17-mm1/hack-serial-suspend.patch
and see if that makes the messages get to the serial console.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 132+ messages in thread
* [-mm patch] drivers/acpi/scan.c: make acpi_bus_type static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (5 preceding siblings ...)
2006-06-21 21:48 ` swsusp regression [Was: 2.6.17-mm1] Jiri Slaby
@ 2006-06-21 21:57 ` Adrian Bunk
2006-06-21 21:57 ` [-mm patch] drivers/ide/legacy/ide-cs.c: make 2 functions static Adrian Bunk
` (23 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 21:57 UTC (permalink / raw)
To: Andrew Morton, len.brown; +Cc: linux-kernel, linux-acpi
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> git-acpi.patch
>...
> git trees
>...
This patch makes the needlessly global acpi_bus_type static.
I'd also suggest to rename this struct, since although it's named
acpi_bus_type, it's of type "struct bus_type",
not "struct acpi_bus_type" as defined in include/acpi/acpi_bus.h .
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm1-full/drivers/acpi/scan.c.old 2006-06-21 22:35:30.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/acpi/scan.c 2006-06-21 22:35:40.000000000 +0200
@@ -1450,7 +1450,7 @@
}
-struct bus_type acpi_bus_type = {
+static struct bus_type acpi_bus_type = {
.name = "acpi",
.suspend = acpi_device_suspend,
.resume = acpi_device_resume,
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] drivers/ide/legacy/ide-cs.c: make 2 functions static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (6 preceding siblings ...)
2006-06-21 21:57 ` [-mm patch] drivers/acpi/scan.c: make acpi_bus_type static Adrian Bunk
@ 2006-06-21 21:57 ` Adrian Bunk
2006-06-21 21:57 ` [-mm patch] drivers/md/md.c: make code static Adrian Bunk
` (22 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 21:57 UTC (permalink / raw)
To: Andrew Morton, Thomas Kleffel, Dominik Brodowski
Cc: linux-kernel, B.Zolnierkiewicz, linux-ide
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> git-pcmcia.patch
>...
> git trees
>...
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/ide/legacy/ide-cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.17-mm1-full/drivers/ide/legacy/ide-cs.c.old 2006-06-21 22:54:20.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/ide/legacy/ide-cs.c 2006-06-21 22:54:37.000000000 +0200
@@ -170,11 +170,11 @@
return ide_register_hw_with_fixup(&hw, NULL, ide_undecoded_slave);
}
-void outb_io(unsigned char value, unsigned long port) {
+static void outb_io(unsigned char value, unsigned long port) {
outb(value, port);
}
-void outb_mem(unsigned char value, unsigned long port) {
+static void outb_mem(unsigned char value, unsigned long port) {
writeb(value, (void __iomem *) port);
}
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] drivers/md/md.c: make code static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (7 preceding siblings ...)
2006-06-21 21:57 ` [-mm patch] drivers/ide/legacy/ide-cs.c: make 2 functions static Adrian Bunk
@ 2006-06-21 21:57 ` Adrian Bunk
2006-06-21 21:57 ` [-mm patch] drivers/media/video/vivi.c: make 2 functions static Adrian Bunk
` (21 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 21:57 UTC (permalink / raw)
To: Andrew Morton, mingo, neilb; +Cc: linux-kernel, linux-raid
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/md/md.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.17-mm1-full/drivers/md/md.c.old 2006-06-21 22:59:44.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/md/md.c 2006-06-21 23:00:02.000000000 +0200
@@ -175,7 +175,7 @@
/* Alternate version that can be called from interrupts
* when calling sysfs_notify isn't needed.
*/
-void md_new_event_inintr(mddev_t *mddev)
+static void md_new_event_inintr(mddev_t *mddev)
{
atomic_inc(&md_event_count);
wake_up(&md_event_waiters);
@@ -2309,7 +2309,7 @@
*/
enum array_state { clear, inactive, suspended, readonly, read_auto, clean, active,
write_pending, active_idle, bad_word};
-char *array_states[] = {
+static char *array_states[] = {
"clear", "inactive", "suspended", "readonly", "read-auto", "clean", "active",
"write-pending", "active-idle", NULL };
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] drivers/media/video/vivi.c: make 2 functions static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (8 preceding siblings ...)
2006-06-21 21:57 ` [-mm patch] drivers/md/md.c: make code static Adrian Bunk
@ 2006-06-21 21:57 ` Adrian Bunk
2006-06-21 21:57 ` [-mm patch] gpio: make two mutexes static again Adrian Bunk
` (20 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 21:57 UTC (permalink / raw)
To: Andrew Morton, v4l-dvb-maintainer; +Cc: linux-kernel
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> git-dvb.patch
>...
> git trees
>...
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/media/video/vivi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.17-mm1-full/drivers/media/video/vivi.c.old 2006-06-21 23:04:12.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/media/video/vivi.c 2006-06-21 23:04:31.000000000 +0200
@@ -1011,7 +1011,7 @@
}
#endif
-int vidioc_streamon (struct file *file, void *priv, enum v4l2_buf_type i)
+static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type i)
{
struct vivi_fh *fh=priv;
struct vivi_dev *dev = fh->dev;
@@ -1026,7 +1026,7 @@
return (videobuf_streamon(&fh->vb_vidq));
}
-int vidioc_streamoff (struct file *file, void *priv, enum v4l2_buf_type i)
+static int vidioc_streamoff(struct file *file, void *priv, enum v4l2_buf_type i)
{
struct vivi_fh *fh=priv;
struct vivi_dev *dev = fh->dev;
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] gpio: make two mutexes static again
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (9 preceding siblings ...)
2006-06-21 21:57 ` [-mm patch] drivers/media/video/vivi.c: make 2 functions static Adrian Bunk
@ 2006-06-21 21:57 ` Adrian Bunk
2006-06-21 22:54 ` [-mm patch] drivers/scsi/qla2xxx/: make some functions static Adrian Bunk
` (19 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 21:57 UTC (permalink / raw)
To: Andrew Morton, Jim Cromie; +Cc: linux-kernel
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +chardev-gpio-for-scx200-pc-8736x-replace-spinlocks.patch
>...
> GPIO driver framework.
>...
scx200_gpio_config_lock and pc8736x_gpio_config_lock became global
without a good reason.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/i386/kernel/scx200.c | 2 +-
drivers/char/pc8736x_gpio.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.17-mm1-full/arch/i386/kernel/scx200.c.old 2006-06-21 22:32:23.000000000 +0200
+++ linux-2.6.17-mm1-full/arch/i386/kernel/scx200.c 2006-06-21 22:32:32.000000000 +0200
@@ -46,7 +46,7 @@
.probe = scx200_probe,
};
-DEFINE_MUTEX(scx200_gpio_config_lock);
+static DEFINE_MUTEX(scx200_gpio_config_lock);
static void __devinit scx200_init_shadow(void)
{
--- linux-2.6.17-mm1-full/drivers/char/pc8736x_gpio.c.old 2006-06-21 22:46:56.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/char/pc8736x_gpio.c 2006-06-21 22:47:05.000000000 +0200
@@ -32,7 +32,7 @@
module_param(major, int, 0);
MODULE_PARM_DESC(major, "Major device number");
-DEFINE_MUTEX(pc8736x_gpio_config_lock);
+static DEFINE_MUTEX(pc8736x_gpio_config_lock);
static unsigned pc8736x_gpio_base;
static u8 pc8736x_gpio_shadow[4];
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] drivers/scsi/qla2xxx/: make some functions static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (10 preceding siblings ...)
2006-06-21 21:57 ` [-mm patch] gpio: make two mutexes static again Adrian Bunk
@ 2006-06-21 22:54 ` Adrian Bunk
2006-06-21 23:20 ` [-mm patch] make drivers/scsi/pata_pcmcia.c:pcmcia_remove_one() static Adrian Bunk
` (18 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 22:54 UTC (permalink / raw)
To: Andrew Morton, rolandd, linux-driver
Cc: linux-kernel, openib-general, linux-scsi
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> git-infiniband.patch
>...
> git trees
>...
This patch makes some needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/scsi/qla2xxx/qla_gbl.h | 6 ------
drivers/scsi/qla2xxx/qla_init.c | 8 +++++---
drivers/scsi/qla2xxx/qla_iocb.c | 3 ++-
3 files changed, 7 insertions(+), 10 deletions(-)
--- linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_gbl.h.old 2006-06-22 00:48:35.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_gbl.h 2006-06-22 00:50:32.000000000 +0200
@@ -31,13 +31,9 @@
extern void qla24xx_update_fw_options(scsi_qla_host_t *);
extern int qla2x00_load_risc(struct scsi_qla_host *, uint32_t *);
extern int qla24xx_load_risc(scsi_qla_host_t *, uint32_t *);
-extern int qla24xx_load_risc_flash(scsi_qla_host_t *, uint32_t *);
-
-extern fc_port_t *qla2x00_alloc_fcport(scsi_qla_host_t *, gfp_t);
extern int qla2x00_loop_resync(scsi_qla_host_t *);
-extern int qla2x00_find_new_loop_id(scsi_qla_host_t *, fc_port_t *);
extern int qla2x00_fabric_login(scsi_qla_host_t *, fc_port_t *, uint16_t *);
extern int qla2x00_local_device_login(scsi_qla_host_t *, fc_port_t *);
@@ -80,8 +76,6 @@
/*
* Global Function Prototypes in qla_iocb.c source file.
*/
-extern void qla2x00_isp_cmd(scsi_qla_host_t *);
-
extern uint16_t qla2x00_calc_iocbs_32(uint16_t);
extern uint16_t qla2x00_calc_iocbs_64(uint16_t);
extern void qla2x00_build_scsi_iocbs_32(srb_t *, cmd_entry_t *, uint16_t);
--- linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_init.c.old 2006-06-22 00:48:58.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_init.c 2006-06-22 00:49:50.000000000 +0200
@@ -39,6 +39,8 @@
static int qla2x00_restart_isp(scsi_qla_host_t *);
+static int qla2x00_find_new_loop_id(scsi_qla_host_t *ha, fc_port_t *dev);
+
/****************************************************************************/
/* QLogic ISP2x00 Hardware Support Functions. */
/****************************************************************************/
@@ -1701,7 +1703,7 @@
*
* Returns a pointer to the allocated fcport, or NULL, if none available.
*/
-fc_port_t *
+static fc_port_t *
qla2x00_alloc_fcport(scsi_qla_host_t *ha, gfp_t flags)
{
fc_port_t *fcport;
@@ -2497,7 +2499,7 @@
* Context:
* Kernel context.
*/
-int
+static int
qla2x00_find_new_loop_id(scsi_qla_host_t *ha, fc_port_t *dev)
{
int rval;
@@ -3472,7 +3474,7 @@
return (rval);
}
-int
+static int
qla24xx_load_risc_flash(scsi_qla_host_t *ha, uint32_t *srisc_addr)
{
int rval;
--- linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_iocb.c.old 2006-06-22 00:50:42.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_iocb.c 2006-06-22 00:51:00.000000000 +0200
@@ -15,6 +15,7 @@
static inline cont_entry_t *qla2x00_prep_cont_type0_iocb(scsi_qla_host_t *);
static inline cont_a64_entry_t *qla2x00_prep_cont_type1_iocb(scsi_qla_host_t *);
static request_t *qla2x00_req_pkt(scsi_qla_host_t *ha);
+static void qla2x00_isp_cmd(scsi_qla_host_t *ha);
/**
* qla2x00_get_cmd_direction() - Determine control_flag data direction.
@@ -574,7 +575,7 @@
*
* Note: The caller must hold the hardware lock before calling this routine.
*/
-void
+static void
qla2x00_isp_cmd(scsi_qla_host_t *ha)
{
device_reg_t __iomem *reg = ha->iobase;
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] make drivers/scsi/pata_pcmcia.c:pcmcia_remove_one() static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (11 preceding siblings ...)
2006-06-21 22:54 ` [-mm patch] drivers/scsi/qla2xxx/: make some functions static Adrian Bunk
@ 2006-06-21 23:20 ` Adrian Bunk
2006-06-22 10:50 ` Alan Cox
2006-06-21 23:37 ` [-mm patch] make drivers/usb/misc/cy7c63.c:vendor_command() static Adrian Bunk
` (17 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 23:20 UTC (permalink / raw)
To: Andrew Morton, alan; +Cc: linux-kernel, jgarzik, linux-ide
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> git-libata-all.patch
>...
> git trees
>...
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c.old 2006-06-22 00:43:23.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c 2006-06-22 00:43:33.000000000 +0200
@@ -294,7 +294,7 @@
* cleanup. Also called on module unload for any active devices.
*/
-void pcmcia_remove_one(struct pcmcia_device *pdev)
+static void pcmcia_remove_one(struct pcmcia_device *pdev)
{
struct ata_pcmcia_info *info = pdev->priv;
struct device *dev = &pdev->dev;
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [-mm patch] make drivers/scsi/pata_pcmcia.c:pcmcia_remove_one() static
2006-06-21 23:20 ` [-mm patch] make drivers/scsi/pata_pcmcia.c:pcmcia_remove_one() static Adrian Bunk
@ 2006-06-22 10:50 ` Alan Cox
0 siblings, 0 replies; 132+ messages in thread
From: Alan Cox @ 2006-06-22 10:50 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, alan, linux-kernel, jgarzik, linux-ide
On Thu, Jun 22, 2006 at 01:20:12AM +0200, Adrian Bunk wrote:
> On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc6-mm2:
> >...
> > git-libata-all.patch
> >...
> > git trees
> >...
>
> This patch makes a needlessly global function static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Alan Cox <alan@redhat.com>
>
> --- linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c.old 2006-06-22 00:43:23.000000000 +0200
> +++ linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c 2006-06-22 00:43:33.000000000 +0200
> @@ -294,7 +294,7 @@
> * cleanup. Also called on module unload for any active devices.
> */
>
> -void pcmcia_remove_one(struct pcmcia_device *pdev)
> +static void pcmcia_remove_one(struct pcmcia_device *pdev)
> {
> struct ata_pcmcia_info *info = pdev->priv;
> struct device *dev = &pdev->dev;
--
--
In Ximian did mad Miguel a mighty mail client decree
Where Nat the crazy hacker ran
Through sourcecode measureless to man
And never coredump free
^ permalink raw reply [flat|nested] 132+ messages in thread
* [-mm patch] make drivers/usb/misc/cy7c63.c:vendor_command() static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (12 preceding siblings ...)
2006-06-21 23:20 ` [-mm patch] make drivers/scsi/pata_pcmcia.c:pcmcia_remove_one() static Adrian Bunk
@ 2006-06-21 23:37 ` Adrian Bunk
2006-06-21 23:39 ` 2.6.17-mm1 : two PF flags with the same value Peter Williams
` (16 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-21 23:37 UTC (permalink / raw)
To: Andrew Morton, Oliver Bock
Cc: linux-kernel, Greg Kroah-Hartman, linux-usb-devel
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +gregkh-usb-usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers.patch
>...
> USB tree updates
>...
This patch makes the needlessly global vendor_command() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm1-full/drivers/usb/misc/cy7c63.c.old 2006-06-22 01:25:08.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/usb/misc/cy7c63.c 2006-06-22 01:25:57.000000000 +0200
@@ -63,8 +63,8 @@
};
/* used to send usb control messages to device */
-int vendor_command(struct cy7c63 *dev, unsigned char request,
- unsigned char address, unsigned char data) {
+static int vendor_command(struct cy7c63 *dev, unsigned char request,
+ unsigned char address, unsigned char data) {
int retval = 0;
unsigned int pipe;
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1 : two PF flags with the same value
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (13 preceding siblings ...)
2006-06-21 23:37 ` [-mm patch] make drivers/usb/misc/cy7c63.c:vendor_command() static Adrian Bunk
@ 2006-06-21 23:39 ` Peter Williams
2006-06-21 23:44 ` Andrew Morton
2006-06-22 0:12 ` Paul Jackson
2006-06-22 10:03 ` [-mm patch] #if 0 drivers/usb/input/hid-core.c:hid_find_field_by_usage() Adrian Bunk
` (15 subsequent siblings)
30 siblings, 2 replies; 132+ messages in thread
From: Peter Williams @ 2006-06-21 23:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
Doing my quick review of changes to bits of code that overlap where I
wish to work I've noticed that PF_SPREAD_SLAB and PF_MUTEX_TESTER have
the same value.
define PF_SPREAD_SLAB 0x02000000 /* Spread some slab caches over cpuset */
#define PF_MEMPOLICY 0x10000000 /* Non-default NUMA mempolicy */
#define PF_MUTEX_TESTER 0x02000000 /* Thread belongs to the rt mutex
tester */
This will have interesting consequences in some circumstances, I imagine.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] #if 0 drivers/usb/input/hid-core.c:hid_find_field_by_usage()
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (14 preceding siblings ...)
2006-06-21 23:39 ` 2.6.17-mm1 : two PF flags with the same value Peter Williams
@ 2006-06-22 10:03 ` Adrian Bunk
2006-06-22 10:03 ` [-mm patch] fs/gfs2/: make code static Adrian Bunk
` (14 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-22 10:03 UTC (permalink / raw)
To: Andrew Morton, Anssi Hannula, Dmitry Torokhov; +Cc: linux-kernel, linux-input
This patch #if 0's the no longer used hid_find_field_by_usage().
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/usb/input/hid-core.c | 3 ++-
drivers/usb/input/hid.h | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.17-mm1-full/drivers/usb/input/hid.h.old 2006-06-22 01:20:25.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/usb/input/hid.h 2006-06-22 01:20:33.000000000 +0200
@@ -519,7 +519,6 @@
int hid_set_field(struct hid_field *, unsigned, __s32);
void hid_submit_report(struct hid_device *, struct hid_report *, unsigned char dir);
void hid_init_reports(struct hid_device *hid);
-struct hid_field *hid_find_field_by_usage(struct hid_device *hid, __u32 wanted_usage, int type);
int hid_wait_io(struct hid_device* hid);
--- linux-2.6.17-mm1-full/drivers/usb/input/hid-core.c.old 2006-06-22 01:20:41.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/usb/input/hid-core.c 2006-06-22 01:21:00.000000000 +0200
@@ -1108,7 +1108,7 @@
/*
* Find a report field with a specified HID usage.
*/
-
+#if 0
struct hid_field *hid_find_field_by_usage(struct hid_device *hid, __u32 wanted_usage, int type)
{
struct hid_report *report;
@@ -1120,6 +1120,7 @@
return report->field[i];
return NULL;
}
+#endif /* 0 */
static int hid_submit_out(struct hid_device *hid)
{
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] fs/gfs2/: make code static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (15 preceding siblings ...)
2006-06-22 10:03 ` [-mm patch] #if 0 drivers/usb/input/hid-core.c:hid_find_field_by_usage() Adrian Bunk
@ 2006-06-22 10:03 ` Adrian Bunk
2006-06-22 10:25 ` Steven Whitehouse
2006-06-22 14:58 ` 2.6.17-mm1 Franck Bui-Huu
` (13 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-22 10:03 UTC (permalink / raw)
To: Andrew Morton, swhiteho; +Cc: linux-kernel, linux-cluster
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> git-gfs2.patch
>...
> git trees
>...
This patch makes the following needlessly global code static:
- eaops.c: struct gfs2_security_eaops
- rgrp.c: gfs2_free_uninit_di()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/gfs2/eaops.c | 2 +-
fs/gfs2/eaops.h | 2 --
fs/gfs2/rgrp.c | 2 +-
fs/gfs2/rgrp.h | 1 -
4 files changed, 2 insertions(+), 5 deletions(-)
--- linux-2.6.17-mm1-full/fs/gfs2/eaops.h.old 2006-06-22 01:39:33.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/eaops.h 2006-06-22 01:39:45.000000000 +0200
@@ -23,8 +23,6 @@
extern struct gfs2_eattr_operations gfs2_system_eaops;
-extern struct gfs2_eattr_operations gfs2_security_eaops;
-
extern struct gfs2_eattr_operations *gfs2_ea_ops[];
#endif /* __EAOPS_DOT_H__ */
--- linux-2.6.17-mm1-full/fs/gfs2/eaops.c.old 2006-06-22 01:39:05.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/eaops.c 2006-06-22 01:39:40.000000000 +0200
@@ -214,7 +214,7 @@
.eo_name = "system",
};
-struct gfs2_eattr_operations gfs2_security_eaops = {
+static struct gfs2_eattr_operations gfs2_security_eaops = {
.eo_get = security_eo_get,
.eo_set = security_eo_set,
.eo_remove = security_eo_remove,
--- linux-2.6.17-mm1-full/fs/gfs2/rgrp.h.old 2006-06-22 01:39:52.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/rgrp.h 2006-06-22 01:40:07.000000000 +0200
@@ -43,7 +43,6 @@
void gfs2_free_data(struct gfs2_inode *ip, uint64_t bstart, uint32_t blen);
void gfs2_free_meta(struct gfs2_inode *ip, uint64_t bstart, uint32_t blen);
-void gfs2_free_uninit_di(struct gfs2_rgrpd *rgd, uint64_t blkno);
void gfs2_free_di(struct gfs2_rgrpd *rgd, struct gfs2_inode *ip);
void gfs2_unlink_di(struct inode *inode);
--- linux-2.6.17-mm1-full/fs/gfs2/rgrp.c.old 2006-06-22 01:40:15.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/rgrp.c 2006-06-22 01:40:20.000000000 +0200
@@ -1401,7 +1401,7 @@
gfs2_trans_add_rg(rgd);
}
-void gfs2_free_uninit_di(struct gfs2_rgrpd *rgd, uint64_t blkno)
+static void gfs2_free_uninit_di(struct gfs2_rgrpd *rgd, uint64_t blkno)
{
struct gfs2_sbd *sdp = rgd->rd_sbd;
struct gfs2_rgrpd *tmp_rgd;
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [-mm patch] fs/gfs2/: make code static
2006-06-22 10:03 ` [-mm patch] fs/gfs2/: make code static Adrian Bunk
@ 2006-06-22 10:25 ` Steven Whitehouse
0 siblings, 0 replies; 132+ messages in thread
From: Steven Whitehouse @ 2006-06-22 10:25 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, linux-cluster
Hi,
On Thu, 2006-06-22 at 12:03 +0200, Adrian Bunk wrote:
> On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc6-mm2:
> >...
> > git-gfs2.patch
> >...
> > git trees
> >...
>
> This patch makes the following needlessly global code static:
> - eaops.c: struct gfs2_security_eaops
> - rgrp.c: gfs2_free_uninit_di()
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
Thanks for the patch. I've added it to the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6.git
Steve.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (16 preceding siblings ...)
2006-06-22 10:03 ` [-mm patch] fs/gfs2/: make code static Adrian Bunk
@ 2006-06-22 14:58 ` Franck Bui-Huu
2006-06-22 15:20 ` 2.6.17-mm1 Mel Gorman
2006-06-22 15:52 ` 2.6.17-mm1: kernel/lockdep.c: write-only variables Adrian Bunk
` (12 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-22 14:58 UTC (permalink / raw)
To: Andrew Morton, mel; +Cc: linux-kernel, Franck
Andrew,
Andrew Morton wrote:
>
>
> All 1738 patches:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/patch-list
>
Is the following patch really needed ?
flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch
"""
The FLATMEM memory model assumes that memory is in one contigious area
based at pfn 0. If we initialise node 0 to start at any other offset we
will incorrectly map pfn's to the wrong struct page *. The key to the
memory model is the contigious nature of the memory not the location of it.
Relax the requirement for the area to start at 0.
"""
Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
convertions work when node 0 start offset do not start at 0 ?
My physical memory start at 0x20000000. So node 0 starts at an offset
different from 0. I setup ARCH_PFN_OFFSET this way
#define ARCH_PFN_OFFSET (0x20000000 << PAGE_SHIFT)
Until now (2.6.17), it works well, but this patch breaks my machine.
If you need more details about my memory mapping, feel free to ask.
Thanks
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-22 14:58 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-22 15:20 ` Mel Gorman
2006-06-22 15:50 ` 2.6.17-mm1 Franck Bui-Huu
0 siblings, 1 reply; 132+ messages in thread
From: Mel Gorman @ 2006-06-22 15:20 UTC (permalink / raw)
To: Franck; +Cc: Andrew Morton, linux-kernel
On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> Andrew,
>
> Andrew Morton wrote:
>>
>>
>> All 1738 patches:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/patch-list
>>
>
> Is the following patch really needed ?
>
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch
>
> """
> The FLATMEM memory model assumes that memory is in one contigious area
> based at pfn 0. If we initialise node 0 to start at any other offset we
> will incorrectly map pfn's to the wrong struct page *. The key to the
> memory model is the contigious nature of the memory not the location of it.
> Relax the requirement for the area to start at 0.
> """
>
> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> convertions work when node 0 start offset do not start at 0 ?
>
What happens if you have ARCH_PFN_OFFSET as
#define ARCH_PFN_OFFSET (0UL)
?
What arch is this?
> My physical memory start at 0x20000000. So node 0 starts at an offset
> different from 0. I setup ARCH_PFN_OFFSET this way
>
> #define ARCH_PFN_OFFSET (0x20000000 << PAGE_SHIFT)
>
If physical memory starts at 0x20000000, why is the PFN not
0x20000000 >> PAGE_SHIFT ?
> Until now (2.6.17), it works well, but this patch breaks my machine.
>
> If you need more details about my memory mapping, feel free to ask.
>
> Thanks
>
> Franck
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-22 15:20 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-22 15:50 ` Franck Bui-Huu
2006-06-22 15:54 ` 2.6.17-mm1 Mel Gorman
0 siblings, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-22 15:50 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck, Andrew Morton, linux-kernel
Mel Gorman wrote:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>
>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
>> convertions work when node 0 start offset do not start at 0 ?
>>
>
> What happens if you have ARCH_PFN_OFFSET as
>
> #define ARCH_PFN_OFFSET (0UL)
>
> ?
It's the default value (see memory_model.h). It means that pfn start
for node 0 is 0, therefore your physical memory address starts at 0.
>
> What arch is this?
>
well I'm working on MIPS, but you can take a look at ARM that does the
same thing better...
>> My physical memory start at 0x20000000. So node 0 starts at an offset
>> different from 0. I setup ARCH_PFN_OFFSET this way
>>
>> #define ARCH_PFN_OFFSET (0x20000000 << PAGE_SHIFT)
>>
>
> If physical memory starts at 0x20000000, why is the PFN not
> 0x20000000 >> PAGE_SHIFT ?
>
It is a typo...
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-22 15:50 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-22 15:54 ` Mel Gorman
2006-06-22 16:14 ` 2.6.17-mm1 Russell King
2006-06-22 17:25 ` 2.6.17-mm1 Franck Bui-Huu
0 siblings, 2 replies; 132+ messages in thread
From: Mel Gorman @ 2006-06-22 15:54 UTC (permalink / raw)
To: Franck; +Cc: Andrew Morton, linux-kernel
On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> Mel Gorman wrote:
>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>>
>>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
>>> convertions work when node 0 start offset do not start at 0 ?
>>>
>>
>> What happens if you have ARCH_PFN_OFFSET as
>>
>> #define ARCH_PFN_OFFSET (0UL)
>>
>> ?
>
> It's the default value (see memory_model.h). It means that pfn start
> for node 0 is 0, therefore your physical memory address starts at 0.
>
I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
ARCH_PFN_OFFSET is used as
#define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
ARCH_PFN_OFFSET)
because it knew that the map may not start at PFN 0. With
flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
start at PFN 0 even if physical memory does not start until later.
>>
>> What arch is this?
>>
>
> well I'm working on MIPS, but you can take a look at ARM that does the
> same thing better...
>
>>> My physical memory start at 0x20000000. So node 0 starts at an offset
>>> different from 0. I setup ARCH_PFN_OFFSET this way
>>>
>>> #define ARCH_PFN_OFFSET (0x20000000 << PAGE_SHIFT)
>>>
>>
>> If physical memory starts at 0x20000000, why is the PFN not
>> 0x20000000 >> PAGE_SHIFT ?
>>
>
> It is a typo...
>
ok
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-22 15:54 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-22 16:14 ` Russell King
2006-06-22 16:50 ` 2.6.17-mm1 Mel Gorman
2006-06-22 17:25 ` 2.6.17-mm1 Franck Bui-Huu
1 sibling, 1 reply; 132+ messages in thread
From: Russell King @ 2006-06-22 16:14 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck, Andrew Morton, linux-kernel
On Thu, Jun 22, 2006 at 04:54:06PM +0100, Mel Gorman wrote:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >It's the default value (see memory_model.h). It means that pfn start
> >for node 0 is 0, therefore your physical memory address starts at 0.
>
> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> ARCH_PFN_OFFSET is used as
>
> #define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
> ARCH_PFN_OFFSET)
>
> because it knew that the map may not start at PFN 0. With
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> start at PFN 0 even if physical memory does not start until later.
Doesn't that result in a massive array of struct pages if your memory
starts a 3GB physical and has 4K pages? If you have only 32MB in that
scenario, and that was correct, you'd gobble 25MB of that just to
store that array. Ouch.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-22 16:14 ` 2.6.17-mm1 Russell King
@ 2006-06-22 16:50 ` Mel Gorman
0 siblings, 0 replies; 132+ messages in thread
From: Mel Gorman @ 2006-06-22 16:50 UTC (permalink / raw)
To: Russell King; +Cc: Franck, Andrew Morton, linux-kernel
On Thu, 22 Jun 2006, Russell King wrote:
> On Thu, Jun 22, 2006 at 04:54:06PM +0100, Mel Gorman wrote:
>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>> It's the default value (see memory_model.h). It means that pfn start
>>> for node 0 is 0, therefore your physical memory address starts at 0.
>>
>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>> ARCH_PFN_OFFSET is used as
>>
>> #define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
>> ARCH_PFN_OFFSET)
>>
>> because it knew that the map may not start at PFN 0. With
>> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
>> start at PFN 0 even if physical memory does not start until later.
>
> Doesn't that result in a massive array of struct pages if your memory
> starts a 3GB physical and has 4K pages?
No, I should have been clear. The size of the map remains the same but
mem_map does not point directly to NODE_DATA(0)->node_mem_map when the PFN
of node 0 is not 0. Instead mem_map points to
NODE_DATA(0)->node_mem_map - NODE_DATA(0)->node_start_pfn
The relevant bit of code is
map = alloc_remap(pgdat->node_id, size);
if (!map)
map = alloc_bootmem_node(pgdat, size);
pgdat->node_mem_map = map + (pgdat->node_start_pfn - start);
/*
* With FLATMEM the global mem_map is used. This is assumed
* to be based at pfn 0 such that 'pfn = page* - mem_map'
* is true. Adjust map relative to node_mem_map to
* maintain this relationship.
*/
map -= pgdat->node_start_pfn;
and later
if (pgdat == NODE_DATA(0))
mem_map = map;
So memory is wasted and ARCH_PFN_OFFSET isn't needed in the case where it
is working around NODE_DATA(0)->node_start_pfn != 0
> If you have only 32MB in that
> scenario, and that was correct, you'd gobble 25MB of that just to
> store that array. Ouch.
>
It would be a kick in the shins all right if that was the case.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-22 15:54 ` 2.6.17-mm1 Mel Gorman
2006-06-22 16:14 ` 2.6.17-mm1 Russell King
@ 2006-06-22 17:25 ` Franck Bui-Huu
2006-06-23 10:20 ` 2.6.17-mm1 Mel Gorman
1 sibling, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-22 17:25 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-kernel
2006/6/22, Mel Gorman <mel@csn.ul.ie>:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>
> > Mel Gorman wrote:
> >> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >>>
> >>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> >>> convertions work when node 0 start offset do not start at 0 ?
> >>>
> >>
> >> What happens if you have ARCH_PFN_OFFSET as
> >>
> >> #define ARCH_PFN_OFFSET (0UL)
> >>
> >> ?
> >
> > It's the default value (see memory_model.h). It means that pfn start
> > for node 0 is 0, therefore your physical memory address starts at 0.
> >
>
> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
has been sent. So your patch seems to be incomplete...
> ARCH_PFN_OFFSET is used as
>
> #define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
> ARCH_PFN_OFFSET)
>
> because it knew that the map may not start at PFN 0. With
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> start at PFN 0 even if physical memory does not start until later.
>
well your approach's trick is on the mem_map address whereas
ARCH_PFN_OFFSET's one is on the computation of the index. Your
solution may result in smaller kernel (when ARCH_PFN_OFFSET != 0)
because in your case page/pfn conversion is simpler.
Maybe in your patch instead of doing:
map -= pgdat->node_start_pfn;
you could do:
map -= ARCH_OFFSET_PFN;
--
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-22 17:25 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-23 10:20 ` Mel Gorman
2006-06-23 12:22 ` 2.6.17-mm1 Franck Bui-Huu
0 siblings, 1 reply; 132+ messages in thread
From: Mel Gorman @ 2006-06-23 10:20 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Andrew Morton, linux-kernel
On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> 2006/6/22, Mel Gorman <mel@csn.ul.ie>:
> >On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >
> >> Mel Gorman wrote:
> >>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >>>>
> >>>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> >>>> convertions work when node 0 start offset do not start at 0 ?
> >>>>
> >>>
> >>> What happens if you have ARCH_PFN_OFFSET as
> >>>
> >>> #define ARCH_PFN_OFFSET (0UL)
> >>>
> >>> ?
> >>
> >> It's the default value (see memory_model.h). It means that pfn start
> >> for node 0 is 0, therefore your physical memory address starts at 0.
> >>
> >
> >I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>
> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> has been sent. So your patch seems to be incomplete...
Difficult to argue with that logic.
>
> >ARCH_PFN_OFFSET is used as
> >
> >#define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
> > ARCH_PFN_OFFSET)
> >
> >because it knew that the map may not start at PFN 0. With
> >flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> >start at PFN 0 even if physical memory does not start until later.
> >
>
> well your approach's trick is on the mem_map address whereas
> ARCH_PFN_OFFSET's one is on the computation of the index. Your
> solution may result in smaller kernel (when ARCH_PFN_OFFSET != 0)
> because in your case page/pfn conversion is simpler.
>
> Maybe in your patch instead of doing:
>
> map -= pgdat->node_start_pfn;
>
> you could do:
>
> map -= ARCH_OFFSET_PFN;
>
That will assume that ARCH_OFFSET_PFN is always equal to
NODE_DATA(0)->node_start_pfn which may cause other breakage further down
the line. How about something like this? (boot tested on x86 only)
>>> Begin patch
The FLATMEM memory model assumes that memory is
on contiguous area starting from PFN 0. The patch
flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch relaxed
this assumption by offsetting mem_map from NODE_DATA(0)->node_mem_map
by NODE_DATA(0)->node_start_pfn. However, some architectures are using
ARCH_OFFSET_PFN to do a similar job at a runtime cost which causes the map
to get offset twice.
This patch catches the situation where ARCH_OFFSET_PFN was being used to
workaround NODE_DATA(0)->node_start_pfn != 0 and prints a message letting
the arch maintainer know that ARCH_OFFSET_PFN may be safe to remove.
Once the message appears on no architectures, it may be safe to remove
ARCH_OFFSET_PFN totally.
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h 2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h 2006-06-23 10:44:18.000000000 +0100
@@ -28,9 +28,8 @@
*/
#if defined(CONFIG_FLATMEM)
-#define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
- ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn) (mem_map + (pfn))
+#define __page_to_pfn(page) ((unsigned long)((page) - mem_map))
#elif defined(CONFIG_DISCONTIGMEM)
#define __pfn_to_page(pfn) \
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/mm/page_alloc.c linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm1-clean/mm/page_alloc.c 2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c 2006-06-23 10:49:01.000000000 +0100
@@ -2316,7 +2316,22 @@ static void __init alloc_node_mem_map(st
* is true. Adjust map relative to node_mem_map to
* maintain this relationship.
*/
- map -= pgdat->node_start_pfn;
+ if (ARCH_PFN_OFFSET == 0)
+ map -= pgdat->node_start_pfn;
+ else {
+ /*
+ * If ARCH_PFN_OFFSET is being used to to workaround
+ * old assumptions of the FLATMEM memory model, print
+ * a message so that ARCH_PFN_OFFSET can be safely
+ * removed. If there are no remaining users of
+ * ARCH_PFN_OFFSET after this message no longer
+ * shows up, it'll be safe to remove this else block
+ */
+ if (ARCH_PFN_OFFSET == pgdat->node_start_pfn)
+ printk("ARCH_PFN_OFFSET not necessary\n");
+
+ map -= ARCH_PFN_OFFSET;
+ }
}
#ifdef CONFIG_FLATMEM
/*
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 10:20 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-23 12:22 ` Franck Bui-Huu
2006-06-23 12:56 ` 2.6.17-mm1 Franck Bui-Huu
2006-06-23 13:46 ` 2.6.17-mm1 Mel Gorman
0 siblings, 2 replies; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-23 12:22 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck Bui-Huu, Andrew Morton, linux-kernel
Mel Gorman wrote:
> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>
>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>> has been sent. So your patch seems to be incomplete...
>
> Difficult to argue with that logic.
>
sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
solve this before your patch has been sent. So the requirement for
memory to start at pfn 0 is already solved.
Your patch solves the problem in a different way, but it's
incompatible with the current one (ARCH_PFN_OFFSET).
IMHO the question is now, which method is the best one ? If it's yours
the we probably need to get ride of the previous method and add yours
(but don't forget to modify arch such ARM which are currently using
ARCH_PFN_OFFSET).
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-23 12:22 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-23 12:56 ` Franck Bui-Huu
2006-06-23 13:46 ` 2.6.17-mm1 Mel Gorman
1 sibling, 0 replies; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-23 12:56 UTC (permalink / raw)
To: franck.bui-huu
Cc: Mel Gorman, Franck Bui-Huu, Andrew Morton, linux-kernel, rmk+lkml
Franck Bui-Huu wrote:
> Mel Gorman wrote:
>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>> has been sent. So your patch seems to be incomplete...
>> Difficult to argue with that logic.
>>
>
> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> solve this before your patch has been sent. So the requirement for
> memory to start at pfn 0 is already solved.
>
> Your patch solves the problem in a different way, but it's
> incompatible with the current one (ARCH_PFN_OFFSET).
>
> IMHO the question is now, which method is the best one ? If it's yours
> the we probably need to get ride of the previous method and add yours
> (but don't forget to modify arch such ARM which are currently using
> ARCH_PFN_OFFSET).
>
maybe these figures can help to make our choice:
text data bss dec hex filename
2226384 223824 110624 2560832 271340 vmlinux-arch-pfn-offset-0
2228488 223824 110624 2562936 271b78 vmlinux-arch-pfn-offset-not-0
2226964 223856 110624 2561444 2715a4 vmlinux-out-of-line-pfn-to-page
Arch is MIPS and I used gcc 3.4.4
So your solution gives the smallest kernel with my config although the win
is only 0.1%. Maybe it would be good to have ARM figures/opinion too.
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-23 12:22 ` 2.6.17-mm1 Franck Bui-Huu
2006-06-23 12:56 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-23 13:46 ` Mel Gorman
2006-06-23 14:52 ` 2.6.17-mm1 Franck Bui-Huu
2006-06-23 15:06 ` 2.6.17-mm1 Franck Bui-Huu
1 sibling, 2 replies; 132+ messages in thread
From: Mel Gorman @ 2006-06-23 13:46 UTC (permalink / raw)
To: franck.bui-huu; +Cc: Franck Bui-Huu, Andrew Morton, linux-kernel
On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> >>>>
> >>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> >> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> >> has been sent. So your patch seems to be incomplete...
> >
> > Difficult to argue with that logic.
> >
>
> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> solve this before your patch has been sent. So the requirement for
> memory to start at pfn 0 is already solved.
>
In that case, the patch is as simple as you suggested earlier (patch
below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
bit of an obscure #define if you ask me. The obscurity can be lived with of
course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> IMHO the question is now, which method is the best one ?
My method should very slightly reduce the size of the kernel and have a
very minor performance improvement. How measurable it is depends on how
often page_to_pfn and pfn_to_page are called.
> the we probably need to get ride of the previous method and add yours
> (but don't forget to modify arch such ARM which are currently using
> ARCH_PFN_OFFSET).
>
If we decide to simply hold onto ARCH_PFN_OFFSET, the fix is simply;
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h 2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h 2006-06-23 10:44:18.000000000 +0100
@@ -28,9 +28,8 @@
*/
#if defined(CONFIG_FLATMEM)
-#define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
- ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn) (mem_map + (pfn))
+#define __page_to_pfn(page) ((unsigned long)((page) - mem_map))
#elif defined(CONFIG_DISCONTIGMEM)
#define __pfn_to_page(pfn) \
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/mm/page_alloc.c linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm1-clean/mm/page_alloc.c 2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c 2006-06-23 14:00:11.000000000 +0100
@@ -2316,7 +2316,7 @@ static void __init alloc_node_mem_map(st
* is true. Adjust map relative to node_mem_map to
* maintain this relationship.
*/
- map -= pgdat->node_start_pfn;
+ map -= ARCH_PFN_OFFSET;
}
#ifdef CONFIG_FLATMEM
/*
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-23 13:46 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-23 14:52 ` Franck Bui-Huu
2006-06-23 15:06 ` 2.6.17-mm1 Franck Bui-Huu
1 sibling, 0 replies; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-23 14:52 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck Bui-Huu, Andrew Morton, linux-kernel
Mel Gorman wrote:
> On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
>> Mel Gorman wrote:
>>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>>> has been sent. So your patch seems to be incomplete...
>>> Difficult to argue with that logic.
>>>
>> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
>> solve this before your patch has been sent. So the requirement for
>> memory to start at pfn 0 is already solved.
>>
>
> In that case, the patch is as simple as you suggested earlier (patch
> below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> bit of an obscure #define if you ask me. The obscurity can be lived with of
> course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
>
yes with the patch below it seems useless. But it's also a good way
for all arch to use the same name for defining the start of the
memory.
>> IMHO the question is now, which method is the best one ?
>
> My method should very slightly reduce the size of the kernel and have a
> very minor performance improvement. How measurable it is depends on how
> often page_to_pfn and pfn_to_page are called.
>
>> the we probably need to get ride of the previous method and add yours
>> (but don't forget to modify arch such ARM which are currently using
>> ARCH_PFN_OFFSET).
>>
>
> If we decide to simply hold onto ARCH_PFN_OFFSET, the fix is simply;
here is the patch I'm using, which is mainly yours.
-- >8 --
[PATCH] flatmem: tiny optimisation when memory do not start at 0
The FLATMEM memory model assumes that memory is in one contigious area
based at pfn 0. Some archictectures, like ARM, use ARCH_PFN_OFFSET to
relax this requirement. This involves one more operation during
page/pfn conversions.
Instead this patch modifies the address of mem_map to make
mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
This results in a slight gain on kernel code size.
---
include/asm-generic/memory_model.h | 6 +++---
mm/page_alloc.c | 15 +++++++++++----
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 0cfb086..2faa12f 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -34,9 +34,9 @@ #else
*/
#if defined(CONFIG_FLATMEM)
-#define pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
- ARCH_PFN_OFFSET)
+#define pfn_to_page(pfn) (mem_map + (pfn))
+#define page_to_pfn(page) ((unsigned long)((page) - mem_map))
+
#elif defined(CONFIG_DISCONTIGMEM)
#define pfn_to_page(pfn) \
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 253a450..ed6a40f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
static void __init alloc_node_mem_map(struct pglist_data *pgdat)
{
+#ifdef CONFIG_FLAT_NODE_MEM_MAP
+ struct page *map = pgdat->node_mem_map;
+
/* Skip empty nodes */
if (!pgdat->node_spanned_pages)
return;
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
/* ia64 gets its own node_mem_map, before this, without bootmem */
- if (!pgdat->node_mem_map) {
+ if (!map) {
unsigned long size, start, end;
- struct page *map;
/*
* The zone's endpoints aren't required to be MAX_ORDER
@@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
* With no DISCONTIG, the global mem_map is just set as node 0's
*/
if (pgdat == NODE_DATA(0))
- mem_map = NODE_DATA(0)->node_mem_map;
+ /*
+ * mem_map is assumed to be based at pfn 0 such that
+ * 'pfn = page* - mem_map' is true. Adjust map
+ * relative to node_mem_map to maintain this
+ * relationship.
+ */
+ mem_map = map - ARCH_PFN_OFFSET;
#endif
#endif /* CONFIG_FLAT_NODE_MEM_MAP */
}
--
1.4.0.g64e8
^ permalink raw reply related [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 13:46 ` 2.6.17-mm1 Mel Gorman
2006-06-23 14:52 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-23 15:06 ` Franck Bui-Huu
2006-06-23 15:13 ` 2.6.17-mm1 Mel Gorman
2006-06-23 15:14 ` 2.6.17-mm1 Franck Bui-Huu
1 sibling, 2 replies; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-23 15:06 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck Bui-Huu, Andrew Morton, linux-kernel
Mel Gorman wrote:
> On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
>> Mel Gorman wrote:
>>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>>> has been sent. So your patch seems to be incomplete...
>>> Difficult to argue with that logic.
>>>
>> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
>> solve this before your patch has been sent. So the requirement for
>> memory to start at pfn 0 is already solved.
>>
>
> In that case, the patch is as simple as you suggested earlier (patch
> below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> bit of an obscure #define if you ask me. The obscurity can be lived with of
> course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
>
what do you think about this use of ARCH_PFN_OFFSET ?
diff --git a/mm/bootmem.c b/mm/bootmem.c
index d213fed..fd28eed 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
return(free_all_bootmem_core(pgdat));
}
-unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
+unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
{
max_low_pfn = pages;
min_low_pfn = start;
- return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
+ return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
}
#ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ed6a40f..43abaeb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
* relative to node_mem_map to maintain this
* relationship.
*/
- mem_map = map - ARCH_PFN_OFFSET;
+ mem_map = map - pgdat->node_start_pfn;
#endif
#endif /* CONFIG_FLAT_NODE_MEM_MAP */
}
@@ -2181,8 +2181,7 @@ #endif
void __init free_area_init(unsigned long *zones_size)
{
- free_area_init_node(0, NODE_DATA(0), zones_size,
- __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
+ free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
}
#ifdef CONFIG_PROC_FS
^ permalink raw reply related [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 15:06 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-23 15:13 ` Mel Gorman
2006-06-23 15:51 ` 2.6.17-mm1 Franck Bui-Huu
2006-06-23 15:14 ` 2.6.17-mm1 Franck Bui-Huu
1 sibling, 1 reply; 132+ messages in thread
From: Mel Gorman @ 2006-06-23 15:13 UTC (permalink / raw)
To: franck.bui-huu; +Cc: Franck Bui-Huu, Andrew Morton, linux-kernel
On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
> >> Mel Gorman wrote:
> >>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> >>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> >>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> >>>> has been sent. So your patch seems to be incomplete...
> >>> Difficult to argue with that logic.
> >>>
> >> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> >> solve this before your patch has been sent. So the requirement for
> >> memory to start at pfn 0 is already solved.
> >>
> >
> > In that case, the patch is as simple as you suggested earlier (patch
> > below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> > bit of an obscure #define if you ask me. The obscurity can be lived with of
> > course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> >
>
> what do you think about this use of ARCH_PFN_OFFSET ?
>
I believe that arches calling free_area_init_node() directly, but using
CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
guarantee that pgdat->node_start_pfn will have any relation to
ARCH_PFN_OFFSET. It is why in an earlier patch, I made a check for
ARCH_PFN_OFFSET == pgdat->node_start_pfn and only then printed a message
saying that ARCH_PFN_OFFSET was unnecessary.
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
> return(free_all_bootmem_core(pgdat));
> }
>
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
> {
> max_low_pfn = pages;
> min_low_pfn = start;
> - return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> + return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
> }
>
> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ed6a40f..43abaeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
> * relative to node_mem_map to maintain this
> * relationship.
> */
> - mem_map = map - ARCH_PFN_OFFSET;
> + mem_map = map - pgdat->node_start_pfn;
> #endif
> #endif /* CONFIG_FLAT_NODE_MEM_MAP */
> }
> @@ -2181,8 +2181,7 @@ #endif
>
> void __init free_area_init(unsigned long *zones_size)
> {
> - free_area_init_node(0, NODE_DATA(0), zones_size,
> - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> + free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
> }
>
> #ifdef CONFIG_PROC_FS
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 15:13 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-23 15:51 ` Franck Bui-Huu
2006-06-23 16:38 ` 2.6.17-mm1 Mel Gorman
0 siblings, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-23 15:51 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck Bui-Huu, Andrew Morton, linux-kernel
Mel Gorman wrote:
> On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
>> what do you think about this use of ARCH_PFN_OFFSET ?
>>
>
> I believe that arches calling free_area_init_node() directly, but using
> CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
> guarantee that pgdat->node_start_pfn will have any relation to
> ARCH_PFN_OFFSET.
I agree we shouldn't make this assumption.
what about this ?
-- >8 --
[PATCH] flatmem: tiny optimisation when memory do not start at 0
The FLATMEM memory model assumes that memory is in one
contigious area based at pfn 0. Some archictectures, like
ARM, use ARCH_PFN_OFFSET to relax this requirement but it
involves one more operation during page/pfn conversion.
Instead this patch modifies the address of mem_map to make
mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
The result is a slight gain on kernel code size.
It also relaxes this requirement in two more places:
free_area_init(...)
init_bootmem(...)
---
include/asm-generic/memory_model.h | 6 +++---
mm/bootmem.c | 4 ++--
mm/page_alloc.c | 18 ++++++++++++------
3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 0cfb086..2faa12f 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -34,9 +34,9 @@ #else
*/
#if defined(CONFIG_FLATMEM)
-#define pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
- ARCH_PFN_OFFSET)
+#define pfn_to_page(pfn) (mem_map + (pfn))
+#define page_to_pfn(page) ((unsigned long)((page) - mem_map))
+
#elif defined(CONFIG_DISCONTIGMEM)
#define pfn_to_page(pfn) \
diff --git a/mm/bootmem.c b/mm/bootmem.c
index d213fed..fd28eed 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
return(free_all_bootmem_core(pgdat));
}
-unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
+unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
{
max_low_pfn = pages;
min_low_pfn = start;
- return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
+ return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
}
#ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 253a450..3e97bc3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
static void __init alloc_node_mem_map(struct pglist_data *pgdat)
{
+#ifdef CONFIG_FLAT_NODE_MEM_MAP
+ struct page *map = pgdat->node_mem_map;
+
/* Skip empty nodes */
if (!pgdat->node_spanned_pages)
return;
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
/* ia64 gets its own node_mem_map, before this, without bootmem */
- if (!pgdat->node_mem_map) {
+ if (!map) {
unsigned long size, start, end;
- struct page *map;
/*
* The zone's endpoints aren't required to be MAX_ORDER
@@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
* With no DISCONTIG, the global mem_map is just set as node 0's
*/
if (pgdat == NODE_DATA(0))
- mem_map = NODE_DATA(0)->node_mem_map;
+ /*
+ * mem_map is assumed to be based at pfn 0 such that
+ * 'pfn = page* - mem_map' is true. Adjust map
+ * relative to node_mem_map to maintain this
+ * relationship.
+ */
+ mem_map = map - ARCH_PFN_OFFSET;
#endif
#endif /* CONFIG_FLAT_NODE_MEM_MAP */
}
@@ -2174,8 +2181,7 @@ #endif
void __init free_area_init(unsigned long *zones_size)
{
- free_area_init_node(0, NODE_DATA(0), zones_size,
- __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
+ free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
}
#ifdef CONFIG_PROC_FS
--
1.4.0.g64e8
^ permalink raw reply related [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 15:51 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-23 16:38 ` Mel Gorman
2006-06-26 8:31 ` 2.6.17-mm1 Franck Bui-Huu
0 siblings, 1 reply; 132+ messages in thread
From: Mel Gorman @ 2006-06-23 16:38 UTC (permalink / raw)
To: Franck; +Cc: Andrew Morton, Linux Kernel Mailing List
On Fri, 23 Jun 2006, Franck Bui-Huu wrote:
> Mel Gorman wrote:
>> On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
>>> what do you think about this use of ARCH_PFN_OFFSET ?
>>>
>>
>> I believe that arches calling free_area_init_node() directly, but using
>> CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
>> guarantee that pgdat->node_start_pfn will have any relation to
>> ARCH_PFN_OFFSET.
>
> I agree we shouldn't make this assumption.
>
> what about this ?
>
> -- >8 --
> [PATCH] flatmem: tiny optimisation when memory do not start at 0
>
> The FLATMEM memory model assumes that memory is in one
> contigious area based at pfn 0. Some archictectures, like
> ARM, use ARCH_PFN_OFFSET to relax this requirement but it
> involves one more operation during page/pfn conversion.
>
> Instead this patch modifies the address of mem_map to make
> mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
> The result is a slight gain on kernel code size.
>
> It also relaxes this requirement in two more places:
> free_area_init(...)
> init_bootmem(...)
>
> ---
> include/asm-generic/memory_model.h | 6 +++---
> mm/bootmem.c | 4 ++--
> mm/page_alloc.c | 18 ++++++++++++------
> 3 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
> index 0cfb086..2faa12f 100644
> --- a/include/asm-generic/memory_model.h
> +++ b/include/asm-generic/memory_model.h
> @@ -34,9 +34,9 @@ #else
> */
> #if defined(CONFIG_FLATMEM)
>
> -#define pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
> -#define page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
> - ARCH_PFN_OFFSET)
> +#define pfn_to_page(pfn) (mem_map + (pfn))
> +#define page_to_pfn(page) ((unsigned long)((page) - mem_map))
> +
> #elif defined(CONFIG_DISCONTIGMEM)
>
> #define pfn_to_page(pfn) \
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
> return(free_all_bootmem_core(pgdat));
> }
>
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
> {
> max_low_pfn = pages;
> min_low_pfn = start;
> - return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> + return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
> }
>
Not all arches will use init_bootmem(). Arm for example uses
init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map, not
any node attribute. I suspect (but don't know for a fact) that if we try
and change node attributes with ARCH_PFN_OFFSET, we'll shoot ourselves in
the foot.
> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 253a450..3e97bc3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
>
> static void __init alloc_node_mem_map(struct pglist_data *pgdat)
> {
> +#ifdef CONFIG_FLAT_NODE_MEM_MAP
> + struct page *map = pgdat->node_mem_map;
> +
> /* Skip empty nodes */
> if (!pgdat->node_spanned_pages)
> return;
>
> -#ifdef CONFIG_FLAT_NODE_MEM_MAP
> /* ia64 gets its own node_mem_map, before this, without bootmem */
> - if (!pgdat->node_mem_map) {
> + if (!map) {
> unsigned long size, start, end;
> - struct page *map;
>
> /*
> * The zone's endpoints aren't required to be MAX_ORDER
> @@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
> * With no DISCONTIG, the global mem_map is just set as node 0's
> */
> if (pgdat == NODE_DATA(0))
> - mem_map = NODE_DATA(0)->node_mem_map;
> + /*
> + * mem_map is assumed to be based at pfn 0 such that
> + * 'pfn = page* - mem_map' is true. Adjust map
> + * relative to node_mem_map to maintain this
> + * relationship.
> + */
> + mem_map = map - ARCH_PFN_OFFSET;
This part is fine.
> #endif
> #endif /* CONFIG_FLAT_NODE_MEM_MAP */
> }
> @@ -2174,8 +2181,7 @@ #endif
>
> void __init free_area_init(unsigned long *zones_size)
> {
> - free_area_init_node(0, NODE_DATA(0), zones_size,
> - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> + free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
> }
>
Same comment applies as for init_bootmem(). I can't be sure it's a good
idea.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 16:38 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-26 8:31 ` Franck Bui-Huu
2006-06-26 10:37 ` 2.6.17-mm1 Mel Gorman
0 siblings, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-26 8:31 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck, Andrew Morton, Linux Kernel Mailing List
Hi Mel
Mel Gorman wrote:
> On Fri, 23 Jun 2006, Franck Bui-Huu wrote:
>
[snip]
>>
>> -unsigned long __init init_bootmem (unsigned long start, unsigned long
>> pages)
>> +unsigned long __init init_bootmem(unsigned long start, unsigned long
>> pages)
>> {
>> max_low_pfn = pages;
>> min_low_pfn = start;
>> - return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
>> + return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET,
>> pages);
>> }
>>
>
> Not all arches will use init_bootmem(). Arm for example uses
> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
page number that has physical memory. I don't see why we couldn't use
it to correctly initialise the memory system...
If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
kernel will initialise the start of memory to 0 which is boggus. IOW,
we can't use this function without this change (except if your memory
start at 0 of course). And I think that init_bootmem() has been
implemented for systems which have only one node _whatever_ memory
start value...
>> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
[snip]
>> @@ -2174,8 +2181,7 @@ #endif
>>
>> void __init free_area_init(unsigned long *zones_size)
>> {
>> - free_area_init_node(0, NODE_DATA(0), zones_size,
>> - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
>> + free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET,
>> NULL);
>> }
>>
>
> Same comment applies as for init_bootmem(). I can't be sure it's a good
> idea.
>
same comment as for init_bootmem()
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-26 8:31 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-26 10:37 ` Mel Gorman
2006-06-26 11:31 ` 2.6.17-mm1 Franck Bui-Huu
0 siblings, 1 reply; 132+ messages in thread
From: Mel Gorman @ 2006-06-26 10:37 UTC (permalink / raw)
To: Franck; +Cc: Andrew Morton, Linux Kernel Mailing List
On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> Hi Mel
>
> Mel Gorman wrote:
>> On Fri, 23 Jun 2006, Franck Bui-Huu wrote:
>>
>
> [snip]
>
>>>
>>> -unsigned long __init init_bootmem (unsigned long start, unsigned long
>>> pages)
>>> +unsigned long __init init_bootmem(unsigned long start, unsigned long
>>> pages)
>>> {
>>> max_low_pfn = pages;
>>> min_low_pfn = start;
>>> - return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
>>> + return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET,
>>> pages);
>>> }
>>>
>>
>> Not all arches will use init_bootmem(). Arm for example uses
>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>
> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
> page number that has physical memory. I don't see why we couldn't use
> it to correctly initialise the memory system...
>
Architectures will not always have a known fixed start of physical memory.
On IA64 at least, they initialise memory as if it starts at 0 but on my
one test machine, the beginning part is always a memory hole. I've seen
nothing to indicate that this hole will be the same size on all IA64
machines but I kinda doubt it. Also, arches that use init_bootmem() do not
necessary use free_area_init().
> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
> kernel will initialise the start of memory to 0 which is boggus.
> IOW,
> we can't use this function without this change (except if your memory
> start at 0 of course). And I think that init_bootmem() has been
> implemented for systems which have only one node _whatever_ memory
> start value...
>
While you may be right, it'll only fix the problem for arches with
ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I
guess). But arches using init_bootmem_node or not using free_area_init()
may still get kicked.
>>> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>
> [snip]
>
>>> @@ -2174,8 +2181,7 @@ #endif
>>>
>>> void __init free_area_init(unsigned long *zones_size)
>>> {
>>> - free_area_init_node(0, NODE_DATA(0), zones_size,
>>> - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
>>> + free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET,
>>> NULL);
>>> }
>>>
>>
>> Same comment applies as for init_bootmem(). I can't be sure it's a good
>> idea.
>>
>
> same comment as for init_bootmem()
>
>
> Franck
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-26 10:37 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-26 11:31 ` Franck Bui-Huu
2006-06-26 13:22 ` 2.6.17-mm1 Mel Gorman
0 siblings, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-26 11:31 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck, Andrew Morton, Linux Kernel Mailing List
Mel Gorman wrote:
>
> Architectures will not always have a known fixed start of physical
> memory. On IA64 at least, they initialise memory as if it starts at 0
> but on my one test machine, the beginning part is always a memory hole.
in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
change...
> I've seen nothing to indicate that this hole will be the same size on
> all IA64 machines but I kinda doubt it. Also, arches that use
> init_bootmem() do not necessary use free_area_init().
>
but in that case do they use ARCH_PFN_OFFSET != 0 ? if so that would be
very surprising. That would meand "I have a hole a the start of my mem,
I don't know at compile time where it starts, but I state that my physical
mem start at ARCH_PFN_OFFSET anyways"
>> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
>> kernel will initialise the start of memory to 0 which is boggus.
>> IOW,
>> we can't use this function without this change (except if your memory
>> start at 0 of course). And I think that init_bootmem() has been
>> implemented for systems which have only one node _whatever_ memory
>> start value...
>>
>
> While you may be right, it'll only fix the problem for arches with
> ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I
> guess). But arches using init_bootmem_node or not using free_area_init()
> may still get kicked.
>
Again in these cases, I doubt that they will setup ARCH_PFN_OFFSET...
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-26 11:31 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-26 13:22 ` Mel Gorman
2006-06-26 13:49 ` 2.6.17-mm1 Franck Bui-Huu
0 siblings, 1 reply; 132+ messages in thread
From: Mel Gorman @ 2006-06-26 13:22 UTC (permalink / raw)
To: Franck; +Cc: Andrew Morton, Linux Kernel Mailing List
On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> Mel Gorman wrote:
>>>> Not all arches will use init_bootmem(). Arm for example uses
>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>>>>
>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
>>> page number that has physical memory. I don't see why we couldn't
>>> useit to correctly initialise the memory system...
>>
>> Architectures will not always have a known fixed start of physical
>> memory. On IA64 at least, they initialise memory as if it starts at 0
>> but on my one test machine, the beginning part is always a memory hole.
>
> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
> change...
>
The change is that ARCH_PFN_OFFSET has a slightly different meaning when
you alter those two initialisation functions. Currently it is used to
offset memmap from NODE_DATA(0)->node_start_pfn. By changing
free_area_init() and init_bootmem(), it changes to altering the value of
NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
particular way. I believe it makes ARCH_PFN_OFFSET even more obscure than
it currently is.
I think we should just fix the problem at hand now for which two simple
patches have been posted and consider making further changes to
free_area_init() and init_bootmem() as a separate issue.
>> I've seen nothing to indicate that this hole will be the same size on
>> all IA64 machines but I kinda doubt it. Also, arches that use
>> init_bootmem() do not necessary use free_area_init().
>>
>
> but in that case do they use ARCH_PFN_OFFSET != 0 ?
IA64 do not and I didn't check all arches.
> if so that would be
> very surprising. That would meand "I have a hole a the start of my mem,
> I don't know at compile time where it starts, but I state that my physical
> mem start at ARCH_PFN_OFFSET anyways"
>
>>> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
>>> kernel will initialise the start of memory to 0 which is boggus.
>>> IOW,
>>> we can't use this function without this change (except if your memory
>>> start at 0 of course). And I think that init_bootmem() has been
>>> implemented for systems which have only one node _whatever_ memory
>>> start value...
>>>
>>
>> While you may be right, it'll only fix the problem for arches with
>> ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I
>> guess). But arches using init_bootmem_node or not using free_area_init()
>> may still get kicked.
>>
>
> Again in these cases, I doubt that they will setup ARCH_PFN_OFFSET...
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-26 13:22 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-26 13:49 ` Franck Bui-Huu
2006-06-26 14:31 ` 2.6.17-mm1 Mel Gorman
0 siblings, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-26 13:49 UTC (permalink / raw)
To: Mel Gorman; +Cc: Franck, Andrew Morton, Linux Kernel Mailing List
Mel Gorman wrote:
> On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
>
>> Mel Gorman wrote:
>
>>>>> Not all arches will use init_bootmem(). Arm for example uses
>>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>>>>>
>>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
>>>> page number that has physical memory. I don't see why we couldn't
>>>> useit to correctly initialise the memory system...
>>>
>>> Architectures will not always have a known fixed start of physical
>>> memory. On IA64 at least, they initialise memory as if it starts at 0
>>> but on my one test machine, the beginning part is always a memory hole.
>>
>> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
>> change...
>>
>
> The change is that ARCH_PFN_OFFSET has a slightly different meaning when
> you alter those two initialisation functions. Currently it is used to
> offset memmap from NODE_DATA(0)->node_start_pfn. By changing
> free_area_init() and init_bootmem(), it changes to altering the value of
> NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
> particular way.
well I don't see your point there. Is ARCH_PFN_OFFSET != 0 supposed to work
with free_area_init() and init_bootmem() ? If so, there is a bug since
NODE_DATA(0)->node_start_pfn is not setup correctly...
> I think we should just fix the problem at hand now for which two simple
> patches have been posted and consider making further changes to
> free_area_init() and init_bootmem() as a separate issue.
>
I agree this is a separate issue. We should resolve it in a different thread.
Mind to start a new one that involve people who can shed some light here ?
Thanks
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-26 13:49 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-26 14:31 ` Mel Gorman
2006-06-26 15:05 ` 2.6.17-mm1 Franck Bui-Huu
0 siblings, 1 reply; 132+ messages in thread
From: Mel Gorman @ 2006-06-26 14:31 UTC (permalink / raw)
To: vagabon >> Franck; +Cc: Andrew Morton, Linux Kernel Mailing List
On (26/06/06 15:49), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> >
> >> Mel Gorman wrote:
> >
> >>>>> Not all arches will use init_bootmem(). Arm for example uses
> >>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
> >>>>>
> >>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
> >>>> page number that has physical memory. I don't see why we couldn't
> >>>> useit to correctly initialise the memory system...
> >>>
> >>> Architectures will not always have a known fixed start of physical
> >>> memory. On IA64 at least, they initialise memory as if it starts at 0
> >>> but on my one test machine, the beginning part is always a memory hole.
> >>
> >> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
> >> change...
> >>
> >
> > The change is that ARCH_PFN_OFFSET has a slightly different meaning when
> > you alter those two initialisation functions. Currently it is used to
> > offset memmap from NODE_DATA(0)->node_start_pfn. By changing
> > free_area_init() and init_bootmem(), it changes to altering the value of
> > NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
> > particular way.
>
> well I don't see your point there. Is ARCH_PFN_OFFSET != 0 supposed to work
> with free_area_init() and init_bootmem() ?
I don't know for sure and for that reason alone, I'd rather not change
the meaning of ARCH_PFN_OFFSET as part of a "fix".
> If so, there is a bug since
> NODE_DATA(0)->node_start_pfn is not setup correctly...
>
> > I think we should just fix the problem at hand now for which two simple
> > patches have been posted and consider making further changes to
> > free_area_init() and init_bootmem() as a separate issue.
> >
>
> I agree this is a separate issue. We should resolve it in a different thread.
> Mind to start a new one that involve people who can shed some light here ?
>
Lets close this out first and then figure out where to go next. The following
patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
!= 0 and documents what ARCH_PFN_OFFSET is for.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h 2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h 2006-06-26 15:22:19.000000000 +0100
@@ -6,6 +6,20 @@
#if defined(CONFIG_FLATMEM)
+/*
+ * With FLATMEM, the mem_map on node 0 is used as the global mem_map.
+ * This implicitly assumes that NODE_DATA(0)->node_start_pfn == 0 and
+ * represents the first physical page frame in the system. This is not
+ * always the case as an architecture may start physical memory at 3GB
+ * for example. Rather than allocating an empty mem_map to represent
+ * the non-existent memory, ARCH_PFN_OFFSET is subtracted from
+ * NODE_DATA(0)->node_mem_map such that;
+ *
+ * PFN 0 = mem_map = NODE_DATA(0)->node_mem_map - ARCH_PFN_OFFSET
+ *
+ * One would expect NODE_DATA(0)->node_start_pfn == ARCH_PFN_OFFSET but
+ * depending on how memory is initialised, this is not always the case.
+ */
#ifndef ARCH_PFN_OFFSET
#define ARCH_PFN_OFFSET (0UL)
#endif
@@ -28,9 +42,8 @@
*/
#if defined(CONFIG_FLATMEM)
-#define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
- ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn) (mem_map + (pfn))
+#define __page_to_pfn(page) ((unsigned long)((page) - mem_map))
#elif defined(CONFIG_DISCONTIGMEM)
#define __pfn_to_page(pfn) \
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/mm/page_alloc.c linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm2-clean/mm/page_alloc.c 2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c 2006-06-26 15:11:29.000000000 +0100
@@ -2103,7 +2103,7 @@ static void __init alloc_node_mem_map(st
* is true. Adjust map relative to node_mem_map to
* maintain this relationship.
*/
- map -= pgdat->node_start_pfn;
+ map -= ARCH_PFN_OFFSET;
}
#ifdef CONFIG_FLATMEM
/*
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-26 14:31 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-26 15:05 ` Franck Bui-Huu
2006-06-26 15:15 ` 2.6.17-mm1 Mel Gorman
0 siblings, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-26 15:05 UTC (permalink / raw)
To: Mel Gorman
Cc: vagabon >> Franck, Andrew Morton, Linux Kernel Mailing List
Mel Gorman wrote:
>
> Lets close this out first and then figure out where to go next. The following
> patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
> != 0 and documents what ARCH_PFN_OFFSET is for.
>
why not dropping the initial patch, and resubmit the whole thing that
can be called an optimization rather than a fix ?
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h
> --- linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h 2006-06-26 11:38:21.000000000 +0100
> +++ linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h 2006-06-26 15:22:19.000000000 +0100
> @@ -6,6 +6,20 @@
>
> #if defined(CONFIG_FLATMEM)
>
> +/*
> + * With FLATMEM, the mem_map on node 0 is used as the global mem_map.
> + * This implicitly assumes that NODE_DATA(0)->node_start_pfn == 0 and
> + * represents the first physical page frame in the system. This is not
> + * always the case as an architecture may start physical memory at 3GB
> + * for example. Rather than allocating an empty mem_map to represent
> + * the non-existent memory, ARCH_PFN_OFFSET is subtracted from
> + * NODE_DATA(0)->node_mem_map such that;
> + *
> + * PFN 0 = mem_map = NODE_DATA(0)->node_mem_map - ARCH_PFN_OFFSET
> + *
> + * One would expect NODE_DATA(0)->node_start_pfn == ARCH_PFN_OFFSET but
> + * depending on how memory is initialised, this is not always the case.
> + */
> #ifndef ARCH_PFN_OFFSET
> #define ARCH_PFN_OFFSET (0UL)
> #endif
> @@ -28,9 +42,8 @@
> */
> #if defined(CONFIG_FLATMEM)
>
> -#define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET))
> -#define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
> - ARCH_PFN_OFFSET)
> +#define __pfn_to_page(pfn) (mem_map + (pfn))
> +#define __page_to_pfn(page) ((unsigned long)((page) - mem_map))
> #elif defined(CONFIG_DISCONTIGMEM)
>
> #define __pfn_to_page(pfn) \
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/mm/page_alloc.c linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c
> --- linux-2.6.17-mm2-clean/mm/page_alloc.c 2006-06-26 11:38:21.000000000 +0100
> +++ linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c 2006-06-26 15:11:29.000000000 +0100
> @@ -2103,7 +2103,7 @@ static void __init alloc_node_mem_map(st
> * is true. Adjust map relative to node_mem_map to
> * maintain this relationship.
> */
> - map -= pgdat->node_start_pfn;
> + map -= ARCH_PFN_OFFSET;
why not moving this inside the if statement below ?
> }
> #ifdef CONFIG_FLATMEM
> /*
>
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-26 15:05 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-26 15:15 ` Mel Gorman
0 siblings, 0 replies; 132+ messages in thread
From: Mel Gorman @ 2006-06-26 15:15 UTC (permalink / raw)
To: Franck; +Cc: Andrew Morton, Linux Kernel Mailing List
On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> Mel Gorman wrote:
>>
>> Lets close this out first and then figure out where to go next. The following
>> patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
>> != 0 and documents what ARCH_PFN_OFFSET is for.
>>
>
> why not dropping the initial patch, and resubmit the whole thing that
> can be called an optimization rather than a fix ?
>
Also works. I note that the patch has been dropped from -mm so I'll
revisit it after the next -mm release.
> <snipped>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-23 15:06 ` 2.6.17-mm1 Franck Bui-Huu
2006-06-23 15:13 ` 2.6.17-mm1 Mel Gorman
@ 2006-06-23 15:14 ` Franck Bui-Huu
2006-06-23 19:55 ` 2.6.17-mm1 Russell King
1 sibling, 1 reply; 132+ messages in thread
From: Franck Bui-Huu @ 2006-06-23 15:14 UTC (permalink / raw)
To: franck.bui-huu; +Cc: Mel Gorman, Franck Bui-Huu, Andrew Morton, linux-kernel
Franck Bui-Huu wrote:
>
> what do you think about this use of ARCH_PFN_OFFSET ?
>
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
> return(free_all_bootmem_core(pgdat));
> }
>
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
> {
> max_low_pfn = pages;
> min_low_pfn = start;
> - return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> + return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
> }
>
> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ed6a40f..43abaeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
> * relative to node_mem_map to maintain this
> * relationship.
> */
> - mem_map = map - ARCH_PFN_OFFSET;
> + mem_map = map - pgdat->node_start_pfn;
> #endif
> #endif /* CONFIG_FLAT_NODE_MEM_MAP */
> }
> @@ -2181,8 +2181,7 @@ #endif
>
> void __init free_area_init(unsigned long *zones_size)
> {
> - free_area_init_node(0, NODE_DATA(0), zones_size,
> - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
I'm wondering why using "__pa(PAGE_OFFSET) >> PAGE_SHIFT" to compute the start
of memory. That should always result in 0, shouldn't it ?
Franck
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 15:14 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-23 19:55 ` Russell King
0 siblings, 0 replies; 132+ messages in thread
From: Russell King @ 2006-06-23 19:55 UTC (permalink / raw)
To: Franck; +Cc: franck.bui-huu, Mel Gorman, Andrew Morton, linux-kernel
On Fri, Jun 23, 2006 at 05:14:23PM +0200, Franck Bui-Huu wrote:
> Franck Bui-Huu wrote:
> > - free_area_init_node(0, NODE_DATA(0), zones_size,
> > - __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
>
> I'm wondering why using "__pa(PAGE_OFFSET) >> PAGE_SHIFT" to compute the start
> of memory. That should always result in 0, shouldn't it ?
No. There are platforms where memory starts at about 3GB physical,
so __pa(PAGE_OFFSET) = 0xc0000000, which most definitely isn't zero
when shifted right by PAGE_SHIFT.
The world is not a PC.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 132+ messages in thread
* 2.6.17-mm1: kernel/lockdep.c: write-only variables
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (17 preceding siblings ...)
2006-06-22 14:58 ` 2.6.17-mm1 Franck Bui-Huu
@ 2006-06-22 15:52 ` Adrian Bunk
2006-06-23 7:26 ` Ingo Molnar
2006-06-22 21:34 ` 2.6.17-mm1: UML failing w/o SKAS enabled Theodore Tso
` (11 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-22 15:52 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar; +Cc: linux-kernel
The following variables in kernel/lockdep.c are write-only:
nr_hardirq_read_safe_locks
nr_hardirq_read_unsafe_locks
nr_hardirq_safe_locks
nr_hardirq_unsafe_locks
nr_softirq_read_safe_locks
nr_softirq_read_unsafe_locks
nr_softirq_safe_locks
nr_softirq_unsafe_locks
Is a usage pending or should they be removed?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1: kernel/lockdep.c: write-only variables
2006-06-22 15:52 ` 2.6.17-mm1: kernel/lockdep.c: write-only variables Adrian Bunk
@ 2006-06-23 7:26 ` Ingo Molnar
2006-06-23 7:49 ` Ingo Molnar
0 siblings, 1 reply; 132+ messages in thread
From: Ingo Molnar @ 2006-06-23 7:26 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel
* Adrian Bunk <bunk@stusta.de> wrote:
> The following variables in kernel/lockdep.c are write-only:
> nr_hardirq_read_safe_locks
> nr_hardirq_read_unsafe_locks
> nr_hardirq_safe_locks
> nr_hardirq_unsafe_locks
> nr_softirq_read_safe_locks
> nr_softirq_read_unsafe_locks
> nr_softirq_safe_locks
> nr_softirq_unsafe_locks
>
> Is a usage pending or should they be removed?
they are stale - i'll remove them. (there's a new calculation method for
them)
Ingo
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: kernel/lockdep.c: write-only variables
2006-06-23 7:26 ` Ingo Molnar
@ 2006-06-23 7:49 ` Ingo Molnar
0 siblings, 0 replies; 132+ messages in thread
From: Ingo Molnar @ 2006-06-23 7:49 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel
* Ingo Molnar <mingo@elte.hu> wrote:
>
> * Adrian Bunk <bunk@stusta.de> wrote:
>
> > The following variables in kernel/lockdep.c are write-only:
> > nr_hardirq_read_safe_locks
> > nr_hardirq_read_unsafe_locks
> > nr_hardirq_safe_locks
> > nr_hardirq_unsafe_locks
> > nr_softirq_read_safe_locks
> > nr_softirq_read_unsafe_locks
> > nr_softirq_safe_locks
> > nr_softirq_unsafe_locks
> >
> > Is a usage pending or should they be removed?
>
> they are stale - i'll remove them. (there's a new calculation method
> for them)
the patch is below. (Andrew, please dont apply this one - will be part
of another patchset)
Ingo
---
kernel/lockdep.c | 16 ----------------
kernel/lockdep_internals.h | 8 --------
2 files changed, 24 deletions(-)
Index: linux/kernel/lockdep.c
===================================================================
--- linux.orig/kernel/lockdep.c
+++ linux/kernel/lockdep.c
@@ -271,14 +271,6 @@ atomic_t softirqs_off_events;
atomic_t redundant_softirqs_on;
atomic_t redundant_softirqs_off;
atomic_t nr_unused_locks;
-atomic_t nr_hardirq_safe_locks;
-atomic_t nr_softirq_safe_locks;
-atomic_t nr_hardirq_unsafe_locks;
-atomic_t nr_softirq_unsafe_locks;
-atomic_t nr_hardirq_read_safe_locks;
-atomic_t nr_softirq_read_safe_locks;
-atomic_t nr_hardirq_read_unsafe_locks;
-atomic_t nr_softirq_read_unsafe_locks;
atomic_t nr_cyclic_checks;
atomic_t nr_cyclic_check_recursions;
atomic_t nr_find_usage_forwards_checks;
@@ -1640,7 +1632,6 @@ static int mark_lock(struct task_struct
LOCK_ENABLED_HARDIRQS_READ, "hard-read"))
return 0;
#endif
- debug_atomic_inc(&nr_hardirq_safe_locks);
if (hardirq_verbose(this->type))
ret = 2;
break;
@@ -1666,7 +1657,6 @@ static int mark_lock(struct task_struct
LOCK_ENABLED_SOFTIRQS_READ, "soft-read"))
return 0;
#endif
- debug_atomic_inc(&nr_softirq_safe_locks);
if (softirq_verbose(this->type))
ret = 2;
break;
@@ -1680,7 +1670,6 @@ static int mark_lock(struct task_struct
if (!check_usage_forwards(curr, this,
LOCK_ENABLED_HARDIRQS, "hard"))
return 0;
- debug_atomic_inc(&nr_hardirq_read_safe_locks);
if (hardirq_verbose(this->type))
ret = 2;
break;
@@ -1694,7 +1683,6 @@ static int mark_lock(struct task_struct
if (!check_usage_forwards(curr, this,
LOCK_ENABLED_SOFTIRQS, "soft"))
return 0;
- debug_atomic_inc(&nr_softirq_read_safe_locks);
if (softirq_verbose(this->type))
ret = 2;
break;
@@ -1721,7 +1709,6 @@ static int mark_lock(struct task_struct
LOCK_USED_IN_HARDIRQ_READ, "hard-read"))
return 0;
#endif
- debug_atomic_inc(&nr_hardirq_unsafe_locks);
if (hardirq_verbose(this->type))
ret = 2;
break;
@@ -1748,7 +1735,6 @@ static int mark_lock(struct task_struct
LOCK_USED_IN_SOFTIRQ_READ, "soft-read"))
return 0;
#endif
- debug_atomic_inc(&nr_softirq_unsafe_locks);
if (softirq_verbose(this->type))
ret = 2;
break;
@@ -1764,7 +1750,6 @@ static int mark_lock(struct task_struct
LOCK_USED_IN_HARDIRQ, "hard"))
return 0;
#endif
- debug_atomic_inc(&nr_hardirq_read_unsafe_locks);
if (hardirq_verbose(this->type))
ret = 2;
break;
@@ -1780,7 +1765,6 @@ static int mark_lock(struct task_struct
LOCK_USED_IN_SOFTIRQ, "soft"))
return 0;
#endif
- debug_atomic_inc(&nr_softirq_read_unsafe_locks);
if (softirq_verbose(this->type))
ret = 2;
break;
Index: linux/kernel/lockdep_internals.h
===================================================================
--- linux.orig/kernel/lockdep_internals.h
+++ linux/kernel/lockdep_internals.h
@@ -69,14 +69,6 @@ extern atomic_t softirqs_off_events;
extern atomic_t redundant_softirqs_on;
extern atomic_t redundant_softirqs_off;
extern atomic_t nr_unused_locks;
-extern atomic_t nr_hardirq_safe_locks;
-extern atomic_t nr_softirq_safe_locks;
-extern atomic_t nr_hardirq_unsafe_locks;
-extern atomic_t nr_softirq_unsafe_locks;
-extern atomic_t nr_hardirq_read_safe_locks;
-extern atomic_t nr_softirq_read_safe_locks;
-extern atomic_t nr_hardirq_read_unsafe_locks;
-extern atomic_t nr_softirq_read_unsafe_locks;
extern atomic_t nr_cyclic_checks;
extern atomic_t nr_cyclic_check_recursions;
extern atomic_t nr_find_usage_forwards_checks;
^ permalink raw reply [flat|nested] 132+ messages in thread
* 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (18 preceding siblings ...)
2006-06-22 15:52 ` 2.6.17-mm1: kernel/lockdep.c: write-only variables Adrian Bunk
@ 2006-06-22 21:34 ` Theodore Tso
2006-06-22 21:57 ` Andrew Morton
2006-06-23 2:42 ` Jeff Dike
2006-06-23 10:55 ` [-mm patch] fs/reiser4/: possible cleanups Adrian Bunk
` (10 subsequent siblings)
30 siblings, 2 replies; 132+ messages in thread
From: Theodore Tso @ 2006-06-22 21:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
link:
arch/um/sys-i386/built-in.o: In function `__setup_host_supports_tls':tls.c:(.init.text+0x14): undefined reference to `check_host_supports_tls'
collect2: ld returned 1 exit status
This can fixed be addressed with the attached patch, but it the
resulting kernel still doesn't boot:
<tytso@candygram> {/usr/projects/uml/linux-2.6.17-mm1}
35% ./linux
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
UML running in TT mode
tracing thread pid = 25812
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
<tytso@candygram> {/usr/projects/uml/linux-2.6.17-mm1}
36%
If anyone has any suggestions, I'd appreciate them.
- Ted
[-- Attachment #2: fix-uml-no-skas --]
[-- Type: text/plain, Size: 489 bytes --]
Index: linux-2.6.17-mm1/arch/um/os-Linux/sys-i386/Makefile
===================================================================
--- linux-2.6.17-mm1.orig/arch/um/os-Linux/sys-i386/Makefile 2006-06-17 21:49:35.000000000 -0400
+++ linux-2.6.17-mm1/arch/um/os-Linux/sys-i386/Makefile 2006-06-22 17:28:59.000000000 -0400
@@ -3,7 +3,8 @@
# Licensed under the GPL
#
-obj-$(CONFIG_MODE_SKAS) = registers.o tls.o
+obj-$(CONFIG_MODE_SKAS) = registers.o
+obj-y = tls.o
USER_OBJS := $(obj-y)
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-22 21:34 ` 2.6.17-mm1: UML failing w/o SKAS enabled Theodore Tso
@ 2006-06-22 21:57 ` Andrew Morton
2006-06-23 2:54 ` Jeff Dike
2006-06-23 2:42 ` Jeff Dike
1 sibling, 1 reply; 132+ messages in thread
From: Andrew Morton @ 2006-06-22 21:57 UTC (permalink / raw)
To: Theodore Tso; +Cc: linux-kernel, Jeff Dike
Theodore Tso <tytso@mit.edu> wrote:
>
> When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
> link:
>
> arch/um/sys-i386/built-in.o: In function `__setup_host_supports_tls':tls.c:(.init.text+0x14): undefined reference to `check_host_supports_tls'
> collect2: ld returned 1 exit status
>
> This can fixed be addressed with the attached patch,
--- linux-2.6.17-mm1.orig/arch/um/os-Linux/sys-i386/Makefile 2006-06-17 21:49:35.000000000 -0400
+++ linux-2.6.17-mm1/arch/um/os-Linux/sys-i386/Makefile 2006-06-22 17:28:59.000000000 -0400
@@ -3,7 +3,8 @@
# Licensed under the GPL
#
-obj-$(CONFIG_MODE_SKAS) = registers.o tls.o
+obj-$(CONFIG_MODE_SKAS) = registers.o
+obj-y = tls.o
USER_OBJS := $(obj-y)
hm, I don't see anything in -mm which could cause this.
> but it the
> resulting kernel still doesn't boot:
>
> <tytso@candygram> {/usr/projects/uml/linux-2.6.17-mm1}
> 35% ./linux
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> Checking for tmpfs mount on /dev/shm...OK
> Checking PROT_EXEC mmap in /dev/shm/...OK
> UML running in TT mode
> tracing thread pid = 25812
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
>
> <tytso@candygram> {/usr/projects/uml/linux-2.6.17-mm1}
> 36%
>
> If anyone has any suggestions, I'd appreciate them.
>
It's not clear what actually happened - did it quietly exit, or what?
I haven't run UML in several years, alas. I should work out how to do it
(again). Links to any uml-for-dummies site would be appreciated ;)
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-22 21:57 ` Andrew Morton
@ 2006-06-23 2:54 ` Jeff Dike
2006-06-23 10:10 ` Roman Zippel
0 siblings, 1 reply; 132+ messages in thread
From: Jeff Dike @ 2006-06-23 2:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Theodore Tso, linux-kernel
On Thu, Jun 22, 2006 at 02:57:43PM -0700, Andrew Morton wrote:
> I haven't run UML in several years, alas. I should work out how to do it
> (again). Links to any uml-for-dummies site would be appreciated ;)
http://user-mode-linux.sourceforge.net/new/index.html
Scroll down to the "Getting Started" section. You download two files,
uncompress them, and run UML. The only way I can think to make it
easier would be to make it one file by sticking the filesystem in an
initramfs :-)
For building UML, see
http://user-mode-linux.sourceforge.net/new/source.html
The important thing is to start with a defconfig in order to avoid
config grabbing the host's config from /boot.
Jeff
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-23 2:54 ` Jeff Dike
@ 2006-06-23 10:10 ` Roman Zippel
2006-06-23 14:28 ` Jeff Dike
0 siblings, 1 reply; 132+ messages in thread
From: Roman Zippel @ 2006-06-23 10:10 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, Theodore Tso, linux-kernel
Hi,
On Thu, 22 Jun 2006, Jeff Dike wrote:
> The important thing is to start with a defconfig in order to avoid
> config grabbing the host's config from /boot.
BTW this can be now configured. Check DEFCONFIG_LIST in init/Kconfig in
-mm.
bye, Roman
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-23 10:10 ` Roman Zippel
@ 2006-06-23 14:28 ` Jeff Dike
2006-06-26 11:52 ` Roman Zippel
0 siblings, 1 reply; 132+ messages in thread
From: Jeff Dike @ 2006-06-23 14:28 UTC (permalink / raw)
To: Roman Zippel; +Cc: Andrew Morton, Theodore Tso, linux-kernel
On Fri, Jun 23, 2006 at 12:10:35PM +0200, Roman Zippel wrote:
> BTW this can be now configured. Check DEFCONFIG_LIST in init/Kconfig in
> -mm.
So, something like this would be OK in order to have the UML build
just use its own defconfig?
Jeff
Make the UML build ignore the host configs in /boot, /lib, and /etc
and just use its own defconfig.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Index: linux-2.6.17/arch/um/Kconfig
===================================================================
--- linux-2.6.17.orig/arch/um/Kconfig 2006-06-20 17:24:29.000000000 -0400
+++ linux-2.6.17/arch/um/Kconfig 2006-06-23 10:20:27.000000000 -0400
@@ -1,3 +1,8 @@
+config DEFCONFIG_LIST
+ string
+ option defconfig_list
+ default "arch/um/defconfig"
+
# UML uses the generic IRQ sugsystem
config GENERIC_HARDIRQS
bool
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-23 14:28 ` Jeff Dike
@ 2006-06-26 11:52 ` Roman Zippel
2006-06-29 21:13 ` Jeff Dike
0 siblings, 1 reply; 132+ messages in thread
From: Roman Zippel @ 2006-06-26 11:52 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, Theodore Tso, linux-kernel
Hi,
On Fri, 23 Jun 2006, Jeff Dike wrote:
> Index: linux-2.6.17/arch/um/Kconfig
> ===================================================================
> --- linux-2.6.17.orig/arch/um/Kconfig 2006-06-20 17:24:29.000000000 -0400
> +++ linux-2.6.17/arch/um/Kconfig 2006-06-23 10:20:27.000000000 -0400
> @@ -1,3 +1,8 @@
> +config DEFCONFIG_LIST
> + string
> + option defconfig_list
> + default "arch/um/defconfig"
> +
> # UML uses the generic IRQ sugsystem
> config GENERIC_HARDIRQS
> bool
That would work too, but what I had in mind was to customize the entry in
init/Kconfig, e.g.
config DEFCONFIG_LIST
string
option defconfig_list
default "/lib/modules/$UNAME_RELEASE/.config"
default "/etc/kernel-config"
default "/boot/config-$UNAME_RELEASE"
depends on !UML
config DEFCONFIG_LIST
default "arch/$ARCH/defconfig"
This way the last entry is always the same for all archs and the rest can
be customized.
bye, Roman
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-26 11:52 ` Roman Zippel
@ 2006-06-29 21:13 ` Jeff Dike
0 siblings, 0 replies; 132+ messages in thread
From: Jeff Dike @ 2006-06-29 21:13 UTC (permalink / raw)
To: Roman Zippel; +Cc: Andrew Morton, Theodore Tso, linux-kernel
On Mon, Jun 26, 2006 at 01:52:54PM +0200, Roman Zippel wrote:
> That would work too, but what I had in mind was to customize the entry in
> init/Kconfig, e.g.
>
> config DEFCONFIG_LIST
> string
> option defconfig_list
> default "/lib/modules/$UNAME_RELEASE/.config"
> default "/etc/kernel-config"
> default "/boot/config-$UNAME_RELEASE"
> depends on !UML
>
> config DEFCONFIG_LIST
> default "arch/$ARCH/defconfig"
>
> This way the last entry is always the same for all archs and the rest can
> be customized.
Fine by me, are you going to send that in, or should I?
Jeff
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-22 21:34 ` 2.6.17-mm1: UML failing w/o SKAS enabled Theodore Tso
2006-06-22 21:57 ` Andrew Morton
@ 2006-06-23 2:42 ` Jeff Dike
2006-06-23 21:07 ` Theodore Tso
1 sibling, 1 reply; 132+ messages in thread
From: Jeff Dike @ 2006-06-23 2:42 UTC (permalink / raw)
To: Theodore Tso, Andrew Morton, linux-kernel
On Thu, Jun 22, 2006 at 05:34:43PM -0400, Theodore Tso wrote:
> When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
> link:
Why are you trying to do that? tt mode is bitrotting - the only
reason it is still there is that skas mode doesn't fully support SMP
yet. If SMP is the reason, then I'll add the necessary support and
send in the patch.
Jeff
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-23 2:42 ` Jeff Dike
@ 2006-06-23 21:07 ` Theodore Tso
2006-06-23 21:46 ` Jeff Dike
0 siblings, 1 reply; 132+ messages in thread
From: Theodore Tso @ 2006-06-23 21:07 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel
On Thu, Jun 22, 2006 at 10:42:22PM -0400, Jeff Dike wrote:
> On Thu, Jun 22, 2006 at 05:34:43PM -0400, Theodore Tso wrote:
> > When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
> > link:
>
> Why are you trying to do that? tt mode is bitrotting - the only
> reason it is still there is that skas mode doesn't fully support SMP
> yet. If SMP is the reason, then I'll add the necessary support and
> send in the patch.
Well, because my host kernel is running a completely stock 2.6.17
kernel and so I don't have the SKAS patch applied. If the goal is to
abandon tt mode, it would be really nice if the SKAS patch gets
integrated into mainline first....
- Ted
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-23 21:07 ` Theodore Tso
@ 2006-06-23 21:46 ` Jeff Dike
2006-06-24 12:43 ` Theodore Tso
2006-06-24 14:00 ` Theodore Tso
0 siblings, 2 replies; 132+ messages in thread
From: Jeff Dike @ 2006-06-23 21:46 UTC (permalink / raw)
To: Theodore Tso, Andrew Morton, linux-kernel
On Fri, Jun 23, 2006 at 05:07:14PM -0400, Theodore Tso wrote:
> Well, because my host kernel is running a completely stock 2.6.17
> kernel and so I don't have the SKAS patch applied. If the goal is to
> abandon tt mode, it would be really nice if the SKAS patch gets
> integrated into mainline first....
UML has a form of skas which runs on stock hosts. defconfig will give
you a CONFIG_MODE_SKAS, !CONFIG_MODE_TT UML which will run on an
unmodified host.
Jeff
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-23 21:46 ` Jeff Dike
@ 2006-06-24 12:43 ` Theodore Tso
2006-06-24 15:18 ` Jeff Dike
2006-06-24 14:00 ` Theodore Tso
1 sibling, 1 reply; 132+ messages in thread
From: Theodore Tso @ 2006-06-24 12:43 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel
On Fri, Jun 23, 2006 at 05:46:23PM -0400, Jeff Dike wrote:
> On Fri, Jun 23, 2006 at 05:07:14PM -0400, Theodore Tso wrote:
> > Well, because my host kernel is running a completely stock 2.6.17
> > kernel and so I don't have the SKAS patch applied. If the goal is to
> > abandon tt mode, it would be really nice if the SKAS patch gets
> > integrated into mainline first....
>
> UML has a form of skas which runs on stock hosts. defconfig will give
> you a CONFIG_MODE_SKAS, !CONFIG_MODE_TT UML which will run on an
> unmodified host.
It might be good to explicitly state that in the Kconfig
documentation, in particular in the documentation for CONFIG_MODE_TT.
Note that the entry for CONFIG_MODE_SKAS still mentions the need for
an external patch, and I tried searching 2.6.17-mm1's x86 config
options to see if the SKAS patch had been applied, and I couldn't find
anything, so I assumed that SKAS still required the out-of-tree patch.
If the situation is changed,
config MODE_SKAS
bool "Separate Kernel Address Space support" if MODE_TT
default y
help
This option controls whether skas (separate kernel address space)
support is compiled in. If you have applied the skas patch to the
host, then you certainly want to say Y here (and consider saying N
to CONFIG_MODE_TT). Otherwise, it is safe to say Y. Disabling this
option will shrink the UML binary slightly.
Also, just as a suggestion, it might be a good idea to update the UML
HOWTO in Documentation/uml/UserModeLinux-HOWTO.txt (or at least the
November 18, 2002 date), and also the SKAS page at:
http://user-mode-linux.sourceforge.net/skas.html
Regards,
- Ted
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-24 12:43 ` Theodore Tso
@ 2006-06-24 15:18 ` Jeff Dike
0 siblings, 0 replies; 132+ messages in thread
From: Jeff Dike @ 2006-06-24 15:18 UTC (permalink / raw)
To: Theodore Tso, Andrew Morton, linux-kernel
On Sat, Jun 24, 2006 at 08:43:54AM -0400, Theodore Tso wrote:
> It might be good to explicitly state that in the Kconfig
> documentation, in particular in the documentation for CONFIG_MODE_TT.
I'll fix those.
> Also, just as a suggestion, it might be a good idea to update the UML
> HOWTO in Documentation/uml/UserModeLinux-HOWTO.txt (or at least the
> November 18, 2002 date), and also the SKAS page at:
>
> http://user-mode-linux.sourceforge.net/skas.html
Yeah, I'm working on updating the site - see
http://user-mode-linux.sourceforge.net/new/index.html
for what I have so far.
Jeff
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-23 21:46 ` Jeff Dike
2006-06-24 12:43 ` Theodore Tso
@ 2006-06-24 14:00 ` Theodore Tso
2006-06-24 15:22 ` Jeff Dike
1 sibling, 1 reply; 132+ messages in thread
From: Theodore Tso @ 2006-06-24 14:00 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
On Fri, Jun 23, 2006 at 05:46:23PM -0400, Jeff Dike wrote:
> On Fri, Jun 23, 2006 at 05:07:14PM -0400, Theodore Tso wrote:
> > Well, because my host kernel is running a completely stock 2.6.17
> > kernel and so I don't have the SKAS patch applied. If the goal is to
> > abandon tt mode, it would be really nice if the SKAS patch gets
> > integrated into mainline first....
>
> UML has a form of skas which runs on stock hosts. defconfig will give
> you a CONFIG_MODE_SKAS, !CONFIG_MODE_TT UML which will run on an
> unmodified host.
OK, so now what did I do wrong? Host is 2.6.17; running on a
dual-core Pentium M. UML is 2.6.17-mm1 without any patches:
<tytso@candygram> {/usr/projects/uml/linux-2.6.17-mm1}
32% ./linux
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
Checking for the skas3 patch in the host:
- /proc/mm...not found
- PTRACE_FAULTINFO...not found
- PTRACE_LDT...not found
UML running in SKAS0 mode
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
<tytso@candygram> {/usr/projects/uml/linux-2.6.17-mm1}
33%
Looks like UML just crashed (tm), without any explanation. Kconfig
attached. Suggestions on how to debug this would be appreciated.
- Ted
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 14066 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.17-mm1
# Sat Jun 24 09:50:33 2006
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_UML=y
CONFIG_MMU=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_IRQ_RELEASE_METHOD=y
#
# UML-specific options
#
# CONFIG_MODE_TT is not set
# CONFIG_STATIC_LINK is not set
CONFIG_MODE_SKAS=y
#
# Host processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_UML_X86=y
# CONFIG_64BIT is not set
CONFIG_SEMAPHORE_SLEEPERS=y
# CONFIG_HOST_2G_2G is not set
CONFIG_TOP_ADDR=0xc0000000
# CONFIG_3_LEVEL_PGTABLES is not set
CONFIG_STUB_CODE=0xbfffe000
CONFIG_STUB_DATA=0xbffff000
CONFIG_STUB_START=0xbfffe000
CONFIG_ARCH_HAS_SC_SIGNALS=y
CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ADAPTIVE_READAHEAD=y
CONFIG_DEBUG_READAHEAD=y
CONFIG_READAHEAD_SMOOTH_AGING=y
CONFIG_LD_SCRIPT_DYN=y
CONFIG_NET=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_HOSTFS=y
# CONFIG_HPPFS is not set
CONFIG_MCONSOLE=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_NEST_LEVEL=0
CONFIG_HIGHMEM=y
CONFIG_KERNEL_STACK_ORDER=2
CONFIG_UML_REAL_TIME_CLOCK=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
CONFIG_SYSCTL=y
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_KLIBC_ERRLIST=y
CONFIG_KLIBC_ZLIB=y
CONFIG_UID16=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
#
# Block layer
#
# CONFIG_LBD is not set
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Block devices
#
# CONFIG_BLK_DEV_UBD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_MMAPPER is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_ATA_OVER_ETH is not set
#
# Character Devices
#
CONFIG_STDERR_CONSOLE=y
CONFIG_STDIO_CONSOLE=y
CONFIG_SSL=y
CONFIG_NULL_CHAN=y
CONFIG_PORT_CHAN=y
CONFIG_PTY_CHAN=y
CONFIG_TTY_CHAN=y
CONFIG_XTERM_CHAN=y
# CONFIG_NOCONFIG_CHAN is not set
CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
CONFIG_CON_CHAN="xterm"
CONFIG_SSL_CHAN="pty"
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
CONFIG_SOFT_WATCHDOG=m
# CONFIG_UML_WATCHDOG is not set
CONFIG_UML_SOUND=y
CONFIG_SOUND=y
CONFIG_HOSTAUDIO=y
CONFIG_UML_RANDOM=y
#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Networking
#
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
# CONFIG_IEEE80211_CRYPT_CCMP is not set
# CONFIG_IEEE80211_CRYPT_TKIP is not set
# CONFIG_IEEE80211_SOFTMAC is not set
CONFIG_WIRELESS_EXT=y
#
# UML Network Devices
#
CONFIG_UML_NET=y
# CONFIG_UML_NET_ETHERTAP is not set
CONFIG_UML_NET_TUNTAP=y
# CONFIG_UML_NET_SLIP is not set
CONFIG_UML_NET_DAEMON=y
# CONFIG_UML_NET_MCAST is not set
# CONFIG_UML_NET_PCAP is not set
# CONFIG_UML_NET_SLIRP is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
#
# PHY device support
#
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_NET_WIRELESS_RTNETLINK=y
#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m
CONFIG_PROC_EVENTS=m
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Distributed Lock Manager
#
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
#
# Library routines
#
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_INPUT is not set
#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHEDSTATS=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_RWSEMS is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
CONFIG_FORCED_INLINING=y
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_PROFILE_LIKELY is not set
# CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set
# CONFIG_GPROF is not set
# CONFIG_GCOV is not set
# CONFIG_SYSCALL_DEBUG is not set
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-24 14:00 ` Theodore Tso
@ 2006-06-24 15:22 ` Jeff Dike
2006-06-24 15:38 ` Theodore Tso
2006-06-24 16:06 ` Thomas Gleixner
0 siblings, 2 replies; 132+ messages in thread
From: Jeff Dike @ 2006-06-24 15:22 UTC (permalink / raw)
To: Theodore Tso, Andrew Morton, linux-kernel
On Sat, Jun 24, 2006 at 10:00:01AM -0400, Theodore Tso wrote:
> 32% ./linux
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> Checking for tmpfs mount on /dev/shm...OK
> Checking PROT_EXEC mmap in /dev/shm/...OK
> Checking for the skas3 patch in the host:
> - /proc/mm...not found
> - PTRACE_FAULTINFO...not found
> - PTRACE_LDT...not found
> UML running in SKAS0 mode
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
>
> <tytso@candygram> {/usr/projects/uml/linux-2.6.17-mm1}
> 33%
>
> Looks like UML just crashed (tm), without any explanation. Kconfig
> attached. Suggestions on how to debug this would be appreciated.
I'm working on this - the genirq stuff in -mm broke UML. Add stderr=1
to the command line to see the actual crash. 2.6.17 is fine, except
you need a klibc patch for O= builds.
Jeff
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-24 15:22 ` Jeff Dike
@ 2006-06-24 15:38 ` Theodore Tso
2006-06-24 16:06 ` Thomas Gleixner
1 sibling, 0 replies; 132+ messages in thread
From: Theodore Tso @ 2006-06-24 15:38 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel
On Sat, Jun 24, 2006 at 11:22:35AM -0400, Jeff Dike wrote:
> I'm working on this - the genirq stuff in -mm broke UML. Add stderr=1
> to the command line to see the actual crash. 2.6.17 is fine, except
> you need a klibc patch for O= builds.
Yeah, I was using CONFIG_MODE_TT with 2.6.17 to test the inode
slimming patches, mainly because it was a lot easier to test each
patch one at a time, and UML was working just fine for me. The only
reason I was using TT was because it had always worked before, so I
just carried over the .config file and I didn't know that TT mode was
getting deprecated. (I was using UML with 2.6.17-mm1 to port the
patches to the -mm tree so they could get wider testing.)
- Ted
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1: UML failing w/o SKAS enabled
2006-06-24 15:22 ` Jeff Dike
2006-06-24 15:38 ` Theodore Tso
@ 2006-06-24 16:06 ` Thomas Gleixner
2006-06-25 16:08 ` Jeff Dike
1 sibling, 1 reply; 132+ messages in thread
From: Thomas Gleixner @ 2006-06-24 16:06 UTC (permalink / raw)
To: Jeff Dike; +Cc: Theodore Tso, Andrew Morton, linux-kernel
On Sat, 2006-06-24 at 11:22 -0400, Jeff Dike wrote:
> On Sat, Jun 24, 2006 at 10:00:01AM -0400, Theodore Tso wrote:
> > Looks like UML just crashed (tm), without any explanation. Kconfig
> > attached. Suggestions on how to debug this would be appreciated.
>
> I'm working on this - the genirq stuff in -mm broke UML. Add stderr=1
> to the command line to see the actual crash. 2.6.17 is fine, except
> you need a klibc patch for O= builds.
Jeff, its the following patch:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/broken-out/genirq-allow-usage-of-no_irq_chip.patch
It was a brown paperbag thinko. Back it out or use -mm2
tglx
^ permalink raw reply [flat|nested] 132+ messages in thread
* [-mm patch] fs/reiser4/: possible cleanups
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (19 preceding siblings ...)
2006-06-22 21:34 ` 2.6.17-mm1: UML failing w/o SKAS enabled Theodore Tso
@ 2006-06-23 10:55 ` Adrian Bunk
2006-06-23 15:54 ` Hans Reiser
2006-06-23 10:55 ` [-mm patch] fs/ufs/inode.c: make 2 functions static Adrian Bunk
` (9 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:55 UTC (permalink / raw)
To: Andrew Morton, reiserfs-dev; +Cc: linux-kernel
This patch contains the following possible cleanups:
- make needlessly global code static
- proper prototype for the following function:
- plugin/file/file.c: init_uf_coord()
- "extern inline" -> "static inline"
- #if 0/comment out the following unused functions:
- plugin/file/cryptcompress.c: jnode_of_cluster()
- plugin/plugin.c: force_plugin()
- plugin/plugin_set.c: plugin_set_compression()
- remove the following unused variable:
- plugin/file/file.c: xversion
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/reiser4/block_alloc.c | 10 +++++-----
fs/reiser4/flush_queue.c | 2 +-
fs/reiser4/jnode.c | 7 ++++---
fs/reiser4/jnode.h | 4 ----
fs/reiser4/plugin/cluster.h | 1 -
fs/reiser4/plugin/file/cryptcompress.c | 6 ++++--
fs/reiser4/plugin/file/cryptcompress.h | 2 --
fs/reiser4/plugin/file/file.c | 4 +---
fs/reiser4/plugin/file/file.h | 4 ++--
fs/reiser4/plugin/item/extent_file_ops.c | 2 --
fs/reiser4/plugin/plugin.c | 2 ++
fs/reiser4/plugin/plugin.h | 1 -
fs/reiser4/plugin/plugin_set.c | 2 +-
fs/reiser4/plugin/plugin_set.h | 1 -
fs/reiser4/super.h | 1 -
fs/reiser4/super_ops.c | 4 ++--
fs/reiser4/txnmgr.h | 1 -
17 files changed, 22 insertions(+), 32 deletions(-)
--- linux-2.6.17-mm1-full/fs/reiser4/block_alloc.c.old 2006-06-22 16:00:18.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/block_alloc.c 2006-06-22 16:02:35.000000000 +0200
@@ -554,8 +554,8 @@
/* adjust sb block counters, if real (on-disk) block allocation immediately
follows grabbing of free disk space. */
-void grabbed2used(reiser4_context *ctx, reiser4_super_info_data *sbinfo,
- __u64 count)
+static void grabbed2used(reiser4_context *ctx, reiser4_super_info_data *sbinfo,
+ __u64 count)
{
sub_from_ctx_grabbed(ctx, count);
@@ -570,8 +570,8 @@
}
/* adjust sb block counters when @count unallocated blocks get mapped to disk */
-void fake_allocated2used(reiser4_super_info_data *sbinfo, __u64 count,
- reiser4_ba_flags_t flags)
+static void fake_allocated2used(reiser4_super_info_data *sbinfo, __u64 count,
+ reiser4_ba_flags_t flags)
{
spin_lock_reiser4_super(sbinfo);
@@ -583,7 +583,7 @@
spin_unlock_reiser4_super(sbinfo);
}
-void flush_reserved2used(txn_atom * atom, __u64 count)
+static void flush_reserved2used(txn_atom * atom, __u64 count)
{
reiser4_super_info_data *sbinfo;
--- linux-2.6.17-mm1-full/fs/reiser4/txnmgr.h.old 2006-06-22 16:02:59.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/txnmgr.h 2006-06-22 16:03:04.000000000 +0200
@@ -661,7 +661,6 @@
extern void fq_put(flush_queue_t *);
extern void fuse_fq(txn_atom * to, txn_atom * from);
extern void queue_jnode(flush_queue_t *, jnode *);
-extern void mark_jnode_queued(flush_queue_t *, jnode *);
extern int write_fq(flush_queue_t *, long *, int);
extern int current_atom_finish_all_fq(void);
--- linux-2.6.17-mm1-full/fs/reiser4/flush_queue.c.old 2006-06-22 16:03:13.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/flush_queue.c 2006-06-22 16:03:20.000000000 +0200
@@ -191,7 +191,7 @@
}
/* */
-void mark_jnode_queued(flush_queue_t * fq, jnode * node)
+static void mark_jnode_queued(flush_queue_t * fq, jnode * node)
{
JF_SET(node, JNODE_FLUSH_QUEUED);
count_enqueued_node(fq);
--- linux-2.6.17-mm1-full/fs/reiser4/jnode.h.old 2006-06-22 16:04:24.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/jnode.h 2006-06-22 16:05:25.000000000 +0200
@@ -349,12 +349,8 @@
extern jnode *jnode_by_page(struct page *pg) NONNULL;
extern jnode *jnode_of_page(struct page *pg) NONNULL;
void jnode_attach_page(jnode * node, struct page *pg);
-jnode *find_get_jnode(reiser4_tree * tree,
- struct address_space *mapping, oid_t oid,
- unsigned long index);
void unhash_unformatted_jnode(jnode *);
-struct page *jnode_get_page_locked(jnode *, gfp_t gfp_flags);
extern jnode *page_next_jnode(jnode * node) NONNULL;
extern void jnode_init(jnode * node, reiser4_tree * tree, jnode_type) NONNULL;
extern void jnode_make_dirty(jnode * node) NONNULL;
--- linux-2.6.17-mm1-full/fs/reiser4/jnode.c.old 2006-06-22 16:04:40.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/jnode.c 2006-06-22 16:05:34.000000000 +0200
@@ -537,8 +537,9 @@
* allocate new jnode, insert it, and also insert into radix tree for the
* given inode/mapping.
*/
-jnode *find_get_jnode(reiser4_tree * tree, struct address_space *mapping,
- oid_t oid, unsigned long index)
+static jnode *find_get_jnode(reiser4_tree * tree,
+ struct address_space *mapping,
+ oid_t oid, unsigned long index)
{
jnode *result;
jnode *shadow;
@@ -786,7 +787,7 @@
/* Lock a page attached to jnode, create and attach page to jnode if it had no
* one. */
-struct page *jnode_get_page_locked(jnode * node, gfp_t gfp_flags)
+static struct page *jnode_get_page_locked(jnode * node, gfp_t gfp_flags)
{
struct page *page;
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.h.old 2006-06-22 16:06:08.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.h 2006-06-22 16:07:20.000000000 +0200
@@ -459,7 +459,6 @@
void save_file_hint(struct file *, const hint_t *);
void hint_init_zero(hint_t *);
int crc_inode_ok(struct inode *inode);
-int jnode_of_cluster(const jnode * node, struct page * page);
extern int ctail_read_disk_cluster (reiser4_cluster_t *, struct inode *, int);
extern int do_readpage_ctail(struct inode *, reiser4_cluster_t *,
struct page * page);
@@ -472,7 +471,6 @@
int (*can_inherit)(struct inode * child,
struct inode * parent));
void attach_crypto_stat(struct inode * inode, crypto_stat_t * info);
-void detach_crypto_stat(struct inode * inode);
void change_crypto_stat(struct inode * inode, crypto_stat_t * new);
crypto_stat_t * alloc_crypto_stat (struct inode * inode);
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/cluster.h.old 2006-06-22 16:06:47.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/cluster.h 2006-06-22 16:06:53.000000000 +0200
@@ -240,7 +240,6 @@
int inflate_cluster(reiser4_cluster_t *, struct inode *);
int find_cluster(reiser4_cluster_t *, struct inode *, int read, int write);
-void forget_cluster_pages(struct page **page, int nrpages);
int flush_cluster_pages(reiser4_cluster_t *, jnode *, struct inode *);
int deflate_cluster(reiser4_cluster_t *, struct inode *);
void truncate_page_cluster(struct inode *inode, cloff_t start);
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.c.old 2006-06-22 16:06:19.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.c 2006-06-22 16:07:39.000000000 +0200
@@ -380,7 +380,7 @@
}
#endif /* REISER4_DEBUG */
-void detach_crypto_stat(struct inode * inode)
+static void detach_crypto_stat(struct inode * inode)
{
assert("edward-1385", inode != NULL);
assert("edward-1386", host_allows_crypto_stat(inode));
@@ -1574,6 +1574,7 @@
understand that pages of cryptcompress files are not
flushable.
*/
+#if 0
int jnode_of_cluster(const jnode * node, struct page * page)
{
assert("edward-1339", node != NULL);
@@ -1597,6 +1598,7 @@
}
return 0;
}
+#endif /* 0 */
/* put cluster pages */
void release_cluster_pages(reiser4_cluster_t * clust)
@@ -1751,7 +1753,7 @@
jput(node);
}
-void forget_cluster_pages(struct page **pages, int nr)
+static void forget_cluster_pages(struct page **pages, int nr)
{
int i;
for (i = 0; i < nr; i++) {
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.h.old 2006-06-22 16:07:55.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.h 2006-06-22 16:18:08.000000000 +0200
@@ -114,7 +114,6 @@
const reiser4_key *, znode_lock_mode,
struct inode *);
-void validate_extended_coord(uf_coord_t *, loff_t offset);
int load_file_hint(struct file *, hint_t *);
void save_file_hint(struct file *, const hint_t *);
@@ -235,8 +234,9 @@
int find_or_create_extent(struct page *);
int equal_to_ldk(znode *, const reiser4_key *);
+void init_uf_coord(uf_coord_t *uf_coord, lock_handle *lh);
-extern inline int cbk_errored(int cbk_result)
+static inline int cbk_errored(int cbk_result)
{
return (cbk_result != CBK_COORD_NOTFOUND
&& cbk_result != CBK_COORD_FOUND);
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/item/extent_file_ops.c.old 2006-06-22 16:49:24.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/item/extent_file_ops.c 2006-06-22 16:49:51.000000000 +0200
@@ -734,8 +734,6 @@
return count;
}
-void init_uf_coord(uf_coord_t *uf_coord, lock_handle *lh);
-
/**
* update_extent
* @file:
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.c.old 2006-06-22 16:08:12.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.c 2006-06-22 16:08:37.000000000 +0200
@@ -103,7 +103,7 @@
uf_coord->valid = 0;
}
-void validate_extended_coord(uf_coord_t *uf_coord, loff_t offset)
+static void validate_extended_coord(uf_coord_t *uf_coord, loff_t offset)
{
assert("vs-1333", uf_coord->valid == 0);
@@ -760,8 +760,6 @@
hint->ext_coord.lh, lock_mode, ZNODE_LOCK_LOPRI);
}
-int xversion;
-
/**
* find_or_create_extent -
* @page:
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.h.old 2006-06-22 16:09:55.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.h 2006-06-22 16:10:05.000000000 +0200
@@ -886,7 +886,6 @@
int grab_plugin(struct inode *self, struct inode *ancestor, pset_member memb);
int grab_plugin_from(struct inode *self, pset_member memb,
reiser4_plugin * plug);
-int force_plugin(struct inode *self, pset_member memb, reiser4_plugin * plug);
/* defined in fs/reiser4/plugin/object.c */
extern file_plugin file_plugins[LAST_FILE_PLUGIN_ID];
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.c.old 2006-06-22 16:10:12.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.c 2006-06-22 16:11:03.000000000 +0200
@@ -348,6 +348,7 @@
return result;
}
+#if 0
int force_plugin(struct inode *self, pset_member memb, reiser4_plugin * plug)
{
reiser4_inode *info;
@@ -362,6 +363,7 @@
update_plugin_mask(info, memb);
return result;
}
+#endif /* 0 */
reiser4_plugin_type_data plugins[REISER4_PLUGIN_TYPES] = {
/* C90 initializers */
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.h.old 2006-06-22 16:11:33.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.h 2006-06-22 16:11:42.000000000 +0200
@@ -57,7 +57,6 @@
extern int plugin_set_hash(plugin_set ** set, hash_plugin * plug);
extern int plugin_set_fibration(plugin_set ** set, fibration_plugin * plug);
extern int plugin_set_sd(plugin_set ** set, item_plugin * plug);
-extern int plugin_set_compression(plugin_set ** set, compression_plugin * plug);
extern int plugin_set_cluster(plugin_set ** set, cluster_plugin * plug);
extern int init_plugin_set(void);
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.c.old 2006-06-22 16:11:54.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.c 2006-06-22 16:12:25.000000000 +0200
@@ -322,7 +322,7 @@
DEFINE_PLUGIN_SET(item_plugin, sd)
/* DEFINE_PLUGIN_SET(cipher_plugin, cipher) */
/* DEFINE_PLUGIN_SET(digest_plugin, digest) */
- DEFINE_PLUGIN_SET(compression_plugin, compression)
+ /* DEFINE_PLUGIN_SET(compression_plugin, compression) */
/* DEFINE_PLUGIN_SET(compression_mode_plugin, compression_mode) */
DEFINE_PLUGIN_SET(cluster_plugin, cluster)
/* DEFINE_PLUGIN_SET(regular_plugin, regular_entry) */
--- linux-2.6.17-mm1-full/fs/reiser4/super.h.old 2006-06-22 16:12:41.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/super.h 2006-06-22 16:12:46.000000000 +0200
@@ -452,7 +452,6 @@
extern struct super_operations reiser4_super_operations;
extern struct export_operations reiser4_export_operations;
extern struct dentry_operations reiser4_dentry_operations;
-extern struct dentry *reiser4_debugfs_root;
/* __REISER4_SUPER_H__ */
#endif
--- linux-2.6.17-mm1-full/fs/reiser4/super_ops.c.old 2006-06-22 16:12:55.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/super_ops.c 2006-06-22 16:13:16.000000000 +0200
@@ -16,6 +16,8 @@
/* slab cache for inodes */
static kmem_cache_t *inode_cache;
+static struct dentry *reiser4_debugfs_root = NULL;
+
/**
* init_once - constructor for reiser4 inodes
* @obj: inode to be initialized
@@ -593,8 +595,6 @@
*cachep = NULL;
}
-struct dentry *reiser4_debugfs_root = NULL;
-
/**
* init_reiser4 - reiser4 initialization entry point
*
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] fs/ufs/inode.c: make 2 functions static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (20 preceding siblings ...)
2006-06-23 10:55 ` [-mm patch] fs/reiser4/: possible cleanups Adrian Bunk
@ 2006-06-23 10:55 ` Adrian Bunk
2006-06-23 10:55 ` [-mm patch] make ipc/sem.c:exit_sem() static Adrian Bunk
` (8 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:55 UTC (permalink / raw)
To: Andrew Morton, Evgeniy Dushistov; +Cc: linux-kernel
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/ufs/inode.c | 9 ++++++---
include/linux/ufs_fs.h | 2 --
2 files changed, 6 insertions(+), 5 deletions(-)
--- linux-2.6.17-mm1-full/include/linux/ufs_fs.h.old 2006-06-22 16:52:18.000000000 +0200
+++ linux-2.6.17-mm1-full/include/linux/ufs_fs.h 2006-06-22 16:53:11.000000000 +0200
@@ -973,13 +973,11 @@
extern struct inode * ufs_new_inode (struct inode *, int);
/* inode.c */
-extern u64 ufs_frag_map (struct inode *, sector_t);
extern void ufs_read_inode (struct inode *);
extern void ufs_put_inode (struct inode *);
extern int ufs_write_inode (struct inode *, int);
extern int ufs_sync_inode (struct inode *);
extern void ufs_delete_inode (struct inode *);
-extern struct buffer_head * ufs_getfrag (struct inode *, unsigned, int, int *);
extern struct buffer_head * ufs_bread (struct inode *, unsigned, int, int *);
extern int ufs_getfrag_block (struct inode *inode, sector_t fragment, struct buffer_head *bh_result, int create);
--- linux-2.6.17-mm1-full/fs/ufs/inode.c.old 2006-06-22 16:52:31.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/ufs/inode.c 2006-06-22 16:55:15.000000000 +0200
@@ -41,6 +41,8 @@
#include "swab.h"
#include "util.h"
+static u64 ufs_frag_map(struct inode *inode, sector_t frag);
+
static int ufs_block_to_path(struct inode *inode, sector_t i_block, sector_t offsets[4])
{
struct ufs_sb_private_info *uspi = UFS_SB(inode->i_sb)->s_uspi;
@@ -80,7 +82,7 @@
* the begining of the filesystem.
*/
-u64 ufs_frag_map(struct inode *inode, sector_t frag)
+static u64 ufs_frag_map(struct inode *inode, sector_t frag)
{
struct ufs_inode_info *ufsi = UFS_I(inode);
struct super_block *sb = inode->i_sb;
@@ -514,8 +516,9 @@
goto abort;
}
-struct buffer_head *ufs_getfrag(struct inode *inode, unsigned int fragment,
- int create, int *err)
+static struct buffer_head *ufs_getfrag(struct inode *inode,
+ unsigned int fragment,
+ int create, int *err)
{
struct buffer_head dummy;
int error;
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] make ipc/sem.c:exit_sem() static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (21 preceding siblings ...)
2006-06-23 10:55 ` [-mm patch] fs/ufs/inode.c: make 2 functions static Adrian Bunk
@ 2006-06-23 10:55 ` Adrian Bunk
2006-06-23 10:55 ` [-mm patch] kernel/lockdep.c: make 3 functions static Adrian Bunk
` (7 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:55 UTC (permalink / raw)
To: Andrew Morton, Matt Helsley; +Cc: linux-kernel, Jes Sorensen
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +task-watchers-register-semundo-task-watcher.patch
>...
> API for registering against task lifecycle events.
>...
exit_sem() can now become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/sem.h | 5 -----
ipc/sem.c | 3 ++-
2 files changed, 2 insertions(+), 6 deletions(-)
--- linux-2.6.17-mm1-full/include/linux/sem.h.old 2006-06-22 17:10:52.000000000 +0200
+++ linux-2.6.17-mm1-full/include/linux/sem.h 2006-06-22 17:11:02.000000000 +0200
@@ -141,7 +141,6 @@
#ifdef CONFIG_SYSVIPC
extern int copy_semundo(unsigned long clone_flags, struct task_struct *tsk);
-extern void exit_sem(struct task_struct *tsk);
#else
static inline int copy_semundo(unsigned long clone_flags, struct task_struct *tsk)
@@ -149,10 +148,6 @@
return 0;
}
-static inline void exit_sem(struct task_struct *tsk)
-{
- return;
-}
#endif
#endif /* __KERNEL__ */
--- linux-2.6.17-mm1-full/ipc/sem.c.old 2006-06-22 17:11:17.000000000 +0200
+++ linux-2.6.17-mm1-full/ipc/sem.c 2006-06-22 17:12:16.000000000 +0200
@@ -103,6 +103,7 @@
static int newary (struct ipc_namespace *, key_t, int, int);
static void freeary (struct ipc_namespace *ns, struct sem_array *sma, int id);
+static void exit_sem(struct task_struct *tsk);
#ifdef CONFIG_PROC_FS
static int sysvipc_sem_proc_show(struct seq_file *s, void *it);
#endif
@@ -1350,7 +1351,7 @@
* The current implementation does not do so. The POSIX standard
* and SVID should be consulted to determine what behavior is mandated.
*/
-void exit_sem(struct task_struct *tsk)
+static void exit_sem(struct task_struct *tsk)
{
struct sem_undo_list *undo_list;
struct sem_undo *u, **up;
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] kernel/lockdep.c: make 3 functions static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (22 preceding siblings ...)
2006-06-23 10:55 ` [-mm patch] make ipc/sem.c:exit_sem() static Adrian Bunk
@ 2006-06-23 10:55 ` Adrian Bunk
2006-06-23 11:08 ` Ingo Molnar
2006-06-23 10:55 ` [-mm patch] drivers/char/agp/nvidia-agp.c: remove unused variable Adrian Bunk
` (6 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:55 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar; +Cc: linux-kernel
This patch makes three needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
kernel/lockdep.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.17-mm1-full/kernel/lockdep.c.old 2006-06-22 17:39:33.000000000 +0200
+++ linux-2.6.17-mm1-full/kernel/lockdep.c 2006-06-22 17:48:58.000000000 +0200
@@ -444,7 +444,7 @@
printk(" ");
}
-void print_lock_type_header(struct lock_type *type, int depth)
+static void print_lock_type_header(struct lock_type *type, int depth)
{
int bit;
@@ -516,7 +516,7 @@
printk(" } [%d]", nr);
}
-void print_lock_type(struct lock_type *type)
+static void print_lock_type(struct lock_type *type)
{
print_lock_type_header(type, 0);
if (!list_empty(&type->locks_after))
@@ -1177,7 +1177,7 @@
* To make lock name printouts unique, we calculate a unique
* type->name_version generation counter:
*/
-int count_matching_names(struct lock_type *new_type)
+static int count_matching_names(struct lock_type *new_type)
{
struct lock_type *type;
int count = 0;
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] drivers/char/agp/nvidia-agp.c: remove unused variable
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (23 preceding siblings ...)
2006-06-23 10:55 ` [-mm patch] kernel/lockdep.c: make 3 functions static Adrian Bunk
@ 2006-06-23 10:55 ` Adrian Bunk
2006-06-23 10:55 ` [-mm patch] make kernel/sysctl.c:_proc_do_string() static Adrian Bunk
` (5 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:55 UTC (permalink / raw)
To: Andrew Morton, Ben Collins, Dave Jones; +Cc: linux-kernel
On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> git-agpgart.patch
>...
> git trees
>...
This patch removes an unused variable.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm1-full/drivers/char/agp/nvidia-agp.c.old 2006-06-22 18:31:18.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/char/agp/nvidia-agp.c 2006-06-22 18:31:39.000000000 +0200
@@ -387,8 +387,6 @@
static int agp_nvidia_resume(struct pci_dev *pdev)
{
- struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
-
/* set power state 0 and restore PCI space */
pci_set_power_state (pdev, 0);
pci_restore_state(pdev);
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] make kernel/sysctl.c:_proc_do_string() static
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (24 preceding siblings ...)
2006-06-23 10:55 ` [-mm patch] drivers/char/agp/nvidia-agp.c: remove unused variable Adrian Bunk
@ 2006-06-23 10:55 ` Adrian Bunk
2006-06-23 10:55 ` [-mm patch] make kernel/utsname.c:clone_uts_ns() Adrian Bunk
` (4 subsequent siblings)
30 siblings, 0 replies; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:55 UTC (permalink / raw)
To: Andrew Morton, Sam Vilain; +Cc: linux-kernel
This patch makes the needlessly global _proc_do_string() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm1-full/kernel/sysctl.c.old 2006-06-22 20:50:08.000000000 +0200
+++ linux-2.6.17-mm1-full/kernel/sysctl.c 2006-06-22 20:50:39.000000000 +0200
@@ -1706,8 +1706,9 @@
return do_rw_proc(1, file, (char __user *) buf, count, ppos);
}
-int _proc_do_string(void* data, int maxlen, int write, struct file *filp,
- void __user *buffer, size_t *lenp, loff_t *ppos)
+static int _proc_do_string(void* data, int maxlen, int write,
+ struct file *filp, void __user *buffer,
+ size_t *lenp, loff_t *ppos)
{
size_t len;
char __user *p;
^ permalink raw reply [flat|nested] 132+ messages in thread* [-mm patch] make kernel/utsname.c:clone_uts_ns()
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (25 preceding siblings ...)
2006-06-23 10:55 ` [-mm patch] make kernel/sysctl.c:_proc_do_string() static Adrian Bunk
@ 2006-06-23 10:55 ` Adrian Bunk
2006-06-23 16:35 ` Serge E. Hallyn
2006-06-23 10:56 ` [-mm patch] mm/readahead.c: cleanups Adrian Bunk
` (3 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:55 UTC (permalink / raw)
To: Andrew Morton, Serge E. Hallyn; +Cc: linux-kernel
This patch makes the needlessly global clone_uts_ns() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-mm1-full/kernel/utsname.c.old 2006-06-22 20:53:20.000000000 +0200
+++ linux-2.6.17-mm1-full/kernel/utsname.c 2006-06-22 20:53:31.000000000 +0200
@@ -19,7 +19,7 @@
* @old_ns: namespace to clone
* Return NULL on error (failure to kmalloc), new ns otherwise
*/
-struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
+static struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
{
struct uts_namespace *ns;
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [-mm patch] make kernel/utsname.c:clone_uts_ns()
2006-06-23 10:55 ` [-mm patch] make kernel/utsname.c:clone_uts_ns() Adrian Bunk
@ 2006-06-23 16:35 ` Serge E. Hallyn
0 siblings, 0 replies; 132+ messages in thread
From: Serge E. Hallyn @ 2006-06-23 16:35 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Serge E. Hallyn, linux-kernel
True.
Acked-by: Serge Hallyn <serue@us.ibm.com>
thanks,
-serge
Quoting Adrian Bunk (bunk@stusta.de):
> This patch makes the needlessly global clone_uts_ns() static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.17-mm1-full/kernel/utsname.c.old 2006-06-22 20:53:20.000000000 +0200
> +++ linux-2.6.17-mm1-full/kernel/utsname.c 2006-06-22 20:53:31.000000000 +0200
> @@ -19,7 +19,7 @@
> * @old_ns: namespace to clone
> * Return NULL on error (failure to kmalloc), new ns otherwise
> */
> -struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
> +static struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
> {
> struct uts_namespace *ns;
>
^ permalink raw reply [flat|nested] 132+ messages in thread
* [-mm patch] mm/readahead.c: cleanups
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (26 preceding siblings ...)
2006-06-23 10:55 ` [-mm patch] make kernel/utsname.c:clone_uts_ns() Adrian Bunk
@ 2006-06-23 10:56 ` Adrian Bunk
2006-06-24 6:00 ` Andrew Morton
2006-06-23 12:33 ` 2.6.17-mm1 Michal Piotrowski
` (2 subsequent siblings)
30 siblings, 1 reply; 132+ messages in thread
From: Adrian Bunk @ 2006-06-23 10:56 UTC (permalink / raw)
To: Andrew Morton, Wu Fengguang; +Cc: linux-kernel
This patch contains the following cleanups:
- make needlessly global code static
- rename the global variable debug_level (sic) to readahead_debug_level
- proper extern declaration for readahead_debug_level in
include/linux/mm.h
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/mm.h | 6 ++++++
mm/filemap.c | 12 +++---------
mm/readahead.c | 19 +++++++++----------
3 files changed, 18 insertions(+), 19 deletions(-)
--- linux-2.6.17-mm1-full/include/linux/mm.h.old 2006-06-22 22:04:21.000000000 +0200
+++ linux-2.6.17-mm1-full/include/linux/mm.h 2006-06-22 22:09:13.000000000 +0200
@@ -1062,6 +1062,12 @@
#endif
}
+#ifdef CONFIG_DEBUG_READAHEAD
+extern u32 readahead_debug_level;
+#else
+#define readahead_debug_level 0
+#endif /* CONFIG_DEBUG_READAHEAD */
+
/* Do stack extension */
extern int expand_stack(struct vm_area_struct *vma, unsigned long address);
#ifdef CONFIG_IA64
--- linux-2.6.17-mm1-full/mm/readahead.c.old 2006-06-22 20:57:07.000000000 +0200
+++ linux-2.6.17-mm1-full/mm/readahead.c 2006-06-23 00:31:25.000000000 +0200
@@ -102,10 +102,10 @@
};
#ifdef CONFIG_DEBUG_READAHEAD
-u32 initial_ra_hit;
-u32 initial_ra_miss;
-u32 debug_level = 1;
-u32 disable_stateful_method = 0;
+static u32 initial_ra_hit;
+static u32 initial_ra_miss;
+u32 readahead_debug_level = 1;
+static u32 disable_stateful_method = 0;
static const char * const ra_class_name[];
static void ra_account(struct file_ra_state *ra, enum ra_event e, int pages);
# define debug_inc(var) do { var++; } while (0)
@@ -114,13 +114,12 @@
# define ra_account(ra, e, pages) do { } while (0)
# define debug_inc(var) do { } while (0)
# define debug_option(o) (0)
-# define debug_level (0)
#endif /* CONFIG_DEBUG_READAHEAD */
#define dprintk(args...) \
- do { if (debug_level >= 2) printk(KERN_DEBUG args); } while(0)
+ do { if (readahead_debug_level >= 2) printk(KERN_DEBUG args); } while(0)
#define ddprintk(args...) \
- do { if (debug_level >= 3) printk(KERN_DEBUG args); } while(0)
+ do { if (readahead_debug_level >= 3) printk(KERN_DEBUG args); } while(0)
void default_unplug_io_fn(struct backing_dev_info *bdi, struct page *page)
{
@@ -2011,7 +2010,7 @@
{
enum ra_class c;
- if (!debug_level)
+ if (!readahead_debug_level)
return;
if (e == RA_EVENT_READAHEAD_HIT && pages < 0) {
@@ -2142,7 +2141,7 @@
return 1;
}
-struct file_operations ra_events_fops = {
+static struct file_operations ra_events_fops = {
.owner = THIS_MODULE,
.open = ra_events_open,
.write = ra_events_write,
@@ -2168,7 +2167,7 @@
READAHEAD_DEBUGFS_ENTRY_U32(initial_ra_hit);
READAHEAD_DEBUGFS_ENTRY_U32(initial_ra_miss);
- READAHEAD_DEBUGFS_ENTRY_U32(debug_level);
+ debugfs_create_u32("debug_level", 0644, root, &readahead_debug_level);
READAHEAD_DEBUGFS_ENTRY_BOOL(disable_stateful_method);
return 0;
--- linux-2.6.17-mm1-full/mm/filemap.c.old 2006-06-22 22:03:34.000000000 +0200
+++ linux-2.6.17-mm1-full/mm/filemap.c 2006-06-22 22:06:37.000000000 +0200
@@ -45,12 +45,6 @@
generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
loff_t offset, unsigned long nr_segs);
-#ifdef CONFIG_DEBUG_READAHEAD
-extern u32 debug_level;
-#else
-#define debug_level 0
-#endif /* CONFIG_DEBUG_READAHEAD */
-
/*
* Shared mappings implemented 30.11.1994. It's not fully working yet,
* though.
@@ -937,7 +931,7 @@
if (!isize)
goto out;
- if (debug_level >= 5)
+ if (readahead_debug_level >= 5)
printk(KERN_DEBUG "read-file(ino=%lu, req=%lu+%lu)\n",
inode->i_ino, index, last_index - index);
@@ -995,7 +989,7 @@
if (prefer_adaptive_readahead())
readahead_cache_hit(&ra, page);
- if (debug_level >= 7)
+ if (readahead_debug_level >= 7)
printk(KERN_DEBUG "read-page(ino=%lu, idx=%lu, io=%s)\n",
inode->i_ino, index,
PageUptodate(page) ? "hit" : "miss");
@@ -1524,7 +1518,7 @@
if (prefer_adaptive_readahead())
readahead_cache_hit(ra, page);
- if (debug_level >= 6)
+ if (readahead_debug_level >= 6)
printk(KERN_DEBUG "read-mmap(ino=%lu, idx=%lu, hint=%s, io=%s)\n",
inode->i_ino, pgoff,
VM_RandomReadHint(area) ? "random" :
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: [-mm patch] mm/readahead.c: cleanups
2006-06-23 10:56 ` [-mm patch] mm/readahead.c: cleanups Adrian Bunk
@ 2006-06-24 6:00 ` Andrew Morton
0 siblings, 0 replies; 132+ messages in thread
From: Andrew Morton @ 2006-06-24 6:00 UTC (permalink / raw)
To: Adrian Bunk; +Cc: wfg, linux-kernel
On Fri, 23 Jun 2006 12:56:17 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> This patch contains the following cleanups:
> - make needlessly global code static
> - rename the global variable debug_level (sic) to readahead_debug_level
> - proper extern declaration for readahead_debug_level in
> include/linux/mm.h
>
I can't really use this, since it sprinkles changes all over the patch
series. Three separate patches would have been better, although even that
would be a hassle.
Anyway, I just edited the diffs, got most of it.
What does this
- READAHEAD_DEBUGFS_ENTRY_U32(debug_level);
+ debugfs_create_u32("debug_level", 0644, root, &readahead_debug_level);
do?
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (27 preceding siblings ...)
2006-06-23 10:56 ` [-mm patch] mm/readahead.c: cleanups Adrian Bunk
@ 2006-06-23 12:33 ` Michal Piotrowski
2006-06-23 20:42 ` 2.6.17-mm1 Andrew Morton
2006-06-23 15:48 ` 2.6.17-mm1 Eduard Bloch
2006-06-23 20:39 ` 2.6.17-mm1 Keith Mannthey
30 siblings, 1 reply; 132+ messages in thread
From: Michal Piotrowski @ 2006-06-23 12:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, Arjan van de Ven, linux-kernel
Hi,
On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>
Firefox 2 - a new testing tool for bug hunters.
Jun 23 11:03:48 ltg01-fedora kernel: =======================================
Jun 23 11:03:48 ltg01-fedora kernel: [ INFO: out of order unlock detected. ]
Jun 23 11:03:48 ltg01-fedora kernel: ---------------------------------------
Jun 23 11:03:48 ltg01-fedora kernel: The code is fine but needs lock
validator annotation.
Jun 23 11:03:48 ltg01-fedora kernel: firefox-bin/25734 is trying to
release lock (tasklist_lock) at:
Jun 23 11:03:48 ltg01-fedora kernel: [<c017b02c>] flush_old_exec+0x12f/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel: but the next lock to release is:
Jun 23 11:03:48 ltg01-fedora kernel: (&sighand->siglock){++..}, at:
[<c017afab>] flush_old_exec+0xae/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:
Jun 23 11:03:48 ltg01-fedora kernel: other info that might help us debug this:
Jun 23 11:03:48 ltg01-fedora kernel: 2 locks held by firefox-bin/25734:
Jun 23 11:03:48 ltg01-fedora kernel: #0: (tasklist_lock){..??}, at:
[<c017afa4>] flush_old_exec+0xa7/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel: #1: (&sighand->siglock){++..},
at: [<c017afab>] flush_old_exec+0xae/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:
Jun 23 11:03:48 ltg01-fedora kernel: stack backtrace:
Jun 23 11:03:48 ltg01-fedora kernel: [<c0103e89>] show_trace+0xd/0x10
Jun 23 11:03:48 ltg01-fedora kernel: [<c0104483>] dump_stack+0x19/0x1b
Jun 23 11:03:48 ltg01-fedora kernel: [<c0139c52>] lock_release+0x19a/0x371
Jun 23 11:03:48 ltg01-fedora kernel: [<c02f1148>] _read_unlock+0x16/0x46
Jun 23 11:03:48 ltg01-fedora kernel: [<c017b02c>] flush_old_exec+0x12f/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel: [<c019b698>] load_elf_binary+0x4c8/0x15f4
Jun 23 11:03:48 ltg01-fedora kernel: [<c017a8e1>]
search_binary_handler+0xfc/0x32b
Jun 23 11:03:48 ltg01-fedora kernel: [<c017c533>] do_execve+0x16c/0x225
Jun 23 11:03:48 ltg01-fedora kernel: [<c01016e1>] sys_execve+0x3a/0x8b
Jun 23 11:03:48 ltg01-fedora kernel: [<c02f157d>] sysenter_past_esp+0x56/0x8d
Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 12:33 ` 2.6.17-mm1 Michal Piotrowski
@ 2006-06-23 20:42 ` Andrew Morton
0 siblings, 0 replies; 132+ messages in thread
From: Andrew Morton @ 2006-06-23 20:42 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: mingo, arjan, linux-kernel
On Fri, 23 Jun 2006 14:33:27 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> Hi,
>
> On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> >
>
> Firefox 2 - a new testing tool for bug hunters.
Thanks.
> Jun 23 11:03:48 ltg01-fedora kernel: =======================================
> Jun 23 11:03:48 ltg01-fedora kernel: [ INFO: out of order unlock detected. ]
> Jun 23 11:03:48 ltg01-fedora kernel: ---------------------------------------
This test is a bit of a nuisance.
> Jun 23 11:03:48 ltg01-fedora kernel: The code is fine but needs lock
> validator annotation.
> Jun 23 11:03:48 ltg01-fedora kernel: firefox-bin/25734 is trying to
> release lock (tasklist_lock) at:
> Jun 23 11:03:48 ltg01-fedora kernel: [<c017b02c>] flush_old_exec+0x12f/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel: but the next lock to release is:
> Jun 23 11:03:48 ltg01-fedora kernel: (&sighand->siglock){++..}, at:
> [<c017afab>] flush_old_exec+0xae/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel:
> Jun 23 11:03:48 ltg01-fedora kernel: other info that might help us debug this:
> Jun 23 11:03:48 ltg01-fedora kernel: 2 locks held by firefox-bin/25734:
> Jun 23 11:03:48 ltg01-fedora kernel: #0: (tasklist_lock){..??}, at:
> [<c017afa4>] flush_old_exec+0xa7/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel: #1: (&sighand->siglock){++..},
> at: [<c017afab>] flush_old_exec+0xae/0xa5f
This is de_thread(). It's deliberate.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (28 preceding siblings ...)
2006-06-23 12:33 ` 2.6.17-mm1 Michal Piotrowski
@ 2006-06-23 15:48 ` Eduard Bloch
2006-06-23 16:42 ` 2.6.17-mm1 Jiri Slaby
2006-06-23 20:39 ` 2.6.17-mm1 Keith Mannthey
30 siblings, 1 reply; 132+ messages in thread
From: Eduard Bloch @ 2006-06-23 15:48 UTC (permalink / raw)
To: linux-kernel
#include <hallo.h>
* Andrew Morton [Wed, Jun 21 2006, 03:48:57AM]:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
Cannot build it. Looks like the build system is looping over:
GEN usr/klibc/syscalls/typesize.c
KLIBCCC usr/klibc/syscalls/typesize.o
OBJCOPY usr/klibc/syscalls/typesize.bin
GEN usr/klibc/syscalls/syscalls.mk
GEN usr/klibc/syscalls/typesize.c
KLIBCCC usr/klibc/syscalls/typesize.o
OBJCOPY usr/klibc/syscalls/typesize.bin
GEN usr/klibc/syscalls/syscalls.mk
GEN usr/klibc/syscalls/typesize.c
KLIBCCC usr/klibc/syscalls/typesize.o
OBJCOPY usr/klibc/syscalls/typesize.bin
GEN usr/klibc/syscalls/syscalls.mk
GEN usr/klibc/syscalls/typesize.c
KLIBCCC usr/klibc/syscalls/typesize.o
OBJCOPY usr/klibc/syscalls/typesize.bin
GEN usr/klibc/syscalls/syscalls.mk
No matter whether executed as user or as root. Setting KBUILD_VERBOSE
does not help much, for the log see http://people.debian.org/~blade/log .
Eduard.
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 15:48 ` 2.6.17-mm1 Eduard Bloch
@ 2006-06-23 16:42 ` Jiri Slaby
0 siblings, 0 replies; 132+ messages in thread
From: Jiri Slaby @ 2006-06-23 16:42 UTC (permalink / raw)
To: Eduard Bloch; +Cc: linux-kernel
Eduard Bloch napsal(a):
> #include <hallo.h>
> * Andrew Morton [Wed, Jun 21 2006, 03:48:57AM]:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>
> Cannot build it. Looks like the build system is looping over:
>
> GEN usr/klibc/syscalls/typesize.c
> KLIBCCC usr/klibc/syscalls/typesize.o
> OBJCOPY usr/klibc/syscalls/typesize.bin
> GEN usr/klibc/syscalls/syscalls.mk
> GEN usr/klibc/syscalls/typesize.c
> KLIBCCC usr/klibc/syscalls/typesize.o
> OBJCOPY usr/klibc/syscalls/typesize.bin
> GEN usr/klibc/syscalls/syscalls.mk
> GEN usr/klibc/syscalls/typesize.c
> KLIBCCC usr/klibc/syscalls/typesize.o
> OBJCOPY usr/klibc/syscalls/typesize.bin
> GEN usr/klibc/syscalls/syscalls.mk
> GEN usr/klibc/syscalls/typesize.c
> KLIBCCC usr/klibc/syscalls/typesize.o
> OBJCOPY usr/klibc/syscalls/typesize.bin
> GEN usr/klibc/syscalls/syscalls.mk
>
> No matter whether executed as user or as root. Setting KBUILD_VERBOSE
> does not help much, for the log see http://people.debian.org/~blade/log .
Should be fixed already:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115091547426482&w=2
regards,
--
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ jirislaby@gmail.com _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-21 10:48 2.6.17-mm1 Andrew Morton
` (29 preceding siblings ...)
2006-06-23 15:48 ` 2.6.17-mm1 Eduard Bloch
@ 2006-06-23 20:39 ` Keith Mannthey
2006-06-23 21:32 ` 2.6.17-mm1 Andrew Morton
30 siblings, 1 reply; 132+ messages in thread
From: Keith Mannthey @ 2006-06-23 20:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew,
When I make mrproper to clean the kernel tree with the -mm trees (at
least the last few releases) I end up having to remove
/include/linux/dwarf2-defs.h myself. This file is generated at build
time but mrproper isn't cleaning it up. This file is always present
in a tree that has been built but not in the origninal tree so a diff
of the tree picks it up.
Is this expected?
Thanks,
Keith
^ permalink raw reply [flat|nested] 132+ messages in thread* Re: 2.6.17-mm1
2006-06-23 20:39 ` 2.6.17-mm1 Keith Mannthey
@ 2006-06-23 21:32 ` Andrew Morton
2006-06-24 21:27 ` 2.6.17-mm1 Sam Ravnborg
0 siblings, 1 reply; 132+ messages in thread
From: Andrew Morton @ 2006-06-23 21:32 UTC (permalink / raw)
To: Keith Mannthey; +Cc: linux-kernel, Sam Ravnborg
On Fri, 23 Jun 2006 13:39:01 -0700
"Keith Mannthey" <kmannth@gmail.com> wrote:
> Andrew,
> When I make mrproper to clean the kernel tree with the -mm trees (at
> least the last few releases) I end up having to remove
> /include/linux/dwarf2-defs.h myself. This file is generated at build
> time but mrproper isn't cleaning it up. This file is always present
> in a tree that has been built but not in the origninal tree so a diff
> of the tree picks it up.
>
> Is this expected?
>
No, it's not expected. That's due to the kgdb patches.
Sam, what should we be doing here?
Thanks.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-23 21:32 ` 2.6.17-mm1 Andrew Morton
@ 2006-06-24 21:27 ` Sam Ravnborg
2006-06-24 21:53 ` 2.6.17-mm1 Andrew Morton
0 siblings, 1 reply; 132+ messages in thread
From: Sam Ravnborg @ 2006-06-24 21:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: Keith Mannthey, linux-kernel
On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> On Fri, 23 Jun 2006 13:39:01 -0700
> "Keith Mannthey" <kmannth@gmail.com> wrote:
>
> > Andrew,
> > When I make mrproper to clean the kernel tree with the -mm trees (at
> > least the last few releases) I end up having to remove
> > /include/linux/dwarf2-defs.h myself. This file is generated at build
> > time but mrproper isn't cleaning it up. This file is always present
> > in a tree that has been built but not in the origninal tree so a diff
> > of the tree picks it up.
> >
> > Is this expected?
> >
>
> No, it's not expected. That's due to the kgdb patches.
>
> Sam, what should we be doing here?
The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
before starting to build the kernel.
So the only same solution would be to move it all to the Kbuild file in
the top-level directory. Then we should also let same Kbuild file take
care of cleaning up.
I noticed that kgdb patches was dropped in -mm this time.
Shall I try to cook up a patch next time you include kgdb?
Sam
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-24 21:27 ` 2.6.17-mm1 Sam Ravnborg
@ 2006-06-24 21:53 ` Andrew Morton
2006-07-02 18:54 ` 2.6.17-mm1 Tom Rini
0 siblings, 1 reply; 132+ messages in thread
From: Andrew Morton @ 2006-06-24 21:53 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: kmannth, linux-kernel, Tom Rini
On Sat, 24 Jun 2006 23:27:06 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:
> On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> > On Fri, 23 Jun 2006 13:39:01 -0700
> > "Keith Mannthey" <kmannth@gmail.com> wrote:
> >
> > > Andrew,
> > > When I make mrproper to clean the kernel tree with the -mm trees (at
> > > least the last few releases) I end up having to remove
> > > /include/linux/dwarf2-defs.h myself. This file is generated at build
> > > time but mrproper isn't cleaning it up. This file is always present
> > > in a tree that has been built but not in the origninal tree so a diff
> > > of the tree picks it up.
> > >
> > > Is this expected?
> > >
> >
> > No, it's not expected. That's due to the kgdb patches.
> >
> > Sam, what should we be doing here?
>
> The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
> before starting to build the kernel.
> So the only same solution would be to move it all to the Kbuild file in
> the top-level directory. Then we should also let same Kbuild file take
> care of cleaning up.
>
> I noticed that kgdb patches was dropped in -mm this time.
> Shall I try to cook up a patch next time you include kgdb?
>
I wouldn't bother, really - we have bigger fish to fry.
I cc'ed Tom, who might care to take a look at it sometime.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 2.6.17-mm1
2006-06-24 21:53 ` 2.6.17-mm1 Andrew Morton
@ 2006-07-02 18:54 ` Tom Rini
0 siblings, 0 replies; 132+ messages in thread
From: Tom Rini @ 2006-07-02 18:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Sam Ravnborg, kmannth, linux-kernel
On Sat, Jun 24, 2006 at 02:53:05PM -0700, Andrew Morton wrote:
> On Sat, 24 Jun 2006 23:27:06 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> > > On Fri, 23 Jun 2006 13:39:01 -0700
> > > "Keith Mannthey" <kmannth@gmail.com> wrote:
> > >
> > > > Andrew,
> > > > When I make mrproper to clean the kernel tree with the -mm trees (at
> > > > least the last few releases) I end up having to remove
> > > > /include/linux/dwarf2-defs.h myself. This file is generated at build
> > > > time but mrproper isn't cleaning it up. This file is always present
> > > > in a tree that has been built but not in the origninal tree so a diff
> > > > of the tree picks it up.
> > > >
> > > > Is this expected?
> > > >
> > >
> > > No, it's not expected. That's due to the kgdb patches.
> > >
> > > Sam, what should we be doing here?
> >
> > The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
> > before starting to build the kernel.
> > So the only same solution would be to move it all to the Kbuild file in
> > the top-level directory. Then we should also let same Kbuild file take
> > care of cleaning up.
> >
> > I noticed that kgdb patches was dropped in -mm this time.
> > Shall I try to cook up a patch next time you include kgdb?
> >
>
> I wouldn't bother, really - we have bigger fish to fry.
Just got back from a holiday, catching up on things now.
I _thought_ this had been fixed, but it may have been after Andrew
grabbed the patches last, I'll double check soon.
--
Tom Rini
^ permalink raw reply [flat|nested] 132+ messages in thread