Tuesday, February 9, 2010

linux.kernel - 26 new messages in 16 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* x86: slightly unify ret_from_fork - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6a92c712eda199f5?hl=en
* 2.6.33-rc7-git1: Radeon KMS and plymouthd hits kernel BUG - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/c6602d4fcd5f4c26?hl=en
* pagecache tracepoints proposal - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7981b41c86c59df1?hl=en
* linux-next: build failure after merge of the pci tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ee5e668c9da07b8d?hl=en
* s2disk hang update - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/69e5c9798a1fe4e7?hl=en
* i2c-taos-evm bus driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/be50d93c7a49559d?hl=en
* fs: buffer_head, remove kmem_cache constructor to reduce memory usage under
slub - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c8d7821e6166fc08?hl=en
* net: TCP thin linear timeouts - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1c1d9af7a4062cf7?hl=en
* [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7) -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2164e63bc6a3877c?hl=en
* MTD: create lockless versions of {get,put}_mtd_device This will be used to
resolve deadlock in block translation layer. - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/218cbc44b1591b85?hl=en
* Failure to fallback to nfsd-v3 (?) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/88441ff8fd85e18f?hl=en
* linux-next: manual merge of the omap_dss2 tree with the omap tree - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/6301abd44550ec77?hl=en
* Work to enable SmartMedia/xD support in mtd subsystem - 7 messages, 1 author
http://groups.google.com/group/linux.kernel/t/908c78315d608847?hl=en
* tracking memory usage/leak in "inactive" field in /proc/meminfo? - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/59f0d2bf0a30f6a8?hl=en
* PROBLEM: iwlagn kernel 2.6.32.3 ooops - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/495ea89b3e565346?hl=en
* of/gpio: Implement GPIOLIB notifier hooks - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ba7a7613f0e1b508?hl=en

==============================================================================
TOPIC: x86: slightly unify ret_from_fork
http://groups.google.com/group/linux.kernel/t/6a92c712eda199f5?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 8:00 am
From: Ian Campbell


I came across some minor differences between the 32 and 64 bit
implementations of ret_from_fork. Although I don't expect this is code
which can realistically be completely unified there seemed to be some
value in making the two look a bit more similar.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: x86@kernel.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: 2.6.33-rc7-git1: Radeon KMS and plymouthd hits kernel BUG
http://groups.google.com/group/linux.kernel/t/c6602d4fcd5f4c26?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 8:30 am
From: Thomas Backlund


(please cc me on replies)

Hi, Is this known ?

Kernel: 2.6.33-rc7-git1
Arch: x86_64
Distro: Mandriva Cooker

RADEON_KMS is enabled.

Plymouth is version 0.7.2

I hit the bug below:


> < ... >
>
> [ 0.000000] Command line: BOOT_IMAGE=Cooker-tmb root=/dev/sda2 resume=/dev/sda1 splash=silent vga=791
>
> < ... >
>
> [ 18.703916] [drm] Initialized drm 1.1.0 20060810
> [ 18.968389] [drm] radeon defaulting to kernel modesetting.
> [ 18.968392] [drm] radeon kernel modesetting enabled.
> [ 18.968468] radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [ 18.968475] radeon 0000:01:00.0: setting latency timer to 64
> [ 18.970523] [drm] radeon: Initializing kernel modesetting.
> [ 18.971122] [drm] register mmio base: 0xCFEF0000
> [ 18.971124] [drm] register mmio size: 65536
> [ 18.971208] ATOM BIOS: MXM
> [ 18.971223] [drm] Clocks initialized !
> [ 18.971245] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
> [ 18.971248] [drm] Detected VRAM RAM=256M, BAR=256M
> [ 18.971249] [drm] RAM width 128bits DDR
> [ 18.971291] [TTM] Zone kernel: Available graphics memory: 2028530 kiB.
> [ 18.971306] [drm] radeon: 256M of VRAM memory ready
> [ 18.971308] [drm] radeon: 512M of GTT memory ready.
> [ 18.971365] radeon 0000:01:00.0: irq 29 for MSI/MSI-X
> [ 18.971372] [drm] radeon: using MSI.
> [ 18.971407] [drm] radeon: irq initialized.
> [ 18.971409] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [ 18.972290] [drm] Loading RV630 Microcode
> [ 18.972295] platform radeon_cp.0: firmware: requesting radeon/RV630_pfp.bin
> [ 18.973590] platform radeon_cp.0: firmware: requesting radeon/RV630_me.bin
> [ 18.974702] platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
> [ 19.044477] [drm] ring test succeeded in 1 usecs
> [ 19.044562] [drm] radeon: ib pool ready.
> [ 19.044633] [drm] ib test succeeded in 0 usecs
> [ 19.044635] [drm] Enabling audio support
> [ 19.044709] [drm] Default TV standard: NTSC
> [ 19.044786] [drm] Radeon Display Connectors
> [ 19.044788] [drm] Connector 0:
> [ 19.044789] [drm] LVDS
> [ 19.044791] [drm] DDC: 0xac0 0xac0 0xac4 0xac4 0xac8 0xac8 0xacc 0xacc
> [ 19.044792] [drm] Encoders:
> [ 19.044793] [drm] LCD1: INTERNAL_LVTM1
> [ 19.044794] [drm] Connector 1:
> [ 19.044795] [drm] DIN
> [ 19.044796] [drm] Encoders:
> [ 19.044797] [drm] TV1: INTERNAL_KLDSCP_DAC2
> [ 19.044799] [drm] Connector 2:
> [ 19.044799] [drm] VGA
> [ 19.044801] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [ 19.044803] [drm] Encoders:
> [ 19.044804] [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [ 19.044805] [drm] Connector 3:
> [ 19.044806] [drm] DVI-I
> [ 19.044807] [drm] HPD1
> [ 19.044808] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [ 19.044810] [drm] Encoders:
> [ 19.044811] [drm] DFP1: INTERNAL_KLDSCP_TMDS1
> [ 19.614327] [drm] fb mappable at 0xD0141000
> [ 19.614329] [drm] vram apper at 0xD0000000
> [ 19.614330] [drm] size 4096000
> [ 19.614332] [drm] fb depth is 24
> [ 19.614333] [drm] pitch is 5120
> [ 19.614337] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
> [ 19.614353] Console: switching to colour dummy device 80x25
> [ 19.614598] Console: switching to colour frame buffer device 160x50
> [ 20.069974] fb0: radeondrmfb frame buffer device
> [ 20.069976] registered panic notifier
> [ 20.069984] [drm] Initialized radeon 2.0.0 20080528 for 0000:01:00.0 on minor 0
>
> < ... >
>
> [ 24.214473] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> [ 24.215135] BUG: unable to handle kernel paging request at ffff88013f8bb3c0
> [ 24.215137] IP: [<ffff88013f8bb3c0>] 0xffff88013f8bb3c0
> [ 24.215143] PGD 14a7063 PUD 19067 PMD 800000013f8001e3
> [ 24.215146] Oops: 0011 [#1] PREEMPT SMP
> [ 24.215148] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/size
> [ 24.215150] CPU 1
> [ 24.215153] Pid: 35, comm: plymouthd Not tainted 2.6.33-tmb-desktop-0.rc7.1.2mdv #1 Columbia /TravelMate 5720
> [ 24.215155] RIP: 0010:[<ffff88013f8bb3c0>] [<ffff88013f8bb3c0>] 0xffff88013f8bb3c0
> [ 24.215158] RSP: 0018:ffff88013e7f9eb0 EFLAGS: 00010286
> [ 24.215160] RAX: ffff88013f8bb3c0 RBX: ffff88013f8bb000 RCX: 0000000000000003
> [ 24.215161] RDX: ffff88013f8bb3b0 RSI: 0000000000000001 RDI: ffff88013f8bb000
> [ 24.215163] RBP: ffff88013e7f9ec8 R08: 0000000000000000 R09: 0000000000000000
> [ 24.215164] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88013f8bb008
> [ 24.215166] R13: ffff88013f422b40 R14: ffff88013f8b2e38 R15: ffff88013e70a400
> [ 24.215168] FS: 00007f7575149700(0000) GS:ffff880028300000(0000) knlGS:0000000000000000
> [ 24.215170] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 24.215171] CR2: ffff88013f8bb3c0 CR3: 000000013e7bc000 CR4: 00000000000006e0
> [ 24.215173] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 24.215174] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 24.215176] Process plymouthd (pid: 35, threadinfo ffff88013e7f8000, task ffff88013e7c12f0)
> [ 24.215178] Stack:
> [ 24.215178] ffffffff811aa56e ffff88013e7b6900 0000000000000008 ffff88013e7f9f08
> [ 24.215181] <0> ffffffff810d025a 00007f7574fc8000 ffff88013e7b6900 ffff88013e7cc840
> [ 24.215183] <0> 0000000000000000 ffff88013e7cc8c0 00000000006f3c40 ffff88013e7f9f18
> [ 24.215186] Call Trace:
> [ 24.215192] [<ffffffff811aa56e>] ? fb_release+0x3e/0x70
> [ 24.215197] [<ffffffff810d025a>] __fput+0xda/0x1f0
> [ 24.215205] [<ffffffff810d038d>] fput+0x1d/0x30
> [ 24.215207] [<ffffffff810ccb28>] filp_close+0x58/0x90
> [ 24.215214] [<ffffffff810ccc1c>] sys_close+0xbc/0x110
> [ 24.215218] [<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b
> [ 24.215220] Code: 88 ff ff 90 b3 8b 3f 01 88 ff ff a0 b3 8b 3f 01 88 ff ff a0 b3 8b 3f 01 88 ff ff b0 b3 8b 3f 01 88 ff ff b0 b3 8b 3f 01 88 ff ff <c0> b3 8b 3f 01 88 ff ff c0 b3 8b 3f 01 88 ff ff d0 b3 8b 3f 01
> [ 24.215234] RIP [<ffff88013f8bb3c0>] 0xffff88013f8bb3c0
> [ 24.215237] RSP <ffff88013e7f9eb0>
> [ 24.215238] CR2: ffff88013f8bb3c0
> [ 24.215239] ---[ end trace 5b06034eebbc9527 ]---

--
Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: pagecache tracepoints proposal
http://groups.google.com/group/linux.kernel/t/7981b41c86c59df1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 8:30 am
From: Wu Fengguang


> Here is a scratch patch to exercise the "object collections" idea :)
>
> Interestingly, the pagecache walk is pretty fast, while copying out the trace
> data takes more time:
>
> # time (echo / > walk-fs)
> (; echo / > walk-fs; ) 0.01s user 0.11s system 82% cpu 0.145 total
>
> # time wc /debug/tracing/trace
> 4570 45893 551282 /debug/tracing/trace
> wc /debug/tracing/trace 0.75s user 0.55s system 88% cpu 1.470 total

Ah got it: it takes much time to "print" the raw trace data.

> TODO:
>
> correctness
> - show file path name
> XXX: can trace_seq_path() be called directly inside TRACE_EVENT()?

OK, finished with the file name with d_path(). I choose not to mangle
the possible '\n' in file names, and simply show "?" for such files,
for the sake of speed.

Thanks,
Fengguang
---
tracing: pagecache object collections

This dumps
- all cached files of a mounted fs (the inode-cache)
- all cached pages of a cached file (the page-cache)

Usage and Sample output:

# echo /dev > /debug/tracing/objects/mm/pages/walk-fs
# tail /debug/tracing/trace
zsh-2528 [000] 10429.172470: dump_inode: ino=889 size=0 cached=0 age=442 dirty=0 dev=0:18 file=/dev/console
zsh-2528 [000] 10429.172472: dump_inode: ino=888 size=0 cached=0 age=442 dirty=7 dev=0:18 file=/dev/null
zsh-2528 [000] 10429.172474: dump_inode: ino=887 size=40 cached=0 age=442 dirty=0 dev=0:18 file=/dev/shm
zsh-2528 [000] 10429.172477: dump_inode: ino=886 size=40 cached=0 age=442 dirty=0 dev=0:18 file=/dev/pts
zsh-2528 [000] 10429.172479: dump_inode: ino=885 size=11 cached=0 age=442 dirty=0 dev=0:18 file=/dev/core
zsh-2528 [000] 10429.172481: dump_inode: ino=884 size=15 cached=0 age=442 dirty=0 dev=0:18 file=/dev/stderr
zsh-2528 [000] 10429.172483: dump_inode: ino=883 size=15 cached=0 age=442 dirty=0 dev=0:18 file=/dev/stdout
zsh-2528 [000] 10429.172486: dump_inode: ino=882 size=15 cached=0 age=442 dirty=0 dev=0:18 file=/dev/stdin
zsh-2528 [000] 10429.172488: dump_inode: ino=881 size=13 cached=0 age=442 dirty=0 dev=0:18 file=/dev/fd
zsh-2528 [000] 10429.172491: dump_inode: ino=872 size=13360 cached=0 age=442 dirty=0 dev=0:18 file=/dev

Here "age" is either age from inode create time, or from last dirty time.

TODO:

correctness
- reliably prevent ring buffer overflow,
by replacing cond_resched() with some wait function
(eg. wait until 2+ pages are free in ring buffer)
- use stable_page_flags() in recent kernel

output style
- use plain tracing output format (no fancy TASK-PID/.../FUNCTION fields)
- clear ring buffer before dumping the objects?
- output format: key=value pairs ==> header + tabbed values?
- add filtering options if necessary

CC: Ingo Molnar <mingo@elte.hu>
CC: Chris Frost <frost@cs.ucla.edu>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
fs/inode.c | 2
include/trace/events/mm.h | 70 ++++++++++++
kernel/trace/trace_mm.c | 204 ++++++++++++++++++++++++++++++++++++
3 files changed, 275 insertions(+), 1 deletion(-)

--- linux-mm.orig/include/trace/events/mm.h 2010-02-08 23:19:09.000000000 +0800
+++ linux-mm/include/trace/events/mm.h 2010-02-09 23:39:03.000000000 +0800
@@ -2,6 +2,7 @@
#define _TRACE_MM_H

#include <linux/tracepoint.h>
+#include <linux/pagemap.h>
#include <linux/mm.h>

#undef TRACE_SYSTEM
@@ -42,6 +43,75 @@ TRACE_EVENT(dump_pages,
__entry->mapcount, __entry->index)
);

+TRACE_EVENT(dump_pagecache_range,
+
+ TP_PROTO(struct page *page, unsigned long len),
+
+ TP_ARGS(page, len),
+
+ TP_STRUCT__entry(
+ __field( unsigned long, index )
+ __field( unsigned long, len )
+ __field( unsigned long, flags )
+ __field( unsigned int, count )
+ __field( unsigned int, mapcount )
+ ),
+
+ TP_fast_assign(
+ __entry->index = page->index;
+ __entry->len = len;
+ __entry->flags = page->flags;
+ __entry->count = atomic_read(&page->_count);
+ __entry->mapcount = page_mapcount(page);
+ ),
+
+ TP_printk("index=%lu len=%lu flags=%lx count=%u mapcount=%u",
+ __entry->index,
+ __entry->len,
+ __entry->flags,
+ __entry->count,
+ __entry->mapcount)
+);
+
+TRACE_EVENT(dump_inode,
+
+ TP_PROTO(struct inode *inode, char *name, int len),
+
+ TP_ARGS(inode, name, len),
+
+ TP_STRUCT__entry(
+ __field( unsigned long, ino )
+ __field( loff_t, size )
+ __field( unsigned long, nrpages )
+ __field( unsigned long, age )
+ __field( unsigned long, state )
+ __field( dev_t, dev )
+ __dynamic_array(char, file, len )
+ ),
+
+ TP_fast_assign(
+ __entry->ino = inode->i_ino;
+ __entry->size = i_size_read(inode);
+ __entry->nrpages = inode->i_mapping->nrpages;
+ __entry->age = jiffies - inode->dirtied_when;
+ __entry->state = inode->i_state;
+ __entry->dev = inode->i_sb->s_dev;
+ memcpy(__get_str(file), name, len);
+ ),
+
+ TP_printk("ino=%lu size=%llu cached=%lu age=%lu dirty=%lu "
+ "dev=%u:%u file=%s",
+ __entry->ino,
+ __entry->size,
+ __entry->nrpages << PAGE_CACHE_SHIFT,
+ __entry->age / HZ,
+ __entry->state & I_DIRTY,
+ MAJOR(__entry->dev),
+ MINOR(__entry->dev),
+ strchr(__get_str(file), '\n') ? "?" : __get_str(file))
+);
+
+

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate