* Re: [tip:perf/core] perf top: Introduce slang based TUI
From: Arnaldo Carvalho de Melo @ 2011-02-01 19:28 UTC (permalink / raw)
To: Yinghai Lu
Cc: mingo, hpa, paulus, eranian, linux-kernel, tzanussi, efault,
peterz, fweisbec, tglx, mingo, linux-tip-commits
In-Reply-To: <4D48562B.20006@kernel.org>
Em Tue, Feb 01, 2011 at 10:51:23AM -0800, Yinghai Lu escreveu:
> On 02/01/2011 01:20 AM, tip-bot for Arnaldo Carvalho de Melo wrote:
> > + slsmg_write_nstring(width >= syme->map->dso->long_name_len ?
> > + syme->map->dso->long_name :
> > + syme->map->dso->short_name, width);
>
>
> need update macro for that calling
>
> [PATCH] perf: fix compiling for perf top tui
>
> util/ui/browsers/top.c: In function ‘perf_top_browser__write’:
> util/ui/browsers/top.c:60:2: error: cast to pointer from integer of different size
> util/ui/browsers/top.c:60:2: error: comparison between pointer and integer
> util/ui/browsers/top.c:60:2: error: passing argument 1 of ‘SLsmg_write_nstring’ discards qualifiers from pointer target type
> /usr/include/slang.h:1728:16: note: expected ‘char *’ but argument is of type ‘const char *’
> make: *** [util/ui/browsers/top.o] Error 1
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Good catch, why I didn't got this here is a mistery... anyway, applying,
thanks,
- Arnaldo
> ---
> tools/perf/util/ui/libslang.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/tools/perf/util/ui/libslang.h
> ===================================================================
> --- linux-2.6.orig/tools/perf/util/ui/libslang.h
> +++ linux-2.6/tools/perf/util/ui/libslang.h
> @@ -13,11 +13,11 @@
>
> #if SLANG_VERSION < 20104
> #define slsmg_printf(msg, args...) \
> - SLsmg_printf((char *)msg, ##args)
> + SLsmg_printf((char *)(msg), ##args)
> #define slsmg_write_nstring(msg, len) \
> - SLsmg_write_nstring((char *)msg, len)
> + SLsmg_write_nstring((char *)(msg), len)
> #define sltt_set_color(obj, name, fg, bg) \
> - SLtt_set_color(obj,(char *)name, (char *)fg, (char *)bg)
> + SLtt_set_color(obj,(char *)(name), (char *)(fg), (char *)(bg))
> #else
> #define slsmg_printf SLsmg_printf
> #define slsmg_write_nstring SLsmg_write_nstring
^ permalink raw reply
* Re: [EDAC-AMD64] Display correct RAM sizes in ganged mode on F10 CPUs
From: Markus Trippelsdorf @ 2011-02-01 19:27 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-edac@vger.kernel.org, Petkov, Borislav, Doug Thompson,
linux-kernel@vger.kernel.org
In-Reply-To: <20110201185114.GD8418@aftab>
On 2011.02.01 at 19:51 +0100, Borislav Petkov wrote:
> On Sat, Jan 29, 2011 at 04:15:31PM -0500, Markus Trippelsdorf wrote:
> > The EDAC_AMD64 module displays only half the actual memory size, when
> > RAM is running in ganged mode on F10 CPUs. Fix this by moving the the
> > conversion factor check out of the if block, where it is never reached.
> >
> > With this patch:
> >
> > Unganged:
> > amd64: DRAM ECC enabled.
> > EDAC amd64: F10h detected (node 0).
> > EDAC amd64: using x4 syndromes.
> > EDAC MC: DCT0 chip selects:
> > kernel: EDAC amd64: MC: 0: 1024MB 1: 1024MB
> > kernel: EDAC amd64: MC: 2: 1024MB 3: 1024MB
> > kernel: EDAC amd64: MC: 4: 0MB 5: 0MB
> > kernel: EDAC amd64: MC: 6: 0MB 7: 0MB
> > kernel: EDAC MC: DCT1 chip selects:
> > kernel: EDAC amd64: MC: 0: 1024MB 1: 1024MB
> > kernel: EDAC amd64: MC: 2: 1024MB 3: 1024MB
> > kernel: EDAC amd64: MC: 4: 0MB 5: 0MB
> > kernel: EDAC amd64: MC: 6: 0MB 7: 0MB
> > kernel: EDAC amd64: MCT channel count: 2
>
> Hmm, can you send me your whole dmesg without your patch, dmidecode
> output and the exact model of your DIMMs.
Jan 29 19:05:39 gentoo kernel: Initializing cgroup subsys cpu
Jan 29 19:05:39 gentoo kernel: Linux version 2.6.38-rc2-00284-g52cda7c (markus@gentoo.trippels.de) (gcc version 4.6.0-alpha20110122 20110122 (experimental) (Gentoo 4.6.0_alpha20110122) ) #36 SMP PREEMPT Sat Jan 29 19:02:03 CET 2011
Jan 29 19:05:39 gentoo kernel: Command line: BOOT_IMAGE=/usr/src/linux/arch/x86/boot/bzImage root=PARTUUID=36e41736-f955-4ea2-8782-6983989a3b51 init=/sbin/minit fbcon=rotate:3 drm_kms_helper.poll=0 quiet
Jan 29 19:05:39 gentoo kernel: BIOS-provided physical RAM map:
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 0000000000100000 - 00000000dfe90000 (usable)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 00000000dfe90000 - 00000000dfea8000 (ACPI data)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 00000000dfea8000 - 00000000dfed0000 (ACPI NVS)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 00000000dfed0000 - 00000000dff00000 (reserved)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
Jan 29 19:05:39 gentoo kernel: BIOS-e820: 0000000100000000 - 0000000220000000 (usable)
Jan 29 19:05:39 gentoo kernel: NX (Execute Disable) protection: active
Jan 29 19:05:39 gentoo kernel: DMI present.
Jan 29 19:05:39 gentoo kernel: DMI: M4A78T-E/System Product Name, BIOS 3406 08/20/2010
Jan 29 19:05:39 gentoo kernel: e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
Jan 29 19:05:39 gentoo kernel: e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
Jan 29 19:05:39 gentoo kernel: last_pfn = 0x220000 max_arch_pfn = 0x400000000
Jan 29 19:05:39 gentoo kernel: MTRR default type: uncachable
Jan 29 19:05:39 gentoo kernel: MTRR fixed ranges enabled:
Jan 29 19:05:39 gentoo kernel: 00000-9FFFF write-back
Jan 29 19:05:39 gentoo kernel: A0000-EFFFF uncachable
Jan 29 19:05:39 gentoo kernel: F0000-FFFFF write-protect
Jan 29 19:05:39 gentoo kernel: MTRR variable ranges enabled:
Jan 29 19:05:39 gentoo kernel: 0 base 000000000000 mask FFFF80000000 write-back
Jan 29 19:05:39 gentoo kernel: 1 base 000080000000 mask FFFFC0000000 write-back
Jan 29 19:05:39 gentoo kernel: 2 base 0000C0000000 mask FFFFE0000000 write-back
Jan 29 19:05:39 gentoo kernel: 3 disabled
Jan 29 19:05:39 gentoo kernel: 4 disabled
Jan 29 19:05:39 gentoo kernel: 5 disabled
Jan 29 19:05:39 gentoo kernel: 6 disabled
Jan 29 19:05:39 gentoo kernel: 7 disabled
Jan 29 19:05:39 gentoo kernel: TOM2: 0000000220000000 aka 8704M
Jan 29 19:05:39 gentoo kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
Jan 29 19:05:39 gentoo kernel: e820 update range: 00000000e0000000 - 0000000100000000 (usable) ==> (reserved)
Jan 29 19:05:39 gentoo kernel: last_pfn = 0xdfe90 max_arch_pfn = 0x400000000
Jan 29 19:05:39 gentoo kernel: initial memory mapped : 0 - 20000000
Jan 29 19:05:39 gentoo kernel: Using GB pages for direct mapping
Jan 29 19:05:39 gentoo kernel: init_memory_mapping: 0000000000000000-00000000dfe90000
Jan 29 19:05:39 gentoo kernel: 0000000000 - 00c0000000 page 1G
Jan 29 19:05:39 gentoo kernel: 00c0000000 - 00dfe00000 page 2M
Jan 29 19:05:39 gentoo kernel: 00dfe00000 - 00dfe90000 page 4k
Jan 29 19:05:39 gentoo kernel: kernel direct mapping tables up to dfe90000 @ 1fffd000-20000000
Jan 29 19:05:39 gentoo kernel: init_memory_mapping: 0000000100000000-0000000220000000
Jan 29 19:05:39 gentoo kernel: 0100000000 - 0200000000 page 1G
Jan 29 19:05:39 gentoo kernel: 0200000000 - 0220000000 page 2M
Jan 29 19:05:39 gentoo kernel: kernel direct mapping tables up to 220000000 @ dfe8e000-dfe90000
Jan 29 19:05:39 gentoo kernel: ACPI: RSDP 00000000000fb880 00024 (v02 ACPIAM)
Jan 29 19:05:39 gentoo kernel: ACPI: XSDT 00000000dfe90100 0005C (v01 082010 XSDT1403 20100820 MSFT 00000097)
Jan 29 19:05:39 gentoo kernel: ACPI: FACP 00000000dfe90290 000F4 (v03 082010 FACP1403 20100820 MSFT 00000097)
Jan 29 19:05:39 gentoo kernel: ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20110112/tbfadt-557)
Jan 29 19:05:39 gentoo kernel: ACPI: DSDT 00000000dfe90450 0E6FE (v01 A1152 A1152000 00000000 INTL 20060113)
Jan 29 19:05:39 gentoo kernel: ACPI: FACS 00000000dfea8000 00040
Jan 29 19:05:39 gentoo kernel: ACPI: APIC 00000000dfe90390 0007C (v01 082010 APIC1403 20100820 MSFT 00000097)
Jan 29 19:05:39 gentoo kernel: ACPI: MCFG 00000000dfe90410 0003C (v01 082010 OEMMCFG 20100820 MSFT 00000097)
Jan 29 19:05:39 gentoo kernel: ACPI: OEMB 00000000dfea8040 00072 (v01 082010 OEMB1403 20100820 MSFT 00000097)
Jan 29 19:05:39 gentoo kernel: ACPI: SRAT 00000000dfe9f450 000E8 (v01 AMD FAM_F_10 00000002 AMD 00000001)
Jan 29 19:05:39 gentoo kernel: ACPI: HPET 00000000dfe9f540 00038 (v01 082010 OEMHPET 20100820 MSFT 00000097)
Jan 29 19:05:39 gentoo kernel: ACPI: SSDT 00000000dfe9f580 0088C (v01 A M I POWERNOW 00000001 AMD 00000001)
Jan 29 19:05:39 gentoo kernel: ACPI: Local APIC address 0xfee00000
Jan 29 19:05:39 gentoo kernel: [ffffea0000000000-ffffea00077fffff] PMD -> [ffff8800cc000000-ffff8800d31fffff] on node 0
Jan 29 19:05:39 gentoo kernel: Zone PFN ranges:
Jan 29 19:05:39 gentoo kernel: DMA 0x00000010 -> 0x00001000
Jan 29 19:05:39 gentoo kernel: DMA32 0x00001000 -> 0x00100000
Jan 29 19:05:39 gentoo kernel: Normal 0x00100000 -> 0x00220000
Jan 29 19:05:39 gentoo kernel: Movable zone start PFN for each node
Jan 29 19:05:39 gentoo kernel: early_node_map[3] active PFN ranges
Jan 29 19:05:39 gentoo kernel: 0: 0x00000010 -> 0x0000009f
Jan 29 19:05:39 gentoo kernel: 0: 0x00000100 -> 0x000dfe90
Jan 29 19:05:39 gentoo kernel: 0: 0x00100000 -> 0x00220000
Jan 29 19:05:39 gentoo kernel: On node 0 totalpages: 2096671
Jan 29 19:05:39 gentoo kernel: DMA zone: 56 pages used for memmap
Jan 29 19:05:39 gentoo kernel: DMA zone: 2 pages reserved
Jan 29 19:05:39 gentoo kernel: DMA zone: 3925 pages, LIFO batch:0
Jan 29 19:05:39 gentoo kernel: DMA32 zone: 14280 pages used for memmap
Jan 29 19:05:39 gentoo kernel: DMA32 zone: 898760 pages, LIFO batch:31
Jan 29 19:05:39 gentoo kernel: Normal zone: 16128 pages used for memmap
Jan 29 19:05:39 gentoo kernel: Normal zone: 1163520 pages, LIFO batch:31
Jan 29 19:05:39 gentoo kernel: ACPI: PM-Timer IO Port: 0x808
Jan 29 19:05:39 gentoo kernel: ACPI: Local APIC address 0xfee00000
Jan 29 19:05:39 gentoo kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Jan 29 19:05:39 gentoo kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Jan 29 19:05:39 gentoo kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
Jan 29 19:05:39 gentoo kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
Jan 29 19:05:39 gentoo kernel: ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled)
Jan 29 19:05:39 gentoo kernel: ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled)
Jan 29 19:05:39 gentoo kernel: ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
Jan 29 19:05:39 gentoo kernel: IOAPIC[0]: apic_id 4, version 33, address 0xfec00000, GSI 0-23
Jan 29 19:05:39 gentoo kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Jan 29 19:05:39 gentoo kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
Jan 29 19:05:39 gentoo kernel: ACPI: IRQ0 used by override.
Jan 29 19:05:39 gentoo kernel: ACPI: IRQ2 used by override.
Jan 29 19:05:39 gentoo kernel: ACPI: IRQ9 used by override.
Jan 29 19:05:39 gentoo kernel: Using ACPI (MADT) for SMP configuration information
Jan 29 19:05:39 gentoo kernel: ACPI: HPET id: 0x8300 base: 0xfed00000
Jan 29 19:05:39 gentoo kernel: SMP: Allowing 4 CPUs, 0 hotplug CPUs
Jan 29 19:05:39 gentoo kernel: nr_irqs_gsi: 40
Jan 29 19:05:39 gentoo kernel: Allocating PCI resources starting at dff00000 (gap: dff00000:20000000)
Jan 29 19:05:39 gentoo kernel: setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
Jan 29 19:05:39 gentoo kernel: PERCPU: Embedded 24 pages/cpu @ffff8800dfc00000 s74560 r0 d23744 u524288
Jan 29 19:05:39 gentoo kernel: pcpu-alloc: s74560 r0 d23744 u524288 alloc=1*2097152
Jan 29 19:05:39 gentoo kernel: pcpu-alloc: [0] 0 1 2 3
Jan 29 19:05:39 gentoo kernel: Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2066205
Jan 29 19:05:39 gentoo kernel: Kernel command line: BOOT_IMAGE=/usr/src/linux/arch/x86/boot/bzImage root=PARTUUID=36e41736-f955-4ea2-8782-6983989a3b51 init=/sbin/minit fbcon=rotate:3 drm_kms_helper.poll=0 quiet
Jan 29 19:05:39 gentoo kernel: PID hash table entries: 4096 (order: 3, 32768 bytes)
Jan 29 19:05:39 gentoo kernel: Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Jan 29 19:05:39 gentoo kernel: Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Jan 29 19:05:39 gentoo kernel: Memory: 8182108k/8912896k available (5550k kernel code, 526212k absent, 204576k reserved, 2205k data, 596k init)
Jan 29 19:05:39 gentoo kernel: SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Jan 29 19:05:39 gentoo kernel: Preemptable hierarchical RCU implementation.
Jan 29 19:05:39 gentoo kernel: NR_IRQS:384
Jan 29 19:05:39 gentoo kernel: Extended CMOS year: 2000
Jan 29 19:05:39 gentoo kernel: spurious 8259A interrupt: IRQ7.
Jan 29 19:05:39 gentoo kernel: Console: colour VGA+ 80x25
Jan 29 19:05:39 gentoo kernel: console [tty0] enabled
Jan 29 19:05:39 gentoo kernel: hpet clockevent registered
Jan 29 19:05:39 gentoo kernel: Fast TSC calibration using PIT
Jan 29 19:05:39 gentoo kernel: Detected 3211.424 MHz processor.
Jan 29 19:05:39 gentoo kernel: Calibrating delay loop (skipped), value calculated using timer frequency.. 6422.84 BogoMIPS (lpj=3211424)
Jan 29 19:05:39 gentoo kernel: pid_max: default: 32768 minimum: 301
Jan 29 19:05:39 gentoo kernel: Mount-cache hash table entries: 256
Jan 29 19:05:39 gentoo kernel: tseg: 0000000000
Jan 29 19:05:39 gentoo kernel: CPU: Physical Processor ID: 0
Jan 29 19:05:39 gentoo kernel: CPU: Processor Core ID: 0
Jan 29 19:05:39 gentoo kernel: mce: CPU supports 6 MCE banks
Jan 29 19:05:39 gentoo kernel: using C1E aware idle routine
Jan 29 19:05:39 gentoo kernel: Freeing SMP alternatives: 16k freed
Jan 29 19:05:39 gentoo kernel: ACPI: Core revision 20110112
Jan 29 19:05:39 gentoo kernel: ftrace: allocating 18624 entries in 74 pages
Jan 29 19:05:39 gentoo kernel: Setting APIC routing to flat
Jan 29 19:05:39 gentoo kernel: ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
Jan 29 19:05:39 gentoo kernel: CPU0: AMD Phenom(tm) II X4 955 Processor stepping 02
Jan 29 19:05:39 gentoo kernel: Performance Events: AMD PMU driver.
Jan 29 19:05:39 gentoo kernel: ... version: 0
Jan 29 19:05:39 gentoo kernel: ... bit width: 48
Jan 29 19:05:39 gentoo kernel: ... generic registers: 4
Jan 29 19:05:39 gentoo kernel: ... value mask: 0000ffffffffffff
Jan 29 19:05:39 gentoo kernel: ... max period: 00007fffffffffff
Jan 29 19:05:39 gentoo kernel: ... fixed-purpose events: 0
Jan 29 19:05:39 gentoo kernel: ... event mask: 000000000000000f
Jan 29 19:05:39 gentoo kernel: System has AMD C1E enabled
Jan 29 19:05:39 gentoo kernel: Switch to broadcast mode on CPU0
Jan 29 19:05:39 gentoo kernel: MCE: In-kernel MCE decoding enabled.
Jan 29 19:05:39 gentoo kernel: Booting Node 0, Processors #1
Jan 29 19:05:39 gentoo kernel: Switch to broadcast mode on CPU1
Jan 29 19:05:39 gentoo kernel: #2
Jan 29 19:05:39 gentoo kernel: Switch to broadcast mode on CPU2
Jan 29 19:05:39 gentoo kernel: #3 Ok.
Jan 29 19:05:39 gentoo kernel: Brought up 4 CPUs
Jan 29 19:05:39 gentoo kernel: Total of 4 processors activated (25687.75 BogoMIPS).
Jan 29 19:05:39 gentoo kernel: Switch to broadcast mode on CPU3
Jan 29 19:05:39 gentoo kernel: devtmpfs: initialized
Jan 29 19:05:39 gentoo kernel: NET: Registered protocol family 16
Jan 29 19:05:39 gentoo kernel: node 0 link 0: io port [1000, ffffff]
Jan 29 19:05:39 gentoo kernel: TOM: 00000000e0000000 aka 3584M
Jan 29 19:05:39 gentoo kernel: Fam 10h mmconf [e0000000, efffffff]
Jan 29 19:05:39 gentoo kernel: node 0 link 0: mmio [a0000, bffff]
Jan 29 19:05:39 gentoo kernel: node 0 link 0: mmio [e0000000, efffffff] ==> none
Jan 29 19:05:39 gentoo kernel: node 0 link 0: mmio [f0000000, fbcfffff]
Jan 29 19:05:39 gentoo kernel: node 0 link 0: mmio [fbd00000, fbefffff]
Jan 29 19:05:39 gentoo kernel: node 0 link 0: mmio [fbf00000, ffefffff]
Jan 29 19:05:39 gentoo kernel: TOM2: 0000000220000000 aka 8704M
Jan 29 19:05:39 gentoo kernel: bus: [00, 07] on node 0 link 0
Jan 29 19:05:39 gentoo kernel: bus: 00 index 0 [io 0x0000-0xffff]
Jan 29 19:05:39 gentoo kernel: bus: 00 index 1 [mem 0x000a0000-0x000bffff]
Jan 29 19:05:39 gentoo kernel: bus: 00 index 2 [mem 0xf0000000-0xffffffff]
Jan 29 19:05:39 gentoo kernel: bus: 00 index 3 [mem 0x220000000-0xfcffffffff]
Jan 29 19:05:39 gentoo kernel: Extended Config Space enabled on 1 nodes
Jan 29 19:05:39 gentoo kernel: ACPI: bus type pci registered
Jan 29 19:05:39 gentoo kernel: PCI: Using configuration type 1 for base access
Jan 29 19:05:39 gentoo kernel: PCI: Using configuration type 1 for extended access
Jan 29 19:05:39 gentoo kernel: mtrr: your CPUs had inconsistent fixed MTRR settings
Jan 29 19:05:39 gentoo kernel: mtrr: probably your BIOS does not setup all CPUs.
Jan 29 19:05:39 gentoo kernel: mtrr: corrected configuration.
Jan 29 19:05:39 gentoo kernel: bio: create slab <bio-0> at 0
Jan 29 19:05:39 gentoo kernel: ACPI: EC: Look up EC in DSDT
Jan 29 19:05:39 gentoo kernel: ACPI: Executed 3 blocks of module-level executable AML code
Jan 29 19:05:39 gentoo kernel: ACPI: Interpreter enabled
Jan 29 19:05:39 gentoo kernel: ACPI: (supports S0 S5)
Jan 29 19:05:39 gentoo kernel: ACPI: Using IOAPIC for interrupt routing
Jan 29 19:05:39 gentoo kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
Jan 29 19:05:39 gentoo kernel: pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7]
Jan 29 19:05:39 gentoo kernel: pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff]
Jan 29 19:05:39 gentoo kernel: pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
Jan 29 19:05:39 gentoo kernel: pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff]
Jan 29 19:05:39 gentoo kernel: pci_root PNP0A03:00: host bridge window [mem 0xdff00000-0xdfffffff]
Jan 29 19:05:39 gentoo kernel: pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:00.0: [1022:9600] type 0 class 0x000600
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: [1022:9602] type 1 class 0x000604
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: [1022:9606] type 1 class 0x000604
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: PME# disabled
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: [1002:4390] type 0 class 0x000101
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: reg 10: [io 0xc000-0xc007]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: reg 14: [io 0xb000-0xb003]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: reg 18: [io 0xa000-0xa007]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: reg 1c: [io 0x9000-0x9003]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: reg 20: [io 0x8000-0x800f]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: reg 24: [mem 0xfbcffc00-0xfbcfffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:11.0: set SATA to AHCI mode
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.0: reg 10: [mem 0xfbcfd000-0xfbcfdfff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.1: [1002:4398] type 0 class 0x000c03
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.1: reg 10: [mem 0xfbcfe000-0xfbcfefff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.2: reg 10: [mem 0xfbcff800-0xfbcff8ff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.2: supports D1 D2
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
Jan 29 19:05:39 gentoo kernel: pci 0000:00:12.2: PME# disabled
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.0: reg 10: [mem 0xfbcfb000-0xfbcfbfff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.1: [1002:4398] type 0 class 0x000c03
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.1: reg 10: [mem 0xfbcfc000-0xfbcfcfff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.2: reg 10: [mem 0xfbcff400-0xfbcff4ff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.2: supports D1 D2
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
Jan 29 19:05:39 gentoo kernel: pci 0000:00:13.2: PME# disabled
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.1: [1002:439c] type 0 class 0x000101
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.1: reg 10: [io 0x0000-0x0007]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.1: reg 14: [io 0x0000-0x0003]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.1: reg 18: [io 0x0000-0x0007]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.1: reg 1c: [io 0x0000-0x0003]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.1: reg 20: [io 0xff00-0xff0f]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.3: [1002:439d] type 0 class 0x000601
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: [1002:4384] type 1 class 0x000604
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.5: reg 10: [mem 0xfbcfa000-0xfbcfafff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:18.0: [1022:1200] type 0 class 0x000600
Jan 29 19:05:39 gentoo kernel: pci 0000:00:18.1: [1022:1201] type 0 class 0x000600
Jan 29 19:05:39 gentoo kernel: pci 0000:00:18.2: [1022:1202] type 0 class 0x000600
Jan 29 19:05:39 gentoo kernel: pci 0000:00:18.3: [1022:1203] type 0 class 0x000600
Jan 29 19:05:39 gentoo kernel: pci 0000:00:18.4: [1022:1204] type 0 class 0x000600
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.0: [1002:9614] type 0 class 0x000300
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.0: reg 10: [mem 0xf0000000-0xf7ffffff pref]
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.0: reg 14: [io 0xd000-0xd0ff]
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.0: reg 18: [mem 0xfbee0000-0xfbeeffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.0: reg 24: [mem 0xfbd00000-0xfbdfffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.0: supports D1 D2
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.1: [1002:960f] type 0 class 0x000403
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.1: reg 10: [mem 0xfbefc000-0xfbefffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.1: supports D1 D2
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: bridge window [io 0xd000-0xdfff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: bridge window [mem 0xfbd00000-0xfbefffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: bridge window [mem 0xf0000000-0xf7ffffff 64bit pref]
Jan 29 19:05:39 gentoo kernel: pci 0000:02:00.0: [1969:1026] type 0 class 0x000200
Jan 29 19:05:39 gentoo kernel: pci 0000:02:00.0: reg 10: [mem 0xfbfc0000-0xfbffffff 64bit]
Jan 29 19:05:39 gentoo kernel: pci 0000:02:00.0: reg 18: [io 0xec00-0xec7f]
Jan 29 19:05:39 gentoo kernel: pci 0000:02:00.0: PME# supported from D3hot D3cold
Jan 29 19:05:39 gentoo kernel: pci 0000:02:00.0: PME# disabled
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: PCI bridge to [bus 02-02]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: bridge window [io 0xe000-0xefff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: bridge window [mem 0xfbf00000-0xfbffffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: PCI bridge to [bus 03-03] (subtractive decode)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [io 0xf000-0x0000] (disabled)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem 0xfff00000-0x000fffff] (disabled)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7] (subtractive decode)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [io 0x0d00-0xffff] (subtractive decode)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem 0x000d0000-0x000dffff] (subtractive decode)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem 0xdff00000-0xdfffffff] (subtractive decode)
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem 0xf0000000-0xfebfffff] (subtractive decode)
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:00: on NUMA node 0
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE6._PRT]
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs *4 7 10 11 12 14 15)
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 4 *7 10 11 12 14 15)
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 12 14 15)
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 *11 12 14 15)
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 15) *0, disabled.
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) *0, disabled.
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 12 14 15)
Jan 29 19:05:39 gentoo kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) *0, disabled.
Jan 29 19:05:39 gentoo kernel: SCSI subsystem initialized
Jan 29 19:05:39 gentoo kernel: libata version 3.00 loaded.
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver usbfs
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver hub
Jan 29 19:05:39 gentoo kernel: usbcore: registered new device driver usb
Jan 29 19:05:39 gentoo kernel: Advanced Linux Sound Architecture Driver Version 1.0.23.
Jan 29 19:05:39 gentoo kernel: PCI: Using ACPI for IRQ routing
Jan 29 19:05:39 gentoo kernel: PCI: pci_cache_line_size set to 64 bytes
Jan 29 19:05:39 gentoo kernel: reserve RAM buffer: 000000000009fc00 - 000000000009ffff
Jan 29 19:05:39 gentoo kernel: reserve RAM buffer: 00000000dfe90000 - 00000000dfffffff
Jan 29 19:05:39 gentoo kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
Jan 29 19:05:39 gentoo kernel: hpet0: 4 comparators, 32-bit 14.318180 MHz counter
Jan 29 19:05:39 gentoo kernel: Switching to clocksource hpet
Jan 29 19:05:39 gentoo kernel: Switched to NOHz mode on CPU #1
Jan 29 19:05:39 gentoo kernel: Switched to NOHz mode on CPU #2
Jan 29 19:05:39 gentoo kernel: Switched to NOHz mode on CPU #3
Jan 29 19:05:39 gentoo kernel: Switched to NOHz mode on CPU #0
Jan 29 19:05:39 gentoo kernel: pnp: PnP ACPI init
Jan 29 19:05:39 gentoo kernel: ACPI: bus type pnp registered
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [bus 00-ff]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [io 0x0cf8-0x0cff]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [io 0x0000-0x0cf7 window]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [io 0x0d00-0xffff window]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [mem 0x000a0000-0x000bffff window]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [mem 0x000d0000-0x000dffff window]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [mem 0xdff00000-0xdfffffff window]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: [mem 0xf0000000-0xfebfffff window]
Jan 29 19:05:39 gentoo kernel: pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled]
Jan 29 19:05:39 gentoo kernel: pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled]
Jan 29 19:05:39 gentoo kernel: system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:02: [dma 4]
Jan 29 19:05:39 gentoo kernel: pnp 00:02: [io 0x0000-0x000f]
Jan 29 19:05:39 gentoo kernel: pnp 00:02: [io 0x0081-0x0083]
Jan 29 19:05:39 gentoo kernel: pnp 00:02: [io 0x0087]
Jan 29 19:05:39 gentoo kernel: pnp 00:02: [io 0x0089-0x008b]
Jan 29 19:05:39 gentoo kernel: pnp 00:02: [io 0x008f]
Jan 29 19:05:39 gentoo kernel: pnp 00:02: [io 0x00c0-0x00df]
Jan 29 19:05:39 gentoo kernel: pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:03: [io 0x0070-0x0071]
Jan 29 19:05:39 gentoo kernel: pnp 00:03: [irq 8]
Jan 29 19:05:39 gentoo kernel: pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:04: [io 0x0061]
Jan 29 19:05:39 gentoo kernel: pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:05: [io 0x00f0-0x00ff]
Jan 29 19:05:39 gentoo kernel: pnp 00:05: [irq 13]
Jan 29 19:05:39 gentoo kernel: pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:06: [mem 0xfed00000-0xfed003ff]
Jan 29 19:05:39 gentoo kernel: pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:07: [io 0x0060]
Jan 29 19:05:39 gentoo kernel: pnp 00:07: [io 0x0064]
Jan 29 19:05:39 gentoo kernel: pnp 00:07: [mem 0xfec00000-0xfec00fff]
Jan 29 19:05:39 gentoo kernel: pnp 00:07: [mem 0xfee00000-0xfee00fff]
Jan 29 19:05:39 gentoo kernel: system 00:07: [mem 0xfec00000-0xfec00fff] could not be reserved
Jan 29 19:05:39 gentoo kernel: system 00:07: [mem 0xfee00000-0xfee00fff] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0010-0x001f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0022-0x003f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0062-0x0063]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0065-0x006f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0072-0x007f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0080]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0084-0x0086]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0088]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x008c-0x008e]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0090-0x009f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x00a2-0x00bf]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x00b1]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x00e0-0x00ef]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x04d0-0x04d1]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x040b]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x04d6]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0c00-0x0c01]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0c14]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0c50-0x0c51]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0c52]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0c6c]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0c6f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0cd0-0x0cd1]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0cd2-0x0cd3]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0cd4-0x0cd5]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0cd6-0x0cd7]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0cd8-0x0cdf]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0b00-0x0b3f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0800-0x089f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0000-0xffffffffffffffff disabled]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0b00-0x0b0f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0b20-0x0b3f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0900-0x090f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0910-0x091f]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0xfe00-0xfefe]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0060]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [io 0x0064]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [mem 0xdff00000-0xdfffffff]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [mem 0xffb80000-0xffbfffff]
Jan 29 19:05:39 gentoo kernel: pnp 00:08: [mem 0xfec10000-0xfec1001f]
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x04d0-0x04d1] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x040b] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x04d6] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0c00-0x0c01] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0c14] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0c50-0x0c51] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0c52] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0c6c] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0c6f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0cd0-0x0cd1] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0cd2-0x0cd3] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0cd4-0x0cd5] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0cd6-0x0cd7] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0cd8-0x0cdf] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0b00-0x0b3f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0800-0x089f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0b00-0x0b0f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0b20-0x0b3f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0900-0x090f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0x0910-0x091f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [io 0xfe00-0xfefe] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [mem 0xdff00000-0xdfffffff] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [mem 0xffb80000-0xffbfffff] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: [mem 0xfec10000-0xfec1001f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:09: [io 0x0000-0xffffffffffffffff disabled]
Jan 29 19:05:39 gentoo kernel: pnp 00:09: [io 0x0230-0x023f]
Jan 29 19:05:39 gentoo kernel: pnp 00:09: [io 0x0290-0x029f]
Jan 29 19:05:39 gentoo kernel: pnp 00:09: [io 0x0f40-0x0f4f]
Jan 29 19:05:39 gentoo kernel: pnp 00:09: [io 0x0a30-0x0a3f]
Jan 29 19:05:39 gentoo kernel: system 00:09: [io 0x0230-0x023f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:09: [io 0x0290-0x029f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:09: [io 0x0f40-0x0f4f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:09: [io 0x0a30-0x0a3f] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:0a: [mem 0xe0000000-0xefffffff]
Jan 29 19:05:39 gentoo kernel: system 00:0a: [mem 0xe0000000-0xefffffff] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
Jan 29 19:05:39 gentoo kernel: pnp 00:0b: [mem 0x00000000-0x0009ffff]
Jan 29 19:05:39 gentoo kernel: pnp 00:0b: [mem 0x000c0000-0x000cffff]
Jan 29 19:05:39 gentoo kernel: pnp 00:0b: [mem 0x000e0000-0x000fffff]
Jan 29 19:05:39 gentoo kernel: pnp 00:0b: [mem 0x00100000-0xdfefffff]
Jan 29 19:05:39 gentoo kernel: pnp 00:0b: [mem 0xfec00000-0xffffffff]
Jan 29 19:05:39 gentoo kernel: system 00:0b: [mem 0x00000000-0x0009ffff] could not be reserved
Jan 29 19:05:39 gentoo kernel: system 00:0b: [mem 0x000c0000-0x000cffff] has been reserved
Jan 29 19:05:39 gentoo kernel: system 00:0b: [mem 0x000e0000-0x000fffff] could not be reserved
Jan 29 19:05:39 gentoo kernel: system 00:0b: [mem 0x00100000-0xdfefffff] could not be reserved
Jan 29 19:05:39 gentoo kernel: system 00:0b: [mem 0xfec00000-0xffffffff] could not be reserved
Jan 29 19:05:39 gentoo kernel: system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)
Jan 29 19:05:39 gentoo kernel: pnp: PnP ACPI: found 12 devices
Jan 29 19:05:39 gentoo kernel: ACPI: ACPI bus type pnp unregistered
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: bridge window [io 0xd000-0xdfff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: bridge window [mem 0xfbd00000-0xfbefffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: bridge window [mem 0xf0000000-0xf7ffffff 64bit pref]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: PCI bridge to [bus 02-02]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: bridge window [io 0xe000-0xefff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: bridge window [mem 0xfbf00000-0xfbffffff]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: bridge window [mem pref disabled]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: PCI bridge to [bus 03-03]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [io disabled]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem disabled]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:14.4: bridge window [mem pref disabled]
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Jan 29 19:05:39 gentoo kernel: pci 0000:00:06.0: setting latency timer to 64
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:00: resource 5 [io 0x0d00-0xffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:00: resource 8 [mem 0xdff00000-0xdfffffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:01: resource 0 [io 0xd000-0xdfff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:01: resource 1 [mem 0xfbd00000-0xfbefffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:01: resource 2 [mem 0xf0000000-0xf7ffffff 64bit pref]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:02: resource 0 [io 0xe000-0xefff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:02: resource 1 [mem 0xfbf00000-0xfbffffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:03: resource 4 [io 0x0000-0x0cf7]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:03: resource 5 [io 0x0d00-0xffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000dffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:03: resource 8 [mem 0xdff00000-0xdfffffff]
Jan 29 19:05:39 gentoo kernel: pci_bus 0000:03: resource 9 [mem 0xf0000000-0xfebfffff]
Jan 29 19:05:39 gentoo kernel: NET: Registered protocol family 2
Jan 29 19:05:39 gentoo kernel: IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
Jan 29 19:05:39 gentoo kernel: TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
Jan 29 19:05:39 gentoo kernel: TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
Jan 29 19:05:39 gentoo kernel: TCP: Hash tables configured (established 262144 bind 65536)
Jan 29 19:05:39 gentoo kernel: TCP reno registered
Jan 29 19:05:39 gentoo kernel: UDP hash table entries: 4096 (order: 5, 131072 bytes)
Jan 29 19:05:39 gentoo kernel: UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
Jan 29 19:05:39 gentoo kernel: NET: Registered protocol family 1
Jan 29 19:05:39 gentoo kernel: pci 0000:00:01.0: MSI quirk detected; subordinate MSI disabled
Jan 29 19:05:39 gentoo kernel: pci 0000:01:05.0: Boot video device
Jan 29 19:05:39 gentoo kernel: PCI: CLS 64 bytes, default 64
Jan 29 19:05:39 gentoo kernel: PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Jan 29 19:05:39 gentoo kernel: Placing 64MB software IO TLB between ffff8800dae8b000 - ffff8800dee8b000
Jan 29 19:05:39 gentoo kernel: software IO TLB at phys 0xdae8b000 - 0xdee8b000
Jan 29 19:05:39 gentoo kernel: kvm: Nested Virtualization enabled
Jan 29 19:05:39 gentoo kernel: kvm: Nested Paging enabled
Jan 29 19:05:39 gentoo kernel: SGI XFS with security attributes, large block/inode numbers, no debug enabled
Jan 29 19:05:39 gentoo kernel: msgmni has been set to 15980
Jan 29 19:05:39 gentoo kernel: Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
Jan 29 19:05:39 gentoo kernel: io scheduler noop registered
Jan 29 19:05:39 gentoo kernel: io scheduler cfq registered (default)
Jan 29 19:05:39 gentoo kernel: input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
Jan 29 19:05:39 gentoo kernel: ACPI: Power Button [PWRB]
Jan 29 19:05:39 gentoo kernel: input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
Jan 29 19:05:39 gentoo kernel: ACPI: Power Button [PWRF]
Jan 29 19:05:39 gentoo kernel: ACPI: acpi_idle registered with cpuidle
Jan 29 19:05:39 gentoo kernel: ACPI: processor limited to max C-state 1
Jan 29 19:05:39 gentoo kernel: [drm] Initialized drm 1.1.0 20060810
Jan 29 19:05:39 gentoo kernel: [drm] radeon defaulting to kernel modesetting.
Jan 29 19:05:39 gentoo kernel: [drm] radeon kernel modesetting enabled.
Jan 29 19:05:39 gentoo kernel: radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Jan 29 19:05:39 gentoo kernel: radeon 0000:01:05.0: setting latency timer to 64
Jan 29 19:05:39 gentoo kernel: [drm] initializing kernel modesetting (RS780 0x1002:0x9614).
Jan 29 19:05:39 gentoo kernel: [drm] register mmio base: 0xFBEE0000
Jan 29 19:05:39 gentoo kernel: [drm] register mmio size: 65536
Jan 29 19:05:39 gentoo kernel: ATOM BIOS: 113
Jan 29 19:05:39 gentoo kernel: radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
Jan 29 19:05:39 gentoo kernel: radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
Jan 29 19:05:39 gentoo kernel: [drm] Detected VRAM RAM=128M, BAR=128M
Jan 29 19:05:39 gentoo kernel: [drm] RAM width 32bits DDR
Jan 29 19:05:39 gentoo kernel: [TTM] Zone kernel: Available graphics memory: 4091062 kiB.
Jan 29 19:05:39 gentoo kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
Jan 29 19:05:39 gentoo kernel: [TTM] Initializing pool allocator.
Jan 29 19:05:39 gentoo kernel: [drm] radeon: 128M of VRAM memory ready
Jan 29 19:05:39 gentoo kernel: [drm] radeon: 512M of GTT memory ready.
Jan 29 19:05:39 gentoo kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Jan 29 19:05:39 gentoo kernel: [drm] Driver supports precise vblank timestamp query.
Jan 29 19:05:39 gentoo kernel: [drm] radeon: irq initialized.
Jan 29 19:05:39 gentoo kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
Jan 29 19:05:39 gentoo kernel: [drm] Loading RS780 Microcode
Jan 29 19:05:39 gentoo kernel: radeon 0000:01:05.0: WB enabled
Jan 29 19:05:39 gentoo kernel: [drm] ring test succeeded in 1 usecs
Jan 29 19:05:39 gentoo kernel: [drm] radeon: ib pool ready.
Jan 29 19:05:39 gentoo kernel: [drm] ib test succeeded in 0 usecs
Jan 29 19:05:39 gentoo kernel: [drm] Enabling audio support
Jan 29 19:05:39 gentoo kernel: [drm] Radeon Display Connectors
Jan 29 19:05:39 gentoo kernel: [drm] Connector 0:
Jan 29 19:05:39 gentoo kernel: [drm] VGA
Jan 29 19:05:39 gentoo kernel: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
Jan 29 19:05:39 gentoo kernel: [drm] Encoders:
Jan 29 19:05:39 gentoo kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Jan 29 19:05:39 gentoo kernel: [drm] Connector 1:
Jan 29 19:05:39 gentoo kernel: [drm] DVI-D
Jan 29 19:05:39 gentoo kernel: [drm] HPD3
Jan 29 19:05:39 gentoo kernel: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
Jan 29 19:05:39 gentoo kernel: [drm] Encoders:
Jan 29 19:05:39 gentoo kernel: [drm] DFP3: INTERNAL_KLDSCP_LVTMA
Jan 29 19:05:39 gentoo kernel: [drm] radeon: power management initialized
Jan 29 19:05:39 gentoo kernel: [drm] fb mappable at 0xF0141000
Jan 29 19:05:39 gentoo kernel: [drm] vram apper at 0xF0000000
Jan 29 19:05:39 gentoo kernel: [drm] size 7258112
Jan 29 19:05:39 gentoo kernel: [drm] fb depth is 24
Jan 29 19:05:39 gentoo kernel: [drm] pitch is 6912
Jan 29 19:05:39 gentoo kernel: Console: switching to colour frame buffer device 131x105
Jan 29 19:05:39 gentoo kernel: fb0: radeondrmfb frame buffer device
Jan 29 19:05:39 gentoo kernel: drm: registered panic notifier
Jan 29 19:05:39 gentoo kernel: [drm] Initialized radeon 2.8.0 20080528 for 0000:01:05.0 on minor 0
Jan 29 19:05:39 gentoo kernel: loop: module loaded
Jan 29 19:05:39 gentoo kernel: ahci 0000:00:11.0: version 3.0
Jan 29 19:05:39 gentoo kernel: ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Jan 29 19:05:39 gentoo kernel: ahci 0000:00:11.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
Jan 29 19:05:39 gentoo kernel: ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
Jan 29 19:05:39 gentoo kernel: scsi0 : ahci
Jan 29 19:05:39 gentoo kernel: scsi1 : ahci
Jan 29 19:05:39 gentoo kernel: scsi2 : ahci
Jan 29 19:05:39 gentoo kernel: scsi3 : ahci
Jan 29 19:05:39 gentoo kernel: ata1: SATA max UDMA/133 irq_stat 0x00400000, PHY RDY changed
Jan 29 19:05:39 gentoo kernel: ata2: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffd80 irq 22
Jan 29 19:05:39 gentoo kernel: ata3: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffe00 irq 22
Jan 29 19:05:39 gentoo kernel: ata4: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffe80 irq 22
Jan 29 19:05:39 gentoo kernel: pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jan 29 19:05:39 gentoo kernel: pata_atiixp 0000:00:14.1: setting latency timer to 64
Jan 29 19:05:39 gentoo kernel: scsi4 : pata_atiixp
Jan 29 19:05:39 gentoo kernel: scsi5 : pata_atiixp
Jan 29 19:05:39 gentoo kernel: ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
Jan 29 19:05:39 gentoo kernel: ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
Jan 29 19:05:39 gentoo kernel: ATL1E 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Jan 29 19:05:39 gentoo kernel: ATL1E 0000:02:00.0: setting latency timer to 64
Jan 29 19:05:39 gentoo kernel: PPP generic driver version 2.4.2
Jan 29 19:05:39 gentoo kernel: tun: Universal TUN/TAP device driver, 1.6
Jan 29 19:05:39 gentoo kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Jan 29 19:05:39 gentoo kernel: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: EHCI Host Controller
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: applying AMD SB600/SB700 USB freeze workaround
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: debug port 1
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: irq 17, io mem 0xfbcff800
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
Jan 29 19:05:39 gentoo kernel: hub 1-0:1.0: USB hub found
Jan 29 19:05:39 gentoo kernel: hub 1-0:1.0: 6 ports detected
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: EHCI Host Controller
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: applying AMD SB600/SB700 USB freeze workaround
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: debug port 1
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: irq 19, io mem 0xfbcff400
Jan 29 19:05:39 gentoo kernel: ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
Jan 29 19:05:39 gentoo kernel: hub 2-0:1.0: USB hub found
Jan 29 19:05:39 gentoo kernel: hub 2-0:1.0: 6 ports detected
Jan 29 19:05:39 gentoo kernel: ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.0: OHCI Host Controller
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.0: irq 16, io mem 0xfbcfd000
Jan 29 19:05:39 gentoo kernel: hub 3-0:1.0: USB hub found
Jan 29 19:05:39 gentoo kernel: hub 3-0:1.0: 3 ports detected
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.1: OHCI Host Controller
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.1: new USB bus registered, assigned bus number 4
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:12.1: irq 16, io mem 0xfbcfe000
Jan 29 19:05:39 gentoo kernel: hub 4-0:1.0: USB hub found
Jan 29 19:05:39 gentoo kernel: hub 4-0:1.0: 3 ports detected
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.0: OHCI Host Controller
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.0: irq 18, io mem 0xfbcfb000
Jan 29 19:05:39 gentoo kernel: ata5.00: ATAPI: HL-DT-STDVD-RAM GH22NP20, 1.03, max UDMA/66
Jan 29 19:05:39 gentoo kernel: ata5.00: configured for UDMA/66
Jan 29 19:05:39 gentoo kernel: hub 5-0:1.0: USB hub found
Jan 29 19:05:39 gentoo kernel: hub 5-0:1.0: 3 ports detected
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.1: OHCI Host Controller
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 6
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:13.1: irq 18, io mem 0xfbcfc000
Jan 29 19:05:39 gentoo kernel: hub 6-0:1.0: USB hub found
Jan 29 19:05:39 gentoo kernel: hub 6-0:1.0: 3 ports detected
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:14.5: OHCI Host Controller
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 7
Jan 29 19:05:39 gentoo kernel: ohci_hcd 0000:00:14.5: irq 18, io mem 0xfbcfa000
Jan 29 19:05:39 gentoo kernel: hub 7-0:1.0: USB hub found
Jan 29 19:05:39 gentoo kernel: hub 7-0:1.0: 2 ports detected
Jan 29 19:05:39 gentoo kernel: Initializing USB Mass Storage driver...
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver usb-storage
Jan 29 19:05:39 gentoo kernel: USB Mass Storage support registered.
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver usbserial
Jan 29 19:05:39 gentoo kernel: USB Serial support registered for generic
Jan 29 19:05:39 gentoo kernel: ata4: SATA link down (SStatus 0 SControl 300)
Jan 29 19:05:39 gentoo kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 19:05:39 gentoo kernel: ata2: SATA link down (SStatus 0 SControl 300)
Jan 29 19:05:39 gentoo kernel: ata3.00: ATA-8: OCZ-VERTEX, 1.6, max UDMA/133
Jan 29 19:05:39 gentoo kernel: ata3.00: 62533296 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
Jan 29 19:05:39 gentoo kernel: ata3.00: configured for UDMA/133
Jan 29 19:05:39 gentoo kernel: usb 4-1: new full speed USB device using ohci_hcd and address 2
Jan 29 19:05:39 gentoo kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jan 29 19:05:39 gentoo kernel: ata1.00: ATA-7: SAMSUNG HD103UJ, 1AA01118, max UDMA7
Jan 29 19:05:39 gentoo kernel: ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
Jan 29 19:05:39 gentoo kernel: ata1.00: configured for UDMA/133
Jan 29 19:05:39 gentoo kernel: scsi 0:0:0:0: Direct-Access ATA SAMSUNG HD103UJ 1AA0 PQ: 0 ANSI: 5
Jan 29 19:05:39 gentoo kernel: sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
Jan 29 19:05:39 gentoo kernel: sd 0:0:0:0: [sda] Write Protect is off
Jan 29 19:05:39 gentoo kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Jan 29 19:05:39 gentoo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 29 19:05:39 gentoo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jan 29 19:05:39 gentoo kernel: scsi 2:0:0:0: Direct-Access ATA OCZ-VERTEX 1.6 PQ: 0 ANSI: 5
Jan 29 19:05:39 gentoo kernel: sd 2:0:0:0: [sdb] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
Jan 29 19:05:39 gentoo kernel: sd 2:0:0:0: Attached scsi generic sg1 type 0
Jan 29 19:05:39 gentoo kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jan 29 19:05:39 gentoo kernel: sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Jan 29 19:05:39 gentoo kernel: sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 29 19:05:39 gentoo kernel: scsi 4:0:0:0: CD-ROM HL-DT-ST DVD-RAM GH22NP20 1.03 PQ: 0 ANSI: 5
Jan 29 19:05:39 gentoo kernel: sdb: sdb1 sdb2
Jan 29 19:05:39 gentoo kernel: sd 2:0:0:0: [sdb] Attached SCSI disk
Jan 29 19:05:39 gentoo kernel: sda: sda1 sda2 sda3
Jan 29 19:05:39 gentoo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jan 29 19:05:39 gentoo kernel: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Jan 29 19:05:39 gentoo kernel: cdrom: Uniform CD-ROM driver Revision: 3.20
Jan 29 19:05:39 gentoo kernel: sr 4:0:0:0: Attached scsi CD-ROM sr0
Jan 29 19:05:39 gentoo kernel: sr 4:0:0:0: Attached scsi generic sg2 type 5
Jan 29 19:05:39 gentoo kernel: Refined TSC clocksource calibration: 3210.827 MHz.
Jan 29 19:05:39 gentoo kernel: Switching to clocksource tsc
Jan 29 19:05:39 gentoo kernel: usb 4-2: new full speed USB device using ohci_hcd and address 3
Jan 29 19:05:39 gentoo kernel: usb 4-3: new low speed USB device using ohci_hcd and address 4
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver usbserial_generic
Jan 29 19:05:39 gentoo kernel: usbserial: USB Serial Driver core
Jan 29 19:05:39 gentoo kernel: USB Serial support registered for GSM modem (1-port)
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver option
Jan 29 19:05:39 gentoo kernel: option: v0.7.2:USB Driver for GSM modems
Jan 29 19:05:39 gentoo kernel: i8042: PNP: No PS/2 controller found. Probing ports directly.
Jan 29 19:05:39 gentoo kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Jan 29 19:05:39 gentoo kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Jan 29 19:05:39 gentoo kernel: mousedev: PS/2 mouse device common for all mice
Jan 29 19:05:39 gentoo kernel: rtc_cmos 00:03: RTC can wake from S4
Jan 29 19:05:39 gentoo kernel: rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
Jan 29 19:05:39 gentoo kernel: rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
Jan 29 19:05:39 gentoo kernel: i2c /dev entries driver
Jan 29 19:05:39 gentoo kernel: EDAC MC: Ver: 2.1.0 Jan 29 2011
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_sysfs_setup_mc_kset: edac_sysfs_setup_mc_kset()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_sysfs_setup_mc_kset: edac_sysfs_setup_mc_kset() Registered '.../edac/mc' kobject
Jan 29 19:05:39 gentoo kernel: EDAC amd64_edac: v3.3.0
Jan 29 19:05:39 gentoo kernel: EDAC amd64: DRAM ECC enabled.
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 0, MCG_CTL: 0x3f, NB MSR is enabled
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 1, MCG_CTL: 0x3f, NB MSR is enabled
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 2, MCG_CTL: 0x3f, NB MSR is enabled
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_nb_mce_bank_enabled_on_node: core: 3, MCG_CTL: 0x3f, NB MSR is enabled
Jan 29 19:05:39 gentoo kernel: EDAC amd64: F10h detected (node 0).
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: reserve_mc_sibling_devs: F1: 0000:00:18.1
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: reserve_mc_sibling_devs: F2: 0000:00:18.2
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: reserve_mc_sibling_devs: F3: 0000:00:18.3
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: read_mc_regs: TOP_MEM: 0x00000000e0000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: read_mc_regs: TOP_MEM2: 0x0000000220000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: f10_read_dram_ctl_register: F2x110 (DCTL Sel. Low): 0x00000510, High range addresses at: 0x0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: f10_read_dram_ctl_register: DCT mode: ganged, All DCTs on: yes
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: f10_read_dram_ctl_register: DCT data interleave for ECC: disabled, DRAM cleared since last warm reset: yes
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: f10_read_dram_ctl_register: DCT channel interleave: disabled, DCT interleave bits selector: 0x0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: read_mc_regs: DRAM-BASE[0]: 0x0000000000000000 DRAM-LIMIT: 0x000000021fffffff
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: read_mc_regs: IntlvEn=Disabled W R IntlvSel=0 DstNode=0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[0]=0x00000001 reg: F2x40
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[1]=0x00000209 reg: F2x44
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[2]=0x00000401 reg: F2x48
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[3]=0x00000609 reg: F2x4c
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[4]=0x00000000 reg: F2x50
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[5]=0x00000000 reg: F2x54
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[6]=0x00000000 reg: F2x58
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSB0[7]=0x00000000 reg: F2x5c
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSM0[0]=0x01f839e0 reg: F2x60
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSM0[1]=0x01f839e0 reg: F2x64
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSM0[2]=0x00000000 reg: F2x68
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_read_dct_base_mask: DCSM0[3]=0x00000000 reg: F2x6c
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_misc_regs: F3xE8 (NB Cap): 0x02077f59
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_misc_regs: NB two channel DRAM capable: yes
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_misc_regs: ECC capable: yes, ChipKill ECC capable: yes
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_dramcfg_low: F2x090 (DRAM Cfg Low): 0x00090800
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_dramcfg_low: DIMM type: unbuffered; all DIMMs support ECC: yes
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_dramcfg_low: PAR/ERR parity: disabled
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_dramcfg_low: DCT 128bit mode width: 128b
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_dramcfg_low: x4 logical DIMMs present: L0: no L1: no L2: no L3: no
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_misc_regs: F3xB0 (Online Spare): 0x00000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_misc_regs: F1xF0 (DRAM Hole Address): 0xe0002003, base: 0xe0000000, offset: 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_dump_misc_regs: DramHoleValid: yes
Jan 29 19:05:39 gentoo kernel: EDAC amd64: using x4 syndromes.
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_debug_display_dimm_sizes: F2x080 (DRAM Bank Address Mapping): 0x00000055
Jan 29 19:05:39 gentoo kernel: EDAC MC: DCT0 chip selects:
Jan 29 19:05:39 gentoo kernel: EDAC amd64: MC: 0: 1024MB 1: 1024MB
Jan 29 19:05:39 gentoo kernel: EDAC amd64: MC: 2: 1024MB 3: 1024MB
Jan 29 19:05:39 gentoo kernel: EDAC amd64: MC: 4: 0MB 5: 0MB
Jan 29 19:05:39 gentoo kernel: EDAC amd64: MC: 6: 0MB 7: 0MB
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_mc_register_sysfs_main_kobj: edac_mc_register_sysfs_main_kobj()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_mc_register_sysfs_main_kobj: edac_mc_register_sysfs_main_kobj() Registered '.../edac/mc0' kobject
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: node 0, NBCFG=0x4af0005c[ChipKillEccCap: 1|DramEccEn: 1]
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 5
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0x0 translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0x0 to SysAddr 0x0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0xffffffe1fff9ffff translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0xffffffe1fff9ffff to SysAddr 0xffffffe1fff9ffff
Jan 29 19:05:39 gentoo kernel: EDAC amd64: CS0: Unbuffered DDR3 RAM
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: for MC node 0 csrow 0:
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: input_addr_min: 0x0 input_addr_max: 0xffffffe1fff9ffff
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: sys_addr: 0xffffffe1fff9ffff page_mask: 0x1e00060000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: nr_pages: 524288 first_page: 0x0 last_page: 0xfe1fff9f
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 1 VALID for MC node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: (csrow=1) DBAM map index= 5
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0x20000 translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0x20000 to SysAddr 0x20000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0xffffffe1fffbffff translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0xffffffe1fffbffff to SysAddr 0xffffffe1fffbffff
Jan 29 19:05:39 gentoo kernel: EDAC amd64: CS1: Unbuffered DDR3 RAM
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: for MC node 0 csrow 1:
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: input_addr_min: 0x20000 input_addr_max: 0xffffffe1fffbffff
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: sys_addr: 0xffffffe1fffbffff page_mask: 0x1e00060000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: nr_pages: 524288 first_page: 0x20 last_page: 0xfe1fffbf
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 2 VALID for MC node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: (csrow=2) DBAM map index= 5
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0x40000 translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0x40000 to SysAddr 0x40000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0xffffffe1fffdffff translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0xffffffe1fffdffff to SysAddr 0xffffffe1fffdffff
Jan 29 19:05:39 gentoo kernel: EDAC amd64: CS2: Unbuffered DDR3 RAM
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: for MC node 0 csrow 2:
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: input_addr_min: 0x40000 input_addr_max: 0xffffffe1fffdffff
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: sys_addr: 0xffffffe1fffdffff page_mask: 0x1e00060000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: nr_pages: 524288 first_page: 0x40 last_page: 0xfe1fffdf
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 3 VALID for MC node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: (csrow=3) DBAM map index= 5
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0x60000 translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0x60000 to SysAddr 0x60000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: input_addr_to_dram_addr: InputAddr 0xffffffe1ffffffff translates to DramAddr of same value
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: amd64_get_dram_hole_info: DHAR info for node 0 base 0xe0000000 offset 0x20000000 size 0x20000000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: dram_addr_to_sys_addr: Node 0, DramAddr 0xffffffe1ffffffff to SysAddr 0xffffffe1ffffffff
Jan 29 19:05:39 gentoo kernel: EDAC amd64: CS3: Unbuffered DDR3 RAM
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: for MC node 0 csrow 3:
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: input_addr_min: 0x60000 input_addr_max: 0xffffffe1ffffffff
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: sys_addr: 0xffffffe1ffffffff page_mask: 0x1e00060000
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: nr_pages: 524288 first_page: 0x60 last_page: 0xfe1fffff
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 4 EMPTY for node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 5 EMPTY for node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 6 EMPTY for node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: init_csrows: ----CSROW 7 EMPTY for node 0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_mc_add_mc: edac_mc_add_mc()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_sysfs_mci_device: edac_create_sysfs_mci_device() idx=0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() sysfs_attrib = ffffffff818b3c00
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file dhar
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() sysfs_attrib = ffffffff818b3c28
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file dbam
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() sysfs_attrib = ffffffff818b3c50
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file topmem
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() sysfs_attrib = ffffffff818b3c78
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file topmem2
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() sysfs_attrib = ffffffff818b3ca0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file dram_hole
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() sysfs_attrib = ffffffff818b3cc8
Jan 29 19:05:39 gentoo kernel: EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 0000:00:18.2
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_alloc_ctl_info: edac_pci_alloc_ctl_info()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_add_device: edac_pci_add_device()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: add_edac_pci_to_global_list: add_edac_pci_to_global_list()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: find_edac_pci_by_dev: find_edac_pci_by_dev()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_create_sysfs: edac_pci_create_sysfs() idx=0
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_main_kobj_setup: edac_pci_main_kobj_setup()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_main_kobj_setup: Registered '.../edac/pci' kobject
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_create_instance_kobj: edac_pci_create_instance_kobj()
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_create_instance_kobj: edac_pci_create_instance_kobj() Register instance 'pci0' kobject
Jan 29 19:05:39 gentoo kernel: EDAC DEBUG: edac_pci_workq_setup: edac_pci_workq_setup()
Jan 29 19:05:39 gentoo kernel: EDAC PCI0: Giving out device to module 'amd64_edac' controller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED)
Jan 29 19:05:39 gentoo kernel: cpuidle: using governor ladder
Jan 29 19:05:39 gentoo kernel: cpuidle: using governor menu
Jan 29 19:05:39 gentoo kernel: input: C-Media USB Headphone Set as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.3/input/input2
Jan 29 19:05:39 gentoo kernel: generic-usb 0003:0D8C:000C.0001: input,hidraw0: USB HID v1.00 Device [C-Media USB Headphone Set ] on usb-0000:00:12.1-1/input3
Jan 29 19:05:39 gentoo kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.0/input/input3
Jan 29 19:05:39 gentoo kernel: generic-usb 0003:046D:C52B.0002: input,hidraw1: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:12.1-2/input0
Jan 29 19:05:39 gentoo kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.1/input/input4
Jan 29 19:05:39 gentoo kernel: generic-usb 0003:046D:C52B.0003: input,hiddev0,hidraw2: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:12.1-2/input1
Jan 29 19:05:39 gentoo kernel: generic-usb 0003:046D:C52B.0004: hiddev0,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:12.1-2/input2
Jan 29 19:05:39 gentoo kernel: input: HID 046a:0011 as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.0/input/input5
Jan 29 19:05:39 gentoo kernel: generic-usb 0003:046A:0011.0005: input,hidraw4: USB HID v1.10 Keyboard [HID 046a:0011] on usb-0000:00:12.1-3/input0
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver usbhid
Jan 29 19:05:39 gentoo kernel: usbhid: USB HID core driver
Jan 29 19:05:39 gentoo kernel: usbcore: registered new interface driver snd-usb-audio
Jan 29 19:05:39 gentoo kernel: ALSA device list:
Jan 29 19:05:39 gentoo kernel: #0: C-Media USB Headphone Set at usb-0000:00:12.1-1, full speed
Jan 29 19:05:39 gentoo kernel: Netfilter messages via NETLINK v0.30.
Jan 29 19:05:39 gentoo kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Jan 29 19:05:39 gentoo kernel: ctnetlink v0.93: registering with nfnetlink.
Jan 29 19:05:39 gentoo kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Jan 29 19:05:39 gentoo kernel: TCP cubic registered
Jan 29 19:05:39 gentoo kernel: NET: Registered protocol family 17
Jan 29 19:05:39 gentoo kernel: powernow-k8: Found 1 AMD Phenom(tm) II X4 955 Processor (4 cpu cores) (version 2.20.00)
Jan 29 19:05:39 gentoo kernel: powernow-k8: 0 : pstate 0 (3200 MHz)
Jan 29 19:05:39 gentoo kernel: powernow-k8: 1 : pstate 1 (2500 MHz)
Jan 29 19:05:39 gentoo kernel: powernow-k8: 2 : pstate 2 (2100 MHz)
Jan 29 19:05:39 gentoo kernel: powernow-k8: 3 : pstate 3 (800 MHz)
Jan 29 19:05:39 gentoo kernel: rtc_cmos 00:03: setting system clock to 2011-01-29 18:05:38 UTC (1296324338)
Jan 29 19:05:39 gentoo kernel: EXT4-fs (sdb2): mounted filesystem without journal. Opts: (null)
Jan 29 19:05:39 gentoo kernel: VFS: Mounted root (ext4 filesystem) readonly on device 8:18.
Jan 29 19:05:39 gentoo kernel: devtmpfs: mounted
Jan 29 19:05:39 gentoo kernel: Freeing unused kernel memory: 596k freed
Jan 29 19:05:39 gentoo kernel: EXT4-fs (sdb2): re-mounted. Opts: (null)
Jan 29 19:05:39 gentoo kernel: EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
Jan 29 19:05:39 gentoo kernel: XFS mounting filesystem sda2
Jan 29 19:05:39 gentoo kernel: Ending clean XFS mount for filesystem: sda2
Jan 29 19:05:39 gentoo kernel: ATL1E 0000:02:00.0: irq 40 for MSI/MSI-X
Jan 29 19:05:39 gentoo kernel: ATL1E 0000:02:00.0: eth0: NIC Link is Up <100 Mbps Full Duplex>
Jan 29 19:05:39 gentoo kernel: udev[916]: starting version 164
# dmidecode -t memory
# dmidecode 2.10
SMBIOS 2.5 present.
Handle 0x0034, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x0036, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0034
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: None
Locator: DIMM0
Bank Locator: BANK0
Type: DDR
Type Detail: Synchronous
Speed: 1333 MHz
Manufacturer: Manufacturer00
Serial Number: SerNum00
Asset Tag: AssetTagNum0
Part Number: ModulePartNumber00
Handle 0x0038, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0034
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: None
Locator: DIMM1
Bank Locator: BANK1
Type: DDR
Type Detail: Synchronous
Speed: 1333 MHz
Manufacturer: Manufacturer01
Serial Number: SerNum01
Asset Tag: AssetTagNum1
Part Number: ModulePartNumber01
Handle 0x003A, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0034
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: None
Locator: DIMM2
Bank Locator: BANK2
Type: DDR
Type Detail: Synchronous
Speed: 1333 MHz
Manufacturer: Manufacturer02
Serial Number: SerNum02
Asset Tag: AssetTagNum2
Part Number: ModulePartNumber02
Handle 0x003C, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0034
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: None
Locator: DIMM3
Bank Locator: BANK3
Type: DDR
Type Detail: Synchronous
Speed: 1333 MHz
Manufacturer: Manufacturer03
Serial Number: SerNum03
Asset Tag: AssetTagNum3
Part Number: ModulePartNumber03
Memory type: 2x Kingston ValueRAM KVR1333D3E9SK2/4G
--
Markus
^ permalink raw reply
* avoid ip forward replaces the source MAC address
From: Elvis Yoan Tamayo Mollares @ 2011-02-01 19:27 UTC (permalink / raw)
To: kernelnewbies
hi list, during ip forwarding process, the kernel replace the source MAC
address of the package it received with my own MAC address.. My question
is: Is there any way to avoid this behavior?
Regards.
^ permalink raw reply
* Re: poky-image-sato-sdk failed at do_rootfs
From: Wolfgang Denk @ 2011-02-01 19:27 UTC (permalink / raw)
To: Richard Purdie; +Cc: poky@yoctoproject.org
In-Reply-To: <1296567139.13501.19158.camel@rex>
Dear Richard Purdie,
In message <1296567139.13501.19158.camel@rex> you wrote:
>
> Can you please try a build from scratch. I think most of your .ipk files
> look corrupt as there are many eglibc dependencies in there which there
> simply shouldn't be. If they were built whilst eglibc was rebuilding
> that would explain the problem but it means your build directory is
> unstable now :(. If there is a root cause, the above patch isn't it.
I just ran a build of poky-image-sato-sdk for qemuarm from scratch,
mainline code, git commit id 4c8f498
Result:
...
| ccache gcc -m32 -pipe -std=gnu99 -Wall -W -Wextra -fPIC -D_LARGEFILE64_SOURCE -D_ATFILE_SOURCE -m32 -DPSEUDO_PREFIX='"/opt/poky/build/mainline-4c8f498/tmp/sysroots/x86_64-linux/usr"' -DPSEUDO_SUFFIX='""' -DPSEUDO_BINDIR='"bin"' -DPSEUDO_LIBDIR='"lib/pseudo/lib"' -DPSEUDO_LOCALSTATEDIR='"var/pseudo"' -DPSEUDO_VERSION='"0.3"' -O2 -g -L/opt/poky/build/mainline-4c8f498/tmp/sysroots/x86_64-linux/usr/lib -I/opt/poky/build/mainline-4c8f498/tmp/sysroots/x86_64-linux/usr/include -Wl,-R/opt/poky/build/mainline-4c8f498/tmp/sysroots/x86_64-linux/usr/lib -shared -o lib/pseudo/lib/libpseudo.so \
| pseudo_client.o pseudo_ipc.o \
| pseudo_wrappers.o pseudo_tables.o pseudo_util.o -ldl
| /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.5.1/libgcc_s.so when searching for -lgcc_s
| /usr/bin/ld: cannot find -lgcc_s
| collect2: ld returned 1 exit status
| make: *** [lib/pseudo/lib/libpseudo.so] Error 1
| FATAL: oe_runmake failed
| Function 'do_compile' failed (see /opt/poky/build/mainline-4c8f498/tmp/work/x86_64-linux/pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17/temp/log.do_compile.17807 for further information)
NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_compile: Failed
ERROR: 'virtual:native:/opt/poky/git/poky/work/meta/recipes-devtools/pseudo/pseudo_git.bb' failed
ERROR: Task 7 (virtual:native:/opt/poky/git/poky/work/meta/recipes-devtools/pseudo/pseudo_git.bb, do_compile) failed with exit code '1'
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Copy from one, it's plagiarism; copy from two, it's research.
^ permalink raw reply
* Re: [PATCH] libxc: maintain a small, per-handle, cache of hypercall buffer memory
From: Ian Jackson @ 2011-02-01 19:26 UTC (permalink / raw)
To: Ian Campbell; +Cc: Zheng, Shan, xen-devel, Haitao, Shaohui
In-Reply-To: <2839f3e69c7667e25ce6.1296552739@localhost.localdomain>
Ian Campbell writes ("[Xen-devel] [PATCH] libxc: maintain a small, per-handle, cache of hypercall buffer memory"):
> libxc: maintain a small, per-handle, cache of hypercall buffer memory
Applied, thanks.
Ian.
^ permalink raw reply
* Re: Nvidia 9500GT Xen VGA passthru
From: Anish Patel @ 2011-02-01 19:26 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: xen-devel, Peter van der Maas, xen-users
In-Reply-To: <20110131192615.GC2754@reaktio.net>
Hi All,
I have managed to get the 2nd vga passed though. I had to use
AMD/ATI card to get this done.
Thanks
Anish
On 01/31/11 14:26, Pasi Kärkkäinen wrote:
> On Mon, Jan 31, 2011 at 11:39:51AM -0500, Anish Patel wrote:
>> I have this almost working now, I think the only thing that i need to
>> change is to add a gfx_passthru=2 option to let xen know not to read
>> from /dev/mem then an option to tell it what VGA rom to use. Are there
>> any patches for 4.01 for this?
>>
> I think gfx_passthru can only use 0 or 1 nowadays.
>
> Patches probably need to be forward-ported to current Xen..
> most of them are for xen-unstable from the Xen 3.5 days..
>
> -- Pasi
>
>> Thanks
>> Anish
>> On 01/31/11 06:50, Pasi Kärkkäinen wrote:
>>> On Sun, Jan 30, 2011 at 12:42:56AM -0500, Peter van der Maas wrote:
>>>> I really have not played with too much after the proof of concept. I do recall something eventually breaking the config, perhaps a Xen update. I've since put the hardware to better use, although I am still intrigued by Xen. At the time, I was working with a team that was giving serious consideration to virtualizing their platform, and what better way to learn than dig in and get my hands dirty.
>>>>
>>>> I tried to include as much detail at the time, with the plethora of different Xen builds, BIOS's updates, etc.
>>>>
>>>> If someone has something specific I can try to help, but doubtful I will be of any use. For example, I did not realize Xen 4.x was even released. Recent projects I've been working on do not lend themselves well to virtualization; however, I might have to give Xen 4.0 shot - just to play, of course. There were some serious changes happening with Xen, the Linux kernel, and KVM when I stopped playing.
>>>>
>>> Ok.
>>>
>>> I mainly meant if you remember what custom patches did you have to use/create?
>>> Most probably you had to do some vBar=pBar hacking, right?
>>>
>>> I guess I'll have to try this myself one day and document the process
>>> with current Xen versions..
>>>
>>> -- Pasi
>>>
>>>
>>>> Sorry I could not be of more help.
>>>>
>>>> Peter van der Maas
>>>> peter&pjv-c.com
>>>>
>>>> -----Original Message-----
>>>> From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
>>>> Sent: Saturday, January 29, 2011 2:04 PM
>>>> To: Peter van der Maas
>>>> Cc: xen-users@lists.xensource.com; anish.mailing.list@gmail.com; xen-devel@lists.xensource.com
>>>> Subject: Nvidia 9500GT Xen VGA passthru
>>>>
>>>>
>>>> Hello Peter,
>>>>
>>>> Some people have been asking for tips about Nvidia Xen VGA passthru,
>>>> so maybe you could help?
>>>>
>>>> Could you post the exact steps you did?
>>>>
>>>> Have you tried with Xen 4.0.x after your initial experiments in 2009?
>>>>
>>>> Thanks!
>>>>
>>>> -- Pasi
>>>>
>>>> On Mon, Jan 26, 2009 at 02:16:32PM -0500, Peter J. van der Maas wrote:
>>>>> I am happy to announce that I have successfully (and finally!) been able
>>>>> to pass a PCIe graphics card via VT-d to a Windows XP HVM DomU.
>>>>>
>>>>>
>>>>>
>>>>> About time!
>>>>>
>>>>>
>>>>>
>>>>> Config:
>>>>>
>>>>> -Intel Q6600 Core 2 Quad-Core, G0 stepping (I think)
>>>>>
>>>>> -Intel DQ35JO Motherboard, Q35 Chipset, BIOS v.991 (1/9/09), VT and VT-d
>>>>> enabled
>>>>>
>>>>> -nVidia 9500GT (for VT-d passthrough - DomU)
>>>>>
>>>>> -nVidia GeForce2 MX200 (Dom0 console)
>>>>>
>>>>> -Xen (build: xen-unstable, recent as of ~ 1/25/09 1:00AM-EST)
>>>>>
>>>>> -Dom0: Linux-2.6.18.8-xen (via xen-unstable.hg)
>>>>>
>>>>> -DomU: Windows XP (pro, sp3, 32-bit)
>>>>>
>>>>>
>>>>>
>>>>> Once the VT-d bugs were recently corrected (thank you, xen-devel!),
>>>>> everything went fairly smoothly. Still very buggy yet (its
>>>>> xen-unstable!), but overall it works.
>>>>>
>>>>>
>>>>>
>>>>> Make sure support for the PCI-backend is compiled into the kernel (not
>>>>> just a module) and that you have your pciback.hide options in grub
>>>>> (late-binding may work, but I haven't tried).
>>>>>
>>>>>
>>>>>
>>>>> Good luck!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Peter van der Maas
>>>>> _______________________________________________
>>>>> Xen-users mailing list
>>>>> Xen-users@lists.xensource.com
>>>>> http://lists.xensource.com/xen-users
^ permalink raw reply
* Re: [PATCH] ptrace: use safer wake up on ptrace_detach()
From: Oleg Nesterov @ 2011-02-01 19:17 UTC (permalink / raw)
To: Tejun Heo; +Cc: Roland McGrath, jan.kratochvil, linux-kernel, torvalds, akpm
In-Reply-To: <20110201150727.GP14211@htj.dyndns.org>
On 02/01, Tejun Heo wrote:
>
> Hello,
>
> On Tue, Feb 01, 2011 at 02:40:37PM +0100, Oleg Nesterov wrote:
> > On 02/01, Tejun Heo wrote:
> > >
> > > --- work.orig/kernel/ptrace.c
> > > +++ work/kernel/ptrace.c
> > > @@ -313,7 +313,7 @@ int ptrace_detach(struct task_struct *ch
> > > child->exit_code = data;
> > > dead = __ptrace_detach(current, child);
> > > if (!child->exit_state)
> > > - wake_up_process(child);
> > > + wake_up_state(child, TASK_TRACED | TASK_STOPPED);
> >
> > Well, it can't be TASK_TRACED at this point. And of course this still
> > contradicts to __set_task_state(child, TASK_STOPPED) in ptrace_untrace().
> > IOW, to me the previous patch makes more sense.
>
> Yeah, it can't be in TRACED but the whole point of the patch is
> avoiding rude wakeups, so as long as it doesn't end up waking random
> [un]interruptible sleeps... It will be removed later anyway.
Yes, yes, I understand.
> > But OK, I understand Roland's concerns. And, at least this change
> > fixes the bug mentioned in 95a3540d.
> >
> > Acked-by: Oleg Nesterov <oleg@redhat.com>
>
> Oleg, Roland, you guys are the maintainers, so how do you guys want to
> route the patches which have been acked?
Well. I know only one way, send it to akpm ;)
> As it's likely that there
> will be quite some number of ptrace patches, it will be better to have
> a git tree.
Probably yes... but everything in this area goes through -mm so far.
Oleg.
^ permalink raw reply
* Re: [PATCH] libxl: fix unsafe subtraction in libxl_set_memory_target
From: Ian Jackson @ 2011-02-01 19:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel
In-Reply-To: <alpine.DEB.2.00.1102011636410.7277@kaball-desktop>
Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl: fix unsafe subtraction in libxl_set_memory_target"):
> The current libxl_set_memory_target function subtracts a negative amount
> from an uint32_t variable without checking if the operation wraps
> around.
>
> This patch fixes this bug (that I previously believed to be an
> hypervisor issue):
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1729
Applied, thanks.
Ian.
^ permalink raw reply
* [PATCH] mount.cifs: fix possible use of uninitialized variable
From: Jeff Layton @ 2011-02-01 19:24 UTC (permalink / raw)
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA
It's possible to "goto return_i" in this function at several points
before line_buf is set. At that point, the NULL pointer check won't
work correctly and we can end up with a SIGSEGV.
Signed-off-by: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
---
mount.cifs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mount.cifs.c b/mount.cifs.c
index 5f29761..3a2b539 100644
--- a/mount.cifs.c
+++ b/mount.cifs.c
@@ -636,7 +636,7 @@ parsing_err:
static int open_cred_file(char *file_name,
struct parsed_mount_info *parsed_info)
{
- char *line_buf;
+ char *line_buf = NULL;
char *temp_val = NULL;
FILE *fs = NULL;
int i;
--
1.7.3.5
^ permalink raw reply related
* Re: [PATCH] tools: disable linker --as-needed option
From: Ian Jackson @ 2011-02-01 19:23 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xensource.com, Nathan March, Jan Beulich
In-Reply-To: <1296556074.13091.73.camel@zakaz.uk.xensource.com>
Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: disable linker --as-needed option"):
> My usual measure for this stuff is Debian. It seems Debian Lenny
> (current stable, just about) has 2.18, Etch (previous stable) has 2.17
> and Sarge (one before that) has 2.15. I think we can simply make the use
> of this option unconditional.
Right, thanks, applied.
Ian.
^ permalink raw reply
* Re: [PATCH] virtio_blk: allow re-reading config space at runtime
From: Christoph Hellwig @ 2011-02-01 19:21 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Christoph Hellwig, Rusty Russell, linux-kernel
In-Reply-To: <20110201183827.GB24924@redhat.com>
On Tue, Feb 01, 2011 at 08:38:27PM +0200, Michael S. Tsirkin wrote:
> Should not be hard to solve.
> If it's running, it is ok to requeue. I don't remember offhand if it's
> ok to requeue if it's queued but not running, if not we could have a
> flag that signals that's the case.
Looks like the workqueue infrastructure does indeed handle requing
an pending work_struct, and we're free to reuse it from the point
just before the callback is called.
Does the version below look okay?
---
From: Christoph Hellwig <hch@lst.de>
Subject: [PATCH v2] virtio_blk: allow re-reading config space at runtime
Wire up the virtio_driver config_changed method to get notified about
config changes raised by the host. For now we just re-read the device
size to support online resizing of devices, but once we add more
attributes that might be changeable they could be added as well.
Note that the config_changed method is called from irq context, so
we'll have to use the workqueue infrastructure to provide us a proper
user context for our changes.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/drivers/block/virtio_blk.c
===================================================================
--- linux-2.6.orig/drivers/block/virtio_blk.c 2010-12-01 09:30:59.647253809 -0700
+++ linux-2.6/drivers/block/virtio_blk.c 2011-02-01 12:10:02.803164641 -0700
@@ -6,10 +6,12 @@
#include <linux/virtio.h>
#include <linux/virtio_blk.h>
#include <linux/scatterlist.h>
+#include <linux/string_helpers.h>
#define PART_BITS 4
static int major, index;
+struct workqueue_struct *virtblk_wq;
struct virtio_blk
{
@@ -26,6 +28,9 @@ struct virtio_blk
mempool_t *pool;
+ /* Process context for config space updates */
+ struct work_struct config_work;
+
/* What host tells us, plus 2 for header & tailer. */
unsigned int sg_elems;
@@ -291,6 +296,47 @@ static ssize_t virtblk_serial_show(struc
}
DEVICE_ATTR(serial, S_IRUGO, virtblk_serial_show, NULL);
+static void virtblk_config_changed_work(struct work_struct *work)
+{
+ struct virtio_blk *vblk =
+ container_of(work, struct virtio_blk, config_work);
+ struct virtio_device *vdev = vblk->vdev;
+ struct request_queue *q = vblk->disk->queue;
+ char cap_str_2[10], cap_str_10[10];
+ u64 capacity, size;
+
+ /* Host must always specify the capacity. */
+ vdev->config->get(vdev, offsetof(struct virtio_blk_config, capacity),
+ &capacity, sizeof(capacity));
+
+ /* If capacity is too big, truncate with warning. */
+ if ((sector_t)capacity != capacity) {
+ dev_warn(&vdev->dev, "Capacity %llu too large: truncating\n",
+ (unsigned long long)capacity);
+ capacity = (sector_t)-1;
+ }
+
+ size = capacity * queue_logical_block_size(q);
+ string_get_size(size, STRING_UNITS_2, cap_str_2, sizeof(cap_str_2));
+ string_get_size(size, STRING_UNITS_10, cap_str_10, sizeof(cap_str_10));
+
+ dev_notice(&vdev->dev,
+ "new size: %llu %d-byte logical blocks (%s/%s)\n",
+ (unsigned long long)capacity,
+ queue_logical_block_size(q),
+ cap_str_10, cap_str_2);
+
+ set_capacity(vblk->disk, capacity);
+
+}
+
+static void virtblk_config_changed(struct virtio_device *vdev)
+{
+ struct virtio_blk *vblk = vdev->priv;
+
+ queue_work(virtblk_wq, &vblk->config_work);
+}
+
static int __devinit virtblk_probe(struct virtio_device *vdev)
{
struct virtio_blk *vblk;
@@ -327,6 +373,7 @@ static int __devinit virtblk_probe(struc
vblk->vdev = vdev;
vblk->sg_elems = sg_elems;
sg_init_table(vblk->sg, vblk->sg_elems);
+ INIT_WORK(&vblk->config_work, virtblk_config_changed_work);
/* We expect one virtqueue, for output. */
vblk->vq = virtio_find_single_vq(vdev, blk_done, "requests");
@@ -477,6 +524,8 @@ static void __devexit virtblk_remove(str
{
struct virtio_blk *vblk = vdev->priv;
+ flush_work(&vblk->config_work);
+
/* Nothing should be pending. */
BUG_ON(!list_empty(&vblk->reqs));
@@ -508,27 +557,47 @@ static unsigned int features[] = {
* Use __refdata to avoid this warning.
*/
static struct virtio_driver __refdata virtio_blk = {
- .feature_table = features,
- .feature_table_size = ARRAY_SIZE(features),
- .driver.name = KBUILD_MODNAME,
- .driver.owner = THIS_MODULE,
- .id_table = id_table,
- .probe = virtblk_probe,
- .remove = __devexit_p(virtblk_remove),
+ .feature_table = features,
+ .feature_table_size = ARRAY_SIZE(features),
+ .driver.name = KBUILD_MODNAME,
+ .driver.owner = THIS_MODULE,
+ .id_table = id_table,
+ .probe = virtblk_probe,
+ .remove = __devexit_p(virtblk_remove),
+ .config_changed = virtblk_config_changed,
};
static int __init init(void)
{
+ int error;
+
+ virtblk_wq = alloc_workqueue("md_misc", 0, 0);
+ if (!virtblk_wq)
+ return -ENOMEM;
+
major = register_blkdev(0, "virtblk");
- if (major < 0)
- return major;
- return register_virtio_driver(&virtio_blk);
+ if (major < 0) {
+ error = major;
+ goto out_destroy_workqueue;
+ }
+
+ error = register_virtio_driver(&virtio_blk);
+ if (error)
+ goto out_unregister_blkdev;
+ return 0;
+
+out_unregister_blkdev:
+ unregister_blkdev(major, "virtblk");
+out_destroy_workqueue:
+ destroy_workqueue(virtblk_wq);
+ return error;
}
static void __exit fini(void)
{
unregister_blkdev(major, "virtblk");
unregister_virtio_driver(&virtio_blk);
+ destroy_workqueue(virtblk_wq);
}
module_init(init);
module_exit(fini);
^ permalink raw reply
* Re: User space RAID-6 access
From: Piergiorgio Sartor @ 2011-02-01 19:21 UTC (permalink / raw)
To: NeilBrown; +Cc: Piergiorgio Sartor, linux-raid
In-Reply-To: <20110201075259.4beaf501@notabene.brown>
On Tue, Feb 01, 2011 at 07:52:59AM +1100, NeilBrown wrote:
> On Mon, 31 Jan 2011 21:20:55 +0100 Piergiorgio Sartor
> <piergiorgio.sartor@nexgo.de> wrote:
>
> > Hi all,
> >
> > some times ago, I think was Neil, it was mentioned
> > about the possibility to access consistently a RAID-6
> > array from user space, in order to be able to perform
> > some checks, like the notorius "which HDD has wrong data".
> >
> > Is there any reference or documentation or source code
> > which can be taken as example for such a case?
> >
>
> Look in the mdadm source code, particularly at restripe.c
>
> Also
> make test_stripe
>
> make a program the the test suite uses for verify data correctness.
>
> That should give you enough hints to get you started.
Hi Neil, thanks for the pointer.
I had a look at the code and there is something I did not get.
It seems to me the HDDs composing the array are "simply"
opened with "open".
In case the array is in use, how is avoided a race condition
between the "test_stripe" program and the md device?
I mean, the first could start to read from the HDDs and the
other could write something in the same place, leading to an
inconsistent parity, from the "test_stripe" point of view,
since it missed some update.
Or there is a locking inside md (in "test_stripe" I could
not see and it would also be dangerous)?
Thanks again,
bye,
--
piergiorgio
^ permalink raw reply
* Re: Three small patches for xen-4.1.0-rc
From: Ian Jackson @ 2011-02-01 19:21 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xensource.com, M A Young
In-Reply-To: <1296552004.13091.11.camel@zakaz.uk.xensource.com>
Ian Campbell writes ("Re: [Xen-devel] Three small patches for xen-4.1.0-rc"):
> On Mon, 2011-01-31 at 22:37 +0000, M A Young wrote:
> > Here are three small patches that I have applied to the Fedora xen builds
> > and I think are are suitable for xen-4.1.0.
Thanks, I have applied them.
> Thanks, I general we would prefer separate patches to be submitted
> separately rather than bundled in a single submission ("hg email" can
> help with this for large series).
I agree with Ian's comments.
> > The next patch updates a comment about NetworkManager not supporting
> > bridging in Fedora 11 to refer instead to Fedora 14.
>
> Was the NetworkManager stuff introduced in 14 and erroneously documented
> as being in 11, or was it in 11 and worked fine, or has it been
> continuously broken since F11? IOW should this comment refer to breakage
> in Fedora 11 thru 14 or something similar?
Perhaps you misread the document ? I don't think NetworkManager can
set up a bridge at all. So you just have to disable NetworkManager.
I clarified the wording slightly while applying the patch.
> > The final patch solve a build problem in Fedora rawhide, where rpm (4.9.0)
> > doesn't automatically supply a "provides" entry for a library unless it is
> > executable. This patch makes the libvhd and libblktap library files
> > executable (and consistent with the other libraries in xen) so that rpm
> > generates the right "provides" entries and therefore does the right thing
> > when resolving package dependencies.
>
> Ick, but apparently normal.
Shared libraries are indeed supposed to be executable. This isn't the
only thing that can go wrong if they aren't.
Thanks,
Ian.
^ permalink raw reply
* [Qemu-devel] [PATCH] make tsc stable over migration and machine start
From: Glauber Costa @ 2011-02-01 19:17 UTC (permalink / raw)
To: kvm; +Cc: mtosatti, qemu-devel, avi
If the machine is stopped, we should not record two different tsc values
upon a save operation. The same problem happens with kvmclock.
But kvmclock is taking a different diretion, being now seen as a separate
device. Since this is unlikely to happen with the tsc, I am taking the
approach here of simply registering a handler for state change, and
using a per-CPUState variable that prevents double updates for the TSC.
Signed-off-by: Glauber Costa <glommer@redhat.com>
---
target-i386/cpu.h | 1 +
target-i386/kvm.c | 19 ++++++++++++++++++-
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 6d619e8..7f1c4f8 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -732,6 +732,7 @@ typedef struct CPUX86State {
uint32_t sipi_vector;
uint32_t cpuid_kvm_features;
uint32_t cpuid_svm_features;
+ uint8_t update_tsc;
/* in order to simplify APIC support, we leave this pointer to the
user */
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index ecb8405..c3925be 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -302,6 +302,16 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
static int _kvm_arch_init_vcpu(CPUState *env);
+static void cpu_update_state(void *opaque, int running, int reason)
+{
+ CPUState *env = opaque;
+
+ if (!running) {
+ env->update_tsc = 1;
+ }
+}
+
+
int kvm_arch_init_vcpu(CPUState *env)
{
int r;
@@ -444,6 +454,8 @@ int kvm_arch_init_vcpu(CPUState *env)
}
#endif
+ qemu_add_vm_change_state_handler(cpu_update_state, env);
+
return kvm_vcpu_ioctl(env, KVM_SET_CPUID2, &cpuid_data);
}
@@ -1093,7 +1105,12 @@ static int kvm_get_msrs(CPUState *env)
msrs[n++].index = MSR_STAR;
if (kvm_has_msr_hsave_pa(env))
msrs[n++].index = MSR_VM_HSAVE_PA;
- msrs[n++].index = MSR_IA32_TSC;
+
+ if (env->update_tsc) {
+ msrs[n++].index = MSR_IA32_TSC;
+ env->update_tsc = 0;
+ }
+
#ifdef TARGET_X86_64
if (lm_capable_kernel) {
msrs[n++].index = MSR_CSTAR;
--
1.7.2.3
^ permalink raw reply related
* [U-Boot] PCIE supported networking cards?
From: Scott Wood @ 2011-02-01 19:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1B46169A-A880-41D2-8676-2B62BDCD57CF@kernel.crashing.org>
On Tue, 1 Feb 2011 13:15:01 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
> We utilize e1000 PCIe cards all the time
Aren't there some versions that work, and some that don't?
-Scott
>
> - k
>
> On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:
>
> > Are there any PCIE networking cards that are supported? So far I've
> > tried an Intel card and a Realtek RTL8168 card, but neither is
> > supported. It looks like the E1000 driver only supports PCI and PCIX
> > based cards (Linux uses the e1000e card for PCIe cards).
> >
> > -Aaron
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [PATCH] make tsc stable over migration and machine start
From: Glauber Costa @ 2011-02-01 19:17 UTC (permalink / raw)
To: kvm; +Cc: qemu-devel, avi, mtosatti
If the machine is stopped, we should not record two different tsc values
upon a save operation. The same problem happens with kvmclock.
But kvmclock is taking a different diretion, being now seen as a separate
device. Since this is unlikely to happen with the tsc, I am taking the
approach here of simply registering a handler for state change, and
using a per-CPUState variable that prevents double updates for the TSC.
Signed-off-by: Glauber Costa <glommer@redhat.com>
---
target-i386/cpu.h | 1 +
target-i386/kvm.c | 19 ++++++++++++++++++-
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 6d619e8..7f1c4f8 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -732,6 +732,7 @@ typedef struct CPUX86State {
uint32_t sipi_vector;
uint32_t cpuid_kvm_features;
uint32_t cpuid_svm_features;
+ uint8_t update_tsc;
/* in order to simplify APIC support, we leave this pointer to the
user */
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index ecb8405..c3925be 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -302,6 +302,16 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
static int _kvm_arch_init_vcpu(CPUState *env);
+static void cpu_update_state(void *opaque, int running, int reason)
+{
+ CPUState *env = opaque;
+
+ if (!running) {
+ env->update_tsc = 1;
+ }
+}
+
+
int kvm_arch_init_vcpu(CPUState *env)
{
int r;
@@ -444,6 +454,8 @@ int kvm_arch_init_vcpu(CPUState *env)
}
#endif
+ qemu_add_vm_change_state_handler(cpu_update_state, env);
+
return kvm_vcpu_ioctl(env, KVM_SET_CPUID2, &cpuid_data);
}
@@ -1093,7 +1105,12 @@ static int kvm_get_msrs(CPUState *env)
msrs[n++].index = MSR_STAR;
if (kvm_has_msr_hsave_pa(env))
msrs[n++].index = MSR_VM_HSAVE_PA;
- msrs[n++].index = MSR_IA32_TSC;
+
+ if (env->update_tsc) {
+ msrs[n++].index = MSR_IA32_TSC;
+ env->update_tsc = 0;
+ }
+
#ifdef TARGET_X86_64
if (lm_capable_kernel) {
msrs[n++].index = MSR_CSTAR;
--
1.7.2.3
^ permalink raw reply related
* [PATCH] e2fsprogs: Fix how we treat user-spcified filesystem size
From: Lukas Czerner @ 2011-02-01 19:18 UTC (permalink / raw)
To: linux-ext4; +Cc: tytso, lczerner
mke2fs and resize2fs allows specifying filesystem size as a parameter,
former called as blocks-count. However it has been a little bit messy so
this commit fixes it mainly by updating man pages.
We can not specify filesystem size in blocks count withou specifying
blocksize as well. It is because we need blocks count to determine
filesystem type, and we need filesystem type to determine blocksize. So
it should not be allowed, however due to compatibility reason it should
be still possible, so at least print warning message for now, so we can
easily restrict that later.
Filesystem size can be specified using units as suffixes. This was not
documented for mke2fs, so this commits adds proper documentation into
mke2fs man page.
For the sake of completeness add 'b' (blocks count) unit.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
---
lib/e2p/parse_num.c | 9 +++++++++
misc/mke2fs.8.in | 40 ++++++++++++++++++++++++++++++++++------
resize/resize2fs.8.in | 8 ++++----
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/lib/e2p/parse_num.c b/lib/e2p/parse_num.c
index 83a329a..5e7924b 100644
--- a/lib/e2p/parse_num.c
+++ b/lib/e2p/parse_num.c
@@ -10,6 +10,7 @@
*/
#include "e2p.h"
+#include "../misc/nls-enable.h"
#include <stdlib.h>
@@ -37,6 +38,14 @@ unsigned long long parse_num_blocks2(const char *arg, int log_block_size)
num >>= (1+log_block_size);
break;
case '\0':
+ case 'b':
+ if (!log_block_size) {
+ fprintf(stderr,
+ _("Warning: You can not specify blocks count "
+ "without specifying block size '-b'. Will "
+ "assume kilobytes instead of blocks count!.\n"
+ ));
+ }
break;
default:
return 0;
diff --git a/misc/mke2fs.8.in b/misc/mke2fs.8.in
index 2eead17..67a69b8 100644
--- a/misc/mke2fs.8.in
+++ b/misc/mke2fs.8.in
@@ -108,7 +108,7 @@ mke2fs \- create an ext2/ext3/ext4 filesystem
]
.I device
[
-.I blocks-count
+.I filesystem-size
]
@JDEV@.sp
@JDEV@.B "mke2fs \-O journal_dev"
@@ -136,7 +136,7 @@ mke2fs \- create an ext2/ext3/ext4 filesystem
@JDEV@]
@JDEV@.I external-journal
@JDEV@[
-@JDEV@.I blocks-count
+@JDEV@.I filesystem-size
@JDEV@]
.SH DESCRIPTION
.B mke2fs
@@ -145,15 +145,43 @@ partition.
.I device
is the special file corresponding to the device (e.g
.IR /dev/hdXX ).
-.I blocks-count
-is the number of blocks on the device. If omitted,
-.B mke2fs
-automagically figures the file system size. If called as
+.I filesystem-size
+is the size of the filesystem you want to create.
+If no units are specified, the units of the
+.I filesystem-size
+parameter shall be the blocks count of the filesystem. Keep in mind that
+you can not specify
+.I filesystem-size
+in blocks count without specifying the blocksize as well. This will be
+allowed for now (kilobytes will be assumed)
+due to compatibility reasons, however it may be restricted
+in the future.
+Optionally, the
+.I filesystem-size
+parameter may be suffixed by one of the following the units
+designators: 'b', 's', 'K', 'M', or 'G',
+for blocks count, 512 byte sectors, kilobytes, megabytes, or gigabytes,
+respectively.
+The
+.I filesystem-size
+may never be larger than the size of the partition.
+If
+.I filesystem-size
+parameter is not specified, it will default to the size of the partition.
+If called as
.B mkfs.ext3
a journal is created as if the
.B \-j
option was specified.
.PP
+Note: when kilobytes is used above, I mean
+.IR real ,
+power-of-2 kilobytes, (i.e., 1024 bytes), which some politically correct
+folks insist should be the stupid-sounding ``kibibytes''. The same
+holds true for megabytes, also sometimes known as ``mebibytes'', or
+gigabytes, as the amazingly silly ``gibibytes''. Makes you want to
+gibber, doesn't it?
+.PP
The defaults of the parameters for the newly created filesystem, if not
overridden by the options listed below, are controlled by the
.B /etc/mke2fs.conf
diff --git a/resize/resize2fs.8.in b/resize/resize2fs.8.in
index e02345d..52aaef8 100644
--- a/resize/resize2fs.8.in
+++ b/resize/resize2fs.8.in
@@ -38,13 +38,13 @@ The
parameter specifies the requested new size of the filesystem.
If no units are specified, the units of the
.I size
-parameter shall be the filesystem blocksize of the filesystem.
+parameter shall be the blocks count of the filesystem.
Optionally, the
.I size
parameter may be suffixed by one of the following the units
-designators: 's', 'K', 'M', or 'G',
-for 512 byte sectors, kilobytes, megabytes, or gigabytes, respectively.
-The
+designators: 'b', 's', 'K', 'M', or 'G',
+for blocks count, 512 byte sectors, kilobytes, megabytes, or gigabytes,
+respectively. The
.I size
of the filesystem may never be larger than the size of the partition.
If
--
1.7.2.3
^ permalink raw reply related
* [PATCH v2] release kvmclock page on reset
From: Glauber Costa @ 2011-02-01 19:16 UTC (permalink / raw)
To: kvm; +Cc: linux-kernel, aliguori, Jan Kiszka
When a vcpu is reset, kvmclock page keeps being writen to this days.
This is wrong and inconsistent: a cpu reset should take it to its
initial state.
Signed-off-by: Glauber Costa <glommer@redhat.com>
CC: Jan Kiszka <jan.kiszka@siemens.com>
---
arch/x86/kvm/x86.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bcc0efc..c39ab4a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1453,6 +1453,14 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
return 0;
}
+static void kvmclock_reset(struct kvm_vcpu *vcpu)
+{
+ if (vcpu->arch.time_page) {
+ kvm_release_page_dirty(vcpu->arch.time_page);
+ vcpu->arch.time_page = NULL;
+ }
+}
+
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
{
switch (msr) {
@@ -1510,10 +1518,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
break;
case MSR_KVM_SYSTEM_TIME_NEW:
case MSR_KVM_SYSTEM_TIME: {
- if (vcpu->arch.time_page) {
- kvm_release_page_dirty(vcpu->arch.time_page);
- vcpu->arch.time_page = NULL;
- }
+ kvmclock_reset(vcpu);
vcpu->arch.time = data;
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
@@ -5814,10 +5819,7 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
{
- if (vcpu->arch.time_page) {
- kvm_release_page_dirty(vcpu->arch.time_page);
- vcpu->arch.time_page = NULL;
- }
+ kvmclock_reset(vcpu);
free_cpumask_var(vcpu->arch.wbinvd_dirty_mask);
fx_free(vcpu);
@@ -5878,6 +5880,8 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
kvm_make_request(KVM_REQ_EVENT, vcpu);
vcpu->arch.apf.msr_val = 0;
+ kvmclock_reset(vcpu);
+
kvm_clear_async_pf_completion_queue(vcpu);
kvm_async_pf_hash_reset(vcpu);
vcpu->arch.apf.halted = false;
--
1.7.2.3
^ permalink raw reply related
* [PATCH] gpu/stub: fix acpi_video build error, fix stub kconfig dependencies
From: Randy Dunlap @ 2011-02-01 19:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Len Brown, Stephen Rothwell, Luming Yu, linux-next, LKML,
linux-acpi, Linus Torvalds, Andrew Morton, Rafael J. Wysocki
In-Reply-To: <20110201120323.GA6714@elte.hu>
From: Randy Dunlap <randy.dunlap@oracle.com>
The comments under "config STUB_POULSBO" are close to correct,
but they are not being followed. This patch updates them to reflect
the requirements for THERMAL.
This build error is caused by STUB_POULSBO selecting ACPI_VIDEO
when ACPI_VIDEO's config requirements are not met.
ERROR: "thermal_cooling_device_register" [drivers/acpi/video.ko] undefined!
ERROR: "thermal_cooling_device_unregister" [drivers/acpi/video.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/gpu/stub/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--- lnx-2638-rc3.orig/drivers/gpu/stub/Kconfig
+++ lnx-2638-rc3/drivers/gpu/stub/Kconfig
@@ -1,11 +1,13 @@
config STUB_POULSBO
tristate "Intel GMA500 Stub Driver"
depends on PCI
+ depends on NET # for THERMAL
# Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
select ACPI_VIDEO if ACPI
+ select THERMAL if ACPI
help
Choose this option if you have a system that has Intel GMA500
(Poulsbo) integrated graphics. If M is selected, the module will
^ permalink raw reply
* RE: XFS Preallocation
From: Peter Vajgel @ 2011-02-01 19:20 UTC (permalink / raw)
To: Dave Chinner; +Cc: Jef Fox, xfs@oss.sgi.com
In-Reply-To: <20110201080354.GM11040@dastard>
> -----Original Message-----
> From: Dave Chinner [mailto:david@fromorbit.com]
> Sent: Tuesday, February 01, 2011 12:04 AM
> To: Peter Vajgel
> Cc: Jef Fox; xfs@oss.sgi.com
> Subject: Re: XFS Preallocation
>
> On Tue, Feb 01, 2011 at 04:45:09AM +0000, Peter Vajgel wrote:
> > > Preallocation is the only option. Allowing preallocation without
> > > marking extents as unwritten opens a massive security hole (i.e.
> > > exposes stale data) so I say no to any request for addition of such
> > > functionality (and have for years).
> >
> > How about opening this option to at least root (root can already read
> > the device anyway)?.
>
> # ls -l foo
> -rw-r--r-- 1 dave dave 0 Aug 16 10:44 foo
> #
> # prealloc_without_unwritten 0 1048576 foo # ls -l foo
> -rw-r--r-- 1 dave dave 1048576 Aug 16 10:44 foo #
>
> Now user dave can read the stale data exposed by the root only operation. Any
> combination of making the file available to a non-root user after a preallocation-
> without-unwritten-extents
> operation has this problem. IOWs, just making such a syscall "root only" doesn't
> solve the security problem.
Correct - if an admin made prealloc_without_unwritten runnable by any user then yes - but I would argue that such an admin should not even have root privileges. Vxfs had this ability since version 1 and I don't' remember a single customer complaint about this feature. Most of the times the feature was used by db to preallocate large amounts of space knowing that they won't incur any overhead (even transactional) when doing direct io to the pre-allocated range. It could be that at those times even a transactional overhead was significant enough that we wanted to eliminate it.
>
> To fix it, we have to require inodes have 0600 perms, owned by root, and cannot be
> chmod/chowned to anyone else, ever. At that point, we're requiring applications to run
> as root to to use this functionality. Same requirement as fiemap + reading from the
> block device, which you can do right without any kernel mods or filesystem hacks...
>
> > There are cases when creating large
> > files without writing to them is important. A good example is testing
> > xfs overhead when doing a specific workload (like random
> > reads) to large files.
>
> For testing it doesn't matter how long it takes you to write the file in the first place.
At the scale we operate it does. We have multiple variables so the number of combinations is large. We have hit every single possible hardware and software problem and problem resolution can take months if it takes days to reproduce the problem. Hardware vendors (disk, controller, motherboard manufacturers) are much more responsive when you can reproduce a problem on the fly in seconds (especially in comparative benchmarking). The tests usually run only couple of minutes. With 12x3TB (possibly multiplied by a factor of X with our new platform) it would be unacceptable to wait for writes to finish.
>
> > In this case we want to hit the disk on every request. Currently we
> > have a workaround (below) but official support would be preferable.
>
> Officially, we _removed_ the unwritten=0 option from mkfs because of the security
> problems. Not to mention that it was never, ever tested...
>
> >
> > --pv
> >
> >
> > # create_xfs_files
> >
> > dev=$1
> > mntpt=$2
> > dircount=$3
> > filecount=$4
> > size=$5
> >
> > # Umount.
> > umount $2
> >
> > # Create the fs.
> > mkfs -t xfs -f -d unwritten=0,su=256k,sw=10 -l su=256k -L "/hay" $dev
>
> Which fails due to:
>
> unknown option -d unwritten=0
> /* blocksize */ [-b log=n|size=num]
> /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num,
> (sunit=value,swidth=value|su=num,sw=num),
> sectlog=n|sectsize=num .....
It still works for us but we tend to be conservative in moving our releases.
>
> > # Clear unwritten flag - current xfs ignores this flag typeset -i
> > agcount=$(xfs_db -c "sb" -c "print" $dev | grep agcount) typeset -i
> > i=0 while [[ $i != $agcount ]] do
> > xfs_db -x -c "sb $i" -c "write versionnum 0xa4a4" $dev
> > i=i+1
> > done
> >
> > # Mount the filesystem.
> > mount -t xfs -o nobarrier,noatime,nodiratime,inode64,allocsize=1g $dev
> > $mntpt
> >
> > i=0
> > while [[ $i != $dircount ]]
> > do
> > mkdir $mntpt/dir$i
> > typeset -i j=0
> > while [[ $j != $filecount ]]
> > do
> > file=$mntpt/dir$i/file$j
> > xfs_io -f -c "resvsp 0 $size" $file
> > inum=$(ls -i $file | awk '{print $1}')
> > umount $mntpt
> > xfs_db -x -c "inode $inum" -c "write core.size $size" $dev
> > mount -t xfs -o nobarrier,noatime,nodiratime,inode64,allocsize=1g
> > $dev $mntpt
>
> That's quite a hack to work around the EOF zeroing that extending the file size after
> allocating would do because the preallocated extents beyond EOF are not marked
> unwritten. Perhaps truncating the file first, then preallocating is what you want:
>
> xfs_io -f -c "truncate $size" -c "resvsp 0 $size" $file
I think I had it in reverse before - allocate and truncate but the truncate got stuck in a loop (probably zeroing out the extents?) making the node unresponsive to the point that it was impossible to ssh to it. It eventually returned but it took a while. But that was like 3 years ago. If I get to it I'll try the other order.
>
> > j=j+1
> > done
> > i=i+1
> > done
>
> Regardless of all this, perhaps themost important point is that your proposed use of
> XFS is fundamentally unsupportable by the linux XFS
> community: you've got proprietary software on some external hardware writing to the
> disk without going through the linux XFS kernel code.
> You're basically in the same boat as people running proprietary kernel modules -
> unless you can prove the problem is not caused by your hw/sw or manual filesystem
> modifications, then it's a waste of our (limited) resources to even look at the problem.
> That generally comes down to being able to reproduce the problem on a vanilla kernel
> on a filesystem created with a supported mkfs....
Understood. That's why I limit this hack only to testing. I would never even dream to put this into production. Although one could assume that if xfs_check/xfs_repair bless the filesystem before it's mounted you would be safe. But then you might be exposing yourself to bugs in xfs_check/xfs_repair which might have been overlooked since it's not the usual way of using xfs.
Thank you,
Peter
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
From: Kumar Gala @ 2011-02-01 19:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1296579706.1995.60.camel@haiying-laptop>
On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote:
> On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
>>>>
>>> If it is a one time setting, there should be no problem to put it into
>>> board code. But these pin settings need to be done before any usage of
>>> phy read/write (accessing MDIO/MDC), and need to be released after the
>>> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
>>> can be accessed. If we use board code to set/release the pin, we don't
>>> know when the phy access and nand flash access will happen.
>>
>> Is this actually a board issue or an SoC issue?
>>
> It is not a board issue. It is a SoC *feature*. Too many pins are muxed
> on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
> which is used for MDIO signal.
>
> Haiying
>
But its a board decision on how they want to utilize those pins and for what feature.
- k
^ permalink raw reply
* Re: [PATCH 1/2] resize2fs: Add support for lazy itable initialization
From: Andreas Dilger @ 2011-02-01 19:15 UTC (permalink / raw)
To: Lukas Czerner; +Cc: linux-ext4, tytso
In-Reply-To: <1296580465-28519-1-git-send-email-lczerner@redhat.com>
On 2011-02-01, at 10:14, Lukas Czerner wrote:
> This commit adds extended options '-E' to the resize2fs code along with
> the first extended option lazy_itable_init=n.
Here it says the option is "=n", is it also possible to force this with "=y"?
> +static void parse_extended_opts(int *flags, const char *opts)
> +{
> + if (!strcmp(token, "lazy_itable_init")) {
> + int lazy;
> + if (arg)
> + lazy = strtoul(arg, &p, 0);
> + else
> + lazy = 1;
> + if (lazy)
> + *flags |= RESIZE_LAZY_ITABLE_INIT;
Here it parses the option as "=0" or "=1", not "=n" or "=y". It looks like "=n" will accidentally return 0 from strtoul(), so that works as expected, but the "=y" option would fail (it would also return 0).
> + if (r_usage) {
> + fprintf(stderr, _("\nBad option(s) specified: %s\n\n"
> + "\tlazy_itable_init=<0 to disable, 1 to enable>\n\n"),
It looks a bit confusing "=<0 to disable", I thought initially that meant any value <= 0 would disable it, though I later see that there is a closing '>'. I think it is more standard to use "{}" braces for "one of these options must be given".
> @@ -232,6 +290,12 @@ int main (int argc, char ** argv)
> + if (access("/sys/fs/ext4/features/lazy_itable_init", R_OK) == 0)
> + flags |= RESIZE_LAZY_ITABLE_INIT;
> +
> + if (extended_opts)
> + parse_extended_opts(&flags, extended_opts);
Good that the command-line options override the default value.
> +.B lazy_itable_init\fR[\fB= \fI<0 to disable, 1 to enable>\fR]
Similarly, this should use "{}" around the options instead of "<>".
> +If enabled and the uninit_bg feature is enabled, the inode table will
> +not be fully initialized by
I would write "not be zeroed out on disk", since it is otherwise unclear
if "not fully initialized" means that there will be less inodes available
or some other issues if the inode table is not "fully" initialized.
Cheers, Andreas
^ permalink raw reply
* [U-Boot] PCIE supported networking cards?
From: Kumar Gala @ 2011-02-01 19:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D485ABE.9010604@caviumnetworks.com>
We utilize e1000 PCIe cards all the time
- k
On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:
> Are there any PCIE networking cards that are supported? So far I've
> tried an Intel card and a Realtek RTL8168 card, but neither is
> supported. It looks like the E1000 driver only supports PCI and PCIX
> based cards (Linux uses the e1000e card for PCIe cards).
>
> -Aaron
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply
* Re: [PATCH V2 5/6] powerpc/44x: boot wrapper: allow kernel to load into non-zero address
From: Scott Wood @ 2011-02-01 19:13 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev
In-Reply-To: <1296586126-32765-6-git-send-email-shaggy@linux.vnet.ibm.com>
On Tue, 1 Feb 2011 12:48:45 -0600
Dave Kleikamp <shaggy@linux.vnet.ibm.com> wrote:
> For AMP, different kernel instances load into separate memory regions.
> Read the start of memory from the device tree and limit the memory to what's
> specified in the device tree.
>
> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/boot/treeboot-iss4xx.c | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/treeboot-iss4xx.c b/arch/powerpc/boot/treeboot-iss4xx.c
> index fcc4495..868c8b4 100644
> --- a/arch/powerpc/boot/treeboot-iss4xx.c
> +++ b/arch/powerpc/boot/treeboot-iss4xx.c
> @@ -34,9 +34,28 @@
>
> BSS_STACK(4096);
>
> +static ibm4xx_memstart;
type?
> +static void *iss_4xx_vmlinux_alloc(unsigned long size)
> +{
> + return ibm4xx_memstart;
> }
Doesn't this generate a warning for implicitly casting int to void *?
-Scott
^ permalink raw reply
* [Buildroot] [git commit master 1/1] ruby: don't build documentation when building for host either
From: Peter Korsgaard @ 2011-02-01 19:14 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=b823c04d080016b28c955240ec634764718041bd
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
We don't use it, so it only slows down the build.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/ruby/ruby.mk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/package/ruby/ruby.mk b/package/ruby/ruby.mk
index adb1862..966a6a1 100644
--- a/package/ruby/ruby.mk
+++ b/package/ruby/ruby.mk
@@ -12,6 +12,8 @@ RUBY_DEPENDENCIES = host-ruby
RUBY_MAKE_ENV = $(TARGET_MAKE_ENV)
RUBY_CONF_OPT = --disable-install-doc
+HOST_RUBY_CONF_OPT = --disable-install-doc
+
# Force optionals to build before we do
ifeq ($(BR2_PACKAGE_BERKELEYDB),y)
RUBY_DEPENDENCIES += berkeleydb
--
1.7.3.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.