* "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-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: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
* 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-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
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).