* [PATCH] Require mmap handler for a.out executables (was Re: 2.6.18-rc2-mm1)
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
@ 2006-07-27 10:27 ` Eugene Teo
2006-07-27 11:40 ` [patch -mm] s390: remove s390 touch_nmi_watchdog() define Heiko Carstens
` (18 subsequent siblings)
19 siblings, 0 replies; 107+ messages in thread
From: Eugene Teo @ 2006-07-27 10:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Marcel Holtmann
Hi Andrew,
Andrew Morton wrote:
[snipped]
> - Lots of random patches. Many of them are bugfixes and I shall, as usual,
> go through them all identifying 2.6.18 material. But I can miss things, so
> please don't be afraid to point 2.6.18 candidates out to me.
[snipped]
The following patch provides better protection against people exploiting stuff
in /proc and I hope you consider it for upstream inclusion.
Thanks.
Eugene
[PATCH] Require mmap handler for a.out executables
Files supported by fs/proc/base.c, i.e. /proc/<pid>/*, are not capable
of meeting the validity checks in ELF load_elf_*() handling because they
have no mmap handler which is required by ELF. In order to stop a.out
executables being used as part of an exploit attack against /proc-related
vulnerabilities, we make a.out executables depend on ->mmap() existing.
Signed-off-by: Eugene Teo <eteo@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
commit 1597cf8405734e4747c808bb7e04115a6670dccf
tree 49050549aee6406dab0c021c5aa4e9bfc337bd8f
parent 44eb123126d289bac398cac0232309c228386671
author Marcel Holtmann <marcel@holtmann.org> Wed, 26 Jul 2006 12:12:14 +0200
committer Marcel Holtmann <marcel@holtmann.org> Wed, 26 Jul 2006 12:12:14 +0200
fs/binfmt_aout.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index f312103..5638acf 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -278,6 +278,9 @@ static int load_aout_binary(struct linux
return -ENOEXEC;
}
+ if (!bprm->file->f_op || !bprm->file->f_op->mmap)
+ return -ENOEXEC;
+
fd_offset = N_TXTOFF(ex);
/* Check initial limits. This avoids letting people circumvent
@@ -476,6 +479,9 @@ static int load_aout_library(struct file
goto out;
}
+ if (!file->f_op || !file->f_op->mmap)
+ goto out;
+
if (N_FLAGS(ex))
goto out;
--
eteo redhat.com ph: +65 6490 4142 http://www.kernel.org/~eugeneteo
gpg fingerprint: 47B9 90F6 AE4A 9C51 37E0 D6E1 EA84 C6A2 58DF 8823
^ permalink raw reply related [flat|nested] 107+ messages in thread* [patch -mm] s390: remove s390 touch_nmi_watchdog() define
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
2006-07-27 10:27 ` [PATCH] Require mmap handler for a.out executables (was Re: 2.6.18-rc2-mm1) Eugene Teo
@ 2006-07-27 11:40 ` Heiko Carstens
2006-07-27 12:26 ` 2.6.18-rc2-mm1 Frederik Deweerdt
` (17 subsequent siblings)
19 siblings, 0 replies; 107+ messages in thread
From: Heiko Carstens @ 2006-07-27 11:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Martin Schwidefsky
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Remove s390 touch_nmi_watchdog() define to avoid compile warnings.
touch_nmi_watchdog() got converted to touch_softlockup_watchdog() which
in case of !CONFIG_DETECT_SOFTLOCKUP is also a nop, just like we want it
on s390.
In file included from kernel/sched.c:23:
include/linux/nmi.h:20:1: warning: "touch_nmi_watchdog" redefined
In file included from include/linux/nmi.h:8,
from kernel/sched.c:23:
include/asm/irq.h:22:1: warning: this is the location of the previous definition
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
include/asm-s390/irq.h | 3 ---
1 files changed, 3 deletions(-)
Index: linux-2.6.18-rc2-mm1/include/asm-s390/irq.h
===================================================================
--- linux-2.6.18-rc2-mm1.orig/include/asm-s390/irq.h 2006-07-27 13:25:11.000000000 +0200
+++ linux-2.6.18-rc2-mm1/include/asm-s390/irq.h 2006-07-27 13:34:53.000000000 +0200
@@ -19,8 +19,5 @@
NR_IRQS,
};
-#define touch_nmi_watchdog() do { } while(0)
-
#endif /* __KERNEL__ */
#endif
-
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
2006-07-27 10:27 ` [PATCH] Require mmap handler for a.out executables (was Re: 2.6.18-rc2-mm1) Eugene Teo
2006-07-27 11:40 ` [patch -mm] s390: remove s390 touch_nmi_watchdog() define Heiko Carstens
@ 2006-07-27 12:26 ` Frederik Deweerdt
2006-07-27 12:39 ` [patch] fix "efi_init_e820_map undefined" warning Frederik Deweerdt
2006-07-27 13:12 ` Should cpuset ABBA deadlock fix be in 2.6.18-rc2-mmx? Paul Jackson
` (16 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-27 12:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, hostmaster
On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
Hi,
Compiling on i386 without the CONFIG_EFI enabled complains because it can't find
efi_init_e820_map prototype:
arch/i386/kernel/setup.c: In function `setup_arch':
arch/i386/kernel/setup.c:1560: warning: implicit declaration of function `efi_init_e820_map'
The attached corrects this, and also makes efi_init_e820_map static.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
--- v2.6.18-rc2-mm1~ori/arch/i386/kernel/setup.c 2006-07-27 11:46:05.000000000 +0200
+++ v2.6.18-rc2-mm1/arch/i386/kernel/setup.c 2006-07-27 11:51:02.000000000 +0200
@@ -1453,7 +1453,7 @@ static void set_mca_bus(int x) { }
/*
* Make a e820 memory map
*/
-void __init efi_init_e820_map(void)
+static void __init efi_init_e820_map(void)
{
efi_memory_desc_t *md;
unsigned long long start = 0;
@@ -1505,7 +1505,9 @@ void __init efi_init_e820_map(void)
}
}
}
-#endif
+#else
+static void __init efi_init_e820_map(void) { }
+#endif /* CONFIG_EFI */
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
^ permalink raw reply [flat|nested] 107+ messages in thread* [patch] fix "efi_init_e820_map undefined" warning
2006-07-27 12:26 ` 2.6.18-rc2-mm1 Frederik Deweerdt
@ 2006-07-27 12:39 ` Frederik Deweerdt
0 siblings, 0 replies; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-27 12:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, hostmaster
On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
(Sorry for the resend, I forgot to add a proper subject line)
Hi,
Compiling on i386 without the CONFIG_EFI enabled complains because it can't find
efi_init_e820_map prototype:
arch/i386/kernel/setup.c: In function `setup_arch':
arch/i386/kernel/setup.c:1560: warning: implicit declaration of function `efi_init_e820_map'
The attached corrects this, and also makes efi_init_e820_map static.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
--- v2.6.18-rc2-mm1~ori/arch/i386/kernel/setup.c 2006-07-27 11:46:05.000000000 +0200
+++ v2.6.18-rc2-mm1/arch/i386/kernel/setup.c 2006-07-27 11:51:02.000000000 +0200
@@ -1453,7 +1453,7 @@ static void set_mca_bus(int x) { }
/*
* Make a e820 memory map
*/
-void __init efi_init_e820_map(void)
+static void __init efi_init_e820_map(void)
{
efi_memory_desc_t *md;
unsigned long long start = 0;
@@ -1505,7 +1505,9 @@ void __init efi_init_e820_map(void)
}
}
}
-#endif
+#else
+static void __init efi_init_e820_map(void) { }
+#endif /* CONFIG_EFI */
/*
* Determine if we were loaded by an EFI loader. If so, then we have also been
^ permalink raw reply [flat|nested] 107+ messages in thread
* Should cpuset ABBA deadlock fix be in 2.6.18-rc2-mmx?
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-07-27 12:26 ` 2.6.18-rc2-mm1 Frederik Deweerdt
@ 2006-07-27 13:12 ` Paul Jackson
2006-07-27 18:22 ` Andrew Morton
2006-07-27 13:32 ` 2.6.18-rc2-mm1 Michal Piotrowski
` (15 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Paul Jackson @ 2006-07-27 13:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
I'd like to encourage including the patch:
Cpuset: fix ABBA deadlock with cpu hotplug lock
in 2.6.18-rc2-mmx. This patch was sent to lkml,
copied to akpm, 14 July. It was sent again to lkml,
in response to a request for a copy from Linus, on
23 July, copied again to akpm.
Granted, the case for including it is not absolute.
The fix is simple enough and fixes a definite deadlock,
as verified by testing results on the system that was
seeing this deadlock.
However ... only one system, world-wide, has the magic
workload to provoke this deadlock, so far. And it involves
the cpu hotplug lock, which perhaps Linus would like to
nuke entirely.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (3 preceding siblings ...)
2006-07-27 13:12 ` Should cpuset ABBA deadlock fix be in 2.6.18-rc2-mmx? Paul Jackson
@ 2006-07-27 13:32 ` Michal Piotrowski
2006-07-27 18:59 ` 2.6.18-rc2-mm1 Michal Piotrowski
2006-07-28 8:17 ` 2.6.18-rc2-mm1 Michal Piotrowski
2006-07-27 14:04 ` 2.6.18-rc2-mm1 Andy Whitcroft
` (14 subsequent siblings)
19 siblings, 2 replies; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-27 13:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi Andrew,
On 27/07/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
It appears while /sbin/start_udev
Jul 27 15:17:17 ltg01-fedora kernel: BUG: unable to handle kernel
paging request at virtual address 6b6b6c07
Jul 27 15:17:17 ltg01-fedora kernel: printing eip:
Jul 27 15:17:17 ltg01-fedora kernel: c0138722
Jul 27 15:17:17 ltg01-fedora kernel: *pde = 00000000
Jul 27 15:17:17 ltg01-fedora kernel: Oops: 0002 [#1]
Jul 27 15:17:17 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
Jul 27 15:17:17 ltg01-fedora kernel: last sysfs file:
/devices/pci0000:00/0000:00:1d.7/uevent
Jul 27 15:17:17 ltg01-fedora kernel: Modules linked in: snd_timer snd
soundcore snd_page_alloc intel_agp agpgart ide_cd cdrom ipv6 w83627hf
hwmon_vid hwmon i2c_isa i2c_i801 skge af_packet
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink
xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace
p4_clockmod speedstep_lib binfmt_misc thermal processor fan container
rtc unix
Jul 27 15:17:17 ltg01-fedora kernel: CPU: 0
Jul 27 15:17:17 ltg01-fedora kernel: EIP: 0060:[<c0138722>] Not
tainted VLI
Jul 27 15:17:17 ltg01-fedora kernel: EFLAGS: 00010046 (2.6.18-rc2-mm1 #78)
Jul 27 15:17:17 ltg01-fedora kernel: EIP is at __lock_acquire+0x362/0xaea
Jul 27 15:17:17 ltg01-fedora kernel: eax: 00000000 ebx: 6b6b6b6b
ecx: c0360358 edx: 00000000
Jul 27 15:17:17 ltg01-fedora kernel: esi: 00000000 edi: 00000000
ebp: f544ddf4 esp: f544ddc0
Jul 27 15:17:17 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
Jul 27 15:17:17 ltg01-fedora kernel: Process udevd (pid: 1353,
ti=f544d000 task=f6fce8f0 task.ti=f544d000)
Jul 27 15:17:17 ltg01-fedora kernel: Stack: 00000000 00000000 00000000
c7749ea4 f6fce8f0 c0138e74 000001e8 00000000
Jul 27 15:17:17 ltg01-fedora kernel: 00000000 f6653fa4 00000246
00000000 00000000 f544de1c c0139214 00000000
Jul 27 15:17:17 ltg01-fedora kernel: 00000002 00000000 c014fe3a
c7749ea4 c7749e90 f6fce8f0 f5b19b04 f544de34
Jul 27 15:17:17 ltg01-fedora kernel: Call Trace:
Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:17 ltg01-fedora kernel: DWARF2 unwinder stuck at
sysenter_past_esp+0x56/0x8d
Jul 27 15:17:17 ltg01-fedora kernel: Leftover inexact backtrace:
Jul 27 15:17:17 ltg01-fedora kernel: [<c0104318>] show_stack_log_lvl+0x8c/0x97
Jul 27 15:17:17 ltg01-fedora kernel: [<c010447f>] show_registers+0x15c/0x1ed
Jul 27 15:17:17 ltg01-fedora kernel: [<c01046c2>] die+0x1b2/0x2b7
Jul 27 15:17:17 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:17 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:17 ltg01-fedora kernel: Code: 68 4b 75 2f c0 68 d5 04 00
00 68 b9 75 31 c0 68 e3 06 31 c0 e8 ce 7e fe ff e8 87 c2 fc ff 83 c4
10 eb 08 85 db 0f 84 6b 07 00 00 <f0> ff 83 9c 00 00 00 8b 55 dc 8b 92
5c 05 00 00 89 55 e4 83 fa
Jul 27 15:17:17 ltg01-fedora kernel: EIP: [<c0138722>]
__lock_acquire+0x362/0xaea SS:ESP 0068:f544ddc0
Jul 27 15:17:17 ltg01-fedora kernel: <3>BUG: sleeping function called
from invalid context at /usr/src/linux-mm/kernel/rwsem.c:20
Jul 27 15:17:17 ltg01-fedora kernel: in_atomic():1, irqs_disabled():1
Jul 27 15:17:17 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
Jul 27 15:17:17 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:17 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:17 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
Jul 27 15:17:17 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
Jul 27 15:17:17 ltg01-fedora kernel: [<c012cd93>]
blocking_notifier_call_chain+0x11/0x2d
Jul 27 15:17:17 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:17 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
Jul 27 15:17:18 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd93>]
blocking_notifier_call_chain+0x11/0x2d
Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:18 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:18 ltg01-fedora kernel: note: udevd[1353] exited with
preempt_count 1
Jul 27 15:17:18 ltg01-fedora kernel: BUG: scheduling while atomic:
udevd/0x00000001/1353
Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
__down_failed+0xa/0xe
Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
Jul 27 15:17:18 ltg01-fedora kernel: [<c02f32aa>]
.text.lock.kernel_lock+0x1b/0x3d
Jul 27 15:17:18 ltg01-fedora kernel: [<c023c881>] disassociate_ctty+0xd/0x16e
Jul 27 15:17:18 ltg01-fedora kernel: [<c0122d8d>] do_exit+0x452/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:18 ltg01-fedora kernel: slab error in
verify_redzone_free(): cache `delayacct_cache': double free detected
Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
cache_free_debugcheck+0xcc/0x1c7
Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
__delayacct_tsk_exit+0x38/0x3d
Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
delayacct_watch_task+0x5a/0x65
Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
blocking_notifier_call_chain+0x1d/0x2d
Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
cache_free_debugcheck+0xcc/0x1c7
Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
__delayacct_tsk_exit+0x38/0x3d
Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
delayacct_watch_task+0x5a/0x65
Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
blocking_notifier_call_chain+0x1d/0x2d
Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
Jul 27 15:17:18 ltg01-fedora kernel: [<c0123424>] sys_exit_group+0xf/0x11
Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
list *0xc0138722
0xc0138722 is in __lock_acquire (include2/asm/atomic.h:96).
91 *
92 * Atomically increments @v by 1.
93 */
94 static __inline__ void atomic_inc(atomic_t *v)
95 {
96 __asm__ __volatile__(
97 LOCK_PREFIX "incl %0"
98 :"+m" (v->counter));
99 }
100
http://www.stardust.webpages.pl/files/mm/2.6.18-rc2-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] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-27 13:32 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-27 18:59 ` Michal Piotrowski
2006-07-29 12:15 ` 2.6.18-rc2-mm1 Michal Piotrowski
2006-07-28 8:17 ` 2.6.18-rc2-mm1 Michal Piotrowski
1 sibling, 1 reply; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-27 18:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 27/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi Andrew,
>
> On 27/07/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> >
>
> It appears while /sbin/start_udev
>
> Jul 27 15:17:17 ltg01-fedora kernel: BUG: unable to handle kernel
> paging request at virtual address 6b6b6c07
> Jul 27 15:17:17 ltg01-fedora kernel: printing eip:
> Jul 27 15:17:17 ltg01-fedora kernel: c0138722
> Jul 27 15:17:17 ltg01-fedora kernel: *pde = 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: Oops: 0002 [#1]
> Jul 27 15:17:17 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> Jul 27 15:17:17 ltg01-fedora kernel: last sysfs file:
> /devices/pci0000:00/0000:00:1d.7/uevent
> Jul 27 15:17:17 ltg01-fedora kernel: Modules linked in: snd_timer snd
> soundcore snd_page_alloc intel_agp agpgart ide_cd cdrom ipv6 w83627hf
> hwmon_vid hwmon i2c_isa i2c_i801 skge af_packet
> ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink
> xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace
> p4_clockmod speedstep_lib binfmt_misc thermal processor fan container
> rtc unix
> Jul 27 15:17:17 ltg01-fedora kernel: CPU: 0
> Jul 27 15:17:17 ltg01-fedora kernel: EIP: 0060:[<c0138722>] Not
> tainted VLI
> Jul 27 15:17:17 ltg01-fedora kernel: EFLAGS: 00010046 (2.6.18-rc2-mm1 #78)
> Jul 27 15:17:17 ltg01-fedora kernel: EIP is at __lock_acquire+0x362/0xaea
> Jul 27 15:17:17 ltg01-fedora kernel: eax: 00000000 ebx: 6b6b6b6b
> ecx: c0360358 edx: 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: esi: 00000000 edi: 00000000
> ebp: f544ddf4 esp: f544ddc0
> Jul 27 15:17:17 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> Jul 27 15:17:17 ltg01-fedora kernel: Process udevd (pid: 1353,
> ti=f544d000 task=f6fce8f0 task.ti=f544d000)
> Jul 27 15:17:17 ltg01-fedora kernel: Stack: 00000000 00000000 00000000
> c7749ea4 f6fce8f0 c0138e74 000001e8 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: 00000000 f6653fa4 00000246
> 00000000 00000000 f544de1c c0139214 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: 00000002 00000000 c014fe3a
> c7749ea4 c7749e90 f6fce8f0 f5b19b04 f544de34
> Jul 27 15:17:17 ltg01-fedora kernel: Call Trace:
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:17 ltg01-fedora kernel: DWARF2 unwinder stuck at
> sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:17 ltg01-fedora kernel: Leftover inexact backtrace:
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0104318>] show_stack_log_lvl+0x8c/0x97
> Jul 27 15:17:17 ltg01-fedora kernel: [<c010447f>] show_registers+0x15c/0x1ed
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01046c2>] die+0x1b2/0x2b7
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:17 ltg01-fedora kernel: Code: 68 4b 75 2f c0 68 d5 04 00
> 00 68 b9 75 31 c0 68 e3 06 31 c0 e8 ce 7e fe ff e8 87 c2 fc ff 83 c4
> 10 eb 08 85 db 0f 84 6b 07 00 00 <f0> ff 83 9c 00 00 00 8b 55 dc 8b 92
> 5c 05 00 00 89 55 e4 83 fa
> Jul 27 15:17:17 ltg01-fedora kernel: EIP: [<c0138722>]
> __lock_acquire+0x362/0xaea SS:ESP 0068:f544ddc0
> Jul 27 15:17:17 ltg01-fedora kernel: <3>BUG: sleeping function called
> from invalid context at /usr/src/linux-mm/kernel/rwsem.c:20
> Jul 27 15:17:17 ltg01-fedora kernel: in_atomic():1, irqs_disabled():1
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
> Jul 27 15:17:17 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
> Jul 27 15:17:17 ltg01-fedora kernel: [<c012cd93>]
> blocking_notifier_call_chain+0x11/0x2d
> Jul 27 15:17:17 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
> error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
> Jul 27 15:17:18 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd93>]
> blocking_notifier_call_chain+0x11/0x2d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:18 ltg01-fedora kernel: note: udevd[1353] exited with
> preempt_count 1
> Jul 27 15:17:18 ltg01-fedora kernel: BUG: scheduling while atomic:
> udevd/0x00000001/1353
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
> Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
> __down_failed+0xa/0xe
> Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f32aa>]
> .text.lock.kernel_lock+0x1b/0x3d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c023c881>] disassociate_ctty+0xd/0x16e
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122d8d>] do_exit+0x452/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:18 ltg01-fedora kernel: slab error in
> verify_redzone_free(): cache `delayacct_cache': double free detected
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
> cache_free_debugcheck+0xcc/0x1c7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
> __delayacct_tsk_exit+0x38/0x3d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
> delayacct_watch_task+0x5a/0x65
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
> blocking_notifier_call_chain+0x1d/0x2d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
> cache_free_debugcheck+0xcc/0x1c7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
> __delayacct_tsk_exit+0x38/0x3d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
> delayacct_watch_task+0x5a/0x65
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
> blocking_notifier_call_chain+0x1d/0x2d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0123424>] sys_exit_group+0xf/0x11
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
>
> list *0xc0138722
> 0xc0138722 is in __lock_acquire (include2/asm/atomic.h:96).
> 91 *
> 92 * Atomically increments @v by 1.
> 93 */
> 94 static __inline__ void atomic_inc(atomic_t *v)
> 95 {
> 96 __asm__ __volatile__(
> 97 LOCK_PREFIX "incl %0"
> 98 :"+m" (v->counter));
> 99 }
> 100
>
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc2-mm1/mm-config
>
Bug is between
reducing-local_bh_enable-disable-overhead-in-irqtrace.patch
and
reiserfs-use-generic_file_open-for-open-checks.patch
(we could reject 5 reiserfs patches from suspects list)
Between
remove-incorrect-unlock_kernel-from-failure-path-in.patch
and
reiserfs-use-generic_file_open-for-open-checks.patch
I have noticed a lot of this bugs
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 224 bytes per conntrack
BUG: warning at /usr/src/linux-work1/kernel/cpu.c:51/unlock_cpu_hotplug()
[<c0103f0a>] show_trace_log_lvl+0x58/0x152
[<c010460e>] show_trace+0xd/0x10
[<c010472d>] dump_stack+0x19/0x1b
[<c013991e>] unlock_cpu_hotplug+0x2f/0x59
[<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
[<c0287c7e>] store+0x37/0x48
[<c0199cd3>] sysfs_write_file+0xa6/0xcc
[<c0167567>] vfs_write+0xab/0x157
[<c0167baa>] sys_write+0x3b/0x60
[<c0102ea1>] sysenter_past_esp+0x56/0x8d
DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
Leftover inexact backtrace:
[<c010460e>] show_trace+0xd/0x10
[<c010472d>] dump_stack+0x19/0x1b
[<c013991e>] unlock_cpu_hotplug+0x2f/0x59
[<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
[<c0287c7e>] store+0x37/0x48
[<c0199cd3>] sysfs_write_file+0xa6/0xcc
[<c0167567>] vfs_write+0xab/0x157
[<c0167baa>] sys_write+0x3b/0x60
[<c0102ea1>] sysenter_past_esp+0x56/0x8d
I'll finish this bisection later.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-27 18:59 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-29 12:15 ` Michal Piotrowski
2006-07-29 12:17 ` 2.6.18-rc2-mm1 Michal Piotrowski
0 siblings, 1 reply; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-29 12:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Dave Jones, linux-kernel
Hi Dave,
On 27/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Between
> remove-incorrect-unlock_kernel-from-failure-path-in.patch
> and
> reiserfs-use-generic_file_open-for-open-checks.patch
> I have noticed a lot of this bugs
I was wrong (as usually :)
git-cpufreq.patch is causing this error
> Netfilter messages via NETLINK v0.30.
> ip_conntrack version 2.4 (8192 buckets, 65536 max) - 224 bytes per conntrack
> BUG: warning at /usr/src/linux-work1/kernel/cpu.c:51/unlock_cpu_hotplug()
> [<c0103f0a>] show_trace_log_lvl+0x58/0x152
> [<c010460e>] show_trace+0xd/0x10
> [<c010472d>] dump_stack+0x19/0x1b
> [<c013991e>] unlock_cpu_hotplug+0x2f/0x59
> [<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
> [<c0287c7e>] store+0x37/0x48
> [<c0199cd3>] sysfs_write_file+0xa6/0xcc
> [<c0167567>] vfs_write+0xab/0x157
> [<c0167baa>] sys_write+0x3b/0x60
> [<c0102ea1>] sysenter_past_esp+0x56/0x8d
> DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
> Leftover inexact backtrace:
> [<c010460e>] show_trace+0xd/0x10
> [<c010472d>] dump_stack+0x19/0x1b
> [<c013991e>] unlock_cpu_hotplug+0x2f/0x59
> [<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
> [<c0287c7e>] store+0x37/0x48
> [<c0199cd3>] sysfs_write_file+0xa6/0xcc
> [<c0167567>] vfs_write+0xab/0x157
> [<c0167baa>] sys_write+0x3b/0x60
> [<c0102ea1>] sysenter_past_esp+0x56/0x8d
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-29 12:15 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-29 12:17 ` Michal Piotrowski
0 siblings, 0 replies; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-29 12:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: Dave Jones, linux-kernel
On 29/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi Dave,
>
> On 27/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Between
> > remove-incorrect-unlock_kernel-from-failure-path-in.patch
> > and
> > reiserfs-use-generic_file_open-for-open-checks.patch
> > I have noticed a lot of this bugs
>
> I was wrong (as usually :)
>
> git-cpufreq.patch is causing this error
>
> > Netfilter messages via NETLINK v0.30.
> > ip_conntrack version 2.4 (8192 buckets, 65536 max) - 224 bytes per conntrack
> > BUG: warning at /usr/src/linux-work1/kernel/cpu.c:51/unlock_cpu_hotplug()
> > [<c0103f0a>] show_trace_log_lvl+0x58/0x152
> > [<c010460e>] show_trace+0xd/0x10
> > [<c010472d>] dump_stack+0x19/0x1b
> > [<c013991e>] unlock_cpu_hotplug+0x2f/0x59
> > [<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
> > [<c0287c7e>] store+0x37/0x48
> > [<c0199cd3>] sysfs_write_file+0xa6/0xcc
> > [<c0167567>] vfs_write+0xab/0x157
> > [<c0167baa>] sys_write+0x3b/0x60
> > [<c0102ea1>] sysenter_past_esp+0x56/0x8d
> > DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
> > Leftover inexact backtrace:
> > [<c010460e>] show_trace+0xd/0x10
> > [<c010472d>] dump_stack+0x19/0x1b
> > [<c013991e>] unlock_cpu_hotplug+0x2f/0x59
> > [<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
> > [<c0287c7e>] store+0x37/0x48
> > [<c0199cd3>] sysfs_write_file+0xa6/0xcc
> > [<c0167567>] vfs_write+0xab/0x157
> > [<c0167baa>] sys_write+0x3b/0x60
> > [<c0102ea1>] sysenter_past_esp+0x56/0x8d
>
http://www.stardust.webpages.pl/files/mm/2.6.18-rc2-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] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-27 13:32 ` 2.6.18-rc2-mm1 Michal Piotrowski
2006-07-27 18:59 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-28 8:17 ` Michal Piotrowski
2006-07-28 8:34 ` 2.6.18-rc2-mm1 Andrew Morton
2006-07-28 17:57 ` 2.6.18-rc2-mm1 Matt Helsley
1 sibling, 2 replies; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-28 8:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: Matt Helsley, linux-kernel
Hi,
On 27/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi Andrew,
>
> On 27/07/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> >
>
> It appears while /sbin/start_udev
>
> Jul 27 15:17:17 ltg01-fedora kernel: BUG: unable to handle kernel
> paging request at virtual address 6b6b6c07
> Jul 27 15:17:17 ltg01-fedora kernel: printing eip:
> Jul 27 15:17:17 ltg01-fedora kernel: c0138722
> Jul 27 15:17:17 ltg01-fedora kernel: *pde = 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: Oops: 0002 [#1]
> Jul 27 15:17:17 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> Jul 27 15:17:17 ltg01-fedora kernel: last sysfs file:
> /devices/pci0000:00/0000:00:1d.7/uevent
> Jul 27 15:17:17 ltg01-fedora kernel: Modules linked in: snd_timer snd
> soundcore snd_page_alloc intel_agp agpgart ide_cd cdrom ipv6 w83627hf
> hwmon_vid hwmon i2c_isa i2c_i801 skge af_packet
> ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink
> xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace
> p4_clockmod speedstep_lib binfmt_misc thermal processor fan container
> rtc unix
> Jul 27 15:17:17 ltg01-fedora kernel: CPU: 0
> Jul 27 15:17:17 ltg01-fedora kernel: EIP: 0060:[<c0138722>] Not
> tainted VLI
> Jul 27 15:17:17 ltg01-fedora kernel: EFLAGS: 00010046 (2.6.18-rc2-mm1 #78)
> Jul 27 15:17:17 ltg01-fedora kernel: EIP is at __lock_acquire+0x362/0xaea
> Jul 27 15:17:17 ltg01-fedora kernel: eax: 00000000 ebx: 6b6b6b6b
> ecx: c0360358 edx: 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: esi: 00000000 edi: 00000000
> ebp: f544ddf4 esp: f544ddc0
> Jul 27 15:17:17 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> Jul 27 15:17:17 ltg01-fedora kernel: Process udevd (pid: 1353,
> ti=f544d000 task=f6fce8f0 task.ti=f544d000)
> Jul 27 15:17:17 ltg01-fedora kernel: Stack: 00000000 00000000 00000000
> c7749ea4 f6fce8f0 c0138e74 000001e8 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: 00000000 f6653fa4 00000246
> 00000000 00000000 f544de1c c0139214 00000000
> Jul 27 15:17:17 ltg01-fedora kernel: 00000002 00000000 c014fe3a
> c7749ea4 c7749e90 f6fce8f0 f5b19b04 f544de34
> Jul 27 15:17:17 ltg01-fedora kernel: Call Trace:
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:17 ltg01-fedora kernel: DWARF2 unwinder stuck at
> sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:17 ltg01-fedora kernel: Leftover inexact backtrace:
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0104318>] show_stack_log_lvl+0x8c/0x97
> Jul 27 15:17:17 ltg01-fedora kernel: [<c010447f>] show_registers+0x15c/0x1ed
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01046c2>] die+0x1b2/0x2b7
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:17 ltg01-fedora kernel: Code: 68 4b 75 2f c0 68 d5 04 00
> 00 68 b9 75 31 c0 68 e3 06 31 c0 e8 ce 7e fe ff e8 87 c2 fc ff 83 c4
> 10 eb 08 85 db 0f 84 6b 07 00 00 <f0> ff 83 9c 00 00 00 8b 55 dc 8b 92
> 5c 05 00 00 89 55 e4 83 fa
> Jul 27 15:17:17 ltg01-fedora kernel: EIP: [<c0138722>]
> __lock_acquire+0x362/0xaea SS:ESP 0068:f544ddc0
> Jul 27 15:17:17 ltg01-fedora kernel: <3>BUG: sleeping function called
> from invalid context at /usr/src/linux-mm/kernel/rwsem.c:20
> Jul 27 15:17:17 ltg01-fedora kernel: in_atomic():1, irqs_disabled():1
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:17 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
> Jul 27 15:17:17 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
> Jul 27 15:17:17 ltg01-fedora kernel: [<c012cd93>]
> blocking_notifier_call_chain+0x11/0x2d
> Jul 27 15:17:17 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:17 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
> error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
> Jul 27 15:17:18 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd93>]
> blocking_notifier_call_chain+0x11/0x2d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:18 ltg01-fedora kernel: note: udevd[1353] exited with
> preempt_count 1
> Jul 27 15:17:18 ltg01-fedora kernel: BUG: scheduling while atomic:
> udevd/0x00000001/1353
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
> Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
> __down_failed+0xa/0xe
> Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f32aa>]
> .text.lock.kernel_lock+0x1b/0x3d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c023c881>] disassociate_ctty+0xd/0x16e
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122d8d>] do_exit+0x452/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
> __delayacct_blkio_ticks+0x16/0x67
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> Jul 27 15:17:18 ltg01-fedora kernel: slab error in
> verify_redzone_free(): cache `delayacct_cache': double free detected
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
> cache_free_debugcheck+0xcc/0x1c7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
> __delayacct_tsk_exit+0x38/0x3d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
> delayacct_watch_task+0x5a/0x65
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
> blocking_notifier_call_chain+0x1d/0x2d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
> cache_free_debugcheck+0xcc/0x1c7
> Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
> Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
> __delayacct_tsk_exit+0x38/0x3d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
> delayacct_watch_task+0x5a/0x65
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
> blocking_notifier_call_chain+0x1d/0x2d
> Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0123424>] sys_exit_group+0xf/0x11
> Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
>
> list *0xc0138722
> 0xc0138722 is in __lock_acquire (include2/asm/atomic.h:96).
> 91 *
> 92 * Atomically increments @v by 1.
> 93 */
> 94 static __inline__ void atomic_inc(atomic_t *v)
> 95 {
> 96 __asm__ __volatile__(
> 97 LOCK_PREFIX "incl %0"
> 98 :"+m" (v->counter));
> 99 }
> 100
>
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc2-mm1/mm-config
>
Matt, can you look at this?
My hunt file shows me, that this patches are causing oops.
GOOD
#
#
task-watchers-task-watchers.patch
task-watchers-register-process-events-task-watcher.patch
task-watchers-refactor-process-events.patch
task-watchers-make-process-events-configurable-as.patch
task-watchers-allow-task-watchers-to-block.patch
task-watchers-register-audit-task-watcher.patch
task-watchers-register-per-task-delay-accounting.patch
task-watchers-register-profile-as-a-task-watcher.patch
task-watchers-add-support-for-per-task-watchers.patch
task-watchers-register-semundo-task-watcher.patch
task-watchers-register-per-task-semundo-watcher.patch
BAD
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-28 8:17 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-28 8:34 ` Andrew Morton
2006-07-28 18:49 ` 2.6.18-rc2-mm1 Matt Helsley
2006-07-28 17:57 ` 2.6.18-rc2-mm1 Matt Helsley
1 sibling, 1 reply; 107+ messages in thread
From: Andrew Morton @ 2006-07-28 8:34 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: matthltc, linux-kernel
On Fri, 28 Jul 2006 10:17:44 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> Matt, can you look at this?
>
> My hunt file shows me, that this patches are causing oops.
> GOOD
> #
> #
> task-watchers-task-watchers.patch
> task-watchers-register-process-events-task-watcher.patch
> task-watchers-refactor-process-events.patch
> task-watchers-make-process-events-configurable-as.patch
> task-watchers-allow-task-watchers-to-block.patch
> task-watchers-register-audit-task-watcher.patch
> task-watchers-register-per-task-delay-accounting.patch
> task-watchers-register-profile-as-a-task-watcher.patch
> task-watchers-add-support-for-per-task-watchers.patch
> task-watchers-register-semundo-task-watcher.patch
> task-watchers-register-per-task-semundo-watcher.patch
> BAD
Thanks for working that out.
I've actually been thinking that we shouldn't proceed with those patches.
They're a nice cleanup and make the kernel code _look_ better and I really
like them because of this. But the cost is potentially significant. We
replace N direct calls with a walk of a notifier chain, more than N
indirect calls, demultiplexing at the other end and then a direct call.
That's a significant amount of additional overhead to make the kernel
source look nicer.
Plus, ugly though it is, you can look at the current code and see what it's
doing. With a notifier chain you have to grep around the tree and work out
what might be hooking into the chain, which is harder.
Finally, the consolidation into a notifier chain forces all the
fork/exit/exec hooks into an one-size-fits-all model. What happens if one
subsystem wants to hook in before exit_mmap() and another one wants to hook
in after exit_mmap() (for example)?
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-28 8:34 ` 2.6.18-rc2-mm1 Andrew Morton
@ 2006-07-28 18:49 ` Matt Helsley
2006-07-28 19:53 ` 2.6.18-rc2-mm1 Michal Piotrowski
0 siblings, 1 reply; 107+ messages in thread
From: Matt Helsley @ 2006-07-28 18:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: Michal Piotrowski, LKML, Shailabh Nagar, Balbir Singh
On Fri, 2006-07-28 at 01:34 -0700, Andrew Morton wrote:
> On Fri, 28 Jul 2006 10:17:44 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> > Matt, can you look at this?
> >
> > My hunt file shows me, that this patches are causing oops.
> > GOOD
> > #
> > #
> > task-watchers-task-watchers.patch
> > task-watchers-register-process-events-task-watcher.patch
> > task-watchers-refactor-process-events.patch
> > task-watchers-make-process-events-configurable-as.patch
> > task-watchers-allow-task-watchers-to-block.patch
> > task-watchers-register-audit-task-watcher.patch
> > task-watchers-register-per-task-delay-accounting.patch
> > task-watchers-register-profile-as-a-task-watcher.patch
> > task-watchers-add-support-for-per-task-watchers.patch
> > task-watchers-register-semundo-task-watcher.patch
> > task-watchers-register-per-task-semundo-watcher.patch
> > BAD
>
> Thanks for working that out.
I noticed the delay accounting functions in the stack trace. Perhaps
task-watchers-register-per-task-delay-accounting.patch is causing the
problem. With all of the recent churn in per-task delay accounting I'm
wondering if that patch is still correct. Balbir, Shailabh, what do you
think?
> I've actually been thinking that we shouldn't proceed with those patches.
>
> They're a nice cleanup and make the kernel code _look_ better and I really
> like them because of this. But the cost is potentially significant. We
> replace N direct calls with a walk of a notifier chain, more than N
> indirect calls, demultiplexing at the other end and then a direct call.
> That's a significant amount of additional overhead to make the kernel
> source look nicer.
OK. The multiple notifier chain approach you suggested gets rid of
demultiplexing. We'd replace N direct calls with a walk of a notifier
chain and (more than??) N indirect calls.
An alternative suggested to me by Al Viro is to handle these functions
much like the *_initcall() macros in include/linux/init.h. This replaces
N direct calls with an array walk and N indirect calls. Unfortunately,
this does not work for modules.
> Plus, ugly though it is, you can look at the current code and see what it's
> doing. With a notifier chain you have to grep around the tree and work out
> what might be hooking into the chain, which is harder.
The same is true when using function pointers in other areas of the
kernel. They make the code harder to trace but have advantages you can't
get by simply pasting the function call into the path.
That said, I think walking the code is a bit easier with the multichain
approach. Lastly, at each invocation I could put in a comment explaining
how to find users of the chain.
> Finally, the consolidation into a notifier chain forces all the
> fork/exit/exec hooks into an one-size-fits-all model. What happens if one
> subsystem wants to hook in before exit_mmap() and another one wants to hook
> in after exit_mmap() (for example)?
As I see it there's not much I can do about the one-size-fits-all
model. So I tried to find the one size that fits most.
I think many systems that place calls in these paths aren't as
sensitive to their precise location as you might imagine. Many need to
initialize their per-task data and clean it up. They tend to depend on a
valid task structure and little else. Fewer systems -- profile for
instance -- have very specific requirements for when/where they get
called. Yet even profile can use some of task watchers.
I considered some obvious alternatives but they had worse problems.
Adding more notifications will run into naming problems. Using notifier
block priorities would have similar problems and be even harder to trace
by hand.
For those special systems that don't fit this "size" I think leaving
them in these paths is the best approach.
Cheers,
-Matt Helsley
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-28 18:49 ` 2.6.18-rc2-mm1 Matt Helsley
@ 2006-07-28 19:53 ` Michal Piotrowski
2006-07-28 20:39 ` 2.6.18-rc2-mm1 Matt Helsley
0 siblings, 1 reply; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-28 19:53 UTC (permalink / raw)
To: Matt Helsley; +Cc: Andrew Morton, LKML, Shailabh Nagar, Balbir Singh
On 28/07/06, Matt Helsley <matthltc@us.ibm.com> wrote:
> On Fri, 2006-07-28 at 01:34 -0700, Andrew Morton wrote:
> > On Fri, 28 Jul 2006 10:17:44 +0200
> > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> >
> > > Matt, can you look at this?
> > >
> > > My hunt file shows me, that this patches are causing oops.
> > > GOOD
> > > #
> > > #
> > > task-watchers-task-watchers.patch
> > > task-watchers-register-process-events-task-watcher.patch
> > > task-watchers-refactor-process-events.patch
> > > task-watchers-make-process-events-configurable-as.patch
> > > task-watchers-allow-task-watchers-to-block.patch
> > > task-watchers-register-audit-task-watcher.patch
> > > task-watchers-register-per-task-delay-accounting.patch
> > > task-watchers-register-profile-as-a-task-watcher.patch
> > > task-watchers-add-support-for-per-task-watchers.patch
> > > task-watchers-register-semundo-task-watcher.patch
> > > task-watchers-register-per-task-semundo-watcher.patch
> > > BAD
> >
> > Thanks for working that out.
>
> I noticed the delay accounting functions in the stack trace. Perhaps
> task-watchers-register-per-task-delay-accounting.patch is causing the
> problem.
Confirmed.
>
> Cheers,
> -Matt Helsley
>
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-28 19:53 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-28 20:39 ` Matt Helsley
2006-07-28 21:34 ` 2.6.18-rc2-mm1 Andrew Morton
` (2 more replies)
0 siblings, 3 replies; 107+ messages in thread
From: Matt Helsley @ 2006-07-28 20:39 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: Andrew Morton, LKML, Shailabh Nagar, Balbir Singh
On Fri, 2006-07-28 at 21:53 +0200, Michal Piotrowski wrote:
> On 28/07/06, Matt Helsley <matthltc@us.ibm.com> wrote:
> > On Fri, 2006-07-28 at 01:34 -0700, Andrew Morton wrote:
> > > On Fri, 28 Jul 2006 10:17:44 +0200
> > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > >
> > > > Matt, can you look at this?
> > > >
> > > > My hunt file shows me, that this patches are causing oops.
> > > > GOOD
> > > > #
> > > > #
> > > > task-watchers-task-watchers.patch
> > > > task-watchers-register-process-events-task-watcher.patch
> > > > task-watchers-refactor-process-events.patch
> > > > task-watchers-make-process-events-configurable-as.patch
> > > > task-watchers-allow-task-watchers-to-block.patch
> > > > task-watchers-register-audit-task-watcher.patch
> > > > task-watchers-register-per-task-delay-accounting.patch
> > > > task-watchers-register-profile-as-a-task-watcher.patch
> > > > task-watchers-add-support-for-per-task-watchers.patch
> > > > task-watchers-register-semundo-task-watcher.patch
> > > > task-watchers-register-per-task-semundo-watcher.patch
> > > > BAD
> > >
> > > Thanks for working that out.
> >
> > I noticed the delay accounting functions in the stack trace. Perhaps
> > task-watchers-register-per-task-delay-accounting.patch is causing the
> > problem.
>
> Confirmed.
Excellent, thanks for the rapid confirmation. I'll work with Shailabh
and Balbir to fix this. In the meantime perhaps
task-watchers-register-per-task-delay-accounting.patch should be dropped
from -mm.
Cheers,
-Matt Helsley
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-28 20:39 ` 2.6.18-rc2-mm1 Matt Helsley
@ 2006-07-28 21:34 ` Andrew Morton
2006-07-29 2:04 ` 2.6.18-rc2-mm1 Valdis.Kletnieks
2006-07-29 22:34 ` 2.6.18-rc2-mm1 Shailabh Nagar
2 siblings, 0 replies; 107+ messages in thread
From: Andrew Morton @ 2006-07-28 21:34 UTC (permalink / raw)
To: Matt Helsley; +Cc: michal.k.k.piotrowski, linux-kernel, nagar, balbir
On Fri, 28 Jul 2006 13:39:50 -0700
Matt Helsley <matthltc@us.ibm.com> wrote:
> > > I noticed the delay accounting functions in the stack trace. Perhaps
> > > task-watchers-register-per-task-delay-accounting.patch is causing the
> > > problem.
> >
> > Confirmed.
>
> Excellent, thanks for the rapid confirmation. I'll work with Shailabh
> and Balbir to fix this. In the meantime perhaps
> task-watchers-register-per-task-delay-accounting.patch should be dropped
> from -mm.
I think the whole patch series should be dropped, sorry. We will
occasionally add more runtime overhead to gain code maintainability or
readability or to squach warnings. But I do think this patchset goes too
far.
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-28 20:39 ` 2.6.18-rc2-mm1 Matt Helsley
2006-07-28 21:34 ` 2.6.18-rc2-mm1 Andrew Morton
@ 2006-07-29 2:04 ` Valdis.Kletnieks
2006-07-29 22:34 ` 2.6.18-rc2-mm1 Shailabh Nagar
2 siblings, 0 replies; 107+ messages in thread
From: Valdis.Kletnieks @ 2006-07-29 2:04 UTC (permalink / raw)
To: Matt Helsley
Cc: Michal Piotrowski, Andrew Morton, LKML, Shailabh Nagar, Balbir Singh
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
On Fri, 28 Jul 2006 13:39:50 PDT, Matt Helsley said:
> On Fri, 2006-07-28 at 21:53 +0200, Michal Piotrowski wrote:
> > On 28/07/06, Matt Helsley <matthltc@us.ibm.com> wrote:
> > > I noticed the delay accounting functions in the stack trace. Perhaps
> > > task-watchers-register-per-task-delay-accounting.patch is causing the
> > > problem.
> >
> > Confirmed.
>
> Excellent, thanks for the rapid confirmation. I'll work with Shailabh
> and Balbir to fix this. In the meantime perhaps
> task-watchers-register-per-task-delay-accounting.patch should be dropped
> from -mm.
I finished a bisect on -mm - I ca confirm that this one patch is also
responsible for the solid lockups I was seeing on a Dell C840. Am now up
and running on -rc2-mm1 with this one reverted.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-28 20:39 ` 2.6.18-rc2-mm1 Matt Helsley
2006-07-28 21:34 ` 2.6.18-rc2-mm1 Andrew Morton
2006-07-29 2:04 ` 2.6.18-rc2-mm1 Valdis.Kletnieks
@ 2006-07-29 22:34 ` Shailabh Nagar
2006-07-29 23:38 ` 2.6.18-rc2-mm1 Michal Piotrowski
2 siblings, 1 reply; 107+ messages in thread
From: Shailabh Nagar @ 2006-07-29 22:34 UTC (permalink / raw)
To: Matt Helsley; +Cc: Michal Piotrowski, Andrew Morton, LKML, Balbir Singh
Matt Helsley wrote:
> On Fri, 2006-07-28 at 21:53 +0200, Michal Piotrowski wrote:
>
>>On 28/07/06, Matt Helsley <matthltc@us.ibm.com> wrote:
>>
>>>On Fri, 2006-07-28 at 01:34 -0700, Andrew Morton wrote:
>>>
>>>>On Fri, 28 Jul 2006 10:17:44 +0200
>>>>"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>>>>
>>>>
>>>>>Matt, can you look at this?
>>>>>
>>>>>My hunt file shows me, that this patches are causing oops.
>>>>>GOOD
>>>>>#
>>>>>#
>>>>>task-watchers-task-watchers.patch
>>>>>task-watchers-register-process-events-task-watcher.patch
>>>>>task-watchers-refactor-process-events.patch
>>>>>task-watchers-make-process-events-configurable-as.patch
>>>>>task-watchers-allow-task-watchers-to-block.patch
>>>>>task-watchers-register-audit-task-watcher.patch
>>>>>task-watchers-register-per-task-delay-accounting.patch
>>>>>task-watchers-register-profile-as-a-task-watcher.patch
>>>>>task-watchers-add-support-for-per-task-watchers.patch
>>>>>task-watchers-register-semundo-task-watcher.patch
>>>>>task-watchers-register-per-task-semundo-watcher.patch
>>>>>BAD
>>>>
>>>>Thanks for working that out.
>>>
>>> I noticed the delay accounting functions in the stack trace. Perhaps
>>>task-watchers-register-per-task-delay-accounting.patch is causing the
>>>problem.
>>
>>Confirmed.
>
>
> Excellent, thanks for the rapid confirmation. I'll work with Shailabh
> and Balbir to fix this. In the meantime perhaps
> task-watchers-register-per-task-delay-accounting.patch should be dropped
> from -mm.
>
> Cheers,
> -Matt Helsley
>
The error is almost certainly because delayacct_tsk_init is being
called at WATCH_TASK_CLONE (which is triggered after the task has been
added to the tasklist) rather than WATCH_INIT (before).
__delayacct_tsk_init, which gets notified by WATCH_TASK_* initializes
the spinlock tsk->delays_lock which could get used as soon as task is
present in tasklist. The lockup is very likely due to use of this
uninitialized spinlock.
So the fix should be to change WATCH_TASK_CLONE to WATCH_TASK_INIT
in the delayacct_watch_task function created by this patch.
--Shailabh
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-29 22:34 ` 2.6.18-rc2-mm1 Shailabh Nagar
@ 2006-07-29 23:38 ` Michal Piotrowski
0 siblings, 0 replies; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-29 23:38 UTC (permalink / raw)
To: Shailabh Nagar; +Cc: Matt Helsley, Andrew Morton, LKML, Balbir Singh
Hi,
On 30/07/06, Shailabh Nagar <nagar@watson.ibm.com> wrote:
> Matt Helsley wrote:
> > On Fri, 2006-07-28 at 21:53 +0200, Michal Piotrowski wrote:
> >
> >>On 28/07/06, Matt Helsley <matthltc@us.ibm.com> wrote:
> >>
> >>>On Fri, 2006-07-28 at 01:34 -0700, Andrew Morton wrote:
> >>>
> >>>>On Fri, 28 Jul 2006 10:17:44 +0200
> >>>>"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> >>>>
> >>>>
> >>>>>Matt, can you look at this?
> >>>>>
> >>>>>My hunt file shows me, that this patches are causing oops.
> >>>>>GOOD
> >>>>>#
> >>>>>#
> >>>>>task-watchers-task-watchers.patch
> >>>>>task-watchers-register-process-events-task-watcher.patch
> >>>>>task-watchers-refactor-process-events.patch
> >>>>>task-watchers-make-process-events-configurable-as.patch
> >>>>>task-watchers-allow-task-watchers-to-block.patch
> >>>>>task-watchers-register-audit-task-watcher.patch
> >>>>>task-watchers-register-per-task-delay-accounting.patch
> >>>>>task-watchers-register-profile-as-a-task-watcher.patch
> >>>>>task-watchers-add-support-for-per-task-watchers.patch
> >>>>>task-watchers-register-semundo-task-watcher.patch
> >>>>>task-watchers-register-per-task-semundo-watcher.patch
> >>>>>BAD
> >>>>
> >>>>Thanks for working that out.
> >>>
> >>> I noticed the delay accounting functions in the stack trace. Perhaps
> >>>task-watchers-register-per-task-delay-accounting.patch is causing the
> >>>problem.
> >>
> >>Confirmed.
> >
> >
> > Excellent, thanks for the rapid confirmation. I'll work with Shailabh
> > and Balbir to fix this. In the meantime perhaps
> > task-watchers-register-per-task-delay-accounting.patch should be dropped
> > from -mm.
> >
> > Cheers,
> > -Matt Helsley
> >
>
>
> The error is almost certainly because delayacct_tsk_init is being
> called at WATCH_TASK_CLONE (which is triggered after the task has been
> added to the tasklist) rather than WATCH_INIT (before).
>
> __delayacct_tsk_init, which gets notified by WATCH_TASK_* initializes
> the spinlock tsk->delays_lock which could get used as soon as task is
> present in tasklist. The lockup is very likely due to use of this
> uninitialized spinlock.
>
> So the fix should be to change WATCH_TASK_CLONE to WATCH_TASK_INIT
> in the delayacct_watch_task function created by this patch.
Problem solved. Thanks.
>
> --Shailabh
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-28 8:17 ` 2.6.18-rc2-mm1 Michal Piotrowski
2006-07-28 8:34 ` 2.6.18-rc2-mm1 Andrew Morton
@ 2006-07-28 17:57 ` Matt Helsley
1 sibling, 0 replies; 107+ messages in thread
From: Matt Helsley @ 2006-07-28 17:57 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: Andrew Morton, LKML
On Fri, 2006-07-28 at 10:17 +0200, Michal Piotrowski wrote:
> Hi,
>
> On 27/07/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi Andrew,
> >
> > On 27/07/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> > >
> >
> > It appears while /sbin/start_udev
> >
> > Jul 27 15:17:17 ltg01-fedora kernel: BUG: unable to handle kernel
> > paging request at virtual address 6b6b6c07
> > Jul 27 15:17:17 ltg01-fedora kernel: printing eip:
> > Jul 27 15:17:17 ltg01-fedora kernel: c0138722
> > Jul 27 15:17:17 ltg01-fedora kernel: *pde = 00000000
> > Jul 27 15:17:17 ltg01-fedora kernel: Oops: 0002 [#1]
> > Jul 27 15:17:17 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > Jul 27 15:17:17 ltg01-fedora kernel: last sysfs file:
> > /devices/pci0000:00/0000:00:1d.7/uevent
> > Jul 27 15:17:17 ltg01-fedora kernel: Modules linked in: snd_timer snd
> > soundcore snd_page_alloc intel_agp agpgart ide_cd cdrom ipv6 w83627hf
> > hwmon_vid hwmon i2c_isa i2c_i801 skge af_packet
> > ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink
> > xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace
> > p4_clockmod speedstep_lib binfmt_misc thermal processor fan container
> > rtc unix
> > Jul 27 15:17:17 ltg01-fedora kernel: CPU: 0
> > Jul 27 15:17:17 ltg01-fedora kernel: EIP: 0060:[<c0138722>] Not
> > tainted VLI
> > Jul 27 15:17:17 ltg01-fedora kernel: EFLAGS: 00010046 (2.6.18-rc2-mm1 #78)
> > Jul 27 15:17:17 ltg01-fedora kernel: EIP is at __lock_acquire+0x362/0xaea
> > Jul 27 15:17:17 ltg01-fedora kernel: eax: 00000000 ebx: 6b6b6b6b
> > ecx: c0360358 edx: 00000000
> > Jul 27 15:17:17 ltg01-fedora kernel: esi: 00000000 edi: 00000000
> > ebp: f544ddf4 esp: f544ddc0
> > Jul 27 15:17:17 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> > Jul 27 15:17:17 ltg01-fedora kernel: Process udevd (pid: 1353,
> > ti=f544d000 task=f6fce8f0 task.ti=f544d000)
> > Jul 27 15:17:17 ltg01-fedora kernel: Stack: 00000000 00000000 00000000
> > c7749ea4 f6fce8f0 c0138e74 000001e8 00000000
> > Jul 27 15:17:17 ltg01-fedora kernel: 00000000 f6653fa4 00000246
> > 00000000 00000000 f544de1c c0139214 00000000
> > Jul 27 15:17:17 ltg01-fedora kernel: 00000002 00000000 c014fe3a
> > c7749ea4 c7749e90 f6fce8f0 f5b19b04 f544de34
> > Jul 27 15:17:17 ltg01-fedora kernel: Call Trace:
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
> > __delayacct_blkio_ticks+0x16/0x67
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> > Jul 27 15:17:17 ltg01-fedora kernel: DWARF2 unwinder stuck at
> > sysenter_past_esp+0x56/0x8d
> > Jul 27 15:17:17 ltg01-fedora kernel: Leftover inexact backtrace:
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0104318>] show_stack_log_lvl+0x8c/0x97
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c010447f>] show_registers+0x15c/0x1ed
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01046c2>] die+0x1b2/0x2b7
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c014fe3a>]
> > __delayacct_blkio_ticks+0x16/0x67
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> > Jul 27 15:17:17 ltg01-fedora kernel: Code: 68 4b 75 2f c0 68 d5 04 00
> > 00 68 b9 75 31 c0 68 e3 06 31 c0 e8 ce 7e fe ff e8 87 c2 fc ff 83 c4
> > 10 eb 08 85 db 0f 84 6b 07 00 00 <f0> ff 83 9c 00 00 00 8b 55 dc 8b 92
> > 5c 05 00 00 89 55 e4 83 fa
> > Jul 27 15:17:17 ltg01-fedora kernel: EIP: [<c0138722>]
> > __lock_acquire+0x362/0xaea SS:ESP 0068:f544ddc0
> > Jul 27 15:17:17 ltg01-fedora kernel: <3>BUG: sleeping function called
> > from invalid context at /usr/src/linux-mm/kernel/rwsem.c:20
> > Jul 27 15:17:17 ltg01-fedora kernel: in_atomic():1, irqs_disabled():1
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c012cd93>]
> > blocking_notifier_call_chain+0x11/0x2d
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> > Jul 27 15:17:17 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> > Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
> > error_code+0x39/0x40
> > Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0118d37>] __might_sleep+0x8d/0x95
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c013595d>] down_read+0x15/0x3b
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd93>]
> > blocking_notifier_call_chain+0x11/0x2d
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0122961>] do_exit+0x26/0xa4f
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
> > __delayacct_blkio_ticks+0x16/0x67
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> > Jul 27 15:17:18 ltg01-fedora kernel: note: udevd[1353] exited with
> > preempt_count 1
> > Jul 27 15:17:18 ltg01-fedora kernel: BUG: scheduling while atomic:
> > udevd/0x00000001/1353
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
> > Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
> > __down_failed+0xa/0xe
> > Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02ef76f>] __sched_text_start+0x5f/0xc95
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2977>] __down+0xaf/0xc3
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02f275e>] __down_failed+0xa/0xe
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02f32aa>]
> > .text.lock.kernel_lock+0x1b/0x3d
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c023c881>] disassociate_ctty+0xd/0x16e
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0122d8d>] do_exit+0x452/0xa4f
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01047a1>] die+0x291/0x2b7
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0116f5f>] do_page_fault+0x410/0x4f0
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0103d1d>] error_code+0x39/0x40
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0139214>] lock_acquire+0x71/0x91
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c02f2bfb>] _spin_lock+0x23/0x32
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c014fe3a>]
> > __delayacct_blkio_ticks+0x16/0x67
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01a4f76>] do_task_stat+0x3df/0x6c1
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01a5265>] proc_tgid_stat+0xd/0xf
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01a29dd>] proc_info_read+0x50/0xb3
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0171cbb>] vfs_read+0xcb/0x177
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c017217c>] sys_read+0x3b/0x71
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> > Jul 27 15:17:18 ltg01-fedora kernel: slab error in
> > verify_redzone_free(): cache `delayacct_cache': double free detected
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0104192>] show_trace_log_lvl+0x58/0x152
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
> > cache_free_debugcheck+0xcc/0x1c7
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
> > __delayacct_tsk_exit+0x38/0x3d
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
> > delayacct_watch_task+0x5a/0x65
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
> > blocking_notifier_call_chain+0x1d/0x2d
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0104896>] show_trace+0xd/0x10
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c01049b5>] dump_stack+0x19/0x1b
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c016bdb4>] __slab_error+0x17/0x1c
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c016be85>]
> > cache_free_debugcheck+0xcc/0x1c7
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c016c74f>] kmem_cache_free+0xa0/0xff
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c014ff3e>]
> > __delayacct_tsk_exit+0x38/0x3d
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0150281>]
> > delayacct_watch_task+0x5a/0x65
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012ca03>] notifier_call_chain+0x20/0x31
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012cd9f>]
> > blocking_notifier_call_chain+0x1d/0x2d
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c012cdc6>] notify_watchers+0x17/0x53
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0122bf4>] do_exit+0x2b9/0xa4f
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0123415>] sys_exit_group+0x0/0x11
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0123424>] sys_exit_group+0xf/0x11
> > Jul 27 15:17:18 ltg01-fedora kernel: [<c0103119>] sysenter_past_esp+0x56/0x8d
> >
> > list *0xc0138722
> > 0xc0138722 is in __lock_acquire (include2/asm/atomic.h:96).
> > 91 *
> > 92 * Atomically increments @v by 1.
> > 93 */
> > 94 static __inline__ void atomic_inc(atomic_t *v)
> > 95 {
> > 96 __asm__ __volatile__(
> > 97 LOCK_PREFIX "incl %0"
> > 98 :"+m" (v->counter));
> > 99 }
> > 100
> >
> > http://www.stardust.webpages.pl/files/mm/2.6.18-rc2-mm1/mm-config
> >
>
> Matt, can you look at this?
>
> My hunt file shows me, that this patches are causing oops.
> GOOD
> #
> #
> task-watchers-task-watchers.patch
> task-watchers-register-process-events-task-watcher.patch
> task-watchers-refactor-process-events.patch
> task-watchers-make-process-events-configurable-as.patch
> task-watchers-allow-task-watchers-to-block.patch
> task-watchers-register-audit-task-watcher.patch
> task-watchers-register-per-task-delay-accounting.patch
> task-watchers-register-profile-as-a-task-watcher.patch
> task-watchers-add-support-for-per-task-watchers.patch
> task-watchers-register-semundo-task-watcher.patch
> task-watchers-register-per-task-semundo-watcher.patch
> BAD
>
> Regards,
> Michal
Sure. Thanks for the report.
Cheers,
-Matt Helsley
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (4 preceding siblings ...)
2006-07-27 13:32 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-27 14:04 ` Andy Whitcroft
2006-07-27 14:48 ` 2.6.18-rc2-mm1 Andy Whitcroft
2006-07-27 15:37 ` [PATCH] highmem: fixed ip27-memory.c build error Yoichi Yuasa
` (13 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Andy Whitcroft @ 2006-07-27 14:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Seems that this one is eating /dev/null's during 'make' phase of a
build. Am trying to track down whats changed.
-apw
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-27 14:04 ` 2.6.18-rc2-mm1 Andy Whitcroft
@ 2006-07-27 14:48 ` Andy Whitcroft
0 siblings, 0 replies; 107+ messages in thread
From: Andy Whitcroft @ 2006-07-27 14:48 UTC (permalink / raw)
To: Roland McGrath; +Cc: Andy Whitcroft, Andrew Morton, linux-kernel
Andy Whitcroft wrote:
> Seems that this one is eating /dev/null's during 'make' phase of a
> build. Am trying to track down whats changed.
Ok, this seems to be related to the changes in:
vdso-hash-style-fix.patch
Backing this out reverses the new behaviour.
It looks like the check to see if the options are valid, use -o
/dev/null -xc /dev/null and that is causing the compiler to remove
/dev/null.
The machines affected do not seem to have such old compilers:
gcc version 3.3.4 (Debian 1:3.3.4-3)
Yeah, yeah I know I should not be running my builds as root, but then we
should not be eating it either.
-apw
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH] highmem: fixed ip27-memory.c build error
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (5 preceding siblings ...)
2006-07-27 14:04 ` 2.6.18-rc2-mm1 Andy Whitcroft
@ 2006-07-27 15:37 ` Yoichi Yuasa
2006-07-27 18:16 ` [-mm patch] arch/i386/pci/mmconfig.c: fixes Adrian Bunk
` (12 subsequent siblings)
19 siblings, 0 replies; 107+ messages in thread
From: Yoichi Yuasa @ 2006-07-27 15:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi,
This patch has fixed following build error.
This error occurred in relation to reduce-max_nr_zones-move-highmem-counters-into-highmemc-h.patch .
CC arch/mips/sgi-ip27/ip27-memory.o
arch/mips/sgi-ip27/ip27-memory.c: In function `mem_init':
arch/mips/sgi-ip27/ip27-memory.c:582: error: `totalhigh_pages' undeclared (first use in this function)
arch/mips/sgi-ip27/ip27-memory.c:582: error: (Each undeclared identifier is reported only once
arch/mips/sgi-ip27/ip27-memory.c:582: error: for each function it appears in.)
make[1]: *** [arch/mips/sgi-ip27/ip27-memory.o] Error 1
make: *** [arch/mips/sgi-ip27] Error 2
Yoichi
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X linux-2.6.18-rc2-mm1/Documentation/dontdiff linux-2.6.18-rc2-mm1-orig/arch/mips/sgi-ip27/ip27-memory.c linux-2.6.18-rc2-mm1/arch/mips/sgi-ip27/ip27-memory.c
--- linux-2.6.18-rc2-mm1-orig/arch/mips/sgi-ip27/ip27-memory.c 2006-07-27 20:15:23.680114000 +0900
+++ linux-2.6.18-rc2-mm1/arch/mips/sgi-ip27/ip27-memory.c 2006-07-27 19:40:11.234693250 +0900
@@ -19,6 +19,7 @@
#include <linux/swap.h>
#include <linux/bootmem.h>
#include <linux/pfn.h>
+#include <linux/highmem.h>
#include <asm/page.h>
#include <asm/sections.h>
^ permalink raw reply [flat|nested] 107+ messages in thread* [-mm patch] arch/i386/pci/mmconfig.c: fixes
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (6 preceding siblings ...)
2006-07-27 15:37 ` [PATCH] highmem: fixed ip27-memory.c build error Yoichi Yuasa
@ 2006-07-27 18:16 ` Adrian Bunk
2006-07-28 8:09 ` 2.6.18-rc2-mm1 Reuben Farrelly
` (11 subsequent siblings)
19 siblings, 0 replies; 107+ messages in thread
From: Adrian Bunk @ 2006-07-27 18:16 UTC (permalink / raw)
To: Andrew Morton, Edgar Hucek; +Cc: linux-kernel
On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc2-mm1:
>...
> +add-force-of-use-mmconfig.patch
>...
> x86 updates
>...
This patch contains the following fixes:
- add an #include <asm/setup.h> for getting the prototype of
add_memory_region()
since add_memory_region() has two "long long" parameters, it's
possible this might fix runtime corruption problems
- make the needlessly global pci_mmcfg_force() static
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/i386/pci/mmconfig.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.18-rc2-mm1-full/arch/i386/pci/mmconfig.c.old 2006-07-27 16:18:48.000000000 +0200
+++ linux-2.6.18-rc2-mm1-full/arch/i386/pci/mmconfig.c 2006-07-27 16:19:42.000000000 +0200
@@ -15,6 +15,7 @@
#include <linux/dmi.h>
#include <linux/efi.h>
#include <asm/e820.h>
+#include <asm/setup.h>
#include "pci.h"
/* aperture is up to 256MB but BIOS may reserve less */
@@ -225,7 +226,7 @@
* Check force MMCONFIG.
*/
-int __init pci_mmcfg_force(void)
+static int __init pci_mmcfg_force(void)
{
if (efi_enabled) {
if (dmi_check_system(pci_mmcfg_dmi_system_apple)) {
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (7 preceding siblings ...)
2006-07-27 18:16 ` [-mm patch] arch/i386/pci/mmconfig.c: fixes Adrian Bunk
@ 2006-07-28 8:09 ` Reuben Farrelly
2006-07-28 8:35 ` [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc Frederik Deweerdt
` (10 subsequent siblings)
19 siblings, 0 replies; 107+ messages in thread
From: Reuben Farrelly @ 2006-07-28 8:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Linux Netdev List, herbert
On 27/07/2006 8:56 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
> - git-klibc has been dropped due to very bad parallel-make problems.
>
> - Added a new line to the boilerplate, below!
>
> - Added Sam's lxdialog tree, as git-lxdialog.patch. You no longer need
> x-ray spectacles to read the menuconfig screens.
>
> - Lots of random patches. Many of them are bugfixes and I shall, as usual,
> go through them all identifying 2.6.18 material. But I can miss things, so
> please don't be afraid to point 2.6.18 candidates out to me.
>
> I also have, as usual, a number of bugfixes agains the git trees. I'll
> send these to the maintainers until they stick and then I lose track of
> them. So don't be afraid to send reminders to the subsystem maintainers
> either.
Still seeing breakage with the e1000/NAT. Now the problem isn't so much that
the bug exists, but that unlike in -rc1-mm2, the trace scrolls over and over and
over (with some variation down into it) until the kernel completely panics and
the box has to be rebooted.
http://www.ussg.iu.edu/hypermail/linux/kernel/0607.1/2689.html from Herbert Xu
talks about the original problem.
It's a regression from the previous -mm whereby the trace would print out just once.
Starting Dovecot Imap: [ OK ]
Starting clamd: [ OK ]
Starting amavisd: BUG: warning at net/core/dev.c:1168/skb_checksum_help()
Call Trace:
[<ffffffff80269c65>] show_trace+0xb5/0x324
[<ffffffff80269ee9>] dump_stack+0x15/0x1c
[<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
[<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
[<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
[<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
[<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
[<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
[<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
[<ffffffff80235389>] ip_local_deliver+0x199/0x270
[<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
[<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
[<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
[<ffffffff803c7b45>] e1000_clean+0x325/0x45b
[<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
[<ffffffff80211663>] __do_softirq+0x78/0x105
[<ffffffff80260716>] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
<IRQ> [<ffffffff8026b679>] do_softirq+0x39/0xa4
[<ffffffff802888b8>] irq_exit+0x58/0x5a
[<ffffffff8026b798>] do_IRQ+0xb4/0xbe
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter
iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle
ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1
RIP: 0010:[<ffffffff80269e6f>] [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff806366f0 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
RDX: 0000000000000010 RSI: ffff81003d95c840 RDI: ffff81003d95c140
RBP: ffffffff806367f0 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000001 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS: 00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack: ffffffff806cec48 ffffffff80636fc0 0000000000000001 ffff81002c9d78f8
0000000000000000 0000000000000000 00007fffff571020 ffff810029e63f58
ffffffff80636f80 0000000000000046 0000000000000000 0000000000000000
Call Trace:
[<ffffffff80269ee9>] dump_stack+0x15/0x1c
[<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
[<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
[<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
[<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
[<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
[<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
[<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
[<ffffffff80235389>] ip_local_deliver+0x199/0x270
[<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
[<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
[<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
[<ffffffff803c7b45>] e1000_clean+0x325/0x45b
[<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
[<ffffffff80211663>] __do_softirq+0x78/0x105
[<ffffffff80260716>] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
<IRQ> [<ffffffff8026b679>] do_softirq+0x39/0xa4
[<ffffffff802888b8>] irq_exit+0x58/0x5a
[<ffffffff8026b798>] do_IRQ+0xb4/0xbe
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [2] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter
iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle
ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1
RIP: 0010:[<ffffffff80269e6f>] [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80636378 EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff80636478 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS: 00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack: 000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
0000000000000000 0000000000000000 00007fffff571020 ffff810029e63f58
ffffffff80636f80 0000000000000046 0000000000000001 0000000000000002
Call Trace:
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
<IRQ> [<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269ee9>] dump_stack+0x15/0x1c
[<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
[<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
[<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
[<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
[<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
[<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
[<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
[<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
[<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
[<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
[<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
[<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
[<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
[<ffffffff80235389>] ip_local_deliver+0x199/0x270
[<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
[<ffffffff80439ccc>] kfree_skb+0x2c/0x31
[<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
[<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
[<ffffffff803c7b45>] e1000_clean+0x325/0x45b
[<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
[<ffffffff8021164f>] __do_softirq+0x64/0x105
[<ffffffff80211663>] __do_softirq+0x78/0x105
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8026b679>] do_softirq+0x39/0xa4
[<ffffffff802888b8>] irq_exit+0x58/0x5a
[<ffffffff8026b798>] do_IRQ+0xb4/0xbe
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [3] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter
iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle
ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1
RIP: 0010:[<ffffffff80269e6f>] [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80635ff8 EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff806360f8 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS: 00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack: 000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
<IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff8029a627>] mark_held_locks+0x5d/0x96
[<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269ee9>] dump_stack+0x15/0x1c
[<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
[<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
[<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
[<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
[<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
[<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
[<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
[<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
[<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
[<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
[<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
[<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
[<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
[<ffffffff80235389>] ip_local_deliver+0x199/0x270
[<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
[<ffffffff80439ccc>] kfree_skb+0x2c/0x31
[<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
[<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
[<ffffffff803c7b45>] e1000_clean+0x325/0x45b
[<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
[<ffffffff8021164f>] __do_softirq+0x64/0x105
[<ffffffff80211663>] __do_softirq+0x78/0x105
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8026b679>] do_softirq+0x39/0xa4
[<ffffffff802888b8>] irq_exit+0x58/0x5a
[<ffffffff8026b798>] do_IRQ+0xb4/0xbe
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [4] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter
iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle
ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1
RIP: 0010:[<ffffffff80269e6f>] [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80635c78 EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff80635d78 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS: 00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack: 000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
<IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff80285f9f>] vprintk+0x30f/0x35d
[<ffffffff802a2f8a>] kallsyms_lookup+0xea/0x1b5
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff8029a627>] mark_held_locks+0x5d/0x96
[<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269ee9>] dump_stack+0x15/0x1c
[<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
[<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
[<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
[<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
[<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
[<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
[<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
[<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
[<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
[<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
[<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
[<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
[<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
[<ffffffff80235389>] ip_local_deliver+0x199/0x270
[<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
[<ffffffff80439ccc>] kfree_skb+0x2c/0x31
[<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
[<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
[<ffffffff803c7b45>] e1000_clean+0x325/0x45b
[<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
[<ffffffff8021164f>] __do_softirq+0x64/0x105
[<ffffffff80211663>] __do_softirq+0x78/0x105
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8026b679>] do_softirq+0x39/0xa4
[<ffffffff802888b8>] irq_exit+0x58/0x5a
[<ffffffff8026b798>] do_IRQ+0xb4/0xbe
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [5] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter
iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle
ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1
RIP: 0010:[<ffffffff80269e6f>] [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff806358f8 EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff806359f8 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS: 00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack: 000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
<IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff80285f9f>] vprintk+0x30f/0x35d
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff80285f9f>] vprintk+0x30f/0x35d
[<ffffffff802a2f8a>] kallsyms_lookup+0xea/0x1b5
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff8029a627>] mark_held_locks+0x5d/0x96
[<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269ee9>] dump_stack+0x15/0x1c
[<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
[<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
[<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
[<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
[<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
[<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
[<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
[<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
[<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
[<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
[<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
[<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
[<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
[<ffffffff80235389>] ip_local_deliver+0x199/0x270
[<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
[<ffffffff80439ccc>] kfree_skb+0x2c/0x31
[<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
[<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
[<ffffffff803c7b45>] e1000_clean+0x325/0x45b
[<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
[<ffffffff8021164f>] __do_softirq+0x64/0x105
[<ffffffff80211663>] __do_softirq+0x78/0x105
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8026b679>] do_softirq+0x39/0xa4
[<ffffffff802888b8>] irq_exit+0x58/0x5a
[<ffffffff8026b798>] do_IRQ+0xb4/0xbe
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
<EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [6] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter
iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle
ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1
RIP: 0010:[<ffffffff80269e6f>] [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80635578 EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff80635678 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS: 00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack: 000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
<IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff80285f9f>] vprintk+0x30f/0x35d
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff80285f9f>] vprintk+0x30f/0x35d
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff80285f9f>] vprintk+0x30f/0x35d
[<ffffffff802a2f8a>] kallsyms_lookup+0xea/0x1b5
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff8029fae0>] module_text_address+0x16/0x46
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80269e7b>] show_trace+0x2cb/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269fdf>] _show_stack+0xef/0xfe
[<ffffffff8026a07a>] show_registers+0x8c/0x101
[<ffffffff8026a18f>] __die+0xa0/0xe3
[<ffffffff8020af95>] do_page_fault+0x785/0x89d
[<ffffffff8029a627>] mark_held_locks+0x5d/0x96
[<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
[<ffffffff802601ed>] error_exit+0x0/0x96
[<ffffffff80269e6f>] show_trace+0x2bf/0x324
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff80269ee9>] dump_stack+0x15/0x1c
[<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
[<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
[<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
[<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804579a6>] dst_output+0x0/0x10
[<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
[<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
[<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
[<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
[<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
[<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
[<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
[<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
[<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
[<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
[<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
[<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
[<ffffffff80258960>] nf_hook_slow+0x60/0xcd
[<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
[<ffffffff80235389>] ip_local_deliver+0x199/0x270
[<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
[<ffffffff80439ccc>] kfree_skb+0x2c/0x31
[<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
[<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
[<ffffffff803c7b45>] e1000_clean+0x325/0x45b
[<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
[<ffffffff8021164f>] __do_softirq+0x64/0x105
[<ffffffff80211663>] __do_softirq+0x78/0x105
[<ffffffff80260716>] call_softirq+0x1e/0x28
[<ffffffff8026b679>] do_softirq+0x39/0xa4
[<ffffffff802888b8>] irq_exit+0x58/0x5a
[<ffffffff8026b798>] do_IRQ+0xb4/0xbe
[<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
<EOI>
Thanks,
Reuben
^ permalink raw reply [flat|nested] 107+ messages in thread* [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (8 preceding siblings ...)
2006-07-28 8:09 ` 2.6.18-rc2-mm1 Reuben Farrelly
@ 2006-07-28 8:35 ` Frederik Deweerdt
2006-07-28 9:00 ` Marcel Holtmann
2006-07-28 9:17 ` Masatake YAMATO
2006-07-28 8:56 ` 2.6.18-rc2-mm1 Michal Piotrowski
` (9 subsequent siblings)
19 siblings, 2 replies; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-28 8:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, jet
On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
Hi,
I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
BUG:
[ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
[ 43.232000] in_atomic():1, irqs_disabled():0
[ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
[ 43.232000] [<c010415e>] show_trace+0x27/0x29
[ 43.232000] [<c010426e>] dump_stack+0x26/0x28
[ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
[ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
[ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
[ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
[ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
[ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
[ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
[ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
[ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
[ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
[ 43.240000] [<b7f38410>] 0xb7f38410
This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for
the following functions:
- bnep_sock_create
- cmtp_sock_create
- hci_sock_create
- hidp_sock_create
- l2cap_sock_create
- rfcomm_sock_create
- sco_sock_create
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/bnep/sock.c v2.6.18-rc2-mm1/net/bluetooth/bnep/sock.c
--- v2.6.18-rc2-mm1~ori/net/bluetooth/bnep/sock.c 2006-07-27 11:45:45.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/bnep/sock.c 2006-07-28 10:18:34.000000000 +0200
@@ -181,7 +181,7 @@ static int bnep_sock_create(struct socke
if (sock->type != SOCK_RAW)
return -ESOCKTNOSUPPORT;
- sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &bnep_proto, 1);
+ sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &bnep_proto, 1);
if (!sk)
return -ENOMEM;
diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/cmtp/sock.c v2.6.18-rc2-mm1/net/bluetooth/cmtp/sock.c
--- v2.6.18-rc2-mm1~ori/net/bluetooth/cmtp/sock.c 2006-07-27 11:45:45.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/cmtp/sock.c 2006-07-28 10:18:49.000000000 +0200
@@ -172,7 +172,7 @@ static int cmtp_sock_create(struct socke
if (sock->type != SOCK_RAW)
return -ESOCKTNOSUPPORT;
- sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &cmtp_proto, 1);
+ sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &cmtp_proto, 1);
if (!sk)
return -ENOMEM;
diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/hci_sock.c v2.6.18-rc2-mm1/net/bluetooth/hci_sock.c
--- v2.6.18-rc2-mm1~ori/net/bluetooth/hci_sock.c 2006-07-27 11:45:45.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/hci_sock.c 2006-07-28 09:28:48.000000000 +0200
@@ -618,7 +618,7 @@ static int hci_sock_create(struct socket
sock->ops = &hci_sock_ops;
- sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &hci_sk_proto, 1);
+ sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &hci_sk_proto, 1);
if (!sk)
return -ENOMEM;
diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/hidp/sock.c v2.6.18-rc2-mm1/net/bluetooth/hidp/sock.c
--- v2.6.18-rc2-mm1~ori/net/bluetooth/hidp/sock.c 2006-07-27 11:45:45.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/hidp/sock.c 2006-07-28 10:19:03.000000000 +0200
@@ -178,7 +178,7 @@ static int hidp_sock_create(struct socke
if (sock->type != SOCK_RAW)
return -ESOCKTNOSUPPORT;
- sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &hidp_proto, 1);
+ sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &hidp_proto, 1);
if (!sk)
return -ENOMEM;
diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/l2cap.c v2.6.18-rc2-mm1/net/bluetooth/l2cap.c
--- v2.6.18-rc2-mm1~ori/net/bluetooth/l2cap.c 2006-07-27 11:45:45.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/l2cap.c 2006-07-28 10:09:12.000000000 +0200
@@ -559,7 +559,7 @@ static int l2cap_sock_create(struct sock
sock->ops = &l2cap_sock_ops;
- sk = l2cap_sock_alloc(sock, protocol, GFP_KERNEL);
+ sk = l2cap_sock_alloc(sock, protocol, GFP_ATOMIC);
if (!sk)
return -ENOMEM;
diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/rfcomm/sock.c v2.6.18-rc2-mm1/net/bluetooth/rfcomm/sock.c
--- v2.6.18-rc2-mm1~ori/net/bluetooth/rfcomm/sock.c 2006-07-27 11:45:45.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/rfcomm/sock.c 2006-07-28 10:16:59.000000000 +0200
@@ -336,7 +336,7 @@ static int rfcomm_sock_create(struct soc
sock->ops = &rfcomm_sock_ops;
- if (!(sk = rfcomm_sock_alloc(sock, protocol, GFP_KERNEL)))
+ if (!(sk = rfcomm_sock_alloc(sock, protocol, GFP_ATOMIC)))
return -ENOMEM;
rfcomm_sock_init(sk, NULL);
diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/sco.c v2.6.18-rc2-mm1/net/bluetooth/sco.c
--- v2.6.18-rc2-mm1~ori/net/bluetooth/sco.c 2006-07-27 11:45:45.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/sco.c 2006-07-28 10:11:28.000000000 +0200
@@ -452,7 +452,7 @@ static int sco_sock_create(struct socket
sock->ops = &sco_sock_ops;
- if (!(sk = sco_sock_alloc(sock, protocol, GFP_KERNEL)))
+ if (!(sk = sco_sock_alloc(sock, protocol, GFP_ATOMIC)))
return -ENOMEM;
sco_sock_init(sk, NULL);
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc
2006-07-28 8:35 ` [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc Frederik Deweerdt
@ 2006-07-28 9:00 ` Marcel Holtmann
2006-07-28 12:36 ` Frederik Deweerdt
2006-07-28 9:17 ` Masatake YAMATO
1 sibling, 1 reply; 107+ messages in thread
From: Marcel Holtmann @ 2006-07-28 9:00 UTC (permalink / raw)
To: Frederik Deweerdt; +Cc: Andrew Morton, linux-kernel, jet
Hi Frederik,
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> >
>
> I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> BUG:
> [ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> [ 43.232000] in_atomic():1, irqs_disabled():0
> [ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> [ 43.232000] [<c010415e>] show_trace+0x27/0x29
> [ 43.232000] [<c010426e>] dump_stack+0x26/0x28
> [ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
> [ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
> [ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
> [ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
> [ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
> [ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
> [ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
> [ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
> [ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
> [ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
> [ 43.240000] [<b7f38410>] 0xb7f38410
the comment from Max Krasnyansky (the original author) I got was this:
As far as I remember there was some upper level locking that ensured
that protected registration stuff. But it's been awhile so I may be
completely wrong.
And Masatake YAMATO mentioned:
It seems that lock_kernel/unlock_kernel was used in sys_init_module.
However, now it is gone.
I haven't looked at the new module loading code to verify if we really
need to protect our socket registration or not.
Regards
Marcel
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc
2006-07-28 9:00 ` Marcel Holtmann
@ 2006-07-28 12:36 ` Frederik Deweerdt
0 siblings, 0 replies; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-28 12:36 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Andrew Morton, linux-kernel, jet
On Fri, Jul 28, 2006 at 11:00:09AM +0200, Marcel Holtmann wrote:
> Hi Frederik,
>
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> > >
> >
> > I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> > BUG:
> > [ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> > [ 43.232000] in_atomic():1, irqs_disabled():0
> > [ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> > [ 43.232000] [<c010415e>] show_trace+0x27/0x29
> > [ 43.232000] [<c010426e>] dump_stack+0x26/0x28
> > [ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
> > [ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
> > [ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
> > [ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
> > [ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
> > [ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
> > [ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
> > [ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
> > [ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
> > [ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
> > [ 43.240000] [<b7f38410>] 0xb7f38410
>
> the comment from Max Krasnyansky (the original author) I got was this:
>
> As far as I remember there was some upper level locking that ensured
> that protected registration stuff. But it's been awhile so I may be
> completely wrong.
>
> And Masatake YAMATO mentioned:
>
> It seems that lock_kernel/unlock_kernel was used in sys_init_module.
> However, now it is gone.
>
> I haven't looked at the new module loading code to verify if we really
> need to protect our socket registration or not.
>
I'm really not an expert here, but from what I read, the only obvious
locking done in sys_init_module is involves 'module_mutex'. And that
mutex is released at the time 'mod->init()' is called.
Regards,
Frederik
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc
2006-07-28 8:35 ` [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc Frederik Deweerdt
2006-07-28 9:00 ` Marcel Holtmann
@ 2006-07-28 9:17 ` Masatake YAMATO
2006-07-28 12:32 ` Frederik Deweerdt
1 sibling, 1 reply; 107+ messages in thread
From: Masatake YAMATO @ 2006-07-28 9:17 UTC (permalink / raw)
To: deweerdt; +Cc: akpm, linux-kernel
> I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> BUG:
> [ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> [ 43.232000] in_atomic():1, irqs_disabled():0
> [ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> [ 43.232000] [<c010415e>] show_trace+0x27/0x29
> [ 43.232000] [<c010426e>] dump_stack+0x26/0x28
> [ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
> [ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
> [ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
> [ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
> [ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
> [ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
> [ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
> [ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
> [ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
> [ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
> [ 43.240000] [<b7f38410>] 0xb7f38410
>
>
> This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for
> the following functions:
> - bnep_sock_create
> - cmtp_sock_create
> - hci_sock_create
> - hidp_sock_create
> - l2cap_sock_create
> - rfcomm_sock_create
> - sco_sock_create
There is very similar code in i net/socket.c(I guess some part of
bluetooth/af_bluetooth.c is derived from net/socket.c):
static int __sock_create(int family, int type, int protocol, struct socket **res, int kern)
{
...
net_family_read_lock();
...
if ((err = net_families[family]->create(sock, protocol)) < 0) {
sock->ops = NULL;
goto out_module_put;
}
...
net_family_read_unlock();
return err;
}
I can find GFP_KERNEL is used to allocate object in
net_families[family]->create(sock, protocol). e.g.:
net/ipv4/af_inet.c:
static int inet_create(struct socket *sock, int protocol)
{
...
sk = sk_alloc(PF_INET, GFP_KERNEL, answer_prot, 1);
...
}
Tricks are in net_family_read_lock and net_family_read_unlock:
net/socket.c:
static __inline__ void net_family_read_lock(void)
{
atomic_inc(&net_family_lockct);
spin_unlock_wait(&net_family_lock);
}
static __inline__ void net_family_read_unlock(void)
{
atomic_dec(&net_family_lockct);
}
So there are two ways to avoid the bug:
1. As proposed by Frederik, use sk_alloc with GFP_ATOMIC or
2. use net_family_{read|writ}_{lock|unlock} in af_bluetooth.c.
I wonder which is better.
Masatake YAMATO
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc
2006-07-28 9:17 ` Masatake YAMATO
@ 2006-07-28 12:32 ` Frederik Deweerdt
2006-07-28 13:12 ` Masatake YAMATO
0 siblings, 1 reply; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-28 12:32 UTC (permalink / raw)
To: Masatake YAMATO; +Cc: akpm, linux-kernel
On Fri, Jul 28, 2006 at 06:17:56PM +0900, Masatake YAMATO wrote:
> > I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> > BUG:
> > [ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> > [ 43.232000] in_atomic():1, irqs_disabled():0
> > [ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> > [ 43.232000] [<c010415e>] show_trace+0x27/0x29
> > [ 43.232000] [<c010426e>] dump_stack+0x26/0x28
> > [ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
> > [ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
> > [ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
> > [ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
> > [ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
> > [ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
> > [ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
> > [ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
> > [ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
> > [ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
> > [ 43.240000] [<b7f38410>] 0xb7f38410
> >
> >
> > This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for
> > the following functions:
> > - bnep_sock_create
> > - cmtp_sock_create
> > - hci_sock_create
> > - hidp_sock_create
> > - l2cap_sock_create
> > - rfcomm_sock_create
> > - sco_sock_create
>
> There is very similar code in i net/socket.c(I guess some part of
> bluetooth/af_bluetooth.c is derived from net/socket.c):
>
[... skip net/socket.c code ...]
>
> So there are two ways to avoid the bug:
> 1. As proposed by Frederik, use sk_alloc with GFP_ATOMIC or
> 2. use net_family_{read|writ}_{lock|unlock} in af_bluetooth.c.
>
I'd say that using a net_family_* like function set is much better,
if only in terms of preemptibility.
I'll write an implementation that allows to use the same code
in socket.c and in af_bluetooth.c
Regards,
Frederik
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc
2006-07-28 12:32 ` Frederik Deweerdt
@ 2006-07-28 13:12 ` Masatake YAMATO
2006-07-28 16:15 ` [01/04 mm-patch, rfc] Add lightweight rwlock (was Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc) Frederik Deweerdt
0 siblings, 1 reply; 107+ messages in thread
From: Masatake YAMATO @ 2006-07-28 13:12 UTC (permalink / raw)
To: deweerdt; +Cc: akpm, linux-kernel
Hi,
> On Fri, Jul 28, 2006 at 06:17:56PM +0900, Masatake YAMATO wrote:
> > > I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> > > BUG:
> > > [ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> > > [ 43.232000] in_atomic():1, irqs_disabled():0
> > > [ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> > > [ 43.232000] [<c010415e>] show_trace+0x27/0x29
> > > [ 43.232000] [<c010426e>] dump_stack+0x26/0x28
> > > [ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
> > > [ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
> > > [ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
> > > [ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
> > > [ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
> > > [ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
> > > [ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
> > > [ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
> > > [ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
> > > [ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
> > > [ 43.240000] [<b7f38410>] 0xb7f38410
> > >
> > >
> > > This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for
> > > the following functions:
> > > - bnep_sock_create
> > > - cmtp_sock_create
> > > - hci_sock_create
> > > - hidp_sock_create
> > > - l2cap_sock_create
> > > - rfcomm_sock_create
> > > - sco_sock_create
> >
> > There is very similar code in i net/socket.c(I guess some part of
> > bluetooth/af_bluetooth.c is derived from net/socket.c):
> >
> [... skip net/socket.c code ...]
> >
> > So there are two ways to avoid the bug:
> > 1. As proposed by Frederik, use sk_alloc with GFP_ATOMIC or
> > 2. use net_family_{read|writ}_{lock|unlock} in af_bluetooth.c.
> >
> I'd say that using a net_family_* like function set is much better,
> if only in terms of preemptibility.
>
> I'll write an implementation that allows to use the same code
> in socket.c and in af_bluetooth.c
>
> Regards,
> Frederik
I found one more similar code set at net/dccp/ccid.c for the same purpose:
/*
* The strategy is: modifications ccids vector are short, do not sleep and
* veeery rare, but read access should be free of any exclusive locks.
*/
static void ccids_write_lock(void)
{
spin_lock(&ccids_lock);
while (atomic_read(&ccids_lockct) != 0) {
spin_unlock(&ccids_lock);
yield();
spin_lock(&ccids_lock);
}
}
static inline void ccids_write_unlock(void)
{
spin_unlock(&ccids_lock);
}
static inline void ccids_read_lock(void)
{
atomic_inc(&ccids_lockct);
spin_unlock_wait(&ccids_lock);
}
static inline void ccids_read_unlock(void)
{
atomic_dec(&ccids_lockct);
}
I'm new to the kernel, however, I think it is better to unify
them into one and to give a good name.
Masatake YAMATO
^ permalink raw reply [flat|nested] 107+ messages in thread* [01/04 mm-patch, rfc] Add lightweight rwlock (was Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc)
2006-07-28 13:12 ` Masatake YAMATO
@ 2006-07-28 16:15 ` Frederik Deweerdt
2006-07-28 16:23 ` [02/04 " Frederik Deweerdt
2006-07-31 7:06 ` [01/04 mm-patch, rfc] Add lightweight rwlock Masatake YAMATO
0 siblings, 2 replies; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-28 16:15 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, acme, marcel, jet
[-- Attachment #1: Type: text/plain, Size: 3376 bytes --]
On Fri, Jul 28, 2006 at 10:12:52PM +0900, Masatake YAMATO wrote:
> Hi,
> > On Fri, Jul 28, 2006 at 06:17:56PM +0900, Masatake YAMATO wrote:
> > > > I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
> > > > BUG:
> > > > [ 43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
> > > > [ 43.232000] in_atomic():1, irqs_disabled():0
> > > > [ 43.232000] [<c0104114>] show_trace_log_lvl+0x197/0x1ba
> > > > [ 43.232000] [<c010415e>] show_trace+0x27/0x29
> > > > [ 43.232000] [<c010426e>] dump_stack+0x26/0x28
> > > > [ 43.232000] [<c011ad1c>] __might_sleep+0xa2/0xaa
> > > > [ 43.232000] [<c0173085>] __kmalloc+0x9c/0xb3
> > > > [ 43.232000] [<c02f9295>] sk_alloc+0x1bc/0x1de
> > > > [ 43.232000] [<c036d689>] hci_sock_create+0x42/0x8a
> > > > [ 43.236000] [<c0366f40>] bt_sock_create+0xb5/0x154
> > > > [ 43.236000] [<c02f69dc>] __sock_create+0x131/0x356
> > > > [ 43.236000] [<c02f6c2f>] sock_create+0x2e/0x30
> > > > [ 43.236000] [<c02f6c88>] sys_socket+0x27/0x53
> > > > [ 43.240000] [<c02f7db5>] sys_socketcall+0xa9/0x277
> > > > [ 43.240000] [<c0103131>] sysenter_past_esp+0x56/0x8d
> > > > [ 43.240000] [<b7f38410>] 0xb7f38410
> > > >
> > > >
> > > > This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for
> > > > the following functions:
> > > > - bnep_sock_create
> > > > - cmtp_sock_create
> > > > - hci_sock_create
> > > > - hidp_sock_create
> > > > - l2cap_sock_create
> > > > - rfcomm_sock_create
> > > > - sco_sock_create
> > >
> > > There is very similar code in i net/socket.c(I guess some part of
> > > bluetooth/af_bluetooth.c is derived from net/socket.c):
> > >
> > [... skip net/socket.c code ...]
> > >
> > > So there are two ways to avoid the bug:
> > > 1. As proposed by Frederik, use sk_alloc with GFP_ATOMIC or
> > > 2. use net_family_{read|writ}_{lock|unlock} in af_bluetooth.c.
> > >
> > I'd say that using a net_family_* like function set is much better,
> > if only in terms of preemptibility.
> >
> > I'll write an implementation that allows to use the same code
> > in socket.c and in af_bluetooth.c
> >
> I found one more similar code set at net/dccp/ccid.c for the same purpose:
OK, thanks, I modified it too.
The following set of patches adds a struct lw_rwlock (for lightweight
rwlock) which contains a spin_lock_t and an atomic_t. It is defined
in include/linux/lw_rwlock.h.
This lw_rwlock aims at protecting structures that are modified very rarely
and quickly. This assumptions allow the reader to merely increment the
atomic_t, allowing it to sleep why the lw_rwlock is help.
There were already two users of this kind of API: net/socket.c to protect
'net_families' and net/dccp/ccid.c to protect 'ccids'. As suggested
by Masatake YAMATO, this looked like good way to protect 'bt_proto'
in net/bluetooth/af_bluetooth.c as well. This patchset aims at having
only one implementation in the kernel.
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
include/linux/lw_rwlock.h | 71 +++++++++++++++++++++++++++++++++++++++++++
net/bluetooth/af_bluetooth.c | 15 ++++-----
net/dccp/ccid.c | 63 +++++++-------------------------------
net/socket.c | 58 ++++-------------------------------
4 files changed, 100 insertions(+), 107 deletions(-)
[-- Attachment #2: lw_rwlock-include-file.patch --]
[-- Type: text/plain, Size: 1789 bytes --]
--- v2.6.18-rc2-mm1~ori/include/linux/lw_rwlock.h 1970-01-01 01:00:00.000000000 +0100
+++ v2.6.18-rc2-mm1/include/linux/lw_rwlock.h 2006-07-28 17:25:04.000000000 +0200
@@ -0,0 +1,71 @@
+#ifndef __LINUX_LW_RWLOCK_H
+#define __LINUX_LW_RWLOCK_H
+
+/*
+ * LightWeight readwriter lock.
+ * The strategy is: modifications while the lock is held are short, do not
+ * sleep and veeery rare, but read access should be free of any exclusive
+ * locks.
+ * The original implementation was written for net/socket.c
+ */
+
+#include <linux/spinlock.h>
+
+
+struct lw_rwlock {
+ /* tracks down the number of current readers */
+ atomic_t readers;
+ /* the actual lock, only held by writers */
+ spinlock_t lock;
+};
+
+#define __LW_RWLOCK_UNLOCKED(lockname) \
+ { { 0 }, __SPIN_LOCK_UNLOCKED(lockname) }
+
+#define lw_rwlock_init(x) \
+ do { *(x) = (lw_rwlock_t) __LW_RWLOCK_UNLOCKED(x); } while (0)
+
+#define DEFINE_LW_RWLOCK(x) \
+ struct lw_rwlock x = __LW_RWLOCK_UNLOCKED(x)
+
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
+
+static inline void lw_write_lock(struct lw_rwlock *l)
+{
+ spin_lock(&l->lock);
+ while (atomic_read(&l->readers) != 0) {
+ spin_unlock(&l->lock);
+
+ yield();
+
+ spin_lock(&l->lock);
+ }
+}
+
+static inline void lw_write_unlock(struct lw_rwlock *l)
+{
+ spin_unlock(&l->lock);
+}
+
+static inline void lw_read_lock(struct lw_rwlock *l)
+{
+ atomic_inc(&l->readers);
+ spin_unlock_wait(&l->lock);
+}
+
+static inline void lw_read_unlock(struct lw_rwlock *l)
+{
+ atomic_dec(&l->readers);
+}
+
+#else
+
+#define lw_write_lock(x) do { } while(0)
+#define lw_write_unlock(x) do { } while(0)
+#define lw_read_lock(x) do { } while(0)
+#define lw_read_unlock() do { } while(0)
+
+#endif /* CONFIG_SMP || CONFIG_PREEMPT */
+
+
+#endif /* __LINUX_LW_RWLOCK_H */
^ permalink raw reply [flat|nested] 107+ messages in thread* [02/04 mm-patch, rfc] Add lightweight rwlock (was Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc)
2006-07-28 16:15 ` [01/04 mm-patch, rfc] Add lightweight rwlock (was Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc) Frederik Deweerdt
@ 2006-07-28 16:23 ` Frederik Deweerdt
2006-07-28 16:28 ` [03/04 mm-patch, rfc] Add lightweight rwlock to net/dccp/ccid.c " Frederik Deweerdt
2006-07-31 7:06 ` [01/04 mm-patch, rfc] Add lightweight rwlock Masatake YAMATO
1 sibling, 1 reply; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-28 16:23 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, acme, marcel, jet
[-- Attachment #1: Type: text/plain, Size: 239 bytes --]
This patch is part of the lw_rwlock patchset, it removes the
net_family_{read,write}_{lock,unlock} functions which have been moved
to linux/lw_rwlock.h and made more generic.
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
[-- Attachment #2: net_socket.c-use-lw_rwlocks.patch --]
[-- Type: text/plain, Size: 2941 bytes --]
--- v2.6.18-rc2-mm1~ori/net/socket.c 2006-07-27 11:46:12.000000000 +0200
+++ v2.6.18-rc2-mm1/net/socket.c 2006-07-28 15:50:06.000000000 +0200
@@ -85,6 +85,7 @@
#include <linux/kmod.h>
#include <linux/audit.h>
#include <linux/wireless.h>
+#include <linux/lw_rwlock.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -143,50 +144,7 @@ static struct file_operations socket_fil
static struct net_proto_family *net_families[NPROTO];
-#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
-static atomic_t net_family_lockct = ATOMIC_INIT(0);
-static DEFINE_SPINLOCK(net_family_lock);
-
-/* The strategy is: modifications net_family vector are short, do not
- sleep and veeery rare, but read access should be free of any exclusive
- locks.
- */
-
-static void net_family_write_lock(void)
-{
- spin_lock(&net_family_lock);
- while (atomic_read(&net_family_lockct) != 0) {
- spin_unlock(&net_family_lock);
-
- yield();
-
- spin_lock(&net_family_lock);
- }
-}
-
-static __inline__ void net_family_write_unlock(void)
-{
- spin_unlock(&net_family_lock);
-}
-
-static __inline__ void net_family_read_lock(void)
-{
- atomic_inc(&net_family_lockct);
- spin_unlock_wait(&net_family_lock);
-}
-
-static __inline__ void net_family_read_unlock(void)
-{
- atomic_dec(&net_family_lockct);
-}
-
-#else
-#define net_family_write_lock() do { } while(0)
-#define net_family_write_unlock() do { } while(0)
-#define net_family_read_lock() do { } while(0)
-#define net_family_read_unlock() do { } while(0)
-#endif
-
+static DEFINE_LW_RWLOCK(net_family_lock);
/*
* Statistics counters of the socket lists
@@ -1125,7 +1083,7 @@ static int __sock_create(int family, int
}
#endif
- net_family_read_lock();
+ lw_read_lock(&net_family_lock);
if (net_families[family] == NULL) {
err = -EAFNOSUPPORT;
goto out;
@@ -1176,7 +1134,7 @@ static int __sock_create(int family, int
security_socket_post_create(sock, family, type, protocol, kern);
out:
- net_family_read_unlock();
+ lw_read_unlock(&net_family_lock);
return err;
out_module_put:
module_put(net_families[family]->owner);
@@ -2025,13 +1983,13 @@ int sock_register(struct net_proto_famil
printk(KERN_CRIT "protocol %d >= NPROTO(%d)\n", ops->family, NPROTO);
return -ENOBUFS;
}
- net_family_write_lock();
+ lw_write_lock(&net_family_lock);
err = -EEXIST;
if (net_families[ops->family] == NULL) {
net_families[ops->family]=ops;
err = 0;
}
- net_family_write_unlock();
+ lw_write_unlock(&net_family_lock);
printk(KERN_INFO "NET: Registered protocol family %d\n",
ops->family);
return err;
@@ -2048,9 +2006,9 @@ int sock_unregister(int family)
if (family < 0 || family >= NPROTO)
return -1;
- net_family_write_lock();
+ lw_write_lock(&net_family_lock);
net_families[family]=NULL;
- net_family_write_unlock();
+ lw_write_unlock(&net_family_lock);
printk(KERN_INFO "NET: Unregistered protocol family %d\n",
family);
return 0;
^ permalink raw reply [flat|nested] 107+ messages in thread* [03/04 mm-patch, rfc] Add lightweight rwlock to net/dccp/ccid.c (was Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc)
2006-07-28 16:23 ` [02/04 " Frederik Deweerdt
@ 2006-07-28 16:28 ` Frederik Deweerdt
2006-07-28 16:33 ` [04/04 mm-patch, rfc] Add lightweight rwlock to net/bluetooth/af_bluetooth.c " Frederik Deweerdt
0 siblings, 1 reply; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-28 16:28 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, acme, marcel, jet
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
This patch is part of the lw_rwlock patchset, it removes the
ccids_{read,write}_{lock,unlock} functions which have been moved
to linux/lw_rwlock.h and made more generic.
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
[-- Attachment #2: net_dccp_ccid.c-use-lw_rwlocks.patch --]
[-- Type: text/plain, Size: 3512 bytes --]
--- v2.6.18-rc2-mm1~ori/net/dccp/ccid.c 2006-06-18 03:49:35.000000000 +0200
+++ v2.6.18-rc2-mm1/net/dccp/ccid.c 2006-07-28 16:19:32.000000000 +0200
@@ -12,48 +12,11 @@
*/
#include "ccid.h"
+#include <linux/lw_rwlock.h>
static struct ccid_operations *ccids[CCID_MAX];
-#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
-static atomic_t ccids_lockct = ATOMIC_INIT(0);
-static DEFINE_SPINLOCK(ccids_lock);
-
-/*
- * The strategy is: modifications ccids vector are short, do not sleep and
- * veeery rare, but read access should be free of any exclusive locks.
- */
-static void ccids_write_lock(void)
-{
- spin_lock(&ccids_lock);
- while (atomic_read(&ccids_lockct) != 0) {
- spin_unlock(&ccids_lock);
- yield();
- spin_lock(&ccids_lock);
- }
-}
-
-static inline void ccids_write_unlock(void)
-{
- spin_unlock(&ccids_lock);
-}
+static DEFINE_LW_RWLOCK(ccids_lock);
-static inline void ccids_read_lock(void)
-{
- atomic_inc(&ccids_lockct);
- spin_unlock_wait(&ccids_lock);
-}
-
-static inline void ccids_read_unlock(void)
-{
- atomic_dec(&ccids_lockct);
-}
-
-#else
-#define ccids_write_lock() do { } while(0)
-#define ccids_write_unlock() do { } while(0)
-#define ccids_read_lock() do { } while(0)
-#define ccids_read_unlock() do { } while(0)
-#endif
static kmem_cache_t *ccid_kmem_cache_create(int obj_size, const char *fmt,...)
{
@@ -103,13 +66,13 @@ int ccid_register(struct ccid_operations
if (ccid_ops->ccid_hc_tx_slab == NULL)
goto out_free_rx_slab;
- ccids_write_lock();
+ lw_write_lock(&ccids_lock);
err = -EEXIST;
if (ccids[ccid_ops->ccid_id] == NULL) {
ccids[ccid_ops->ccid_id] = ccid_ops;
err = 0;
}
- ccids_write_unlock();
+ lw_write_unlock(&ccids_lock);
if (err != 0)
goto out_free_tx_slab;
@@ -131,9 +94,9 @@ EXPORT_SYMBOL_GPL(ccid_register);
int ccid_unregister(struct ccid_operations *ccid_ops)
{
- ccids_write_lock();
+ lw_write_lock(&ccids_lock);
ccids[ccid_ops->ccid_id] = NULL;
- ccids_write_unlock();
+ lw_write_unlock(&ccids_lock);
ccid_kmem_cache_destroy(ccid_ops->ccid_hc_tx_slab);
ccid_ops->ccid_hc_tx_slab = NULL;
@@ -152,15 +115,15 @@ struct ccid *ccid_new(unsigned char id,
struct ccid_operations *ccid_ops;
struct ccid *ccid = NULL;
- ccids_read_lock();
+ lw_read_lock(&ccids_lock);
#ifdef CONFIG_KMOD
if (ccids[id] == NULL) {
/* We only try to load if in process context */
- ccids_read_unlock();
+ lw_read_unlock(&ccids_lock);
if (gfp & GFP_ATOMIC)
goto out;
request_module("net-dccp-ccid-%d", id);
- ccids_read_lock();
+ lw_read_lock(&ccids_lock);
}
#endif
ccid_ops = ccids[id];
@@ -170,7 +133,7 @@ struct ccid *ccid_new(unsigned char id,
if (!try_module_get(ccid_ops->ccid_owner))
goto out_unlock;
- ccids_read_unlock();
+ lw_read_unlock(&ccids_lock);
ccid = kmem_cache_alloc(rx ? ccid_ops->ccid_hc_rx_slab :
ccid_ops->ccid_hc_tx_slab, gfp);
@@ -191,7 +154,7 @@ struct ccid *ccid_new(unsigned char id,
out:
return ccid;
out_unlock:
- ccids_read_unlock();
+ lw_read_unlock(&ccids_lock);
goto out;
out_free_ccid:
kmem_cache_free(rx ? ccid_ops->ccid_hc_rx_slab :
@@ -235,10 +198,10 @@ static void ccid_delete(struct ccid *cci
ccid_ops->ccid_hc_tx_exit(sk);
kmem_cache_free(ccid_ops->ccid_hc_tx_slab, ccid);
}
- ccids_read_lock();
+ lw_read_lock(&ccids_lock);
if (ccids[ccid_ops->ccid_id] != NULL)
module_put(ccid_ops->ccid_owner);
- ccids_read_unlock();
+ lw_read_unlock(&ccids_lock);
}
void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk)
^ permalink raw reply [flat|nested] 107+ messages in thread* [04/04 mm-patch, rfc] Add lightweight rwlock to net/bluetooth/af_bluetooth.c (was Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc)
2006-07-28 16:28 ` [03/04 mm-patch, rfc] Add lightweight rwlock to net/dccp/ccid.c " Frederik Deweerdt
@ 2006-07-28 16:33 ` Frederik Deweerdt
0 siblings, 0 replies; 107+ messages in thread
From: Frederik Deweerdt @ 2006-07-28 16:33 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, acme, marcel, jet
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
This patch is part of the lw_rwlock patchset, it removes the
bt_proto_rwlock lock from af_bluetooth.c and uses the newly available
linux/lw_rwlock.h
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
[-- Attachment #2: net_bluetooth_af_bluetooth.c-use-lw_rwlocks.patch --]
[-- Type: text/plain, Size: 1675 bytes --]
--- v2.6.18-rc2-mm1~ori/net/bluetooth/af_bluetooth.c 2006-07-27 11:46:12.000000000 +0200
+++ v2.6.18-rc2-mm1/net/bluetooth/af_bluetooth.c 2006-07-28 16:22:50.000000000 +0200
@@ -27,6 +27,7 @@
#include <linux/module.h>
#include <linux/spinlock.h>
+#include <linux/lw_rwlock.h>
#include <linux/types.h>
#include <linux/list.h>
#include <linux/errno.h>
@@ -54,7 +55,7 @@
/* Bluetooth sockets */
#define BT_MAX_PROTO 8
static struct net_proto_family *bt_proto[BT_MAX_PROTO];
-static DEFINE_RWLOCK(bt_proto_rwlock);
+static DEFINE_LW_RWLOCK(bt_proto_rwlock);
int bt_sock_register(int proto, struct net_proto_family *ops)
{
@@ -65,12 +66,12 @@ int bt_sock_register(int proto, struct n
err = -EEXIST;
- write_lock(&bt_proto_rwlock);
+ lw_write_lock(&bt_proto_rwlock);
if (bt_proto[proto] == NULL) {
err = 0;
bt_proto[proto] = ops;
}
- write_unlock(&bt_proto_rwlock);
+ lw_write_unlock(&bt_proto_rwlock);
return err;
}
@@ -84,12 +85,12 @@ int bt_sock_unregister(int proto)
return -EINVAL;
err = -ENOENT;
- write_lock(&bt_proto_rwlock);
+ lw_write_lock(&bt_proto_rwlock);
if (bt_proto[proto]) {
err = 0;
bt_proto[proto] = NULL;
}
- write_unlock(&bt_proto_rwlock);
+ lw_write_unlock(&bt_proto_rwlock);
return err;
}
@@ -108,12 +109,12 @@ static int bt_sock_create(struct socket
}
#endif
err = -EPROTONOSUPPORT;
- read_lock(&bt_proto_rwlock);
+ lw_read_lock(&bt_proto_rwlock);
if (bt_proto[proto] && try_module_get(bt_proto[proto]->owner)) {
err = bt_proto[proto]->create(sock, proto);
module_put(bt_proto[proto]->owner);
}
- read_unlock(&bt_proto_rwlock);
+ lw_read_unlock(&bt_proto_rwlock);
return err;
}
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [01/04 mm-patch, rfc] Add lightweight rwlock
2006-07-28 16:15 ` [01/04 mm-patch, rfc] Add lightweight rwlock (was Re: [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc) Frederik Deweerdt
2006-07-28 16:23 ` [02/04 " Frederik Deweerdt
@ 2006-07-31 7:06 ` Masatake YAMATO
2006-08-01 9:06 ` Frederik Deweerdt
1 sibling, 1 reply; 107+ messages in thread
From: Masatake YAMATO @ 2006-07-31 7:06 UTC (permalink / raw)
To: deweerdt; +Cc: linux-kernel, akpm, acme, marcel
Hi,
> The following set of patches adds a struct lw_rwlock (for lightweight
> rwlock) which contains a spin_lock_t and an atomic_t. It is defined
> in include/linux/lw_rwlock.h.
I think the name, "lightweight" is too generic. It implies just lw_rwlock
is better than rwlock. The name may lead that people use lw_rwlock rather
than rwlock any place through there are places where rwlock is better than
lw_rwlock. So I looked for the name:
sw_rwlock: seldom writing rwlock
wp_rwlock: write pricey rwlock
rp_rwlock: read prioritized rwlock
If you could find good one, plesae use it instead.
Masatake YAMATO
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [01/04 mm-patch, rfc] Add lightweight rwlock
2006-07-31 7:06 ` [01/04 mm-patch, rfc] Add lightweight rwlock Masatake YAMATO
@ 2006-08-01 9:06 ` Frederik Deweerdt
0 siblings, 0 replies; 107+ messages in thread
From: Frederik Deweerdt @ 2006-08-01 9:06 UTC (permalink / raw)
To: Masatake YAMATO; +Cc: linux-kernel, akpm, acme, marcel
On Mon, Jul 31, 2006 at 04:06:15PM +0900, Masatake YAMATO wrote:
Hi,
> > The following set of patches adds a struct lw_rwlock (for lightweight
> > rwlock) which contains a spin_lock_t and an atomic_t. It is defined
> > in include/linux/lw_rwlock.h.
>
> I think the name, "lightweight" is too generic.
Fair enough.
> It implies just lw_rwlock is better than rwlock. The name may lead that people
> use lw_rwlock rather than rwlock any place through there are places where
> rwlock is better than lw_rwlock. So I looked for the name:
>
> sw_rwlock: seldom writing rwlock
> wp_rwlock: write pricey rwlock
write expensive, we_rwlock? I like your idea of stressing the fact that
the protected data has to be seldom modified if you intend to use this
kind of lock.
> rp_rwlock: read prioritized rwlock
>
I'll re-submit the patch with a proper naming for the rc3-mm1. However, I'd
like to get some feedback on the code itself: the current
whatever_rwlock code won't be debuggable with lockdep, and I'm not sure
there's not some more clever way to do it.
Thanks,
Frederik
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (9 preceding siblings ...)
2006-07-28 8:35 ` [mm-patch] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc Frederik Deweerdt
@ 2006-07-28 8:56 ` Michal Piotrowski
2006-07-28 9:23 ` 2.6.18-rc2-mm1 Andrew Morton
2006-07-28 15:53 ` [PATCH] 2.6.18-rc2-mm1 i386 add_memory_region undefined Valdis.Kletnieks
` (8 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Michal Piotrowski @ 2006-07-28 8:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 27/07/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
[snip]
> - Semi-daily snapshots of the -mm lineup are uploaded to
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
> the mm-commits list.
Andrew, have you considered switching that tree to git? IMHO
git-bisect is a killer-app.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 107+ messages in thread* [PATCH] 2.6.18-rc2-mm1 i386 add_memory_region undefined
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (10 preceding siblings ...)
2006-07-28 8:56 ` 2.6.18-rc2-mm1 Michal Piotrowski
@ 2006-07-28 15:53 ` Valdis.Kletnieks
2006-07-28 18:20 ` 2.6.18-rc2-mm1 - hard lockups on Dell C840 Valdis.Kletnieks
` (7 subsequent siblings)
19 siblings, 0 replies; 107+ messages in thread
From: Valdis.Kletnieks @ 2006-07-28 15:53 UTC (permalink / raw)
To: Andrew Morton, Edgar Hucek; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On Thu, 27 Jul 2006 01:56:39 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
Building with -Werror-implicit-function-declaration fails:
CC arch/i386/pci/mmconfig.o
arch/i386/pci/mmconfig.c: In function 'pci_mmcfg_force':
arch/i386/pci/mmconfig.c:232: error: implicit declaration of function 'add_memory_region'
Problem is a missing #include, patch attached. Problem was introduced by
add-force-of-use-mmconfig.patch. This is a bug even without the -Werror, as the
implicit declaration doesn't match the real one.
Patch attached.
Signed-Off-By: Valdis Kletnieks <valdis.kletnieks@vt.edu>
--- linux-2.6.18-rc2-mm1/arch/i386/pci/mmconfig.c.broken 2006-07-28 10:21:59.000000000 -0400
+++ linux-2.6.18-rc2-mm1/arch/i386/pci/mmconfig.c 2006-07-28 11:45:30.000000000 -0400
@@ -15,6 +15,7 @@
#include <linux/dmi.h>
#include <linux/efi.h>
#include <asm/e820.h>
+#include <asm/setup.h>
#include "pci.h"
/* aperture is up to 256MB but BIOS may reserve less */
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1 - hard lockups on Dell C840
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (11 preceding siblings ...)
2006-07-28 15:53 ` [PATCH] 2.6.18-rc2-mm1 i386 add_memory_region undefined Valdis.Kletnieks
@ 2006-07-28 18:20 ` Valdis.Kletnieks
2006-07-28 18:44 ` 2.6.18-rc2-mm1 timer int 0 doesn't work Paul Fulghum
` (6 subsequent siblings)
19 siblings, 0 replies; 107+ messages in thread
From: Valdis.Kletnieks @ 2006-07-28 18:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
On Thu, 27 Jul 2006 01:56:39 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
I'm seeing pseudorandom hard lockups soon after boot on a Dell Latitude C840.
It just siezes up, even alt-sysrq is totally wedged, need to power cycle to
recover. There doesn't seem to be a really obvious trigger - the first time it
died after all the /etc/rc5.d scripts, while trying to start the X server. The
second, I brought it up single-user, and it didn't even live long enough to
give me a prompt. Multiple attempts hung at different places, but always
within 2-3 minutes.
2.6.18-rc1-mm1 works fine, as does 2.6.18-rc2 plus origin.patch and git-libata-all.patch
(vanilla -rc2 won't recognize my piix controller, not in a mood to reconfigure
to use ide rather than libata).
Off to go play bisect-the-mm, though it may be later in weekend before I
finish that...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 107+ messages in thread* 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (12 preceding siblings ...)
2006-07-28 18:20 ` 2.6.18-rc2-mm1 - hard lockups on Dell C840 Valdis.Kletnieks
@ 2006-07-28 18:44 ` Paul Fulghum
2006-07-28 21:48 ` Andrew Morton
2006-07-28 19:46 ` Kubuntu's udev broken with 2.6.18-rc2-mm1 Andrew James Wade
` (5 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Paul Fulghum @ 2006-07-28 18:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
2.6.18-rc2-mm1 causes boot to fail early with:
kernel panic: IO_APIC timer interrupt 0 doesn't work
2.6.18-rc2 works.
2.6.18-rc2-mm1 kernel config located at:
http://www.microgate.com/ftp/linux/test/config
syslog from working 2.6.18-rc2 located at:
http://www.microgate.com/ftp/linux/test/syslog
--
Paul Fulghum
Microgate Systems, Ltd
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-28 18:44 ` 2.6.18-rc2-mm1 timer int 0 doesn't work Paul Fulghum
@ 2006-07-28 21:48 ` Andrew Morton
2006-07-28 22:10 ` Paul Fulghum
2006-07-28 23:38 ` Andi Kleen
0 siblings, 2 replies; 107+ messages in thread
From: Andrew Morton @ 2006-07-28 21:48 UTC (permalink / raw)
To: Paul Fulghum; +Cc: linux-kernel, Andi Kleen, Ingo Molnar, Eric W. Biederman
On Fri, 28 Jul 2006 13:44:36 -0500
Paul Fulghum <paulkf@microgate.com> wrote:
> 2.6.18-rc2-mm1 causes boot to fail early with:
> kernel panic: IO_APIC timer interrupt 0 doesn't work
>
> 2.6.18-rc2 works.
>
> 2.6.18-rc2-mm1 kernel config located at:
> http://www.microgate.com/ftp/linux/test/config
>
> syslog from working 2.6.18-rc2 located at:
> http://www.microgate.com/ftp/linux/test/syslog
>
I don't know what would have caused this. Was 2.6.18-rc1-mm2 OK?
Patches which touch arch/i386/kernel/io_apic.c are:
x86_64-mm-i386-up-generic-arch.patch
x86_64-mm-i386-io-apic-access.patch
genirq-convert-the-i386-architecture-to-irq-chips.patch
initial-generic-hypertransport-interrupt-support.patch
genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector.patch
genirq-i386-irq-move-msi-message-composition-into-io_apicc.patch
genirq-i386-irq-dynamic-irq-support.patch
The developers of those patches are cc'ed.
A bisection search would be useful, if you have the time. I'd zero in on
the x86_64 tree initially. Perhaps x86_64-mm-i386-io-apic-access.patch.
Or it could be something else altogether.
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-28 21:48 ` Andrew Morton
@ 2006-07-28 22:10 ` Paul Fulghum
2006-07-28 23:38 ` Andi Kleen
1 sibling, 0 replies; 107+ messages in thread
From: Paul Fulghum @ 2006-07-28 22:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Andi Kleen, Ingo Molnar, Eric W. Biederman
Andrew Morton wrote:
> I don't know what would have caused this. Was 2.6.18-rc1-mm2 OK?
I have not tried that combination.
> Patches which touch arch/i386/kernel/io_apic.c are:
>
> x86_64-mm-i386-up-generic-arch.patch
> x86_64-mm-i386-io-apic-access.patch
> genirq-convert-the-i386-architecture-to-irq-chips.patch
> initial-generic-hypertransport-interrupt-support.patch
> genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector.patch
> genirq-i386-irq-move-msi-message-composition-into-io_apicc.patch
> genirq-i386-irq-dynamic-irq-support.patch
>
> The developers of those patches are cc'ed.
>
> A bisection search would be useful, if you have the time. I'd zero in on
> the x86_64 tree initially. Perhaps x86_64-mm-i386-io-apic-access.patch.
>
> Or it could be something else altogether.
The machine in question is at the office so I won't be able
to test that particular setup this weekend. I will test removing
the listed patches as time permits starting on Monday.
It happens every time so there is no problem in reproducing it.
I will also test 2.6.18-rc2-mm1 on my home machine which
is AMDx2 as well (but a different chipset/MB).
--
Paul
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-28 21:48 ` Andrew Morton
2006-07-28 22:10 ` Paul Fulghum
@ 2006-07-28 23:38 ` Andi Kleen
2006-07-29 0:15 ` Paul Fulghum
2006-07-29 15:33 ` Paul Fulghum
1 sibling, 2 replies; 107+ messages in thread
From: Andi Kleen @ 2006-07-28 23:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: Paul Fulghum, linux-kernel, Ingo Molnar, Eric W. Biederman
> > syslog from working 2.6.18-rc2 located at:
> > http://www.microgate.com/ftp/linux/test/syslog
What happened to the new lines? It looks like a bad alphabet soup
Do you perhaps have a boot log from before 2.6.17 (e.g. 2.6.16)?
Preferably with newlines.
>
> A bisection search would be useful, if you have the time. I'd zero in on
> the x86_64 tree initially. Perhaps x86_64-mm-i386-io-apic-access.patch.
It's remove-timer-fallback likely. I was working on that already.
Some boards go into the timer fallback path since 2.6.17/64bit for so
far unknown reasons and that doesn't work anymore because I removed the
fallback path.
-Andi
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-28 23:38 ` Andi Kleen
@ 2006-07-29 0:15 ` Paul Fulghum
2006-07-29 1:16 ` Paul Fulghum
2006-07-29 15:33 ` Paul Fulghum
1 sibling, 1 reply; 107+ messages in thread
From: Paul Fulghum @ 2006-07-29 0:15 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Ingo Molnar, Eric W. Biederman
On Sat, 2006-07-29 at 01:38 +0200, Andi Kleen wrote:
> What happened to the new lines? It looks like a bad alphabet soup
When I download and edit syslog from the specified URL, it has newlines.
> Do you perhaps have a boot log from before 2.6.17 (e.g. 2.6.16)?
I can get a syslog from < 2.6.17
but not right now as that machine is at the office.
> It's remove-timer-fallback likely. I was working on that already.
>
> Some boards go into the timer fallback path since 2.6.17/64bit for so
> far unknown reasons and that doesn't work anymore because I removed the
> fallback path.
I might burn some time tomorrow and go into the office
to try removing that patch. By Monday at the latest.
I'm doing a build on my home machine now to see if it
happens there also.
--
Paul
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 0:15 ` Paul Fulghum
@ 2006-07-29 1:16 ` Paul Fulghum
2006-07-29 1:24 ` Andrew Morton
2006-07-29 2:36 ` Andi Kleen
0 siblings, 2 replies; 107+ messages in thread
From: Paul Fulghum @ 2006-07-29 1:16 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Ingo Molnar, Eric W. Biederman
On Fri, 2006-07-28 at 19:15 -0500, Paul Fulghum wrote:
> I'm doing a build on my home machine now to see if it
> happens there also.
Well, the timer int 0 problem does not happen on my home machine.
However, it still crashes in early boot for a different reason.
2.6.18-rc2 works fine with same config.
In this case the error is:
No per-cpu room for modules
...
insmod:error interting '/lib/scsi_mod.ko' -1 cannot allocate memory
...
[other modules depending on scsi_mod.ko fail to load]
...
kernel panic - Attempted to kill init - d000
Woof! (said the dog because the cow said moo)
syslog from working 2.6.18-rc2 below:
Jul 28 20:01:23 localhost kernel: Linux version 2.6.18-rc2 (paulkf@localhost.localdomain) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Fri Jul 28 19:52:34 CDT 2006
Jul 28 20:01:23 localhost kernel: BIOS-provided physical RAM map:
Jul 28 20:01:23 localhost kernel: BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
Jul 28 20:01:23 localhost kernel: BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
Jul 28 20:01:23 localhost kernel: BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Jul 28 20:01:23 localhost kernel: BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
Jul 28 20:01:23 localhost kernel: BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS)
Jul 28 20:01:23 localhost kernel: BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data)
Jul 28 20:01:23 localhost kernel: BIOS-e820: 00000000d0000000 - 00000000e0000000 (reserved)
Jul 28 20:01:23 localhost kernel: BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Jul 28 20:01:23 localhost kernel: DMI 2.3 present.
Jul 28 20:01:24 localhost rpc.statd[1926]: Version 1.0.8-rc2 Starting
Jul 28 20:01:25 localhost kernel: Scanning NUMA topology in Northbridge 24
Jul 28 20:01:25 localhost kernel: Number of nodes 1
Jul 28 20:01:25 localhost kernel: Node 0 MemBase 0000000000000000 Limit 000000007fff0000
Jul 28 20:01:25 localhost kernel: Using node hash shift of 63
Jul 28 20:01:25 localhost kernel: Bootmem setup node 0 0000000000000000-000000007fff0000
Jul 28 20:01:25 localhost kernel: Nvidia board detected. Ignoring ACPI timer override.
Jul 28 20:01:25 localhost kernel: ACPI: PM-Timer IO Port: 0x1008
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Jul 28 20:01:25 localhost kernel: Processor #0 15:11 APIC version 16
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Jul 28 20:01:25 localhost kernel: Processor #1 15:11 APIC version 16
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
Jul 28 20:01:25 localhost kernel: ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
Jul 28 20:01:25 localhost kernel: IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Jul 28 20:01:25 localhost kernel: ACPI: BIOS IRQ0 pin2 override ignored.
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Jul 28 20:01:25 localhost kernel: Setting APIC routing to physical flat
Jul 28 20:01:25 localhost kernel: Using ACPI (MADT) for SMP configuration information
Jul 28 20:01:25 localhost kernel: Allocating PCI resources starting at 88000000 (gap: 80000000:50000000)
Jul 28 20:01:25 localhost kernel: SMP: Allowing 2 CPUs, 0 hotplug CPUs
Jul 28 20:01:25 localhost kernel: Built 1 zonelists. Total pages: 514549
Jul 28 20:01:25 localhost kernel: Kernel command line: ro root=LABEL=/1 rhgb quiet
Jul 28 20:01:25 localhost kernel: Initializing CPU#0
Jul 28 20:01:25 localhost kernel: PID hash table entries: 4096 (order: 12, 32768 bytes)
Jul 28 20:01:25 localhost kernel: Disabling vsyscall due to use of PM timer
Jul 28 20:01:25 localhost kernel: time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
Jul 28 20:01:25 localhost kernel: time.c: Detected 2010.330 MHz processor.
Jul 28 20:01:25 localhost kernel: Console: colour VGA+ 80x25
Jul 28 20:01:25 localhost kernel: Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Jul 28 20:01:25 localhost kernel: Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Jul 28 20:01:25 localhost kernel: Checking aperture...
Jul 28 20:01:25 localhost kernel: CPU 0: aperture @ 2ea0000000 size 32 MB
Jul 28 20:01:25 localhost kernel: Aperture too small (32 MB)
Jul 28 20:01:25 localhost kernel: No AGP bridge found
Jul 28 20:01:25 localhost kernel: Memory: 2053824k/2097088k available (2316k kernel code, 42876k reserved, 1238k data, 204k init)
Jul 28 20:01:25 localhost kernel: Calibrating delay using timer specific routine.. 4023.90 BogoMIPS (lpj=8047819)
Jul 28 20:01:25 localhost kernel: Security Framework v1.0.0 initialized
Jul 28 20:01:25 localhost kernel: SELinux: Initializing.
Jul 28 20:01:25 localhost kernel: SELinux: Starting in permissive mode
Jul 28 20:01:25 localhost kernel: selinux_register_security: Registering secondary module capability
Jul 28 20:01:25 localhost kernel: Capability LSM initialized as secondary
Jul 28 20:01:25 localhost kernel: Mount-cache hash table entries: 256
Jul 28 20:01:25 localhost kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU: L2 Cache: 512K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU 0/0 -> Node 0
Jul 28 20:01:25 localhost kernel: CPU: Physical Processor ID: 0
Jul 28 20:01:25 localhost kernel: CPU: Processor Core ID: 0
Jul 28 20:01:25 localhost kernel: SMP alternatives: switching to UP code
Jul 28 20:01:25 localhost kernel: ACPI: Core revision 20060707
Jul 28 20:01:25 localhost kernel: Using local APIC timer interrupts.
Jul 28 20:01:25 localhost kernel: result 12564579
Jul 28 20:01:25 localhost kernel: Detected 12.564 MHz APIC timer.
Jul 28 20:01:25 localhost kernel: SMP alternatives: switching to SMP code
Jul 28 20:01:25 localhost kernel: Booting processor 1/2 APIC 0x1
Jul 28 20:01:25 localhost kernel: Initializing CPU#1
Jul 28 20:01:25 localhost kernel: Calibrating delay using timer specific routine.. 4020.89 BogoMIPS (lpj=8041781)
Jul 28 20:01:25 localhost kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU: L2 Cache: 512K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU 1/1 -> Node 0
Jul 28 20:01:25 localhost kernel: CPU: Physical Processor ID: 0
Jul 28 20:01:25 localhost kernel: CPU: Processor Core ID: 1
Jul 28 20:01:25 localhost kernel: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 01
Jul 28 20:01:25 localhost kernel: CPU 1: Syncing TSC to CPU 0.
Jul 28 20:01:25 localhost kernel: CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 566 cycles)
Jul 28 20:01:25 localhost kernel: Brought up 2 CPUs
Jul 28 20:01:25 localhost kernel: testing NMI watchdog ... OK.
Jul 28 20:01:25 localhost kernel: migration_cost=253
Jul 28 20:01:25 localhost kernel: checking if image is initramfs... it is
Jul 28 20:01:25 localhost kernel: Freeing initrd memory: 1078k freed
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 16
Jul 28 20:01:25 localhost kernel: ACPI: bus type pci registered
Jul 28 20:01:25 localhost kernel: PCI: Using MMCONFIG at d0000000
Jul 28 20:01:25 localhost kernel: PCI: No mmconfig possible on device 0:18
Jul 28 20:01:25 localhost kernel: ACPI: Interpreter enabled
Jul 28 20:01:25 localhost kernel: ACPI: Using IOAPIC for interrupt routing
Jul 28 20:01:25 localhost kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Jul 28 20:01:25 localhost kernel: PCI: Transparent bridge - 0000:00:09.0
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 7 9 *10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 *5 7 9 10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 7 9 10 11 *12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 7 9 *10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LUB2] (IRQs *3 4 5 7 9 10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Jul 28 20:01:25 localhost kernel: pnp: PnP ACPI init
Jul 28 20:01:25 localhost kernel: pnp: PnP ACPI: found 12 devices
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver usbfs
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver hub
Jul 28 20:01:25 localhost kernel: PCI: Using ACPI for IRQ routing
Jul 28 20:01:25 localhost kernel: PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
Jul 28 20:01:25 localhost kernel: PCI-DMA: Disabling IOMMU.
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1000-0x107f could not be reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1080-0x10ff has been reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1400-0x147f has been reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1480-0x14ff could not be reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1800-0x187f has been reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1880-0x18ff has been reserved
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:09.0
Jul 28 20:01:25 localhost kernel: IO window: disabled.
Jul 28 20:01:25 localhost kernel: MEM window: f3000000-f30fffff
Jul 28 20:01:25 localhost kernel: PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0b.0
Jul 28 20:01:25 localhost kernel: IO window: a000-afff
Jul 28 20:01:25 localhost kernel: MEM window: disabled.
Jul 28 20:01:25 localhost kernel: PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0c.0
Jul 28 20:01:25 localhost kernel: IO window: 9000-9fff
Jul 28 20:01:25 localhost kernel: MEM window: disabled.
Jul 28 20:01:25 localhost kernel: PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0d.0
Jul 28 20:01:25 localhost kernel: IO window: 8000-8fff
Jul 28 20:01:25 localhost kernel: MEM window: disabled.
Jul 28 20:01:25 localhost kernel: PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0e.0
Jul 28 20:01:25 localhost kernel: IO window: b000-bfff
Jul 28 20:01:25 localhost kernel: MEM window: f0000000-f2ffffff
Jul 28 20:01:25 localhost kernel: PREFETCH window: e0000000-efffffff
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 2
Jul 28 20:01:25 localhost kernel: IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
Jul 28 20:01:25 localhost kernel: TCP established hash table entries: 131072 (order: 10, 4194304 bytes)
Jul 28 20:01:25 localhost kernel: TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
Jul 28 20:01:25 localhost kernel: TCP: Hash tables configured (established 131072 bind 65536)
Jul 28 20:01:25 localhost kernel: TCP reno registered
Jul 28 20:01:25 localhost kernel: audit: initializing netlink socket (disabled)
Jul 28 20:01:25 localhost kernel: audit(1154116852.688:1): initialized
Jul 28 20:01:25 localhost kernel: Total HugeTLB memory allocated, 0
Jul 28 20:01:25 localhost kernel: VFS: Disk quotas dquot_6.5.1
Jul 28 20:01:25 localhost kernel: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Jul 28 20:01:25 localhost kernel: SELinux: Registering netfilter hooks
Jul 28 20:01:25 localhost kernel: Initializing Cryptographic API
Jul 28 20:01:25 localhost kernel: io scheduler noop registered
Jul 28 20:01:25 localhost kernel: io scheduler anticipatory registered
Jul 28 20:01:25 localhost kernel: io scheduler deadline registered
Jul 28 20:01:25 localhost kernel: io scheduler cfq registered (default)
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0b.0
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0c.0
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0d.0
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0e.0
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Jul 28 20:01:25 localhost kernel: Real Time Clock Driver v1.12ac
Jul 28 20:01:25 localhost kernel: Linux agpgart interface v0.101 (c) Dave Jones
Jul 28 20:01:25 localhost kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
Jul 28 20:01:25 localhost kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jul 28 20:01:25 localhost kernel: 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jul 28 20:01:25 localhost kernel: RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Jul 28 20:01:25 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
Jul 28 20:01:25 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: chipset revision 162
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: not 100% native mode: will probe irqs later
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: 0000:00:06.0 (rev a2) UDMA133 controller
Jul 28 20:01:25 localhost kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Jul 28 20:01:25 localhost kernel: hda: _NEC DVD_RW ND-3540A, ATAPI CD/DVD-ROM drive
Jul 28 20:01:25 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jul 28 20:01:25 localhost kernel: hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Jul 28 20:01:25 localhost kernel: Uniform CD-ROM driver Revision: 3.20
Jul 28 20:01:25 localhost kernel: ide-floppy driver 0.99.newide
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver libusual
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver hiddev
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver usbhid
Jul 28 20:01:25 localhost kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver
Jul 28 20:01:25 localhost kernel: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
Jul 28 20:01:25 localhost kernel: PNP: PS/2 controller doesn't have AUX irq; using default 12
Jul 28 20:01:25 localhost kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Jul 28 20:01:25 localhost kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Jul 28 20:01:25 localhost kernel: mice: PS/2 mouse device common for all mice
Jul 28 20:01:25 localhost kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
Jul 28 20:01:25 localhost kernel: md: bitmap version 4.39
Jul 28 20:01:25 localhost kernel: TCP bic registered
Jul 28 20:01:25 localhost kernel: Initializing IPsec netlink socket
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 1
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 17
Jul 28 20:01:25 localhost kernel: powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
Jul 28 20:01:25 localhost kernel: powernow-k8: invalid freq entries 3900000 kHz vs. 65535000 kHz
Jul 28 20:01:25 localhost last message repeated 3 times
Jul 28 20:01:25 localhost kernel: powernow-k8: 0 : fid 0xc (2000 MHz), vid 0x8
Jul 28 20:01:25 localhost kernel: powernow-k8: 1 : fid 0x2 (1000 MHz), vid 0x12
Jul 28 20:01:25 localhost kernel: ACPI: (supports S0 S1 S4 S5)
Jul 28 20:01:25 localhost kernel: Freeing unused kernel memory: 204k freed
Jul 28 20:01:25 localhost kernel: Write protecting the kernel read-only data: 464k
Jul 28 20:01:25 localhost kernel: SCSI subsystem initialized
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23
Jul 28 20:01:25 localhost kernel: GSI 16 sharing vector 0xB1 and IRQ 16
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 16
Jul 28 20:01:25 localhost kernel: ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE000 irq 16
Jul 28 20:01:25 localhost kernel: ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE008 irq 16
Jul 28 20:01:25 localhost kernel: scsi0 : sata_nv
Jul 28 20:01:25 localhost kernel: input: AT Translated Set 2 keyboard as /class/input/input0
Jul 28 20:01:25 localhost kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Jul 28 20:01:25 localhost kernel: ata1.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32)
Jul 28 20:01:25 localhost kernel: ata1.00: ata1: dev 0 multi count 16
Jul 28 20:01:25 localhost kernel: ata1.00: configured for UDMA/133
Jul 28 20:01:25 localhost kernel: scsi1 : sata_nv
Jul 28 20:01:25 localhost kernel: ata2: SATA link down (SStatus 0 SControl 300)
Jul 28 20:01:25 localhost kernel: Vendor: ATA Model: Maxtor 7L300S0 Rev: BANC
Jul 28 20:01:25 localhost kernel: Type: Direct-Access ANSI SCSI revision: 05
Jul 28 20:01:25 localhost kernel: SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
Jul 28 20:01:25 localhost kernel: sda: Write Protect is off
Jul 28 20:01:25 localhost kernel: SCSI device sda: drive cache: write back
Jul 28 20:01:25 localhost kernel: SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
Jul 28 20:01:25 localhost kernel: sda: Write Protect is off
Jul 28 20:01:25 localhost kernel: SCSI device sda: drive cache: write back
Jul 28 20:01:25 localhost kernel: sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
Jul 28 20:01:25 localhost kernel: sd 0:0:0:0: Attached scsi disk sda
Jul 28 20:01:25 localhost kernel: kjournald starting. Commit interval 5 seconds
Jul 28 20:01:25 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 28 20:01:25 localhost kernel: audit(1154116856.620:2): enforcing=1 old_enforcing=0 auid=4294967295
Jul 28 20:01:25 localhost kernel: security: 3 users, 6 roles, 1417 types, 151 bools, 1 sens, 256 cats
Jul 28 20:01:25 localhost kernel: security: 57 classes, 41080 rules
Jul 28 20:01:25 localhost kernel: SELinux: Completing initialization.
Jul 28 20:01:25 localhost kernel: SELinux: Setting up existing superblocks.
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev sda8, type ext3), uses xattr
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev devpts, type devpts), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev cpuset, type cpuset), not configured for labeling
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: audit(1154116856.892:3): policy loaded auid=4294967295
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: audit(1154134859.998:4): avc: denied { audit_write } for pid=469 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
Jul 28 20:01:25 localhost kernel: input: PC Speaker as /class/input/input1
Jul 28 20:01:25 localhost kernel: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 22
Jul 28 20:01:25 localhost kernel: GSI 17 sharing vector 0xB9 and IRQ 17
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 22 (level, low) -> IRQ 17
Jul 28 20:01:25 localhost kernel: forcedeth: using HIGHDMA
Jul 28 20:01:25 localhost kernel: eth0: forcedeth.c: subsystem: 01458:e000 bound to 0000:00:0a.0
Jul 28 20:01:25 localhost kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x1c00
Jul 28 20:01:25 localhost kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x1c40
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 21
Jul 28 20:01:25 localhost kernel: GSI 18 sharing vector 0xC1 and IRQ 18
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 21 (level, low) -> IRQ 18
Jul 28 20:01:25 localhost kernel: intel8x0_measure_ac97_clock: measured 58545 usecs
Jul 28 20:01:25 localhost kernel: intel8x0: clocking to 46966
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
Jul 28 20:01:25 localhost kernel: GSI 19 sharing vector 0xC9 and IRQ 19
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 19
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 20
Jul 28 20:01:25 localhost kernel: GSI 20 sharing vector 0xD1 and IRQ 20
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 20 (level, low) -> IRQ 20
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: EHCI Host Controller
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: debug port 1
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: irq 20, io mem 0xfeb00000
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Jul 28 20:01:25 localhost kernel: usb usb1: configuration #1 chosen from 1 choice
Jul 28 20:01:25 localhost kernel: hub 1-0:1.0: USB hub found
Jul 28 20:01:25 localhost kernel: hub 1-0:1.0: 10 ports detected
Jul 28 20:01:25 localhost kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19] MMIO=[f3004000-f30047ff] Max Packet=[4096] IR/IT contexts=[4/8]
Jul 28 20:01:25 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 23 (level, low) -> IRQ 16
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: OHCI Host Controller
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: irq 16, io mem 0xf3101000
Jul 28 20:01:25 localhost kernel: usb usb2: configuration #1 chosen from 1 choice
Jul 28 20:01:25 localhost kernel: hub 2-0:1.0: USB hub found
Jul 28 20:01:25 localhost kernel: hub 2-0:1.0: 10 ports detected
Jul 28 20:01:25 localhost kernel: usb 1-6: new high speed USB device using ehci_hcd and address 2
Jul 28 20:01:25 localhost kernel: usb 1-6: configuration #1 chosen from 1 choice
Jul 28 20:01:25 localhost kernel: hub 1-6:1.0: USB hub found
Jul 28 20:01:25 localhost kernel: hub 1-6:1.0: 4 ports detected
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: wakeup
Jul 28 20:01:25 localhost kernel: Non-volatile memory driver v1.2
Jul 28 20:01:25 localhost kernel: usb 1-6.1: new full speed USB device using ehci_hcd and address 5
Jul 28 20:01:25 localhost kernel: usb 1-6.1: configuration #1 chosen from 1 choice
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 1:16 ` Paul Fulghum
@ 2006-07-29 1:24 ` Andrew Morton
2006-07-29 2:37 ` Paul Fulghum
` (2 more replies)
2006-07-29 2:36 ` Andi Kleen
1 sibling, 3 replies; 107+ messages in thread
From: Andrew Morton @ 2006-07-29 1:24 UTC (permalink / raw)
To: Paul Fulghum; +Cc: ak, linux-kernel, mingo, ebiederm
On Fri, 28 Jul 2006 20:16:32 -0500
Paul Fulghum <paulkf@microgate.com> wrote:
> On Fri, 2006-07-28 at 19:15 -0500, Paul Fulghum wrote:
> > I'm doing a build on my home machine now to see if it
> > happens there also.
>
> Well, the timer int 0 problem does not happen on my home machine.
> However, it still crashes in early boot for a different reason.
>
> 2.6.18-rc2 works fine with same config.
>
> In this case the error is:
>
> No per-cpu room for modules
yeah, sorry, that's a known problem which nobody appears to be doing
anything about. The expansion of NR_IRQS gobbles all the percpu memory in
the kstat structure.
I assume you have a large NR_CPUS? Decreasing it should help.
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 1:24 ` Andrew Morton
@ 2006-07-29 2:37 ` Paul Fulghum
2006-07-29 2:58 ` Eric W. Biederman
2006-07-29 4:03 ` Ingo Molnar
2 siblings, 0 replies; 107+ messages in thread
From: Paul Fulghum @ 2006-07-29 2:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: ak, linux-kernel, mingo, ebiederm
On Fri, 2006-07-28 at 18:24 -0700, Andrew Morton wrote:
> yeah, sorry, that's a known problem which nobody appears to be doing
> anything about. The expansion of NR_IRQS gobbles all the percpu memory in
> the kstat structure.
>
> I assume you have a large NR_CPUS? Decreasing it should help.
It was using the Fedora Core 5 default of 255.
Reducing it to 2 makes it work.
So the timer int 0 problem is specific to the machine.
I'm guessing that the cheap HP machine using the ATI chipset
is one of the boards Andi was talking about.
--
Paul
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 1:24 ` Andrew Morton
2006-07-29 2:37 ` Paul Fulghum
@ 2006-07-29 2:58 ` Eric W. Biederman
2006-07-29 4:03 ` Ingo Molnar
2 siblings, 0 replies; 107+ messages in thread
From: Eric W. Biederman @ 2006-07-29 2:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: Paul Fulghum, ak, linux-kernel, mingo
Andrew Morton <akpm@osdl.org> writes:
> On Fri, 28 Jul 2006 20:16:32 -0500
> Paul Fulghum <paulkf@microgate.com> wrote:
>
>> On Fri, 2006-07-28 at 19:15 -0500, Paul Fulghum wrote:
>> > I'm doing a build on my home machine now to see if it
>> > happens there also.
>>
>> Well, the timer int 0 problem does not happen on my home machine.
>> However, it still crashes in early boot for a different reason.
>>
>> 2.6.18-rc2 works fine with same config.
>>
>> In this case the error is:
>>
>> No per-cpu room for modules
>
> yeah, sorry, that's a known problem which nobody appears to be doing
> anything about. The expansion of NR_IRQS gobbles all the percpu memory in
> the kstat structure.
Sorry I didn't realize it was so easy to trip over.
It's on my todo list for sometime in the next couple of days.
> I assume you have a large NR_CPUS? Decreasing it should help.
Eric
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 1:24 ` Andrew Morton
2006-07-29 2:37 ` Paul Fulghum
2006-07-29 2:58 ` Eric W. Biederman
@ 2006-07-29 4:03 ` Ingo Molnar
2006-07-30 23:00 ` Steven Rostedt
2 siblings, 1 reply; 107+ messages in thread
From: Ingo Molnar @ 2006-07-29 4:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: Paul Fulghum, ak, linux-kernel, ebiederm, Steven Rostedt
* Andrew Morton <akpm@osdl.org> wrote:
> > 2.6.18-rc2 works fine with same config.
> >
> > In this case the error is:
> >
> > No per-cpu room for modules
>
> yeah, sorry, that's a known problem which nobody appears to be doing
> anything about. The expansion of NR_IRQS gobbles all the percpu
> memory in the kstat structure.
while the fundamental issue is the NR_IRQS problem which we'll fix
separately, Steve has a patchset to make percpu room dynamic:
http://lkml.org/lkml/2006/4/14/137
Ingo
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 4:03 ` Ingo Molnar
@ 2006-07-30 23:00 ` Steven Rostedt
0 siblings, 0 replies; 107+ messages in thread
From: Steven Rostedt @ 2006-07-30 23:00 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, Paul Fulghum, ak, linux-kernel, ebiederm
On Sat, 2006-07-29 at 06:03 +0200, Ingo Molnar wrote:
> * Andrew Morton <akpm@osdl.org> wrote:
>
> > > 2.6.18-rc2 works fine with same config.
> > >
> > > In this case the error is:
> > >
> > > No per-cpu room for modules
> >
> > yeah, sorry, that's a known problem which nobody appears to be doing
> > anything about. The expansion of NR_IRQS gobbles all the percpu
> > memory in the kstat structure.
>
> while the fundamental issue is the NR_IRQS problem which we'll fix
> separately, Steve has a patchset to make percpu room dynamic:
>
> http://lkml.org/lkml/2006/4/14/137
That implementation was doomed because it added another dereference that
would kill numa implementations. I implemented another version that
used page tables, but some people said that this would waste TLB
entries. See here
http://lwn.net/Articles/184103/
Perhaps another version that might be beneficial is one that mixes the
current approach with this one. That is to have a dynamic page case
that would happen only after a default was exhausted. And then we could
even warn about it if we don't like that. This way we can warn the user
if they don't like having the module's per_cpu files dynamically
allocated, which might slow down the system do to another TLB line
taken.
-- Steve
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 1:16 ` Paul Fulghum
2006-07-29 1:24 ` Andrew Morton
@ 2006-07-29 2:36 ` Andi Kleen
1 sibling, 0 replies; 107+ messages in thread
From: Andi Kleen @ 2006-07-29 2:36 UTC (permalink / raw)
To: Paul Fulghum; +Cc: Andrew Morton, linux-kernel, Ingo Molnar, Eric W. Biederman
On Fri, Jul 28, 2006 at 08:16:32PM -0500, Paul Fulghum wrote:
> On Fri, 2006-07-28 at 19:15 -0500, Paul Fulghum wrote:
> > I'm doing a build on my home machine now to see if it
> > happens there also.
>
> Well, the timer int 0 problem does not happen on my home machine.
Yes, it only happens on a few machines.
> 2.6.18-rc2 works fine with same config.
>
> In this case the error is:
>
> No per-cpu room for modules
That's also a known problem, but a different one.
-Andi
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-28 23:38 ` Andi Kleen
2006-07-29 0:15 ` Paul Fulghum
@ 2006-07-29 15:33 ` Paul Fulghum
2006-07-29 19:50 ` Eric W. Biederman
1 sibling, 1 reply; 107+ messages in thread
From: Paul Fulghum @ 2006-07-29 15:33 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Ingo Molnar, Eric W. Biederman
On Sat, 2006-07-29 at 01:38 +0200, Andi Kleen wrote:
> It's remove-timer-fallback likely. I was working on that already.
>
> Some boards go into the timer fallback path since 2.6.17/64bit for so
> far unknown reasons and that doesn't work anymore because I removed the
> fallback path.
remove-timer-fallback did not reverse cleanly against 2.6.18-rc2-mm1
I tried to patch it up and got it to compile without
errors or warnings. The result was a hard freeze early in
the boot, so I suspect more is necessary to restore that
function.
--
Paul Fulghum
Microgate Systems, Ltd
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 15:33 ` Paul Fulghum
@ 2006-07-29 19:50 ` Eric W. Biederman
2006-07-29 22:05 ` Paul Fulghum
0 siblings, 1 reply; 107+ messages in thread
From: Eric W. Biederman @ 2006-07-29 19:50 UTC (permalink / raw)
To: Paul Fulghum; +Cc: Andi Kleen, Andrew Morton, linux-kernel, Ingo Molnar
Paul Fulghum <paulkf@microgate.com> writes:
> On Sat, 2006-07-29 at 01:38 +0200, Andi Kleen wrote:
>
>> It's remove-timer-fallback likely. I was working on that already.
>>
>> Some boards go into the timer fallback path since 2.6.17/64bit for so
>> far unknown reasons and that doesn't work anymore because I removed the
>> fallback path.
>
> remove-timer-fallback did not reverse cleanly against 2.6.18-rc2-mm1
>
> I tried to patch it up and got it to compile without
> errors or warnings. The result was a hard freeze early in
> the boot, so I suspect more is necessary to restore that
> function.
Any chance you can post the your reversed version of remove-timer-fallback
so we can have a clue about what happened.
Eric
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 19:50 ` Eric W. Biederman
@ 2006-07-29 22:05 ` Paul Fulghum
2006-07-31 5:31 ` Andi Kleen
0 siblings, 1 reply; 107+ messages in thread
From: Paul Fulghum @ 2006-07-29 22:05 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Andi Kleen, Andrew Morton, linux-kernel, Ingo Molnar
Eric W. Biederman wrote:
>>I tried to patch it up and got it to compile without
>>errors or warnings. The result was a hard freeze early in
>>the boot, so I suspect more is necessary to restore that
>>function.
>
>
> Any chance you can post the your reversed version of remove-timer-fallback
> so we can have a clue about what happened.
While I'm taking the time to post my attempt at a reveresed patch,
it would also be useful for the person who originated the
patch to do the same. I'm not an expert on the code in
question, so the participation of the original author
would help speed things along.
--
Paul
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-29 22:05 ` Paul Fulghum
@ 2006-07-31 5:31 ` Andi Kleen
2006-07-31 13:32 ` Paul Fulghum
0 siblings, 1 reply; 107+ messages in thread
From: Andi Kleen @ 2006-07-31 5:31 UTC (permalink / raw)
To: Paul Fulghum; +Cc: Eric W. Biederman, Andrew Morton, linux-kernel, Ingo Molnar
On Sat, Jul 29, 2006 at 05:05:01PM -0500, Paul Fulghum wrote:
> Eric W. Biederman wrote:
> >>I tried to patch it up and got it to compile without
> >>errors or warnings. The result was a hard freeze early in
> >>the boot, so I suspect more is necessary to restore that
> >>function.
> >
> >
> >Any chance you can post the your reversed version of remove-timer-fallback
> >so we can have a clue about what happened.
>
> While I'm taking the time to post my attempt at a reveresed patch,
> it would also be useful for the person who originated the
> patch to do the same. I'm not an expert on the code in
> question, so the participation of the original author
> would help speed things along.
I dropped the patch now - when Andrew resyncs his tree with
mine next time it should be fixed.
Still need to figure out the root cause though.
-Andi
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: 2.6.18-rc2-mm1 timer int 0 doesn't work
2006-07-31 5:31 ` Andi Kleen
@ 2006-07-31 13:32 ` Paul Fulghum
0 siblings, 0 replies; 107+ messages in thread
From: Paul Fulghum @ 2006-07-31 13:32 UTC (permalink / raw)
To: Andi Kleen; +Cc: Eric W. Biederman, Andrew Morton, linux-kernel, Ingo Molnar
Andi Kleen wrote:
> I dropped the patch now - when Andrew resyncs his tree with
> mine next time it should be fixed.
OK
> Still need to figure out the root cause though.
I have a machine that exhibits the problem
should you want me to test a patch.
--
Paul Fulghum
Microgate Systems, Ltd.
^ permalink raw reply [flat|nested] 107+ messages in thread
* Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (13 preceding siblings ...)
2006-07-28 18:44 ` 2.6.18-rc2-mm1 timer int 0 doesn't work Paul Fulghum
@ 2006-07-28 19:46 ` Andrew James Wade
2006-07-27 19:56 ` Andrew Morton
2006-07-29 17:48 ` [-mm patch] security/selinux/hooks.c: make 4 functions static Adrian Bunk
` (4 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Andrew James Wade @ 2006-07-28 19:46 UTC (permalink / raw)
To: Andrew Morton, gregkh; +Cc: linux-kernel
Hello,
Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev
(079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had
bogus permissions (crw-------). I've kludged around the problem by
populating /lib/udev/devices from a good /dev, but I'm assuming the
breakage was unintentional.
Andrew Wade
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-28 19:46 ` Kubuntu's udev broken with 2.6.18-rc2-mm1 Andrew James Wade
@ 2006-07-27 19:56 ` Andrew Morton
2006-07-27 20:12 ` Greg KH
2006-07-27 21:28 ` Valdis.Kletnieks
0 siblings, 2 replies; 107+ messages in thread
From: Andrew Morton @ 2006-07-27 19:56 UTC (permalink / raw)
To: ajwade; +Cc: andrew.j.wade, gregkh, linux-kernel
On Fri, 28 Jul 2006 15:46:08 -0400
Andrew James Wade <andrew.j.wade@gmail.com> wrote:
> Hello,
>
> Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev
> (079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had
> bogus permissions (crw-------). I've kludged around the problem by
> populating /lib/udev/devices from a good /dev, but I'm assuming the
> breakage was unintentional.
>
/dev/null damage is due to a combination of vdso-hash-style-fix.patch and
doing the kernel build as root (don't do that).
I don't know what happened to /dev/mem.
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-27 19:56 ` Andrew Morton
@ 2006-07-27 20:12 ` Greg KH
2006-07-28 14:33 ` Andrew James Wade
2006-07-27 21:28 ` Valdis.Kletnieks
1 sibling, 1 reply; 107+ messages in thread
From: Greg KH @ 2006-07-27 20:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: ajwade, andrew.j.wade, linux-kernel
On Thu, Jul 27, 2006 at 12:56:55PM -0700, Andrew Morton wrote:
> On Fri, 28 Jul 2006 15:46:08 -0400
> Andrew James Wade <andrew.j.wade@gmail.com> wrote:
>
> > Hello,
> >
> > Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev
> > (079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had
> > bogus permissions (crw-------). I've kludged around the problem by
> > populating /lib/udev/devices from a good /dev, but I'm assuming the
> > breakage was unintentional.
> >
>
> /dev/null damage is due to a combination of vdso-hash-style-fix.patch and
> doing the kernel build as root (don't do that).
>
> I don't know what happened to /dev/mem.
Me either. Look in /sys/class/mem/ Is it full of symlinks or real
directories?
If symlinks, your version of udev should be able to handle it properly,
but might have a bug somehow.
Try running udevmonitor and echo a "1" to /sys/class/mem/mem/uevent and
see if udev creates the device properly or not.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-27 20:12 ` Greg KH
@ 2006-07-28 14:33 ` Andrew James Wade
2006-07-30 14:01 ` Laurent Riffard
0 siblings, 1 reply; 107+ messages in thread
From: Andrew James Wade @ 2006-07-28 14:33 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, andrew.j.wade, linux-kernel
On Thursday 27 July 2006 16:12, Greg KH wrote:
> On Thu, Jul 27, 2006 at 12:56:55PM -0700, Andrew Morton wrote:
> > On Fri, 28 Jul 2006 15:46:08 -0400
> > Andrew James Wade <andrew.j.wade@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev
> > > (079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had
> > > bogus permissions (crw-------). I've kludged around the problem by
> > > populating /lib/udev/devices from a good /dev, but I'm assuming the
> > > breakage was unintentional.
> > >
> >
> > /dev/null damage is due to a combination of vdso-hash-style-fix.patch and
> > doing the kernel build as root (don't do that).
> >
> > I don't know what happened to /dev/mem.
>
> Me either. Look in /sys/class/mem/ Is it full of symlinks or real
> directories?
Symlinks.
> If symlinks, your version of udev should be able to handle it properly,
> but might have a bug somehow.
>
> Try running udevmonitor and echo a "1" to /sys/class/mem/mem/uevent and
> see if udev creates the device properly or not.
udevmonitor prints the received event from the kernel [UEVENT]
and the event which udev sends out after rule processing [UDEV]
UEVENT[1154093169.330045] add@/devices/mem
UDEV [1154093169.331914] add@/devices/mem
The device node was not created.
udev.log for 2.6.18-rc1-mm2 (which does work) has these lines:
UEVENT[1154105360.092631] add@/class/mem/mem
ACTION=add
DEVPATH=/class/mem/mem
SUBSYSTEM=mem
SEQNUM=589
MAJOR=1
MINOR=1
...
UDEV [1154105363.575086] add@/class/mem/mem
UDEV_LOG=3
ACTION=add
DEVPATH=/class/mem/mem
SUBSYSTEM=mem
SEQNUM=589
MAJOR=1
MINOR=1
UDEVD_EVENT=1
DEVNAME=/dev/mem
The Changelog for udev v081 has:
"prepare moving of /sys/class devices to /sys/devices"
Is this related?
Thanks,
Andrew Wade
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-28 14:33 ` Andrew James Wade
@ 2006-07-30 14:01 ` Laurent Riffard
2006-07-31 0:03 ` Greg KH
0 siblings, 1 reply; 107+ messages in thread
From: Laurent Riffard @ 2006-07-30 14:01 UTC (permalink / raw)
To: ajwade; +Cc: Andrew Morton, andrew.j.wade, linux-kernel, Greg KH
Le 28.07.2006 16:33, Andrew James Wade a écrit :
> On Thursday 27 July 2006 16:12, Greg KH wrote:
>> On Thu, Jul 27, 2006 at 12:56:55PM -0700, Andrew Morton wrote:
>>> On Fri, 28 Jul 2006 15:46:08 -0400
>>> Andrew James Wade <andrew.j.wade@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev
>>>> (079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had
>>>> bogus permissions (crw-------). I've kludged around the problem by
>>>> populating /lib/udev/devices from a good /dev, but I'm assuming the
>>>> breakage was unintentional.
>>>>
>>> /dev/null damage is due to a combination of vdso-hash-style-fix.patch and
>>> doing the kernel build as root (don't do that).
>>>
>>> I don't know what happened to /dev/mem.
>> Me either. Look in /sys/class/mem/ Is it full of symlinks or real
>> directories?
>
> Symlinks.
>
>> If symlinks, your version of udev should be able to handle it properly,
>> but might have a bug somehow.
>>
>> Try running udevmonitor and echo a "1" to /sys/class/mem/mem/uevent and
>> see if udev creates the device properly or not.
>
> udevmonitor prints the received event from the kernel [UEVENT]
> and the event which udev sends out after rule processing [UDEV]
>
> UEVENT[1154093169.330045] add@/devices/mem
> UDEV [1154093169.331914] add@/devices/mem
>
> The device node was not created.
>
> udev.log for 2.6.18-rc1-mm2 (which does work) has these lines:
>
> UEVENT[1154105360.092631] add@/class/mem/mem
> ACTION=add
> DEVPATH=/class/mem/mem
> SUBSYSTEM=mem
> SEQNUM=589
> MAJOR=1
> MINOR=1
>
> ...
>
> UDEV [1154105363.575086] add@/class/mem/mem
> UDEV_LOG=3
> ACTION=add
> DEVPATH=/class/mem/mem
> SUBSYSTEM=mem
> SEQNUM=589
> MAJOR=1
> MINOR=1
> UDEVD_EVENT=1
> DEVNAME=/dev/mem
>
> The Changelog for udev v081 has:
> "prepare moving of /sys/class devices to /sys/devices"
> Is this related?
>
> Thanks,
> Andrew Wade
gregkh-driver-mem-devices.patch seems to be the culprit.
With this patch, /sys/class/mem/ looks like this:
/sys/class/mem/
|-- full -> ../../devices/full
|-- kmem -> ../../devices/kmem
|-- kmsg -> ../../devices/kmsg
|-- mem -> ../../devices/mem
|-- null -> ../../devices/null
|-- port -> ../../devices/port
|-- random -> ../../devices/random
|-- urandom -> ../../devices/urandom
`-- zero -> ../../devices/zero
9 directories, 0 files
And /sys/class/mem/*/ look like this:
/sys/class/mem/full/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/kmem/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/kmsg/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/mem/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/null/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/port/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/random/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/urandom/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/zero/
|-- dev
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
18 directories, 36 files
In this situation, udev (version 096 here) is unable to create these
device files (/dev/full, /dev/kmem, /dev/kmsg, etc.). /dev/null does
exist (with wrong permissions) because it has been created by the
initrd script.
In order to get back the device files, I have to run the following
command:
# for f in /sys/class/mem/*/uevent; do echo 1 > $f; done
After gregkh-driver-mem-devices.patch been reverted, all is working
fine and /sys/class/mem/ looks like this:
/sys/class/mem/
|-- full
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
|-- kmem
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
|-- kmsg
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
|-- mem
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
|-- null
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
|-- port
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
|-- random
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
|-- urandom
| |-- dev
| |-- subsystem -> ../../../class/mem
| `-- uevent
`-- zero
|-- dev
|-- subsystem -> ../../../class/mem
`-- uevent
18 directories, 18 files
~~
laurent
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-30 14:01 ` Laurent Riffard
@ 2006-07-31 0:03 ` Greg KH
2006-07-31 2:27 ` Andrew James Wade
0 siblings, 1 reply; 107+ messages in thread
From: Greg KH @ 2006-07-31 0:03 UTC (permalink / raw)
To: Laurent Riffard; +Cc: ajwade, Andrew Morton, andrew.j.wade, linux-kernel
On Sun, Jul 30, 2006 at 04:01:43PM +0200, Laurent Riffard wrote:
> In this situation, udev (version 096 here) is unable to create these
> device files (/dev/full, /dev/kmem, /dev/kmsg, etc.). /dev/null does
> exist (with wrong permissions) because it has been created by the
> initrd script.
Something's really broken with that version of udev then, because the
094 version I have running here works just fine with these symlinks.
> In order to get back the device files, I have to run the following
> command:
> # for f in /sys/class/mem/*/uevent; do echo 1 > $f; done
Ah, ok, it sounds like it's not a bug in udev itself, but rather a bug
in the way your distro does it's initialization of udev, at boot. I
suggest you file a bug with them, as they are known for doing this a bit
differently than any other distro (and different from how the udev
developers recommend), so they can fix it. It's probably just a shell
script issue.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 0:03 ` Greg KH
@ 2006-07-31 2:27 ` Andrew James Wade
2006-07-31 3:37 ` Greg KH
0 siblings, 1 reply; 107+ messages in thread
From: Andrew James Wade @ 2006-07-31 2:27 UTC (permalink / raw)
To: Greg KH; +Cc: Laurent Riffard, Andrew Morton, andrew.j.wade, linux-kernel
On Sunday 30 July 2006 20:03, Greg KH wrote:
> Something's really broken with that version of udev then, because the
> 094 version I have running here works just fine with these symlinks.
Maybe, but some really odd things were happening in /sys with the
patch. I could still follow the bogus symlinks. More than that
/sys/class/mem/mem$ cd ../../class
and
/sys/class/mem/mem$ cd ../..
_both_ ended up with a $PWD of /sys/class.
With the patch reverted, udev now works correctly (thanks, Laurent), and
/sys/class/mem/mem$ cd ../../class
fails with the expected error.
Andrew Wade
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 2:27 ` Andrew James Wade
@ 2006-07-31 3:37 ` Greg KH
2006-07-31 4:22 ` Andrew Morton
` (2 more replies)
0 siblings, 3 replies; 107+ messages in thread
From: Greg KH @ 2006-07-31 3:37 UTC (permalink / raw)
To: ajwade; +Cc: Laurent Riffard, Andrew Morton, andrew.j.wade, linux-kernel
On Sun, Jul 30, 2006 at 10:27:06PM -0400, Andrew James Wade wrote:
> On Sunday 30 July 2006 20:03, Greg KH wrote:
> > Something's really broken with that version of udev then, because the
> > 094 version I have running here works just fine with these symlinks.
>
> Maybe, but some really odd things were happening in /sys with the
> patch. I could still follow the bogus symlinks. More than that
>
> /sys/class/mem/mem$ cd ../../class
> and
> /sys/class/mem/mem$ cd ../..
>
> _both_ ended up with a $PWD of /sys/class.
Ick, ok, the problem is that my "virtual device" patch isn't in my
"public" patch set that Andrew pulls from. It will fix this issue up.
I'll work on cleaning it up to be used by everyone tomorrow and move it
to the tree that Andrew pulls from. Then the next -mm release should
have this issue fixed.
If you want to verify this, please apply the patch at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-virtual.patch
and let me know if it solves your issue (note that the reference
counting is not completly correct in that patch, that's why I haven't
unleashed it on -mm yet.)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 3:37 ` Greg KH
@ 2006-07-31 4:22 ` Andrew Morton
2006-07-31 4:35 ` Greg KH
2006-07-31 8:10 ` Laurent Riffard
2006-08-01 3:01 ` Andrew James Wade
2 siblings, 1 reply; 107+ messages in thread
From: Andrew Morton @ 2006-07-31 4:22 UTC (permalink / raw)
To: Greg KH; +Cc: ajwade, laurent.riffard, andrew.j.wade, linux-kernel
On Sun, 30 Jul 2006 20:37:57 -0700
Greg KH <greg@kroah.com> wrote:
> On Sun, Jul 30, 2006 at 10:27:06PM -0400, Andrew James Wade wrote:
> > On Sunday 30 July 2006 20:03, Greg KH wrote:
> > > Something's really broken with that version of udev then, because the
> > > 094 version I have running here works just fine with these symlinks.
> >
> > Maybe, but some really odd things were happening in /sys with the
> > patch. I could still follow the bogus symlinks. More than that
> >
> > /sys/class/mem/mem$ cd ../../class
> > and
> > /sys/class/mem/mem$ cd ../..
> >
> > _both_ ended up with a $PWD of /sys/class.
>
> Ick, ok, the problem is that my "virtual device" patch isn't in my
> "public" patch set that Andrew pulls from. It will fix this issue up.
> I'll work on cleaning it up to be used by everyone tomorrow and move it
> to the tree that Andrew pulls from. Then the next -mm release should
> have this issue fixed.
Mutter. This stuff breaks my FC3 test box and there is, afaict, no clear
way for users to upgrade udev to unbreak it.
As a developer I could of course bang on things until it works, but that's
not the point. The point is that these patches break Linux on a major
release from a major vendor only two years after its release. That's not a
minor problem, is it?
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 4:22 ` Andrew Morton
@ 2006-07-31 4:35 ` Greg KH
2006-07-31 4:50 ` Andrew Morton
0 siblings, 1 reply; 107+ messages in thread
From: Greg KH @ 2006-07-31 4:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: ajwade, laurent.riffard, andrew.j.wade, linux-kernel
On Sun, Jul 30, 2006 at 09:22:27PM -0700, Andrew Morton wrote:
> On Sun, 30 Jul 2006 20:37:57 -0700
> Greg KH <greg@kroah.com> wrote:
>
> > On Sun, Jul 30, 2006 at 10:27:06PM -0400, Andrew James Wade wrote:
> > > On Sunday 30 July 2006 20:03, Greg KH wrote:
> > > > Something's really broken with that version of udev then, because the
> > > > 094 version I have running here works just fine with these symlinks.
> > >
> > > Maybe, but some really odd things were happening in /sys with the
> > > patch. I could still follow the bogus symlinks. More than that
> > >
> > > /sys/class/mem/mem$ cd ../../class
> > > and
> > > /sys/class/mem/mem$ cd ../..
> > >
> > > _both_ ended up with a $PWD of /sys/class.
> >
> > Ick, ok, the problem is that my "virtual device" patch isn't in my
> > "public" patch set that Andrew pulls from. It will fix this issue up.
> > I'll work on cleaning it up to be used by everyone tomorrow and move it
> > to the tree that Andrew pulls from. Then the next -mm release should
> > have this issue fixed.
>
> Mutter. This stuff breaks my FC3 test box and there is, afaict, no clear
> way for users to upgrade udev to unbreak it.
>
> As a developer I could of course bang on things until it works, but that's
> not the point. The point is that these patches break Linux on a major
> release from a major vendor only two years after its release. That's not a
> minor problem, is it?
Well, yes, it is. That distro is unsupported now, right?
How long do you expect the kernel to support unsupported, community
based distros that thrive on the fact that they are quickly updated?
Look at Documentation/Changes for the version of udev that the kernel
now requires. It's 071 due to the input layer code (which was released
in October of 2005). Odds are you have just gotten lucky that FC3 is
not working for you right now.
And yes, I will revert the patch in mainline that causes people to have
to upgrade to a udev that is in FC5, and wait till the next release for
that to happen (the minimum will be 081, which was released in January,
2006, by the time 2.6.19 is out, that will be about 10 months old.)
Debian and Gentoo already support new enough versions of udev, and so
does OpenSuSE and Fedora with their latest, supported versions. How
long should the kernel be forced to lag behind?
I'm also going to fix up older versions of SuSE (10.0, which is no
longer supported by the vendor) so that it will support this kernel
change too, it's only a few lines of patch to udev, but don't have the
ability to do the same for Fedora, sorry.
Remember, most distros tie their kernel to their userspace very tightly,
so the ability to upgrade the kernel without some userspace packages
does not always work (HAL stopped working long ago in FC3 with newer
kernels I imagine.) If you are a kernel developer, who updates kernels
often, choose a distro that allows that flexibility (Gentoo and Debian
are two that I know of, FC Rawhide and OpenSuSE Factory are two others
that should also do it.)
Remember, FC3 is now in Legacy support mode, not something the mainline
kernel should have to worry about.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 4:35 ` Greg KH
@ 2006-07-31 4:50 ` Andrew Morton
2006-07-31 5:15 ` Greg KH
0 siblings, 1 reply; 107+ messages in thread
From: Andrew Morton @ 2006-07-31 4:50 UTC (permalink / raw)
To: Greg KH; +Cc: ajwade, laurent.riffard, andrew.j.wade, linux-kernel
On Sun, 30 Jul 2006 21:35:42 -0700
Greg KH <greg@kroah.com> wrote:
> Remember, FC3 is now in Legacy support mode, not something the mainline
> kernel should have to worry about.
It's not specifically related to FC3. It's udev - we've broken _any_
distribution which uses a two-year-old udev. In fact we're proposing
breaking any distro which has an older-than-ten-month udev. That's really
bad.
It's worse on FC3 because there is, as far as I can tell, no rpm or srpm
which can be used to unbreak it. And pointing at Documentation/Changes
doesn't alter that, does it?
Personally, there's no way I'm upgrading this box because I _want_ to run
old distros to catch things like this. So I'll hack it around to work
somehow. I can do that, because I'm a developer.
Are we going to stop doing this soon?
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 4:50 ` Andrew Morton
@ 2006-07-31 5:15 ` Greg KH
2006-07-31 6:00 ` Andrew Morton
0 siblings, 1 reply; 107+ messages in thread
From: Greg KH @ 2006-07-31 5:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: ajwade, laurent.riffard, andrew.j.wade, linux-kernel
On Sun, Jul 30, 2006 at 09:50:25PM -0700, Andrew Morton wrote:
> On Sun, 30 Jul 2006 21:35:42 -0700
> Greg KH <greg@kroah.com> wrote:
>
> > Remember, FC3 is now in Legacy support mode, not something the mainline
> > kernel should have to worry about.
>
> It's not specifically related to FC3. It's udev - we've broken _any_
> distribution which uses a two-year-old udev. In fact we're proposing
> breaking any distro which has an older-than-ten-month udev. That's really
> bad.
Why? What do you propose we do then? Wait a year? Two years? I've
already stated that I'm going to wait 3 more months in order to be able
to fix up the currently supported distros to handle the changes needed.
I'll even dig up RC4 to get that working, as it shouldn't be that hard
to do so. What more can I do?
> It's worse on FC3 because there is, as far as I can tell, no rpm or srpm
> which can be used to unbreak it. And pointing at Documentation/Changes
> doesn't alter that, does it?
No, but it does show that you are running on an unsupported distro. Why
should the kernel developers have to support this? When is the cut-off
date?
> Personally, there's no way I'm upgrading this box because I _want_ to run
> old distros to catch things like this. So I'll hack it around to work
> somehow. I can do that, because I'm a developer.
And that's the only group of people who would try to do this.
Seriously, I don't see the complaint here. It's an unsupported distro
by the very makers of that distro. How long should the community have
to care about a distro after the creators of it have abandonded it?
> Are we going to stop doing this soon?
Not if we want to keep on making things better. The real reason I made
these changes is to get power management working better. We need to get
the devices into the proper place in the sysfs tree in order to handle
suspend/resume for classes of devices properly. That's what Linus's
patch did, and now I'm moving the devices to allow it to really happen.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 5:15 ` Greg KH
@ 2006-07-31 6:00 ` Andrew Morton
2006-07-31 7:54 ` bert hubert
2006-07-31 11:14 ` Alan Cox
0 siblings, 2 replies; 107+ messages in thread
From: Andrew Morton @ 2006-07-31 6:00 UTC (permalink / raw)
To: Greg KH; +Cc: ajwade, laurent.riffard, andrew.j.wade, linux-kernel
On Sun, 30 Jul 2006 22:15:47 -0700
Greg KH <greg@kroah.com> wrote:
> On Sun, Jul 30, 2006 at 09:50:25PM -0700, Andrew Morton wrote:
> > On Sun, 30 Jul 2006 21:35:42 -0700
> > Greg KH <greg@kroah.com> wrote:
> >
> > > Remember, FC3 is now in Legacy support mode, not something the mainline
> > > kernel should have to worry about.
> >
> > It's not specifically related to FC3. It's udev - we've broken _any_
> > distribution which uses a two-year-old udev. In fact we're proposing
> > breaking any distro which has an older-than-ten-month udev. That's really
> > bad.
>
> Why? What do you propose we do then? Wait a year? Two years?
Greg, once we put an interface into the kernel and expose it to userspace,
that's it - we support it forever. At least, that's the model. Yes,
sometimes in cases of necessity where we cannot feasibly support old
userspace we'll break things, with long notice and considerable thought
and care.
The impact is lower in this case because we've already trained our
long-suffering users to expect udev to regularly break.
> And that's the only group of people who would try to do this.
> Seriously, I don't see the complaint here. It's an unsupported distro
> by the very makers of that distro. How long should the community have
> to care about a distro after the creators of it have abandonded it?
Please stop going on about FC3. My (repeat) point is that we're proposing
to break _all_ distros which are older than ten months. We don't play the
"oh, that isn't supported any more" game.
> > Are we going to stop doing this soon?
>
> Not if we want to keep on making things better. The real reason I made
> these changes is to get power management working better. We need to get
> the devices into the proper place in the sysfs tree in order to handle
> suspend/resume for classes of devices properly. That's what Linus's
> patch did, and now I'm moving the devices to allow it to really happen.
>
This sucks. Do you know what machines we'll be breaking out there? I
sure don't.
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 6:00 ` Andrew Morton
@ 2006-07-31 7:54 ` bert hubert
2006-07-31 8:30 ` Jesper Juhl
2006-07-31 11:14 ` Alan Cox
1 sibling, 1 reply; 107+ messages in thread
From: bert hubert @ 2006-07-31 7:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, ajwade, laurent.riffard, andrew.j.wade, linux-kernel
On Sun, Jul 30, 2006 at 11:00:33PM -0700, Andrew Morton wrote:
> The impact is lower in this case because we've already trained our
> long-suffering users to expect udev to regularly break.
It has broken, even in 2.6.18-rc3, see http://lkml.org/lkml/2006/7/30/163
'2.6.18-rc3 does not like an old udev (071)' and beyond.
It now requires udev 079, in disaccordance with the Documentation/Changes
file.
This breaks Ubuntu LTS, which for some reason chose to ship udev 071.
Thanks.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 7:54 ` bert hubert
@ 2006-07-31 8:30 ` Jesper Juhl
0 siblings, 0 replies; 107+ messages in thread
From: Jesper Juhl @ 2006-07-31 8:30 UTC (permalink / raw)
To: bert hubert, Andrew Morton, Greg KH, ajwade, laurent.riffard,
andrew.j.wade, linux-kernel
On 31/07/06, bert hubert <bert.hubert@netherlabs.nl> wrote:
> On Sun, Jul 30, 2006 at 11:00:33PM -0700, Andrew Morton wrote:
> > The impact is lower in this case because we've already trained our
> > long-suffering users to expect udev to regularly break.
>
> It has broken, even in 2.6.18-rc3, see http://lkml.org/lkml/2006/7/30/163
> '2.6.18-rc3 does not like an old udev (071)' and beyond.
>
> It now requires udev 079, in disaccordance with the Documentation/Changes
> file.
>
> This breaks Ubuntu LTS, which for some reason chose to ship udev 071.
>
It'll probably also cause trouble for the upcomming release of Slackware.
Slackware 11 is just around the corner and slackware-current currently
has udev 071. The kernel is 2.4.32 or 2.6.17.7 (user choice), but I'll
bet many people will want to install newer kernels.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 6:00 ` Andrew Morton
2006-07-31 7:54 ` bert hubert
@ 2006-07-31 11:14 ` Alan Cox
1 sibling, 0 replies; 107+ messages in thread
From: Alan Cox @ 2006-07-31 11:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, ajwade, laurent.riffard, andrew.j.wade, linux-kernel
Ar Sul, 2006-07-30 am 23:00 -0700, ysgrifennodd Andrew Morton:
> > > Are we going to stop doing this soon?
> >
> > Not if we want to keep on making things better. The real reason I made
> > these changes is to get power management working better. We need to get
> > the devices into the proper place in the sysfs tree in order to handle
> > suspend/resume for classes of devices properly. That's what Linus's
> > patch did, and now I'm moving the devices to allow it to really happen.
> >
>
> This sucks. Do you know what machines we'll be breaking out there? I
> sure don't.
Greg, this changeset should get ripped out and thrown away. Its wrong.
Its an API breakage and it is going to catch a lot of people. People
said at the kernel summit the sysfs had serious problems because of the
structure it exposes and you said you could use symlinks and the like to
work around it, or fix the code.
How about proving it or doing the work to make it possible rather than
continuing to break everything repeatedly.
Alan
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 3:37 ` Greg KH
2006-07-31 4:22 ` Andrew Morton
@ 2006-07-31 8:10 ` Laurent Riffard
2006-08-01 3:01 ` Andrew James Wade
2 siblings, 0 replies; 107+ messages in thread
From: Laurent Riffard @ 2006-07-31 8:10 UTC (permalink / raw)
To: Greg KH; +Cc: ajwade, Andrew Morton, andrew.j.wade, linux-kernel
Le 31.07.2006 05:37, Greg KH a écrit :
> On Sun, Jul 30, 2006 at 10:27:06PM -0400, Andrew James Wade wrote:
>> On Sunday 30 July 2006 20:03, Greg KH wrote:
>>> Something's really broken with that version of udev then, because the
>>> 094 version I have running here works just fine with these symlinks.
>> Maybe, but some really odd things were happening in /sys with the
>> patch. I could still follow the bogus symlinks. More than that
>>
>> /sys/class/mem/mem$ cd ../../class
>> and
>> /sys/class/mem/mem$ cd ../..
>>
>> _both_ ended up with a $PWD of /sys/class.
>
> Ick, ok, the problem is that my "virtual device" patch isn't in my
> "public" patch set that Andrew pulls from. It will fix this issue up.
> I'll work on cleaning it up to be used by everyone tomorrow and move it
> to the tree that Andrew pulls from. Then the next -mm release should
> have this issue fixed.
>
> If you want to verify this, please apply the patch at:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-virtual.patch
> and let me know if it solves your issue (note that the reference
> counting is not completly correct in that patch, that's why I haven't
> unleashed it on -mm yet.)
device-virtual.patch won't apply on top of 2.6.18-rc2-mm1:
linux-2.6-mm$ head -4 Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 18
EXTRAVERSION = -rc2-mm1
linux-2.6-mm$ quilt pop -a
Aucun patch retiré
linux-2.6-mm$ quilt push
Application de patches/device-virtual.patch
patching file drivers/base/Makefile
patching file drivers/base/base.h
Hunk #1 succeeded at 44 (offset 1 line).
patching file drivers/base/core.c
Hunk #1 succeeded at 434 (offset 60 lines).
Hunk #2 FAILED at 486.
Hunk #3 succeeded at 615 (offset 61 lines).
1 out of 3 hunks FAILED -- rejects in file drivers/base/core.c
patching file drivers/base/virtual.c
patching file include/linux/device.h
Hunk #1 succeeded at 356 (offset 5 lines).
Le patch patches/device-virtual.patch ne s'applique pas proprement
(forcez l'application avec -f)
--
laurent
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-31 3:37 ` Greg KH
2006-07-31 4:22 ` Andrew Morton
2006-07-31 8:10 ` Laurent Riffard
@ 2006-08-01 3:01 ` Andrew James Wade
2 siblings, 0 replies; 107+ messages in thread
From: Andrew James Wade @ 2006-08-01 3:01 UTC (permalink / raw)
To: Greg KH; +Cc: Laurent Riffard, Andrew Morton, andrew.j.wade, linux-kernel
On Sunday 30 July 2006 23:37, Greg KH wrote:
> On Sun, Jul 30, 2006 at 10:27:06PM -0400, Andrew James Wade wrote:
> > On Sunday 30 July 2006 20:03, Greg KH wrote:
> > > Something's really broken with that version of udev then, because the
> > > 094 version I have running here works just fine with these symlinks.
> >
> > Maybe, but some really odd things were happening in /sys with the
> > patch. I could still follow the bogus symlinks. More than that
> >
> > /sys/class/mem/mem$ cd ../../class
> > and
> > /sys/class/mem/mem$ cd ../..
> >
> > _both_ ended up with a $PWD of /sys/class.
Sorry for the false alarm: I didn't note the previous level of symlinks
in /sys/class/mem, and the subsystem symlinks were actually correct.
The strange behaviour of cd was the result of my shell being to clever
for my own good.
...
>
> If you want to verify this, please apply the patch at:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-virtual.patch
> and let me know if it solves your issue (note that the reference
> counting is not completly correct in that patch, that's why I haven't
> unleashed it on -mm yet.)
Unfortunately not. I hand-applied the one reject like so:
diff -rupN 2.6.18-rc2-mm1/drivers/base/core.c linux/drivers/base/core.c
--- 2.6.18-rc2-mm1/drivers/base/core.c 2006-07-31 22:07:24.000000000 -0400
+++ linux/drivers/base/core.c 2006-07-31 15:57:59.000000000 -0400
@@ -368,7 +368,7 @@ static int device_add_class_symlinks(str
dev->bus_id);
if (error)
goto out_subsys;
- if (dev->parent) {
+ if ((dev->parent) && (!dev->virtual)) {
error = sysfs_create_link(&dev->kobj, &dev->parent->kobj,
"device");
if (error)
but udev (79-0ubuntu34) did not work with the patch applied.
thanks,
Andrew Wade
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: Kubuntu's udev broken with 2.6.18-rc2-mm1
2006-07-27 19:56 ` Andrew Morton
2006-07-27 20:12 ` Greg KH
@ 2006-07-27 21:28 ` Valdis.Kletnieks
1 sibling, 0 replies; 107+ messages in thread
From: Valdis.Kletnieks @ 2006-07-27 21:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: ajwade, andrew.j.wade, gregkh, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
On Thu, 27 Jul 2006 12:56:55 PDT, Andrew Morton said:
> On Fri, 28 Jul 2006 15:46:08 -0400
> Andrew James Wade <andrew.j.wade@gmail.com> wrote:
>
> > Hello,
> >
> > Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev
> > (079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had
> > bogus permissions (crw-------). I've kludged around the problem by
> > populating /lib/udev/devices from a good /dev, but I'm assuming the
> > breakage was unintentional.
> >
>
> /dev/null damage is due to a combination of vdso-hash-style-fix.patch and
> doing the kernel build as root (don't do that).
Hmm... I thought the vdso-hash whoops caused /dev/null to get removed and
thus recreated as a regular file - Andrew Wade is showing it as being
mode 600 - but still a 'char special'?
Or did udev get there before somebody managed to recreate it, and it
stuck funky permissions on it?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 107+ messages in thread
* [-mm patch] security/selinux/hooks.c: make 4 functions static
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (14 preceding siblings ...)
2006-07-28 19:46 ` Kubuntu's udev broken with 2.6.18-rc2-mm1 Andrew James Wade
@ 2006-07-29 17:48 ` Adrian Bunk
2006-07-30 0:37 ` James Morris
2006-07-29 17:58 ` swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1] Jiri Slaby
` (3 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Adrian Bunk @ 2006-07-29 17:48 UTC (permalink / raw)
To: Andrew Morton, Venkat Yekkirala; +Cc: linux-kernel, davem, netdev, sds, jmorris
On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc2-mm1:
>...
> git-net.patch
>...
> git trees
>...
This patch makes four needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
security/selinux/hooks.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- linux-2.6.18-rc2-mm1-full/security/selinux/hooks.c.old 2006-07-27 20:31:37.000000000 +0200
+++ linux-2.6.18-rc2-mm1-full/security/selinux/hooks.c 2006-07-27 20:32:46.000000000 +0200
@@ -3576,7 +3576,7 @@
}
}
-void selinux_sock_graft(struct sock* sk, struct socket *parent)
+static void selinux_sock_graft(struct sock* sk, struct socket *parent)
{
struct inode_security_struct *isec = SOCK_INODE(parent)->i_security;
struct sk_security_struct *sksec = sk->sk_security;
@@ -3584,8 +3584,8 @@
isec->sid = sksec->sid;
}
-int selinux_inet_conn_request(struct sock *sk, struct sk_buff *skb,
- struct request_sock *req)
+static int selinux_inet_conn_request(struct sock *sk, struct sk_buff *skb,
+ struct request_sock *req)
{
struct sk_security_struct *sksec = sk->sk_security;
int err;
@@ -3603,7 +3603,8 @@
return 0;
}
-void selinux_inet_csk_clone(struct sock *newsk, const struct request_sock *req)
+static void selinux_inet_csk_clone(struct sock *newsk,
+ const struct request_sock *req)
{
struct sk_security_struct *newsksec = newsk->sk_security;
@@ -3614,7 +3615,8 @@
time it will have been created and available. */
}
-void selinux_req_classify_flow(const struct request_sock *req, struct flowi *fl)
+static void selinux_req_classify_flow(const struct request_sock *req,
+ struct flowi *fl)
{
fl->secid = req->secid;
}
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [-mm patch] security/selinux/hooks.c: make 4 functions static
2006-07-29 17:48 ` [-mm patch] security/selinux/hooks.c: make 4 functions static Adrian Bunk
@ 2006-07-30 0:37 ` James Morris
0 siblings, 0 replies; 107+ messages in thread
From: James Morris @ 2006-07-30 0:37 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Venkat Yekkirala, linux-kernel, davem, netdev, sds
On Sat, 29 Jul 2006, Adrian Bunk wrote:
> On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc2-mm1:
> >...
> > git-net.patch
> >...
> > git trees
> >...
>
> This patch makes four needlessly global functions static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: James Morris <jmorris@namei.org>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 107+ messages in thread
* swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (15 preceding siblings ...)
2006-07-29 17:48 ` [-mm patch] security/selinux/hooks.c: make 4 functions static Adrian Bunk
@ 2006-07-29 17:58 ` Jiri Slaby
2006-07-29 18:59 ` Rafael J. Wysocki
2006-07-30 11:35 ` 2.6.18-rc2-mm1 fails to reboot properly on Dell Latitude CPiA Christian Trefzer
` (2 subsequent siblings)
19 siblings, 1 reply; 107+ messages in thread
From: Jiri Slaby @ 2006-07-29 17:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, pavel, linux-pm, linux-mm
Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
Hello,
I have problems with swsusp again. While suspending, the very last thing kernel
writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
Here is a snapshot of the screen:
http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
It's SMP system (HT), higmem enabled (1 gig of ram).
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 17:58 ` swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1] Jiri Slaby
@ 2006-07-29 18:59 ` Rafael J. Wysocki
2006-07-29 23:06 ` Jiri Slaby
0 siblings, 1 reply; 107+ messages in thread
From: Rafael J. Wysocki @ 2006-07-29 18:59 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, pavel, linux-pm, linux-mm
Hi,
On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
> Hello,
>
> I have problems with swsusp again. While suspending, the very last thing kernel
> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> Here is a snapshot of the screen:
> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>
> It's SMP system (HT), higmem enabled (1 gig of ram).
Most probably it hangs in device_power_up(), so the problem seems to be
with one of the devices that are resumed with IRQs off.
Does vanila .18-rc2 work?
Rafael
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 18:59 ` Rafael J. Wysocki
@ 2006-07-29 23:06 ` Jiri Slaby
2006-07-29 23:10 ` Rafael J. Wysocki
2006-07-29 23:22 ` Pavel Machek
0 siblings, 2 replies; 107+ messages in thread
From: Jiri Slaby @ 2006-07-29 23:06 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jiri Slaby, Andrew Morton, linux-kernel, pavel, linux-pm, linux-mm
Rafael J. Wysocki napsal(a):
> Hi,
>
> On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
>> Andrew Morton napsal(a):
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>> Hello,
>>
>> I have problems with swsusp again. While suspending, the very last thing kernel
>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>> Here is a snapshot of the screen:
>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>
>> It's SMP system (HT), higmem enabled (1 gig of ram).
>
> Most probably it hangs in device_power_up(), so the problem seems to be
> with one of the devices that are resumed with IRQs off.
>
> Does vanila .18-rc2 work?
Yup, it does.
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 23:06 ` Jiri Slaby
@ 2006-07-29 23:10 ` Rafael J. Wysocki
2006-07-29 23:59 ` Jiri Slaby
2006-07-30 0:03 ` Jiri Slaby
2006-07-29 23:22 ` Pavel Machek
1 sibling, 2 replies; 107+ messages in thread
From: Rafael J. Wysocki @ 2006-07-29 23:10 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, pavel, linux-pm, linux-mm
On Sunday 30 July 2006 01:06, Jiri Slaby wrote:
> Rafael J. Wysocki napsal(a):
> > Hi,
> >
> > On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
> >> Andrew Morton napsal(a):
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> >> Hello,
> >>
> >> I have problems with swsusp again. While suspending, the very last thing kernel
> >> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >> Here is a snapshot of the screen:
> >> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>
> >> It's SMP system (HT), higmem enabled (1 gig of ram).
> >
> > Most probably it hangs in device_power_up(), so the problem seems to be
> > with one of the devices that are resumed with IRQs off.
> >
> > Does vanila .18-rc2 work?
>
> Yup, it does.
Hm, in fact this may be a problem with any device driver.
Could you please boot the system with init=/bin/bash and try to suspend?
Rafael
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 23:10 ` Rafael J. Wysocki
@ 2006-07-29 23:59 ` Jiri Slaby
2006-07-30 0:03 ` Jiri Slaby
1 sibling, 0 replies; 107+ messages in thread
From: Jiri Slaby @ 2006-07-29 23:59 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jiri Slaby, Andrew Morton, linux-kernel, pavel, linux-pm, linux-mm
Rafael J. Wysocki napsal(a):
> On Sunday 30 July 2006 01:06, Jiri Slaby wrote:
>> Rafael J. Wysocki napsal(a):
>>> Hi,
>>>
>>> On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
>>>> Andrew Morton napsal(a):
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>>>> Hello,
>>>>
>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>> Here is a snapshot of the screen:
>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>
>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>> with one of the devices that are resumed with IRQs off.
>>>
>>> Does vanila .18-rc2 work?
>> Yup, it does.
>
> Hm, in fact this may be a problem with any device driver.
>
> Could you please boot the system with init=/bin/bash and try to suspend?
No change.
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 23:10 ` Rafael J. Wysocki
2006-07-29 23:59 ` Jiri Slaby
@ 2006-07-30 0:03 ` Jiri Slaby
1 sibling, 0 replies; 107+ messages in thread
From: Jiri Slaby @ 2006-07-30 0:03 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jiri Slaby, Andrew Morton, linux-kernel, pavel, linux-pm, linux-mm
Rafael J. Wysocki napsal(a):
> On Sunday 30 July 2006 01:06, Jiri Slaby wrote:
>> Rafael J. Wysocki napsal(a):
>>> Hi,
>>>
>>> On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
>>>> Andrew Morton napsal(a):
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>>>> Hello,
>>>>
>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>> Here is a snapshot of the screen:
>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>
>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>> with one of the devices that are resumed with IRQs off.
>>>
>>> Does vanila .18-rc2 work?
>> Yup, it does.
>
> Hm, in fact this may be a problem with any device driver.
Note 1: 2.6.18-rc1-mm2 was(is) working just fine.
Note 2: when I was going through these -mm diff, the culprit may be radeon
driver -- there are some PM changes... Or if you want to go on your own, here is
lspci output:
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub
Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
(rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon
9000] (rev 01)
01:00.1 Display controller: ATI Technologies Inc Radeon RV250 [Radeon 9000]
(Secondary) (rev 01)
02:02.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
02:02.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)
02:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000
Controller (PHY/Link)
02:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet
Controller (rev 02)
with -n:
00:00.0 0600: 8086:2570 (rev 02)
00:01.0 0604: 8086:2571 (rev 02)
00:1d.0 0c03: 8086:24d2 (rev 02)
00:1d.1 0c03: 8086:24d4 (rev 02)
00:1d.2 0c03: 8086:24d7 (rev 02)
00:1d.3 0c03: 8086:24de (rev 02)
00:1d.7 0c03: 8086:24dd (rev 02)
00:1e.0 0604: 8086:244e (rev c2)
00:1f.0 0601: 8086:24d0 (rev 02)
00:1f.1 0101: 8086:24db (rev 02)
00:1f.2 0101: 8086:24d1 (rev 02)
00:1f.3 0c05: 8086:24d3 (rev 02)
01:00.0 0300: 1002:4966 (rev 01)
01:00.1 0380: 1002:496e (rev 01)
02:02.0 0401: 1102:0002 (rev 0a)
02:02.1 0980: 1102:7002 (rev 0a)
02:05.0 0c00: 104c:8024
02:08.0 0200: 8086:1050 (rev 02)
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 23:06 ` Jiri Slaby
2006-07-29 23:10 ` Rafael J. Wysocki
@ 2006-07-29 23:22 ` Pavel Machek
2006-07-29 23:58 ` Jiri Slaby
1 sibling, 1 reply; 107+ messages in thread
From: Pavel Machek @ 2006-07-29 23:22 UTC (permalink / raw)
To: Jiri Slaby
Cc: Rafael J. Wysocki, Andrew Morton, linux-kernel, linux-pm, linux-mm
Hi!
> >> I have problems with swsusp again. While suspending, the very last thing kernel
> >> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >> Here is a snapshot of the screen:
> >> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>
> >> It's SMP system (HT), higmem enabled (1 gig of ram).
> >
> > Most probably it hangs in device_power_up(), so the problem seems to be
> > with one of the devices that are resumed with IRQs off.
> >
> > Does vanila .18-rc2 work?
>
> Yup, it does.
Can you try up kernel, no highmem? (mem=512M)?
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] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 23:22 ` Pavel Machek
@ 2006-07-29 23:58 ` Jiri Slaby
2006-07-30 0:06 ` Pavel Machek
2006-07-30 11:36 ` James Courtier-Dutton
0 siblings, 2 replies; 107+ messages in thread
From: Jiri Slaby @ 2006-07-29 23:58 UTC (permalink / raw)
To: Pavel Machek
Cc: Jiri Slaby, Rafael J. Wysocki, Andrew Morton, linux-kernel,
linux-pm, linux-mm
Pavel Machek napsal(a):
> Hi!
>
>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>> Here is a snapshot of the screen:
>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>
>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>> with one of the devices that are resumed with IRQs off.
>>>
>>> Does vanila .18-rc2 work?
>> Yup, it does.
>
> Can you try up kernel, no highmem? (mem=512M)?
It writes then:
p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
in endless loop when resuming -- after reading from swap.
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 23:58 ` Jiri Slaby
@ 2006-07-30 0:06 ` Pavel Machek
2006-07-30 7:31 ` Rafael J. Wysocki
2006-07-30 11:36 ` James Courtier-Dutton
1 sibling, 1 reply; 107+ messages in thread
From: Pavel Machek @ 2006-07-30 0:06 UTC (permalink / raw)
To: Jiri Slaby
Cc: Rafael J. Wysocki, Andrew Morton, linux-kernel, linux-pm, linux-mm
Hi!
> >>>> I have problems with swsusp again. While suspending, the very last thing kernel
> >>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >>>> Here is a snapshot of the screen:
> >>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>>>
> >>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> >>> Most probably it hangs in device_power_up(), so the problem seems to be
> >>> with one of the devices that are resumed with IRQs off.
> >>>
> >>> Does vanila .18-rc2 work?
> >> Yup, it does.
> >
> > Can you try up kernel, no highmem? (mem=512M)?
>
> It writes then:
> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> in endless loop when resuming -- after reading from swap.
Okay, so we have two different problems here.
One is "hang during suspend" with smp/highmem mode, and one is
probably driver problem with p16v (whatever it is).
/data/l/linux/sound/pci/emu10k1/irq.c:
snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
use=%d\n", status2, mask, pvoice, pvoice->use);
...aha, so you may want to unload emu10k1 for testing.
Since you mention radeon in one of your other mails, just try it in
vesafb mode...
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] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-30 0:06 ` Pavel Machek
@ 2006-07-30 7:31 ` Rafael J. Wysocki
2006-07-30 8:08 ` Jiri Slaby
0 siblings, 1 reply; 107+ messages in thread
From: Rafael J. Wysocki @ 2006-07-30 7:31 UTC (permalink / raw)
To: Pavel Machek; +Cc: Jiri Slaby, Andrew Morton, linux-kernel, linux-pm, linux-mm
On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> Hi!
>
> > >>>> I have problems with swsusp again. While suspending, the very last thing kernel
> > >>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> > >>>> Here is a snapshot of the screen:
> > >>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> > >>>>
> > >>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> > >>> Most probably it hangs in device_power_up(), so the problem seems to be
> > >>> with one of the devices that are resumed with IRQs off.
> > >>>
> > >>> Does vanila .18-rc2 work?
> > >> Yup, it does.
> > >
> > > Can you try up kernel, no highmem? (mem=512M)?
> >
> > It writes then:
> > p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> > in endless loop when resuming -- after reading from swap.
>
> Okay, so we have two different problems here.
>
> One is "hang during suspend" with smp/highmem mode,
That one is "interesting". I've no idea why the restoration of highmem would
have caused the box to hang like that. Jiri, could you please post the output
of dmesg after a fresh boot?
> and one is probably driver problem with p16v (whatever it is).
>
> /data/l/linux/sound/pci/emu10k1/irq.c:
> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> use=%d\n", status2, mask, pvoice, pvoice->use);
>
> ...aha, so you may want to unload emu10k1 for testing.
>
> Since you mention radeon in one of your other mails, just try it in
> vesafb mode...
Yes. Or just don't compile the radeon driver and see what happens.
Rafael
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-30 7:31 ` Rafael J. Wysocki
@ 2006-07-30 8:08 ` Jiri Slaby
2006-07-30 9:28 ` Rafael J. Wysocki
0 siblings, 1 reply; 107+ messages in thread
From: Jiri Slaby @ 2006-07-30 8:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Pavel Machek, Andrew Morton, linux-kernel, linux-pm, linux-mm
Rafael J. Wysocki napsal(a):
> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
>> Hi!
>>
>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>>>>> Here is a snapshot of the screen:
>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>>>>
>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>>>>> with one of the devices that are resumed with IRQs off.
>>>>>>
>>>>>> Does vanila .18-rc2 work?
>>>>> Yup, it does.
>>>> Can you try up kernel, no highmem? (mem=512M)?
>>> It writes then:
>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
>>> in endless loop when resuming -- after reading from swap.
>> Okay, so we have two different problems here.
>>
>> One is "hang during suspend" with smp/highmem mode,
>
> That one is "interesting". I've no idea why the restoration of highmem would
> have caused the box to hang like that. Jiri, could you please post the output
> of dmesg after a fresh boot?
higmem is ok. ioapic0 is the culprit -- its class resume dies:
if (cls->resume)
cls->resume(dev); <----
in __sysdev_resume
>> and one is probably driver problem with p16v (whatever it is).
>>
>> /data/l/linux/sound/pci/emu10k1/irq.c:
>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
>> use=%d\n", status2, mask, pvoice, pvoice->use);
>>
>> ...aha, so you may want to unload emu10k1 for testing.
Sure, this helped.
>> Since you mention radeon in one of your other mails, just try it in
>> vesafb mode...
>
> Yes. Or just don't compile the radeon driver and see what happens.
Doesn't matter. I do not use graphics (fb) in console -- radeon was not inited
at all, it was bad tip.
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-30 8:08 ` Jiri Slaby
@ 2006-07-30 9:28 ` Rafael J. Wysocki
2006-07-30 10:54 ` Jiri Slaby
0 siblings, 1 reply; 107+ messages in thread
From: Rafael J. Wysocki @ 2006-07-30 9:28 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Pavel Machek, Andrew Morton, linux-kernel, linux-pm, linux-mm
On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
> Rafael J. Wysocki napsal(a):
> > On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> >> Hi!
> >>
> >>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
> >>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >>>>>>> Here is a snapshot of the screen:
> >>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>>>>>>
> >>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> >>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
> >>>>>> with one of the devices that are resumed with IRQs off.
> >>>>>>
> >>>>>> Does vanila .18-rc2 work?
> >>>>> Yup, it does.
> >>>> Can you try up kernel, no highmem? (mem=512M)?
> >>> It writes then:
> >>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> >>> in endless loop when resuming -- after reading from swap.
> >> Okay, so we have two different problems here.
> >>
> >> One is "hang during suspend" with smp/highmem mode,
> >
> > That one is "interesting". I've no idea why the restoration of highmem would
> > have caused the box to hang like that. Jiri, could you please post the output
> > of dmesg after a fresh boot?
>
> higmem is ok. ioapic0 is the culprit -- its class resume dies:
> if (cls->resume)
> cls->resume(dev); <----
> in __sysdev_resume
Ah, so my first guess was actually correct. :-)
> >> and one is probably driver problem with p16v (whatever it is).
> >>
> >> /data/l/linux/sound/pci/emu10k1/irq.c:
> >> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> >> use=%d\n", status2, mask, pvoice, pvoice->use);
> >>
> >> ...aha, so you may want to unload emu10k1 for testing.
>
> Sure, this helped.
So, we have two different regressions here.
Please try to revert git-alsa.patch and see if the emu10k1-related problem
goes away.
As far as the first one is concerned, the genirq-* patches look suspicious.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-30 9:28 ` Rafael J. Wysocki
@ 2006-07-30 10:54 ` Jiri Slaby
2006-07-30 11:08 ` Pavel Machek
2006-07-30 11:34 ` Rafael J. Wysocki
0 siblings, 2 replies; 107+ messages in thread
From: Jiri Slaby @ 2006-07-30 10:54 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Pavel Machek, Andrew Morton, linux-kernel, linux-pm, alsa-devel, mingo
Uncc: linux-mm
Cc: alsa-devel
Cc: mingo
Rafael J. Wysocki wrote:
> On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
>> Rafael J. Wysocki napsal(a):
>>> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>>>>>>> Here is a snapshot of the screen:
>>>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>>>>>>
>>>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>>>>>>> with one of the devices that are resumed with IRQs off.
>>>>>>>>
>>>>>>>> Does vanila .18-rc2 work?
>>>>>>> Yup, it does.
>>>>>> Can you try up kernel, no highmem? (mem=512M)?
>>>>> It writes then:
>>>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
>>>>> in endless loop when resuming -- after reading from swap.
>>>> Okay, so we have two different problems here.
[snip]
>>>> and one is probably driver problem with p16v (whatever it is).
>>>>
>>>> /data/l/linux/sound/pci/emu10k1/irq.c:
>>>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
>>>> use=%d\n", status2, mask, pvoice, pvoice->use);
>>>>
>>>> ...aha, so you may want to unload emu10k1 for testing.
>> Sure, this helped.
>
> So, we have two different regressions here.
>
> Please try to revert git-alsa.patch and see if the emu10k1-related problem
> goes away.
Wow, it didn't helped, I find out there is a difference between in-kernel and
modules version of the driver. When compiled as modules (loaded/unloaded)
suspending (and resuming) is working ok (enabled higmem and preempt back --
still no smp), when compiled in-kernel (see the config diff below), it doesn't
resume.
@@ -1263,8 +1263,8 @@
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
-CONFIG_SND_HWDEP=m
-CONFIG_SND_RAWMIDI=m
+CONFIG_SND_HWDEP=y
+CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
@@ -1282,8 +1282,8 @@
#
# Generic devices
#
-CONFIG_SND_AC97_CODEC=m
-CONFIG_SND_AC97_BUS=m
+CONFIG_SND_AC97_CODEC=y
+CONFIG_SND_AC97_BUS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
@@ -1347,7 +1347,7 @@
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
-CONFIG_SND_EMU10K1=m
+CONFIG_SND_EMU10K1=y
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
> As far as the first one is concerned, the genirq-* patches look suspicious.
Hmm, what to do?
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-30 10:54 ` Jiri Slaby
@ 2006-07-30 11:08 ` Pavel Machek
2006-07-30 11:34 ` Rafael J. Wysocki
1 sibling, 0 replies; 107+ messages in thread
From: Pavel Machek @ 2006-07-30 11:08 UTC (permalink / raw)
To: Jiri Slaby
Cc: Rafael J. Wysocki, Andrew Morton, linux-kernel, linux-pm,
alsa-devel, mingo
Hi!
> >Please try to revert git-alsa.patch and see if the emu10k1-related problem
> >goes away.
>
> Wow, it didn't helped, I find out there is a difference between in-kernel
> and modules version of the driver. When compiled as modules
> (loaded/unloaded) suspending (and resuming) is working ok (enabled higmem
> and preempt back -- still no smp), when compiled in-kernel (see the config
> diff below), it doesn't resume.
Yes, that sometimes happens. You could work around it by catching
PM_EVENT_PRETHAW message and resetting the hardware in this case. Or
just fix the resume routine.
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] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-30 10:54 ` Jiri Slaby
2006-07-30 11:08 ` Pavel Machek
@ 2006-07-30 11:34 ` Rafael J. Wysocki
2006-07-31 13:59 ` [Alsa-devel] " Takashi Iwai
1 sibling, 1 reply; 107+ messages in thread
From: Rafael J. Wysocki @ 2006-07-30 11:34 UTC (permalink / raw)
To: Jiri Slaby
Cc: Pavel Machek, Andrew Morton, linux-kernel, linux-pm, alsa-devel, mingo
On Sunday 30 July 2006 12:54, Jiri Slaby wrote:
> Uncc: linux-mm
> Cc: alsa-devel
> Cc: mingo
>
> Rafael J. Wysocki wrote:
> > On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
> >> Rafael J. Wysocki napsal(a):
> >>> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> >>>> Hi!
> >>>>
> >>>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
> >>>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >>>>>>>>> Here is a snapshot of the screen:
> >>>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>>>>>>>>
> >>>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> >>>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
> >>>>>>>> with one of the devices that are resumed with IRQs off.
> >>>>>>>>
> >>>>>>>> Does vanila .18-rc2 work?
> >>>>>>> Yup, it does.
> >>>>>> Can you try up kernel, no highmem? (mem=512M)?
> >>>>> It writes then:
> >>>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> >>>>> in endless loop when resuming -- after reading from swap.
> >>>> Okay, so we have two different problems here.
>
> [snip]
>
> >>>> and one is probably driver problem with p16v (whatever it is).
> >>>>
> >>>> /data/l/linux/sound/pci/emu10k1/irq.c:
> >>>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> >>>> use=%d\n", status2, mask, pvoice, pvoice->use);
> >>>>
> >>>> ...aha, so you may want to unload emu10k1 for testing.
> >> Sure, this helped.
> >
> > So, we have two different regressions here.
> >
> > Please try to revert git-alsa.patch and see if the emu10k1-related problem
> > goes away.
>
> Wow, it didn't helped, I find out there is a difference between in-kernel and
> modules version of the driver. When compiled as modules (loaded/unloaded)
> suspending (and resuming) is working ok (enabled higmem and preempt back --
> still no smp), when compiled in-kernel (see the config diff below), it doesn't
> resume.
> @@ -1263,8 +1263,8 @@
> CONFIG_SND=y
> CONFIG_SND_TIMER=y
> CONFIG_SND_PCM=y
> -CONFIG_SND_HWDEP=m
> -CONFIG_SND_RAWMIDI=m
> +CONFIG_SND_HWDEP=y
> +CONFIG_SND_RAWMIDI=y
> CONFIG_SND_SEQUENCER=y
> # CONFIG_SND_SEQ_DUMMY is not set
> CONFIG_SND_OSSEMUL=y
> @@ -1282,8 +1282,8 @@
> #
> # Generic devices
> #
> -CONFIG_SND_AC97_CODEC=m
> -CONFIG_SND_AC97_BUS=m
> +CONFIG_SND_AC97_CODEC=y
> +CONFIG_SND_AC97_BUS=y
> # CONFIG_SND_DUMMY is not set
> # CONFIG_SND_VIRMIDI is not set
> # CONFIG_SND_MTPAV is not set
> @@ -1347,7 +1347,7 @@
> # CONFIG_SND_INDIGO is not set
> # CONFIG_SND_INDIGOIO is not set
> # CONFIG_SND_INDIGODJ is not set
> -CONFIG_SND_EMU10K1=m
> +CONFIG_SND_EMU10K1=y
> # CONFIG_SND_EMU10K1X is not set
> # CONFIG_SND_ENS1370 is not set
> # CONFIG_SND_ENS1371 is not set
If the driver is compiled in, its .suspend() routine gets called before the
suspend image is restored and puts the card in a state that confuses
the .resume() called after the image has been restored.
I think snd_emu10k1_suspend() should reset the device if state == PMSG_PRETHAW .
> > As far as the first one is concerned, the genirq-* patches look suspicious.
>
> Hmm, what to do?
I would try to revert them altogether and see what happens. If that doesn't
help, the only thing that comes to mind is to carry out a binary search for
the offending patch. :-(
Greetings,
Rafael
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [Alsa-devel] swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-30 11:34 ` Rafael J. Wysocki
@ 2006-07-31 13:59 ` Takashi Iwai
2006-07-31 14:03 ` Pavel Machek
0 siblings, 1 reply; 107+ messages in thread
From: Takashi Iwai @ 2006-07-31 13:59 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jiri Slaby, Andrew Morton, linux-pm, alsa-devel, linux-kernel,
Pavel Machek, mingo
At Sun, 30 Jul 2006 13:34:38 +0200,
Rafael J. Wysocki wrote:
>
> On Sunday 30 July 2006 12:54, Jiri Slaby wrote:
> > Uncc: linux-mm
> > Cc: alsa-devel
> > Cc: mingo
> >
> > Rafael J. Wysocki wrote:
> > > On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
> > >> Rafael J. Wysocki napsal(a):
> > >>> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> > >>>> Hi!
> > >>>>
> > >>>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
> > >>>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> > >>>>>>>>> Here is a snapshot of the screen:
> > >>>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> > >>>>>>>>>
> > >>>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> > >>>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
> > >>>>>>>> with one of the devices that are resumed with IRQs off.
> > >>>>>>>>
> > >>>>>>>> Does vanila .18-rc2 work?
> > >>>>>>> Yup, it does.
> > >>>>>> Can you try up kernel, no highmem? (mem=512M)?
> > >>>>> It writes then:
> > >>>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> > >>>>> in endless loop when resuming -- after reading from swap.
> > >>>> Okay, so we have two different problems here.
> >
> > [snip]
> >
> > >>>> and one is probably driver problem with p16v (whatever it is).
> > >>>>
> > >>>> /data/l/linux/sound/pci/emu10k1/irq.c:
> > >>>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> > >>>> use=%d\n", status2, mask, pvoice, pvoice->use);
> > >>>>
> > >>>> ...aha, so you may want to unload emu10k1 for testing.
> > >> Sure, this helped.
> > >
> > > So, we have two different regressions here.
> > >
> > > Please try to revert git-alsa.patch and see if the emu10k1-related problem
> > > goes away.
> >
> > Wow, it didn't helped, I find out there is a difference between in-kernel and
> > modules version of the driver. When compiled as modules (loaded/unloaded)
> > suspending (and resuming) is working ok (enabled higmem and preempt back --
> > still no smp), when compiled in-kernel (see the config diff below), it doesn't
> > resume.
> > @@ -1263,8 +1263,8 @@
> > CONFIG_SND=y
> > CONFIG_SND_TIMER=y
> > CONFIG_SND_PCM=y
> > -CONFIG_SND_HWDEP=m
> > -CONFIG_SND_RAWMIDI=m
> > +CONFIG_SND_HWDEP=y
> > +CONFIG_SND_RAWMIDI=y
> > CONFIG_SND_SEQUENCER=y
> > # CONFIG_SND_SEQ_DUMMY is not set
> > CONFIG_SND_OSSEMUL=y
> > @@ -1282,8 +1282,8 @@
> > #
> > # Generic devices
> > #
> > -CONFIG_SND_AC97_CODEC=m
> > -CONFIG_SND_AC97_BUS=m
> > +CONFIG_SND_AC97_CODEC=y
> > +CONFIG_SND_AC97_BUS=y
> > # CONFIG_SND_DUMMY is not set
> > # CONFIG_SND_VIRMIDI is not set
> > # CONFIG_SND_MTPAV is not set
> > @@ -1347,7 +1347,7 @@
> > # CONFIG_SND_INDIGO is not set
> > # CONFIG_SND_INDIGOIO is not set
> > # CONFIG_SND_INDIGODJ is not set
> > -CONFIG_SND_EMU10K1=m
> > +CONFIG_SND_EMU10K1=y
> > # CONFIG_SND_EMU10K1X is not set
> > # CONFIG_SND_ENS1370 is not set
> > # CONFIG_SND_ENS1371 is not set
>
> If the driver is compiled in, its .suspend() routine gets called before the
> suspend image is restored and puts the card in a state that confuses
> the .resume() called after the image has been restored.
>
> I think snd_emu10k1_suspend() should reset the device if state == PMSG_PRETHAW .
Hm, do we need such inconsitent behavior? I mean, for most drivers,
it doesn't matter whether it's built-in or a module: simply shutdown
at suspend, and initialize at resume.
Takashi
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [Alsa-devel] swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-31 13:59 ` [Alsa-devel] " Takashi Iwai
@ 2006-07-31 14:03 ` Pavel Machek
0 siblings, 0 replies; 107+ messages in thread
From: Pavel Machek @ 2006-07-31 14:03 UTC (permalink / raw)
To: Takashi Iwai
Cc: Rafael J. Wysocki, Jiri Slaby, Andrew Morton, linux-pm,
alsa-devel, linux-kernel, mingo
Hi!
> > If the driver is compiled in, its .suspend() routine gets called before the
> > suspend image is restored and puts the card in a state that confuses
> > the .resume() called after the image has been restored.
> >
> > I think snd_emu10k1_suspend() should reset the device if state == PMSG_PRETHAW .
>
> Hm, do we need such inconsitent behavior? I mean, for most drivers,
> it doesn't matter whether it's built-in or a module: simply shutdown
> at suspend, and initialize at resume.
That's of course the other (and better) solution.
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] 107+ messages in thread
* Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]
2006-07-29 23:58 ` Jiri Slaby
2006-07-30 0:06 ` Pavel Machek
@ 2006-07-30 11:36 ` James Courtier-Dutton
1 sibling, 0 replies; 107+ messages in thread
From: James Courtier-Dutton @ 2006-07-30 11:36 UTC (permalink / raw)
To: Jiri Slaby
Cc: Pavel Machek, Rafael J. Wysocki, Andrew Morton, linux-kernel,
linux-pm, linux-mm
Jiri Slaby wrote:
> Pavel Machek napsal(a):
>> Hi!
>>
>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>>> Here is a snapshot of the screen:
>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>>
>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>>> with one of the devices that are resumed with IRQs off.
>>>>
>>>> Does vanila .18-rc2 work?
>>> Yup, it does.
>> Can you try up kernel, no highmem? (mem=512M)?
>
> It writes then:
> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> in endless loop when resuming -- after reading from swap.
>
> regards,
The p16v chip is present on some creative sound cards, so this is an
ALSA snd-emu10k1 driver that is causing the endless loop. I will change
the code to force it to recover from the unexpected status 0xffffffff
value. The recovery will just consist of reducing the message to a
single message, instead of an endless loop. That value is never present
during normal operations, and the only case of it occurring that I know
about was during a pcmcia card unplug. If it occurs during insertion or
power resume, then I will have to think about some work around.
Is there any reason that an IRQ routine will be called before the
associated PCI IOPORTs have been configured. I did not think it was the
responsibility of the driver to redo all the initialisation PCI calls to
claim DMA and IOPORTs at power resume. To me it seems that the IRQ
routine is being called before PCI DMA and IOPORTs have been initialised.
James
^ permalink raw reply [flat|nested] 107+ messages in thread
* 2.6.18-rc2-mm1 fails to reboot properly on Dell Latitude CPiA
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (16 preceding siblings ...)
2006-07-29 17:58 ` swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1] Jiri Slaby
@ 2006-07-30 11:35 ` Christian Trefzer
2006-07-31 4:42 ` 2.6.18-rc2-mm1 Reuben Farrelly
2006-08-03 15:59 ` [2.6 patch] DVB_CORE must select I2C Adrian Bunk
19 siblings, 0 replies; 107+ messages in thread
From: Christian Trefzer @ 2006-07-30 11:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
After rebooting "normally" through init 6, or by hitting sysrq-b, the
backlight won't come back on and BIOS seems to hang at POST or
something. After a power cycle, it runs the extensive POST instead of
the quick one. Same goes for -rc1-mm2, btw. kexec runs fine, as long as
I provide the "implicit" initramfs file required by the newer -mm
releases at load time.
Any recent changes related to the way i386 machines are kicked to
reboot?
In case anyone needs any info, I'll provide that asap, but right now I
don't have a clue at all. Afraid I cannot test on my workstation, since
my screen died and I don't have a replacement/cannot afford a purchase
right now.
TIA,
Chris
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (17 preceding siblings ...)
2006-07-30 11:35 ` 2.6.18-rc2-mm1 fails to reboot properly on Dell Latitude CPiA Christian Trefzer
@ 2006-07-31 4:42 ` Reuben Farrelly
2006-07-31 4:57 ` 2.6.18-rc2-mm1 Andrew Morton
2006-08-03 15:59 ` [2.6 patch] DVB_CORE must select I2C Adrian Bunk
19 siblings, 1 reply; 107+ messages in thread
From: Reuben Farrelly @ 2006-07-31 4:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jan Beulich, Andi Kleen
On 27/07/2006 8:56 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>
> - git-klibc has been dropped due to very bad parallel-make problems.
>
> - Added a new line to the boilerplate, below!
>
> - Added Sam's lxdialog tree, as git-lxdialog.patch. You no longer need
> x-ray spectacles to read the menuconfig screens.
>
> - Lots of random patches. Many of them are bugfixes and I shall, as usual,
> go through them all identifying 2.6.18 material. But I can miss things, so
> please don't be afraid to point 2.6.18 candidates out to me.
>
> I also have, as usual, a number of bugfixes agains the git trees. I'll
> send these to the maintainers until they stick and then I lose track of
> them. So don't be afraid to send reminders to the subsystem maintainers
> either.
Just had this come out on the console:
(x86_64 - maybe unwinder related?)
Jul 31 16:35:01 tornado kernel: kjournald starting. Commit interval 5 seconds
Jul 31 16:35:01 tornado kernel: EXT3 FS on sdb1, internal journal
Jul 31 16:35:01 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 31 16:35:01 tornado kernel: php[28644]: segfault at 00007fff064edfe8 rip
0000003852a718a8 rsp 00007fff064edfd0 error 6
Jul 31 16:35:01 tornado kernel: general protection fault: 0000 [1] SMP
Jul 31 16:35:01 tornado kernel: last sysfs file: /block/fd0/dev
Jul 31 16:35:01 tornado kernel: CPU 1
Jul 31 16:35:01 tornado kernel: Modules linked in: hidp rfcomm l2cap bluetooth
ipv6 ip_gre iptable_filter iptable_nat ip_nat i
p_conntrack nfnetlink iptable_mangle ip_tables binfmt_misc i2c_i801 serio_raw
iTCO_wdt
Jul 31 16:35:01 tornado kernel: Pid: 15189, comm: nagios Not tainted
2.6.18-rc2-mm1 #2
Jul 31 16:35:01 tornado kernel: RIP: 0010:[<ffffffff8028f1d1>]
[<ffffffff8028f1d1>] notifier_call_chain+0x1e/0x45
Jul 31 16:35:01 tornado kernel: RSP: 0018:ffff810020d35d58 EFLAGS: 00010202
Jul 31 16:35:01 tornado kernel: RAX: 6b6b6b6b6b6b6b6b RBX: ffff81003913f100 RCX:
6b6b6b6b6b6b6b6b
Jul 31 16:35:01 tornado kernel: RDX: ffff81003913f100 RSI: 0000000000000001 RDI:
ffff81001fd8cec0
Jul 31 16:35:01 tornado kernel: RBP: ffff810020d35d78 R08: 0000000000000000 R09:
0000000000000001
Jul 31 16:35:01 tornado kernel: R10: 0000000000000001 R11: 0000000000000001 R12:
ffff81003913f100
Jul 31 16:35:01 tornado kernel: R13: 0000000000000001 R14: ffff81003913f100 R15:
ffff81003913f100
Jul 31 16:35:01 tornado kernel: FS: 00002b1be57ae450(0000)
GS:ffff81003f6eb430(0000) knlGS:0000000000000000
Jul 31 16:35:01 tornado kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jul 31 16:35:01 tornado kernel: CR2: 0000000000884ab0 CR3: 0000000034634000 CR4:
00000000000006e0
Jul 31 16:35:01 tornado kernel: Process nagios (pid: 15189, threadinfo
ffff810020d34000, task ffff81002ff8c0c0)
Jul 31 16:35:01 tornado kernel: Stack: ffff810020d35d88 ffff81003913f100
0000000000000001 0000000001200011
Jul 31 16:35:01 tornado kernel: ffff810020d35d88 ffffffff8028f226
ffff810020d35da8 ffffffff8028f61f
Jul 31 16:35:01 tornado kernel: ffff810020d36000 ffff81002ff8c0c0
ffff810020d35e78 ffffffff8021eafc
Jul 31 16:35:01 tornado kernel: Call Trace:
Jul 31 16:35:01 tornado kernel: [<ffffffff8028f226>]
raw_notifier_call_chain+0x9/0xb
Jul 31 16:35:01 tornado kernel: [<ffffffff8028f61f>] notify_watchers+0x64/0x69
Jul 31 16:35:01 tornado kernel: [<ffffffff8021eafc>] copy_process+0x4dc/0x15c0
Jul 31 16:35:01 tornado kernel: [<ffffffff80231867>] do_fork+0xf7/0x210
Jul 31 16:35:01 tornado kernel: [<ffffffff802692f7>] sys_clone+0x23/0x25
Jul 31 16:35:01 tornado kernel: [<ffffffff8025f7af>] ptregscall_common+0x67/0xac
Jul 31 16:35:01 tornado kernel: DWARF2 unwinder stuck at ptregscall_common+0x67/0xac
Jul 31 16:35:01 tornado kernel: Leftover inexact backtrace:
Jul 31 16:35:01 tornado kernel:
Jul 31 16:35:01 tornado kernel:
Jul 31 16:35:02 tornado kernel: Code: 48 8b 59 08 4c 89 e2 4c 89 ee 48 89 cf ff
11 66 85 c0 78 08
Jul 31 16:35:02 tornado kernel: RIP [<ffffffff8028f1d1>]
notifier_call_chain+0x1e/0x45
Jul 31 16:35:02 tornado kernel: RSP <ffff810020d35d58>
I've applied only one patch to the generic -rc2-mm1 that is in the newer -mm -
the x86_64-unwinder-fix.patch. That fixed the problem I had with the backtraces
repeating over and over until the kernel panicked.
Reuben
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: 2.6.18-rc2-mm1
2006-07-31 4:42 ` 2.6.18-rc2-mm1 Reuben Farrelly
@ 2006-07-31 4:57 ` Andrew Morton
2006-07-31 5:25 ` 2.6.18-rc2-mm1 Andi Kleen
0 siblings, 1 reply; 107+ messages in thread
From: Andrew Morton @ 2006-07-31 4:57 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: linux-kernel, jbeulich, ak
On Mon, 31 Jul 2006 16:42:28 +1200
Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>
> On 27/07/2006 8:56 p.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> >
> > - git-klibc has been dropped due to very bad parallel-make problems.
> >
> > - Added a new line to the boilerplate, below!
> >
> > - Added Sam's lxdialog tree, as git-lxdialog.patch. You no longer need
> > x-ray spectacles to read the menuconfig screens.
> >
> > - Lots of random patches. Many of them are bugfixes and I shall, as usual,
> > go through them all identifying 2.6.18 material. But I can miss things, so
> > please don't be afraid to point 2.6.18 candidates out to me.
> >
> > I also have, as usual, a number of bugfixes agains the git trees. I'll
> > send these to the maintainers until they stick and then I lose track of
> > them. So don't be afraid to send reminders to the subsystem maintainers
> > either.
>
> Just had this come out on the console:
>
> (x86_64 - maybe unwinder related?)
>
> Jul 31 16:35:01 tornado kernel: kjournald starting. Commit interval 5 seconds
> Jul 31 16:35:01 tornado kernel: EXT3 FS on sdb1, internal journal
> Jul 31 16:35:01 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode.
> Jul 31 16:35:01 tornado kernel: php[28644]: segfault at 00007fff064edfe8 rip
> 0000003852a718a8 rsp 00007fff064edfd0 error 6
Please watch the wrodwrapping - it makes things harder to read.
> Jul 31 16:35:01 tornado kernel: general protection fault: 0000 [1] SMP
> Jul 31 16:35:01 tornado kernel: last sysfs file: /block/fd0/dev
> Jul 31 16:35:01 tornado kernel: CPU 1
> Jul 31 16:35:01 tornado kernel: Modules linked in: hidp rfcomm l2cap bluetooth
> ipv6 ip_gre iptable_filter iptable_nat ip_nat i
> p_conntrack nfnetlink iptable_mangle ip_tables binfmt_misc i2c_i801 serio_raw
> iTCO_wdt
> Jul 31 16:35:01 tornado kernel: Pid: 15189, comm: nagios Not tainted
> 2.6.18-rc2-mm1 #2
> Jul 31 16:35:01 tornado kernel: RIP: 0010:[<ffffffff8028f1d1>]
> [<ffffffff8028f1d1>] notifier_call_chain+0x1e/0x45
> Jul 31 16:35:01 tornado kernel: RSP: 0018:ffff810020d35d58 EFLAGS: 00010202
> Jul 31 16:35:01 tornado kernel: RAX: 6b6b6b6b6b6b6b6b RBX: ffff81003913f100 RCX:
> 6b6b6b6b6b6b6b6b
> Jul 31 16:35:01 tornado kernel: RDX: ffff81003913f100 RSI: 0000000000000001 RDI:
> ffff81001fd8cec0
> Jul 31 16:35:01 tornado kernel: RBP: ffff810020d35d78 R08: 0000000000000000 R09:
> 0000000000000001
> Jul 31 16:35:01 tornado kernel: R10: 0000000000000001 R11: 0000000000000001 R12:
> ffff81003913f100
> Jul 31 16:35:01 tornado kernel: R13: 0000000000000001 R14: ffff81003913f100 R15:
> ffff81003913f100
> Jul 31 16:35:01 tornado kernel: FS: 00002b1be57ae450(0000)
> GS:ffff81003f6eb430(0000) knlGS:0000000000000000
> Jul 31 16:35:01 tornado kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> Jul 31 16:35:01 tornado kernel: CR2: 0000000000884ab0 CR3: 0000000034634000 CR4:
> 00000000000006e0
> Jul 31 16:35:01 tornado kernel: Process nagios (pid: 15189, threadinfo
> ffff810020d34000, task ffff81002ff8c0c0)
> Jul 31 16:35:01 tornado kernel: Stack: ffff810020d35d88 ffff81003913f100
> 0000000000000001 0000000001200011
> Jul 31 16:35:01 tornado kernel: ffff810020d35d88 ffffffff8028f226
> ffff810020d35da8 ffffffff8028f61f
> Jul 31 16:35:01 tornado kernel: ffff810020d36000 ffff81002ff8c0c0
> ffff810020d35e78 ffffffff8021eafc
> Jul 31 16:35:01 tornado kernel: Call Trace:
> Jul 31 16:35:01 tornado kernel: [<ffffffff8028f226>]
> raw_notifier_call_chain+0x9/0xb
> Jul 31 16:35:01 tornado kernel: [<ffffffff8028f61f>] notify_watchers+0x64/0x69
> Jul 31 16:35:01 tornado kernel: [<ffffffff8021eafc>] copy_process+0x4dc/0x15c0
> Jul 31 16:35:01 tornado kernel: [<ffffffff80231867>] do_fork+0xf7/0x210
> Jul 31 16:35:01 tornado kernel: [<ffffffff802692f7>] sys_clone+0x23/0x25
> Jul 31 16:35:01 tornado kernel: [<ffffffff8025f7af>] ptregscall_common+0x67/0xac
> Jul 31 16:35:01 tornado kernel: DWARF2 unwinder stuck at ptregscall_common+0x67/0xac
That looks like the task-watchers versus delay-accounting bug. The word on
the street is "change WATCH_TASK_CLONE to WATCH_TASK_INIT in the
delayacct_watch_task function", but nobody has done a patch.
I'm angling to drop the task-watchers patches from next -mm.
> Jul 31 16:35:01 tornado kernel: Leftover inexact backtrace:
> Jul 31 16:35:01 tornado kernel:
> Jul 31 16:35:01 tornado kernel:
> Jul 31 16:35:02 tornado kernel: Code: 48 8b 59 08 4c 89 e2 4c 89 ee 48 89 cf ff
> 11 66 85 c0 78 08
I think Jan has a fix for that in the works.
> Jul 31 16:35:02 tornado kernel: RIP [<ffffffff8028f1d1>]
> notifier_call_chain+0x1e/0x45
> Jul 31 16:35:02 tornado kernel: RSP <ffff810020d35d58>
>
> I've applied only one patch to the generic -rc2-mm1 that is in the newer -mm -
> the x86_64-unwinder-fix.patch. That fixed the problem I had with the backtraces
> repeating over and over until the kernel panicked.
>
OK, thanks. But the "DWARF2 unwinder stuck" problem remains.
^ permalink raw reply [flat|nested] 107+ messages in thread
* [2.6 patch] DVB_CORE must select I2C
2006-07-27 8:56 2.6.18-rc2-mm1 Andrew Morton
` (18 preceding siblings ...)
2006-07-31 4:42 ` 2.6.18-rc2-mm1 Reuben Farrelly
@ 2006-08-03 15:59 ` Adrian Bunk
2006-08-03 16:10 ` [v4l-dvb-maintainer] " Manu Abraham
2006-08-03 16:30 ` Trent Piepho
19 siblings, 2 replies; 107+ messages in thread
From: Adrian Bunk @ 2006-08-03 15:59 UTC (permalink / raw)
To: Andrew Morton, mchehab; +Cc: linux-kernel, v4l-dvb-maintainer, b.buschinski
On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc2-mm1:
>...
> +dvb-core-needs-i2c.patch
>...
> DVB fixes
>...
This means people who observed a compile error will now have the DVB
support silently removed from their kernel.
Please replace it with the patch below.
cu
Adrian
<-- snip -->
DVB_CORE=y, I2C=n resulted in the following compile error reported by
Bernd Buschinski in kernel Bugzilla #6843:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o: In function `dvb_pll_sleep':
dvb-pll.c:(.text+0x80020): undefined reference to `i2c_transfer'
drivers/built-in.o: In function `dvb_pll_set_params':
dvb-pll.c:(.text+0x80326): undefined reference to `i2c_transfer'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc2-mm1-modular/drivers/media/dvb/dvb-core/Kconfig.old 2006-08-03 17:53:54.000000000 +0200
+++ linux-2.6.18-rc2-mm1-modular/drivers/media/dvb/dvb-core/Kconfig 2006-08-03 17:54:06.000000000 +0200
@@ -1,6 +1,7 @@
config DVB_CORE
tristate "DVB Core Support"
depends on DVB
+ select I2C
select CRC32
help
DVB core utility functions for device handling, software fallbacks etc.
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [v4l-dvb-maintainer] [2.6 patch] DVB_CORE must select I2C
2006-08-03 15:59 ` [2.6 patch] DVB_CORE must select I2C Adrian Bunk
@ 2006-08-03 16:10 ` Manu Abraham
2006-08-03 16:30 ` Trent Piepho
1 sibling, 0 replies; 107+ messages in thread
From: Manu Abraham @ 2006-08-03 16:10 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, mchehab, v4l-dvb-maintainer, linux-kernel, b.buschinski
Adrian Bunk wrote:
> On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
>> ...
>> Changes since 2.6.18-rc2-mm1:
>> ...
>> +dvb-core-needs-i2c.patch
>> ...
>> DVB fixes
>> ...
>
> This means people who observed a compile error will now have the DVB
> support silently removed from their kernel.
>
> Please replace it with the patch below.
DVB_CORE should never depend on I2C, the reason being DVB_CORE does not
use anything of I2C but, the drivers which depend on I2C should be made
depend on I2C. That would be the right way to go.
Manu
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [v4l-dvb-maintainer] [2.6 patch] DVB_CORE must select I2C
2006-08-03 15:59 ` [2.6 patch] DVB_CORE must select I2C Adrian Bunk
2006-08-03 16:10 ` [v4l-dvb-maintainer] " Manu Abraham
@ 2006-08-03 16:30 ` Trent Piepho
2006-08-03 19:13 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 107+ messages in thread
From: Trent Piepho @ 2006-08-03 16:30 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, mchehab, v4l-dvb-maintainer, linux-kernel, b.buschinski
On Thu, 3 Aug 2006, Adrian Bunk wrote:
> On Thu, Jul 27, 2006 at 01:56:39AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc2-mm1:
> >...
> > +dvb-core-needs-i2c.patch
> >...
> > DVB fixes
> >...
>
> This means people who observed a compile error will now have the DVB
> support silently removed from their kernel.
This has been fixed differently already. dvb-core.ko doesn't actually use
I2C, only dvb-pll.ko does. Now the dvb-pll.ko module is no longer turned
on by DVB_CORE, but under a new option, DVB_PLL. That option depends on
I2C.
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [v4l-dvb-maintainer] [2.6 patch] DVB_CORE must select I2C
2006-08-03 16:30 ` Trent Piepho
@ 2006-08-03 19:13 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 107+ messages in thread
From: Mauro Carvalho Chehab @ 2006-08-03 19:13 UTC (permalink / raw)
To: Trent Piepho
Cc: Adrian Bunk, Andrew Morton, v4l-dvb-maintainer, linux-kernel,
b.buschinski
Hmm...
Em Qui, 2006-08-03 às 09:30 -0700, Trent Piepho escreveu:
> > This means people who observed a compile error will now have the DVB
> > support silently removed from their kernel.
I think Adrian's idea of selecting I2C, instead of depend on would be a
better approach for DVB_PLL.
>
> This has been fixed differently already. dvb-core.ko doesn't actually use
> I2C, only dvb-pll.ko does. Now the dvb-pll.ko module is no longer turned
> on by DVB_CORE, but under a new option, DVB_PLL. That option depends on
> I2C.
>
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 107+ messages in thread
