twitter: linux.kernel - 26 new messages in 14 topics

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

Today's topics:

* 2.6.31.6: (tg3) swapper: page allocation failure. order:0, mode:0x20 - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/4ed6e91d0919943d?hl=en
* git pull on linux-next makes my system crawl to its knees and beg for mercy -
3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/109495e0b678b319?hl=en
* double unlock in rng_dev_read() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6a5302060430fc45?hl=en
* DMA cache consistency bug introduced in 2.6.28 (Was: Re: Cannot format
floppies under kernel 2.6.*?) - 7 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/7ab0ecc4119ae78c?hl=en
* scheduler fix - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fc9097f7840d0f9a?hl=en
* NULL pointer in usb_serial_probe() introduced by the recent kfifo changes -
3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/416fe3d3ef6ee79e?hl=en
* [patch] DT3155: Use pci_get_device - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/585bf12915aea417?hl=en
* via_rhine kernel crashes in 2.6.32 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/4d8e8d13d27c7077?hl=en
* mac80211 suspend corner case (was: Asus eeepc 1008HA suspend issue and mac
80211 suspend corner) case - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/033504ee0cb101d3?hl=en
* NFS lockdep lock misordering mmap_sem<->i_mutex_key with 2.6.32-git1 - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/865640cc1d5b2326?hl=en
* Staging tree status for the .33 kernel merge - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/818bdf5c79b5bf8d?hl=en
* AlacrityVM guest drivers for 2.6.33 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/265f7bf4a9a1d92d?hl=en
* All kernels after 2.6.32-git10 show only 1 CPU - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/de8e3e045599a528?hl=en
* Christmas Offer!!! - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/41f1e90a5576cfac?hl=en

==============================================================================
TOPIC: 2.6.31.6: (tg3) swapper: page allocation failure. order:0, mode:0x20
http://groups.google.com/group/linux.kernel/t/4ed6e91d0919943d?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 7:20 am
From: Justin Piszcz

Hi,

Running 2.6.31.6 (never saw this issue with earlier kernels < 2.6.31):

Just upgraded to 2.6.32.2, not sure if this has been fixed yet, but FYI,
previously I had run ~2.6.26 for > 400 days without this occurring, as far
as I can remember.

Is this a regression from 2.6.26?

[2407510.480755] udev: starting version 149
[2759231.946818] swapper: page allocation failure. order:0, mode:0x20
[2759231.946825] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.946828] Call Trace:
[2759231.946840] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.946847] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.946851] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.946858] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.946861] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.946867] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.946872] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.946876] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.946882] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.946888] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.946891] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.946896] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.946900] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.946903] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.946908] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.946911] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.946916] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.946919] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.946922] Mem-Info:
[2759231.946924] DMA per-cpu:
[2759231.946926] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.946928] Normal per-cpu:
[2759231.946930] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.946932] HighMem per-cpu:
[2759231.946934] CPU 0: hi: 42, btch: 7 usd: 9
[2759231.946939] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.946940] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.946942] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.946947] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.946951] lowmem_reserve[]: 0 865 992 992
[2759231.946957] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.946961] lowmem_reserve[]: 0 0 1015 1015
[2759231.946968] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.946971] lowmem_reserve[]: 0 0 0 0
[2759231.946975] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.946985] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.946995] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.947005] 34860 total pagecache pages
[2759231.947007] 1338 pages in swap cache
[2759231.947010] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.947012] Free swap = 1691248kB
[2759231.947014] Total swap = 2192832kB
[2759231.947808] 260080 pages RAM
[2759231.947808] 32754 pages HighMem
[2759231.947808] 3509 pages reserved
[2759231.947808] 96118 pages shared
[2759231.947808] 220033 pages non-shared
[2759231.956819] swapper: page allocation failure. order:0, mode:0x20
[2759231.956824] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.956827] Call Trace:
[2759231.956838] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.956844] [<c102e576>] ? ktime_get_ts+0x21/0x44
[2759231.956851] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.956855] [<c102f889>] ? sched_clock_tick+0x3c/0x111
[2759231.956859] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.956865] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.956868] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.956874] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.956879] [<c1004bdc>] ? timer_interrupt+0x24/0x38
[2759231.956883] [<c103adb2>] ? handle_IRQ_event+0x2d/0xbb
[2759231.956887] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.956892] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.956898] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.956901] [<c103adcf>] ? handle_IRQ_event+0x4a/0xbb
[2759231.956904] [<c102ed94>] ? notify_die+0x30/0x34
[2759231.956908] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.956912] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.956915] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.956918] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.956922] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.956926] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.956929] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.956934] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.956937] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.956939] Mem-Info:
[2759231.956941] DMA per-cpu:
[2759231.956943] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.956945] Normal per-cpu:
[2759231.956947] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.956949] HighMem per-cpu:
[2759231.956951] CPU 0: hi: 42, btch: 7 usd: 3
[2759231.956955] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.956957] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.956958] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.956963] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.956967] lowmem_reserve[]: 0 865 992 992
[2759231.956973] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.956977] lowmem_reserve[]: 0 0 1015 1015
[2759231.956983] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.956987] lowmem_reserve[]: 0 0 0 0
[2759231.956990] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.957000] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.957010] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.957019] 34866 total pagecache pages
[2759231.957022] 1338 pages in swap cache
[2759231.957024] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.957027] Free swap = 1691248kB
[2759231.957028] Total swap = 2192832kB
[2759231.957812] 260080 pages RAM
[2759231.957812] 32754 pages HighMem
[2759231.957812] 3509 pages reserved
[2759231.957812] 96125 pages shared
[2759231.957812] 220033 pages non-shared
[2759231.962356] swapper: page allocation failure. order:0, mode:0x20
[2759231.962361] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.962364] Call Trace:
[2759231.962375] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.962380] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.962386] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.962390] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.962396] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.962400] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.962405] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.962409] [<c1004bdc>] ? timer_interrupt+0x24/0x38
[2759231.962413] [<c103adb2>] ? handle_IRQ_event+0x2d/0xbb
[2759231.962417] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.962423] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.962428] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.962431] [<c103adcf>] ? handle_IRQ_event+0x4a/0xbb
[2759231.962435] [<c102ed94>] ? notify_die+0x30/0x34
[2759231.962440] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.962443] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.962447] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.962450] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.962453] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.962458] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.962461] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.962465] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.962469] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.962471] Mem-Info:
[2759231.962473] DMA per-cpu:
[2759231.962475] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.962477] Normal per-cpu:
[2759231.962479] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.962481] HighMem per-cpu:
[2759231.962483] CPU 0: hi: 42, btch: 7 usd: 3
[2759231.962487] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.962489] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.962490] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.962495] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.962499] lowmem_reserve[]: 0 865 992 992
[2759231.962506] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.962509] lowmem_reserve[]: 0 0 1015 1015
[2759231.962515] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.962519] lowmem_reserve[]: 0 0 0 0
[2759231.962523] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.962533] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.962542] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.962552] 34866 total pagecache pages
[2759231.962554] 1338 pages in swap cache
[2759231.962557] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.962559] Free swap = 1691248kB
[2759231.962561] Total swap = 2192832kB
[2759231.963335] 260080 pages RAM
[2759231.963335] 32754 pages HighMem
[2759231.963335] 3509 pages reserved
[2759231.963335] 96125 pages shared
[2759231.963335] 220033 pages non-shared
[2759231.967760] swapper: page allocation failure. order:0, mode:0x20
[2759231.967765] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.967767] Call Trace:
[2759231.967777] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.967783] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.967789] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.967793] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.967800] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.967803] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.967811] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.967815] [<c1004bdc>] ? timer_interrupt+0x24/0x38
[2759231.967819] [<c103adb2>] ? handle_IRQ_event+0x2d/0xbb
[2759231.967823] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.967828] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.967834] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.967837] [<c103adcf>] ? handle_IRQ_event+0x4a/0xbb
[2759231.967841] [<c102ed94>] ? notify_die+0x30/0x34
[2759231.967846] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.967849] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.967853] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.967856] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.967859] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.967864] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.967867] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.967871] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.967875] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.967877] Mem-Info:
[2759231.967879] DMA per-cpu:
[2759231.967881] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.967883] Normal per-cpu:
[2759231.967885] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.967887] HighMem per-cpu:
[2759231.967889] CPU 0: hi: 42, btch: 7 usd: 3
[2759231.967894] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.967896] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.967897] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.967902] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.967906] lowmem_reserve[]: 0 865 992 992
[2759231.967913] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.967917] lowmem_reserve[]: 0 0 1015 1015
[2759231.967923] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.967927] lowmem_reserve[]: 0 0 0 0
[2759231.967930] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.967940] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.967950] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.967960] 34866 total pagecache pages
[2759231.967962] 1338 pages in swap cache
[2759231.967965] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.967967] Free swap = 1691248kB
[2759231.967969] Total swap = 2192832kB
[2759231.968751] 260080 pages RAM
[2759231.968751] 32754 pages HighMem
[2759231.968751] 3509 pages reserved
[2759231.968751] 96125 pages shared
[2759231.968751] 220033 pages non-shared
[2759231.973170] swapper: page allocation failure. order:0, mode:0x20
[2759231.973175] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.973177] Call Trace:
[2759231.973188] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.973193] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.973199] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.973203] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.973210] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.973213] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.973219] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.973223] [<c1004bdc>] ? timer_interrupt+0x24/0x38
[2759231.973227] [<c103adb2>] ? handle_IRQ_event+0x2d/0xbb
[2759231.973231] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.973237] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.973242] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.973245] [<c103adcf>] ? handle_IRQ_event+0x4a/0xbb
[2759231.973250] [<c102ed94>] ? notify_die+0x30/0x34
[2759231.973254] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.973258] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.973262] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.973265] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.973268] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.973273] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.973276] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.973281] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.973284] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.973286] Mem-Info:
[2759231.973288] DMA per-cpu:
[2759231.973291] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.973293] Normal per-cpu:
[2759231.973295] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.973296] HighMem per-cpu:
[2759231.973299] CPU 0: hi: 42, btch: 7 usd: 3
[2759231.973303] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.973305] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.973306] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.973312] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.973315] lowmem_reserve[]: 0 865 992 992
[2759231.973322] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.973326] lowmem_reserve[]: 0 0 1015 1015
[2759231.973332] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.973336] lowmem_reserve[]: 0 0 0 0
[2759231.973340] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.973350] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.973359] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.973369] 34866 total pagecache pages
[2759231.973371] 1338 pages in swap cache
[2759231.973374] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.973376] Free swap = 1691248kB
[2759231.973378] Total swap = 2192832kB
[2759231.974161] 260080 pages RAM
[2759231.974161] 32754 pages HighMem
[2759231.974161] 3509 pages reserved
[2759231.974161] 96125 pages shared
[2759231.974161] 220033 pages non-shared
[2759231.978629] swapper: page allocation failure. order:0, mode:0x20
[2759231.978635] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.978637] Call Trace:
[2759231.978648] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.978655] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.978661] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.978665] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.978671] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.978674] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.978680] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.978684] [<c1004bdc>] ? timer_interrupt+0x24/0x38
[2759231.978688] [<c103adb2>] ? handle_IRQ_event+0x2d/0xbb
[2759231.978692] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.978697] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.978702] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.978706] [<c103adcf>] ? handle_IRQ_event+0x4a/0xbb
[2759231.978710] [<c102ed94>] ? notify_die+0x30/0x34
[2759231.978714] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.978717] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.978721] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.978724] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.978727] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.978732] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.978735] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.978739] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.978742] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.978744] Mem-Info:
[2759231.978746] DMA per-cpu:
[2759231.978748] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.978750] Normal per-cpu:
[2759231.978752] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.978754] HighMem per-cpu:
[2759231.978756] CPU 0: hi: 42, btch: 7 usd: 3
[2759231.978760] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.978762] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.978763] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.978768] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.978771] lowmem_reserve[]: 0 865 992 992
[2759231.978778] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.978781] lowmem_reserve[]: 0 0 1015 1015
[2759231.978787] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.978791] lowmem_reserve[]: 0 0 0 0
[2759231.978794] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.978804] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.978816] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.978826] 34866 total pagecache pages
[2759231.978828] 1338 pages in swap cache
[2759231.978831] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.978833] Free swap = 1691248kB
[2759231.978835] Total swap = 2192832kB
[2759231.979622] 260080 pages RAM
[2759231.979622] 32754 pages HighMem
[2759231.979622] 3509 pages reserved
[2759231.979622] 96125 pages shared
[2759231.979622] 220033 pages non-shared
[2759231.984021] swapper: page allocation failure. order:0, mode:0x20
[2759231.984026] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.984029] Call Trace:
[2759231.984039] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.984044] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.984050] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.984054] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.984060] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.984063] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.984069] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.984073] [<c1004bdc>] ? timer_interrupt+0x24/0x38
[2759231.984077] [<c103adb2>] ? handle_IRQ_event+0x2d/0xbb
[2759231.984080] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.984086] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.984091] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.984094] [<c103adcf>] ? handle_IRQ_event+0x4a/0xbb
[2759231.984098] [<c102ed94>] ? notify_die+0x30/0x34
[2759231.984102] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.984106] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.984110] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.984113] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.984116] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.984121] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.984124] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.984128] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.984131] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.984133] Mem-Info:
[2759231.984135] DMA per-cpu:
[2759231.984137] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.984139] Normal per-cpu:
[2759231.984141] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.984143] HighMem per-cpu:
[2759231.984145] CPU 0: hi: 42, btch: 7 usd: 3
[2759231.984149] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.984151] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.984152] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.984157] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.984161] lowmem_reserve[]: 0 865 992 992
[2759231.984167] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.984171] lowmem_reserve[]: 0 0 1015 1015
[2759231.984176] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.984180] lowmem_reserve[]: 0 0 0 0
[2759231.984183] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.984193] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.984203] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.984212] 34866 total pagecache pages
[2759231.984214] 1338 pages in swap cache
[2759231.984217] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.984219] Free swap = 1691248kB
[2759231.984220] Total swap = 2192832kB
[2759231.985010] 260080 pages RAM
[2759231.985010] 32754 pages HighMem
[2759231.985010] 3509 pages reserved
[2759231.985010] 96125 pages shared
[2759231.985010] 220033 pages non-shared
[2759231.989433] swapper: page allocation failure. order:0, mode:0x20
[2759231.989438] Pid: 0, comm: swapper Not tainted 2.6.31.6 #3
[2759231.989440] Call Trace:
[2759231.989450] [<c1042d81>] ? __alloc_pages_nodemask+0x448/0x508
[2759231.989456] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.989462] [<c105b5e3>] ? cache_alloc_refill+0x244/0x472
[2759231.989466] [<c105b8ab>] ? __kmalloc+0x9a/0x9e
[2759231.989472] [<c12b037f>] ? __alloc_skb+0x46/0x112
[2759231.989475] [<c12b0f25>] ? __netdev_alloc_skb+0x1c/0x37
[2759231.989481] [<c122bb1f>] ? tg3_alloc_rx_skb+0x7d/0x16d
[2759231.989484] [<c1004bdc>] ? timer_interrupt+0x24/0x38
[2759231.989488] [<c103adb2>] ? handle_IRQ_event+0x2d/0xbb
[2759231.989492] [<c12334ed>] ? tg3_poll+0x7db/0x9cb
[2759231.989497] [<c12b600c>] ? net_rx_action+0x6c/0xe0
[2759231.989503] [<c1020ba1>] ? __do_softirq+0x68/0xe1
[2759231.989506] [<c103adcf>] ? handle_IRQ_event+0x4a/0xbb
[2759231.989510] [<c102ed94>] ? notify_die+0x30/0x34
[2759231.989514] [<c101158e>] ? ack_apic_level+0x3c/0x13c
[2759231.989517] [<c1020c40>] ? do_softirq+0x26/0x28
[2759231.989521] [<c10042b1>] ? do_IRQ+0x37/0x8c
[2759231.989524] [<c1003f04>] ? do_nmi+0x140/0x299
[2759231.989527] [<c1003029>] ? common_interrupt+0x29/0x30
[2759231.989532] [<c1007ffa>] ? default_idle+0x36/0x42
[2759231.989535] [<c1001c61>] ? cpu_idle+0x24/0x43
[2759231.989539] [<c1449685>] ? start_kernel+0x219/0x252
[2759231.989542] [<c1449242>] ? unknown_bootoption+0x0/0x1dc
[2759231.989544] Mem-Info:
[2759231.989546] DMA per-cpu:
[2759231.989548] CPU 0: hi: 0, btch: 1 usd: 0
[2759231.989550] Normal per-cpu:
[2759231.989552] CPU 0: hi: 186, btch: 31 usd: 191
[2759231.989554] HighMem per-cpu:
[2759231.989556] CPU 0: hi: 42, btch: 7 usd: 3
[2759231.989561] Active_anon:104889 active_file:12798 inactive_anon:105060
[2759231.989562] inactive_file:14667 unevictable:0 dirty:5061 writeback:5028 unstable:0
[2759231.989564] free:1280 slab:11596 mapped:5235 pagetables:2542 bounce:0
[2759231.989569] DMA free:3484kB min:64kB low:80kB high:96kB active_anon:3852kB inactive_anon:4216kB active_file:1768kB inactive_file:2056kB unevictable:0kB present:15868kB pages_scanned:0 all_unreclaimable? no
[2759231.989572] lowmem_reserve[]: 0 865 992 992
[2759231.989579] Normal free:1384kB min:3728kB low:4660kB high:5592kB active_anon:361100kB inactive_anon:361072kB active_file:40744kB inactive_file:47380kB unevictable:0kB present:885944kB pages_scanned:64 all_unreclaimable? no
[2759231.989582] lowmem_reserve[]: 0 0 1015 1015
[2759231.989588] HighMem free:252kB min:128kB low:264kB high:400kB active_anon:54604kB inactive_anon:54952kB active_file:8680kB inactive_file:9232kB unevictable:0kB present:129992kB pages_scanned:0 all_unreclaimable? no
[2759231.989592] lowmem_reserve[]: 0 0 0 0
[2759231.989596] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3484kB
[2759231.989605] Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1384kB
[2759231.989615] HighMem: 61*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB
[2759231.989624] 34866 total pagecache pages
[2759231.989627] 1338 pages in swap cache
[2759231.989629] Swap cache stats: add 152965, delete 151627, find 13955964/13958438
[2759231.989632] Free swap = 1691248kB
[2759231.989633] Total swap = 2192832kB
[2759231.990424] 260080 pages RAM
[2759231.990424] 32754 pages HighMem
[2759231.990424] 3509 pages reserved
[2759231.990424] 96125 pages shared
[2759231.990424] 220033 pages non-shared

--
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: git pull on linux-next makes my system crawl to its knees and beg for
mercy
http://groups.google.com/group/linux.kernel/t/109495e0b678b319?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Dec 23 2009 7:30 am
From: Denys Vlasenko

On Fri, Dec 18, 2009 at 11:03 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Dec 18, 2009 at 1:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi Luis,
>>
>> On Fri, 18 Dec 2009 09:26:29 -0800 "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>>>
>>> I tend to always be on a 2.6.32 kernel + John's queued up patches for
>>> wireless for the next kernel release (I use wireless-testing). My
>>> system is a Thinkpad T61, userspace is Ubuntu 9.10 based (ships with
>>> git 1.6.3.3) and I kept an ext3 filesystem to be able to go back in
>>> time to 2.6.27 at will without issues. I git clone'd linux-next a few
>>> weeks ago. After a few days I then tried to git pull and my system
>>> became completely unusable, It took *ages* to open up a terminal and
>>
>> The start of the daily linux-next boilerplate says:
>>
>>> If you are tracking the linux-next tree using git, you should not use
>>> "git pull" to do so as that will try to merge the new linux-next release
>>> with the old one. You should use "git fetch" as mentioned in the FAQ on
>>> the wiki (see below).
>>
>> (Unfortunately, the wiki seems to be unavailable at the moment)
>>
>> I am guessing that the merge that git is attempting is killing your
>> laptop (though besides the number of common commits I am not sure why).
>> Please try using "get fetch" instead.
>
> Indeed, I learned my lesson now. Thanks for the details.
>
> Now granted, even if 'git merge' is killing my laptop due to the
> conflicts of the insane merge I was trying to do it *still* should not
> make my box completely unresponsive for so long. And given that I'm
> using mostly distribution specific kernel config options and my have
> ruled out my hard drive it seems a general serious kernel issue even
> down to 2.6.27. Whatever git is doing I'm sure other userspace
> software can also end up generating and would make any user go
> completely bananas. I was about to rip my hair out.

Git gurus would know it by heart, but I am not one. So if I were you,
I would just do a generic diagnostic run. What is it git is doing
so that machine slows down that much? Is it spawning a lot
of running processes? Is it allocating/using so much memory
that your box goes into a severe swap storm?

I guess it is the latter. If it is, then it's not a kernel problem -
kernel can't magically make your system adequately handle a workload
which needs 3 GB for working set when the box only has 2 GB of RAM.
It _will_ be very slow.

--
vda
--
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/

== 2 of 3 ==
Date: Wed, Dec 23 2009 8:30 am
From: "Luis R. Rodriguez"

On Wed, Dec 23, 2009 at 7:27 AM, Denys Vlasenko
<vda.linux@googlemail.com> wrote:
> On Fri, Dec 18, 2009 at 11:03 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Fri, Dec 18, 2009 at 1:56 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> Hi Luis,
>>>
>>> On Fri, 18 Dec 2009 09:26:29 -0800 "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>>>>
>>>> I tend to always be on a 2.6.32 kernel + John's queued up patches for
>>>> wireless for the next kernel release (I use wireless-testing). My
>>>> system is a Thinkpad T61, userspace is Ubuntu 9.10 based (ships with
>>>> git 1.6.3.3) and I kept an ext3 filesystem to be able to go back in
>>>> time to 2.6.27 at will without issues. I git clone'd linux-next a few
>>>> weeks ago. After a few days I then tried to git pull and my system
>>>> became completely unusable, It took *ages* to open up a terminal and
>>>
>>> The start of the daily linux-next boilerplate says:
>>>
>>>> If you are tracking the linux-next tree using git, you should not use
>>>> "git pull" to do so as that will try to merge the new linux-next release
>>>> with the old one. You should use "git fetch" as mentioned in the FAQ on
>>>> the wiki (see below).
>>>
>>> (Unfortunately, the wiki seems to be unavailable at the moment)
>>>
>>> I am guessing that the merge that git is attempting is killing your
>>> laptop (though besides the number of common commits I am not sure why).
>>> Please try using "get fetch" instead.
>>
>> Indeed, I learned my lesson now. Thanks for the details.
>>
>> Now granted, even if 'git merge' is killing my laptop due to the
>> conflicts of the insane merge I was trying to do it *still* should not
>> make my box completely unresponsive for so long. And given that I'm
>> using mostly distribution specific kernel config options and my have
>> ruled out my hard drive it seems a general serious kernel issue even
>> down to 2.6.27. Whatever git is doing I'm sure other userspace
>> software can also end up generating and would make any user go
>> completely bananas. I was about to rip my hair out.
>
> Git gurus would know it by heart, but I am not one. So if I were you,
> I would just do a generic diagnostic run.

Right its the first thing I did, but its to the extent that even doing
that is not possible unless you're willing to wait 5-10 minutes for
some output. I'm not kidding.

> What is it git is doing
> so that machine slows down that much? Is it spawning a lot
> of running processes?

Doesn't seem like it, the only visible git process is get-merge, I
forgot to grep for all git processes though, but I think that was the
only one.

> Is it allocating/using so much memory
> that your box goes into a severe swap storm?

Could be, 979M virtual, 298M resident size (non swapped), 58665 shared.

Unfortunately when this happens I cannot log into my box and run good
diagnostics, that's how much of a pain in the bolas this is. Some
morning I had enough patience I did leave vmstat and iostat running
and didn't see much out of the ordinary except CPU wait time was
pretty high. I did manage to get at least htop running once and took a
screenshot (and this took me about 10 minutes to generate):

http://bombadil.infradead.org/~mcgrof/images/2009/12/git-merge.jpg

So if anything it could be the later, that of a swap storm.

What I should have running is sar, that way I can treck back in time
when I want to.

But even when compiling the kernel my machine becomes unusable for a
few seconds when the linking for vmlinux.o starts and in that case my
swap usage is about 45 - 125 M. A silly example, pandora reliably poos
out on firefox requiring a pkill on firefox to get it back while
vmlinux.o is linking.

> I guess it is the latter.

Only it seems to happen with some other things like compiling the kernel.

I'll see if I can upgrade the memory on this thing.

> If it is, then it's not a kernel problem -
> kernel can't magically make your system adequately handle a workload
> which needs 3 GB for working set when the box only has 2 GB of RAM.
> It _will_ be very slow.

Sure, I'll try to keep my eye out on swap overuse, I suppose it could be that.

I started to be suspicious about the CPU freq governor but I'll note
on both systems even if I set the freq static to the highest I still
had issues. I'll also note on both 2.6.27 and 2.6.32 I used:

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y

I started testing CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y

but don't really notice an improvement.

Luis
--
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/

== 3 of 3 ==
Date: Wed, Dec 23 2009 9:20 am
From: Denys Vlasenko

On Wed, Dec 23, 2009 at 5:20 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> Is it allocating/using so much memory
>> that your box goes into a severe swap storm?
>
> Could be, 979M virtual, 298M resident size (non swapped), 58665 shared.
>
> Unfortunately when this happens I cannot log into my box and run good
> diagnostics, that's how much of a pain in the bolas this is.

Nicing it may make it easier to do diagnostic work.

> Some
> morning I had enough patience I did leave vmstat and iostat running
> and didn't see much out of the ordinary except CPU wait time was
> pretty high. I did manage to get at least htop running once and took a
> screenshot (and this took me about 10 minutes to generate):
>
> http://bombadil.infradead.org/~mcgrof/images/2009/12/git-merge.jpg

Looks like swap space is 2/3 used. This is an indication
of memory starvation.

It may be a residual condition - you have a lot of potentially
bloated programs running. What do you see if you reproduce
this situation soon after boot, with minimum of other running programs?
For one, definitely do not start web browser(s) and such.
Ideally, do not run X at all.

If you still see a lot of swap used, then this is it - git
requires more memory for this task. The possibility that
kernel has a bug where it needlessly swaps out is remote.

==============================================================================
TOPIC: double unlock in rng_dev_read()
http://groups.google.com/group/linux.kernel/t/6a5302060430fc45?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 7:30 am
From: Herbert Xu

On Wed, Dec 23, 2009 at 04:53:36PM +0200, Dan Carpenter wrote:
>
> No no. I mean when size hits zero we are rng_mutex is unlocked.

Good catch! I'll add this patch to the tree. Please take a look
at it. Thanks!

commit f5908267b67917b8cbd98b27fd2be9b5f62ec76f
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed Dec 23 23:22:34 2009 +0800

hwrng: core - Fix double unlock in rng_dev_read

When the loop terminates with size == 0 in rng_dev_read we will
unlock the rng mutex twice.

Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index e989f67..3d9c61e 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -158,10 +158,11 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf,
goto out;
}
}
-out_unlock:
- mutex_unlock(&rng_mutex);
out:
return ret ? : err;
+out_unlock:
+ mutex_unlock(&rng_mutex);
+ goto out;
}

--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: DMA cache consistency bug introduced in 2.6.28 (Was: Re: Cannot format
floppies under kernel 2.6.*?)
http://groups.google.com/group/linux.kernel/t/7ab0ecc4119ae78c?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Dec 23 2009 7:40 am
From: Mark Hounschell

On 12/23/2009 10:10 AM, Pallipadi, Venkatesh wrote:
>
>
>> -----Original Message-----
>> From: Mark Hounschell [mailto:markh@compro.net]
>> Sent: Wednesday, December 23, 2009 5:03 AM
>> To: Pallipadi, Venkatesh
>> Cc: dmarkh@cfl.rr.com; Linus Torvalds; Alain Knaff; Linux
>> Kernel Mailing List; fdutils@fdutils.linux.lu; Li, Shaohua; Ingo Molnar
>> Subject: Re: [Fdutils] DMA cache consistency bug introduced in
>> 2.6.28 (Was: Re: Cannot format floppies under kernel 2.6.*?)
>>
>> On 12/22/2009 07:22 PM, Mark Hounschell wrote:
>>> On 12/22/2009 06:37 PM, Pallipadi, Venkatesh wrote:
>>>> On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
>>>>> On 12/22/2009 12:38 PM, Linus Torvalds wrote:
>>>>>>
>>>>>> [ Ingo, Venki and Shaohua added to cc: see the whole
>> thread on lkml for
>>>>>> details, but Mark is basically chasing down a situation
>> where the floppy
>>>>>> driver seems to have trouble formatting floppies, and
>> it happened
>>>>>> between 2.6.27 and .28. The trouble seems to be that a
>> DMA transfer of a
>>>>>> memory block transfers the wrong value for the first
>> byte of the block.
>>>>>>
>>>>>> Which should be impossible, but whatever. Some part of
>> the system has a
>>>>>> cached buffer that isn't flushed.
>>>>>>
>>>>>> What gets _you_ guys involved is that Mark cannot
>> reproduce the bug if
>>>>>> HPET is disabled in the BIOS or by using 'nohpet'. He
>> found that out by
>>>>>> pure luck while bisecting, because some time during his
>> bisect, his
>>>>>> machine wouldn't even boot with HPET.
>>>>>>
>>>>>> So the problem is: with HPET enabled, 2.6.27.4 _used_
>> to work. But
>>>>>> 2.6.28 (and current -git) does not. Any ideas? ]
>>>>>>
>>>>>> On Tue, 22 Dec 2009, Mark Hounschell wrote:
>>>>>>>
>>>>>>> Ok, I may have something that might help.
>>>>>>>
>>>>>>> # git bisect bad
>>>>>>> 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit
>>>>>>> commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0
>>>>>>> Author: venkatesh.pallipadi@intel.com
>> <venkatesh.pallipadi@intel.com>
>>>>>>> Date: Fri Sep 5 18:02:18 2008 -0700
>>>>>>>
>>>>>>> x86: HPET_MSI Initialise per-cpu HPET timers
>>>>>>>
>>>>>>> Initialize a per CPU HPET MSI timer when possible.
>> We retain the HPET
>>>>>>> timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when
>> legacy mode is being used. We
>>>>>>> setup the remaining HPET timers as per CPU MSI based
>> timers. This per CPU
>>>>>>> timer will eliminate the need for timer broadcasting
>> with IRQ 0 when there
>>>>>>> is non-functional LAPIC timer across CPU deep C-states.
>>>>>>>
>>>>>>> If there are more CPUs than number of available
>> timers, CPUs that do not
>>>>>>> find any timer to use will continue using LAPIC and
>> IRQ 0 broadcast.
>>>>>>>
>>>>>>> Signed-off-by: Venkatesh Pallipadi
>> <venkatesh.pallipadi@intel.com>
>>>>>>> Signed-off-by: Shaohua Li <shaohua.li@intel.com>
>>>>>>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>>>>>>
>>>>>>> And of coarse this was the first commit that I could not
>> boot if I had hpet
>>>>>>> enabled. To get this one to boot (single user mode only)
>> I had to add the
>>>>>>> the quiet cmdline option and following patch from to
>> arch/x86/kernel/hpet.c
>>>>>>>
>>>>>>> commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
>>>>>>>
>>>>>>> @ -445,7 +445,7 @@ static int hpet_setup_irq(struct
>> hpet_dev *dev)
>>>>>>> {
>>>>>>>
>>>>>>> if (request_irq(dev->irq, hpet_interrupt_handler,
>>>>>>> - IRQF_SHARED|IRQF_NOBALANCING,
>> dev->name, dev))
>>>>>>> + IRQF_DISABLED|IRQF_NOBALANCING,
>> dev->name, dev))
>>>>>>> return -1;
>>>>>>>
>>>>>>> disable_irq(dev->irq);
>>>>>>>
>>>>>>> AND add the quiet cmdline option.
>>>>>>
>>>>>> Ok, so we know why HPET didn't boot for you, and that was
>> fixed later (by
>>>>>> that 5ceb1a04). But is this also when the floppy started
>> mis-behaving?
>>>>>>
>>>>>
>>>>> Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when
>> the floppy stops
>>>>> working
>>>>> and also when I could no longer boot with hpet enabled.
>>>>
>>>>
>>>> I am missing something here. Commit 26afe5f2 is where
>> system does not
>>>> boot with HPET or is it where the floppy stops working when you boot
>>>> with HPET enabled.
>>>>
>>>
>>> As it happens, both happen there. Commit 5ceb1a04 is where it starts
>>> booting _again_ with hpet enabled. So I took that patch
>> (5ceb1a04) and
>>> applied it to (26afe5f2f) to be able to boot with hpet
>> enabled. I had to
>>> use the quiet option to get to a login prompt, but there is where the
>>> floppy format first fails, just as it does in 2.6.28 and up.
>>>
>>>> Can you try "idle=halt" with both .27 and .28 with /proc/interrupts
>>>> output in each case. With that option, we should be using local APIC
>>>> timer and PIT, HPET or HPET with MSI should not really
>> matter. Does it
>>>> still fail with .28 with that option?
>>>>
>>
>> 2.6.28 still fails with that option.
>>
>> 2.6.27.41 /proc/interrupts with idle=halt
>>
>> CPU0 CPU1 CPU2 CPU3
>> 0: 126 0 0 1
>> IO-APIC-edge timer
>> 1: 0 0 1 157
>> IO-APIC-edge i8042
>> 3: 0 0 0 6 IO-APIC-edge
>> 4: 0 0 0 6 IO-APIC-edge
>> 6: 0 0 0 4
>> IO-APIC-edge floppy
>> 8: 0 0 0 1
>> IO-APIC-edge rtc0
>> 9: 0 0 0 0
>> IO-APIC-fasteoi acpi
>> 12: 0 0 1 128
>> IO-APIC-edge i8042
>> 14: 0 0 34 4457 IO-APIC-edge
>> pata_atiixp
>> 15: 0 0 4 480 IO-APIC-edge
>> pata_atiixp
>> 16: 0 0 0 397 IO-APIC-fasteoi
>> aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel
>> 17: 0 0 0 2 IO-APIC-fasteoi
>> ehci_hcd:usb1
>> 18: 0 0 0 0 IO-APIC-fasteoi
>> ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
>> 19: 0 0 0 142 IO-APIC-fasteoi
>> aic7xxx, ehci_hcd:usb2, ttySLG0, eth1
>> 22: 0 0 4 1154
>> IO-APIC-fasteoi ahci
>> 219: 0 0 3 63
>> PCI-MSI-edge eth0
>> NMI: 0 0 0 0
>> Non-maskable interrupts
>> LOC: 91539 91964 92525 91181 Local timer
>> interrupts
>> RES: 2888 3873 2434 2721
>> Rescheduling interrupts
>> CAL: 240 245 247 84 function
>> call interrupts
>> TLB: 768 628 526 512 TLB shootdowns
>> SPU: 0 0 0 0 Spurious interrupts
>> ERR: 0
>> MIS: 0
>>
>> 2.6.28 /proc/interrupts with idle=halt
>>
>> CPU0 CPU1 CPU2 CPU3
>> 0: 126 0 2 0
>> IO-APIC-edge timer
>> 1: 0 0 192 0
>> IO-APIC-edge i8042
>> 3: 0 0 6 0 IO-APIC-edge
>> 4: 0 0 6 0 IO-APIC-edge
>> 6: 0 0 4 0
>> IO-APIC-edge floppy
>> 8: 0 0 1 0
>> IO-APIC-edge rtc0
>> 9: 0 0 0 0
>> IO-APIC-fasteoi acpi
>> 12: 0 0 128 1
>> IO-APIC-edge i8042
>> 14: 0 1 147114 396 IO-APIC-edge
>> pata_atiixp
>> 15: 0 0 646 2 IO-APIC-edge
>> pata_atiixp
>> 16: 0 0 396 0 IO-APIC-fasteoi
>> aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel
>> 17: 0 0 0 0 IO-APIC-fasteoi
>> ehci_hcd:usb1
>> 18: 0 0 0 0 IO-APIC-fasteoi
>> ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
>> 19: 0 0 362 1 IO-APIC-fasteoi
>> aic7xxx, ehci_hcd:usb3, ttySLG0, eth1
>> 22: 0 0 874 1
>> IO-APIC-fasteoi ahci
>> 1274: 0 0 193 4
>> PCI-MSI-edge eth0
>> 1279: 513207 0 0 0
>> HPET_MSI-edge hpet2
>> NMI: 0 0 0 0
>> Non-maskable interrupts
>> LOC: 268 513395 513138 522088 Local timer
>> interrupts
>> RES: 3262 3679 2573 3746
>> Rescheduling interrupts
>> CAL: 131 166 57 147 Function
>> call interrupts
>> TLB: 680 438 450 639 TLB shootdowns
>> SPU: 0 0 0 0 Spurious interrupts
>> ERR: 0
>> MIS: 0
>>
>
> Hmm. Looks like hpet2 is still getting used instead of local APIC timer in .28 case.
>
> I was expecting some low number in hpet2 and local timer on all CPU to be around the same value. Above shows CPU 0 is depending on hpet2 for some reason even with idle=halt. Can you send the output of below two in case of .28
> /proc/timer_list

Attached.

> grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*

I have no /sys/devices/system/cpu/cpu0/cpuidle on this machine.
Maybe because of

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

Would it be OK if when you ask for 2.6.28 info, I use a 2.6.32.2 kernel?
That kernel also fails fdformat with hpet enabled on these machines.

Thanks
Mark

== 2 of 7 ==
Date: Wed, Dec 23 2009 8:00 am
From: Mark Hounschell

On 12/23/2009 10:34 AM, Mark Hounschell wrote:
> On 12/23/2009 10:10 AM, Pallipadi, Venkatesh wrote:
>>
>>
>>> -----Original Message-----
>>> From: Mark Hounschell [mailto:markh@compro.net]
>>> Sent: Wednesday, December 23, 2009 5:03 AM
>>> To: Pallipadi, Venkatesh
>>> Cc: dmarkh@cfl.rr.com; Linus Torvalds; Alain Knaff; Linux
>>> Kernel Mailing List; fdutils@fdutils.linux.lu; Li, Shaohua; Ingo Molnar
>>> Subject: Re: [Fdutils] DMA cache consistency bug introduced in
>>> 2.6.28 (Was: Re: Cannot format floppies under kernel 2.6.*?)
>>>
>>> On 12/22/2009 07:22 PM, Mark Hounschell wrote:
>>>> On 12/22/2009 06:37 PM, Pallipadi, Venkatesh wrote:
>>>>> On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
>>>>>> On 12/22/2009 12:38 PM, Linus Torvalds wrote:
>>>>>>>
>>>>>>> [ Ingo, Venki and Shaohua added to cc: see the whole
>>> thread on lkml for
>>>>>>> details, but Mark is basically chasing down a situation
>>> where the floppy
>>>>>>> driver seems to have trouble formatting floppies, and
>>> it happened
>>>>>>> between 2.6.27 and .28. The trouble seems to be that a
>>> DMA transfer of a
>>>>>>> memory block transfers the wrong value for the first
>>> byte of the block.
>>>>>>>
>>>>>>> Which should be impossible, but whatever. Some part of
>>> the system has a
>>>>>>> cached buffer that isn't flushed.
>>>>>>>
>>>>>>> What gets _you_ guys involved is that Mark cannot
>>> reproduce the bug if
>>>>>>> HPET is disabled in the BIOS or by using 'nohpet'. He
>>> found that out by
>>>>>>> pure luck while bisecting, because some time during his
>>> bisect, his
>>>>>>> machine wouldn't even boot with HPET.
>>>>>>>
>>>>>>> So the problem is: with HPET enabled, 2.6.27.4 _used_
>>> to work. But
>>>>>>> 2.6.28 (and current -git) does not. Any ideas? ]
>>>>>>>
>>>>>>> On Tue, 22 Dec 2009, Mark Hounschell wrote:
>>>>>>>>
>>>>>>>> Ok, I may have something that might help.
>>>>>>>>
>>>>>>>> # git bisect bad
>>>>>>>> 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit
>>>>>>>> commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0
>>>>>>>> Author: venkatesh.pallipadi@intel.com
>>> <venkatesh.pallipadi@intel.com>
>>>>>>>> Date: Fri Sep 5 18:02:18 2008 -0700
>>>>>>>>
>>>>>>>> x86: HPET_MSI Initialise per-cpu HPET timers
>>>>>>>>
>>>>>>>> Initialize a per CPU HPET MSI timer when possible.
>>> We retain the HPET
>>>>>>>> timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when
>>> legacy mode is being used. We
>>>>>>>> setup the remaining HPET timers as per CPU MSI based
>>> timers. This per CPU
>>>>>>>> timer will eliminate the need for timer broadcasting
>>> with IRQ 0 when there
>>>>>>>> is non-functional LAPIC timer across CPU deep C-states.
>>>>>>>>
>>>>>>>> If there are more CPUs than number of available
>>> timers, CPUs that do not
>>>>>>>> find any timer to use will continue using LAPIC and
>>> IRQ 0 broadcast.
>>>>>>>>
>>>>>>>> Signed-off-by: Venkatesh Pallipadi
>>> <venkatesh.pallipadi@intel.com>
>>>>>>>> Signed-off-by: Shaohua Li <shaohua.li@intel.com>
>>>>>>>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>>>>>>>
>>>>>>>> And of coarse this was the first commit that I could not
>>> boot if I had hpet
>>>>>>>> enabled. To get this one to boot (single user mode only)
>>> I had to add the
>>>>>>>> the quiet cmdline option and following patch from to
>>> arch/x86/kernel/hpet.c
>>>>>>>>
>>>>>>>> commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
>>>>>>>>
>>>>>>>> @ -445,7 +445,7 @@ static int hpet_setup_irq(struct
>>> hpet_dev *dev)
>>>>>>>> {
>>>>>>>>
>>>>>>>> if (request_irq(dev->irq, hpet_interrupt_handler,
>>>>>>>> - IRQF_SHARED|IRQF_NOBALANCING,
>>> dev->name, dev))
>>>>>>>> + IRQF_DISABLED|IRQF_NOBALANCING,
>>> dev->name, dev))
>>>>>>>> return -1;
>>>>>>>>
>>>>>>>> disable_irq(dev->irq);
>>>>>>>>
>>>>>>>> AND add the quiet cmdline option.
>>>>>>>
>>>>>>> Ok, so we know why HPET didn't boot for you, and that was
>>> fixed later (by
>>>>>>> that 5ceb1a04). But is this also when the floppy started
>>> mis-behaving?
>>>>>>>
>>>>>>
>>>>>> Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when
>>> the floppy stops
>>>>>> working
>>>>>> and also when I could no longer boot with hpet enabled.
>>>>>
>>>>>
>>>>> I am missing something here. Commit 26afe5f2 is where
>>> system does not
>>>>> boot with HPET or is it where the floppy stops working when you boot
>>>>> with HPET enabled.
>>>>>
>>>>
>>>> As it happens, both happen there. Commit 5ceb1a04 is where it starts
>>>> booting _again_ with hpet enabled. So I took that patch
>>> (5ceb1a04) and
>>>> applied it to (26afe5f2f) to be able to boot with hpet
>>> enabled. I had to
>>>> use the quiet option to get to a login prompt, but there is where the
>>>> floppy format first fails, just as it does in 2.6.28 and up.
>>>>
>>>>> Can you try "idle=halt" with both .27 and .28 with /proc/interrupts
>>>>> output in each case. With that option, we should be using local APIC
>>>>> timer and PIT, HPET or HPET with MSI should not really
>>> matter. Does it
>>>>> still fail with .28 with that option?
>>>>>
>>>
>>> 2.6.28 still fails with that option.
>>>
>>> 2.6.27.41 /proc/interrupts with idle=halt
>>>
>>> CPU0 CPU1 CPU2 CPU3
>>> 0: 126 0 0 1
>>> IO-APIC-edge timer
>>> 1: 0 0 1 157
>>> IO-APIC-edge i8042
>>> 3: 0 0 0 6 IO-APIC-edge
>>> 4: 0 0 0 6 IO-APIC-edge
>>> 6: 0 0 0 4
>>> IO-APIC-edge floppy
>>> 8: 0 0 0 1
>>> IO-APIC-edge rtc0
>>> 9: 0 0 0 0
>>> IO-APIC-fasteoi acpi
>>> 12: 0 0 1 128
>>> IO-APIC-edge i8042
>>> 14: 0 0 34 4457 IO-APIC-edge
>>> pata_atiixp
>>> 15: 0 0 4 480 IO-APIC-edge
>>> pata_atiixp
>>> 16: 0 0 0 397 IO-APIC-fasteoi
>>> aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel
>>> 17: 0 0 0 2 IO-APIC-fasteoi
>>> ehci_hcd:usb1
>>> 18: 0 0 0 0 IO-APIC-fasteoi
>>> ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
>>> 19: 0 0 0 142 IO-APIC-fasteoi
>>> aic7xxx, ehci_hcd:usb2, ttySLG0, eth1
>>> 22: 0 0 4 1154
>>> IO-APIC-fasteoi ahci
>>> 219: 0 0 3 63
>>> PCI-MSI-edge eth0
>>> NMI: 0 0 0 0
>>> Non-maskable interrupts
>>> LOC: 91539 91964 92525 91181 Local timer
>>> interrupts
>>> RES: 2888 3873 2434 2721
>>> Rescheduling interrupts
>>> CAL: 240 245 247 84 function
>>> call interrupts
>>> TLB: 768 628 526 512 TLB shootdowns
>>> SPU: 0 0 0 0 Spurious interrupts
>>> ERR: 0
>>> MIS: 0
>>>
>>> 2.6.28 /proc/interrupts with idle=halt
>>>
>>> CPU0 CPU1 CPU2 CPU3
>>> 0: 126 0 2 0
>>> IO-APIC-edge timer
>>> 1: 0 0 192 0
>>> IO-APIC-edge i8042
>>> 3: 0 0 6 0 IO-APIC-edge
>>> 4: 0 0 6 0 IO-APIC-edge
>>> 6: 0 0 4 0
>>> IO-APIC-edge floppy
>>> 8: 0 0 1 0
>>> IO-APIC-edge rtc0
>>> 9: 0 0 0 0
>>> IO-APIC-fasteoi acpi
>>> 12: 0 0 128 1
>>> IO-APIC-edge i8042
>>> 14: 0 1 147114 396 IO-APIC-edge
>>> pata_atiixp
>>> 15: 0 0 646 2 IO-APIC-edge
>>> pata_atiixp
>>> 16: 0 0 396 0 IO-APIC-fasteoi
>>> aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel
>>> 17: 0 0 0 0 IO-APIC-fasteoi
>>> ehci_hcd:usb1
>>> 18: 0 0 0 0 IO-APIC-fasteoi
>>> ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
>>> 19: 0 0 362 1 IO-APIC-fasteoi
>>> aic7xxx, ehci_hcd:usb3, ttySLG0, eth1
>>> 22: 0 0 874 1
>>> IO-APIC-fasteoi ahci
>>> 1274: 0 0 193 4
>>> PCI-MSI-edge eth0
>>> 1279: 513207 0 0 0
>>> HPET_MSI-edge hpet2
>>> NMI: 0 0 0 0
>>> Non-maskable interrupts
>>> LOC: 268 513395 513138 522088 Local timer
>>> interrupts
>>> RES: 3262 3679 2573 3746
>>> Rescheduling interrupts
>>> CAL: 131 166 57 147 Function
>>> call interrupts
>>> TLB: 680 438 450 639 TLB shootdowns
>>> SPU: 0 0 0 0 Spurious interrupts
>>> ERR: 0
>>> MIS: 0
>>>
>>
>> Hmm. Looks like hpet2 is still getting used instead of local APIC timer in .28 case.
>>
>> I was expecting some low number in hpet2 and local timer on all CPU to be around the same value. Above shows CPU 0 is depending on hpet2 for some reason even with idle=halt. Can you send the output of below two in case of .28
>> /proc/timer_list
>
> Attached.
>
>> grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
>
> I have no /sys/devices/system/cpu/cpu0/cpuidle on this machine.
> Maybe because of
>
> #
> # CPU Frequency scaling
> #
> # CONFIG_CPU_FREQ is not set
> # CONFIG_CPU_IDLE is not set
>
> Would it be OK if when you ask for 2.6.28 info, I use a 2.6.32.2 kernel?
> That kernel also fails fdformat with hpet enabled on these machines.
>

I do have this on 2.6.32.2 though.

# grep . /sys/devices/system/cpu/cpuidle/current_*
/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor_ro:ladder

Want me to go back to 2.6.28 and show this?

Mark

== 3 of 7 ==
Date: Wed, Dec 23 2009 8:40 am
From: Linus Torvalds

On Wed, 23 Dec 2009, Mark Hounschell wrote:
> >
> > Hmm. Looks like hpet2 is still getting used instead of local APIC
> > timer in .28 case.
> >
> > I was expecting some low number in hpet2 and local timer on all CPU to
> > be around the same value. Above shows CPU 0 is depending on hpet2 for
> > some reason even with idle=halt. Can you send the output of below two
> > in case of .28 /proc/timer_list
>
> Attached.

Oh wow.

That's crazy:

Tick Device: mode: 1
Per CPU device: 0
Clock Event Device: hpet2
max_delta_ns: 2147483647
min_delta_ns: 5000
mult: 61510047
shift: 32
mode: 3
next_event: 123991000000 nsecs
set_next_event: hpet_msi_next_event
set_mode: hpet_msi_set_mode
event_handler: hrtimer_interrupt

Tick Device: mode: 1
Per CPU device: 1
Clock Event Device: lapic
max_delta_ns: 670831998
min_delta_ns: 1199
mult: 53707624
shift: 32
mode: 3
next_event: 123991125000 nsecs
set_next_event: lapic_next_event
set_mode: lapic_timer_setup
event_handler: hrtimer_interrupt

...

It's not using the lapic for CPU0.

Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty
expensive to reprogram (compared to the local apic). And having different
timers for different CPU's is just odd.

The fact that the timer subsystem can do this and it all (mostly) works at
all is nice and impressive, but doesn't make it any less crazy ;)

That said, none of this seems to explain why DMA/fdformat doesn't work.

Linus
--
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/

== 4 of 7 ==
Date: Wed, Dec 23 2009 8:40 am
From: Andi Kleen

Linus Torvalds <torvalds@linux-foundation.org> writes:

> It's not using the lapic for CPU0.
>
> Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty
> expensive to reprogram (compared to the local apic). And having different
> timers for different CPU's is just odd.
>
> The fact that the timer subsystem can do this and it all (mostly) works at
> all is nice and impressive, but doesn't make it any less crazy ;)

I suspect it's a system where the APIC timer stops in deeper idle
states and it supports them. In this case CPU #0 does timer broadcasts
when needed to wake the other CPUs up from deep C, but for that it has
to run with HPET. At least the other ones can still enjoy the LAPIC
timer.

This might suggest that Mark's floppy controller doesn't like
deep C? Mark, did you try booting with processor.max_cstate=1
and HPET enabled?

-Andi
--
ak@linux.intel.com -- Speaking for myself only.
--
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/

== 5 of 7 ==
Date: Wed, Dec 23 2009 9:00 am
From: Linus Torvalds

On Wed, 23 Dec 2009, Andi Kleen wrote:
>
> I suspect it's a system where the APIC timer stops in deeper idle
> states and it supports them. In this case CPU #0 does timer broadcasts
> when needed to wake the other CPUs up from deep C, but for that it has
> to run with HPET. At least the other ones can still enjoy the LAPIC
> timer.

Ahh, ok, that makes sense. I was assuming the broadcast timer would act in
that capacity, but..

> This might suggest that Mark's floppy controller doesn't like
> deep C? Mark, did you try booting with processor.max_cstate=1
> and HPET enabled?

We have indeed had historical issues with floppy and sleep states before.

I do note another issue, though - the floppy driver itself seems totally
broken when it comes to using interleaved sectors. Alain, that "place
logical sectors" code is simply _broken_ - the "while" kicks in only if
the first sector we test is busy _and_ we were at the last sector so that
we increment past F_SECT_PER_TRACK.

So shouldn't that sector layout be something like the appended?

Linus
---
drivers/block/floppy.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 3266b4f..9c9148c 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -2237,13 +2237,10 @@ static void setup_format_params(int track)
for (count = 1; count <= F_SECT_PER_TRACK; ++count) {
here[n].sect = count;
n = (n + il) % F_SECT_PER_TRACK;
- if (here[n].sect) { /* sector busy, find next free sector */
+ while (here[n].sect) { /* sector busy, find next free sector */
++n;
- if (n >= F_SECT_PER_TRACK) {
+ if (n >= F_SECT_PER_TRACK)
n -= F_SECT_PER_TRACK;
- while (here[n].sect)
- ++n;
- }
}
}
if (_floppy->stretch & FD_SECTBASEMASK) {
--
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/

== 6 of 7 ==
Date: Wed, Dec 23 2009 9:10 am
From: Andi Kleen

On Wed, Dec 23, 2009 at 08:49:38AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 23 Dec 2009, Andi Kleen wrote:
> >
> > I suspect it's a system where the APIC timer stops in deeper idle
> > states and it supports them. In this case CPU #0 does timer broadcasts
> > when needed to wake the other CPUs up from deep C, but for that it has
> > to run with HPET. At least the other ones can still enjoy the LAPIC
> > timer.
>
> Ahh, ok, that makes sense. I was assuming the broadcast timer would act in
> that capacity, but..

The "broadcasts" are done using IPIs from cpu #08 and only when that target
CPU is deep idle. That's more efficient than letting the hardware
always broadcast.

>
> > This might suggest that Mark's floppy controller doesn't like
> > deep C? Mark, did you try booting with processor.max_cstate=1
> > and HPET enabled?
>
> We have indeed had historical issues with floppy and sleep states before.

I removed that code when moving to 64bit (floppy driver disabling C1),
but perhaps we need some variant of it again (but it's the first such
report in many years). Although it would be sad to have it again on all
systems.

-Andi
--
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/

== 7 of 7 ==
Date: Wed, Dec 23 2009 9:20 am
From: Andi Kleen

> This is what I was thining yday and asked Mark to try idle=halt.
> This /proc/interrupts is with idle=halt when there should not be any
> C-states and broadcasts involved.

Ah ok, missed that sorry.

Actually I'm glad that the floppy-idle hack is not needed again.

==============================================================================
TOPIC: scheduler fix
http://groups.google.com/group/linux.kernel/t/fc9097f7840d0f9a?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 8:10 am
From: Ingo Molnar

Linus,

Please pull the latest sched-fixes-for-linus git tree from:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git sched-fixes-for-linus

Thanks,

Ingo

------------------>
Peter Zijlstra (1):
sched: Revert 738d2be, simplify set_task_cpu()

kernel/sched.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 87f1f47..c535cc4 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2045,11 +2045,10 @@ void set_task_cpu(struct task_struct *p, unsigned int new_cpu)

trace_sched_migrate_task(p, new_cpu);

- if (task_cpu(p) == new_cpu)
- return;
-
- p->se.nr_migrations++;
- perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 1, NULL, 0);
+ if (task_cpu(p) != new_cpu) {
+ p->se.nr_migrations++;
+ perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 1, NULL, 0);
+ }

__set_task_cpu(p, new_cpu);
}
--
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: NULL pointer in usb_serial_probe() introduced by the recent kfifo
changes
http://groups.google.com/group/linux.kernel/t/416fe3d3ef6ee79e?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Dec 23 2009 8:20 am
From: "Rafael J. Wysocki"

On Wednesday 23 December 2009, Greg KH wrote:
> On Wed, Dec 23, 2009 at 02:51:31AM +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Something like the patch below is necessary to fix a new NULL pointer deref
> > in usb_serial_probe() that appeared after the recent kfifo changes (in short,
> > the kfifo changes modified the semantics of kfifo_alloc() that
> > usb_serial_probe() reiled on).
>
> What semantic changed? I thought that the kfifo patches came with
> patches that also fixed up any changed that were needed. What went
> wrong here?

Previously write_fifo was allocated by kfifo_alloc() along with the structure
members. Now kfifo_alloc() expects to get a pointer to existing structure.

> Does your patch solve the oops?

Sure, that's why I posted it. :-)

Rafael
--
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/

== 2 of 3 ==
Date: Wed, Dec 23 2009 8:20 am
From: "Rafael J. Wysocki"

On Wednesday 23 December 2009, Alan Stern wrote:
> On Wed, 23 Dec 2009, Rafael J. Wysocki wrote:
>
> > Hi,
> >
> > Something like the patch below is necessary to fix a new NULL pointer deref
> > in usb_serial_probe() that appeared after the recent kfifo changes (in short,
> > the kfifo changes modified the semantics of kfifo_alloc() that
> > usb_serial_probe() reiled on).
> >
> > Thanks,
> > Rafael
> >
> > ---
> > drivers/usb/serial/usb-serial.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > Index: linux-2.6/drivers/usb/serial/usb-serial.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/usb/serial/usb-serial.c
> > +++ linux-2.6/drivers/usb/serial/usb-serial.c
> > @@ -595,8 +595,10 @@ static void port_release(struct device *
> > usb_free_urb(port->write_urb);
> > usb_free_urb(port->interrupt_in_urb);
> > usb_free_urb(port->interrupt_out_urb);
> > - if (!IS_ERR(port->write_fifo) && port->write_fifo)
> > + if (port->write_fifo) {
> > kfifo_free(port->write_fifo);
> > + kfree(port->write_fifo);
> > + }
> > kfree(port->bulk_in_buffer);
> > kfree(port->bulk_out_buffer);
> > kfree(port->interrupt_in_buffer);
> > @@ -939,6 +941,12 @@ int usb_serial_probe(struct usb_interfac
> > dev_err(&interface->dev, "No free urbs available\n");
> > goto probe_error;
> > }
> > + port->write_fifo = kzalloc(sizeof(struct kfifo), GFP_KERNEL);
> > + if (!port->write_fifo) {
> > + dev_err(&interface->dev,
> > + "Couldn't allocate write_fifo\n");
> > + goto probe_error;
> > + }
> > if (kfifo_alloc(port->write_fifo, PAGE_SIZE, GFP_KERNEL))
> > goto probe_error;
> > buffer_size = le16_to_cpu(endpoint->wMaxPacketSize);
>
> Although this would mean further changes elsewhere, doesn't it make
> more sense to embed the struct kfifo directly in the usb_serial_port
> structure instead of allocating it dynamically?

I guess it would, but I wanted to avoid making any further changes.

== 3 of 3 ==
Date: Wed, Dec 23 2009 8:50 am
From: "Rafael J. Wysocki"

On Wednesday 23 December 2009, Stefani Seibold wrote:
> Am Dienstag, den 22.12.2009, 21:37 -0800 schrieb Greg KH:
> > On Wed, Dec 23, 2009 at 02:51:31AM +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > Something like the patch below is necessary to fix a new NULL pointer deref
> > > in usb_serial_probe() that appeared after the recent kfifo changes (in short,
> > > the kfifo changes modified the semantics of kfifo_alloc() that
> > > usb_serial_probe() reiled on).
> >
> > What semantic changed? I thought that the kfifo patches came with
> > patches that also fixed up any changed that were needed. What went
> > wrong here?
> >
>
> This one is a new user of the kfifo API, so it forget to port it to the
> new kfifo API.
>
> Please make the write_fifo in place. Here is my patch to fix the
> regression and full ported version.
>
> Stefani
>
> Signed-off-by: Stefani Seibold <stefani@seibold.net>

Tested-by: Rafael J. Wysocki <rjw@sisk.pl>

> ---
> drivers/usb/serial/generic.c | 12 ++++++------
> drivers/usb/serial/usb-serial.c | 5 ++---
> include/linux/usb/serial.h | 3 ++-
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff -u -N -r -p old/drivers/usb/serial/generic.c new/drivers/usb/serial/generic.c
> --- old/drivers/usb/serial/generic.c 2009-12-23 08:54:06.966476248 +0100
> +++ new/drivers/usb/serial/generic.c 2009-12-23 09:06:25.778474708 +0100
> @@ -276,7 +276,7 @@ static int usb_serial_generic_write_star
> if (port->write_urb_busy)
> start_io = false;
> else {
> - start_io = (kfifo_len(port->write_fifo) != 0);
> + start_io = (kfifo_len(&port->write_fifo) != 0);
> port->write_urb_busy = start_io;
> }
> spin_unlock_irqrestore(&port->lock, flags);
> @@ -285,7 +285,7 @@ static int usb_serial_generic_write_star
> return 0;
>
> data = port->write_urb->transfer_buffer;
> - count = kfifo_out_locked(port->write_fifo, data, port->bulk_out_size, &port->lock);
> + count = kfifo_out_locked(&port->write_fifo, data, port->bulk_out_size, &port->lock);
> usb_serial_debug_data(debug, &port->dev, __func__, count, data);
>
> /* set up our urb */
> @@ -345,7 +345,7 @@ int usb_serial_generic_write(struct tty_
> return usb_serial_multi_urb_write(tty, port,
> buf, count);
>
> - count = kfifo_in_locked(port->write_fifo, buf, count, &port->lock);
> + count = kfifo_in_locked(&port->write_fifo, buf, count, &port->lock);
> result = usb_serial_generic_write_start(port);
>
> if (result >= 0)
> @@ -370,7 +370,7 @@ int usb_serial_generic_write_room(struct
> (serial->type->max_in_flight_urbs -
> port->urbs_in_flight);
> } else if (serial->num_bulk_out)
> - room = port->write_fifo->size - kfifo_len(port->write_fifo);
> + room = kfifo_avail(&port->write_fifo);
> spin_unlock_irqrestore(&port->lock, flags);
>
> dbg("%s - returns %d", __func__, room);
> @@ -391,7 +391,7 @@ int usb_serial_generic_chars_in_buffer(s
> chars = port->tx_bytes_flight;
> spin_unlock_irqrestore(&port->lock, flags);
> } else if (serial->num_bulk_out)
> - chars = kfifo_len(port->write_fifo);
> + chars = kfifo_len(&port->write_fifo);
>
> dbg("%s - returns %d", __func__, chars);
> return chars;
> @@ -507,7 +507,7 @@ void usb_serial_generic_write_bulk_callb
> if (status) {
> dbg("%s - nonzero multi-urb write bulk status "
> "received: %d", __func__, status);
> - kfifo_reset(port->write_fifo);
> + kfifo_reset_out(&port->write_fifo);
> } else
> usb_serial_generic_write_start(port);
> }
> diff -u -N -r -p old/drivers/usb/serial/usb-serial.c new/drivers/usb/serial/usb-serial.c
> --- old/drivers/usb/serial/usb-serial.c 2009-12-23 08:54:23.204476351 +0100
> +++ new/drivers/usb/serial/usb-serial.c 2009-12-23 09:06:39.664475312 +0100
> @@ -595,8 +595,7 @@ static void port_release(struct device *
> usb_free_urb(port->write_urb);
> usb_free_urb(port->interrupt_in_urb);
> usb_free_urb(port->interrupt_out_urb);
> - if (!IS_ERR(port->write_fifo) && port->write_fifo)
> - kfifo_free(port->write_fifo);
> + kfifo_free(&port->write_fifo);
> kfree(port->bulk_in_buffer);
> kfree(port->bulk_out_buffer);
> kfree(port->interrupt_in_buffer);
> @@ -939,7 +938,7 @@ int usb_serial_probe(struct usb_interfac
> dev_err(&interface->dev, "No free urbs available\n");
> goto probe_error;
> }
> - if (kfifo_alloc(port->write_fifo, PAGE_SIZE, GFP_KERNEL))
> + if (kfifo_alloc(&port->write_fifo, PAGE_SIZE, GFP_KERNEL))
> goto probe_error;
> buffer_size = le16_to_cpu(endpoint->wMaxPacketSize);
> port->bulk_out_size = buffer_size;
> diff -u -N -r -p old/include/linux/usb/serial.h new/include/linux/usb/serial.h
> --- old/include/linux/usb/serial.h 2009-12-23 08:54:34.368476110 +0100
> +++ new/include/linux/usb/serial.h 2009-12-23 09:06:32.870725683 +0100
> @@ -16,6 +16,7 @@
> #include <linux/kref.h>
> #include <linux/mutex.h>
> #include <linux/sysrq.h>
> +#include <linux/kfifo.h>
>
> #define SERIAL_TTY_MAJOR 188 /* Nice legal number now */
> #define SERIAL_TTY_MINORS 254 /* loads of devices :) */
> @@ -94,7 +95,7 @@ struct usb_serial_port {
> unsigned char *bulk_out_buffer;
> int bulk_out_size;
> struct urb *write_urb;
> - struct kfifo *write_fifo;
> + struct kfifo write_fifo;
> int write_urb_busy;
> __u8 bulk_out_endpointAddress;
>
>
>
> --
> 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: [patch] DT3155: Use pci_get_device
http://groups.google.com/group/linux.kernel/t/585bf12915aea417?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 8:30 am
From: Greg KH

On Wed, Dec 23, 2009 at 07:54:49PM +1100, Simon Horman wrote:
> The use of pci_find_device() is deprecated.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> Compile tested only.
>
> Alternatively, if pci_find_device() really needs to be used
> then this code needs to depend on PCI_LEGACY.
>
> Index: gregkh-2.6/drivers/staging/dt3155/dt3155_drv.c
> ===================================================================
> --- gregkh-2.6.orig/drivers/staging/dt3155/dt3155_drv.c 2009-12-23 18:41:46.000000000 +1100
> +++ gregkh-2.6/drivers/staging/dt3155/dt3155_drv.c 2009-12-23 18:42:29.000000000 +1100
> @@ -963,7 +963,7 @@ static int find_PCI (void)
> unsigned long base;
> unsigned char irq;
>
> - while ((pci_dev = pci_find_device
> + while ((pci_dev = pci_get_device

You can't just replace these two functions, they operate differently
with regard to the reference counting logic. Otherwise it wouldn't make
sense to have 2 different functions :)

So I can't apply this.

thanks,

greg k-h
--
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: via_rhine kernel crashes in 2.6.32
http://groups.google.com/group/linux.kernel/t/4d8e8d13d27c7077?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 23 2009 8:30 am
From: Andrey Rahmatullin

On Wed, Dec 23, 2009 at 09:52:03AM +0000, Jarek Poplawski wrote:
> BTW, it seems a change in 2.6.31 might trigger these timeouts more
> often than before. Andrey, could you try if this matters here?
They appear once per 4 seconds with or without this patch.

--
WBR, wRAR (ALT Linux Team)
--
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/

== 2 of 2 ==
Date: Wed, Dec 23 2009 8:40 am
From: Jarek Poplawski

Andrey Rahmatullin wrote, On 12/23/2009 05:21 PM:

> On Wed, Dec 23, 2009 at 09:52:03AM +0000, Jarek Poplawski wrote:
>> BTW, it seems a change in 2.6.31 might trigger these timeouts more
>> often than before. Andrey, could you try if this matters here?
> They appear once per 4 seconds with or without this patch.
>

OK, thanks for checking this.

Jarek P.
--
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: mac80211 suspend corner case (was: Asus eeepc 1008HA suspend issue and
mac80211 suspend corner) case
http://groups.google.com/group/linux.kernel/t/033504ee0cb101d3?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 8:30 am
From: "Luis R. Rodriguez"

On Wed, Dec 23, 2009 at 04:08:01AM -0800, Johannes Berg wrote:
> On Tue, 2009-12-22 at 14:30 -0500, Luis R. Rodriguez wrote:
>
> > Johannes, any preferences how to handle this? The patch below avoids
> > the Interrupt being turned off but its not enough given that we still
> > could be associated according to userspace. If the hardware is
> > unresponsive maybe it is best to just let the IRQ go disabled, not
> > sure, but its likely not what happens in all cases.
> >
> > Trimming out the irrelevant parts below.
>
> > http://bombadil.infradead.org/~mcgrof/logs/2.6.31-with-2.6.32-wireless
> > /irq-disabled.txt
> > >
> > > This can be fixed by something like the following:
> > >
> > > diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> > > index e6c08da..63d42fa 100644
> > > --- a/net/mac80211/util.c
> > > +++ b/net/mac80211/util.c
> > > @@ -1031,7 +1031,14 @@ int ieee80211_reconfig(struct ieee80211_local
> > *local)
> > >
> > > /* restart hardware */
> > > if (local->open_count) {
> > > + /*
> > > + * Upon resume hardware can sometimes be goofy due to
> > > + * various platform issues, so restarting the device may
> > > + * at times not work immediately. Propagate the error.
> > > + */
> > > res = drv_start(local);
> > > + if (res)
> > > + return res;
> > >
> > > ieee80211_led_radio(local, true);
> > > }
> > >
> > > But this isn't enough. And since we cannot exactly talk to hardware
> > > we can't try to send a deassoc as harware would be unresponsive. I
> > > also don't see us handling such cases before either on cfg80211 or
> > > mac80211, so curious what we should do.
>
> Well it seems to me that if the driver determines that the hardware is
> unreachable or not responding, it would unregister it from mac80211,
> which would clean up all user-visible state, obviously.

The drivers would not know this until it fails on the first call
from mac80211 which would be start().

> The patch above seems ok to me, but basically papers over the problem.
> If the start there fails, the driver will have to unregister the hw
> since any subsequent start will fail as well.

How about just having mac80211 do that for drivers where the start()
fails and we are resuming? I can give that a shot.

> The way I see it, it's like a USB unplug while suspended/hibernated ...
> the driver notices that and remo

I see, in this case though I'd prefer if mac80211 could do more of
the work instead of requiring each driver to treat start() failures
by unregistering themselves, specially since we don't inform drivers
they are coming back from resume on start().

==============================================================================
TOPIC: NFS lockdep lock misordering mmap_sem<->i_mutex_key with 2.6.32-git1
http://groups.google.com/group/linux.kernel/t/865640cc1d5b2326?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 8:40 am
From: Andi Kleen

> The scenario would be that the writing thread triggers a page fault
> (through __get_user()) when holding the i_mutex, while the other thread
> is trying to grab the i_mutex within the mmap() call.

Hi Trond,

What's the state of this bug? Are you going to accept my patch
or do you have a different one in the pipeline?

Thanks,

-Andi

--
ak@linux.intel.com -- Speaking for myself only.
--
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: Staging tree status for the .33 kernel merge
http://groups.google.com/group/linux.kernel/t/818bdf5c79b5bf8d?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 8:40 am
From: Greg KH

On Wed, Dec 23, 2009 at 11:53:15AM +0100, Sebastian Andrzej Siewior wrote:
> * Greg KH | 2009-12-22 16:54:47 [-0800]:
>
> >Here's a summary of the state of the drivers/staging/ tree, basically
> >what will be coming in the 2.6.33 merge, and what the status of the
> >different drivers are so far.
>
> I can't find usbip in your summary. Is there nothing to say or did you
> just forgot about it?

Oops, I forgot about it. It's slated to be removed in .35 as well,
because no one is working on it.

thanks,

==============================================================================
TOPIC: AlacrityVM guest drivers for 2.6.33
http://groups.google.com/group/linux.kernel/t/265f7bf4a9a1d92d?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 23 2009 8:50 am
From: Gregory Haskins

On 12/23/09 1:51 AM, Ingo Molnar wrote:
>
> * Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>> On 12/22/2009 10:01 AM, Bartlomiej Zolnierkiewicz wrote:
>>>> new e1000 driver is more superior in architecture and do the required
>>>> work to make the new e1000 driver a full replacement for the old one.
>>> Right, like everyone actually does things this way..
>>>
>>> I wonder why do we have OSS, old Firewire and IDE stacks still around then?
>>
>> And it's always a source of pain, isn't it.
>
> Even putting aside the fact that such overlap sucks and is a pain to users
> (and that 98% of driver and subsystem version transitions are done completely
> seemlessly to users - the examples that were cited were the odd ones out of
> 150K commits in the past 4 years, 149K+ of which are seemless), the comparison
> does not even apply really.
>
> e1000, OSS, old Firewire and IDE are hardware stacks, where hardware is a not
> fully understood externality, with its inevitable set of compatibility voes.
> There's often situations where one piece of hardware still works better with
> the old driver, for some odd (or not so odd) reason.
>
> Also, note that the 'new' hw drivers are generally intended and are maintained
> as clear replacements for the old ones, and do so with minimal ABI changes -
> or preferably with no ABI changes at all. Most driver developers just switch
> from old to new and the old bits are left around and are phased out. We phased
> out old OSS recently.
>
> That is a very different situation from the AlacrityVM patches, which:
>
> - Are a pure software concept

By design. In fact, I would describe it as "software to software
optimized" as opposed to trying to shoehorn into something that was
designed as a software-to-hardware interface (and therefore has
assumptions about the constraints in that environment that are not
applicable in software-only).

> and any compatibility mismatch is self-inflicted.

.. because the old model is not great for the intended use cases and has
issues. I've already covered the reasons why adnauseam.

> The patches are in fact breaking the ABI to KVM intentionally (for better or worse).

No, at the very worst they are _augmenting_ the ABI, as evident from the
fact that AlacrityVM is a superset of the entire KVM ABI.

>
> - Gregory claims that the AlacricityVM patches are not a replacement for KVM.
> I.e. there's no intention to phase out any 'old stuff'

There's no reason to phase anything out, except perhaps the virtio-pci
transport. This is one more transport, plugging into virtio underneath
(just like virtio-pci, virtio-lguest, and virtio-s390). I am not even
suggesting that the old transport has to go away, per se. It is the KVM
maintainers who insist on it being all or nothing. For me, I do not see
the big deal in having one more "model" option in the qemu cmd-line, but
that is just my opinion. If the maintainers were really so adamant that
choice is pure evil, I am not sure why we don't see patches for removing
everything but one model type in each IO category. But I digress.

> and it splits the pool of driver developers.

..it these dumb threads that are splitting driver developers with
ignorant statements, irrelevant numbers, and dubious "facts". I
actually tried many many times to ask others to join the effort, and
instead _they_ forked off and made vhost-net with a "sorry, not
interested in working with you"(and based the design largely on the
ideas proposed in my framework, I might add). Thats fine, and it's
their prerogative. I can easily maintain my project out of tree if
upstream is not interested. But do not turn around and try to blame me
for the current state of affairs.

>
> i.e. it has all the makings of a stupid, avoidable, permanent fork. The thing
> is, if AlacricityVM is better, and KVM developers are not willing to fix their
> stuff, replace KVM with it.
>
> It's a bit as if someone found a performance problem with sys_open() and came
> up with sys_open_v2() and claimed that he wants to work with the VFS
> developers while not really doing so but advances sys_open_v2() all the time.

No, its more like if I suggested sys_open_vbus() to augment
sys_open_pci(), sys_open_lguest(), sys_open_s390() because our
fictitious glibc natively supported modular open() implementations. And
I tried to work for a very long time convincing the VFS developers that
this new transport was a good idea to add because it was optimized for
the problem space, made it easy for API callers to reuse the important
elements of the design (e.g. built in "tx-mitigation" instead of waiting
for someone to write it for each device), had new features like the
ability to prioritize signals, create/route signal paths arbitrarily,
implement raw shared memory for idempotent updates, and didn't require
the massive and useless PCI/APIC emulation logic to function like
sys_open_pci() (e.g. easier to port around).

Ultimately, the "VFS developers" said "I know we let other transports in
in the past, but now all transports must be sys_open_pci() based going
forward". Game over, since sys_open_pci cannot support the features I
need, and/or it makes incredibly easy things complex when they don't
need to be so its a poor choice.

>
> Do we allow sys_open_v2() upstream, in the name of openness and diversity,
> letting some apps use that syscall while other apps still use sys_open()?

s/sys_open_v2/sys_open_vbus to portray it accurately, and sure, why not?
There is plenty of precedent already. Its just the top-edge IO ABI.
You can chose realtek, e1000, virtio-net 802.x ABIs today for instance.
This is one more, and despite attempts at painting it duplicative, it
is indeed an evolutionary upgrade IMO especially when you glance beyond
the 802.x world and look at the actual device model presented.

And its moot, anyway, as I have already retracted my one outstanding
pull request based on Linus' observation. So at this time, I am not
advocating _anything_ for upstream inclusion. And I am contemplating
_never_ doing so again. It's not worth _this_.

> Or do we say "enough is enough of this stupidity,

I certainly agree that this thread has indeed introduced a significant
degree of stupidity, yes.

> come up with some strong
> reasons to replace sys_open, and if so, replace the thing and be done with the
> pain!".
>

I am open to this, but powerless to control the decision in the upstream
variant other than to describe what I did, and rebut FUD against it to
make sure the record is straight.

> Overlap and forking can still be done in special circumstances, when a project
> splits and a hostile fork is inevitable due to prolongued and irreconcilable
> differences between the parties

You are certainly a contributing factor in pushing things in that direction.

> and if there's no strong technical advantage
> on either side. I havent seen evidence of this yet though: Gregory
claims that
> he wants to 'work with the community'

Well, I sincerely did in the beginning in the spirit of FOSS. I have to
admit that the desire is constantly eroded after dealing with the likes
of you. So if I have seemed more standoffish as of late, that is the
reason. If that was your goal, congratulations: You have irritated me
into submission. And no, I don't expect you to care.

> and the KVM guys seem to agree violently
> that performance can be improved - and are doing so (and are asking Gregory to
> take part in that effort).

And as I indicated to you in my first reply to this thread: the
performance aspects are but one goal here. Some of the performance
aspects cannot be achieved with their approach (like EIO mitigation as
an example), and some of the other feature based aspects cannot be
achieved either (interrupt priority, dynamic signals, etc). That is why
the calls to unify behind virtio-pci have gone unanswered by me: That
approach is orthogonal to the vbus project goals. Their ability to
understand or agree with that difference has no bearing on whether there
is any technical merit here. I think this is what you are failing to grasp.

There will be people that will say "Well, we can do a PV-APIC and get
EOI mitigation in PCI too". THAT IS WHAT VBUS IS FOR!!! Implementing
linux-kernel backed, shared-memory, high performance devices. Something
like a shared-memory based interrupt controller would be exactly the
kind of thing I envision here. We can also do other things, like high
performance timers, scheduler coordinators, etc. I don't know how many
different ways to describe it in a way that will be understood. I
started with 802.x because its easy to show the performance gains. If I
knew that the entire community would get bent around the axle on 802.x
when I started, I never would have broached the subject like this. Se
la vie.

>
> The main difference is that Gregory claims that improved performance is not
> possible within the existing KVM framework, while the KVM developers disagree.
> The good news is that this is a hard, testable fact.

Yes, I encourage a bakeoff and have code/instructions available to
anyone interested. I also encourage people to think about the other
facilities that are being introduced in addition to performance
enhancements for simple 802.x, or even KVM. This is about building a
modular framework that encompasses both sides of the links (guest AND
host), and implements "best practices" for optimized PV IO ingrained in
its DNA. It tries to do this in such a way that we don't need to write
new backends for every environment that comes along, or rely on
unnecessary emulation layers (PCI/APIC) to achieve it. It's about
extending Linux as a "io-visor" much as it is for userspace apps for any
environments, using a tried and true shared-memory based approach.

>
> I think we should try _much_ harder before giving up and forking the ABI of a
> healthy project and intentionally inflicting pain on our users.
>
> And, at minimum, such kinds of things _have to_ be pointed out in pull
> requests, because it's like utterly important. In fact i couldnt list any more
> important thing to point out in a pull request.

Mea Culpa. Since I've already established that the pull request didn't
directly relate to the controversy, I didn't think to mention that at
the time. These were just a few more drivers to join the ranks of 1000s
more within Linux. In retrospect, I probably should have so I apologize
for that. It was my first pull request to Linus, so I was bound to
screw something up.

-Greg

== 2 of 2 ==
Date: Wed, Dec 23 2009 9:10 am
From: Chris Wright

* Avi Kivity (avi@redhat.com) wrote:
> On 12/23/2009 02:14 PM, Andi Kleen wrote:
> >>http://www.redhat.com/f/pdf/summit/cwright_11_open_source_virt.pdf
> >>
> >>See slide 32. This is without vhost-net.
> >Thanks. Do you also have latency numbers?
>
> No. Copying Chris. This was with the tx mitigation timer disabled,
> so you won't see the usual atrocious userspace virtio latencies, but
> it won't be as good as a host kernel implementation since we take a
> heavyweight exit and qemu is pretty unoptimized.

Those numbers don't show cpu cycles per packet nor do they show latencies.
You won't see the timer based latency, because the tx mitigation scheme
is not timer based for those numbers. Below are some numbers comparing
bare metal, an assigned device, and virtio (not vhost-net, so we are still
doing a heavy-weight exit to qemu and syscalls to deliver to tap device).

> >It seems like there's definitely still potential for improvement
> >with messages<4K. But for the large messages they indeed
> >look rather good.

You are misreading the graph. At <4K it is tracking bare metal (the
green and yellow lines are bare metal, the red and blue bars are virtio).
At >4k we start to drop off (esp. on RX).

This (slide 9) shows AMQP latencies for bare metal, an assigned device,
and virtio.
http://www.redhat.com/f/pdf/summit/bche_320_red_hat_enterprise_mrg.pdf

Similarly, here's some much rawer latency numbers from netpipe, all done
in usecs.

bare assigned
metal PCI NIC virtio
(usecs) (usecs) (usecs)
----- ----- -----
1 bytes 22.20 36.16 53.19
2 bytes 22.21 35.98 53.23
3 bytes 22.22 36.18 53.29
4 bytes 22.25 33.77 53.43
6 bytes 22.33 36.33 53.48
8 bytes 22.32 36.24 53.27
12 bytes 22.25 35.97 53.33
13 bytes 22.40 35.94 53.54
16 bytes 22.36 35.98 53.60
19 bytes 22.40 35.95 53.51
21 bytes 22.42 35.94 53.76
24 bytes 22.32 36.18 53.45
27 bytes 22.34 36.08 53.48
29 bytes 22.36 36.02 53.42
32 bytes 22.46 36.15 53.23
35 bytes 22.36 36.23 53.13
45 bytes 26.32 36.17 53.29
48 bytes 26.24 35.94 53.50
51 bytes 26.44 36.01 53.66
61 bytes 26.43 33.66 53.28
64 bytes 26.66 36.32 53.17
67 bytes 26.35 36.21 53.53
93 bytes 26.59 36.49 45.75
96 bytes 26.48 36.28 45.72
99 bytes 26.51 36.47 45.72
125 bytes 26.74 36.48 45.99
128 bytes 26.44 36.52 45.69
131 bytes 26.52 35.71 45.80
189 bytes 26.77 36.99 46.78
192 bytes 26.96 37.45 47.00
195 bytes 26.96 37.45 47.10
253 bytes 27.01 38.03 47.36
256 bytes 27.09 37.85 47.23
259 bytes 26.98 37.82 47.28
381 bytes 26.61 38.38 47.84
384 bytes 26.72 38.54 48.01
387 bytes 26.76 38.65 47.80
509 bytes 25.13 39.19 48.30
512 bytes 25.13 36.69 56.05
515 bytes 25.15 37.42 55.70
765 bytes 25.29 40.31 57.26
768 bytes 25.25 39.76 57.32
771 bytes 25.26 40.33 57.06
1021 bytes 49.27 57.00 63.73
1024 bytes 49.33 57.09 63.70
1027 bytes 49.07 57.25 63.70
1533 bytes 50.11 58.98 70.57
1536 bytes 50.09 59.30 70.22
1539 bytes 50.18 59.27 70.35
2045 bytes 50.44 59.42 74.31
2048 bytes 50.33 59.29 75.31
2051 bytes 50.32 59.14 74.02
3069 bytes 62.71 64.20 96.87
3072 bytes 62.78 64.94 96.84
3075 bytes 62.83 65.13 96.62
4093 bytes 62.56 64.78 99.63
4096 bytes 62.46 65.04 99.54
4099 bytes 62.47 65.87 99.65
6141 bytes 63.35 65.39 104.03
6144 bytes 63.59 66.16 104.66
6147 bytes 63.74 66.04 104.61
8189 bytes 63.65 66.52 107.75
8192 bytes 63.64 66.71 108.17
8195 bytes 63.66 67.08 109.11
12285 bytes 63.26 84.58 114.13
12288 bytes 63.28 85.38 114.55
12291 bytes 63.22 83.71 114.40
16381 bytes 62.87 98.19 120.48
16384 bytes 63.12 97.96 122.19
16387 bytes 63.48 98.48 121.68
24573 bytes 93.26 108.93 152.67
24576 bytes 94.40 109.42 152.14
24579 bytes 93.37 108.86 153.51
32765 bytes 102.84 115.46 169.04
32768 bytes 100.01 114.62 166.19
32771 bytes 102.61 115.97 167.96
49149 bytes 125.46 144.78 209.99
49152 bytes 123.76 139.70 187.17
49155 bytes 125.13 137.97 185.44
--
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: All kernels after 2.6.32-git10 show only 1 CPU
http://groups.google.com/group/linux.kernel/t/de8e3e045599a528?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:00 am
From: Sid Boyce

On the 4P box, 2.6.32-git10 boots and shows 4 CPU's, 2.6.32-git12 boots
and shows 1 CPU, 2.6.32-git15 to 2.6.33-rc1-git3 1 CPU and lots of oops,
continues with something like "Sending NMI interrupts to CPU's",
[udev] unexpectedly returned with status 0x0100
[udev] failed while handling /devices/pci000:00 -----etc--- same for
other devices.
Unable to capture via serial console as USB doesn't come ready.

On 2P laptop, up to 2.6.33-rc1 boots, 1 CPU and boot option "acpi=noirq"
needed, without it boot hangs, I think from 2.6.32-git15.
Building kernels, I have used the .config from previous kernel and
"make oldconfig".

# uname -r
2.6.32-git12-smp
slipstream:~ # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 4
model name : AMD Phenom(tm) II X4 940 Processor
stepping : 2
cpu MHz : 3013.597
cache size : 512 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc up rep_good nonstop_tsc
pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips : 6027.18
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

# uname -r
2.6.32-git10-smp

# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 4
model name : AMD Phenom(tm) II X4 940 Processor
stepping : 2
cpu MHz : 3013.774
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips : 6027.53
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor : 1
vendor_id : AuthenticAMD
cpu family : 16
model : 4
model name : AMD Phenom(tm) II X4 940 Processor
stepping : 2
cpu MHz : 3013.774
cache size : 512 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good
nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips : 6027.27
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

etc., up to processor 4.

On a 2P laptop
===============
tindog:~ # uname -r
2.6.33-rc1-smp

tindog:~ # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 67
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
stepping : 3
cpu MHz : 1000.000
cache size : 1024 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
rdtscp lm 3dnowext 3dnow up rep_good pni cx16 lahf_lm cmp_legacy svm
extapic cr8_legacy
bogomips : 2009.33
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

The .config for the 4P and 2.6.33-rc1-git3 attached.
Regards
Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

==============================================================================
TOPIC: Christmas Offer!!!
http://groups.google.com/group/linux.kernel/t/41f1e90a5576cfac?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:20 am
From: THE NATIONAL

You've been award 390,000.00GBP in The National Christmas Offer contact with Name:Address:Age:Sex:Telephone for claims.

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Wednesday, December 23, 2009

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

0 Comments:

Post a Comment

About Me

Previous Posts