twitter: linux.kernel - 25 new messages in 19 topics

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

Today's topics:

* tip tree - No irq handler for vector (irq -1) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ba330702ebed7edc?hl=en
* PROBLEM: reproducible crash KVM+nf_conntrack all recent 2.6 kernels - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/47449e73655133f0?hl=en
* jfs_dmap.[ch]: trivial typo fix: s/heigth/height/g - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c94b4d05eb48a454?hl=en
* tree-wide: trivial typo fixes: s/widht/width/g - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/298406deaa4a1192?hl=en
* mm/readahead.c: update the LRU positions of in-core pages, too - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/c3e8affbeb80ebe0?hl=en
* fs: add fincore(2) (mincore(2) for file descriptors) - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/125f9b81a336f668?hl=en
* imxfb: correct location of callbacks in suspend and resume - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/dd006ad4ee3cb300?hl=en
* hang on 2.6.33-rc4 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b860c165c70e891b?hl=en
* linux-next: add utrace tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
* sysctl clean up vm related variable declarations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6ace9fc4debea132?hl=en
* PCIE AER: PCI access remove spinlock protection in aer_inject - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/8b2def1d75dd917d?hl=en
* [PATCH]Change the AZX_MAX_PCMS to 10 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/077e108221e106f7?hl=en
* 2.6.32.5 regression: page allocation failure. order:1, - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/a0015010e6b7ea14?hl=en
* x86: Disable HPET MSI on ATI SB700/SB800 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7ab0ecc4119ae78c?hl=en
* bio too big - in nested raid setup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/67c6a33e58948687?hl=en
* perf_event: circular lock dependency - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/1239a9c16a6fa388?hl=en
* PROBLEM: reproducible crash KVM+nf_conntrack all recent 2.6 kernels - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/b7334ab84a84dcdb?hl=en
* [ARM] perfevents: Event description for ARMv6, Cortex-A8 and Cortex-A9
exported - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/28fcaffa09dfe285?hl=en
* Human readable platform-specific performance event support - 3 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e025bcba6c770351?hl=en

==============================================================================
TOPIC: tip tree - No irq handler for vector (irq -1)
http://groups.google.com/group/linux.kernel/t/ba330702ebed7edc?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 12:00 am
From: Li Zefan

After bootup, I can't use my keyboard and mouse.

Here's the full syslog:

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.33-rc5-tip+ (lizf@localhost.localdomain) (gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) ) #30 SMP Thu Jan 28 14:50:38 CST 2010
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003bff0000 (usable)
BIOS-e820: 000000003bff0000 - 000000003bff3000 (ACPI NVS)
BIOS-e820: 000000003bff3000 - 000000003c000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Notice: NX (Execute Disable) protection missing in CPU or disabled in BIOS!
DMI 2.3 present.
Phoenix BIOS detected: BIOS may corrupt low RAM, working around it.
e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
last_pfn = 0x3bff0 max_arch_pfn = 0x1000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-BFFFF uncachable
C0000-C7FFF write-protect
C8000-FFFFF uncachable
MTRR variable ranges enabled:
0 base 000000000 mask FC0000000 write-back
1 base 03C000000 mask FFC000000 uncachable
2 base 0D0000000 mask FF8000000 write-combining
3 disabled
4 disabled
5 disabled
6 disabled
7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
initial memory mapped : 0 - 01600000
found SMP MP-table at [c00f5ad0] f5ad0
init_memory_mapping: 0000000000000000-0000000037bfe000
0000000000 - 0000200000 page 4k
0000200000 - 0037a00000 page 2M
0037a00000 - 0037bfe000 page 4k
kernel direct mapping tables up to 37bfe000 @ 15000-1a000
RAMDISK: 37d1a000 - 37fef2e1
Allocated new RAMDISK: 00100000 - 003d52e1
Move RAMDISK from 0000000037d1a000 - 0000000037fef2e0 to 00100000 - 003d52e0
ACPI: RSDP 000f7560 00014 (v00 AWARD )
ACPI: RSDT 3bff3040 0002C (v01 AWARD AWRDACPI 42302E31 AWRD 00000000)
ACPI: FACP 3bff30c0 00074 (v01 AWARD AWRDACPI 42302E31 AWRD 00000000)
ACPI: DSDT 3bff3180 03ABC (v01 AWARD AWRDACPI 00001000 MSFT 0100000E)
ACPI: FACS 3bff0000 00040
ACPI: APIC 3bff6c80 00084 (v01 AWARD AWRDACPI 42302E31 AWRD 00000000)
ACPI: Local APIC address 0xfee00000
67MB HIGHMEM available.
891MB LOWMEM available.
mapped low ram: 0 - 37bfe000
low ram: 0 - 37bfe000
node 0 low ram: 00000000 - 37bfe000
node 0 bootmap 00016000 - 0001cf80
(14 early reservations) ==> bootmem [0000000000 - 0037bfe000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000]
#2 [0000400000 - 0001188a1c] TEXT DATA BSS ==> [0000400000 - 0001188a1c]
#3 [0001189000 - 00011940ed] BRK ==> [0001189000 - 00011940ed]
#4 [00000f5ae0 - 0000100000] BIOS reserved ==> [00000f5ae0 - 0000100000]
#5 [00000f5ad0 - 00000f5ae0] MP-table mpf ==> [00000f5ad0 - 00000f5ae0]
#6 [000009f400 - 00000f0c00] BIOS reserved ==> [000009f400 - 00000f0c00]
#7 [00000f0d0c - 00000f5ad0] BIOS reserved ==> [00000f0d0c - 00000f5ad0]
#8 [00000f0c00 - 00000f0d0c] MP-table mpc ==> [00000f0c00 - 00000f0d0c]
#9 [0000010000 - 0000011000] TRAMPOLINE ==> [0000010000 - 0000011000]
#10 [0000011000 - 0000015000] ACPI WAKEUP ==> [0000011000 - 0000015000]
#11 [0000015000 - 0000016000] PGTABLE ==> [0000015000 - 0000016000]
#12 [0000100000 - 00003d52e1] NEW RAMDISK ==> [0000100000 - 00003d52e1]
#13 [0000016000 - 000001d000] BOOTMAP ==> [0000016000 - 000001d000]
Zone PFN ranges:
DMA 0x00000010 -> 0x00001000
Normal 0x00001000 -> 0x00037bfe
HighMem 0x00037bfe -> 0x0003bff0
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000010 -> 0x0000009f
0: 0x00000100 -> 0x0003bff0
On node 0 totalpages: 245631
free_area_init_node: node 0, pgdat c09ef980, node_mem_map c1196200
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 3951 pages, LIFO batch:0
Normal zone: 1752 pages used for memmap
Normal zone: 222502 pages, LIFO batch:31
HighMem zone: 136 pages used for memmap
HighMem zone: 17258 pages, LIFO batch:3
Using APIC driver default
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 4 CPUs, 2 hotplug CPUs
nr_irqs_gsi: 24
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 3c000000 (gap: 3c000000:c2c00000)
setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Embedded 334 pages/cpu @c1a00000 s1346324 r0 d21740 u2097152
pcpu-alloc: s1346324 r0 d21740 u2097152 alloc=1*2097152
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 243711
Kernel command line: ro root=UUID=355bca51-980f-47e8-93ad-16ed4d633479 rhgb quiet ftrace=nop
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
allocated 4914560 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Initializing HighMem for node 0 (00037bfe:0003bff0)
Memory: 946520k/982976k available (4141k kernel code, 35512k reserved, 2043k data, 1832k init, 69576k highmem)
virtual kernel memory layout:
fixmap : 0xfff1b000 - 0xfffff000 ( 912 kB)
pkmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0xf83fe000 - 0xffbfe000 ( 120 MB)
lowmem : 0xc0000000 - 0xf7bfe000 ( 891 MB)
.init : 0xc0a0b000 - 0xc0bd5000 (1832 kB)
.data : 0xc080b5ff - 0xc0a0a458 (2043 kB)
.text : 0xc0400000 - 0xc080b5ff (4141 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
SLUB: Genslabs=13, HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:384
Console: colour VGA+ 80x25
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 3823 kB
per task-struct memory footprint: 1920 bytes
Fast TSC calibration using PIT
Detected 2800.014 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 5600.02 BogoMIPS (lpj=2800014)
Mount-cache hash table entries: 512
Initializing cgroup subsys debug
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Initializing cgroup subsys blkio
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 4 MCE banks
CPU0: Thermal monitoring enabled (TM1)
using mwait in idle threads.
Performance Events: no PMU driver, software events only.
Checking 'hlt' instruction... OK.
ACPI: Core revision 20091214
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 17486 entries in 35 pages
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Pentium(R) D CPU 2.80GHz stepping 04
Testing tracer nop: PASSED
Starting tracer 'nop'
Disabling FTRACE selftests due to running tracer 'nop'
lockdep: fixing up alternatives.
Booting Node 0, Processors #1
Initializing CPU#1
do_IRQ: 1.48 No irq handler for vector (irq -1)
Brought up 2 CPUs
Total of 2 processors activated (11199.29 BogoMIPS).
Time: 7:41:58 Date: 01/28/10
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfbda0, last bus=1
PCI: Using configuration type 1 for base access
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
bio: create slab <bio-0> at 0
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci_root PNP0A03:00: ignoring host bridge windows from ACPI; boot with "pci=use_crs" to use them
pci_root PNP0A03:00: host bridge window [io 0x0000-0x047f] (ignored)
pci_root PNP0A03:00: host bridge window [io 0x0490-0x0cf7] (ignored)
pci_root PNP0A03:00: host bridge window [io 0x0d00-0x0fff] (ignored)
pci_root PNP0A03:00: host bridge window [io 0x1100-0xffff] (ignored)
pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored)
pci_root PNP0A03:00: host bridge window [mem 0x3c000000-0xfebfffff] (ignored)
pci 0000:00:00.0: reg 10: [mem 0xd0000000-0xd7ffffff]
pci 0000:00:02.5: reg 10: [io 0x01f0-0x01f7]
pci 0000:00:02.5: reg 14: [io 0x03f4-0x03f7]
pci 0000:00:02.5: reg 18: [io 0x0170-0x0177]
pci 0000:00:02.5: reg 1c: [io 0x0374-0x0377]
pci 0000:00:02.5: reg 20: [io 0x4000-0x400f]
pci 0000:00:02.5: PME# supported from D3cold
pci 0000:00:02.5: PME# disabled
pci 0000:00:02.7: reg 10: [io 0xd000-0xd0ff]
pci 0000:00:02.7: reg 14: [io 0xd400-0xd47f]
pci 0000:00:02.7: supports D1 D2
pci 0000:00:02.7: PME# supported from D3hot D3cold
pci 0000:00:02.7: PME# disabled
pci 0000:00:03.0: reg 10: [mem 0xe1104000-0xe1104fff]
pci 0000:00:03.1: reg 10: [mem 0xe1100000-0xe1100fff]
pci 0000:00:03.2: reg 10: [mem 0xe1101000-0xe1101fff]
pci 0000:00:03.3: reg 10: [mem 0xe1102000-0xe1102fff]
pci 0000:00:03.3: PME# supported from D0 D3hot D3cold
pci 0000:00:03.3: PME# disabled
pci 0000:00:05.0: reg 10: [io 0xd800-0xd807]
pci 0000:00:05.0: reg 14: [io 0xdc00-0xdc03]
pci 0000:00:05.0: reg 18: [io 0xe000-0xe007]
pci 0000:00:05.0: reg 1c: [io 0xe400-0xe403]
pci 0000:00:05.0: reg 20: [io 0xe800-0xe80f]
pci 0000:00:05.0: PME# supported from D3cold
pci 0000:00:05.0: PME# disabled
pci 0000:00:0e.0: reg 10: [io 0xec00-0xecff]
pci 0000:00:0e.0: reg 14: [mem 0xe1103000-0xe11030ff]
pci 0000:00:0e.0: reg 30: [mem 0x00000000-0x0001ffff pref]
pci 0000:00:0e.0: supports D1 D2
pci 0000:00:0e.0: PME# supported from D1 D2 D3hot D3cold
pci 0000:00:0e.0: PME# disabled
pci 0000:01:00.0: reg 10: [mem 0xd8000000-0xdfffffff pref]
pci 0000:01:00.0: reg 14: [mem 0xe1000000-0xe101ffff]
pci 0000:01:00.0: reg 18: [io 0xc000-0xc07f]
pci 0000:01:00.0: supports D1 D2
pci 0000:00:01.0: PCI bridge to [bus 01-01]
pci 0000:00:01.0: bridge window [io 0xc000-0xcfff]
pci 0000:00:01.0: bridge window [mem 0xe1000000-0xe10fffff]
pci 0000:00:01.0: bridge window [mem 0xd8000000-0xdfffffff pref]
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 14 15)
do_IRQ: 1.58 No irq handler for vector (irq -1)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 14 15)
do_IRQ: 1.59 No irq handler for vector (irq -1)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 *6 7 9 10 11 14 15)
do_IRQ: 1.54 No irq handler for vector (irq -1)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 14 15)
do_IRQ: 1.53 No irq handler for vector (irq -1)
vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: pci_cache_line_size set to 64 bytes
Switching to clocksource tsc
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
system 00:00: [mem 0x000c8000-0x000cbfff] has been reserved
system 00:00: [mem 0x000f0000-0x000f7fff] could not be reserved
system 00:00: [mem 0x000f8000-0x000fbfff] could not be reserved
system 00:00: [mem 0x000fc000-0x000fffff] could not be reserved
system 00:00: [mem 0x3bff0000-0x3bffffff] could not be reserved
system 00:00: [mem 0xffff0000-0xffffffff] has been reserved
system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:00: [mem 0x00100000-0x3bfeffff] could not be reserved
system 00:00: [mem 0xffee0000-0xffefffff] has been reserved
system 00:00: [mem 0xfffe0000-0xfffeffff] has been reserved
system 00:00: [mem 0xfec00000-0xfecfffff] could not be reserved
system 00:00: [mem 0xfee00000-0xfeefffff] has been reserved
system 00:02: [io 0x04d0-0x04d1] has been reserved
system 00:02: [io 0x0800-0x0805] has been reserved
system 00:02: [io 0x0290-0x0297] has been reserved
system 00:02: [io 0x0880-0x088f] has been reserved
pci 0000:00:0e.0: BAR 6: assigned [mem 0x3c000000-0x3c01ffff pref]
pci 0000:00:01.0: PCI bridge to [bus 01-01]
pci 0000:00:01.0: bridge window [io 0xc000-0xcfff]
pci 0000:00:01.0: bridge window [mem 0xe1000000-0xe10fffff]
pci 0000:00:01.0: bridge window [mem 0xd8000000-0xdfffffff pref]
pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffffffffffff]
pci_bus 0000:01: resource 0 [io 0xc000-0xcfff]
pci_bus 0000:01: resource 1 [mem 0xe1000000-0xe10fffff]
pci_bus 0000:01: resource 2 [mem 0xd8000000-0xdfffffff pref]
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 9, 2621440 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 3, 49152 bytes)
UDP-Lite hash table entries: 512 (order: 3, 49152 bytes)
NET: Registered protocol family 1
pci 0000:01:00.0: Boot video device
PCI: CLS 32 bytes, default 64
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 2900k freed
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: disabled - APM is not SMP safe.
highmem bounce pool size: 64 pages
HugeTLB registered 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 1719
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
pci-stub: invalid id string ""
input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1
ACPI: Sleep Button [FUTS]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
ACPI: Power Button [PWRF]
ACPI: Fan [FAN] (on)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
agpgart-sis 0000:00:00.0: SiS chipset [1039/0661]
agpgart-sis 0000:00:00.0: AGP aperture is 128M @ 0xd0000000
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
do_IRQ: 1.52 No irq handler for vector (irq -1)
do_IRQ: 1.52 No irq handler for vector (irq -1)
serial8250: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
do_IRQ: 1.51 No irq handler for vector (irq -1)
do_IRQ: 1.51 No irq handler for vector (irq -1)
serial8250: ttyS1 at I/O 0x2f8 (irq = 0) is a 16550A
00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
brd: module loaded
loop: module loaded
Fixed MDIO Bus: probed
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:03.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:03.3: EHCI Host Controller
ehci_hcd 0000:00:03.3: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:03.3: irq 23, io mem 0xe1102000
ehci_hcd 0000:00:03.3: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.33-rc5-tip+ ehci_hcd
usb usb1: SerialNumber: 0000:00:03.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:03.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
ohci_hcd 0000:00:03.0: OHCI Host Controller
ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:03.0: irq 20, io mem 0xe1104000
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.33-rc5-tip+ ohci_hcd
usb usb2: SerialNumber: 0000:00:03.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:00:03.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
ohci_hcd 0000:00:03.1: OHCI Host Controller
ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:03.1: irq 21, io mem 0xe1100000
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.33-rc5-tip+ ohci_hcd
usb usb3: SerialNumber: 0000:00:03.1
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
ohci_hcd 0000:00:03.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
ohci_hcd 0000:00:03.2: OHCI Host Controller
ohci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 4
ohci_hcd 0000:00:03.2: irq 22, io mem 0xe1101000
usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: OHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.33-rc5-tip+ ohci_hcd
usb usb4: SerialNumber: 0000:00:03.2
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
do_IRQ: 1.60 No irq handler for vector (irq -1)
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
rtc_cmos 00:04: RTC can wake from S4
rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year, 242 bytes nvram
device-mapper: ioctl: 4.16.0-ioctl (2009-11-05) initialised: dm-devel@redhat.com
cpuidle: using governor ladder
cpuidle: using governor menu
nf_conntrack version 0.5.0 (14842 buckets, 59368 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Using IPI No-Shortcut mode
PM: Resume from disk failed.
registered taskstats version 1
Testing kprobe tracing: OK
kmemleak: Kernel memory leak detector initialized
kmemleak: Automatic memory scanning thread started
Magic number: 10:944:673
Initalizing network drop monitor service
Freeing unused kernel memory: 1832k freed
Write protecting the kernel text: 4144k
Write protecting the kernel read-only data: 1572k
pata_sis 0000:00:02.5: version 0.5.2
pata_sis 0000:00:02.5: PCI INT A -> GSI 16 (level, low) -> IRQ 16
scsi0 : pata_sis
scsi1 : pata_sis
ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0x4000 irq 14
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x4008 irq 15
sata_sis 0000:00:05.0: version 1.0
sata_sis 0000:00:05.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
sata_sis 0000:00:05.0: Detected SiS 180/181/964 chipset in SATA mode
scsi2 : sata_sis
scsi3 : sata_sis
ata3: SATA max UDMA/133 cmd 0xd800 ctl 0xdc00 bmdma 0xe800 irq 17
ata4: SATA max UDMA/133 cmd 0xe000 ctl 0xe400 bmdma 0xe808 irq 17
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ATA-7: ST3808110AS, 3.AAE, max UDMA/133
ata3.00: 156301488 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata3.00: configured for UDMA/133
scsi 2:0:0:0: Direct-Access ATA ST3808110AS 3.AA PQ: 0 ANSI: 5
sd 2:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 < sda5 sda6 sda7 sda8 >
sd 2:0:0:0: [sda] Attached SCSI disk
sd 2:0:0:0: Attached scsi generic sg0 type 0
ata4: SATA link down (SStatus 0 SControl 300)
kjournald starting. Commit interval 5 seconds
EXT3-fs (sda5): mounted filesystem with writeback data mode
udev: starting version 141
parport_pc 00:09: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
input: PC Speaker as /devices/platform/pcspkr/input/input3
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:0e.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
r8169 0000:00:0e.0: no PCI Express capability
eth0: RTL8110s at 0xf862a000, 00:16:ec:2e:b7:e0, XID 04000000 IRQ 18
do_IRQ: 3 callbacks suppressed
do_IRQ: 1.56 No irq handler for vector (irq -1)
ppdev: user-space parallel port driver
md: md0 stopped.
md: bind<sda6>
md: linear personality registered for level -1
md0: detected capacity change from 0 to 15726608384
md0: unknown partition table
device-mapper: multipath: version 1.1.1 loaded
EXT3-fs (sda5): using internal journal
kjournald starting. Commit interval 5 seconds
EXT3-fs (sda7): using internal journal
EXT3-fs (sda7): mounted filesystem with writeback data mode
Adding 1048564k swap on /dev/sda8. Priority:-1 extents:1 across:1048564k
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ip6_tables: (C) 2000-2006 Netfilter Core Team
r8169: eth0: link up
r8169: eth0: link up
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
do_IRQ: 1.52 No irq handler for vector (irq -1)
do_IRQ: 1.52 No irq handler for vector (irq -1)
do_IRQ: 1.51 No irq handler for vector (irq -1)
do_IRQ: 1.51 No irq handler for vector (irq -1)
eth0: no IPv6 routers present

--
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: PROBLEM: reproducible crash KVM+nf_conntrack all recent 2.6 kernels
http://groups.google.com/group/linux.kernel/t/47449e73655133f0?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 12:10 am
From: Jon Masters

On Thu, 2010-01-28 at 02:20 -0500, Jon Masters wrote:
> On Thu, 2010-01-28 at 00:46 -0500, Jon Masters wrote:
>
> > A number of people seem to have reported this crash in various forms,
> > but I have yet to see a solution, and can reproduce on 2.6.33-rc5 this
> > evening so I know it's still present in the latest upstream kernels too.
> > Userspace is Fedora 12, and this happens on both all recent F12 kernels
> > (sporadic in 2.6.31 until recently, solidly reproducible on 2.6.32) and
> > upstream 2.6.32, and 2.6.33-rc5 also - hard to find a "known good".
> >
> > The problem happens when using netfilter with KVM (problem does not
> > occur without the firewall loaded, for example) and will occur within a
> > few minutes of attempting to start or stop a guest that is connecting to
> > the network - the easiest way to reproduce so far is simply to start up
> > a bunch of Fedora guests and have them do a "yum update" cycle.
> >
> > All of the crashes appear similar to the following (2.6.33-rc5):
>
> Rebuilt the kernel with all debug options turned on, got some lockdep
> warnings (haven't looked further yet). Here's the output (attached full
> boot log also):

> [ 339.730086] RIP: 0010:[<ffffffff813e5f3e>] [<ffffffff813e5f3e>]
> nf_ct_remove_expectations+0x49/0x5c

This appears to be in the hlist_for_each_entry_safe iteration within
nf_ct_remove_expectations, iterating over the list of nf_conn_help(ers)
returned by nfct_help. I don't know what that code does (I have an idea
but only at a high level at this stage), though I'm poking a little here
to see if I can understand enough of netfilter to be useful. Feel free
to give me some pointers to help you guys debug this faster.

Jon.

==============================================================================
TOPIC: jfs_dmap.[ch]: trivial typo fix: s/heigth/height/g
http://groups.google.com/group/linux.kernel/t/c94b4d05eb48a454?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 12:20 am
From: Daniel Mack

Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Jiri Kosina <trivial@kernel.org>
Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Cc: André Goddard Rosa <andre.goddard@gmail.com>
Cc: jfs-discussion@lists.sourceforge.net
---
fs/jfs/jfs_dmap.c | 16 ++++++++--------
fs/jfs/jfs_dmap.h | 6 +++---
2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index d9b031c..7e19d2f 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -195,7 +195,7 @@ int dbMount(struct inode *ipbmap)
bmp->db_maxag = le32_to_cpu(dbmp_le->dn_maxag);
bmp->db_agpref = le32_to_cpu(dbmp_le->dn_agpref);
bmp->db_aglevel = le32_to_cpu(dbmp_le->dn_aglevel);
- bmp->db_agheigth = le32_to_cpu(dbmp_le->dn_agheigth);
+ bmp->db_agheight = le32_to_cpu(dbmp_le->dn_agheight);
bmp->db_agwidth = le32_to_cpu(dbmp_le->dn_agwidth);
bmp->db_agstart = le32_to_cpu(dbmp_le->dn_agstart);
bmp->db_agl2size = le32_to_cpu(dbmp_le->dn_agl2size);
@@ -287,7 +287,7 @@ int dbSync(struct inode *ipbmap)
dbmp_le->dn_maxag = cpu_to_le32(bmp->db_maxag);
dbmp_le->dn_agpref = cpu_to_le32(bmp->db_agpref);
dbmp_le->dn_aglevel = cpu_to_le32(bmp->db_aglevel);
- dbmp_le->dn_agheigth = cpu_to_le32(bmp->db_agheigth);
+ dbmp_le->dn_agheight = cpu_to_le32(bmp->db_agheight);
dbmp_le->dn_agwidth = cpu_to_le32(bmp->db_agwidth);
dbmp_le->dn_agstart = cpu_to_le32(bmp->db_agstart);
dbmp_le->dn_agl2size = cpu_to_le32(bmp->db_agl2size);
@@ -1440,7 +1440,7 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int l2nb, s64 * results)
* tree index of this allocation group within the control page.
*/
agperlev =
- (1 << (L2LPERCTL - (bmp->db_agheigth << 1))) / bmp->db_agwidth;
+ (1 << (L2LPERCTL - (bmp->db_agheight << 1))) / bmp->db_agwidth;
ti = bmp->db_agstart + bmp->db_agwidth * (agno & (agperlev - 1));

/* dmap control page trees fan-out by 4 and a single allocation
@@ -1459,7 +1459,7 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int l2nb, s64 * results)
* the subtree to find the leftmost leaf that describes this
* free space.
*/
- for (k = bmp->db_agheigth; k > 0; k--) {
+ for (k = bmp->db_agheight; k > 0; k--) {
for (n = 0, m = (ti << 2) + 1; n < 4; n++) {
if (l2nb <= dcp->stree[m + n]) {
ti = m + n;
@@ -3606,7 +3606,7 @@ void dbFinalizeBmap(struct inode *ipbmap)
}

/*
- * compute db_aglevel, db_agheigth, db_width, db_agstart:
+ * compute db_aglevel, db_agheight, db_width, db_agstart:
* an ag is covered in aglevel dmapctl summary tree,
* at agheight level height (from leaf) with agwidth number of nodes
* each, which starts at agstart index node of the smmary tree node
@@ -3615,9 +3615,9 @@ void dbFinalizeBmap(struct inode *ipbmap)
bmp->db_aglevel = BMAPSZTOLEV(bmp->db_agsize);
l2nl =
bmp->db_agl2size - (L2BPERDMAP + bmp->db_aglevel * L2LPERCTL);
- bmp->db_agheigth = l2nl >> 1;
- bmp->db_agwidth = 1 << (l2nl - (bmp->db_agheigth << 1));
- for (i = 5 - bmp->db_agheigth, bmp->db_agstart = 0, n = 1; i > 0;
+ bmp->db_agheight = l2nl >> 1;
+ bmp->db_agwidth = 1 << (l2nl - (bmp->db_agheight << 1));
+ for (i = 5 - bmp->db_agheight, bmp->db_agstart = 0, n = 1; i > 0;
i--) {
bmp->db_agstart += n;
n <<= 2;
diff --git a/fs/jfs/jfs_dmap.h b/fs/jfs/jfs_dmap.h
index 1a6eb41..6dcb906 100644
--- a/fs/jfs/jfs_dmap.h
+++ b/fs/jfs/jfs_dmap.h
@@ -210,7 +210,7 @@ struct dbmap_disk {
__le32 dn_maxag; /* 4: max active alloc group number */
__le32 dn_agpref; /* 4: preferred alloc group (hint) */
__le32 dn_aglevel; /* 4: dmapctl level holding the AG */
- __le32 dn_agheigth; /* 4: height in dmapctl of the AG */
+ __le32 dn_agheight; /* 4: height in dmapctl of the AG */
__le32 dn_agwidth; /* 4: width in dmapctl of the AG */
__le32 dn_agstart; /* 4: start tree index at AG height */
__le32 dn_agl2size; /* 4: l2 num of blks per alloc group */
@@ -229,7 +229,7 @@ struct dbmap {
int dn_maxag; /* max active alloc group number */
int dn_agpref; /* preferred alloc group (hint) */
int dn_aglevel; /* dmapctl level holding the AG */
- int dn_agheigth; /* height in dmapctl of the AG */
+ int dn_agheight; /* height in dmapctl of the AG */
int dn_agwidth; /* width in dmapctl of the AG */
int dn_agstart; /* start tree index at AG height */
int dn_agl2size; /* l2 num of blks per alloc group */
@@ -255,7 +255,7 @@ struct bmap {
#define db_agsize db_bmap.dn_agsize
#define db_agl2size db_bmap.dn_agl2size
#define db_agwidth db_bmap.dn_agwidth
-#define db_agheigth db_bmap.dn_agheigth
+#define db_agheight db_bmap.dn_agheight
#define db_agstart db_bmap.dn_agstart
#define db_numag db_bmap.dn_numag
#define db_maxlevel db_bmap.dn_maxlevel
--
1.6.3.3

==============================================================================
TOPIC: tree-wide: trivial typo fixes: s/widht/width/g
http://groups.google.com/group/linux.kernel/t/298406deaa4a1192?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 12:20 am
From: Daniel Mack

Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Jiri Kosina <trivial@kernel.org>
---
arch/m68k/include/asm/fbio.h | 2 +-
arch/sparc/include/asm/fbio.h | 2 +-
drivers/net/skfp/ess.c | 2 +-
drivers/video/68328fb.c | 2 +-
drivers/video/pm2fb.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/m68k/include/asm/fbio.h b/arch/m68k/include/asm/fbio.h
index b9215a0..0a21da8 100644
--- a/arch/m68k/include/asm/fbio.h
+++ b/arch/m68k/include/asm/fbio.h
@@ -173,7 +173,7 @@ struct mdi_cfginfo {
int mdi_ncluts; /* Number of implemented CLUTs in this MDI */
int mdi_type; /* FBTYPE name */
int mdi_height; /* height */
- int mdi_width; /* widht */
+ int mdi_width; /* width */
int mdi_size; /* available ram */
int mdi_mode; /* 8bpp, 16bpp or 32bpp */
int mdi_pixfreq; /* pixel clock (from PROM) */
diff --git a/arch/sparc/include/asm/fbio.h b/arch/sparc/include/asm/fbio.h
index b9215a0..0a21da8 100644
--- a/arch/sparc/include/asm/fbio.h
+++ b/arch/sparc/include/asm/fbio.h
@@ -173,7 +173,7 @@ struct mdi_cfginfo {
int mdi_ncluts; /* Number of implemented CLUTs in this MDI */
int mdi_type; /* FBTYPE name */
int mdi_height; /* height */
- int mdi_width; /* widht */
+ int mdi_width; /* width */
int mdi_size; /* available ram */
int mdi_mode; /* 8bpp, 16bpp or 32bpp */
int mdi_pixfreq; /* pixel clock (from PROM) */
diff --git a/drivers/net/skfp/ess.c b/drivers/net/skfp/ess.c
index a85efcf..e8387d2 100644
--- a/drivers/net/skfp/ess.c
+++ b/drivers/net/skfp/ess.c
@@ -557,7 +557,7 @@ static void ess_send_alc_req(struct s_smc *smc)

/*
* send never allocation request where the requested payload and
- * overhead is zero or deallocate bandwidht when no bandwidth is
+ * overhead is zero or deallocate bandwidth when no bandwidth is
* parsed
*/
if (!smc->mib.fddiESSPayload) {
diff --git a/drivers/video/68328fb.c b/drivers/video/68328fb.c
index 0b17824..2110556 100644
--- a/drivers/video/68328fb.c
+++ b/drivers/video/68328fb.c
@@ -308,7 +308,7 @@ static int mc68x328fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
* Pseudocolor:
* uses offset = 0 && length = RAMDAC register width.
* var->{color}.offset is 0
- * var->{color}.length contains widht of DAC
+ * var->{color}.length contains width of DAC
* cmap is not used
* RAMDAC[X] is programmed to (red, green, blue)
* Truecolor:
diff --git a/drivers/video/pm2fb.c b/drivers/video/pm2fb.c
index 36436ee..27f93aa 100644
--- a/drivers/video/pm2fb.c
+++ b/drivers/video/pm2fb.c
@@ -896,7 +896,7 @@ static int pm2fb_setcolreg(unsigned regno, unsigned red, unsigned green,
* Pseudocolor:
* uses offset = 0 && length = DAC register width.
* var->{color}.offset is 0
- * var->{color}.length contains widht of DAC
+ * var->{color}.length contains width of DAC
* cmap is not used
* DAC[X] is programmed to (red, green, blue)
* Truecolor:
--
1.6.3.3

==============================================================================
TOPIC: mm/readahead.c: update the LRU positions of in-core pages, too
http://groups.google.com/group/linux.kernel/t/c3e8affbeb80ebe0?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 12:20 am
From: Minchan Kim

On Thu, Jan 28, 2010 at 4:16 PM, Steve VanDeBogart
<vandebo-lkml@nerdbox.net> wrote:
> On Wed, 27 Jan 2010, Minchan Kim wrote:
>
>> This patch effect happens when inactive file list is small, I think.
>> It means it's high memory pressure. so if we move ra pages into
>
> This patch does the same thing regardless of memory pressure - it
> doesn't just apply in high memory pressure situations. Is your concern
> that in high memory pressure situations this patch with make things worse?

Yes.

>
>> head of inactive list, other application which require free page urgently
>> suffer from latency or are killed.
>
> I don't think this patch will affect the number of pages reclaimed, only
> which pages are reclaimed. In extreme cases it could increase the time

Most likely.
But it can affect the number of pages reclaimed at sometime.

For example,

scanning window size for reclaim = 5.
P : hard reclaimable page
R : readaheaded page(easily reclaimable page)

without this patch
HEAD-P - P - P - P ................ - P - R -R -R -R -R- TAIL

reclaimed pages : 5

with this patch
HEAD-R-R-R-R-R .................... - P -P -P -P -P -P -TAIL

reclaimed pages : 0 => might be OOMed.

Yes. It's very extreme example.
it is just for explanation. :)

> needed to reclaim that many pages, but the inactive list would have to be
> very short.

I think short inactive list means now we are suffering from shortage of
free memory. So I think it would be better to discard ra pages rather than
OOMed.

>
>> If VM don't have this patch, of course ra pages are discarded and
>> then I/O performance would be bad. but as I mentioned, it's time
>> high memory pressure. so I/O performance low makes system
>> natural throttling. It can help out of system memory pressure.
>
> Even in low memory situations, improving I/O performance can help the
> overall system performance. For example if most of the inactive list is
> dirty, needlessly discarding pages, just to refetch them will clog
> I/O and increase the time needed to write out the dirty pages.

Yes. That's what I said.
But my point is that it makes system I/O throttling by clogging I/O naturally.
It can prevent fast consumption of memory.
Actually I think mm don't have to consider I/O throttling as far as possible.
It's role of I/O subsystem. but it's not real.
There are some codes for I/O throttling in mm.

>
>> In summary I think it's good about viewpoint of I/O but I am not sure
>> it's good about viewpoint of system.
>
> In this case, I think what's good for I/O is good for the system.
> Please help me understand if I am missing something. Thanks

You didn't missed anything. :)
I don't know how this patch affect in low memory situation.
What we just need is experiment which is valuable.

Wu have a catch in my concern and are making new version.
I am looking forward to that.

>
> --
> Steve
>

--
Kind regards,
Minchan Kim
--
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: fs: add fincore(2) (mincore(2) for file descriptors)
http://groups.google.com/group/linux.kernel/t/125f9b81a336f668?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jan 28 2010 12:30 am
From: Andrew Morton

On Wed, 27 Jan 2010 23:42:35 -0800 (PST) Steve VanDeBogart <vandebo-lkml@NerdBox.Net> wrote:

> > Is it likely that these changes to SQLite and Gimp would be merged into
> > the upstream applications?
>
> Changes to the GIMP fit nicely into the code structure, so it's feasible
> to push this kind of optimization upstream. The changes in SQLite are
> a bit more focused on the benchmark, but a more general approach is not
> conceptually difficult. SQLite may not want the added complexity, but
> other database may be interested in the performance improvement.
>
> Of course, these kernel changes are needed before any application can
> optimize its IO as we did with libprefetch.

That didn't really answer my question.

If there's someone signed up and motivated to do the hard work of
getting these changes integrated into the upstream applications then
that makes us more interested. If, however it was some weekend
proof-of-concept hack which shortly dies an instadeath then... meh,
not so much.

== 2 of 3 ==
Date: Thurs, Jan 28 2010 12:30 am
From: Steve VanDeBogart

On Wed, 27 Jan 2010, Jamie Lokier wrote:

> Chris Frost wrote:
>> We introduced this system call while modifying SQLite and the GIMP to
>> request large prefetches for what would otherwise be non-sequential reads.
>> As a macrobenchmark, we see a 125s SQLite query (72s system time) reduced
>> to 75s (18s system time) by using fincore() instead of mincore(). This
>> speedup of course varies by benchmark and benchmarks size; we've seen
>> both minimal speedups and 1000x speedups. More on these benchmarks in the
>> publication _Reducing Seek Overhead with Application-Directed Prefetching_
>> in USENIX ATC 2009 and at http://libprefetch.cs.ucla.edu/.
>
> My first thought was:
>
> Why is calling fincore() and then issuing reads better than simply
> calling readahead() on the same range? I.e. why is readahead() (or
> POSIX_FADV_WILLNEED) unsuitable to give the same result? Or even
> issuing lots of AIO requests.

A stupid example can illustrate the difference. If you have X bytes
of RAM, and have a file 10 X in size, reading the entire thing in
before accessing it will only hurt performance. (The same situation
where an MRU replacement policy can perform better then a strict LRU
policy.) In other words, using fincore helps the prefetching library
figure out how much to prefetch to optimize performance.

> I knew that I was missing something, so I read the paper ;-) I don't
> fully understand it, but *think* that it says fincore() is used to
> detect when the kernel is evicting pages faster than libprefetch had
> planned for, implying memory pressure, so it adjusts its planning in
> response.

In some sense, yes. At core, Libprefetch uses fincore to detect how much
memory can be used for prefetching. We can ask proc how much is
free and how much is in buffers, but memory use is dynamic, so
libprefetch must monitor it and react appropriately.

> Interesting idea, though I wonder if it wouldn't be even better to
> have a direct way to ask the kernel "tell me when there is memory
> pressure causing my file to be evicted".

Such an interface sounds fairly specialized. It's possible that it would
be more efficient for this particular purpose, but useless for other,
related, purposes. For example, if you want to backup a file without
polluting the buffer cache: before accessing each page of the file,
fincore that page, send it to the backup device, then restore the page
to its previous state with fadvise. fincore is obviously modelled on
mincore, which has stood the test of time as an interface. Even if you
don't like the mincore/fincore interface, you have to admit it can't be
that bad because no replacement interface has been accepted.

--
Steve
--
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: Thurs, Jan 28 2010 12:40 am
From: Steve VanDeBogart

On Thu, 28 Jan 2010, Andrew Morton wrote:

> On Wed, 27 Jan 2010 23:42:35 -0800 (PST) Steve VanDeBogart <vandebo-lkml@NerdBox.Net> wrote:
>
>>> Is it likely that these changes to SQLite and Gimp would be merged into
>>> the upstream applications?
>>
>> Changes to the GIMP fit nicely into the code structure, so it's feasible
>> to push this kind of optimization upstream. The changes in SQLite are
>> a bit more focused on the benchmark, but a more general approach is not
>> conceptually difficult. SQLite may not want the added complexity, but
>> other database may be interested in the performance improvement.
>>
>> Of course, these kernel changes are needed before any application can
>> optimize its IO as we did with libprefetch.
>
> That didn't really answer my question.
>
> If there's someone signed up and motivated to do the hard work of
> getting these changes integrated into the upstream applications then
> that makes us more interested. If, however it was some weekend
> proof-of-concept hack which shortly dies an instadeath then... meh,
> not so much.

Sorry I misunderstood. The maintainer of GraphicsMagick has already
contacted us about making changes similar to our GIMP changes. So yes,
there is interest in really using these changes.

==============================================================================
TOPIC: imxfb: correct location of callbacks in suspend and resume
http://groups.google.com/group/linux.kernel/t/dd006ad4ee3cb300?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 12:30 am
From: Andrew Morton

On Thu, 28 Jan 2010 08:41:01 +0100 Uwe Kleine-K__nig <u.kleine-koenig@pengutronix.de> wrote:

> > What were the runtime effects of this bug?
> For me it was that in the original imxfb_info *fbi backlight_power was
> NULL but in imxfb_suspend it was 4 resulting in an oops as imxfb_suspend
> calls imxfb_disable_controller(fbi) which in turn has
>
> if (fbi->backlight_power)
> fbi->backlight_power(0);

OK, thanks, that was important info.

I rescheduled the patch for 2.6.33 and marked it for 2.6.32.x backporting.
--
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: hang on 2.6.33-rc4
http://groups.google.com/group/linux.kernel/t/b860c165c70e891b?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 12:50 am
From: Norbert Preining

On Mi, 27 Jan 2010, reinette chatre wrote:
> > Should we move that to a bugzilla entry?
> >
>
> Please do. Thank you very much

Done that,
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2155

Should that be a bug in the kernel bugzilla as regression, too?
I mean 2.6.32.N does not suffer from that.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
OSHKOSH (n., vb.)
The noise made by someone who has just been grossly flattered and is
trying to make light of it.
--- Douglas Adams, The Meaning of Liff
--
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: linux-next: add utrace tree
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 1:00 am
From: Ingo Molnar

* Jim Keniston <jkenisto@us.ibm.com> wrote:

> On Wed, 2010-01-27 at 09:54 +0100, Ingo Molnar wrote:
> ...
> > I think the best solution for user probes (by far) is to use a simplified
> > in-kernel instruction emulator for the few common probes instruction. (Kprobes
> > already partially decodes x86 instructions to make it safe to apply
> > accelerated probes and there's other decoding logic in the kernel too.)
> >
> > The design and practical advantages are numerous:
> >
> > - People want to probe their function prologues most of the time ...
> > a single INT3 there will in most cases just hit the initial stack
> > allocation and that's it.
>
> Yes, emulating "push %ebp" would buy us a lot of coverage for a lot of apps
> on x86 (but see below**). [...]

Coverage in practice is all that matters.

Consider the fact that i get 1000 times more bugreports aided by strace, which
has 1000 times more overhead than even the slowest of uprobes approaches.

This simple fact tell us that while performance matters, it is of little use
if good utility and a clean design is not there. (in fact sane and clean
design will almost automatically result in good performance too down the line,
but i digress.) Faster crap is still crap.

> [...] Even there, though, we'd have to address the page fault we'd
> occasionally get when extending the stack vma.

Nope, in the simplest model not even page fault emulation is needed,
get_user()/put_user() would resolve it automatically. If you either get the
value with the pagefault resolved, or you get a -EFAULT.

If you concentrate only on the common case then emulation can be _really_
simple.

Lets compare the two cases via a drawing. Your current uprobes submission
does:

[kernel] do probe thing single-step trap
^ | ^ |
| v | v
[user] INT3 XOL-ins next ins-stream

( add the need for serialization to make sure the whole single-step thing
does not get out of sync with reality. )

And emulator approach would do:

[kernel] emul-demux-fastpath, do probe thing
^ |
| v
[user] INT3 next ins-stream

far simpler conceptually, and faster as well, because it's one kernel entry.

Generally i get nervous if a piece of instrumentation cannot be expressed in
simple ways. _Especially_ if i consider it to concentrate on all the wrong
things and doesnt even break even with a far less complex scheme.

What would be the 'right things' to concentrate on? Make sure it's all all
around end-to-end package that is _useful to people_. As of today i have yet
to get a _single_ bugreport or kernel improvement requested by an application
writer who found out about the inefficiencies in his app using uprobes. There
is a gaping hole of utility here, a whole cathedral of tools written that just
a handful of ordinary Linux person uses. There's big disconnect and i can say
one thing for sure: needless complexity in the wrong places can outright
stiffle tools from becoming good.

> > We could get quite good coverage (and very fast
> > emulation) for the common case in not too much code - and much of that code
> > we already have available. No re-trapping,
>
> As previously discussed, boosting would also get rid of the single-step trap
> for most instructions.

Boosting is not in the uprobes patch-set you submitted. Even with it present
it wont get rid of the initial INT3. So basically _best-case_ (with boosting)
XOL-uprobes could roughly break even with a pure emulator approach ...

That's a big and fundamental difference.

> > no extra instruction patching
>
> x86_64 rip-relative instructions are the only ones we alter.
>
> > and complex maintenance of trampolines.
> >
> > - It's as transparent as it gets - no user-space trampoline or other visible
> > state that modifies behavior or can be stomped upon by user-space bugs.
>
> The XOL vma isn't writable from user space, so I can't think of how it could
> be clobbered merely by a stray memory reference. [...]

Well there must be some purpose to the instrumentation, there must be some way
to save data, right? If yes and it's in user-space, that data is clobberable.
If it's in kernel-space then we have to enter the kernel anyway (with similar
cost patterns to an INT3 entry) - so we just delayed the kernel entry.

So IMHO you have designed in considerable complexity for little immediate
benefit.

> [...] Yes, it's a vma that the unprobed app would never have; and yes, a
> malicious app or kernel module could remove it or alter the protection and
> scribble on it. We don't try to defend the app against such malicious
> attacks, but we do our best to ensure that the kernel side handles such
> attacks gracefully.
>
> > - Lightweight and simple probe insertion: no weird setup sequence needing the
> > stopping of all tasks to install the trampoline. We just add the INT3 and
> > off you go.
>
> FWIW, we don't stop all threads to set up or extend the XOL vma, which is
> typically a one-time event. We just grab a mutex, in case multiple threads
> hit previously-unhit probepoints simultaneously, and simultaneously decide
> that the XOL area needs to be created or extended.

Still it's more complex than purely local state. Plus slower than even a naive
emulator approach would be able to achieve, due to single-stepping.

> > - Emulation is evidently thread-safe, SMP-safe, etc. as it only acts on
> > task local state.
>
> The posted uprobes implementation is, so far as we can tell through code
> inspection and testing, also thread-safe and SMP-safe.
>
> >
> > - The points we can probe are never truly limited as it's all freely
> > upscalable: if you cannot probe an instruction you want to probe today,
> > extend the emulator.
>
> I don't see how ripping out existing support for almost* the entire
> instruction set, and then putting it back instruction by instruction, patch
> by patch, is a win.

IMO it's a win because it's more controlled in what we can and cannot do
safely, and because it's more transparent to the probed context.

But by far the most important aspect is that it should be far less code with
far less complexity, and hence much more graceful from an upstream POV.

Gradual concepts with easy ways forwards/backwards are good. All-or-nothing
frameworks are bad.

> Even if we add emulation, it seems sensible to keep the XOL approach as a
> backup to handle instructions that aren't yet emulated (and architectures
> that don't yet have emulators). That way, if you don't probe any unemulated
> instructions, the XOL vma is never created.

To turn the argument around: an in-kernel emulator is an all-around facility
to make sure we probe safely and securely, _and_ it is also more portable
because it's simpler (because more gradual) to implement on a new architecture
as you dont actually have to copy around instructions (and make sure they work
in that new place), but have to emulate a limited subset of the instruction
space, on purely local state.

There are far less things that can go wrong in such a model.

> > Deny the rest. _All_ versions of uprobes code i've
> > seen so far already restricts the probe-compatible instruction set:
>
> *Yes, we currently decline to probe some instructions that look troublesome
> and we haven't taken the time to test. These include things like privileged
> instructions, int*, in*/out*, and instructions that fuss with the segment
> registers. We've never actually seen such instructions in user apps.
>
>
> > RIP-relative instructions are excluded on 64-bit for example.
>
> No. As discussed in previous posts, we handle rip-relative
> instructions.
>
> >
> > - Emulation has the _least_ semantical side effects as we really execute
> > 'that' instruction -
>
> It seems to me that emulation is the only approach that DOESN'T execute the
> probed instruction.

None of the approaches executes _that_ instruction in _that_ place - the
instruction is either replaced by an INT3 or by a jump-to-trampoline
instruction.

They may execute the same instruction but in another place.

With an emulator (assuming the emulator is correct) we can execute the precise
semantics of that instruction in that place - without any side-effects from
trampolining/replacement.

> > not some other instruction put elsewhere into a
> > special vma or into the process/thread stack, or some special in-kernel
> > trampoline, etc.
> >
> > - Emulation can be very fast for the common case as well. Nobody will probe
> > weird, complex instructions. They will use 'perf probe' to insert probes
> > into their functions 90% of the time ...
> >
> > - FPU and complex ops and pagefault emulation is not really what i'd expect
> > to be necessary for simple probing - but it _can_ be added by people who
> > care about it, if they so wish.
>
> **In practice, we've had to probe all sorts of instructions, including FP
> instructions -- especially where you want to exploit the debug info to get
> the names, types, and locations of variables and args. For some compilers
> and architectures, the debug info isn't reliable until the end of the
> function prologue, at which point you could find any old instruction. Ditto
> if you want to probe statements within a function.

For those cases, frankly, the right approach is to fix the debug info (or
introduce a new one) and forget the old crap.

You treat debuginfo as some god-given property, while it's one of the suckiest
aspects of all of Linux. But we've had that discussion months (and years) ago.
It has improved in gcc 4.5 so there's some hope.

> > Such a scheme would be _far_ more preferable form a maintenance POV as
> > well, as the initial code will be small, and we can extend it gradually.
> > All the other proposals are complex 'all or nothing' schemes with no
> > flexibility for complexity at all.

I repeat this point. To be able to scale in and out of a design is rather
important, and i dont see that with the current XOL proposal.

Ingo
--
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: sysctl clean up vm related variable declarations
http://groups.google.com/group/linux.kernel/t/6ace9fc4debea132?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 28 2010 1:00 am
From: David Rientjes

On Wed, 27 Jan 2010, KAMEZAWA Hiroyuki wrote:

> Now, there are many "extern" declaration in kernel/sysctl.c. "extern"
> declaration in *.c file is not appreciated in general.
> And Hmm...it seems there are a few redundant declarations.
>

sysctl_overcommit_memory and sysctl_overcommit_ratio, right?

> Because most of sysctl variables are defined in its own header file,
> they should be declared in the same style, be done in its own *.h file.
>
> This patch removes some VM(memory management) related sysctl's
> variable declaration from kernel/sysctl.c and move them to
> proper places.
>
> Change log:
> - 2010/01/27 (new)
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

This is a very nice cleanup of the sysctl code, I hope you find the time
to push it regardless of the future direction of the oom killer lowmem
constraint.

One comment below.

> ---
> include/linux/mm.h | 5 +++++
> include/linux/mmzone.h | 1 +
> include/linux/oom.h | 5 +++++
> kernel/sysctl.c | 16 ++--------------
> mm/mmap.c | 5 +++++
> 5 files changed, 18 insertions(+), 14 deletions(-)
>
> Index: mmotm-2.6.33-Jan15-2/include/linux/mm.h
> ===================================================================
> --- mmotm-2.6.33-Jan15-2.orig/include/linux/mm.h
> +++ mmotm-2.6.33-Jan15-2/include/linux/mm.h
> @@ -1432,6 +1432,7 @@ int in_gate_area_no_task(unsigned long a
> #define in_gate_area(task, addr) ({(void)task; in_gate_area_no_task(addr);})
>

twitter

Thursday, January 28, 2010

linux.kernel - 25 new messages in 19 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts