* mmotm 2010-05-19 - Kconfig dependency list from hell...
2010-05-19 23:13 mmotm 2010-05-19-16-12 uploaded akpm
@ 2010-05-20 15:21 ` Valdis.Kletnieks
2010-05-20 15:47 ` mmotm 2010-05-19 BUG weirdness Valdis.Kletnieks
` (3 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Valdis.Kletnieks @ 2010-05-20 15:21 UTC (permalink / raw)
To: Andrew Morton, Roman Zippel; +Cc: linux-kernel, linux-kbuild
[-- Attachment #1: Type: text/plain, Size: 3936 bytes --]
On Wed, 19 May 2010 16:13:09 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-05-19-16-12 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Looks like some code to sort the dependency list and eliminate duplicates is
called for. I hit '?' on a new prompt, and saw this:
CONFIG_COMEDI_FC:
Enable support for shared functions for low-level drivers.
This module is not used directly by end-users. Rather, it
is used by many other comedi drivers.
To compile this driver as a module, choose M here: the module will be
called comedi_fc.
Symbol: COMEDI_FC [=n]
Prompt: Comedi shared functions for low-level driver support
Defined at drivers/staging/comedi/Kconfig:1294
Depends on: STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n]
Location:
-> Device Drivers
-> Staging drivers (STAGING [=y])
-> Exclude Staging drivers from being built (STAGING_EXCLUDE_BUILD [=n])
Selected by: COMEDI_TEST [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n]
&& COMEDI_MISC_DRIVERS [=n] || COMEDI_DAS16M1 [=n] && STAGING [=y] &&
!STAGING_EXCLUDE_BUILD [=n] && COMEDI_ISA_DRIVERS [=n] && ISA [=n] ||
COMEDI_DAS16 [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_ISA_DRIVERS [=n] && ISA [=n] || COMEDI_DAS800 [=n] && STAGING [=y] &&
!STAGING_EXCLUDE_BUILD [=n] && COMEDI_ISA_DRIVERS [=n] && ISA [=n] ||
COMEDI_DAS1800 [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_ISA_DRIVERS [=n] && ISA [=n] || COMEDI_DT282X [=n] && STAGING [=y] &&
!STAGING_EXCLUDE_BUILD [=n] && COMEDI_ISA_DRIVERS [=n] && ISA [=n] ||
COMEDI_ADDI_APCI_3001 [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_PCI_DRIVERS [=n] && PCI [=y] || COMEDI_ADDI_APCI_3120 [=n] && STAGING
[=y] && !STAGING_EXCLUDE_BUILD [=n] && COMEDI_PCI_DRIVERS [=n] && PCI [=y] ||
COMEDI_ADL_PCI9111 [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_PCI_DRIVERS [=n] && PCI [=y] || COMEDI_ADL_PCI9118 [=n] && STAGING [=y]
&& !STAGING_EXCLUDE_BUILD [=n] && COMEDI_PCI_DRIVERS [=n] && PCI [=y] ||
COMEDI_AMPLC_PCI224 [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_PCI_DRIVERS [=n] && PCI [=y] || COMEDI_GSC_HPDI [=n] && STAGING [=y] &&
!STAGING_EXCLUDE_BUILD [=n] && COMEDI_PCI_DRIVERS [=n] && PCI [=y] ||
COMEDI_CB_PCIDAS64 [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_PCI_DRIVERS [=n] && PCI [=y] || COMEDI_CB_PCIDAS [=n] && STAGING [=y] &&
!STAGING_EXCLUDE_BUILD [=n] && COMEDI_PCI_DRIVERS [=n] && PCI [=y] ||
COMEDI_S626 [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_PCI_DRIVERS [=n] && PCI [=y] || COMEDI_NI_MIO_CS [=n] && STAGING [=y] &&
!STAGING_EXCLUDE_BUILD [=n] && COMEDI_PCMCIA_DRIVERS [=n] && PCMCIA [=y] &&
COMEDI_NI_TIO [=n] && COMEDI_NI_COMMON [=n] || COMEDI_USBDUXFAST [=n] &&
STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] && COMEDI_USB_DRIVERS [=n] && USB
[=y] || COMEDI_NI_LABPC [=n] && STAGING [=y] && !STAGING_EXCLUDE_BUILD [=n] &&
COMEDI_NI_COMMON [=n]
(Last line wrapped for readability). That includes these dups:
19 !STAGING_EXCLUDE_BUILD [=n]
18 STAGING [=y]
9 COMEDI_PCI_DRIVERS [=n]
5 COMEDI_ISA_DRIVERS [=n]
It would probably be harder to reduce these:
1 PCI [=y] || COMEDI_S626 [=n]
1 PCI [=y] || COMEDI_NI_MIO_CS [=n]
1 PCI [=y] || COMEDI_GSC_HPDI [=n]
1 PCI [=y] || COMEDI_CB_PCIDAS64 [=n]
1 PCI [=y] || COMEDI_CB_PCIDAS [=n]
1 PCI [=y] || COMEDI_AMPLC_PCI224 [=n]
1 PCI [=y] || COMEDI_ADL_PCI9118 [=n]
1 PCI [=y] || COMEDI_ADL_PCI9111 [=n]
1 PCI [=y] || COMEDI_ADDI_APCI_3120 [=n]
1 ISA [=n] || COMEDI_DT282X [=n]
1 ISA [=n] || COMEDI_DAS800 [=n]
1 ISA [=n] || COMEDI_DAS1800 [=n]
1 ISA [=n] || COMEDI_DAS16 [=n]
1 ISA [=n] || COMEDI_ADDI_APCI_3001 [=n]
(Is there a reason these don't print with () around them? It looks like it
needs them to enforce proper semantics...)
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* mmotm 2010-05-19 BUG weirdness...
2010-05-19 23:13 mmotm 2010-05-19-16-12 uploaded akpm
2010-05-20 15:21 ` mmotm 2010-05-19 - Kconfig dependency list from hell Valdis.Kletnieks
@ 2010-05-20 15:47 ` Valdis.Kletnieks
2010-05-20 12:55 ` Andrew Morton
2010-05-20 21:08 ` [PATCH -mmotm] media: ak881x needs slab.h Randy Dunlap
` (2 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: Valdis.Kletnieks @ 2010-05-20 15:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5736 bytes --]
On Wed, 19 May 2010 16:13:09 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-05-19-16-12 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
So I'm looking closer at the BUG I just posted - I had deleted two further
BUGs because they were obviously follow-ons to the original. But then...
Note the following 2 lines:
[ 35.357018] note: keymap[2481] exited with preempt_count 1
[ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
The kernel reports the instigating process exited - and then reports it as
the offender for a "scheduling while atomic". Insufficient attempted cleanup
after the first BUG? Do we care because this is a sign of a scheduler bug
that could trip on a non-BUG as well, or is it "all bets are off" because of
the first BUG?
[ 35.294528] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 35.295005] IP: [<(null)>] (null)
[ 35.296935] PGD 11da3c067 PUD 11d4ad067 PMD 0
[ 35.296935] Oops: 0010 [#1] PREEMPT SMP
[ 35.299667] last sysfs file: /sys/devices/pci0000:00/0000:00:1a.7/usb1/idVendor
[ 35.300328] CPU 0
[ 35.300328] Modules linked in:
[ 35.300328]
[ 35.300328] Pid: 2481, comm: keymap Not tainted 2.6.34-mmotm0519 #1 0X564R/Latitude E6500
[ 35.300328] RIP: 0010:[<0000000000000000>] [<(null)>] (null)
[ 35.300328] RSP: 0018:ffff88011d4d5cb0 EFLAGS: 00010046
[ 35.310163] RAX: 0000000000000000 RBX: ffff88011c03e000 RCX: 0000000000000081
[ 35.310163] RDX: ffff88011d4d5cc4 RSI: ffff88011d4d5cc8 RDI: ffff88011c03e000
[ 35.310163] RBP: ffff88011d4d5d28 R08: ffff88011e9b28e8 R09: 0000000000000001
[ 35.310163] R10: ffffffff81e0b160 R11: 0000000000000004 R12: 00000000000000a4
[ 35.310163] R13: ffff88011c03e830 R14: 0000000000000286 R15: ffff88011d4d5cc8
[ 35.310163] FS: 00007f4b86283700(0000) GS:ffff880002600000(0000) knlGS:0000000000000000
[ 35.319397] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.319397] CR2: 0000000000000000 CR3: 000000011d575000 CR4: 00000000000406f0
[ 35.319397] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 35.319397] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 35.319397] Process keymap (pid: 2481, threadinfo ffff88011d4d4000, task ffff88011e9b28c0)
[ 35.319397] Stack:
[ 35.319397] ffffffff813bf3d1 ffff88011d4d5cf8 0000008100000246 00000081000000a4
[ 35.319397] <0> 0000000000000004 0000000000000000 ffff88011d4d5cc4 ffff88011cf11200
[ 35.319397] <0> ffff88011c179000 ffff88011d4d5d28 0000000000000081 00007fff9ee21fa0
[ 35.319397] Call Trace:
[ 35.319397] [<ffffffff813bf3d1>] ? input_set_keycode+0xad/0x12c
[ 35.319397] [<ffffffff813c231d>] evdev_do_ioctl+0x22b/0x79b
[ 35.337913] [<ffffffff815a4b04>] ? __mutex_lock_common+0x564/0x580
[ 35.337913] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
[ 35.341507] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
[ 35.341507] [<ffffffff813c28f0>] evdev_ioctl_handler+0x63/0x80
[ 35.344034] [<ffffffff813c292a>] evdev_ioctl+0xb/0xd
[ 35.344034] [<ffffffff810ea6cd>] vfs_ioctl+0x2d/0xa1
[ 35.344034] [<ffffffff810eac4c>] do_vfs_ioctl+0x494/0x4cd
[ 35.344034] [<ffffffff810eacdc>] sys_ioctl+0x57/0x95
[ 35.344034] [<ffffffff8100266b>] system_call_fastpath+0x16/0x1b
[ 35.344034] Code: Bad RIP value.
[ 35.344034] RIP [<(null)>] (null)
[ 35.344034] RSP <ffff88011d4d5cb0>
[ 35.344034] CR2: 0000000000000000
[ 35.357018] ---[ end trace 394fa5aa8a77b6f3 ]---
[ 35.357018] note: keymap[2481] exited with preempt_count 1
[ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
[ 35.361774] INFO: lockdep is turned off.
[ 35.363106] Modules linked in:
[ 35.364442] Pid: 2481, comm: keymap Tainted: G D 2.6.34-mmotm0519 #1
[ 35.365759] Call Trace:
[ 35.367082] [<ffffffff810653af>] ? __debug_show_held_locks+0x1b/0x24
[ 35.368391] [<ffffffff8102e742>] __schedule_bug+0x6d/0x72
[ 35.369716] [<ffffffff815a34de>] schedule+0x10a/0x902
[ 35.371012] [<ffffffff81030b30>] __cond_resched+0x13/0x1f
[ 35.372305] [<ffffffff815a3dfa>] _cond_resched+0x16/0x1d
[ 35.373576] [<ffffffff810c3f10>] unmap_vmas+0x7b7/0x828
[ 35.374850] [<ffffffff810c922b>] exit_mmap+0x82/0xfd
[ 35.376093] [<ffffffff81035ede>] mmput+0x43/0xcf
[ 35.377339] [<ffffffff8103a23a>] exit_mm+0x11d/0x12a
[ 35.378564] [<ffffffff8103c21e>] do_exit+0x2e1/0x932
[ 35.379792] [<ffffffff810393cf>] ? kmsg_dump+0x136/0x150
[ 35.381014] [<ffffffff815a78b5>] oops_end+0x89/0x8e
[ 35.382211] [<ffffffff8101fc79>] no_context+0x1f7/0x206
[ 35.383384] [<ffffffff8101fe0f>] __bad_area_nosemaphore+0x187/0x1c7
[ 35.384571] [<ffffffff810674bf>] ? __lock_acquire+0xc58/0xd09
[ 35.385751] [<ffffffff8101fe5d>] bad_area_nosemaphore+0xe/0x10
[ 35.386936] [<ffffffff815a9433>] do_page_fault+0x1f3/0x44b
[ 35.388111] [<ffffffff815a58f2>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 35.389296] [<ffffffff815a6cbf>] page_fault+0x1f/0x30
[ 35.390437] [<ffffffff813bf3d1>] ? input_set_keycode+0xad/0x12c
[ 35.391534] [<ffffffff813c231d>] evdev_do_ioctl+0x22b/0x79b
[ 35.392639] [<ffffffff815a4b04>] ? __mutex_lock_common+0x564/0x580
[ 35.393722] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
[ 35.394747] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
[ 35.395748] [<ffffffff813c28f0>] evdev_ioctl_handler+0x63/0x80
[ 35.396686] [<ffffffff813c292a>] evdev_ioctl+0xb/0xd
[ 35.397627] [<ffffffff810ea6cd>] vfs_ioctl+0x2d/0xa1
[ 35.398541] [<ffffffff810eac4c>] do_vfs_ioctl+0x494/0x4cd
[ 35.399471] [<ffffffff810eacdc>] sys_ioctl+0x57/0x95
[ 35.400387] [<ffffffff8100266b>] system_call_fastpath+0x16/0x1b
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: mmotm 2010-05-19 BUG weirdness...
2010-05-20 15:47 ` mmotm 2010-05-19 BUG weirdness Valdis.Kletnieks
@ 2010-05-20 12:55 ` Andrew Morton
2010-05-20 16:45 ` Dmitry Torokhov
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Andrew Morton @ 2010-05-20 12:55 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel, Dmitry Torokhov
On Thu, 20 May 2010 11:47:50 -0400 Valdis.Kletnieks@vt.edu wrote:
> On Wed, 19 May 2010 16:13:09 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-05-19-16-12 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> So I'm looking closer at the BUG I just posted
I can't see that BUG report on lkml or in inbox.
> - I had deleted two further
> BUGs because they were obviously follow-ons to the original. But then...
>
> Note the following 2 lines:
>
> [ 35.357018] note: keymap[2481] exited with preempt_count 1
> [ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
>
> The kernel reports the instigating process exited - and then reports it as
> the offender for a "scheduling while atomic". Insufficient attempted cleanup
> after the first BUG? Do we care because this is a sign of a scheduler bug
> that could trip on a non-BUG as well, or is it "all bets are off" because of
> the first BUG?
Yes, the oops code will end up calling do_exit() to get rid of this
process and to try to keep the machine limping along. So if you hit an
oops with (say) a spinlock held, the task will end up calling do_exit()
with a non-zero preempt_count.
So the only problem I'm seeing here is .... Dmitry's ;)
> [ 35.294528] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 35.295005] IP: [<(null)>] (null)
> [ 35.296935] PGD 11da3c067 PUD 11d4ad067 PMD 0
> [ 35.296935] Oops: 0010 [#1] PREEMPT SMP
> [ 35.299667] last sysfs file: /sys/devices/pci0000:00/0000:00:1a.7/usb1/idVendor
> [ 35.300328] CPU 0
> [ 35.300328] Modules linked in:
> [ 35.300328]
> [ 35.300328] Pid: 2481, comm: keymap Not tainted 2.6.34-mmotm0519 #1 0X564R/Latitude E6500
> [ 35.300328] RIP: 0010:[<0000000000000000>] [<(null)>] (null)
> [ 35.300328] RSP: 0018:ffff88011d4d5cb0 EFLAGS: 00010046
> [ 35.310163] RAX: 0000000000000000 RBX: ffff88011c03e000 RCX: 0000000000000081
> [ 35.310163] RDX: ffff88011d4d5cc4 RSI: ffff88011d4d5cc8 RDI: ffff88011c03e000
> [ 35.310163] RBP: ffff88011d4d5d28 R08: ffff88011e9b28e8 R09: 0000000000000001
> [ 35.310163] R10: ffffffff81e0b160 R11: 0000000000000004 R12: 00000000000000a4
> [ 35.310163] R13: ffff88011c03e830 R14: 0000000000000286 R15: ffff88011d4d5cc8
> [ 35.310163] FS: 00007f4b86283700(0000) GS:ffff880002600000(0000) knlGS:0000000000000000
> [ 35.319397] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 35.319397] CR2: 0000000000000000 CR3: 000000011d575000 CR4: 00000000000406f0
> [ 35.319397] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 35.319397] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 35.319397] Process keymap (pid: 2481, threadinfo ffff88011d4d4000, task ffff88011e9b28c0)
> [ 35.319397] Stack:
> [ 35.319397] ffffffff813bf3d1 ffff88011d4d5cf8 0000008100000246 00000081000000a4
> [ 35.319397] <0> 0000000000000004 0000000000000000 ffff88011d4d5cc4 ffff88011cf11200
> [ 35.319397] <0> ffff88011c179000 ffff88011d4d5d28 0000000000000081 00007fff9ee21fa0
> [ 35.319397] Call Trace:
> [ 35.319397] [<ffffffff813bf3d1>] ? input_set_keycode+0xad/0x12c
> [ 35.319397] [<ffffffff813c231d>] evdev_do_ioctl+0x22b/0x79b
> [ 35.337913] [<ffffffff815a4b04>] ? __mutex_lock_common+0x564/0x580
> [ 35.337913] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
> [ 35.341507] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
> [ 35.341507] [<ffffffff813c28f0>] evdev_ioctl_handler+0x63/0x80
> [ 35.344034] [<ffffffff813c292a>] evdev_ioctl+0xb/0xd
> [ 35.344034] [<ffffffff810ea6cd>] vfs_ioctl+0x2d/0xa1
> [ 35.344034] [<ffffffff810eac4c>] do_vfs_ioctl+0x494/0x4cd
> [ 35.344034] [<ffffffff810eacdc>] sys_ioctl+0x57/0x95
> [ 35.344034] [<ffffffff8100266b>] system_call_fastpath+0x16/0x1b
> [ 35.344034] Code: Bad RIP value.
> [ 35.344034] RIP [<(null)>] (null)
> [ 35.344034] RSP <ffff88011d4d5cb0>
> [ 35.344034] CR2: 0000000000000000
> [ 35.357018] ---[ end trace 394fa5aa8a77b6f3 ]---
> [ 35.357018] note: keymap[2481] exited with preempt_count 1
> [ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
> [ 35.361774] INFO: lockdep is turned off.
> [ 35.363106] Modules linked in:
> [ 35.364442] Pid: 2481, comm: keymap Tainted: G D 2.6.34-mmotm0519 #1
> [ 35.365759] Call Trace:
> [ 35.367082] [<ffffffff810653af>] ? __debug_show_held_locks+0x1b/0x24
> [ 35.368391] [<ffffffff8102e742>] __schedule_bug+0x6d/0x72
> [ 35.369716] [<ffffffff815a34de>] schedule+0x10a/0x902
> [ 35.371012] [<ffffffff81030b30>] __cond_resched+0x13/0x1f
> [ 35.372305] [<ffffffff815a3dfa>] _cond_resched+0x16/0x1d
> [ 35.373576] [<ffffffff810c3f10>] unmap_vmas+0x7b7/0x828
> [ 35.374850] [<ffffffff810c922b>] exit_mmap+0x82/0xfd
> [ 35.376093] [<ffffffff81035ede>] mmput+0x43/0xcf
> [ 35.377339] [<ffffffff8103a23a>] exit_mm+0x11d/0x12a
> [ 35.378564] [<ffffffff8103c21e>] do_exit+0x2e1/0x932
> [ 35.379792] [<ffffffff810393cf>] ? kmsg_dump+0x136/0x150
> [ 35.381014] [<ffffffff815a78b5>] oops_end+0x89/0x8e
> [ 35.382211] [<ffffffff8101fc79>] no_context+0x1f7/0x206
> [ 35.383384] [<ffffffff8101fe0f>] __bad_area_nosemaphore+0x187/0x1c7
> [ 35.384571] [<ffffffff810674bf>] ? __lock_acquire+0xc58/0xd09
> [ 35.385751] [<ffffffff8101fe5d>] bad_area_nosemaphore+0xe/0x10
> [ 35.386936] [<ffffffff815a9433>] do_page_fault+0x1f3/0x44b
> [ 35.388111] [<ffffffff815a58f2>] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 35.389296] [<ffffffff815a6cbf>] page_fault+0x1f/0x30
> [ 35.390437] [<ffffffff813bf3d1>] ? input_set_keycode+0xad/0x12c
> [ 35.391534] [<ffffffff813c231d>] evdev_do_ioctl+0x22b/0x79b
> [ 35.392639] [<ffffffff815a4b04>] ? __mutex_lock_common+0x564/0x580
> [ 35.393722] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
> [ 35.394747] [<ffffffff813c28ca>] ? evdev_ioctl_handler+0x3d/0x80
> [ 35.395748] [<ffffffff813c28f0>] evdev_ioctl_handler+0x63/0x80
> [ 35.396686] [<ffffffff813c292a>] evdev_ioctl+0xb/0xd
> [ 35.397627] [<ffffffff810ea6cd>] vfs_ioctl+0x2d/0xa1
> [ 35.398541] [<ffffffff810eac4c>] do_vfs_ioctl+0x494/0x4cd
> [ 35.399471] [<ffffffff810eacdc>] sys_ioctl+0x57/0x95
> [ 35.400387] [<ffffffff8100266b>] system_call_fastpath+0x16/0x1b
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: mmotm 2010-05-19 BUG weirdness...
2010-05-20 12:55 ` Andrew Morton
@ 2010-05-20 16:45 ` Dmitry Torokhov
2010-05-20 17:52 ` Valdis.Kletnieks
2010-05-20 18:17 ` [2.6.34 PATCH] kernel: fix exit message for dead process Valdis.Kletnieks
2 siblings, 0 replies; 12+ messages in thread
From: Dmitry Torokhov @ 2010-05-20 16:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: Valdis.Kletnieks, linux-kernel
On Thursday 20 May 2010 05:55:20 am Andrew Morton wrote:
> On Thu, 20 May 2010 11:47:50 -0400 Valdis.Kletnieks@vt.edu wrote:
> > On Wed, 19 May 2010 16:13:09 PDT, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2010-05-19-16-12 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > So I'm looking closer at the BUG I just posted
>
> I can't see that BUG report on lkml or in inbox.
>
> > - I had deleted two further
> > BUGs because they were obviously follow-ons to the original. But then...
> >
> > Note the following 2 lines:
> >
> > [ 35.357018] note: keymap[2481] exited with preempt_count 1
> > [ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
> >
> > The kernel reports the instigating process exited - and then reports it
> > as the offender for a "scheduling while atomic". Insufficient attempted
> > cleanup after the first BUG? Do we care because this is a sign of a
> > scheduler bug that could trip on a non-BUG as well, or is it "all bets
> > are off" because of the first BUG?
>
> Yes, the oops code will end up calling do_exit() to get rid of this
> process and to try to keep the machine limping along. So if you hit an
> oops with (say) a spinlock held, the task will end up calling do_exit()
> with a non-zero preempt_count.
>
> So the only problem I'm seeing here is .... Dmitry's ;)
Hmm, any chance you could stick a printk in input_set_keycode and print
the id/name of the input device?
--
Dmitry
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mmotm 2010-05-19 BUG weirdness...
2010-05-20 12:55 ` Andrew Morton
2010-05-20 16:45 ` Dmitry Torokhov
@ 2010-05-20 17:52 ` Valdis.Kletnieks
2010-05-20 18:17 ` [2.6.34 PATCH] kernel: fix exit message for dead process Valdis.Kletnieks
2 siblings, 0 replies; 12+ messages in thread
From: Valdis.Kletnieks @ 2010-05-20 17:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Dmitry Torokhov
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
On Thu, 20 May 2010 08:55:20 EDT, Andrew Morton said:
> On Thu, 20 May 2010 11:47:50 -0400 Valdis.Kletnieks@vt.edu wrote:
>
> > On Wed, 19 May 2010 16:13:09 PDT, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2010-05-19-16-12 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > So I'm looking closer at the BUG I just posted
>
> I can't see that BUG report on lkml or in inbox.
Whoops, the first one didn't make it out of my drafts folder for some reason,
is sent now..
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [2.6.34 PATCH] kernel: fix exit message for dead process
2010-05-20 12:55 ` Andrew Morton
2010-05-20 16:45 ` Dmitry Torokhov
2010-05-20 17:52 ` Valdis.Kletnieks
@ 2010-05-20 18:17 ` Valdis.Kletnieks
2010-05-20 18:36 ` Andrew Morton
2 siblings, 1 reply; 12+ messages in thread
From: Valdis.Kletnieks @ 2010-05-20 18:17 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linux-kernel
If a process is exiting with a non-zero preempt_count, it's in fact almost
certainly going to fail to do so because it is exiting due to a BUG or OOPS
while it held a lock, at which point it will never actually exit. So change
the message to say it attempted to do so, rather than implying it succeeded.
Problem spotted when a process BUG'ed, the kernel reported the 'exited' status,
and then proceeded to BUG twice more dealing with the now-zombied process:
> [ 35.357018] note: keymap[2481] exited with preempt_count 1
> [ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
Yes, one line is 83 characters. It's still more readable than a split printk.
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
--- linux-2.6.34-mmotm0519/kernel/exit.c.dist 2010-05-20 10:59:11.646870592 -0400
+++ linux-2.6.34-mmotm0519/kernel/exit.c 2010-05-20 14:05:16.068800223 -0400
@@ -936,7 +936,7 @@ NORET_TYPE void do_exit(long code)
raw_spin_unlock_wait(&tsk->pi_lock);
if (unlikely(in_atomic()))
- printk(KERN_INFO "note: %s[%d] exited with preempt_count %d\n",
+ printk(KERN_INFO "note: %s[%d] tried to exit with preempt_count %d\n",
current->comm, task_pid_nr(current),
preempt_count());
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [2.6.34 PATCH] kernel: fix exit message for dead process
2010-05-20 18:17 ` [2.6.34 PATCH] kernel: fix exit message for dead process Valdis.Kletnieks
@ 2010-05-20 18:36 ` Andrew Morton
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2010-05-20 18:36 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Linus Torvalds, linux-kernel, Ingo Molnar, Peter Zijlstra
On Thu, 20 May 2010 14:17:40 -0400
Valdis.Kletnieks@vt.edu wrote:
> If a process is exiting with a non-zero preempt_count, it's in fact almost
> certainly going to fail to do so because it is exiting due to a BUG or OOPS
> while it held a lock, at which point it will never actually exit. So change
> the message to say it attempted to do so, rather than implying it succeeded.
> Problem spotted when a process BUG'ed, the kernel reported the 'exited' status,
> and then proceeded to BUG twice more dealing with the now-zombied process:
>
> > [ 35.357018] note: keymap[2481] exited with preempt_count 1
> > [ 35.360503] BUG: scheduling while atomic: keymap/2481/0x10000002
>
> Yes, one line is 83 characters. It's still more readable than a split printk.
>
> Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
>
> --- linux-2.6.34-mmotm0519/kernel/exit.c.dist 2010-05-20 10:59:11.646870592 -0400
> +++ linux-2.6.34-mmotm0519/kernel/exit.c 2010-05-20 14:05:16.068800223 -0400
> @@ -936,7 +936,7 @@ NORET_TYPE void do_exit(long code)
> raw_spin_unlock_wait(&tsk->pi_lock);
>
> if (unlikely(in_atomic()))
> - printk(KERN_INFO "note: %s[%d] exited with preempt_count %d\n",
> + printk(KERN_INFO "note: %s[%d] tried to exit with preempt_count %d\n",
> current->comm, task_pid_nr(current),
> preempt_count());
a) this message is kinda like __schedule_bug(), only
__schedule_bug() does more stuff. Perhaps some sharing is in order.
b) do_exit() eventually calls schedule() anyway, so if we have a bad
preempt_count() here, schedule() should end up calling
__schedule_bug(), so we don't need this message in do_exit().
ah-hah, __schedule_bug() doesn't get called on the exit() path due to
task->state==TASK_DEAD. But we can surely change that.
schedule_debug() needs fixing anyway - what's it doing assuming that
TASK_RUNNING==0?
c) it's pretty pointless printing anything at all if this task has
oopsed. This info is never interesting and will just cause the
useful info to scroll into oblivion.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH -mmotm] media: ak881x needs slab.h
2010-05-19 23:13 mmotm 2010-05-19-16-12 uploaded akpm
2010-05-20 15:21 ` mmotm 2010-05-19 - Kconfig dependency list from hell Valdis.Kletnieks
2010-05-20 15:47 ` mmotm 2010-05-19 BUG weirdness Valdis.Kletnieks
@ 2010-05-20 21:08 ` Randy Dunlap
2010-06-01 6:04 ` Ingo Molnar
2010-05-20 21:08 ` [PATCH -mmotm] backlight: fix s6e63m0 kconfig Randy Dunlap
2010-05-20 21:08 ` [PATCH -mmotm] backlight: fix s6e63m0 device attr function return types Randy Dunlap
4 siblings, 1 reply; 12+ messages in thread
From: Randy Dunlap @ 2010-05-20 21:08 UTC (permalink / raw)
To: akpm, Guennadi Liakhovetski, Mauro Carvalho Chehab
Cc: linux-kernel, linux-media
From: Randy Dunlap <randy.dunlap@oracle.com>
Add slab.h to fix ak881x build:
drivers/media/video/ak881x.c:265:error: implicit declaration of function 'kzalloc'
drivers/media/video/ak881x.c:265:warning: assignment makes pointer from integer without a cast
drivers/media/video/ak881x.c:283:error: implicit declaration of function 'kfree'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
---
drivers/media/video/ak881x.c | 1 +
1 file changed, 1 insertion(+)
--- mmotm-2010-0519-1612.orig/drivers/media/video/ak881x.c
+++ mmotm-2010-0519-1612/drivers/media/video/ak881x.c
@@ -11,6 +11,7 @@
#include <linux/i2c.h>
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/slab.h>
#include <linux/videodev2.h>
#include <media/ak881x.h>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH -mmotm] media: ak881x needs slab.h
2010-05-20 21:08 ` [PATCH -mmotm] media: ak881x needs slab.h Randy Dunlap
@ 2010-06-01 6:04 ` Ingo Molnar
0 siblings, 0 replies; 12+ messages in thread
From: Ingo Molnar @ 2010-06-01 6:04 UTC (permalink / raw)
To: Randy Dunlap
Cc: akpm, Guennadi Liakhovetski, Mauro Carvalho Chehab, linux-kernel,
linux-media
* Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Add slab.h to fix ak881x build:
>
> drivers/media/video/ak881x.c:265:error: implicit declaration of function 'kzalloc'
> drivers/media/video/ak881x.c:265:warning: assignment makes pointer from integer without a cast
> drivers/media/video/ak881x.c:283:error: implicit declaration of function 'kfree'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
> ---
> drivers/media/video/ak881x.c | 1 +
This build bug is now triggering in .35-rc1 as well.
Ingo
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH -mmotm] backlight: fix s6e63m0 kconfig
2010-05-19 23:13 mmotm 2010-05-19-16-12 uploaded akpm
` (2 preceding siblings ...)
2010-05-20 21:08 ` [PATCH -mmotm] media: ak881x needs slab.h Randy Dunlap
@ 2010-05-20 21:08 ` Randy Dunlap
2010-05-20 21:08 ` [PATCH -mmotm] backlight: fix s6e63m0 device attr function return types Randy Dunlap
4 siblings, 0 replies; 12+ messages in thread
From: Randy Dunlap @ 2010-05-20 21:08 UTC (permalink / raw)
To: akpm, InKi Dae, Richard Purdie; +Cc: lkml
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix kconfig file dependency and help text.
Move the driver's Kconfig symbol inside the LCD_CLASS_DEVICE block.
When CONFIG_BACKLIGHT_CLASS_DEVICE is not enabled:
ERROR: "backlight_device_register" [drivers/video/backlight/s6e63m0.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: InKi Dae <inki.dae@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
---
Looks like several backlight/LCD drivers have this kind of relationship.
drivers/video/backlight/Kconfig | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- mmotm-2010-0519-1612.orig/drivers/video/backlight/Kconfig
+++ mmotm-2010-0519-1612/drivers/video/backlight/Kconfig
@@ -101,14 +101,16 @@ config LCD_HP700
If you have an HP Jornada 700 series handheld (710/720/728)
say Y to enable LCD control driver.
-endif # LCD_CLASS_DEVICE
-
config LCD_S6E63M0
tristate "S6E63M0 AMOLED LCD Driver"
- depends on LCD_CLASS_DEVICE && SPI
+ depends on SPI && BACKLIGHT_CLASS_DEVICE
default n
help
- If you have an S6E63M0 LCD Panel say Y to enable LCD control driver
+ If you have an S6E63M0 LCD Panel, say Y to enable its
+ LCD control driver.
+
+endif # LCD_CLASS_DEVICE
+
#
# Backlight
#
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH -mmotm] backlight: fix s6e63m0 device attr function return types
2010-05-19 23:13 mmotm 2010-05-19-16-12 uploaded akpm
` (3 preceding siblings ...)
2010-05-20 21:08 ` [PATCH -mmotm] backlight: fix s6e63m0 kconfig Randy Dunlap
@ 2010-05-20 21:08 ` Randy Dunlap
4 siblings, 0 replies; 12+ messages in thread
From: Randy Dunlap @ 2010-05-20 21:08 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel, InKi Dae, Richard Purdie
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix device attribute functions return types.
drivers/video/backlight/s6e63m0.c:718: warning: initialization from incompatible pointer type
drivers/video/backlight/s6e63m0.c:718: warning: initialization from incompatible pointer type
drivers/video/backlight/s6e63m0.c:732: warning: initialization from incompatible pointer type
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: InKi Dae <inki.dae@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
---
drivers/video/backlight/s6e63m0.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- mmotm-2010-0519-1612.orig/drivers/video/backlight/s6e63m0.c
+++ mmotm-2010-0519-1612/drivers/video/backlight/s6e63m0.c
@@ -654,7 +654,7 @@ static const struct backlight_ops s6e63m
.update_status = s6e63m0_set_brightness,
};
-static int s6e63m0_sysfs_show_gamma_mode(struct device *dev,
+static ssize_t s6e63m0_sysfs_show_gamma_mode(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct s6e63m0 *lcd = dev_get_drvdata(dev);
@@ -681,7 +681,7 @@ static int s6e63m0_sysfs_show_gamma_mode
return strlen(buf);
}
-static int s6e63m0_sysfs_store_gamma_mode(struct device *dev,
+static ssize_t s6e63m0_sysfs_store_gamma_mode(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
@@ -718,7 +718,7 @@ static int s6e63m0_sysfs_store_gamma_mod
static DEVICE_ATTR(gamma_mode, 0644,
s6e63m0_sysfs_show_gamma_mode, s6e63m0_sysfs_store_gamma_mode);
-static int s6e63m0_sysfs_show_gamma_table(struct device *dev,
+static ssize_t s6e63m0_sysfs_show_gamma_table(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct s6e63m0 *lcd = dev_get_drvdata(dev);
^ permalink raw reply [flat|nested] 12+ messages in thread