linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* "do_IRQ: 0.89 No irq handler for vector (irq -1)"
@ 2010-10-07  8:55 Dave Airlie
  2010-10-07  9:05 ` Dave Airlie
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Dave Airlie @ 2010-10-07  8:55 UTC (permalink / raw)
  To: LKML, Thomas Gleixner, Ingo Molnar, Jesse Barnes

We are seeing this on both intel and radeon drivers when we reload the
module with 2.6.36-rc7 or so, and we get no irqs for that device.

you can reproduce by

init 3
echo 0 > /sys/class/vtconsole/vtcon1/bind
rmmod i915
modprobe i915

or radeon.

It seems to be possibly MSI related.

Dave.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-07  8:55 "do_IRQ: 0.89 No irq handler for vector (irq -1)" Dave Airlie
@ 2010-10-07  9:05 ` Dave Airlie
  2010-10-07 20:38 ` Thomas Gleixner
  2010-10-10 17:46 ` Maciej Rutecki
  2 siblings, 0 replies; 19+ messages in thread
From: Dave Airlie @ 2010-10-07  9:05 UTC (permalink / raw)
  To: LKML, Thomas Gleixner, Ingo Molnar, Jesse Barnes

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

On Thu, Oct 7, 2010 at 6:55 PM, Dave Airlie <airlied@gmail.com> wrote:
> We are seeing this on both intel and radeon drivers when we reload the
> module with 2.6.36-rc7 or so, and we get no irqs for that device.

Here is complete dmesg from the machine.

Dave

[-- Attachment #2: dmesg --]
[-- Type: application/octet-stream, Size: 43108 bytes --]

Linux version 2.6.36-rc6+ (airlied@panop64.bne.redhat.com) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #107 SMP PREEMPT Wed Oct 6 13:57:05 EST 2010
Command line: ro root=/dev/sda5 3 slub_debug=FZPU
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffa0000 (usable)
 BIOS-e820: 000000003ffa0000 - 000000003ffae000 (ACPI data)
 BIOS-e820: 000000003ffae000 - 000000003ffe0000 (ACPI NVS)
 BIOS-e820: 000000003ffe0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AMI BIOS detected: BIOS may corrupt low RAM, working around it.
e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
No AGP bridge found
last_pfn = 0x3ffa0 max_arch_pfn = 0x400000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
  00000-9FFFF write-back
  A0000-DFFFF uncachable
  E0000-EFFFF write-through
  F0000-FFFFF write-protect
MTRR variable ranges enabled:
  0 base 000000000 mask FC0000000 write-back
  1 disabled
  2 disabled
  3 disabled
  4 disabled
  5 disabled
  6 disabled
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
initial memory mapped : 0 - 20000000
found SMP MP-table at [ffff8800000ff780] ff780
init_memory_mapping: 0000000000000000-000000003ffa0000
 0000000000 - 003fe00000 page 2M
 003fe00000 - 003ffa0000 page 4k
kernel direct mapping tables up to 3ffa0000 @ 16000-19000
RAMDISK: 3793f000 - 37ff0000
ACPI: RSDP 00000000000fa520 00024 (v02 ACPIAM)
ACPI: XSDT 000000003ffa0100 00044 (v01 A M I  OEMXSDT  09000528 MSFT 00000097)
ACPI: FACP 000000003ffa0290 000F4 (v03 A M I  OEMFACP  09000528 MSFT 00000097)
ACPI: DSDT 000000003ffa0400 07F6D (v01  A0281 A0281034 00000034 INTL 02002026)
ACPI: FACS 000000003ffae000 00040
ACPI: APIC 000000003ffa0390 00070 (v01 A M I  OEMAPIC  09000528 MSFT 00000097)
ACPI: OEMB 000000003ffae040 00066 (v01 A M I  AMI_OEM  09000528 MSFT 00000097)
ACPI: MCFG 000000003ffa8370 0003C (v01 A M I  OEMMCFG  09000528 MSFT 00000097)
ACPI: Local APIC address 0xfee00000
 [ffffea0000000000-ffffea0000dfffff] PMD -> [ffff880002000000-ffff880002dfffff] on node 0
Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000010 -> 0x0000009f
    0: 0x00000100 -> 0x0003ffa0
On node 0 totalpages: 261935
  DMA zone: 56 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 3927 pages, LIFO batch:0
  DMA32 zone: 3527 pages used for memmap
  DMA32 zone: 254425 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 2 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 40
early_res array is doubled to 64 at [17000 - 177ff]
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000e4000
PM: Registered nosave memory: 00000000000e4000 - 0000000000100000
Allocating PCI resources starting at 40000000 (gap: 40000000:bfb80000)
setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:2 nr_node_ids:1
PERCPU: Embedded 27 pages/cpu @ffff880001800000 s79488 r8192 d22912 u1048576
pcpu-alloc: s79488 r8192 d22912 u1048576 alloc=1*2097152
pcpu-alloc: [0] 0 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 258352
Kernel command line: ro root=/dev/sda5 3 slub_debug=FZPU
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
No AGP bridge found
Subtract (45 early reservations)
  #1 [0001000000 - 00017aba7c]   TEXT DATA BSS
  #2 [003793f000 - 0037ff0000]         RAMDISK
  #3 [00017ac000 - 00017ac280]             BRK
  #4 [00000ff790 - 0000100000]   BIOS reserved
  #5 [00000ff780 - 00000ff790]    MP-table mpf
  #6 [000009fc00 - 00000f0f80]   BIOS reserved
  #7 [00000f10fc - 00000ff780]   BIOS reserved
  #8 [00000f0f80 - 00000f10fc]    MP-table mpc
  #9 [0000010000 - 0000012000]      TRAMPOLINE
  #10 [0000012000 - 0000016000]     ACPI WAKEUP
  #11 [0000016000 - 0000017000]         PGTABLE
  #12 [00017ac280 - 00017ad280]         BOOTMEM
  #13 [00017aba80 - 00017abb40]         BOOTMEM
  #14 [0001fae000 - 0001faf000]         BOOTMEM
  #15 [0001faf000 - 0001fb0000]         BOOTMEM
  #16 [0002000000 - 0002e00000]        MEMMAP 0
  #17 [00017abb40 - 00017abdc0]         BOOTMEM
  #18 [00017ad280 - 00017b7280]         BOOTMEM
  #19 [00017b8000 - 00017b9000]         BOOTMEM
  #20 [00017abdc0 - 00017abe03]         BOOTMEM
  #21 [00017b7280 - 00017b7478]         BOOTMEM
  #22 [00017abe40 - 00017abea8]         BOOTMEM
  #23 [00017abec0 - 00017abf28]         BOOTMEM
  #24 [00017abf40 - 00017abfa8]         BOOTMEM
  #25 [00017b7480 - 00017b74e8]         BOOTMEM
  #26 [00017b7500 - 00017b7568]         BOOTMEM
  #27 [00017b7580 - 00017b75e8]         BOOTMEM
  #28 [00017b7600 - 00017b7668]         BOOTMEM
  #29 [00017b7680 - 00017b76e8]         BOOTMEM
  #30 [00017abfc0 - 00017abfe0]         BOOTMEM
  #31 [00017b7700 - 00017b7724]         BOOTMEM
  #32 [00017b7740 - 00017b7764]         BOOTMEM
  #33 [0001800000 - 000181b000]         BOOTMEM
  #34 [0001900000 - 000191b000]         BOOTMEM
  #35 [00017b7780 - 00017b7788]         BOOTMEM
  #36 [00017b77c0 - 00017b77c8]         BOOTMEM
  #37 [00017b7800 - 00017b7808]         BOOTMEM
  #38 [00017b7840 - 00017b7850]         BOOTMEM
  #39 [00017b7880 - 00017b79c0]         BOOTMEM
  #40 [00017b79c0 - 00017b7a20]         BOOTMEM
  #41 [00017b7a40 - 00017b7aa0]         BOOTMEM
  #42 [00017b9000 - 00017c1000]         BOOTMEM
  #43 [000191b000 - 0001a1b000]         BOOTMEM
  #44 [000181b000 - 000189b000]         BOOTMEM
Memory: 1016824k/1048192k available (3449k kernel code, 452k absent, 30916k reserved, 3177k data, 448k init)
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
	RCU-based detection of stalled CPUs is disabled.
	Verbose stalled-CPUs detection is disabled.
NR_IRQS:512
Console: colour VGA+ 80x25
console [tty0] enabled
Fast TSC calibration using PIT
Detected 3000.352 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 6000.70 BogoMIPS (lpj=3000352)
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
Mount-cache hash table entries: 256
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 4 MCE banks
CPU0: Thermal monitoring enabled (TM1)
using mwait in idle threads.
Performance Events: Netburst events, Netburst P4/Xeon PMU driver.
... version:                0
... bit width:              40
... generic registers:      18
... value mask:             000000ffffffffff
... max period:             0000007fffffffff
... fixed-purpose events:   0
... event mask:             000000000003ffff
ACPI: Core revision 20100702
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Pentium(R) D CPU 3.00GHz stepping 02
NMI watchdog enabled, takes one hw-pmu counter.
Booting Node   0, Processors  #1 Ok.
NMI watchdog enabled, takes one hw-pmu counter.
Brought up 2 CPUs
Total of 2 processors activated (12000.35 BogoMIPS).
kworker/u:0 used greatest stack depth: 5472 bytes left
Time:  4:02:56  Date: 10/06/10
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
PCI: Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub with MMCONFIG support
PCI: not using MMCONFIG
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: EC: Look up EC in DSDT
ACPI: Executed 1 blocks of module-level executable AML code
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI Warning: Incorrect checksum in table [OEMB] - 0xB0, should be 0xA2 (20100702/tbutils-314)
ACPI: No dock devices found.
PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci_root PNP0A08:00: host bridge window [io  0x0000-0x0cf7] (ignored)
pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff] (ignored)
pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored)
pci_root PNP0A08:00: host bridge window [mem 0x40010000-0xffffffff] (ignored)
pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: PME# disabled
pci 0000:00:1b.0: reg 10: [mem 0xcfdf8000-0xcfdfbfff 64bit]
pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1b.0: PME# disabled
pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.0: PME# disabled
pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.1: PME# disabled
pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.2: PME# disabled
pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
pci 0000:00:1c.3: PME# disabled
pci 0000:00:1d.0: reg 20: [io  0x6000-0x601f]
pci 0000:00:1d.1: reg 20: [io  0x6400-0x641f]
pci 0000:00:1d.2: reg 20: [io  0x6800-0x681f]
pci 0000:00:1d.3: reg 20: [io  0x7000-0x701f]
pci 0000:00:1d.7: reg 10: [mem 0xcfdffc00-0xcfdfffff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:00:1f.0: Force enabled HPET at 0xfed00000
pci 0000:00:1f.0: quirk: [io  0x0800-0x087f] claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: [io  0x0480-0x04bf] claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 0007)
pci 0000:00:1f.1: reg 10: [io  0x0000-0x0007]
pci 0000:00:1f.1: reg 14: [io  0x0000-0x0003]
pci 0000:00:1f.1: reg 18: [io  0x0000-0x0007]
pci 0000:00:1f.1: reg 1c: [io  0x0000-0x0003]
pci 0000:00:1f.1: reg 20: [io  0xffa0-0xffaf]
pci 0000:00:1f.2: reg 10: [io  0x8800-0x8807]
pci 0000:00:1f.2: reg 14: [io  0x8400-0x8403]
pci 0000:00:1f.2: reg 18: [io  0x8000-0x8007]
pci 0000:00:1f.2: reg 1c: [io  0x7800-0x7803]
pci 0000:00:1f.2: reg 20: [io  0x7400-0x740f]
pci 0000:00:1f.2: PME# supported from D3hot
pci 0000:00:1f.2: PME# disabled
pci 0000:00:1f.3: reg 20: [io  0x0400-0x041f]
pci 0000:06:00.0: reg 10: [mem 0xd0000000-0xdfffffff 64bit pref]
pci 0000:06:00.0: reg 18: [mem 0xcffe0000-0xcffeffff 64bit]
pci 0000:06:00.0: reg 20: [io  0xe000-0xe0ff]
pci 0000:06:00.0: reg 30: [mem 0xcffc0000-0xcffdffff pref]
pci 0000:06:00.0: supports D1 D2
pci 0000:06:00.1: reg 10: [mem 0x00000000-0x00003fff 64bit]
pci 0000:06:00.1: supports D1 D2
pci 0000:00:01.0: PCI bridge to [bus 06-06]
pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:01.0:   bridge window [mem 0xcff00000-0xcfffffff]
pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
pci 0000:00:1c.0: PCI bridge to [bus 05-05]
pci 0000:00:1c.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:1c.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
pci 0000:00:1c.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
pci 0000:04:00.0: reg 10: [mem 0xcfee0000-0xcfefffff]
pci 0000:04:00.0: reg 18: [io  0xc800-0xc81f]
pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
pci 0000:04:00.0: PME# disabled
pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
pci 0000:00:1c.1: PCI bridge to [bus 04-04]
pci 0000:00:1c.1:   bridge window [io  0xc000-0xcfff]
pci 0000:00:1c.1:   bridge window [mem 0xcfe00000-0xcfefffff]
pci 0000:00:1c.1:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
pci 0000:00:1c.2: PCI bridge to [bus 03-03]
pci 0000:00:1c.2:   bridge window [io  0xb000-0xbfff]
pci 0000:00:1c.2:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
pci 0000:00:1c.2:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
pci 0000:00:1c.3: PCI bridge to [bus 02-02]
pci 0000:00:1c.3:   bridge window [io  0xa000-0xafff]
pci 0000:00:1c.3:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
pci 0000:00:1c.3:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
pci 0000:00:1e.0: PCI bridge to [bus 01-01] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x9000-0x9fff]
pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
pci 0000:00:1e.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
pci 0000:00:1e.0:   bridge window [io  0x0000-0xffff] (subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0x00000000-0xffffffffffffffff] (subtractive decode)
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
vgaarb: device added: PCI:0000:06:00.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: pci_cache_line_size set to 64 bytes
reserve RAM buffer: 000000000009fc00 - 000000000009ffff 
reserve RAM buffer: 000000003ffa0000 - 000000003fffffff 
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
hpet clockevent registered
HPET: 3 timers in total, 0 timers will be used for per-cpu timer
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 comparators, 64-bit 14.318180 MHz counter
Switching to clocksource tsc
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 15 devices
ACPI: ACPI bus type pnp unregistered
system 00:01: [mem 0xfed13000-0xfed19fff] has been reserved
system 00:08: [io  0x0290-0x0297] has been reserved
system 00:09: [io  0x04d0-0x04d1] has been reserved
system 00:09: [io  0x0800-0x087f] has been reserved
system 00:09: [io  0x0400-0x041f] has been reserved
system 00:09: [io  0x0480-0x04bf] has been reserved
system 00:09: [io  0x0900-0x090f] has been reserved
system 00:09: [mem 0xfed1c000-0xfed1ffff] has been reserved
system 00:09: [mem 0xfed20000-0xfed8ffff] has been reserved
system 00:09: [mem 0xffb00000-0xffbfffff] could not be reserved
system 00:09: [mem 0xfff00000-0xffffffff] has been reserved
system 00:0a: [mem 0xfec00000-0xfec00fff] could not be reserved
system 00:0a: [mem 0xfee00000-0xfee00fff] has been reserved
system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved
system 00:0d: [mem 0xe0000000-0xefffffff] has been reserved
system 00:0e: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:0e: [mem 0x000c0000-0x000dffff] has been reserved
system 00:0e: [mem 0x000e0000-0x000fffff] could not be reserved
system 00:0e: [mem 0x00100000-0x3fffffff] could not be reserved
pci 0000:06:00.1: BAR 0: assigned [mem 0xcff00000-0xcff03fff 64bit]
pci 0000:06:00.1: BAR 0: set to [mem 0xcff00000-0xcff03fff 64bit] (PCI address [0xcff00000-0xcff03fff]
pci 0000:00:01.0: PCI bridge to [bus 06-06]
pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:01.0:   bridge window [mem 0xcff00000-0xcfffffff]
pci 0000:00:01.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
pci 0000:00:1c.0: PCI bridge to [bus 05-05]
pci 0000:00:1c.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:1c.0:   bridge window [mem disabled]
pci 0000:00:1c.0:   bridge window [mem pref disabled]
pci 0000:00:1c.1: PCI bridge to [bus 04-04]
pci 0000:00:1c.1:   bridge window [io  0xc000-0xcfff]
pci 0000:00:1c.1:   bridge window [mem 0xcfe00000-0xcfefffff]
pci 0000:00:1c.1:   bridge window [mem pref disabled]
pci 0000:00:1c.2: PCI bridge to [bus 03-03]
pci 0000:00:1c.2:   bridge window [io  0xb000-0xbfff]
pci 0000:00:1c.2:   bridge window [mem disabled]
pci 0000:00:1c.2:   bridge window [mem pref disabled]
pci 0000:00:1c.3: PCI bridge to [bus 02-02]
pci 0000:00:1c.3:   bridge window [io  0xa000-0xafff]
pci 0000:00:1c.3:   bridge window [mem disabled]
pci 0000:00:1c.3:   bridge window [mem pref disabled]
pci 0000:00:1e.0: PCI bridge to [bus 01-01]
pci 0000:00:1e.0:   bridge window [io  0x9000-0x9fff]
pci 0000:00:1e.0:   bridge window [mem disabled]
pci 0000:00:1e.0:   bridge window [mem pref disabled]
pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:01.0: setting latency timer to 64
pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:1c.0: setting latency timer to 64
pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
pci 0000:00:1c.1: setting latency timer to 64
pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
pci 0000:00:1c.2: setting latency timer to 64
pci 0000:00:1c.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
pci 0000:00:1c.3: setting latency timer to 64
pci 0000:00:1e.0: setting latency timer to 64
pci_bus 0000:00: resource 0 [io  0x0000-0xffff]
pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffffffffffff]
pci_bus 0000:06: resource 0 [io  0xe000-0xefff]
pci_bus 0000:06: resource 1 [mem 0xcff00000-0xcfffffff]
pci_bus 0000:06: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref]
pci_bus 0000:05: resource 0 [io  0xd000-0xdfff]
pci_bus 0000:04: resource 0 [io  0xc000-0xcfff]
pci_bus 0000:04: resource 1 [mem 0xcfe00000-0xcfefffff]
pci_bus 0000:03: resource 0 [io  0xb000-0xbfff]
pci_bus 0000:02: resource 0 [io  0xa000-0xafff]
pci_bus 0000:01: resource 0 [io  0x9000-0x9fff]
pci_bus 0000:01: resource 4 [io  0x0000-0xffff]
pci_bus 0000:01: resource 5 [mem 0x00000000-0xffffffffffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 3, 49152 bytes)
UDP-Lite hash table entries: 512 (order: 3, 49152 bytes)
NET: Registered protocol family 1
pci 0000:06:00.0: Boot video device
PCI: CLS 16 bytes, default 64
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 6852k freed
DMA-API: preallocated 32768 debug entries
DMA-API: debugging enabled by kernel config
audit: initializing netlink socket (disabled)
type=2000 audit(1286337776.733:1): initialized
HugeTLB registered 2 MB page size, pre-allocated 0 pages
msgmni has been set to 1999
SELinux:  Registering netfilter hooks
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
ACPI: acpi_idle registered with cpuidle
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
brd: module loaded
ata_piix 0000:00:1f.1: version 2.13
ata_piix 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ata_piix 0000:00:1f.1: setting latency timer to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ata_piix 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
ata_piix 0000:00:1f.2: setting latency timer to 64
scsi2 : ata_piix
scsi3 : ata_piix
ata3: SATA max UDMA/133 cmd 0x8800 ctl 0x8400 bmdma 0x7400 irq 17
ata4: SATA max UDMA/133 cmd 0x8000 ctl 0x7800 bmdma 0x7408 irq 17
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Registering the dns_resolver key type
PM: Resume from disk failed.
registered taskstats version 1
  Magic number: 14:855:8
/home/airlied/git/drm-2.6/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
ata3.01: ATA-7: WDC WD1600AAJS-08PSA0, 05.06H05, max UDMA/133
ata3.01: 312581808 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata3.01: configured for UDMA/133
scsi 2:0:1:0: Direct-Access     ATA      WDC WD1600AAJS-0 05.0 PQ: 0 ANSI: 5
sd 2:0:1:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)
sd 2:0:1:0: [sda] Write Protect is off
sd 2:0:1:0: [sda] Mode Sense: 00 3a 00 00
sd 2:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
sd 2:0:1:0: [sda] Attached SCSI disk
Freeing unused kernel memory: 448k freed
Write protecting the kernel read-only data: 6144k
Freeing unused kernel memory: 640k freed
Freeing unused kernel memory: 204k freed
dracut: dracut-005-3.fc13
udev: starting version 153
udevd (657): /proc/657/oom_adj is deprecated, please use /proc/657/oom_score_adj instead.
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon 0000:06:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
radeon 0000:06:00.0: setting latency timer to 64
[drm] initializing kernel modesetting (RV740 0x1002:0x94B3).
[drm] register mmio base: 0xCFFE0000
[drm] register mmio size: 65536
ATOM BIOS: Walden
radeon 0000:06:00.0: VRAM: 512M 0x00000000 - 0x1FFFFFFF (512M used)
radeon 0000:06:00.0: GTT: 512M 0x20000000 - 0x3FFFFFFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 512484 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
radeon 0000:06:00.0: irq 40 for MSI/MSI-X
radeon 0000:06:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RV730 Microcode
radeon 0000:06:00.0: WB enabled
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Enabling audio support
failed to evaluate ATIF got AE_BAD_PARAMETER
[drm] Default TV standard: NTSC
[drm] Default TV standard: NTSC
[drm] Default TV standard: NTSC
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I
[drm]   HPD2
[drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c
[drm]   Encoders:
[drm]     CRT2: INTERNAL_KLDSCP_DAC2
[drm]     DFP2: INTERNAL_UNIPHY1
[drm] Connector 1:
[drm]   DIN
[drm]   Encoders:
[drm]     TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I
[drm]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm]     CRT1: INTERNAL_KLDSCP_DAC1
[drm]     DFP1: INTERNAL_UNIPHY
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0142000
[drm] vram apper at 0xD0000000
[drm] size 7258112
[drm] fb depth is 24
[drm]    pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 210x65
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.6.0 20080528 for 0000:06:00.0 on minor 0
modprobe used greatest stack depth: 3488 bytes left
dracut: Starting plymouth daemon
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
uhci_hcd 0000:00:1d.0: setting latency timer to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 20, io base 0x00006000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.36-rc6+ uhci_hcd
usb usb1: SerialNumber: 0000:00:1d.0
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
uhci_hcd 0000:00:1d.1: setting latency timer to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 17, io base 0x00006400
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.36-rc6+ uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.1
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: setting latency timer to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00006800
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.36-rc6+ uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.2
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
ehci_hcd 0000:00:1d.7: setting latency timer to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:1d.7: using broken periodic workaround
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: cache line size of 16 is not supported
ehci_hcd 0000:00:1d.7: irq 20, io mem 0xcfdffc00
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
usb usb4: New USB device found, idVendor=1d6b, idProduct=0002
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: EHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.36-rc6+ ehci_hcd
usb usb4: SerialNumber: 0000:00:1d.7
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 8 ports detected
uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.3: setting latency timer to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 19, io base 0x00007000
usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.36-rc6+ uhci_hcd
usb usb5: SerialNumber: 0000:00:1d.3
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
usb 2-1: new low speed USB device using uhci_hcd and address 2
dracut: Mounted root filesystem /dev/sda5
dracut: Loading SELinux policy
usb 2-1: New USB device found, idVendor=093a, idProduct=2510
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1: Product: USB OPTICAL MOUSE
usb 2-1: Manufacturer: PIXART
input: PIXART USB OPTICAL MOUSE as /devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0/input/input0
generic-usb 0003:093A:2510.0001: input: USB HID v1.10 Mouse [PIXART USB OPTICAL MOUSE] on usb-0000:00:1d.1-1/input0
usb 1-1: new low speed USB device using uhci_hcd and address 2
SELinux: 2048 avtab hash slots, 200126 rules.
usb 1-1: New USB device found, idVendor=1267, idProduct=0103
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
input: HID 1267:0103 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.0/input/input1
generic-usb 0003:1267:0103.0002: input: USB HID v1.10 Keyboard [HID 1267:0103] on usb-0000:00:1d.0-1/input0
input: HID 1267:0103 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.1/input/input2
generic-usb 0003:1267:0103.0003: input: USB HID v1.10 Device [HID 1267:0103] on usb-0000:00:1d.0-1/input1
SELinux: 2048 avtab hash slots, 200126 rules.
SELinux:  9 users, 13 roles, 3329 types, 171 bools, 1 sens, 1024 cats
SELinux:  77 classes, 200126 rules
SELinux:  Permission audit_access in class file not defined in policy.
SELinux:  Permission audit_access in class dir not defined in policy.
SELinux:  Permission execmod in class dir not defined in policy.
SELinux:  Permission audit_access in class lnk_file not defined in policy.
SELinux:  Permission open in class lnk_file not defined in policy.
SELinux:  Permission execmod in class lnk_file not defined in policy.
SELinux:  Permission audit_access in class chr_file not defined in policy.
SELinux:  Permission audit_access in class blk_file not defined in policy.
SELinux:  Permission execmod in class blk_file not defined in policy.
SELinux:  Permission audit_access in class sock_file not defined in policy.
SELinux:  Permission execmod in class sock_file not defined in policy.
SELinux:  Permission audit_access in class fifo_file not defined in policy.
SELinux:  Permission execmod in class fifo_file not defined in policy.
SELinux: the above unknown classes and permissions will be allowed
SELinux:  Completing initialization.
SELinux:  Setting up existing superblocks.
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses transition SIDs
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
SELinux: initialized (dev sda5, type ext4), uses xattr
type=1403 audit(1286337781.250:2): policy loaded auid=4294967295 ses=4294967295
dracut: Switching root
readahead: starting
udev: starting version 153
i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ACPI: resource 0000:00:1f.3 [io  0x0400-0x041f] conflicts with ACPI region SMRG [io  0x0400-0x040f 64bit pref disabled]
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
input: PC Speaker as /devices/platform/pcspkr/input/input3
intel_rng: FWH not detected
input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input4
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
ACPI: Power Button [PWRF]
sd 2:0:1:0: Attached scsi generic sg0 type 0
type=1400 audit(1286337785.593:3): avc:  denied  { mmap_zero } for  pid=1477 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, 114 bytes nvram, hpet irqs
parport_pc 00:07: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
e1000e: Intel(R) PRO/1000 Network Driver - 1.2.7-k2
e1000e: Copyright (c) 1999 - 2010 Intel Corporation.
e1000e 0000:04:00.0: Disabling ASPM  L1
e1000e 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
e1000e 0000:04:00.0: setting latency timer to 64
e1000e 0000:04:00.0: irq 41 for MSI/MSI-X
e1000e 0000:04:00.0: Disabling ASPM L0s 
ppdev: user-space parallel port driver
e1000e 0000:04:00.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:13:d4:ff:1e:44
e1000e 0000:04:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:04:00.0: eth0: MAC: 2, PHY: 2, PBA No: ffffff-0ff
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
HDA Intel 0000:00:1b.0: irq 42 for MSI/MSI-X
HDA Intel 0000:00:1b.0: setting latency timer to 64
hda_codec: ALC882: SKU not ready 0x411111f0
HDA Intel 0000:06:00.1: enabling device (0000 -> 0002)
HDA Intel 0000:06:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:06:00.1: irq 43 for MSI/MSI-X
HDA Intel 0000:06:00.1: setting latency timer to 64
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.18.0-ioctl (2010-06-29) initialised: dm-devel@redhat.com
EXT4-fs (sda5): re-mounted. Opts: (null)
EXT3-fs: barriers not enabled
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda2): using internal journal
EXT3-fs (sda2): mounted filesystem with writeback data mode
SELinux: initialized (dev sda2, type ext3), uses xattr
EXT3-fs: barriers not enabled
kjournald starting.  Commit interval 5 seconds
EXT3-fs (sda1): using internal journal
EXT3-fs (sda1): mounted filesystem with writeback data mode
SELinux: initialized (dev sda1, type ext3), uses xattr
type=1400 audit(1286337791.700:4): avc:  denied  { write } for  pid=1736 comm="quotaon" path="/dev/pts/0" dev=devpts ino=3 scontext=system_u:system_r:quota_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file
Adding 1052252k swap on /dev/sda3.  Priority:-1 extents:1 across:1052252k 
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
ip_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (8007 buckets, 32028 max)
e1000e 0000:04:00.0: irq 41 for MSI/MSI-X
e1000e 0000:04:00.0: irq 41 for MSI/MSI-X
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
type=1400 audit(1286337804.166:5): avc:  denied  { module_request } for  pid=2150 comm="rpc.statd" kmod="net-pf-10" scontext=system_u:system_r:rpcd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
type=1400 audit(1286337807.668:6): avc:  denied  { module_request } for  pid=2389 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286337807.814:7): avc:  denied  { module_request } for  pid=2409 comm="sendmail" kmod="net-pf-10" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286337865.890:8): avc:  denied  { module_request } for  pid=2585 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286337866.412:9): avc:  denied  { module_request } for  pid=2590 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286337909.603:10): avc:  denied  { module_request } for  pid=2849 comm="canberra-gtk-pl" kmod="net-pf-10" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
fuse init (API version 7.15)
SELinux: initialized (dev fuse, type fuse), uses genfs_contexts
flush-8:0 used greatest stack depth: 3472 bytes left
type=1400 audit(1286339422.009:11): avc:  denied  { module_request } for  pid=3416 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286339559.001:12): avc:  denied  { module_request } for  pid=3776 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286404212.575:13): avc:  denied  { module_request } for  pid=10255 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286404213.383:14): avc:  denied  { module_request } for  pid=10261 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 1-1: USB disconnect, address 2
usb 1-1: new low speed USB device using uhci_hcd and address 3
usb 1-1: New USB device found, idVendor=1267, idProduct=0103
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
input: HID 1267:0103 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.0/input/input6
generic-usb 0003:1267:0103.0004: input: USB HID v1.10 Keyboard [HID 1267:0103] on usb-0000:00:1d.0-1/input0
input: HID 1267:0103 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.1/input/input7
generic-usb 0003:1267:0103.0005: input: USB HID v1.10 Device [HID 1267:0103] on usb-0000:00:1d.0-1/input1
type=1400 audit(1286415036.060:15): avc:  denied  { module_request } for  pid=11907 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286415036.518:16): avc:  denied  { module_request } for  pid=11913 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286420177.971:17): avc:  denied  { module_request } for  pid=22896 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286420179.138:18): avc:  denied  { module_request } for  pid=22902 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286432078.346:19): avc:  denied  { module_request } for  pid=1313 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286432079.751:20): avc:  denied  { module_request } for  pid=1338 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=1400 audit(1286441301.607:21): avc:  denied  { module_request } for  pid=4357 comm="sshd" kmod="net-pf-10" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
Console: switching to colour VGA+ 80x25
drm: unregistered panic notifier
[drm] radeon: finishing device.
radeon 0000:06:00.0: ffff88003c952f18 unpin not necessary
[TTM] Finalizing pool allocator.
[TTM] Zone  kernel: Used memory at exit: 1024 kiB.
[drm] radeon: ttm finalized
[drm] Module unloaded
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon 0000:06:00.0: setting latency timer to 64
[drm] initializing kernel modesetting (RV740 0x1002:0x94B3).
[drm] register mmio base: 0xCFFE0000
[drm] register mmio size: 65536
ATOM BIOS: Walden
radeon 0000:06:00.0: VRAM: 512M 0x00000000 - 0x1FFFFFFF (512M used)
radeon 0000:06:00.0: GTT: 512M 0x20000000 - 0x3FFFFFFF
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 512484 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
radeon 0000:06:00.0: irq 40 for MSI/MSI-X
radeon 0000:06:00.0: radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RV730 Microcode
radeon 0000:06:00.0: WB enabled
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
do_IRQ: 0.89 No irq handler for vector (irq -1)
[drm] ib test succeeded in 0 usecs
[drm] Enabling audio support
failed to evaluate ATIF got AE_BAD_PARAMETER
[drm] Default TV standard: NTSC
[drm] Default TV standard: NTSC
[drm] Default TV standard: NTSC
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DVI-I
[drm]   HPD2
[drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c
[drm]   Encoders:
[drm]     CRT2: INTERNAL_KLDSCP_DAC2
[drm]     DFP2: INTERNAL_UNIPHY1
[drm] Connector 1:
[drm]   DIN
[drm]   Encoders:
[drm]     TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm]   DVI-I
[drm]   HPD1
[drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c
[drm]   Encoders:
[drm]     CRT1: INTERNAL_KLDSCP_DAC1
[drm]     DFP1: INTERNAL_UNIPHY
[drm] Internal thermal controller with fan control
[drm] radeon: power management initialized
[drm] fb mappable at 0xD0142000
[drm] vram apper at 0xD0000000
[drm] size 7258112
[drm] fb depth is 24
[drm]    pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 210x65
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.6.0 20080528 for 0000:06:00.0 on minor 0

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-07  8:55 "do_IRQ: 0.89 No irq handler for vector (irq -1)" Dave Airlie
  2010-10-07  9:05 ` Dave Airlie
@ 2010-10-07 20:38 ` Thomas Gleixner
  2010-10-07 21:35   ` Thomas Gleixner
  2010-10-10 17:46 ` Maciej Rutecki
  2 siblings, 1 reply; 19+ messages in thread
From: Thomas Gleixner @ 2010-10-07 20:38 UTC (permalink / raw)
  To: Dave Airlie; +Cc: LKML, Ingo Molnar, Jesse Barnes

On Thu, 7 Oct 2010, Dave Airlie wrote:

> We are seeing this on both intel and radeon drivers when we reload the
> module with 2.6.36-rc7 or so, and we get no irqs for that device.
> 
> you can reproduce by
> 
> init 3
> echo 0 > /sys/class/vtconsole/vtcon1/bind
> rmmod i915
> modprobe i915
> 
> or radeon.
> 
> It seems to be possibly MSI related.

Yeah, can reproduce. Digging into it. I just discovered a even worse
thing. I wanted to know whether it recovers when I rmmod/modprobe the
module again, which resulted in:



Oct  7 22:24:19 ionos kernel: Console: switching to colour VGA+ 80x25
Oct  7 22:24:22 ionos kernel: drm: unregistered panic notifier
Oct  7 22:24:22 ionos kernel: vga_switcheroo: disabled
Oct  7 22:24:22 ionos kernel: BUG: sleeping function called from invalid context at /home/tglx/work/kernel/git/linux-2.6/arch/x86/mm/fault.c:1074
Oct  7 22:24:22 ionos kernel: in_atomic(): 0, irqs_disabled(): 1, pid: 2681, name: udevd
Oct  7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Not tainted 2.6.36-rc7 #4
Oct  7 22:24:22 ionos kernel: Call Trace:
Oct  7 22:24:22 ionos kernel: [<ffffffff8103d3d1>] __might_sleep+0xed/0xef
Oct  7 22:24:22 ionos kernel: [<ffffffff81452d81>] do_page_fault+0x1b2/0x2bb
Oct  7 22:24:22 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
Oct  7 22:24:22 ionos kernel: [<ffffffff8106af14>] ? lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
Oct  7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c

That means that the hrtimer in the shared signal handler is corrupted. Uurg.

Oct  7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
Oct  7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
Oct  7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
Oct  7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
Oct  7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct  7 22:24:22 ionos kernel: BUG: unable to handle kernel paging request at 00000000934a2400

Something is fishy here. That's not a kernel address

Oct  7 22:24:22 ionos kernel: IP: [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: PGD 716e6067 PUD 0 
Oct  7 22:24:22 ionos kernel: Oops: 0000 [#1] SMP 
Oct  7 22:24:22 ionos kernel: last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/bind
Oct  7 22:24:22 ionos kernel: CPU 2 
Oct  7 22:24:22 ionos kernel: Modules linked in: i915(-) fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb iwlagn snd_hda_codec_intelhdmi snd_hda_codec_conexant iwlcore snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_seq snd_seq_device snd_pcm thinkpad_acpi snd_timer uvcvideo snd videodev sdhci_pci cfg80211 sdhci v4l1_compat soundcore snd_page_alloc v4l2_compat_ioctl32 mmc_core wmi microcode rfkill pcspkr joydev e1000e i2c_i801 shpchp iTCO_wdt iTCO_vendor_support firewire_ohci firewire_core crc_itu_t drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: i915]
Oct  7 22:24:22 ionos kernel:
Oct  7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Not tainted 2.6.36-rc7 #4 25222AU/25222AU
Oct  7 22:24:22 ionos kernel: RIP: 0010:[<ffffffff8106af14>]  [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: RSP: 0018:ffff8800573a7e58  EFLAGS: 00010006
Oct  7 22:24:22 ionos kernel: RAX: 00000000000006a4 RBX: 00000000934a2400 RCX: 0000000000000060
Oct  7 22:24:22 ionos kernel: RDX: 00000000000006a4 RSI: ffff8800573a7e90 RDI: ffff880037bffc70
Oct  7 22:24:22 ionos kernel: RBP: ffff8800573a7e78 R08: 0000000000000068 R09: 0101010101010101
Oct  7 22:24:22 ionos kernel: R10: 0000000000000060 R11: 0000000000000202 R12: ffff880037bffc70
Oct  7 22:24:22 ionos kernel: R13: ffff8800573a7e90 R14: ffff8800573a7f28 R15: 0000000000a97c20
Oct  7 22:24:22 ionos kernel: FS:  00007ff08870c7a0(0000) GS:ffff880002500000(0000) knlGS:0000000000000000
Oct  7 22:24:22 ionos kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct  7 22:24:22 ionos kernel: CR2: 000000313a047256 CR3: 00000000716e7000 CR4: 00000000000006e0
Oct  7 22:24:22 ionos kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct  7 22:24:22 ionos kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct  7 22:24:22 ionos kernel: Process udevd (pid: 2681, threadinfo ffff8800573a6000, task ffff880059238000)
Oct  7 22:24:22 ionos kernel: Stack:
Oct  7 22:24:22 ionos kernel: ffff88003798e180 ffff880037bffc70 ffff880059238000 ffff880037bffc70
Oct  7 22:24:22 ionos kernel: <0> ffff8800573a7ea8 ffffffff8106af5e ffff8800573a7e98 00000000810a069d
Oct  7 22:24:22 ionos kernel: <0> ffff880037bffc70 ffff880059238000 ffff8800573a7ee8 ffffffff8105119d
Oct  7 22:24:22 ionos kernel: Call Trace:
Oct  7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
Oct  7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c
Oct  7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
Oct  7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
Oct  7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
Oct  7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
Oct  7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct  7 22:24:22 ionos kernel: Code: 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00 49 89 fc 49 89 f5 49 8b 5c 24 30 48 85 db 74 2a <48> 8b 3b e8 bf 47 3e 00 49 89 45 00 49 3b 5c 24 30 75 0c 41 59 
Oct  7 22:24:22 ionos kernel: RIP  [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: RSP <ffff8800573a7e58>
Oct  7 22:24:22 ionos kernel: CR2: 00000000934a2400
Oct  7 22:24:22 ionos kernel: ---[ end trace 9b1fb5b66b44ba63 ]---
Oct  7 22:24:22 ionos kernel: BUG: unable to handle kernel paging request at 00000000934a2400
Oct  7 22:24:22 ionos kernel: IP: [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: PGD 716e6067 PUD 0 
Oct  7 22:24:22 ionos kernel: Oops: 0000 [#2] SMP 
Oct  7 22:24:22 ionos kernel: last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/bind
Oct  7 22:24:22 ionos kernel: CPU 2 
Oct  7 22:24:22 ionos kernel: Modules linked in: i915(-) fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 ecb iwlagn snd_hda_codec_intelhdmi snd_hda_codec_conexant iwlcore snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_seq snd_seq_device snd_pcm thinkpad_acpi snd_timer uvcvideo snd videodev sdhci_pci cfg80211 sdhci v4l1_compat soundcore snd_page_alloc v4l2_compat_ioctl32 mmc_core wmi microcode rfkill pcspkr joydev e1000e i2c_i801 shpchp iTCO_wdt iTCO_vendor_support firewire_ohci firewire_core crc_itu_t drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: i915]
Oct  7 22:24:22 ionos kernel:
Oct  7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Tainted: G      D     2.6.36-rc7 #4 25222AU/25222AU
Oct  7 22:24:22 ionos kernel: RIP: 0010:[<ffffffff8106af14>]  [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: RSP: 0018:ffff8800573a7b48  EFLAGS: 00010206
Oct  7 22:24:22 ionos kernel: RAX: ffff880037bffc00 RBX: 00000000934a2400 RCX: 00000000000003e8
Oct  7 22:24:22 ionos kernel: RDX: 0000000000000001 RSI: ffff8800573a7b90 RDI: ffff880037bffc70
Oct  7 22:24:22 ionos kernel: RBP: ffff8800573a7b68 R08: 0000000000000000 R09: ffff880076c08000
Oct  7 22:24:22 ionos kernel: R10: ffff880076c08000 R11: 0000000000000020 R12: ffff880037bffc70
Oct  7 22:24:22 ionos kernel: R13: ffff8800573a7b90 R14: 0000000000000000 R15: 0000000000000001
Oct  7 22:24:22 ionos kernel: FS:  00007ff08870c7a0(0000) GS:ffff880002500000(0000) knlGS:0000000000000000
Oct  7 22:24:22 ionos kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct  7 22:24:22 ionos kernel: CR2: 00000000934a2400 CR3: 00000000716e7000 CR4: 00000000000006e0
Oct  7 22:24:22 ionos kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct  7 22:24:22 ionos kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct  7 22:24:22 ionos kernel: Process udevd (pid: 2681, threadinfo ffff8800573a6000, task ffff880059238000)
Oct  7 22:24:22 ionos kernel: Stack:
Oct  7 22:24:22 ionos kernel: ffff8800573a7b78 ffff880037bffc70 0000000000000009 0000000000000009
Oct  7 22:24:22 ionos kernel: <0> ffff8800573a7ba8 ffffffff8106afa2 ffff8800573a7c18 0000000000000046
Oct  7 22:24:22 ionos kernel: <0> ffff8800573a7bc8 0000000000000282 0000000000000000 ffff880037bffc70
Oct  7 22:24:22 ionos kernel: Call Trace:
Oct  7 22:24:22 ionos kernel: [<ffffffff8106afa2>] hrtimer_try_to_cancel+0x1a/0x4b
Oct  7 22:24:22 ionos kernel: [<ffffffff8106afec>] hrtimer_cancel+0x19/0x25
Oct  7 22:24:22 ionos kernel: [<ffffffff81050ac2>] do_exit+0x181/0x726
Oct  7 22:24:22 ionos kernel: [<ffffffff8104dfae>] ? kmsg_dump+0x12b/0x145
Oct  7 22:24:22 ionos kernel: [<ffffffff81450b16>] oops_end+0xbf/0xc7
Oct  7 22:24:22 ionos kernel: [<ffffffff81031e6b>] no_context+0x1fc/0x20b
Oct  7 22:24:22 ionos kernel: [<ffffffff81032004>] __bad_area_nosemaphore+0x18a/0x1ad
Oct  7 22:24:22 ionos kernel: [<ffffffff81032083>] bad_area+0x47/0x4e
Oct  7 22:24:22 ionos kernel: [<ffffffff81452dda>] do_page_fault+0x20b/0x2bb
Oct  7 22:24:22 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
Oct  7 22:24:22 ionos kernel: [<ffffffff8106af14>] ? lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
Oct  7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c
Oct  7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
Oct  7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
Oct  7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
Oct  7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
Oct  7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct  7 22:24:22 ionos kernel: Code: 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00 49 89 fc 49 89 f5 49 8b 5c 24 30 48 85 db 74 2a <48> 8b 3b e8 bf 47 3e 00 49 89 45 00 49 3b 5c 24 30 75 0c 41 59 
Oct  7 22:24:22 ionos kernel: RIP  [<ffffffff8106af14>] lock_hrtimer_base+0x22/0x50
Oct  7 22:24:22 ionos kernel: RSP <ffff8800573a7b48>
Oct  7 22:24:22 ionos kernel: CR2: 00000000934a2400
Oct  7 22:24:22 ionos kernel: ---[ end trace 9b1fb5b66b44ba64 ]---
Oct  7 22:24:22 ionos kernel: Fixing recursive fault but reboot is needed!
Oct  7 22:24:22 ionos kernel: [drm] Module unloaded

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-07 20:38 ` Thomas Gleixner
@ 2010-10-07 21:35   ` Thomas Gleixner
  2010-10-08  7:52     ` Thomas Gleixner
  2010-10-08 11:53     ` Chris Wilson
  0 siblings, 2 replies; 19+ messages in thread
From: Thomas Gleixner @ 2010-10-07 21:35 UTC (permalink / raw)
  To: Dave Airlie; +Cc: LKML, Ingo Molnar, Jesse Barnes

On Thu, 7 Oct 2010, Thomas Gleixner wrote:
> On Thu, 7 Oct 2010, Dave Airlie wrote:
> Oct  7 22:24:19 ionos kernel: Console: switching to colour VGA+ 80x25
> Oct  7 22:24:22 ionos kernel: drm: unregistered panic notifier
> Oct  7 22:24:22 ionos kernel: vga_switcheroo: disabled
> Oct  7 22:24:22 ionos kernel: BUG: sleeping function called from invalid context at /home/tglx/work/kernel/git/linux-2.6/arch/x86/mm/fault.c:1074
> Oct  7 22:24:22 ionos kernel: in_atomic(): 0, irqs_disabled(): 1, pid: 2681, name: udevd
> Oct  7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Not tainted 2.6.36-rc7 #4
> Oct  7 22:24:22 ionos kernel: Call Trace:
> Oct  7 22:24:22 ionos kernel: [<ffffffff8103d3d1>] __might_sleep+0xed/0xef
> Oct  7 22:24:22 ionos kernel: [<ffffffff81452d81>] do_page_fault+0x1b2/0x2bb
> Oct  7 22:24:22 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
> Oct  7 22:24:22 ionos kernel: [<ffffffff8106af14>] ? lock_hrtimer_base+0x22/0x50
> Oct  7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
> Oct  7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c
> 
> That means that the hrtimer in the shared signal handler is corrupted. Uurg.
> 
> Oct  7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
> Oct  7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
> Oct  7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
> Oct  7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
> Oct  7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
> Oct  7 22:24:22 ionos kernel: BUG: unable to handle kernel paging request at 00000000934a2400
> 
> Something is fishy here. That's not a kernel address

I tried the patch you pointed me to on IRC:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=dab8dcfa3c8e3b021a138bee7c17791b4991ba55

The first test worked fine. But after I added some debugging I got
another weird corruption this time on the first unload:

Oct  7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
Oct  7 23:21:31 ionos kernel: drm: unregistered panic notifier
Oct  7 23:21:31 ionos kernel: vga_switcheroo: disabled
Oct  7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown

That one scares me :)

Oct  7 23:21:31 ionos kernel: [drm] Module unloaded
Oct  7 23:21:32 ionos kernel: BUG: sleeping function called from invalid context at /home/tglx/work/kernel/git/linux-2.6/arch/x86/mm/fault.c:1074
Oct  7 23:21:32 ionos kernel: in_atomic(): 0, irqs_disabled(): 1, pid: 1243, name: dbus-daemon
Oct  7 23:21:32 ionos kernel: Pid: 1243, comm: dbus-daemon Not tainted 2.6.36-rc7+ #6
Oct  7 23:21:32 ionos kernel: Call Trace:
Oct  7 23:21:32 ionos kernel: [<ffffffff8103d3d1>] __might_sleep+0xed/0xef
Oct  7 23:21:32 ionos kernel: [<ffffffff81452d81>] do_page_fault+0x1b2/0x2bb
Oct  7 23:21:32 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
Oct  7 23:21:32 ionos kernel: [<ffffffff813988bd>] ? sock_alloc_send_pskb+0xd6/0x2eb
Oct  7 23:21:32 ionos kernel: [<ffffffff8110044d>] ? __kmalloc_node_track_caller+0x149/0x154
Oct  7 23:21:32 ionos kernel: [<ffffffff813988bd>] ? sock_alloc_send_pskb+0xd6/0x2eb
Oct  7 23:21:32 ionos kernel: [<ffffffff8139cc02>] __alloc_skb+0x83/0x141
Oct  7 23:21:32 ionos kernel: [<ffffffff813988bd>] sock_alloc_send_pskb+0xd6/0x2eb
Oct  7 23:21:32 ionos kernel: [<ffffffff81039551>] ? __wake_up_common+0x4e/0x84
Oct  7 23:21:32 ionos kernel: [<ffffffff81399130>] ? cred_to_ucred+0x6d/0x79
Oct  7 23:21:32 ionos kernel: [<ffffffff81398ae7>] sock_alloc_send_skb+0x15/0x17
Oct  7 23:21:32 ionos kernel: [<ffffffff81425818>] unix_stream_sendmsg+0x11c/0x2c3
Oct  7 23:21:32 ionos kernel: [<ffffffff81394921>] __sock_sendmsg+0x6b/0x77
Oct  7 23:21:32 ionos kernel: [<ffffffff81396cc3>] ? sock_aio_write+0x0/0xd4
Oct  7 23:21:32 ionos kernel: [<ffffffff81396d83>] sock_aio_write+0xc0/0xd4
Oct  7 23:21:32 ionos kernel: [<ffffffff8110be39>] do_sync_readv_writev+0xc1/0x100
Oct  7 23:21:32 ionos kernel: [<ffffffff8110bba3>] ? might_fault+0x21/0x23
Oct  7 23:21:32 ionos kernel: [<ffffffff8110bbd4>] ? copy_from_user+0x2f/0x31
Oct  7 23:21:32 ionos kernel: [<ffffffff811d0379>] ? security_file_permission+0x2e/0x33
Oct  7 23:21:32 ionos kernel: [<ffffffff8110cb2e>] do_readv_writev+0xa7/0x129
Oct  7 23:21:32 ionos kernel: [<ffffffff8111bcfc>] ? d_kill+0x3e/0x46
Oct  7 23:21:32 ionos kernel: [<ffffffff8110d7f6>] ? fput+0x214/0x223
Oct  7 23:21:32 ionos kernel: [<ffffffff8110cbf3>] vfs_writev+0x43/0x4e
Oct  7 23:21:32 ionos kernel: [<ffffffff8110cce3>] sys_writev+0x4a/0x93
Oct  7 23:21:32 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct  7 23:21:32 ionos kernel: BUG: unable to handle kernel paging request at 00000037362e313a

We are again dereferencing a user space address.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-07 21:35   ` Thomas Gleixner
@ 2010-10-08  7:52     ` Thomas Gleixner
  2010-10-08 11:46       ` Dave Airlie
  2010-10-08 11:53     ` Chris Wilson
  1 sibling, 1 reply; 19+ messages in thread
From: Thomas Gleixner @ 2010-10-08  7:52 UTC (permalink / raw)
  To: Dave Airlie; +Cc: LKML, Ingo Molnar, Jesse Barnes

On Thu, 7 Oct 2010, Thomas Gleixner wrote:
  Oct  7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
> Oct  7 23:21:31 ionos kernel: drm: unregistered panic notifier
> Oct  7 23:21:31 ionos kernel: vga_switcheroo: disabled
> Oct  7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
> 
> That one scares me :)
> 
> Oct  7 23:21:32 ionos kernel: BUG: unable to handle kernel paging request at 00000037362e313a
> 
> We are again dereferencing a user space address.

Further debugging shows that the interrupt is torn down and the
vectors are cleared. On modprobe the irq is set up again and a
different vector is assigned.

The interrupt which comes in is going to the old vector. So something
is stale in the card.

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-08  7:52     ` Thomas Gleixner
@ 2010-10-08 11:46       ` Dave Airlie
  2010-10-11 22:48         ` Jesse Barnes
  0 siblings, 1 reply; 19+ messages in thread
From: Dave Airlie @ 2010-10-08 11:46 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: LKML, Ingo Molnar, Jesse Barnes, Keith Packard

On Fri, Oct 8, 2010 at 5:52 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 7 Oct 2010, Thomas Gleixner wrote:
>  Oct  7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
>> Oct  7 23:21:31 ionos kernel: drm: unregistered panic notifier
>> Oct  7 23:21:31 ionos kernel: vga_switcheroo: disabled
>> Oct  7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
>>
>> That one scares me :)
>>
>> Oct  7 23:21:32 ionos kernel: BUG: unable to handle kernel paging request at 00000037362e313a
>>
>> We are again dereferencing a user space address.
>
> Further debugging shows that the interrupt is torn down and the
> vectors are cleared. On modprobe the irq is set up again and a
> different vector is assigned.
>
> The interrupt which comes in is going to the old vector. So something
> is stale in the card.

Okay I've traced it with the hints Thomas gave me,

What happens is we have never called pci_disable_device on video
devices for various reasons, like shutting down VGA devices could be
hostile,

however on rmmod of the driver the PCI layer sets the device power
state to PCI_UNKNOWN, when we next load the driver we call
pci_enable_device
which sees the enable cnt is 1, so never calls
pci_set_power_state(PCI_D0), the MSI code won't actually write MSI
msgs unless it knows we are in D0.

Not sure how best to fix, I can workaround by calling
pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
PCI layer should take care of this.

Dave.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-07 21:35   ` Thomas Gleixner
  2010-10-08  7:52     ` Thomas Gleixner
@ 2010-10-08 11:53     ` Chris Wilson
  2010-10-08 12:15       ` Thomas Gleixner
  1 sibling, 1 reply; 19+ messages in thread
From: Chris Wilson @ 2010-10-08 11:53 UTC (permalink / raw)
  To: Thomas Gleixner, Dave Airlie; +Cc: LKML, Ingo Molnar, Jesse Barnes

On Thu, 7 Oct 2010 23:35:43 +0200 (CEST), Thomas Gleixner <tglx@linutronix.de> wrote:
> The first test worked fine. But after I added some debugging I got
> another weird corruption this time on the first unload:
> 
> Oct  7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
> Oct  7 23:21:31 ionos kernel: drm: unregistered panic notifier
> Oct  7 23:21:31 ionos kernel: vga_switcheroo: disabled
> Oct  7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
> 
> That one scares me :)

That was a leak of the object handles which should have been fixed in
.36-rc2

The other horrible crashes look like the set of unload fixes that Daniel
Vetter supplied for .36-rc3 but we postponed to .37.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-08 11:53     ` Chris Wilson
@ 2010-10-08 12:15       ` Thomas Gleixner
  2010-10-08 12:30         ` Chris Wilson
  0 siblings, 1 reply; 19+ messages in thread
From: Thomas Gleixner @ 2010-10-08 12:15 UTC (permalink / raw)
  To: Chris Wilson; +Cc: Dave Airlie, LKML, Ingo Molnar, Jesse Barnes

On Fri, 8 Oct 2010, Chris Wilson wrote:

> On Thu, 7 Oct 2010 23:35:43 +0200 (CEST), Thomas Gleixner <tglx@linutronix.de> wrote:
> > The first test worked fine. But after I added some debugging I got
> > another weird corruption this time on the first unload:
> > 
> > Oct  7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
> > Oct  7 23:21:31 ionos kernel: drm: unregistered panic notifier
> > Oct  7 23:21:31 ionos kernel: vga_switcheroo: disabled
> > Oct  7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
> > 
> > That one scares me :)
> 
> That was a leak of the object handles which should have been fixed in
> .36-rc2

Emphasis on should. That's rc7
 
> The other horrible crashes look like the set of unload fixes that Daniel
> Vetter supplied for .36-rc3 but we postponed to .37.

Well, then you better prevent the removal of the module until it's fixed.

Thanks,

	tglx



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-08 12:15       ` Thomas Gleixner
@ 2010-10-08 12:30         ` Chris Wilson
  0 siblings, 0 replies; 19+ messages in thread
From: Chris Wilson @ 2010-10-08 12:30 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Dave Airlie, LKML, Ingo Molnar, Jesse Barnes

On Fri, 8 Oct 2010 14:15:29 +0200 (CEST), Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 8 Oct 2010, Chris Wilson wrote:
> 
> > That was a leak of the object handles which should have been fixed in
> > .36-rc2
> 
> Emphasis on should. That's rc7

Hmm, that's a new one then. Or, at least the one I know I introduced I
fixed.

> > The other horrible crashes look like the set of unload fixes that Daniel
> > Vetter supplied for .36-rc3 but we postponed to .37.
> 
> Well, then you better prevent the removal of the module until it's fixed.

Is __module_get(THIS_MODULE) sufficient?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-07  8:55 "do_IRQ: 0.89 No irq handler for vector (irq -1)" Dave Airlie
  2010-10-07  9:05 ` Dave Airlie
  2010-10-07 20:38 ` Thomas Gleixner
@ 2010-10-10 17:46 ` Maciej Rutecki
  2 siblings, 0 replies; 19+ messages in thread
From: Maciej Rutecki @ 2010-10-10 17:46 UTC (permalink / raw)
  To: Dave Airlie; +Cc: LKML, Thomas Gleixner, Ingo Molnar, Jesse Barnes

On czwartek, 7 października 2010 o 10:55:15 Dave Airlie wrote:
> We are seeing this on both intel and radeon drivers when we reload the
> module with 2.6.36-rc7 or so, and we get no irqs for that device.
> 
> you can reproduce by
> 
> init 3
> echo 0 > /sys/class/vtconsole/vtcon1/bind
> rmmod i915
> modprobe i915
> 
> or radeon.
> 
> It seems to be possibly MSI related.
> 

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=20022
for your bug report, please add your address to the CC list in there, thanks!

-- 
Maciej Rutecki
http://www.maciek.unixy.pl

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-08 11:46       ` Dave Airlie
@ 2010-10-11 22:48         ` Jesse Barnes
  2010-10-11 23:40           ` Jesse Barnes
  0 siblings, 1 reply; 19+ messages in thread
From: Jesse Barnes @ 2010-10-11 22:48 UTC (permalink / raw)
  To: Dave Airlie
  Cc: Thomas Gleixner, LKML, Ingo Molnar, Keith Packard, Rafael J. Wysocki

On Fri, 8 Oct 2010 21:46:50 +1000
Dave Airlie <airlied@gmail.com> wrote:

> On Fri, Oct 8, 2010 at 5:52 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Thu, 7 Oct 2010, Thomas Gleixner wrote:
> >  Oct  7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
> >> Oct  7 23:21:31 ionos kernel: drm: unregistered panic notifier
> >> Oct  7 23:21:31 ionos kernel: vga_switcheroo: disabled
> >> Oct  7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
> >>
> >> That one scares me :)
> >>
> >> Oct  7 23:21:32 ionos kernel: BUG: unable to handle kernel paging request at 00000037362e313a
> >>
> >> We are again dereferencing a user space address.
> >
> > Further debugging shows that the interrupt is torn down and the
> > vectors are cleared. On modprobe the irq is set up again and a
> > different vector is assigned.
> >
> > The interrupt which comes in is going to the old vector. So something
> > is stale in the card.
> 
> Okay I've traced it with the hints Thomas gave me,
> 
> What happens is we have never called pci_disable_device on video
> devices for various reasons, like shutting down VGA devices could be
> hostile,
> 
> however on rmmod of the driver the PCI layer sets the device power
> state to PCI_UNKNOWN, when we next load the driver we call
> pci_enable_device
> which sees the enable cnt is 1, so never calls
> pci_set_power_state(PCI_D0), the MSI code won't actually write MSI
> msgs unless it knows we are in D0.
> 
> Not sure how best to fix, I can workaround by calling
> pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
> PCI layer should take care of this.

So I think we *should* be able to call pci_disable_device at remove
time.  But as you say, some platforms may not correctly re-route VGA
space to an existing device or disable it properly when we do that.
AFAICT x86 will be ok here though (seems to work ok locally too).

That said, it seems like we should update the current device state at
load time as well, once we've matched the driver it seems like there
should be no harm.

Rafael, what do you think?  Would having the correct power state at
load time cause any trouble with other PM code?  I know we've had
issues with setting it explicitly in the past...

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-11 22:48         ` Jesse Barnes
@ 2010-10-11 23:40           ` Jesse Barnes
  2010-10-12 19:01             ` Rafael J. Wysocki
  0 siblings, 1 reply; 19+ messages in thread
From: Jesse Barnes @ 2010-10-11 23:40 UTC (permalink / raw)
  To: Dave Airlie
  Cc: Thomas Gleixner, LKML, Ingo Molnar, Keith Packard, Rafael J. Wysocki

On Mon, 11 Oct 2010 15:48:26 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Fri, 8 Oct 2010 21:46:50 +1000
> Dave Airlie <airlied@gmail.com> wrote:
> > Not sure how best to fix, I can workaround by calling
> > pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
> > PCI layer should take care of this.
> 
> So I think we *should* be able to call pci_disable_device at remove
> time.  But as you say, some platforms may not correctly re-route VGA
> space to an existing device or disable it properly when we do that.
> AFAICT x86 will be ok here though (seems to work ok locally too).

Just tested this some more, and I think it's the right thing to do in
the KMS case at least.  When we load a KMS driver it takes over the gfx
device and nothing can assume anything about VGA state unless using the
VGA arbiter.  So calling pci_disable_device() in the shutdown path of a
KMS driver shouldn't make things any worse, and will work around this
issue.

Doing so in the non-KMS case violates some PC assumptions though, in
that things like vgacon and the BIOS will assume VGA memory is still
around, which on some platforms pci_disable_device() may affect (I only
checked the x86 implementation).

> That said, it seems like we should update the current device state at
> load time as well, once we've matched the driver it seems like there
> should be no harm.
> 
> Rafael, what do you think?  Would having the correct power state at
> load time cause any trouble with other PM code?  I know we've had
> issues with setting it explicitly in the past...

So we should probably make pci_enable_device pick up the current state
as well, instead of assuming it's unknown just because the enable count
was non-zero (which as Dave points out, can be affected by sysfs writes
too).

The only downside I can think of there is that if the device is already
enabled, we generally have to assume another driver owns it, and who
knows if the device is actually alive enough to read the current state
from.  But I think we handle those errors ok too, so pulling it out
should be safe.

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-11 23:40           ` Jesse Barnes
@ 2010-10-12 19:01             ` Rafael J. Wysocki
  2010-10-12 19:49               ` Jesse Barnes
  2010-10-13 21:20               ` Jesse Barnes
  0 siblings, 2 replies; 19+ messages in thread
From: Rafael J. Wysocki @ 2010-10-12 19:01 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Dave Airlie, Thomas Gleixner, LKML, Ingo Molnar, Keith Packard

On Tuesday, October 12, 2010, Jesse Barnes wrote:
> On Mon, 11 Oct 2010 15:48:26 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > On Fri, 8 Oct 2010 21:46:50 +1000
> > Dave Airlie <airlied@gmail.com> wrote:
> > > Not sure how best to fix, I can workaround by calling
> > > pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
> > > PCI layer should take care of this.
> > 
> > So I think we *should* be able to call pci_disable_device at remove
> > time.  But as you say, some platforms may not correctly re-route VGA
> > space to an existing device or disable it properly when we do that.
> > AFAICT x86 will be ok here though (seems to work ok locally too).
> 
> Just tested this some more, and I think it's the right thing to do in
> the KMS case at least.  When we load a KMS driver it takes over the gfx
> device and nothing can assume anything about VGA state unless using the
> VGA arbiter.  So calling pci_disable_device() in the shutdown path of a
> KMS driver shouldn't make things any worse, and will work around this
> issue.
> 
> Doing so in the non-KMS case violates some PC assumptions though, in
> that things like vgacon and the BIOS will assume VGA memory is still
> around, which on some platforms pci_disable_device() may affect (I only
> checked the x86 implementation).
> 
> > That said, it seems like we should update the current device state at
> > load time as well, once we've matched the driver it seems like there
> > should be no harm.
> > 
> > Rafael, what do you think?  Would having the correct power state at
> > load time cause any trouble with other PM code?  I know we've had
> > issues with setting it explicitly in the past...
> 
> So we should probably make pci_enable_device pick up the current state
> as well, instead of assuming it's unknown just because the enable count
> was non-zero (which as Dave points out, can be affected by sysfs writes
> too).
> 
> The only downside I can think of there is that if the device is already
> enabled, we generally have to assume another driver owns it, and who
> knows if the device is actually alive enough to read the current state
> from.  But I think we handle those errors ok too, so pulling it out
> should be safe.

I remember trying to do something like this and it didn't play well with the
initialization.  Still, I didn't do that in pci_enable_device(), so I can't say
for sure at the moment.  I _think_ it will be fine, though.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-12 19:01             ` Rafael J. Wysocki
@ 2010-10-12 19:49               ` Jesse Barnes
  2010-11-16 19:46                 ` Florian Mickler
  2010-10-13 21:20               ` Jesse Barnes
  1 sibling, 1 reply; 19+ messages in thread
From: Jesse Barnes @ 2010-10-12 19:49 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Dave Airlie, Thomas Gleixner, LKML, Ingo Molnar, Keith Packard

On Tue, 12 Oct 2010 21:01:17 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Tuesday, October 12, 2010, Jesse Barnes wrote:
> > On Mon, 11 Oct 2010 15:48:26 -0700
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > 
> > > On Fri, 8 Oct 2010 21:46:50 +1000
> > > Dave Airlie <airlied@gmail.com> wrote:
> > > > Not sure how best to fix, I can workaround by calling
> > > > pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
> > > > PCI layer should take care of this.
> > > 
> > > So I think we *should* be able to call pci_disable_device at remove
> > > time.  But as you say, some platforms may not correctly re-route VGA
> > > space to an existing device or disable it properly when we do that.
> > > AFAICT x86 will be ok here though (seems to work ok locally too).
> > 
> > Just tested this some more, and I think it's the right thing to do in
> > the KMS case at least.  When we load a KMS driver it takes over the gfx
> > device and nothing can assume anything about VGA state unless using the
> > VGA arbiter.  So calling pci_disable_device() in the shutdown path of a
> > KMS driver shouldn't make things any worse, and will work around this
> > issue.
> > 
> > Doing so in the non-KMS case violates some PC assumptions though, in
> > that things like vgacon and the BIOS will assume VGA memory is still
> > around, which on some platforms pci_disable_device() may affect (I only
> > checked the x86 implementation).
> > 
> > > That said, it seems like we should update the current device state at
> > > load time as well, once we've matched the driver it seems like there
> > > should be no harm.
> > > 
> > > Rafael, what do you think?  Would having the correct power state at
> > > load time cause any trouble with other PM code?  I know we've had
> > > issues with setting it explicitly in the past...
> > 
> > So we should probably make pci_enable_device pick up the current state
> > as well, instead of assuming it's unknown just because the enable count
> > was non-zero (which as Dave points out, can be affected by sysfs writes
> > too).
> > 
> > The only downside I can think of there is that if the device is already
> > enabled, we generally have to assume another driver owns it, and who
> > knows if the device is actually alive enough to read the current state
> > from.  But I think we handle those errors ok too, so pulling it out
> > should be safe.
> 
> I remember trying to do something like this and it didn't play well with the
> initialization.  Still, I didn't do that in pci_enable_device(), so I can't say
> for sure at the moment.  I _think_ it will be fine, though.

Seems to work ok for the buggy i915 reload case.  But looking at it
again, I really don't like two things:
  1) doing just the set_power_state seems wrong, what about the rest of
  enable?
  2) allowing nested enables at all

I know sysfs currently allows us to bump the enable count to arbitrary
levels, but that's easy to fix; we can just check pci_is_enabled()
before calling enable_device in the sysfs store routine.

If we did that, we could warn when pci_enable_device is called in a
nested way, which is generally a bug (two drivers trying to take over a
device?).

I don't think I buy that VGA is special anyway, at least not for KMS
enabled kernels, where vgacon and the BIOS can't assume anything about
graphics state anymore.  More generally, I don't think BIOSes have been
able to assume anything about the current graphics state since Windows
3.1, when most platforms stopped using BIOS calls and/or VGA regs for
mode setting.

Thoughts?

-- 
Jesse Barnes, Intel Open Source Technology Center

--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -963,9 +963,6 @@ static int do_pci_enable_device(struct pci_dev *dev, int bar
 {
        int err;
 
-       err = pci_set_power_state(dev, PCI_D0);
-       if (err < 0 && err != -EIO)
-               return err;
        err = pcibios_enable_device(dev, bars);
        if (err < 0)
                return err;
@@ -994,6 +991,10 @@ static int __pci_enable_device_flags(struct pci_dev *dev,
        int err;
        int i, bars = 0;
 
+       err = pci_set_power_state(dev, PCI_D0);
+       if (err < 0 && err != -EIO)
+               return err;
+
        if (atomic_add_return(1, &dev->enable_cnt) > 1)
                return 0;               /* already enabled */
 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-12 19:01             ` Rafael J. Wysocki
  2010-10-12 19:49               ` Jesse Barnes
@ 2010-10-13 21:20               ` Jesse Barnes
  2010-10-13 21:48                 ` Rafael J. Wysocki
  1 sibling, 1 reply; 19+ messages in thread
From: Jesse Barnes @ 2010-10-13 21:20 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Dave Airlie, Thomas Gleixner, LKML, Ingo Molnar, Keith Packard

On Tue, 12 Oct 2010 21:01:17 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Tuesday, October 12, 2010, Jesse Barnes wrote:
> > On Mon, 11 Oct 2010 15:48:26 -0700
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > 
> > > On Fri, 8 Oct 2010 21:46:50 +1000
> > > Dave Airlie <airlied@gmail.com> wrote:
> > > > Not sure how best to fix, I can workaround by calling
> > > > pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
> > > > PCI layer should take care of this.
> > > 
> > > So I think we *should* be able to call pci_disable_device at remove
> > > time.  But as you say, some platforms may not correctly re-route VGA
> > > space to an existing device or disable it properly when we do that.
> > > AFAICT x86 will be ok here though (seems to work ok locally too).
> > 
> > Just tested this some more, and I think it's the right thing to do in
> > the KMS case at least.  When we load a KMS driver it takes over the gfx
> > device and nothing can assume anything about VGA state unless using the
> > VGA arbiter.  So calling pci_disable_device() in the shutdown path of a
> > KMS driver shouldn't make things any worse, and will work around this
> > issue.
> > 
> > Doing so in the non-KMS case violates some PC assumptions though, in
> > that things like vgacon and the BIOS will assume VGA memory is still
> > around, which on some platforms pci_disable_device() may affect (I only
> > checked the x86 implementation).
> > 
> > > That said, it seems like we should update the current device state at
> > > load time as well, once we've matched the driver it seems like there
> > > should be no harm.
> > > 
> > > Rafael, what do you think?  Would having the correct power state at
> > > load time cause any trouble with other PM code?  I know we've had
> > > issues with setting it explicitly in the past...
> > 
> > So we should probably make pci_enable_device pick up the current state
> > as well, instead of assuming it's unknown just because the enable count
> > was non-zero (which as Dave points out, can be affected by sysfs writes
> > too).
> > 
> > The only downside I can think of there is that if the device is already
> > enabled, we generally have to assume another driver owns it, and who
> > knows if the device is actually alive enough to read the current state
> > from.  But I think we handle those errors ok too, so pulling it out
> > should be safe.
> 
> I remember trying to do something like this and it didn't play well with the
> initialization.  Still, I didn't do that in pci_enable_device(), so I can't say
> for sure at the moment.  I _think_ it will be fine, though.

Here's what I had in mind.  I think it's safer than setting the power
state at enable time, and it works around the enable_cnt leak in the
DRM drivers.

-- 
Jesse Barnes, Intel Open Source Technology Center

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7fa3cbd..37facc1 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -994,6 +994,18 @@ static int __pci_enable_device_flags(struct pci_dev *dev,
 	int err;
 	int i, bars = 0;
 
+	/*
+	 * Power state could be unknown at this point, either due to a fresh
+	 * boot or a device removal call.  So get the current power state
+	 * so that things like MSI message writing will behave as expected
+	 * (e.g. if the device really is in D0 at enable time).
+	 */
+	if (dev->pm_cap) {
+		u16 pmcsr;
+		pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
+		dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK);
+	}
+
 	if (atomic_add_return(1, &dev->enable_cnt) > 1)
 		return 0;		/* already enabled */
 


^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-13 21:20               ` Jesse Barnes
@ 2010-10-13 21:48                 ` Rafael J. Wysocki
  0 siblings, 0 replies; 19+ messages in thread
From: Rafael J. Wysocki @ 2010-10-13 21:48 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Dave Airlie, Thomas Gleixner, LKML, Ingo Molnar, Keith Packard

On Wednesday, October 13, 2010, Jesse Barnes wrote:
> On Tue, 12 Oct 2010 21:01:17 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Tuesday, October 12, 2010, Jesse Barnes wrote:
> > > On Mon, 11 Oct 2010 15:48:26 -0700
> > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > 
> > > > On Fri, 8 Oct 2010 21:46:50 +1000
> > > > Dave Airlie <airlied@gmail.com> wrote:
> > > > > Not sure how best to fix, I can workaround by calling
> > > > > pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
> > > > > PCI layer should take care of this.
> > > > 
> > > > So I think we *should* be able to call pci_disable_device at remove
> > > > time.  But as you say, some platforms may not correctly re-route VGA
> > > > space to an existing device or disable it properly when we do that.
> > > > AFAICT x86 will be ok here though (seems to work ok locally too).
> > > 
> > > Just tested this some more, and I think it's the right thing to do in
> > > the KMS case at least.  When we load a KMS driver it takes over the gfx
> > > device and nothing can assume anything about VGA state unless using the
> > > VGA arbiter.  So calling pci_disable_device() in the shutdown path of a
> > > KMS driver shouldn't make things any worse, and will work around this
> > > issue.
> > > 
> > > Doing so in the non-KMS case violates some PC assumptions though, in
> > > that things like vgacon and the BIOS will assume VGA memory is still
> > > around, which on some platforms pci_disable_device() may affect (I only
> > > checked the x86 implementation).
> > > 
> > > > That said, it seems like we should update the current device state at
> > > > load time as well, once we've matched the driver it seems like there
> > > > should be no harm.
> > > > 
> > > > Rafael, what do you think?  Would having the correct power state at
> > > > load time cause any trouble with other PM code?  I know we've had
> > > > issues with setting it explicitly in the past...
> > > 
> > > So we should probably make pci_enable_device pick up the current state
> > > as well, instead of assuming it's unknown just because the enable count
> > > was non-zero (which as Dave points out, can be affected by sysfs writes
> > > too).
> > > 
> > > The only downside I can think of there is that if the device is already
> > > enabled, we generally have to assume another driver owns it, and who
> > > knows if the device is actually alive enough to read the current state
> > > from.  But I think we handle those errors ok too, so pulling it out
> > > should be safe.
> > 
> > I remember trying to do something like this and it didn't play well with the
> > initialization.  Still, I didn't do that in pci_enable_device(), so I can't say
> > for sure at the moment.  I _think_ it will be fine, though.
> 
> Here's what I had in mind.  I think it's safer than setting the power
> state at enable time, and it works around the enable_cnt leak in the
> DRM drivers.

However, it would have to be done after pci_pm_init() runs.  Perhaps we can
make pci_pm_init() itself put the device into D0?

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-10-12 19:49               ` Jesse Barnes
@ 2010-11-16 19:46                 ` Florian Mickler
  2010-11-16 20:11                   ` Jesse Barnes
  0 siblings, 1 reply; 19+ messages in thread
From: Florian Mickler @ 2010-11-16 19:46 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Rafael J. Wysocki, Dave Airlie, Thomas Gleixner, LKML,
	Ingo Molnar, Keith Packard

On Tue, 12 Oct 2010 12:49:38 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Tue, 12 Oct 2010 21:01:17 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Tuesday, October 12, 2010, Jesse Barnes wrote:
> > > On Mon, 11 Oct 2010 15:48:26 -0700
> > > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > 
> > > > On Fri, 8 Oct 2010 21:46:50 +1000
> > > > Dave Airlie <airlied@gmail.com> wrote:
> > > > > Not sure how best to fix, I can workaround by calling
> > > > > pci_set_power_state(PCI_D0) in the drm drivers, but I sorta thing the
> > > > > PCI layer should take care of this.
> > > > 
> > > > So I think we *should* be able to call pci_disable_device at remove
> > > > time.  But as you say, some platforms may not correctly re-route VGA
> > > > space to an existing device or disable it properly when we do that.
> > > > AFAICT x86 will be ok here though (seems to work ok locally too).
> > > 
> > > Just tested this some more, and I think it's the right thing to do in
> > > the KMS case at least.  When we load a KMS driver it takes over the gfx
> > > device and nothing can assume anything about VGA state unless using the
> > > VGA arbiter.  So calling pci_disable_device() in the shutdown path of a
> > > KMS driver shouldn't make things any worse, and will work around this
> > > issue.
> > > 
> > > Doing so in the non-KMS case violates some PC assumptions though, in
> > > that things like vgacon and the BIOS will assume VGA memory is still
> > > around, which on some platforms pci_disable_device() may affect (I only
> > > checked the x86 implementation).
> > > 
> > > > That said, it seems like we should update the current device state at
> > > > load time as well, once we've matched the driver it seems like there
> > > > should be no harm.
> > > > 
> > > > Rafael, what do you think?  Would having the correct power state at
> > > > load time cause any trouble with other PM code?  I know we've had
> > > > issues with setting it explicitly in the past...
> > > 
> > > So we should probably make pci_enable_device pick up the current state
> > > as well, instead of assuming it's unknown just because the enable count
> > > was non-zero (which as Dave points out, can be affected by sysfs writes
> > > too).
> > > 
> > > The only downside I can think of there is that if the device is already
> > > enabled, we generally have to assume another driver owns it, and who
> > > knows if the device is actually alive enough to read the current state
> > > from.  But I think we handle those errors ok too, so pulling it out
> > > should be safe.
> > 
> > I remember trying to do something like this and it didn't play well with the
> > initialization.  Still, I didn't do that in pci_enable_device(), so I can't say
> > for sure at the moment.  I _think_ it will be fine, though.
> 
> Seems to work ok for the buggy i915 reload case.  But looking at it
> again, I really don't like two things:
>   1) doing just the set_power_state seems wrong, what about the rest of
>   enable?
>   2) allowing nested enables at all
> 
> I know sysfs currently allows us to bump the enable count to arbitrary
> levels, but that's easy to fix; we can just check pci_is_enabled()
> before calling enable_device in the sysfs store routine.
> 
> If we did that, we could warn when pci_enable_device is called in a
> nested way, which is generally a bug (two drivers trying to take over a
> device?).
> 
> I don't think I buy that VGA is special anyway, at least not for KMS
> enabled kernels, where vgacon and the BIOS can't assume anything about
> graphics state anymore.  More generally, I don't think BIOSes have been
> able to assume anything about the current graphics state since Windows
> 3.1, when most platforms stopped using BIOS calls and/or VGA regs for
> mode setting.
> 
> Thoughts?
> 

does this need to go to 2.6.36.y? (is it already on it's way?)

commit 97c145f7c87453cec90e91238fba5fe2c1561b32
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Nov 5 15:16:36 2010 -0400

    PCI: read current power state at enable time


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-11-16 19:46                 ` Florian Mickler
@ 2010-11-16 20:11                   ` Jesse Barnes
  2010-11-16 20:47                     ` Florian Mickler
  0 siblings, 1 reply; 19+ messages in thread
From: Jesse Barnes @ 2010-11-16 20:11 UTC (permalink / raw)
  To: Florian Mickler
  Cc: Rafael J. Wysocki, Dave Airlie, Thomas Gleixner, LKML,
	Ingo Molnar, Keith Packard

On Tue, 16 Nov 2010 20:46:45 +0100
Florian Mickler <florian@mickler.org> wrote:

> On Tue, 12 Oct 2010 12:49:38 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > I don't think I buy that VGA is special anyway, at least not for KMS
> > enabled kernels, where vgacon and the BIOS can't assume anything about
> > graphics state anymore.  More generally, I don't think BIOSes have been
> > able to assume anything about the current graphics state since Windows
> > 3.1, when most platforms stopped using BIOS calls and/or VGA regs for
> > mode setting.
> > 
> > Thoughts?
> > 
> 
> does this need to go to 2.6.36.y? (is it already on it's way?)
> 
> commit 97c145f7c87453cec90e91238fba5fe2c1561b32
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Fri Nov 5 15:16:36 2010 -0400
> 
>     PCI: read current power state at enable time

I hadn't planned on pushing this to stable, but if you have a need
for it there, feel free to propose it.

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
  2010-11-16 20:11                   ` Jesse Barnes
@ 2010-11-16 20:47                     ` Florian Mickler
  0 siblings, 0 replies; 19+ messages in thread
From: Florian Mickler @ 2010-11-16 20:47 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Rafael J. Wysocki, Dave Airlie, Thomas Gleixner, LKML,
	Ingo Molnar, Keith Packard

On Tue, 16 Nov 2010 12:11:07 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Tue, 16 Nov 2010 20:46:45 +0100
> Florian Mickler <florian@mickler.org> wrote:
> 
> > On Tue, 12 Oct 2010 12:49:38 -0700
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > I don't think I buy that VGA is special anyway, at least not for KMS
> > > enabled kernels, where vgacon and the BIOS can't assume anything about
> > > graphics state anymore.  More generally, I don't think BIOSes have been
> > > able to assume anything about the current graphics state since Windows
> > > 3.1, when most platforms stopped using BIOS calls and/or VGA regs for
> > > mode setting.
> > > 
> > > Thoughts?
> > > 
> > 
> > does this need to go to 2.6.36.y? (is it already on it's way?)
> > 
> > commit 97c145f7c87453cec90e91238fba5fe2c1561b32
> > Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> > Date:   Fri Nov 5 15:16:36 2010 -0400
> > 
> >     PCI: read current power state at enable time
> 
> I hadn't planned on pushing this to stable, but if you have a need
> for it there, feel free to propose it.
> 
No, I don't need it. I was closing a regression tracker and thought I
should check. You can judge the impact better then me. 

Regards,
Flo

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2010-11-16 20:47 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-07  8:55 "do_IRQ: 0.89 No irq handler for vector (irq -1)" Dave Airlie
2010-10-07  9:05 ` Dave Airlie
2010-10-07 20:38 ` Thomas Gleixner
2010-10-07 21:35   ` Thomas Gleixner
2010-10-08  7:52     ` Thomas Gleixner
2010-10-08 11:46       ` Dave Airlie
2010-10-11 22:48         ` Jesse Barnes
2010-10-11 23:40           ` Jesse Barnes
2010-10-12 19:01             ` Rafael J. Wysocki
2010-10-12 19:49               ` Jesse Barnes
2010-11-16 19:46                 ` Florian Mickler
2010-11-16 20:11                   ` Jesse Barnes
2010-11-16 20:47                     ` Florian Mickler
2010-10-13 21:20               ` Jesse Barnes
2010-10-13 21:48                 ` Rafael J. Wysocki
2010-10-08 11:53     ` Chris Wilson
2010-10-08 12:15       ` Thomas Gleixner
2010-10-08 12:30         ` Chris Wilson
2010-10-10 17:46 ` Maciej Rutecki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).