* Ethernet chip disappeared from lspci
@ 2015-06-19 13:24 Boszormenyi Zoltan
2015-06-19 13:31 ` Boszormenyi Zoltan
0 siblings, 1 reply; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-19 13:24 UTC (permalink / raw)
To: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]
Hi,
I have a problem on a special POS mainboard that has
a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5.
The initial problem was that when r8169 was not blacklisted,
as soon as this driver loaded, a lot of IRQ problems popped up,
like pressing keys on the USB keyboard made the keys duplicated
and the system was sluggish. Upon powering off the system,
the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
or something like that and the system couldn't even reboot or
get powered down properly.
It was impossible to get dmesg or other diagnostics info out of
the system in this state.
When I blacklisted r8169, everything was OK except there was
no network, obviously.
I also noticed that with kernel 4.0.5, there are memory range conflicts, like
pci 0000:00:02.0: can't claim BAR 0 [mem ....]: address conflict with PCI Bus 0000:00 [mem
... window]
I also tried to load the r8168 driver from Realtek, with the
same results as with r8169.
I don't know what happened, was it the "official" Realtek driver
that disabled the chip, or that I toggled the PXE boot in the BIOS,
but now lspci doesn't list the ethernet chip anymore and not even
the PXE boot messages show up, despite it being enabled in the BIOS.
I tried kernels 3.18.16, 4.0.5 again and 4.1.0-rc8.
I have this in dmesg:
[ 0.136171] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 10 11 12 14 15)
[ 0.136323] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 *14 15)
[ 0.136466] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
[ 0.136609] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
[ 0.136751] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 0.136894] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 0.137050] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 0.137195] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 *6 7 10 11 12 14 15)
and
[ 0.139098] PCI: Using ACPI for IRQ routing
[ 0.139098] PCI: pci_cache_line_size set to 64 bytes
[ 0.139098] pci 0000:00:02.0: can't claim BAR 0 [mem 0xfeb00000-0xfeb7ffff]: address
conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139098] pci 0000:00:02.0: can't claim BAR 2 [mem 0xd0000000-0xdfffffff pref]:
address conflict with PCI Bus 0000:00 [mem 0x7f700000-0xdfffffff window]
[ 0.139104] pci 0000:00:02.0: can't claim BAR 3 [mem 0xfea00000-0xfeafffff]: address
conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139113] pci 0000:00:02.1: can't claim BAR 0 [mem 0xfeb80000-0xfebfffff]: address
conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139123] pci 0000:00:1b.0: can't claim BAR 0 [mem 0xfe9f8000-0xfe9fbfff 64bit]:
address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139146] pci 0000:00:1d.7: can't claim BAR 0 [mem 0xfe9f7c00-0xfe9f7fff]: address
conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139161] pci 0000:00:1f.2: can't claim BAR 5 [mem 0xfe9f7800-0xfe9f7bff]: address
conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139190] Expanded resource reserved due to conflict with PCI Bus 0000:00
Full dmesg for 4.0.5 is attached.
Can anyone help me re-enable the network card?
Thanks in advance,
Zoltán Böszörményi
[-- Attachment #2: dmesg-4.0.5.log --]
[-- Type: text/x-log, Size: 46344 bytes --]
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 4.0.5 (zboszormenyi@buildbox-0001.sicom.com) (gcc version 4.8.2 (GCC) ) #1 SMP Wed Jun 17 12:17:52 EDT 2015
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007f58ffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007f590000-0x000000007f59dfff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x000000007f59e000-0x000000007f5cffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007f5d0000-0x000000007f5dffff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007f5ed000-0x000000007fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
[ 0.000000] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
[ 0.000000] SMBIOS 2.6 present.
[ 0.000000] DMI: SI SL20/SL20, BIOS 080016 04/01/2013
[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000000] e820: last_pfn = 0x7f590 max_arch_pfn = 0x100000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-CFFFF write-protect
[ 0.000000] D0000-DFFFF uncachable
[ 0.000000] E0000-EFFFF write-through
[ 0.000000] F0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000 mask F80000000 write-back
[ 0.000000] 1 base 07F600000 mask FFFF00000 write-through
[ 0.000000] 2 base 07F700000 mask FFFF00000 uncachable
[ 0.000000] 3 base 07F800000 mask FFF800000 uncachable
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC
[ 0.000000] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [c00ff780]
[ 0.000000] initial memory mapped: [mem 0x00000000-0x013fffff]
[ 0.000000] Base memory trampoline at [c009b000] 9b000 size 16384
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[ 0.000000] [mem 0x00000000-0x000fffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x37000000-0x373fffff]
[ 0.000000] [mem 0x37000000-0x373fffff] page 4M
[ 0.000000] init_memory_mapping: [mem 0x00100000-0x36ffffff]
[ 0.000000] [mem 0x00100000-0x003fffff] page 4k
[ 0.000000] [mem 0x00400000-0x36ffffff] page 4M
[ 0.000000] init_memory_mapping: [mem 0x37400000-0x377fdfff]
[ 0.000000] [mem 0x37400000-0x377fdfff] page 4k
[ 0.000000] BRK [0x00ee7000, 0x00ee7fff] PGTABLE
[ 0.000000] RAMDISK: [mem 0x37c22000-0x37e08fff]
[ 0.000000] Allocated new RAMDISK: [mem 0x37617000-0x377fda83]
[ 0.000000] Move RAMDISK from [mem 0x37c22000-0x37e08a83] to [mem 0x37617000-0x377fda83]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000000F99E0 000014 (v00 ACPIAM)
[ 0.000000] ACPI: RSDT 0x000000007F590000 000040 (v01 040113 RSDT2108 20130401 MSFT 00000097)
[ 0.000000] ACPI: FACP 0x000000007F590200 000084 (v01 040113 FACP2108 20130401 MSFT 00000097)
[ 0.000000] ACPI: DSDT 0x000000007F590440 004F45 (v01 1AAAA 1AAAA000 00000000 INTL 20051117)
[ 0.000000] ACPI: FACS 0x000000007F59E000 000040
[ 0.000000] ACPI: APIC 0x000000007F590390 00006C (v01 040113 APIC2108 20130401 MSFT 00000097)
[ 0.000000] ACPI: MCFG 0x000000007F590400 00003C (v01 040113 OEMMCFG 20130401 MSFT 00000097)
[ 0.000000] ACPI: OEMB 0x000000007F59E040 000082 (v01 040113 OEMB2108 20130401 MSFT 00000097)
[ 0.000000] ACPI: HPET 0x000000007F59A440 000038 (v01 040113 OEMHPET 20130401 MSFT 00000097)
[ 0.000000] ACPI: GSCI 0x000000007F59E0D0 002024 (v01 040113 GMCHSCI 20130401 MSFT 00000097)
[ 0.000000] ACPI: SSDT 0x000000007F5A0730 0004F0 (v01 PmRef CpuPm 00003000 INTL 20051117)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] 1149MB HIGHMEM available.
[ 0.000000] 887MB LOWMEM available.
[ 0.000000] mapped low ram: 0 - 377fe000
[ 0.000000] low ram: 0 - 377fe000
[ 0.000000] BRK [0x00ee8000, 0x00ee8fff] PGTABLE
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] Normal [mem 0x0000000001000000-0x00000000377fdfff]
[ 0.000000] HighMem [mem 0x00000000377fe000-0x000000007f58ffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff]
[ 0.000000] node 0: [mem 0x0000000000100000-0x000000007f58ffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000007f58ffff]
[ 0.000000] On node 0 totalpages: 521518
[ 0.000000] free_area_init_node: node 0, pgdat c0d17740, node_mem_map f622b028
[ 0.000000] DMA zone: 40 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 3998 pages, LIFO batch:0
[ 0.000000] Normal zone: 2180 pages used for memmap
[ 0.000000] Normal zone: 223230 pages, LIFO batch:31
[ 0.000000] HighMem zone: 294290 pages, LIFO batch:31
[ 0.000000] Using APIC driver default
[ 0.000000] Reserving Intel graphics stolen memory at 0x7f800000-0x7fffffff
[ 0.000000] ACPI: PM-Timer IO Port: 0x808
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[ 0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0xffffffff base: 0xfed00000
[ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000dffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000e0000-0x000fffff]
[ 0.000000] e820: [mem 0x80000000-0xfedfffff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on bare hardware
[ 0.000000] setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 18 pages/cpu @f61d7000 s40972 r0 d32756 u73728
[ 0.000000] pcpu-alloc: s40972 r0 d32756 u73728 alloc=18*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 519298
[ 0.000000] Kernel command line: BOOT_IMAGE=/bzImage root=UUID=b2cccbac-2717-4fcb-ae65-15189e087778 ro quiet LANG=en.US.UTF-8
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Initializing CPU#0
[ 0.000000] Initializing HighMem for node 0 (000377fe:0007f590)
[ 0.000000] Initializing Movable for node 0 (00000000:00000000)
[ 0.000000] Memory: 2051344K/2086072K available (6222K kernel code, 614K rwdata, 2584K rodata, 792K init, 884K bss, 34728K reserved, 0K cma-reserved, 1177160K highmem)
[ 0.000000] virtual kernel memory layout:
fixmap : 0xfff66000 - 0xfffff000 ( 612 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xf7ffe000 - 0xff7fe000 ( 120 MB)
lowmem : 0xc0000000 - 0xf77fe000 ( 887 MB)
.init : 0xc0d36000 - 0xc0dfc000 ( 792 kB)
.data : 0xc0a13c03 - 0xc0d34b40 (3203 kB)
.text : 0xc0400000 - 0xc0a13c03 (6223 kB)
[ 0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] NR_IRQS:2304 nr_irqs:456 16
[ 0.000000] CPU 0 irqstacks, hard=f5c36000 soft=f5c38000
[ 0.000000] Offload RCU callbacks from all CPUs
[ 0.000000] Offload RCU callbacks from CPUs: 0-3.
[ 0.000000] Console: colour VGA+ 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 1800.086 MHz processor
[ 0.001014] Calibrating delay loop (skipped), value calculated using timer frequency.. 3600.17 BogoMIPS (lpj=1800086)
[ 0.001023] pid_max: default: 32768 minimum: 301
[ 0.001041] ACPI: Core revision 20150204
[ 0.012851] ACPI: All ACPI Tables successfully acquired
[ 0.013087] Security Framework initialized
[ 0.013099] SELinux: Initializing.
[ 0.013112] SELinux: Starting in permissive mode
[ 0.013204] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.013211] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.013585] Initializing cgroup subsys blkio
[ 0.013594] Initializing cgroup subsys memory
[ 0.013611] Initializing cgroup subsys devices
[ 0.013618] Initializing cgroup subsys freezer
[ 0.013625] Initializing cgroup subsys net_cls
[ 0.013632] Initializing cgroup subsys perf_event
[ 0.013639] Initializing cgroup subsys net_prio
[ 0.013684] CPU: Physical Processor ID: 0
[ 0.013688] CPU: Processor Core ID: 0
[ 0.013696] mce: CPU supports 5 MCE banks
[ 0.014019] CPU0: Thermal monitoring enabled (TM1)
[ 0.014026] process: using mwait in idle threads
[ 0.014037] Last level iTLB entries: 4KB 32, 2MB 0, 4MB 0
[ 0.014041] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 8, 1GB 0
[ 0.014568] Freeing SMP alternatives memory: 32K (c0dfc000 - c0e04000)
[ 0.016491] ftrace: allocating 26182 entries in 52 pages
[ 0.031169] Enabling APIC mode: Flat. Using 1 I/O APICs
[ 0.032288] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.043000] smpboot: CPU0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (fam: 06, model: 1c, stepping: 0a)
[ 0.043000] Performance Events: PEBS fmt0+, 8-deep LBR, Atom events, Intel PMU driver.
[ 0.043000] ... version: 3
[ 0.043000] ... bit width: 40
[ 0.043000] ... generic registers: 2
[ 0.043000] ... value mask: 000000ffffffffff
[ 0.043000] ... max period: 000000007fffffff
[ 0.043000] ... fixed-purpose events: 3
[ 0.043000] ... event mask: 0000000700000003
[ 0.043892] CPU 1 irqstacks, hard=f5d6c000 soft=f5d6e000
[ 0.043897] x86: Booting SMP configuration:
[ 0.043901] .... node #0, CPUs: #1
[ 0.002000] Initializing CPU#1
[ 0.002000] Disabled fast string operations
[ 0.056195] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[ 0.056573] CPU 2 irqstacks, hard=f5dee000 soft=f5df0000
[ 0.056578] #2
[ 0.002000] Initializing CPU#2
[ 0.002000] Disabled fast string operations
[ 0.069172] CPU 3 irqstacks, hard=f5e14000 soft=f5e16000
[ 0.069181] #3
[ 0.002000] Initializing CPU#3
[ 0.002000] Disabled fast string operations
[ 0.082070] x86: Booted up 1 node, 4 CPUs
[ 0.082083] smpboot: Total of 4 processors activated (14400.68 BogoMIPS)
[ 0.084166] devtmpfs: initialized
[ 0.084476] PM: Registering ACPI NVS region [mem 0x7f59e000-0x7f5cffff] (204800 bytes)
[ 0.085191] atomic64_test: passed for i586+ platform with CX8 and with SSE
[ 0.085191] pinctrl core: initialized pinctrl subsystem
[ 0.085191] RTC time: 12:50:11, date: 06/19/15
[ 0.085488] NET: Registered protocol family 16
[ 0.089019] cpuidle: using governor menu
[ 0.089192] ACPI: bus type PCI registered
[ 0.089369] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.089377] PCI: not using MMCONFIG
[ 0.089602] PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=4
[ 0.089605] PCI: Using configuration type 1 for base access
[ 0.099130] ACPI: Added _OSI(Module Device)
[ 0.099130] ACPI: Added _OSI(Processor Device)
[ 0.099130] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.099130] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.103125] ACPI: Executed 1 blocks of module-level executable AML code
[ 0.107466] ACPI: Dynamic OEM Table Load:
[ 0.107484] ACPI: SSDT 0x00000000F5EF8000 000594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117)
[ 0.108734] ACPI: Dynamic OEM Table Load:
[ 0.108745] ACPI: SSDT 0x00000000F5E3FC00 000085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117)
[ 0.109691] ACPI: Interpreter enabled
[ 0.109714] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150204/hwxface-580)
[ 0.109724] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20150204/hwxface-580)
[ 0.109749] ACPI: (supports S0 S1 S4 S5)
[ 0.109753] ACPI: Using IOAPIC for interrupt routing
[ 0.109811] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.111642] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[ 0.111647] PCI: Using MMCONFIG for extended config space
[ 0.111691] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.126713] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.126730] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.127489] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 0.128053] acpi PNP0A08:00: host bridge window expanded to [mem 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
[ 0.128290] PCI host bridge to bus 0000:00
[ 0.128299] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.128306] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 0.128312] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 0.128318] pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffff window]
[ 0.128324] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff window]
[ 0.128330] pci_bus 0000:00: root bus resource [mem 0x7f700000-0xdfffffff window]
[ 0.128336] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfed8ffff window]
[ 0.128356] pci 0000:00:00.0: [8086:a000] type 00 class 0x060000
[ 0.128587] pci 0000:00:02.0: [8086:a001] type 00 class 0x030000
[ 0.128604] pci 0000:00:02.0: reg 0x10: [mem 0xfeb00000-0xfeb7ffff]
[ 0.128614] pci 0000:00:02.0: reg 0x14: [io 0xec00-0xec07]
[ 0.128624] pci 0000:00:02.0: reg 0x18: [mem 0xd0000000-0xdfffffff pref]
[ 0.128633] pci 0000:00:02.0: reg 0x1c: [mem 0xfea00000-0xfeafffff]
[ 0.128865] pci 0000:00:02.1: [8086:a002] type 00 class 0x038000
[ 0.128880] pci 0000:00:02.1: reg 0x10: [mem 0xfeb80000-0xfebfffff]
[ 0.129159] pci 0000:00:1b.0: [8086:27d8] type 00 class 0x040300
[ 0.129189] pci 0000:00:1b.0: reg 0x10: [mem 0xfe9f8000-0xfe9fbfff 64bit]
[ 0.129308] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.129526] pci 0000:00:1c.0: [8086:27d0] type 01 class 0x060400
[ 0.129642] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.129742] pci 0000:00:1c.0: System wakeup disabled by ACPI
[ 0.129890] pci 0000:00:1c.1: [8086:27d2] type 01 class 0x060400
[ 0.130015] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
[ 0.130115] pci 0000:00:1c.1: System wakeup disabled by ACPI
[ 0.130274] pci 0000:00:1c.3: [8086:27d6] type 01 class 0x060400
[ 0.130390] pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
[ 0.130488] pci 0000:00:1c.3: System wakeup disabled by ACPI
[ 0.130637] pci 0000:00:1d.0: [8086:27c8] type 00 class 0x0c0300
[ 0.130693] pci 0000:00:1d.0: reg 0x20: [io 0xe400-0xe41f]
[ 0.130854] pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 0.131009] pci 0000:00:1d.1: [8086:27c9] type 00 class 0x0c0300
[ 0.131065] pci 0000:00:1d.1: reg 0x20: [io 0xe480-0xe49f]
[ 0.131215] pci 0000:00:1d.1: System wakeup disabled by ACPI
[ 0.131360] pci 0000:00:1d.2: [8086:27ca] type 00 class 0x0c0300
[ 0.131416] pci 0000:00:1d.2: reg 0x20: [io 0xe800-0xe81f]
[ 0.131564] pci 0000:00:1d.2: System wakeup disabled by ACPI
[ 0.131714] pci 0000:00:1d.3: [8086:27cb] type 00 class 0x0c0300
[ 0.131770] pci 0000:00:1d.3: reg 0x20: [io 0xe880-0xe89f]
[ 0.131918] pci 0000:00:1d.3: System wakeup disabled by ACPI
[ 0.132084] pci 0000:00:1d.7: [8086:27cc] type 00 class 0x0c0320
[ 0.132111] pci 0000:00:1d.7: reg 0x10: [mem 0xfe9f7c00-0xfe9f7fff]
[ 0.132219] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[ 0.132313] pci 0000:00:1d.7: System wakeup disabled by ACPI
[ 0.132461] pci 0000:00:1e.0: [8086:2448] type 01 class 0x060401
[ 0.132614] pci 0000:00:1e.0: System wakeup disabled by ACPI
[ 0.132759] pci 0000:00:1f.0: [8086:27bc] type 00 class 0x060100
[ 0.133079] pci 0000:00:1f.2: [8086:27c0] type 00 class 0x01018f
[ 0.133104] pci 0000:00:1f.2: reg 0x10: [io 0xd800-0xd807]
[ 0.133119] pci 0000:00:1f.2: reg 0x14: [io 0xe080-0xe083]
[ 0.133133] pci 0000:00:1f.2: reg 0x18: [io 0xe000-0xe007]
[ 0.133148] pci 0000:00:1f.2: reg 0x1c: [io 0xdc00-0xdc03]
[ 0.133162] pci 0000:00:1f.2: reg 0x20: [io 0xd880-0xd88f]
[ 0.133177] pci 0000:00:1f.2: reg 0x24: [mem 0xfe9f7800-0xfe9f7bff]
[ 0.133231] pci 0000:00:1f.2: PME# supported from D3hot
[ 0.133457] pci 0000:00:1f.3: [8086:27da] type 00 class 0x0c0500
[ 0.133516] pci 0000:00:1f.3: reg 0x20: [io 0x0400-0x041f]
[ 0.133851] pci 0000:00:1c.0: PCI bridge to [bus 03]
[ 0.133985] pci 0000:00:1c.1: PCI bridge to [bus 02]
[ 0.134131] pci 0000:00:1c.3: PCI bridge to [bus 01]
[ 0.134294] pci 0000:00:1e.0: PCI bridge to [bus 04] (subtractive decode)
[ 0.134312] pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7 window] (subtractive decode)
[ 0.134318] pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff window] (subtractive decode)
[ 0.134324] pci 0000:00:1e.0: bridge window [mem 0x00000000-0xffffffff window] (subtractive decode)
[ 0.134330] pci 0000:00:1e.0: bridge window [mem 0x000d0000-0x000dffff window] (subtractive decode)
[ 0.134337] pci 0000:00:1e.0: bridge window [mem 0x7f700000-0xdfffffff window] (subtractive decode)
[ 0.134343] pci 0000:00:1e.0: bridge window [mem 0xf0000000-0xfed8ffff window] (subtractive decode)
[ 0.134376] pci_bus 0000:00: on NUMA node 0
[ 0.136171] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 10 11 12 14 15)
[ 0.136323] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 *14 15)
[ 0.136466] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
[ 0.136609] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
[ 0.136751] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 0.136894] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 0.137050] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
[ 0.137195] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 *6 7 10 11 12 14 15)
[ 0.137388] ACPI: Enabled 3 GPEs in block 00 to 1F
[ 0.138042] vgaarb: setting as boot device: PCI:0000:00:02.0
[ 0.138042] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.138043] vgaarb: loaded
[ 0.138047] vgaarb: bridge control possible 0000:00:02.0
[ 0.138293] SCSI subsystem initialized
[ 0.138343] libata version 3.00 loaded.
[ 0.138343] ACPI: bus type USB registered
[ 0.138343] usbcore: registered new interface driver usbfs
[ 0.138343] usbcore: registered new interface driver hub
[ 0.139013] usbcore: registered new device driver usb
[ 0.139013] pps_core: LinuxPPS API ver. 1 registered
[ 0.139013] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.139013] PTP clock support registered
[ 0.139098] PCI: Using ACPI for IRQ routing
[ 0.139098] PCI: pci_cache_line_size set to 64 bytes
[ 0.139098] pci 0000:00:02.0: can't claim BAR 0 [mem 0xfeb00000-0xfeb7ffff]: address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139098] pci 0000:00:02.0: can't claim BAR 2 [mem 0xd0000000-0xdfffffff pref]: address conflict with PCI Bus 0000:00 [mem 0x7f700000-0xdfffffff window]
[ 0.139104] pci 0000:00:02.0: can't claim BAR 3 [mem 0xfea00000-0xfeafffff]: address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139113] pci 0000:00:02.1: can't claim BAR 0 [mem 0xfeb80000-0xfebfffff]: address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139123] pci 0000:00:1b.0: can't claim BAR 0 [mem 0xfe9f8000-0xfe9fbfff 64bit]: address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139146] pci 0000:00:1d.7: can't claim BAR 0 [mem 0xfe9f7c00-0xfe9f7fff]: address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139161] pci 0000:00:1f.2: can't claim BAR 5 [mem 0xfe9f7800-0xfe9f7bff]: address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
[ 0.139190] Expanded resource reserved due to conflict with PCI Bus 0000:00
[ 0.139195] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[ 0.139200] e820: reserve RAM buffer [mem 0x7f590000-0x7fffffff]
[ 0.139375] NetLabel: Initializing
[ 0.139379] NetLabel: domain hash size = 128
[ 0.139382] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.139416] NetLabel: unlabeled traffic allowed by default
[ 0.139527] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[ 0.139536] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 0.139546] hpet0: 3 comparators, 64-bit 14.318180 MHz counter
[ 0.142065] Switched to clocksource hpet
[ 0.161609] pnp: PnP ACPI init
[ 0.161790] system 00:00: [mem 0xfed14000-0xfed19fff] has been reserved
[ 0.161799] system 00:00: [mem 0xfed90000-0xfed93fff] has been reserved
[ 0.161808] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 0.161971] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.162148] pnp 00:02: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[ 0.162615] ACPI: IRQ 4 override to edge, high
[ 0.162631] pnp 00:03: [dma 0 disabled]
[ 0.162800] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.163219] ACPI: IRQ 3 override to edge, high
[ 0.163234] pnp 00:04: [dma 0 disabled]
[ 0.163491] pnp 00:04: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.163886] ACPI: IRQ 11 override to edge, high
[ 0.163901] pnp 00:05: [dma 0 disabled]
[ 0.164082] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.164478] ACPI: IRQ 10 override to edge, high
[ 0.164492] pnp 00:06: [dma 0 disabled]
[ 0.164660] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.165086] ACPI: IRQ 5 override to edge, high
[ 0.165101] pnp 00:07: [dma 0 disabled]
[ 0.165263] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.165558] system 00:08: [io 0x0a00-0x0a0f] has been reserved
[ 0.165566] system 00:08: [io 0x0a10-0x0af7] has been reserved
[ 0.165574] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.165860] system 00:09: [io 0x04d0-0x04d1] has been reserved
[ 0.165869] system 00:09: [io 0x0800-0x087f] could not be reserved
[ 0.165875] system 00:09: [io 0x0480-0x04bf] has been reserved
[ 0.165883] system 00:09: [mem 0xfed1c000-0xfed1ffff] has been reserved
[ 0.165889] system 00:09: [mem 0xfed20000-0xfed8ffff] has been reserved
[ 0.165897] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.166262] system 00:0a: [mem 0xfec00000-0xfec00fff] could not be reserved
[ 0.166270] system 00:0a: [mem 0xfee00000-0xfee00fff] has been reserved
[ 0.166278] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.166439] system 00:0b: [mem 0xe0000000-0xefffffff] has been reserved
[ 0.166448] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.166806] pnp 00:0c: disabling [mem 0x00000000-0x0009ffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff pref]
[ 0.166814] pnp 00:0c: disabling [mem 0x000c0000-0x000cffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff pref]
[ 0.166822] pnp 00:0c: disabling [mem 0x000e0000-0x000fffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff pref]
[ 0.166829] pnp 00:0c: disabling [mem 0x00100000-0x7f6fffff] because it overlaps 0000:00:02.0 BAR 2 [mem 0x00000000-0x0fffffff pref]
[ 0.166837] pnp 00:0c: disabling [mem 0x00000000-0x0009ffff disabled] because it overlaps 0000:00:02.0 BAR 3 [mem 0x00000000-0x000fffff]
[ 0.166844] pnp 00:0c: disabling [mem 0x000c0000-0x000cffff disabled] because it overlaps 0000:00:02.0 BAR 3 [mem 0x00000000-0x000fffff]
[ 0.166851] pnp 00:0c: disabling [mem 0x000e0000-0x000fffff disabled] because it overlaps 0000:00:02.0 BAR 3 [mem 0x00000000-0x000fffff]
[ 0.166921] system 00:0c: [mem 0xfed90000-0xffffffff] could not be reserved
[ 0.166930] system 00:0c: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 0.167260] pnp: PnP ACPI: found 13 devices
[ 0.208498] pci 0000:00:1c.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000
[ 0.208509] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000
[ 0.208517] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff] to [bus 03] add_size 200000
[ 0.208532] pci 0000:00:1c.1: bridge window [io 0x1000-0x0fff] to [bus 02] add_size 1000
[ 0.208539] pci 0000:00:1c.1: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02] add_size 200000
[ 0.208546] pci 0000:00:1c.1: bridge window [mem 0x00100000-0x000fffff] to [bus 02] add_size 200000
[ 0.208560] pci 0000:00:1c.3: bridge window [io 0x1000-0x0fff] to [bus 01] add_size 1000
[ 0.208567] pci 0000:00:1c.3: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000
[ 0.208574] pci 0000:00:1c.3: bridge window [mem 0x00100000-0x000fffff] to [bus 01] add_size 200000
[ 0.208605] pci 0000:00:1c.0: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[ 0.208612] pci 0000:00:1c.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 0.208618] pci 0000:00:1c.1: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[ 0.208625] pci 0000:00:1c.1: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 0.208631] pci 0000:00:1c.3: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[ 0.208638] pci 0000:00:1c.3: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 0.208644] pci 0000:00:1c.0: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
[ 0.208650] pci 0000:00:1c.1: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
[ 0.208656] pci 0000:00:1c.3: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
[ 0.208670] pci 0000:00:02.0: BAR 2: assigned [mem 0x80000000-0x8fffffff pref]
[ 0.208680] pci 0000:00:02.0: BAR 3: assigned [mem 0xfef00000-0xfeffffff]
[ 0.208689] pci 0000:00:1c.0: BAR 14: assigned [mem 0xff000000-0xff1fffff]
[ 0.208697] pci 0000:00:1c.0: BAR 15: assigned [mem 0xff200000-0xff3fffff 64bit pref]
[ 0.208705] pci 0000:00:1c.1: BAR 14: assigned [mem 0xff400000-0xff5fffff]
[ 0.208713] pci 0000:00:1c.1: BAR 15: assigned [mem 0xff600000-0xff7fffff 64bit pref]
[ 0.208721] pci 0000:00:1c.3: BAR 14: assigned [mem 0xff800000-0xff9fffff]
[ 0.208729] pci 0000:00:1c.3: BAR 15: assigned [mem 0xffa00000-0xffbfffff 64bit pref]
[ 0.208736] pci 0000:00:02.0: BAR 0: assigned [mem 0xfee80000-0xfeefffff]
[ 0.208745] pci 0000:00:02.1: BAR 0: assigned [mem 0xffc00000-0xffc7ffff]
[ 0.208754] pci 0000:00:1b.0: BAR 0: assigned [mem 0xfed94000-0xfed97fff 64bit]
[ 0.208771] pci 0000:00:1c.0: BAR 13: assigned [io 0x1000-0x1fff]
[ 0.208779] pci 0000:00:1c.1: BAR 13: assigned [io 0x2000-0x2fff]
[ 0.208787] pci 0000:00:1c.3: BAR 13: assigned [io 0x3000-0x3fff]
[ 0.208794] pci 0000:00:1d.7: BAR 0: assigned [mem 0xfed98000-0xfed983ff]
[ 0.208804] pci 0000:00:1f.2: BAR 5: assigned [mem 0xfed98400-0xfed987ff]
[ 0.208817] pci 0000:00:1c.0: PCI bridge to [bus 03]
[ 0.208824] pci 0000:00:1c.0: bridge window [io 0x1000-0x1fff]
[ 0.208833] pci 0000:00:1c.0: bridge window [mem 0xff000000-0xff1fffff]
[ 0.208842] pci 0000:00:1c.0: bridge window [mem 0xff200000-0xff3fffff 64bit pref]
[ 0.208852] pci 0000:00:1c.1: PCI bridge to [bus 02]
[ 0.208859] pci 0000:00:1c.1: bridge window [io 0x2000-0x2fff]
[ 0.208868] pci 0000:00:1c.1: bridge window [mem 0xff400000-0xff5fffff]
[ 0.208876] pci 0000:00:1c.1: bridge window [mem 0xff600000-0xff7fffff 64bit pref]
[ 0.208887] pci 0000:00:1c.3: PCI bridge to [bus 01]
[ 0.208893] pci 0000:00:1c.3: bridge window [io 0x3000-0x3fff]
[ 0.208902] pci 0000:00:1c.3: bridge window [mem 0xff800000-0xff9fffff]
[ 0.208910] pci 0000:00:1c.3: bridge window [mem 0xffa00000-0xffbfffff 64bit pref]
[ 0.208921] pci 0000:00:1e.0: PCI bridge to [bus 04]
[ 0.208939] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window]
[ 0.208945] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window]
[ 0.208951] pci_bus 0000:00: resource 6 [mem 0x00000000-0xffffffff window]
[ 0.208957] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff window]
[ 0.208963] pci_bus 0000:00: resource 8 [mem 0x7f700000-0xdfffffff window]
[ 0.208969] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfed8ffff window]
[ 0.208975] pci_bus 0000:03: resource 0 [io 0x1000-0x1fff]
[ 0.208980] pci_bus 0000:03: resource 1 [mem 0xff000000-0xff1fffff]
[ 0.208986] pci_bus 0000:03: resource 2 [mem 0xff200000-0xff3fffff 64bit pref]
[ 0.208992] pci_bus 0000:02: resource 0 [io 0x2000-0x2fff]
[ 0.208998] pci_bus 0000:02: resource 1 [mem 0xff400000-0xff5fffff]
[ 0.209021] pci_bus 0000:02: resource 2 [mem 0xff600000-0xff7fffff 64bit pref]
[ 0.209027] pci_bus 0000:01: resource 0 [io 0x3000-0x3fff]
[ 0.209032] pci_bus 0000:01: resource 1 [mem 0xff800000-0xff9fffff]
[ 0.209038] pci_bus 0000:01: resource 2 [mem 0xffa00000-0xffbfffff 64bit pref]
[ 0.209045] pci_bus 0000:04: resource 4 [io 0x0000-0x0cf7 window]
[ 0.209050] pci_bus 0000:04: resource 5 [io 0x0d00-0xffff window]
[ 0.209056] pci_bus 0000:04: resource 6 [mem 0x00000000-0xffffffff window]
[ 0.209062] pci_bus 0000:04: resource 7 [mem 0x000d0000-0x000dffff window]
[ 0.209068] pci_bus 0000:04: resource 8 [mem 0x7f700000-0xdfffffff window]
[ 0.209074] pci_bus 0000:04: resource 9 [mem 0xf0000000-0xfed8ffff window]
[ 0.209153] NET: Registered protocol family 2
[ 0.209582] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.209623] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.209676] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.209719] TCP: reno registered
[ 0.209726] UDP hash table entries: 512 (order: 2, 16384 bytes)
[ 0.209742] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[ 0.209867] NET: Registered protocol family 1
[ 0.209910] pci 0000:00:02.0: Video device with shadowed ROM
[ 0.210984] PCI: CLS 32 bytes, default 64
[ 0.211188] Unpacking initramfs...
[ 0.293212] Freeing initrd memory: 1948K (f7617000 - f77fe000)
[ 0.294662] apm: BIOS not found.
[ 0.295048] NatSemi SCx200 Driver
[ 0.295730] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.295766] Initialise system trusted keyring
[ 0.295810] audit: initializing netlink subsys (disabled)
[ 0.295849] audit: type=2000 audit(1434718211.294:1): initialized
[ 0.296490] HugeTLB registered 4 MB page size, pre-allocated 0 pages
[ 0.301076] zpool: loaded
[ 0.301084] zbud: loaded
[ 0.301383] VFS: Disk quotas dquot_6.5.2
[ 0.301491] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.302614] Key type big_key registered
[ 0.302622] SELinux: Registering netfilter hooks
[ 0.305114] alg: No test for stdrng (krng)
[ 0.305142] NET: Registered protocol family 38
[ 0.305160] Key type asymmetric registered
[ 0.305166] Asymmetric key parser 'x509' registered
[ 0.305218] bounce: pool size: 64 pages
[ 0.305336] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 0.305451] io scheduler noop registered
[ 0.305462] io scheduler deadline registered
[ 0.305589] io scheduler cfq registered (default)
[ 0.305889] pcieport 0000:00:1c.0: enabling device (0104 -> 0107)
[ 0.306366] pcieport 0000:00:1c.1: enabling device (0104 -> 0107)
[ 0.306753] pcieport 0000:00:1c.3: enabling device (0104 -> 0107)
[ 0.307279] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[ 0.307290] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded
[ 0.307341] pcieport 0000:00:1c.1: Signaling PME through PCIe PME interrupt
[ 0.307350] pcie_pme 0000:00:1c.1:pcie01: service driver pcie_pme loaded
[ 0.307397] pcieport 0000:00:1c.3: Signaling PME through PCIe PME interrupt
[ 0.307406] pcie_pme 0000:00:1c.3:pcie01: service driver pcie_pme loaded
[ 0.307526] intel_idle: MWAIT substates: 0x10
[ 0.307547] intel_idle: v0.4 model 0x1C
[ 0.307552] intel_idle: lapic_timer_reliable_states 0x2
[ 0.307994] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[ 0.308026] ACPI: Power Button [PWRB]
[ 0.308180] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 0.308187] ACPI: Power Button [PWRF]
[ 0.309852] thermal LNXTHERM:00: registered as thermal_zone0
[ 0.309859] ACPI: Thermal Zone [THRM] (47 C)
[ 0.309975] GHES: HEST is not enabled!
[ 0.310294] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled
[ 0.331072] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 0.351950] 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 0.372830] 00:05: ttyS2 at I/O 0x3e8 (irq = 11, base_baud = 115200) is a 16550A
[ 0.393736] 00:06: ttyS3 at I/O 0x2e8 (irq = 10, base_baud = 115200) is a 16550A
[ 0.414627] 00:07: ttyS4 at I/O 0x4e8 (irq = 5, base_baud = 115200) is a 16550A
[ 0.416299] Non-volatile memory driver v1.3
[ 0.416419] Linux agpgart interface v0.103
[ 0.416565] agpgart-intel 0000:00:00.0: Intel GMA3150 Chipset
[ 0.416593] agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, 262144K mappable
[ 0.416718] agpgart-intel 0000:00:00.0: detected 8192K stolen memory
[ 0.417042] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0x80000000
[ 0.417372] VMware PVSCSI driver - version 1.0.5.0-k
[ 0.417427] hv_vmbus: registering driver hv_storvsc
[ 0.417658] ata_piix 0000:00:1f.2: version 2.13
[ 0.417797] ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
[ 0.420641] scsi host0: ata_piix
[ 0.420983] scsi host1: ata_piix
[ 0.421192] ata1: SATA max UDMA/133 cmd 0xd800 ctl 0xe080 bmdma 0xd880 irq 19
[ 0.421199] ata2: SATA max UDMA/133 cmd 0xe000 ctl 0xdc00 bmdma 0xd888 irq 19
[ 0.421949] libphy: Fixed MDIO Bus: probed
[ 0.422223] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.422238] ehci-pci: EHCI PCI platform driver
[ 0.422442] ehci-pci 0000:00:1d.7: EHCI Host Controller
[ 0.422590] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 1
[ 0.422614] ehci-pci 0000:00:1d.7: debug port 1
[ 0.426544] ehci-pci 0000:00:1d.7: cache line size of 32 is not supported
[ 0.426584] ehci-pci 0000:00:1d.7: irq 23, io mem 0xfed98000
[ 0.432039] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[ 0.432197] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.432204] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.432209] usb usb1: Product: EHCI Host Controller
[ 0.432214] usb usb1: Manufacturer: Linux 4.0.5 ehci_hcd
[ 0.432219] usb usb1: SerialNumber: 0000:00:1d.7
[ 0.432644] hub 1-0:1.0: USB hub found
[ 0.432666] hub 1-0:1.0: 8 ports detected
[ 0.433342] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.433361] ohci-pci: OHCI PCI platform driver
[ 0.433408] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.433593] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[ 0.433762] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
[ 0.433776] uhci_hcd 0000:00:1d.0: detected 2 ports
[ 0.433809] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000e400
[ 0.433958] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.433965] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.433970] usb usb2: Product: UHCI Host Controller
[ 0.433975] usb usb2: Manufacturer: Linux 4.0.5 uhci_hcd
[ 0.433980] usb usb2: SerialNumber: 0000:00:1d.0
[ 0.434387] hub 2-0:1.0: USB hub found
[ 0.434408] hub 2-0:1.0: 2 ports detected
[ 0.434856] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[ 0.435035] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
[ 0.435051] uhci_hcd 0000:00:1d.1: detected 2 ports
[ 0.435084] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000e480
[ 0.435239] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.435245] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.435251] usb usb3: Product: UHCI Host Controller
[ 0.435256] usb usb3: Manufacturer: Linux 4.0.5 uhci_hcd
[ 0.435261] usb usb3: SerialNumber: 0000:00:1d.1
[ 0.435642] hub 3-0:1.0: USB hub found
[ 0.435664] hub 3-0:1.0: 2 ports detected
[ 0.436150] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[ 0.436314] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
[ 0.436328] uhci_hcd 0000:00:1d.2: detected 2 ports
[ 0.436383] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000e800
[ 0.436531] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.436537] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.436543] usb usb4: Product: UHCI Host Controller
[ 0.436548] usb usb4: Manufacturer: Linux 4.0.5 uhci_hcd
[ 0.436553] usb usb4: SerialNumber: 0000:00:1d.2
[ 0.436918] hub 4-0:1.0: USB hub found
[ 0.436940] hub 4-0:1.0: 2 ports detected
[ 0.437407] uhci_hcd 0000:00:1d.3: UHCI Host Controller
[ 0.437560] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
[ 0.437578] uhci_hcd 0000:00:1d.3: detected 2 ports
[ 0.437629] uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000e880
[ 0.437787] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.437794] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.437799] usb usb5: Product: UHCI Host Controller
[ 0.437804] usb usb5: Manufacturer: Linux 4.0.5 uhci_hcd
[ 0.437809] usb usb5: SerialNumber: 0000:00:1d.3
[ 0.438211] hub 5-0:1.0: USB hub found
[ 0.438233] hub 5-0:1.0: 2 ports detected
[ 0.438672] usbcore: registered new interface driver usbserial
[ 0.438703] usbcore: registered new interface driver usbserial_generic
[ 0.438731] usbserial: USB Serial support registered for generic
[ 0.438867] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[ 0.438871] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[ 0.439666] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.439942] mousedev: PS/2 mouse device common for all mice
[ 0.440534] rtc_cmos 00:01: RTC can wake from S4
[ 0.440830] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0
[ 0.440875] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 0.441125] device-mapper: uevent: version 1.0.3
[ 0.441389] device-mapper: ioctl: 4.30.0-ioctl (2014-12-22) initialised: dm-devel@redhat.com
[ 0.442723] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.443146] usbcore: registered new interface driver usbhid
[ 0.443150] usbhid: USB HID core driver
[ 0.443254] drop_monitor: Initializing network drop monitor service
[ 0.443450] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 0.443549] TCP: cubic registered
[ 0.443565] Initializing XFRM netlink socket
[ 0.444142] NET: Registered protocol family 10
[ 0.444681] mip6: Mobile IPv6
[ 0.444691] NET: Registered protocol family 17
[ 0.445458] Using IPI No-Shortcut mode
[ 0.445970] Loading compiled-in X.509 certificates
[ 0.456441] Loaded X.509 cert 'Magrathea: Glacier signing key: c33fac7d5ea6d301713be26d544a04b7eae384b0'
[ 0.456489] registered taskstats version 1
[ 0.457250] Magic number: 3:487:835
[ 0.457396] rtc_cmos 00:01: setting system clock to 2015-06-19 12:50:12 UTC (1434718212)
[ 0.457545] PM: Hibernation image not present or could not be loaded.
[ 0.483128] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[ 0.586255] ata1.00: CFA: TRANSCEND, 20110519, max UDMA/66
[ 0.586264] ata1.00: 7962192 sectors, multi 0: LBA
[ 0.586271] ata1.00: applying bridge limits
[ 0.592247] ata1.00: configured for UDMA/66
[ 0.592505] scsi 0:0:0:0: Direct-Access ATA TRANSCEND 0519 PQ: 0 ANSI: 5
[ 0.593111] sd 0:0:0:0: [sda] 7962192 512-byte logical blocks: (4.07 GB/3.79 GiB)
[ 0.593331] sd 0:0:0:0: [sda] Write Protect is off
[ 0.593340] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 0.593350] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 0.593405] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 0.594306] sda: sda1 sda2 sda3
[ 0.595165] sd 0:0:0:0: [sda] Attached SCSI disk
[ 0.595682] Freeing unused kernel memory: 792K (c0d36000 - c0dfc000)
[ 0.595845] Write protecting the kernel text: 6224k
[ 0.595954] Write protecting the kernel read-only data: 2588k
[ 0.715735] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
[ 0.815061] random: systemd urandom read with 45 bits of entropy available
[ 0.858074] usb 2-1: new low-speed USB device number 2 using uhci_hcd
[ 1.002556] systemd[1]: [/lib/systemd/system/mariadb-prepare.service:10] Unknown lvalue 'RequiredBy' in section 'Unit'
[ 1.004103] usb 2-1: New USB device found, idVendor=04f3, idProduct=0103
[ 1.004112] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.021921] input: HID 04f3:0103 as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/0003:04F3:0103.0001/input/input3
[ 1.072634] hid-generic 0003:04F3:0103.0001: input,hidraw0: USB HID v1.10 Keyboard [HID 04f3:0103] on usb-0000:00:1d.0-1/input0
[ 1.097398] input: HID 04f3:0103 as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1/0003:04F3:0103.0002/input/input4
[ 1.149464] hid-generic 0003:04F3:0103.0002: input,hidraw1: USB HID v1.10 Device [HID 04f3:0103] on usb-0000:00:1d.0-1/input1
[ 1.164921] ip6_tables: module verification failed: signature and/or required key missing - tainting kernel
[ 1.165640] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 1.223544] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 1.295064] tsc: Refined TSC clocksource calibration: 1799.971 MHz
[ 1.392586] EXT4-fs (sda3): re-mounted. Opts: (null)
[ 1.424733] systemd-journald[132]: Received request to flush runtime journal from PID 1
[ 1.439469] random: nonblocking pool is initialized
[ 2.133444] input: PC Speaker as /devices/platform/pcspkr/input/input5
[ 2.154213] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
[ 2.166676] iTCO_vendor_support: vendor-support=0
[ 2.168286] gpio_ich: GPIO from 462 to 511 on gpio_ich
[ 2.187654] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 2.187731] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
[ 2.202571] Error: Driver 'pcspkr' is already registered, aborting...
[ 2.217389] microcode: CPU0 sig=0x106ca, pf=0x8, revision=0x107
[ 2.221106] microcode: CPU1 sig=0x106ca, pf=0x8, revision=0x107
[ 2.221151] microcode: CPU2 sig=0x106ca, pf=0x8, revision=0x107
[ 2.221189] microcode: CPU3 sig=0x106ca, pf=0x8, revision=0x107
[ 2.221390] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 2.223837] [drm] Initialized drm 1.1.0 20060810
[ 2.272765] [drm] Memory usable by graphics device = 512M
[ 2.272773] [drm] Replacing VGA console driver
[ 2.273813] Console: switching to colour dummy device 80x25
[ 2.282161] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.282171] [drm] Driver supports precise vblank timestamp query.
[ 2.282367] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 2.286306] [drm] initialized overlay support
[ 2.286504] i915: No ACPI video bus found
[ 2.286591] [drm] Initialized i915 1.6.0 20150130 for 0000:00:02.0 on minor 0
[ 2.295360] Switched to clocksource tsc
[ 2.299952] fbcon: inteldrmfb (fb0) is primary device
[ 2.388603] Adding 262140k swap on /dev/sda2. Priority:-1 extents:1 across:262140k FS
[ 2.467665] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 3.991108] Console: switching to colour frame buffer device 128x48
[ 4.010359] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 4.010362] i915 0000:00:02.0: registered panic notifier
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ethernet chip disappeared from lspci
2015-06-19 13:24 Ethernet chip disappeared from lspci Boszormenyi Zoltan
@ 2015-06-19 13:31 ` Boszormenyi Zoltan
2015-06-19 13:46 ` ACPI regression? Was " Boszormenyi Zoltan
0 siblings, 1 reply; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-19 13:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Nevermind, this is a POS machine with a big battery inside.
When I allowed it to discharge, the network card came back
with PXE boot. There might have been some bad state kept
by the battery.
Sorry for the noise.
2015-06-19 15:24 keltezéssel, Boszormenyi Zoltan írta:
> Hi,
>
> I have a problem on a special POS mainboard that has
> a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5.
>
> The initial problem was that when r8169 was not blacklisted,
> as soon as this driver loaded, a lot of IRQ problems popped up,
> like pressing keys on the USB keyboard made the keys duplicated
> and the system was sluggish. Upon powering off the system,
> the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
> or something like that and the system couldn't even reboot or
> get powered down properly.
>
> It was impossible to get dmesg or other diagnostics info out of
> the system in this state.
>
> When I blacklisted r8169, everything was OK except there was
> no network, obviously.
>
> I also noticed that with kernel 4.0.5, there are memory range conflicts, like
>
> pci 0000:00:02.0: can't claim BAR 0 [mem ....]: address conflict with PCI Bus 0000:00 [mem
> ... window]
>
> I also tried to load the r8168 driver from Realtek, with the
> same results as with r8169.
>
> I don't know what happened, was it the "official" Realtek driver
> that disabled the chip, or that I toggled the PXE boot in the BIOS,
> but now lspci doesn't list the ethernet chip anymore and not even
> the PXE boot messages show up, despite it being enabled in the BIOS.
> I tried kernels 3.18.16, 4.0.5 again and 4.1.0-rc8.
>
> I have this in dmesg:
>
> [ 0.136171] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 10 11 12 14 15)
> [ 0.136323] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 *14 15)
> [ 0.136466] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
> [ 0.136609] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
> [ 0.136751] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> [ 0.136894] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> [ 0.137050] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> [ 0.137195] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 *6 7 10 11 12 14 15)
>
> and
>
> [ 0.139098] PCI: Using ACPI for IRQ routing
> [ 0.139098] PCI: pci_cache_line_size set to 64 bytes
> [ 0.139098] pci 0000:00:02.0: can't claim BAR 0 [mem 0xfeb00000-0xfeb7ffff]: address
> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> [ 0.139098] pci 0000:00:02.0: can't claim BAR 2 [mem 0xd0000000-0xdfffffff pref]:
> address conflict with PCI Bus 0000:00 [mem 0x7f700000-0xdfffffff window]
> [ 0.139104] pci 0000:00:02.0: can't claim BAR 3 [mem 0xfea00000-0xfeafffff]: address
> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> [ 0.139113] pci 0000:00:02.1: can't claim BAR 0 [mem 0xfeb80000-0xfebfffff]: address
> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> [ 0.139123] pci 0000:00:1b.0: can't claim BAR 0 [mem 0xfe9f8000-0xfe9fbfff 64bit]:
> address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> [ 0.139146] pci 0000:00:1d.7: can't claim BAR 0 [mem 0xfe9f7c00-0xfe9f7fff]: address
> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> [ 0.139161] pci 0000:00:1f.2: can't claim BAR 5 [mem 0xfe9f7800-0xfe9f7bff]: address
> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> [ 0.139190] Expanded resource reserved due to conflict with PCI Bus 0000:00
>
> Full dmesg for 4.0.5 is attached.
>
> Can anyone help me re-enable the network card?
>
> Thanks in advance,
> Zoltán Böszörményi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 26+ messages in thread
* ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-19 13:31 ` Boszormenyi Zoltan
@ 2015-06-19 13:46 ` Boszormenyi Zoltan
2015-06-19 23:13 ` Rafael J. Wysocki
0 siblings, 1 reply; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-19 13:46 UTC (permalink / raw)
To: Linux Kernel Mailing List
Hi,
so after the network card came alive again, I tried kernels
3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when
loading the r8169 driver, I experience the symptoms described
below. Also, after booting 4.0.5 and then 4.1.0-rc8, the network
card disappeared from the PCI devices again, neither PXE shows up
nor the device in lspci.
It seems I will have to wait again until the battery loses its
capacity since the last testing to get the network chip back.
I would be happy to test patches that may fix this behavior.
With 3.18.16 and the device in lspci, the network works with r8169.
Best regards,
Zoltán Böszörményi
2015-06-19 15:31 keltezéssel, Boszormenyi Zoltan írta:
> Nevermind, this is a POS machine with a big battery inside.
> When I allowed it to discharge, the network card came back
> with PXE boot. There might have been some bad state kept
> by the battery.
>
> Sorry for the noise.
>
> 2015-06-19 15:24 keltezéssel, Boszormenyi Zoltan írta:
>> Hi,
>>
>> I have a problem on a special POS mainboard that has
>> a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5.
>>
>> The initial problem was that when r8169 was not blacklisted,
>> as soon as this driver loaded, a lot of IRQ problems popped up,
>> like pressing keys on the USB keyboard made the keys duplicated
>> and the system was sluggish. Upon powering off the system,
>> the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
>> or something like that and the system couldn't even reboot or
>> get powered down properly.
>>
>> It was impossible to get dmesg or other diagnostics info out of
>> the system in this state.
>>
>> When I blacklisted r8169, everything was OK except there was
>> no network, obviously.
>>
>> I also noticed that with kernel 4.0.5, there are memory range conflicts, like
>>
>> pci 0000:00:02.0: can't claim BAR 0 [mem ....]: address conflict with PCI Bus 0000:00 [mem
>> ... window]
>>
>> I also tried to load the r8168 driver from Realtek, with the
>> same results as with r8169.
>>
>> I don't know what happened, was it the "official" Realtek driver
>> that disabled the chip, or that I toggled the PXE boot in the BIOS,
>> but now lspci doesn't list the ethernet chip anymore and not even
>> the PXE boot messages show up, despite it being enabled in the BIOS.
>> I tried kernels 3.18.16, 4.0.5 again and 4.1.0-rc8.
>>
>> I have this in dmesg:
>>
>> [ 0.136171] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 10 11 12 14 15)
>> [ 0.136323] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 *14 15)
>> [ 0.136466] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
>> [ 0.136609] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
>> [ 0.136751] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
>> [ 0.136894] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
>> [ 0.137050] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
>> [ 0.137195] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 *6 7 10 11 12 14 15)
>>
>> and
>>
>> [ 0.139098] PCI: Using ACPI for IRQ routing
>> [ 0.139098] PCI: pci_cache_line_size set to 64 bytes
>> [ 0.139098] pci 0000:00:02.0: can't claim BAR 0 [mem 0xfeb00000-0xfeb7ffff]: address
>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>> [ 0.139098] pci 0000:00:02.0: can't claim BAR 2 [mem 0xd0000000-0xdfffffff pref]:
>> address conflict with PCI Bus 0000:00 [mem 0x7f700000-0xdfffffff window]
>> [ 0.139104] pci 0000:00:02.0: can't claim BAR 3 [mem 0xfea00000-0xfeafffff]: address
>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>> [ 0.139113] pci 0000:00:02.1: can't claim BAR 0 [mem 0xfeb80000-0xfebfffff]: address
>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>> [ 0.139123] pci 0000:00:1b.0: can't claim BAR 0 [mem 0xfe9f8000-0xfe9fbfff 64bit]:
>> address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>> [ 0.139146] pci 0000:00:1d.7: can't claim BAR 0 [mem 0xfe9f7c00-0xfe9f7fff]: address
>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>> [ 0.139161] pci 0000:00:1f.2: can't claim BAR 5 [mem 0xfe9f7800-0xfe9f7bff]: address
>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>> [ 0.139190] Expanded resource reserved due to conflict with PCI Bus 0000:00
>>
>> Full dmesg for 4.0.5 is attached.
>>
>> Can anyone help me re-enable the network card?
>>
>> Thanks in advance,
>> Zoltán Böszörményi
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-19 13:46 ` ACPI regression? Was " Boszormenyi Zoltan
@ 2015-06-19 23:13 ` Rafael J. Wysocki
0 siblings, 0 replies; 26+ messages in thread
From: Rafael J. Wysocki @ 2015-06-19 23:13 UTC (permalink / raw)
To: Boszormenyi Zoltan; +Cc: Linux Kernel Mailing List, ACPI Devel Maling List
On Friday, June 19, 2015 03:46:48 PM Boszormenyi Zoltan wrote:
> Hi,
>
> so after the network card came alive again, I tried kernels
> 3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when
> loading the r8169 driver, I experience the symptoms described
> below. Also, after booting 4.0.5 and then 4.1.0-rc8, the network
> card disappeared from the PCI devices again, neither PXE shows up
> nor the device in lspci.
>
> It seems I will have to wait again until the battery loses its
> capacity since the last testing to get the network chip back.
>
> I would be happy to test patches that may fix this behavior.
>
> With 3.18.16 and the device in lspci, the network works with r8169.
The only think I can suggest is to try this patch:
https://patchwork.kernel.org/patch/6628061/
and see if it makes any difference.
> 2015-06-19 15:31 keltezéssel, Boszormenyi Zoltan írta:
> > Nevermind, this is a POS machine with a big battery inside.
> > When I allowed it to discharge, the network card came back
> > with PXE boot. There might have been some bad state kept
> > by the battery.
> >
> > Sorry for the noise.
> >
> > 2015-06-19 15:24 keltezéssel, Boszormenyi Zoltan írta:
> >> Hi,
> >>
> >> I have a problem on a special POS mainboard that has
> >> a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5.
> >>
> >> The initial problem was that when r8169 was not blacklisted,
> >> as soon as this driver loaded, a lot of IRQ problems popped up,
> >> like pressing keys on the USB keyboard made the keys duplicated
> >> and the system was sluggish. Upon powering off the system,
> >> the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
> >> or something like that and the system couldn't even reboot or
> >> get powered down properly.
> >>
> >> It was impossible to get dmesg or other diagnostics info out of
> >> the system in this state.
> >>
> >> When I blacklisted r8169, everything was OK except there was
> >> no network, obviously.
> >>
> >> I also noticed that with kernel 4.0.5, there are memory range conflicts, like
> >>
> >> pci 0000:00:02.0: can't claim BAR 0 [mem ....]: address conflict with PCI Bus 0000:00 [mem
> >> ... window]
> >>
> >> I also tried to load the r8168 driver from Realtek, with the
> >> same results as with r8169.
> >>
> >> I don't know what happened, was it the "official" Realtek driver
> >> that disabled the chip, or that I toggled the PXE boot in the BIOS,
> >> but now lspci doesn't list the ethernet chip anymore and not even
> >> the PXE boot messages show up, despite it being enabled in the BIOS.
> >> I tried kernels 3.18.16, 4.0.5 again and 4.1.0-rc8.
> >>
> >> I have this in dmesg:
> >>
> >> [ 0.136171] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 10 11 12 14 15)
> >> [ 0.136323] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 *14 15)
> >> [ 0.136466] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
> >> [ 0.136609] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
> >> [ 0.136751] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> [ 0.136894] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> [ 0.137050] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> [ 0.137195] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 *6 7 10 11 12 14 15)
> >>
> >> and
> >>
> >> [ 0.139098] PCI: Using ACPI for IRQ routing
> >> [ 0.139098] PCI: pci_cache_line_size set to 64 bytes
> >> [ 0.139098] pci 0000:00:02.0: can't claim BAR 0 [mem 0xfeb00000-0xfeb7ffff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139098] pci 0000:00:02.0: can't claim BAR 2 [mem 0xd0000000-0xdfffffff pref]:
> >> address conflict with PCI Bus 0000:00 [mem 0x7f700000-0xdfffffff window]
> >> [ 0.139104] pci 0000:00:02.0: can't claim BAR 3 [mem 0xfea00000-0xfeafffff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139113] pci 0000:00:02.1: can't claim BAR 0 [mem 0xfeb80000-0xfebfffff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139123] pci 0000:00:1b.0: can't claim BAR 0 [mem 0xfe9f8000-0xfe9fbfff 64bit]:
> >> address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139146] pci 0000:00:1d.7: can't claim BAR 0 [mem 0xfe9f7c00-0xfe9f7fff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139161] pci 0000:00:1f.2: can't claim BAR 5 [mem 0xfe9f7800-0xfe9f7bff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139190] Expanded resource reserved due to conflict with PCI Bus 0000:00
> >>
> >> Full dmesg for 4.0.5 is attached.
> >>
> >> Can anyone help me re-enable the network card?
> >>
> >> Thanks in advance,
> >> Zoltán Böszörményi
> >>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-19 23:13 ` Rafael J. Wysocki
0 siblings, 0 replies; 26+ messages in thread
From: Rafael J. Wysocki @ 2015-06-19 23:13 UTC (permalink / raw)
To: Boszormenyi Zoltan; +Cc: Linux Kernel Mailing List, ACPI Devel Maling List
On Friday, June 19, 2015 03:46:48 PM Boszormenyi Zoltan wrote:
> Hi,
>
> so after the network card came alive again, I tried kernels
> 3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when
> loading the r8169 driver, I experience the symptoms described
> below. Also, after booting 4.0.5 and then 4.1.0-rc8, the network
> card disappeared from the PCI devices again, neither PXE shows up
> nor the device in lspci.
>
> It seems I will have to wait again until the battery loses its
> capacity since the last testing to get the network chip back.
>
> I would be happy to test patches that may fix this behavior.
>
> With 3.18.16 and the device in lspci, the network works with r8169.
The only think I can suggest is to try this patch:
https://patchwork.kernel.org/patch/6628061/
and see if it makes any difference.
> 2015-06-19 15:31 keltezéssel, Boszormenyi Zoltan írta:
> > Nevermind, this is a POS machine with a big battery inside.
> > When I allowed it to discharge, the network card came back
> > with PXE boot. There might have been some bad state kept
> > by the battery.
> >
> > Sorry for the noise.
> >
> > 2015-06-19 15:24 keltezéssel, Boszormenyi Zoltan írta:
> >> Hi,
> >>
> >> I have a problem on a special POS mainboard that has
> >> a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5.
> >>
> >> The initial problem was that when r8169 was not blacklisted,
> >> as soon as this driver loaded, a lot of IRQ problems popped up,
> >> like pressing keys on the USB keyboard made the keys duplicated
> >> and the system was sluggish. Upon powering off the system,
> >> the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
> >> or something like that and the system couldn't even reboot or
> >> get powered down properly.
> >>
> >> It was impossible to get dmesg or other diagnostics info out of
> >> the system in this state.
> >>
> >> When I blacklisted r8169, everything was OK except there was
> >> no network, obviously.
> >>
> >> I also noticed that with kernel 4.0.5, there are memory range conflicts, like
> >>
> >> pci 0000:00:02.0: can't claim BAR 0 [mem ....]: address conflict with PCI Bus 0000:00 [mem
> >> ... window]
> >>
> >> I also tried to load the r8168 driver from Realtek, with the
> >> same results as with r8169.
> >>
> >> I don't know what happened, was it the "official" Realtek driver
> >> that disabled the chip, or that I toggled the PXE boot in the BIOS,
> >> but now lspci doesn't list the ethernet chip anymore and not even
> >> the PXE boot messages show up, despite it being enabled in the BIOS.
> >> I tried kernels 3.18.16, 4.0.5 again and 4.1.0-rc8.
> >>
> >> I have this in dmesg:
> >>
> >> [ 0.136171] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 10 11 12 14 15)
> >> [ 0.136323] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 *14 15)
> >> [ 0.136466] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
> >> [ 0.136609] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
> >> [ 0.136751] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> [ 0.136894] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> [ 0.137050] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
> >> [ 0.137195] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 *6 7 10 11 12 14 15)
> >>
> >> and
> >>
> >> [ 0.139098] PCI: Using ACPI for IRQ routing
> >> [ 0.139098] PCI: pci_cache_line_size set to 64 bytes
> >> [ 0.139098] pci 0000:00:02.0: can't claim BAR 0 [mem 0xfeb00000-0xfeb7ffff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139098] pci 0000:00:02.0: can't claim BAR 2 [mem 0xd0000000-0xdfffffff pref]:
> >> address conflict with PCI Bus 0000:00 [mem 0x7f700000-0xdfffffff window]
> >> [ 0.139104] pci 0000:00:02.0: can't claim BAR 3 [mem 0xfea00000-0xfeafffff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139113] pci 0000:00:02.1: can't claim BAR 0 [mem 0xfeb80000-0xfebfffff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139123] pci 0000:00:1b.0: can't claim BAR 0 [mem 0xfe9f8000-0xfe9fbfff 64bit]:
> >> address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139146] pci 0000:00:1d.7: can't claim BAR 0 [mem 0xfe9f7c00-0xfe9f7fff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139161] pci 0000:00:1f.2: can't claim BAR 5 [mem 0xfe9f7800-0xfe9f7bff]: address
> >> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
> >> [ 0.139190] Expanded resource reserved due to conflict with PCI Bus 0000:00
> >>
> >> Full dmesg for 4.0.5 is attached.
> >>
> >> Can anyone help me re-enable the network card?
> >>
> >> Thanks in advance,
> >> Zoltán Böszörményi
> >>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> Please read the FAQ at http://www.tux.org/lkml/
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-19 23:13 ` Rafael J. Wysocki
(?)
@ 2015-06-20 6:38 ` Boszormenyi Zoltan
-1 siblings, 0 replies; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-20 6:38 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, ACPI Devel Maling List
[-- Attachment #1: Type: text/plain, Size: 5435 bytes --]
2015-06-20 01:13 keltezéssel, Rafael J. Wysocki írta:
> On Friday, June 19, 2015 03:46:48 PM Boszormenyi Zoltan wrote:
>> Hi,
>>
>> so after the network card came alive again, I tried kernels
>> 3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when
>> loading the r8169 driver, I experience the symptoms described
>> below. Also, after booting 4.0.5 and then 4.1.0-rc8, the network
>> card disappeared from the PCI devices again, neither PXE shows up
>> nor the device in lspci.
>>
>> It seems I will have to wait again until the battery loses its
>> capacity since the last testing to get the network chip back.
>>
>> I would be happy to test patches that may fix this behavior.
>>
>> With 3.18.16 and the device in lspci, the network works with r8169.
> The only think I can suggest is to try this patch:
>
> https://patchwork.kernel.org/patch/6628061/
>
> and see if it makes any difference.
Thanks, I tried it on 4.1.0-rc8 and it didn't make a difference.
Attached are the dmesg and the acpidump output, both compressed.
I hope you or someone else can see something that fixes this issue.
Until then, I am stuck with 3.18.16 on this machine.
Thanks in advance,
Zoltán Böszörményi
>
>
>> 2015-06-19 15:31 keltezéssel, Boszormenyi Zoltan írta:
>>> Nevermind, this is a POS machine with a big battery inside.
>>> When I allowed it to discharge, the network card came back
>>> with PXE boot. There might have been some bad state kept
>>> by the battery.
>>>
>>> Sorry for the noise.
>>>
>>> 2015-06-19 15:24 keltezéssel, Boszormenyi Zoltan írta:
>>>> Hi,
>>>>
>>>> I have a problem on a special POS mainboard that has
>>>> a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5.
>>>>
>>>> The initial problem was that when r8169 was not blacklisted,
>>>> as soon as this driver loaded, a lot of IRQ problems popped up,
>>>> like pressing keys on the USB keyboard made the keys duplicated
>>>> and the system was sluggish. Upon powering off the system,
>>>> the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
>>>> or something like that and the system couldn't even reboot or
>>>> get powered down properly.
>>>>
>>>> It was impossible to get dmesg or other diagnostics info out of
>>>> the system in this state.
>>>>
>>>> When I blacklisted r8169, everything was OK except there was
>>>> no network, obviously.
>>>>
>>>> I also noticed that with kernel 4.0.5, there are memory range conflicts, like
>>>>
>>>> pci 0000:00:02.0: can't claim BAR 0 [mem ....]: address conflict with PCI Bus 0000:00 [mem
>>>> ... window]
>>>>
>>>> I also tried to load the r8168 driver from Realtek, with the
>>>> same results as with r8169.
>>>>
>>>> I don't know what happened, was it the "official" Realtek driver
>>>> that disabled the chip, or that I toggled the PXE boot in the BIOS,
>>>> but now lspci doesn't list the ethernet chip anymore and not even
>>>> the PXE boot messages show up, despite it being enabled in the BIOS.
>>>> I tried kernels 3.18.16, 4.0.5 again and 4.1.0-rc8.
>>>>
>>>> I have this in dmesg:
>>>>
>>>> [ 0.136171] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 *7 10 11 12 14 15)
>>>> [ 0.136323] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 *14 15)
>>>> [ 0.136466] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
>>>> [ 0.136609] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
>>>> [ 0.136751] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
>>>> [ 0.136894] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
>>>> [ 0.137050] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
>>>> [ 0.137195] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 *6 7 10 11 12 14 15)
>>>>
>>>> and
>>>>
>>>> [ 0.139098] PCI: Using ACPI for IRQ routing
>>>> [ 0.139098] PCI: pci_cache_line_size set to 64 bytes
>>>> [ 0.139098] pci 0000:00:02.0: can't claim BAR 0 [mem 0xfeb00000-0xfeb7ffff]: address
>>>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>>>> [ 0.139098] pci 0000:00:02.0: can't claim BAR 2 [mem 0xd0000000-0xdfffffff pref]:
>>>> address conflict with PCI Bus 0000:00 [mem 0x7f700000-0xdfffffff window]
>>>> [ 0.139104] pci 0000:00:02.0: can't claim BAR 3 [mem 0xfea00000-0xfeafffff]: address
>>>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>>>> [ 0.139113] pci 0000:00:02.1: can't claim BAR 0 [mem 0xfeb80000-0xfebfffff]: address
>>>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>>>> [ 0.139123] pci 0000:00:1b.0: can't claim BAR 0 [mem 0xfe9f8000-0xfe9fbfff 64bit]:
>>>> address conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>>>> [ 0.139146] pci 0000:00:1d.7: can't claim BAR 0 [mem 0xfe9f7c00-0xfe9f7fff]: address
>>>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>>>> [ 0.139161] pci 0000:00:1f.2: can't claim BAR 5 [mem 0xfe9f7800-0xfe9f7bff]: address
>>>> conflict with PCI Bus 0000:00 [mem 0xf0000000-0xfed8ffff window]
>>>> [ 0.139190] Expanded resource reserved due to conflict with PCI Bus 0000:00
>>>>
>>>> Full dmesg for 4.0.5 is attached.
>>>>
>>>> Can anyone help me re-enable the network card?
>>>>
>>>> Thanks in advance,
>>>> Zoltán Böszörményi
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> Please read the FAQ at http://www.tux.org/lkml/
[-- Attachment #2: acpidump.tgz --]
[-- Type: application/x-compressed-tar, Size: 49038 bytes --]
[-- Attachment #3: dmesg-4.1.0-rc8-3.log.gz --]
[-- Type: application/x-tar, Size: 13161 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-19 23:13 ` Rafael J. Wysocki
(?)
(?)
@ 2015-06-21 10:34 ` Boszormenyi Zoltan
2015-06-21 14:03 ` Bjorn Helgaas
-1 siblings, 1 reply; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 10:34 UTC (permalink / raw)
To: Andreas Mohr
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, ACPI Devel Maling List
[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]
Hi,
please, cc me, I am not subscribed to lkml.
> Hi,
>
> [lkml.org still broken --> no accurate mail header info possible...]
>
> Just to ask the obvious:
> I assume using /sys/bus/pci/rescan does not help once it's broken?
> (since the machine comes up empty at initial-boot scan, too)
I will try it, too, but I am not sure it would work.
Currently I can't test it because the last time I completely discharged
the battery. I also disconnected it to be able to get the realtek chip back
immediately for faster testing. Now, that I have reconnected the battery,
I need to wait for it to be charged somewhat to be able to reproduce
losing the network chip.
> Also, you could try diffing lspci -vvxxx -s.... output
> of working vs. "distorting" kernel version - perhaps some register setup
> has been changed (e.g. due to power management improvements or some such),
> which may encourage the card
> to get a problematic/corrupt state.
I attached a tarball that contains lspci -vvxxx for
- all devices / only the network chip
- before / after "modprobe r8169"
- for all 3 kernel versions tested.
I figured out that if I type the modprobe and lspci in the same command line,
I can get diagnostics out of the machine, after all.
It's not just the Realtek chip that has changed parameters.
(Vague idea) I noticed that some devices have changed like this:
- Memory behind bridge: 80000000-801fffff
- Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
+ Memory behind bridge: ff000000-ff1fffff
+ Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
Can't this cause a problem? E.g. programming the bridge with an address range
that the bridge doesn't actually support?
>
> > Upon powering off the system,
> > the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
>
> Yup, that seems to be
> rtl_eri_read() in ethernet/realtek/r8169.c
> waiting on low condition of
> RTL_R32(ERIAR) & ERIAR_FLAG;
I found that, too, and I think it is a symptom of instead of the cause.
Thanks for your efforts,
Zoltán Böszörményi
[-- Attachment #2: lspci.tgz --]
[-- Type: application/x-compressed-tar, Size: 22851 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 10:34 ` Boszormenyi Zoltan
2015-06-21 14:03 ` Bjorn Helgaas
@ 2015-06-21 14:03 ` Bjorn Helgaas
0 siblings, 0 replies; 26+ messages in thread
From: Bjorn Helgaas @ 2015-06-21 14:03 UTC (permalink / raw)
To: Boszormenyi Zoltan
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
[+cc linux-pci]
Hi Boszormenyi,
On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
> Hi,
>
> please, cc me, I am not subscribed to lkml.
>
>> Hi,
>>
>> [lkml.org still broken --> no accurate mail header info possible...]
>>
>> Just to ask the obvious:
>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>> (since the machine comes up empty at initial-boot scan, too)
>
> I will try it, too, but I am not sure it would work.
>
> Currently I can't test it because the last time I completely discharged
> the battery. I also disconnected it to be able to get the realtek chip back
> immediately for faster testing. Now, that I have reconnected the battery,
> I need to wait for it to be charged somewhat to be able to reproduce
> losing the network chip.
>
>> Also, you could try diffing lspci -vvxxx -s.... output
>> of working vs. "distorting" kernel version - perhaps some register setup
>> has been changed (e.g. due to power management improvements or some such),
>> which may encourage the card
>> to get a problematic/corrupt state.
>
> I attached a tarball that contains lspci -vvxxx for
> - all devices / only the network chip
> - before / after "modprobe r8169"
> - for all 3 kernel versions tested.
>
> I figured out that if I type the modprobe and lspci in the same command line,
> I can get diagnostics out of the machine, after all.
>
> It's not just the Realtek chip that has changed parameters.
>
> (Vague idea) I noticed that some devices have changed like this:
>
> - Memory behind bridge: 80000000-801fffff
> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
> + Memory behind bridge: ff000000-ff1fffff
> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>
> Can't this cause a problem? E.g. programming the bridge with an address range
> that the bridge doesn't actually support?
This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
v3.18.16 dmesg log, so we can compare them?
These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
the code to see what might be going on:
acpi PNP0A08:00: host bridge window expanded to [mem
0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
ignored
pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
64bit pref]: address conflict with PCI Bus 0000:00 [mem
0xf0000000-0xfed8ffff window]
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-21 14:03 ` Bjorn Helgaas
0 siblings, 0 replies; 26+ messages in thread
From: Bjorn Helgaas @ 2015-06-21 14:03 UTC (permalink / raw)
To: Boszormenyi Zoltan
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
[+cc linux-pci]
Hi Boszormenyi,
On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
> Hi,
>
> please, cc me, I am not subscribed to lkml.
>
>> Hi,
>>
>> [lkml.org still broken --> no accurate mail header info possible...]
>>
>> Just to ask the obvious:
>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>> (since the machine comes up empty at initial-boot scan, too)
>
> I will try it, too, but I am not sure it would work.
>
> Currently I can't test it because the last time I completely discharged
> the battery. I also disconnected it to be able to get the realtek chip back
> immediately for faster testing. Now, that I have reconnected the battery,
> I need to wait for it to be charged somewhat to be able to reproduce
> losing the network chip.
>
>> Also, you could try diffing lspci -vvxxx -s.... output
>> of working vs. "distorting" kernel version - perhaps some register setup
>> has been changed (e.g. due to power management improvements or some such),
>> which may encourage the card
>> to get a problematic/corrupt state.
>
> I attached a tarball that contains lspci -vvxxx for
> - all devices / only the network chip
> - before / after "modprobe r8169"
> - for all 3 kernel versions tested.
>
> I figured out that if I type the modprobe and lspci in the same command line,
> I can get diagnostics out of the machine, after all.
>
> It's not just the Realtek chip that has changed parameters.
>
> (Vague idea) I noticed that some devices have changed like this:
>
> - Memory behind bridge: 80000000-801fffff
> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
> + Memory behind bridge: ff000000-ff1fffff
> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>
> Can't this cause a problem? E.g. programming the bridge with an address range
> that the bridge doesn't actually support?
This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
v3.18.16 dmesg log, so we can compare them?
These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
the code to see what might be going on:
acpi PNP0A08:00: host bridge window expanded to [mem
0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
ignored
pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
64bit pref]: address conflict with PCI Bus 0000:00 [mem
0xf0000000-0xfed8ffff window]
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-21 14:03 ` Bjorn Helgaas
0 siblings, 0 replies; 26+ messages in thread
From: Bjorn Helgaas @ 2015-06-21 14:03 UTC (permalink / raw)
To: Boszormenyi Zoltan
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
[+cc linux-pci]
Hi Boszormenyi,
On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
> Hi,
>
> please, cc me, I am not subscribed to lkml.
>
>> Hi,
>>
>> [lkml.org still broken --> no accurate mail header info possible...]
>>
>> Just to ask the obvious:
>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>> (since the machine comes up empty at initial-boot scan, too)
>
> I will try it, too, but I am not sure it would work.
>
> Currently I can't test it because the last time I completely discharged
> the battery. I also disconnected it to be able to get the realtek chip back
> immediately for faster testing. Now, that I have reconnected the battery,
> I need to wait for it to be charged somewhat to be able to reproduce
> losing the network chip.
>
>> Also, you could try diffing lspci -vvxxx -s.... output
>> of working vs. "distorting" kernel version - perhaps some register setup
>> has been changed (e.g. due to power management improvements or some such),
>> which may encourage the card
>> to get a problematic/corrupt state.
>
> I attached a tarball that contains lspci -vvxxx for
> - all devices / only the network chip
> - before / after "modprobe r8169"
> - for all 3 kernel versions tested.
>
> I figured out that if I type the modprobe and lspci in the same command line,
> I can get diagnostics out of the machine, after all.
>
> It's not just the Realtek chip that has changed parameters.
>
> (Vague idea) I noticed that some devices have changed like this:
>
> - Memory behind bridge: 80000000-801fffff
> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
> + Memory behind bridge: ff000000-ff1fffff
> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>
> Can't this cause a problem? E.g. programming the bridge with an address range
> that the bridge doesn't actually support?
This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
v3.18.16 dmesg log, so we can compare them?
These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
the code to see what might be going on:
acpi PNP0A08:00: host bridge window expanded to [mem
0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
ignored
pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
64bit pref]: address conflict with PCI Bus 0000:00 [mem
0xf0000000-0xfed8ffff window]
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 14:03 ` Bjorn Helgaas
(?)
(?)
@ 2015-06-21 14:19 ` Boszormenyi Zoltan
2015-06-21 15:37 ` Boszormenyi Zoltan
2015-06-21 17:25 ` Jiang Liu
-1 siblings, 2 replies; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 14:19 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]
2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
> [+cc linux-pci]
>
> Hi Boszormenyi,
>
> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>> Hi,
>>
>> please, cc me, I am not subscribed to lkml.
>>
>>> Hi,
>>>
>>> [lkml.org still broken --> no accurate mail header info possible...]
>>>
>>> Just to ask the obvious:
>>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>>> (since the machine comes up empty at initial-boot scan, too)
>> I will try it, too, but I am not sure it would work.
>>
>> Currently I can't test it because the last time I completely discharged
>> the battery. I also disconnected it to be able to get the realtek chip back
>> immediately for faster testing. Now, that I have reconnected the battery,
>> I need to wait for it to be charged somewhat to be able to reproduce
>> losing the network chip.
>>
>>> Also, you could try diffing lspci -vvxxx -s.... output
>>> of working vs. "distorting" kernel version - perhaps some register setup
>>> has been changed (e.g. due to power management improvements or some such),
>>> which may encourage the card
>>> to get a problematic/corrupt state.
>> I attached a tarball that contains lspci -vvxxx for
>> - all devices / only the network chip
>> - before / after "modprobe r8169"
>> - for all 3 kernel versions tested.
>>
>> I figured out that if I type the modprobe and lspci in the same command line,
>> I can get diagnostics out of the machine, after all.
>>
>> It's not just the Realtek chip that has changed parameters.
>>
>> (Vague idea) I noticed that some devices have changed like this:
>>
>> - Memory behind bridge: 80000000-801fffff
>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>> + Memory behind bridge: ff000000-ff1fffff
>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>
>> Can't this cause a problem? E.g. programming the bridge with an address range
>> that the bridge doesn't actually support?
> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
> v3.18.16 dmesg log, so we can compare them?
I collected all 3 for you to compare them, compressed, attached.
BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>
> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
> the code to see what might be going on:
>
> acpi PNP0A08:00: host bridge window expanded to [mem
> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
> ignored
> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
> 0xf0000000-0xfed8ffff window]
>
> Bjorn
>
Thanks,
Zoltán Böszörményi
[-- Attachment #2: dmesg.tgz --]
[-- Type: application/x-compressed-tar, Size: 39096 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 14:19 ` Boszormenyi Zoltan
@ 2015-06-21 15:37 ` Boszormenyi Zoltan
2015-06-21 17:25 ` Jiang Liu
1 sibling, 0 replies; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 15:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
2015-06-21 16:19 keltezéssel, Boszormenyi Zoltan írta:
> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
>> [+cc linux-pci]
>>
>> Hi Boszormenyi,
>>
>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>>> Hi,
>>>
>>> please, cc me, I am not subscribed to lkml.
>>>
>>>> Hi,
>>>>
>>>> [lkml.org still broken --> no accurate mail header info possible...]
>>>>
>>>> Just to ask the obvious:
>>>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>>>> (since the machine comes up empty at initial-boot scan, too)
>>> I will try it, too, but I am not sure it would work.
>>>
>>> Currently I can't test it because the last time I completely discharged
>>> the battery. I also disconnected it to be able to get the realtek chip back
>>> immediately for faster testing. Now, that I have reconnected the battery,
>>> I need to wait for it to be charged somewhat to be able to reproduce
>>> losing the network chip.
>>>
>>>> Also, you could try diffing lspci -vvxxx -s.... output
>>>> of working vs. "distorting" kernel version - perhaps some register setup
>>>> has been changed (e.g. due to power management improvements or some such),
>>>> which may encourage the card
>>>> to get a problematic/corrupt state.
>>> I attached a tarball that contains lspci -vvxxx for
>>> - all devices / only the network chip
>>> - before / after "modprobe r8169"
>>> - for all 3 kernel versions tested.
>>>
>>> I figured out that if I type the modprobe and lspci in the same command line,
>>> I can get diagnostics out of the machine, after all.
>>>
>>> It's not just the Realtek chip that has changed parameters.
>>>
>>> (Vague idea) I noticed that some devices have changed like this:
>>>
>>> - Memory behind bridge: 80000000-801fffff
>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>> + Memory behind bridge: ff000000-ff1fffff
>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>
>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>> that the bridge doesn't actually support?
>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>> v3.18.16 dmesg log, so we can compare them?
> I collected all 3 for you to compare them, compressed, attached.
>
> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
Reverting this one didn't help.
>
>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>> the code to see what might be going on:
>>
>> acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>> ignored
>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>> 0xf0000000-0xfed8ffff window]
>>
>> Bjorn
>>
> Thanks,
> Zoltán Böszörményi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-21 15:37 ` Boszormenyi Zoltan
0 siblings, 0 replies; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 15:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
2015-06-21 16:19 keltezéssel, Boszormenyi Zoltan írta:
> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
>> [+cc linux-pci]
>>
>> Hi Boszormenyi,
>>
>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>>> Hi,
>>>
>>> please, cc me, I am not subscribed to lkml.
>>>
>>>> Hi,
>>>>
>>>> [lkml.org still broken --> no accurate mail header info possible...]
>>>>
>>>> Just to ask the obvious:
>>>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>>>> (since the machine comes up empty at initial-boot scan, too)
>>> I will try it, too, but I am not sure it would work.
>>>
>>> Currently I can't test it because the last time I completely discharged
>>> the battery. I also disconnected it to be able to get the realtek chip back
>>> immediately for faster testing. Now, that I have reconnected the battery,
>>> I need to wait for it to be charged somewhat to be able to reproduce
>>> losing the network chip.
>>>
>>>> Also, you could try diffing lspci -vvxxx -s.... output
>>>> of working vs. "distorting" kernel version - perhaps some register setup
>>>> has been changed (e.g. due to power management improvements or some such),
>>>> which may encourage the card
>>>> to get a problematic/corrupt state.
>>> I attached a tarball that contains lspci -vvxxx for
>>> - all devices / only the network chip
>>> - before / after "modprobe r8169"
>>> - for all 3 kernel versions tested.
>>>
>>> I figured out that if I type the modprobe and lspci in the same command line,
>>> I can get diagnostics out of the machine, after all.
>>>
>>> It's not just the Realtek chip that has changed parameters.
>>>
>>> (Vague idea) I noticed that some devices have changed like this:
>>>
>>> - Memory behind bridge: 80000000-801fffff
>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>> + Memory behind bridge: ff000000-ff1fffff
>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>
>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>> that the bridge doesn't actually support?
>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>> v3.18.16 dmesg log, so we can compare them?
> I collected all 3 for you to compare them, compressed, attached.
>
> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
Reverting this one didn't help.
>
>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>> the code to see what might be going on:
>>
>> acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>> ignored
>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>> 0xf0000000-0xfed8ffff window]
>>
>> Bjorn
>>
> Thanks,
> Zoltán Böszörményi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 14:19 ` Boszormenyi Zoltan
@ 2015-06-21 17:25 ` Jiang Liu
2015-06-21 17:25 ` Jiang Liu
1 sibling, 0 replies; 26+ messages in thread
From: Jiang Liu @ 2015-06-21 17:25 UTC (permalink / raw)
To: Boszormenyi Zoltan, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
On 2015/6/21 22:19, Boszormenyi Zoltan wrote:
> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
>> [+cc linux-pci]
>>
>> Hi Boszormenyi,
>>
>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>>> Hi,
>>>
>>> please, cc me, I am not subscribed to lkml.
>>>
>>>> Hi,
>>>>
>>>> [lkml.org still broken --> no accurate mail header info possible...]
>>>>
>>>> Just to ask the obvious:
>>>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>>>> (since the machine comes up empty at initial-boot scan, too)
>>> I will try it, too, but I am not sure it would work.
>>>
>>> Currently I can't test it because the last time I completely discharged
>>> the battery. I also disconnected it to be able to get the realtek chip back
>>> immediately for faster testing. Now, that I have reconnected the battery,
>>> I need to wait for it to be charged somewhat to be able to reproduce
>>> losing the network chip.
>>>
>>>> Also, you could try diffing lspci -vvxxx -s.... output
>>>> of working vs. "distorting" kernel version - perhaps some register setup
>>>> has been changed (e.g. due to power management improvements or some such),
>>>> which may encourage the card
>>>> to get a problematic/corrupt state.
>>> I attached a tarball that contains lspci -vvxxx for
>>> - all devices / only the network chip
>>> - before / after "modprobe r8169"
>>> - for all 3 kernel versions tested.
>>>
>>> I figured out that if I type the modprobe and lspci in the same command line,
>>> I can get diagnostics out of the machine, after all.
>>>
>>> It's not just the Realtek chip that has changed parameters.
>>>
>>> (Vague idea) I noticed that some devices have changed like this:
>>>
>>> - Memory behind bridge: 80000000-801fffff
>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>> + Memory behind bridge: ff000000-ff1fffff
>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>
>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>> that the bridge doesn't actually support?
>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>> v3.18.16 dmesg log, so we can compare them?
>
> I collected all 3 for you to compare them, compressed, attached.
>
> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>
>>
>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>> the code to see what might be going on:
>>
>> acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>> ignored
>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>> 0xf0000000-0xfed8ffff window]
>>
>> Bjorn
Hi Bjorn and Boszormenyi,
From the 3.18 kernel, we got a message:
[ 0.126248] acpi PNP0A08:00: host bridge window
[0x400000000-0xfffffffff] (ignored, not CPU addressable)
And from 4.1.-rc8, we got another message:
[ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
That smells like a 32bit overflow or 64bit cut-off issue.
Hi Boszormenyi, could you please help to provide acpidump from the
machine?
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-21 17:25 ` Jiang Liu
0 siblings, 0 replies; 26+ messages in thread
From: Jiang Liu @ 2015-06-21 17:25 UTC (permalink / raw)
To: Boszormenyi Zoltan, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
On 2015/6/21 22:19, Boszormenyi Zoltan wrote:
> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
>> [+cc linux-pci]
>>
>> Hi Boszormenyi,
>>
>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>>> Hi,
>>>
>>> please, cc me, I am not subscribed to lkml.
>>>
>>>> Hi,
>>>>
>>>> [lkml.org still broken --> no accurate mail header info possible...]
>>>>
>>>> Just to ask the obvious:
>>>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>>>> (since the machine comes up empty at initial-boot scan, too)
>>> I will try it, too, but I am not sure it would work.
>>>
>>> Currently I can't test it because the last time I completely discharged
>>> the battery. I also disconnected it to be able to get the realtek chip back
>>> immediately for faster testing. Now, that I have reconnected the battery,
>>> I need to wait for it to be charged somewhat to be able to reproduce
>>> losing the network chip.
>>>
>>>> Also, you could try diffing lspci -vvxxx -s.... output
>>>> of working vs. "distorting" kernel version - perhaps some register setup
>>>> has been changed (e.g. due to power management improvements or some such),
>>>> which may encourage the card
>>>> to get a problematic/corrupt state.
>>> I attached a tarball that contains lspci -vvxxx for
>>> - all devices / only the network chip
>>> - before / after "modprobe r8169"
>>> - for all 3 kernel versions tested.
>>>
>>> I figured out that if I type the modprobe and lspci in the same command line,
>>> I can get diagnostics out of the machine, after all.
>>>
>>> It's not just the Realtek chip that has changed parameters.
>>>
>>> (Vague idea) I noticed that some devices have changed like this:
>>>
>>> - Memory behind bridge: 80000000-801fffff
>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>> + Memory behind bridge: ff000000-ff1fffff
>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>
>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>> that the bridge doesn't actually support?
>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>> v3.18.16 dmesg log, so we can compare them?
>
> I collected all 3 for you to compare them, compressed, attached.
>
> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>
>>
>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>> the code to see what might be going on:
>>
>> acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>> ignored
>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>> 0xf0000000-0xfed8ffff window]
>>
>> Bjorn
Hi Bjorn and Boszormenyi,
From the 3.18 kernel, we got a message:
[ 0.126248] acpi PNP0A08:00: host bridge window
[0x400000000-0xfffffffff] (ignored, not CPU addressable)
And from 4.1.-rc8, we got another message:
[ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
That smells like a 32bit overflow or 64bit cut-off issue.
Hi Boszormenyi, could you please help to provide acpidump from the
machine?
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 17:25 ` Jiang Liu
(?)
@ 2015-06-21 17:55 ` Jiang Liu
-1 siblings, 0 replies; 26+ messages in thread
From: Jiang Liu @ 2015-06-21 17:55 UTC (permalink / raw)
To: Boszormenyi Zoltan, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
On 2015/6/22 1:25, Jiang Liu wrote:
[...]
>>>> - Memory behind bridge: 80000000-801fffff
>>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>>> + Memory behind bridge: ff000000-ff1fffff
>>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>>
>>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>>> that the bridge doesn't actually support?
>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>> v3.18.16 dmesg log, so we can compare them?
>>
>> I collected all 3 for you to compare them, compressed, attached.
>>
>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>
>>>
>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>> the code to see what might be going on:
>>>
>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>>> ignored
>>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>>> 0xf0000000-0xfed8ffff window]
>>>
>>> Bjorn
> Hi Bjorn and Boszormenyi,
> From the 3.18 kernel, we got a message:
> [ 0.126248] acpi PNP0A08:00: host bridge window
> [0x400000000-0xfffffffff] (ignored, not CPU addressable)
> And from 4.1.-rc8, we got another message:
> [ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
>
> That smells like a 32bit overflow or 64bit cut-off issue.
Hi Bjorn and Boszormenyi,
With v3.18.6, it uses u64 to compare resource ranges. We changed to use
resource_size_t with recent changes, and resource_size_t
may be u32 or u64 depending on configuration. So resource range
[0x400000000-0xfffffffff] may have been cut-off as
[0x00000000-0xffffffff], thus cause the trouble.
Hi Boszormenyi,
Could you please help to try following test patch?
against v4.1-rc8?
Thanks!
Gerry
-------------------------------------------------------------------
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8244f013f210..d7b8c392c420 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
res->start = attr->minimum;
res->end = attr->maximum;
+ if (res->start != attr->minimum || res->end != attr->maximum) {
+ pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
addressable)\n",
+ attr->minimum, attr->maximum);
+ return false;
+ }
/*
* For bridges that translate addresses across the bridge,
-----------------------------------------------------------------------------
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-21 17:55 ` Jiang Liu
0 siblings, 0 replies; 26+ messages in thread
From: Jiang Liu @ 2015-06-21 17:55 UTC (permalink / raw)
To: Boszormenyi Zoltan, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
On 2015/6/22 1:25, Jiang Liu wrote:
[...]
>>>> - Memory behind bridge: 80000000-801fffff
>>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>>> + Memory behind bridge: ff000000-ff1fffff
>>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>>
>>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>>> that the bridge doesn't actually support?
>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>> v3.18.16 dmesg log, so we can compare them?
>>
>> I collected all 3 for you to compare them, compressed, attached.
>>
>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>
>>>
>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>> the code to see what might be going on:
>>>
>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>>> ignored
>>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>>> 0xf0000000-0xfed8ffff window]
>>>
>>> Bjorn
> Hi Bjorn and Boszormenyi,
> From the 3.18 kernel, we got a message:
> [ 0.126248] acpi PNP0A08:00: host bridge window
> [0x400000000-0xfffffffff] (ignored, not CPU addressable)
> And from 4.1.-rc8, we got another message:
> [ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
>
> That smells like a 32bit overflow or 64bit cut-off issue.
Hi Bjorn and Boszormenyi,
With v3.18.6, it uses u64 to compare resource ranges. We changed to use
resource_size_t with recent changes, and resource_size_t
may be u32 or u64 depending on configuration. So resource range
[0x400000000-0xfffffffff] may have been cut-off as
[0x00000000-0xffffffff], thus cause the trouble.
Hi Boszormenyi,
Could you please help to try following test patch?
against v4.1-rc8?
Thanks!
Gerry
-------------------------------------------------------------------
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8244f013f210..d7b8c392c420 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
res->start = attr->minimum;
res->end = attr->maximum;
+ if (res->start != attr->minimum || res->end != attr->maximum) {
+ pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
addressable)\n",
+ attr->minimum, attr->maximum);
+ return false;
+ }
/*
* For bridges that translate addresses across the bridge,
-----------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-21 17:55 ` Jiang Liu
0 siblings, 0 replies; 26+ messages in thread
From: Jiang Liu @ 2015-06-21 17:55 UTC (permalink / raw)
To: Boszormenyi Zoltan, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
On 2015/6/22 1:25, Jiang Liu wrote:
[...]
>>>> - Memory behind bridge: 80000000-801fffff
>>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>>> + Memory behind bridge: ff000000-ff1fffff
>>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>>
>>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>>> that the bridge doesn't actually support?
>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>> v3.18.16 dmesg log, so we can compare them?
>>
>> I collected all 3 for you to compare them, compressed, attached.
>>
>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>
>>>
>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>> the code to see what might be going on:
>>>
>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>>> ignored
>>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>>> 0xf0000000-0xfed8ffff window]
>>>
>>> Bjorn
> Hi Bjorn and Boszormenyi,
> From the 3.18 kernel, we got a message:
> [ 0.126248] acpi PNP0A08:00: host bridge window
> [0x400000000-0xfffffffff] (ignored, not CPU addressable)
> And from 4.1.-rc8, we got another message:
> [ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
>
> That smells like a 32bit overflow or 64bit cut-off issue.
Hi Bjorn and Boszormenyi,
With v3.18.6, it uses u64 to compare resource ranges. We changed to use
resource_size_t with recent changes, and resource_size_t
may be u32 or u64 depending on configuration. So resource range
[0x400000000-0xfffffffff] may have been cut-off as
[0x00000000-0xffffffff], thus cause the trouble.
Hi Boszormenyi,
Could you please help to try following test patch?
against v4.1-rc8?
Thanks!
Gerry
-------------------------------------------------------------------
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8244f013f210..d7b8c392c420 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
res->start = attr->minimum;
res->end = attr->maximum;
+ if (res->start != attr->minimum || res->end != attr->maximum) {
+ pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
addressable)\n",
+ attr->minimum, attr->maximum);
+ return false;
+ }
/*
* For bridges that translate addresses across the bridge,
-----------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 17:25 ` Jiang Liu
(?)
(?)
@ 2015-06-21 18:28 ` Boszormenyi Zoltan
-1 siblings, 0 replies; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 18:28 UTC (permalink / raw)
To: Jiang Liu, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
[-- Attachment #1: Type: text/plain, Size: 3710 bytes --]
2015-06-21 19:25 keltezéssel, Jiang Liu írta:
> On 2015/6/21 22:19, Boszormenyi Zoltan wrote:
>> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
>>> [+cc linux-pci]
>>>
>>> Hi Boszormenyi,
>>>
>>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>>>> Hi,
>>>>
>>>> please, cc me, I am not subscribed to lkml.
>>>>
>>>>> Hi,
>>>>>
>>>>> [lkml.org still broken --> no accurate mail header info possible...]
>>>>>
>>>>> Just to ask the obvious:
>>>>> I assume using /sys/bus/pci/rescan does not help once it's broken?
>>>>> (since the machine comes up empty at initial-boot scan, too)
>>>> I will try it, too, but I am not sure it would work.
>>>>
>>>> Currently I can't test it because the last time I completely discharged
>>>> the battery. I also disconnected it to be able to get the realtek chip back
>>>> immediately for faster testing. Now, that I have reconnected the battery,
>>>> I need to wait for it to be charged somewhat to be able to reproduce
>>>> losing the network chip.
>>>>
>>>>> Also, you could try diffing lspci -vvxxx -s.... output
>>>>> of working vs. "distorting" kernel version - perhaps some register setup
>>>>> has been changed (e.g. due to power management improvements or some such),
>>>>> which may encourage the card
>>>>> to get a problematic/corrupt state.
>>>> I attached a tarball that contains lspci -vvxxx for
>>>> - all devices / only the network chip
>>>> - before / after "modprobe r8169"
>>>> - for all 3 kernel versions tested.
>>>>
>>>> I figured out that if I type the modprobe and lspci in the same command line,
>>>> I can get diagnostics out of the machine, after all.
>>>>
>>>> It's not just the Realtek chip that has changed parameters.
>>>>
>>>> (Vague idea) I noticed that some devices have changed like this:
>>>>
>>>> - Memory behind bridge: 80000000-801fffff
>>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>>> + Memory behind bridge: ff000000-ff1fffff
>>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>>
>>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>>> that the bridge doesn't actually support?
>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>> v3.18.16 dmesg log, so we can compare them?
>> I collected all 3 for you to compare them, compressed, attached.
>>
>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>
>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>> the code to see what might be going on:
>>>
>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>>> ignored
>>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>>> 0xf0000000-0xfed8ffff window]
>>>
>>> Bjorn
> Hi Bjorn and Boszormenyi,
> From the 3.18 kernel, we got a message:
> [ 0.126248] acpi PNP0A08:00: host bridge window
> [0x400000000-0xfffffffff] (ignored, not CPU addressable)
> And from 4.1.-rc8, we got another message:
> [ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
>
> That smells like a 32bit overflow or 64bit cut-off issue.
>
> Hi Boszormenyi, could you please help to provide acpidump from the
> machine?
I already did in a previous mail which was only sent to LKML, but here it is again.
Thanks,
Zoltán
> Thanks!
> Gerry
>
>
>
>
[-- Attachment #2: acpidump.tgz --]
[-- Type: application/x-compressed-tar, Size: 49038 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 17:55 ` Jiang Liu
(?)
(?)
@ 2015-06-21 18:55 ` Boszormenyi Zoltan
2015-06-21 19:59 ` Boszormenyi Zoltan
-1 siblings, 1 reply; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 18:55 UTC (permalink / raw)
To: Jiang Liu, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]
2015-06-21 19:55 keltezéssel, Jiang Liu írta:
> On 2015/6/22 1:25, Jiang Liu wrote:
> [...]
>>>>> - Memory behind bridge: 80000000-801fffff
>>>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>>>> + Memory behind bridge: ff000000-ff1fffff
>>>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>>>
>>>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>>>> that the bridge doesn't actually support?
>>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>>> v3.18.16 dmesg log, so we can compare them?
>>> I collected all 3 for you to compare them, compressed, attached.
>>>
>>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>>
>>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>>> the code to see what might be going on:
>>>>
>>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>>>> ignored
>>>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>>>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>>>> 0xf0000000-0xfed8ffff window]
>>>>
>>>> Bjorn
>> Hi Bjorn and Boszormenyi,
>> From the 3.18 kernel, we got a message:
>> [ 0.126248] acpi PNP0A08:00: host bridge window
>> [0x400000000-0xfffffffff] (ignored, not CPU addressable)
>> And from 4.1.-rc8, we got another message:
>> [ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
>>
>> That smells like a 32bit overflow or 64bit cut-off issue.
> Hi Bjorn and Boszormenyi,
> With v3.18.6, it uses u64 to compare resource ranges. We changed to use
> resource_size_t with recent changes, and resource_size_t
> may be u32 or u64 depending on configuration. So resource range
> [0x400000000-0xfffffffff] may have been cut-off as
> [0x00000000-0xffffffff], thus cause the trouble.
>
> Hi Boszormenyi,
> Could you please help to try following test patch?
> against v4.1-rc8?
I have tried it. The result (dmesg, lspci before/after modprobe) is attached.
The "not CPU addressable" message shows up once in dmesg.
The device shows up in lspci and the module can be loaded. The previously
experienced sluggishness is gone now, but the network doesn't work after modprobe.
I think it was an expected outcome, since that particular range is ignored with this patch.
Thanks,
Zoltán
> Thanks!
> Gerry
> -------------------------------------------------------------------
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 8244f013f210..d7b8c392c420 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
>
> res->start = attr->minimum;
> res->end = attr->maximum;
> + if (res->start != attr->minimum || res->end != attr->maximum) {
> + pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
> addressable)\n",
> + attr->minimum, attr->maximum);
> + return false;
> + }
>
> /*
> * For bridges that translate addresses across the bridge,
> -----------------------------------------------------------------------------
>
[-- Attachment #2: dmesg-lspci-xx2.tgz --]
[-- Type: application/x-compressed-tar, Size: 21863 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
2015-06-21 18:55 ` Boszormenyi Zoltan
@ 2015-06-21 19:59 ` Boszormenyi Zoltan
0 siblings, 0 replies; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 19:59 UTC (permalink / raw)
To: Jiang Liu, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
2015-06-21 20:55 keltezéssel, Boszormenyi Zoltan írta:
> 2015-06-21 19:55 keltezéssel, Jiang Liu írta:
>> On 2015/6/22 1:25, Jiang Liu wrote:
>> [...]
>>>>>> - Memory behind bridge: 80000000-801fffff
>>>>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>>>>> + Memory behind bridge: ff000000-ff1fffff
>>>>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>>>>
>>>>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>>>>> that the bridge doesn't actually support?
>>>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>>>> v3.18.16 dmesg log, so we can compare them?
>>>> I collected all 3 for you to compare them, compressed, attached.
>>>>
>>>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>>>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>>>
>>>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>>>> the code to see what might be going on:
>>>>>
>>>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>>>>> ignored
>>>>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>>>>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>>>>> 0xf0000000-0xfed8ffff window]
>>>>>
>>>>> Bjorn
>>> Hi Bjorn and Boszormenyi,
>>> From the 3.18 kernel, we got a message:
>>> [ 0.126248] acpi PNP0A08:00: host bridge window
>>> [0x400000000-0xfffffffff] (ignored, not CPU addressable)
>>> And from 4.1.-rc8, we got another message:
>>> [ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
>>>
>>> That smells like a 32bit overflow or 64bit cut-off issue.
>> Hi Bjorn and Boszormenyi,
>> With v3.18.6, it uses u64 to compare resource ranges. We changed to use
>> resource_size_t with recent changes, and resource_size_t
>> may be u32 or u64 depending on configuration. So resource range
>> [0x400000000-0xfffffffff] may have been cut-off as
>> [0x00000000-0xffffffff], thus cause the trouble.
>>
>> Hi Boszormenyi,
>> Could you please help to try following test patch?
>> against v4.1-rc8?
> I have tried it. The result (dmesg, lspci before/after modprobe) is attached.
> The "not CPU addressable" message shows up once in dmesg.
> The device shows up in lspci and the module can be loaded. The previously
> experienced sluggishness is gone now, but the network doesn't work after modprobe.
> I think it was an expected outcome, since that particular range is ignored with this patch.
Hm, I can see a very similar message in 3.18.16, so it was not
the expected outcome.
After building the "official" r8168 from Realtek for 4.1.0-rc8,
the difference in lspci from the working 3.18.16 is nil, before
and after modprobe. (r8168 was build for 3.18.16, that's why.)
However, connman (similar to NetworkManager) still sees the network
connectivity as "down". I checked that the firmware files are there in
/lib/firmware/rtl_nic.
With r8168 (the "official" Realtek driver), the kernel message about
"link up" appears immediately and connman can configure the network.
I have tried the patch on 4.0.5, too, with the same result.
So, there may be another problem with the r8169 driver itself besides
this ACPI problem but no matter what I do, I can't seem to be able
to enable debugging messages for r8169.
So, for now I can use r8168 instead of r8169 with this patch.
Thanks,
Zoltán
>
> Thanks,
> Zoltán
>
>> Thanks!
>> Gerry
>> -------------------------------------------------------------------
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 8244f013f210..d7b8c392c420 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
>>
>> res->start = attr->minimum;
>> res->end = attr->maximum;
>> + if (res->start != attr->minimum || res->end != attr->maximum) {
>> + pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
>> addressable)\n",
>> + attr->minimum, attr->maximum);
>> + return false;
>> + }
>>
>> /*
>> * For bridges that translate addresses across the bridge,
>> -----------------------------------------------------------------------------
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
@ 2015-06-21 19:59 ` Boszormenyi Zoltan
0 siblings, 0 replies; 26+ messages in thread
From: Boszormenyi Zoltan @ 2015-06-21 19:59 UTC (permalink / raw)
To: Jiang Liu, Bjorn Helgaas
Cc: Andreas Mohr, Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, linux-pci
2015-06-21 20:55 keltezéssel, Boszormenyi Zoltan írta:
> 2015-06-21 19:55 keltezéssel, Jiang Liu írta:
>> On 2015/6/22 1:25, Jiang Liu wrote:
>> [...]
>>>>>> - Memory behind bridge: 80000000-801fffff
>>>>>> - Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
>>>>>> + Memory behind bridge: ff000000-ff1fffff
>>>>>> + Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff
>>>>>>
>>>>>> Can't this cause a problem? E.g. programming the bridge with an address range
>>>>>> that the bridge doesn't actually support?
>>>>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>>>>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>>>>> v3.18.16 dmesg log, so we can compare them?
>>>> I collected all 3 for you to compare them, compressed, attached.
>>>>
>>>> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
>>>> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>>>>
>>>>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>>>>> the code to see what might be going on:
>>>>>
>>>>> acpi PNP0A08:00: host bridge window expanded to [mem
>>>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>>>>> ignored
>>>>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>>>>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>>>>> 0xf0000000-0xfed8ffff window]
>>>>>
>>>>> Bjorn
>>> Hi Bjorn and Boszormenyi,
>>> From the 3.18 kernel, we got a message:
>>> [ 0.126248] acpi PNP0A08:00: host bridge window
>>> [0x400000000-0xfffffffff] (ignored, not CPU addressable)
>>> And from 4.1.-rc8, we got another message:
>>> [ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
>>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
>>>
>>> That smells like a 32bit overflow or 64bit cut-off issue.
>> Hi Bjorn and Boszormenyi,
>> With v3.18.6, it uses u64 to compare resource ranges. We changed to use
>> resource_size_t with recent changes, and resource_size_t
>> may be u32 or u64 depending on configuration. So resource range
>> [0x400000000-0xfffffffff] may have been cut-off as
>> [0x00000000-0xffffffff], thus cause the trouble.
>>
>> Hi Boszormenyi,
>> Could you please help to try following test patch?
>> against v4.1-rc8?
> I have tried it. The result (dmesg, lspci before/after modprobe) is attached.
> The "not CPU addressable" message shows up once in dmesg.
> The device shows up in lspci and the module can be loaded. The previously
> experienced sluggishness is gone now, but the network doesn't work after modprobe.
> I think it was an expected outcome, since that particular range is ignored with this patch.
Hm, I can see a very similar message in 3.18.16, so it was not
the expected outcome.
After building the "official" r8168 from Realtek for 4.1.0-rc8,
the difference in lspci from the working 3.18.16 is nil, before
and after modprobe. (r8168 was build for 3.18.16, that's why.)
However, connman (similar to NetworkManager) still sees the network
connectivity as "down". I checked that the firmware files are there in
/lib/firmware/rtl_nic.
With r8168 (the "official" Realtek driver), the kernel message about
"link up" appears immediately and connman can configure the network.
I have tried the patch on 4.0.5, too, with the same result.
So, there may be another problem with the r8169 driver itself besides
this ACPI problem but no matter what I do, I can't seem to be able
to enable debugging messages for r8169.
So, for now I can use r8168 instead of r8169 with this patch.
Thanks,
Zoltán
>
> Thanks,
> Zoltán
>
>> Thanks!
>> Gerry
>> -------------------------------------------------------------------
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 8244f013f210..d7b8c392c420 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -206,6 +206,11 @@ static bool acpi_decode_space(struct resource_win *win,
>>
>> res->start = attr->minimum;
>> res->end = attr->maximum;
>> + if (res->start != attr->minimum || res->end != attr->maximum) {
>> + pr_warn("resource window ([%#llx-%#llx] ignored, not CPU
>> addressable)\n",
>> + attr->minimum, attr->maximum);
>> + return false;
>> + }
>>
>> /*
>> * For bridges that translate addresses across the bridge,
>> -----------------------------------------------------------------------------
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel
2015-06-21 19:59 ` Boszormenyi Zoltan
@ 2015-06-23 4:12 ` Jiang Liu
-1 siblings, 0 replies; 26+ messages in thread
From: Jiang Liu @ 2015-06-23 4:12 UTC (permalink / raw)
To: Rafael J . Wysocki, Bjorn Helgaas, Boszormenyi Zoltan, Len Brown
Cc: Jiang Liu, LKML, linux-pci, linux-acpi, x86 @ kernel . org
The data type resource_size_t may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT. So reject ACPI resource descriptors which
will cause resource_size_t overflow with 32bit kernel
This issue was triggered on a platform running 32bit kernel with an
ACPI resource descriptor with address range [0x400000000-0xfffffffff].
Please refer to https://lkml.org/lkml/2015/6/19/277 for more information.
Reported-by: Boszormenyi Zoltan <zboszor@pr.hu>
Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation")
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: stable@vger.kernel.org # 4.0
---
drivers/acpi/resource.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8244f013f210..f1c966e05078 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -193,6 +193,7 @@ static bool acpi_decode_space(struct resource_win *win,
u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
bool wp = addr->info.mem.write_protect;
u64 len = attr->address_length;
+ u64 start, end, offset = 0;
struct resource *res = &win->res;
/*
@@ -204,9 +205,6 @@ static bool acpi_decode_space(struct resource_win *win,
pr_debug("ACPI: Invalid address space min_addr_fix %d, max_addr_fix %d, len %llx\n",
addr->min_address_fixed, addr->max_address_fixed, len);
- res->start = attr->minimum;
- res->end = attr->maximum;
-
/*
* For bridges that translate addresses across the bridge,
* translation_offset is the offset that must be added to the
@@ -214,12 +212,22 @@ static bool acpi_decode_space(struct resource_win *win,
* primary side. Non-bridge devices must list 0 for all Address
* Translation offset bits.
*/
- if (addr->producer_consumer == ACPI_PRODUCER) {
- res->start += attr->translation_offset;
- res->end += attr->translation_offset;
- } else if (attr->translation_offset) {
+ if (addr->producer_consumer == ACPI_PRODUCER)
+ offset = attr->translation_offset;
+ else if (attr->translation_offset)
pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
attr->translation_offset);
+ start = attr->minimum + offset;
+ end = attr->maximum + offset;
+
+ win->offset = offset;
+ res->start = start;
+ res->end = end;
+ if (sizeof(resource_size_t) < sizeof(u64) &&
+ (offset != win->offset || start != res->start || end != res->end)) {
+ pr_warn("acpi resource window ([%#llx-%#llx] ignored, not CPU addressable)\n",
+ attr->minimum, attr->maximum);
+ return false;
}
switch (addr->resource_type) {
@@ -236,8 +244,6 @@ static bool acpi_decode_space(struct resource_win *win,
return false;
}
- win->offset = attr->translation_offset;
-
if (addr->producer_consumer == ACPI_PRODUCER)
res->flags |= IORESOURCE_WINDOW;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel
@ 2015-06-23 4:12 ` Jiang Liu
0 siblings, 0 replies; 26+ messages in thread
From: Jiang Liu @ 2015-06-23 4:12 UTC (permalink / raw)
To: Rafael J . Wysocki, Bjorn Helgaas, Boszormenyi Zoltan, Len Brown
Cc: Jiang Liu, LKML, linux-pci, linux-acpi, x86 @ kernel . org
The data type resource_size_t may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT. So reject ACPI resource descriptors which
will cause resource_size_t overflow with 32bit kernel
This issue was triggered on a platform running 32bit kernel with an
ACPI resource descriptor with address range [0x400000000-0xfffffffff].
Please refer to https://lkml.org/lkml/2015/6/19/277 for more information.
Reported-by: Boszormenyi Zoltan <zboszor@pr.hu>
Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation")
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: stable@vger.kernel.org # 4.0
---
drivers/acpi/resource.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 8244f013f210..f1c966e05078 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -193,6 +193,7 @@ static bool acpi_decode_space(struct resource_win *win,
u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
bool wp = addr->info.mem.write_protect;
u64 len = attr->address_length;
+ u64 start, end, offset = 0;
struct resource *res = &win->res;
/*
@@ -204,9 +205,6 @@ static bool acpi_decode_space(struct resource_win *win,
pr_debug("ACPI: Invalid address space min_addr_fix %d, max_addr_fix %d, len %llx\n",
addr->min_address_fixed, addr->max_address_fixed, len);
- res->start = attr->minimum;
- res->end = attr->maximum;
-
/*
* For bridges that translate addresses across the bridge,
* translation_offset is the offset that must be added to the
@@ -214,12 +212,22 @@ static bool acpi_decode_space(struct resource_win *win,
* primary side. Non-bridge devices must list 0 for all Address
* Translation offset bits.
*/
- if (addr->producer_consumer == ACPI_PRODUCER) {
- res->start += attr->translation_offset;
- res->end += attr->translation_offset;
- } else if (attr->translation_offset) {
+ if (addr->producer_consumer == ACPI_PRODUCER)
+ offset = attr->translation_offset;
+ else if (attr->translation_offset)
pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
attr->translation_offset);
+ start = attr->minimum + offset;
+ end = attr->maximum + offset;
+
+ win->offset = offset;
+ res->start = start;
+ res->end = end;
+ if (sizeof(resource_size_t) < sizeof(u64) &&
+ (offset != win->offset || start != res->start || end != res->end)) {
+ pr_warn("acpi resource window ([%#llx-%#llx] ignored, not CPU addressable)\n",
+ attr->minimum, attr->maximum);
+ return false;
}
switch (addr->resource_type) {
@@ -236,8 +244,6 @@ static bool acpi_decode_space(struct resource_win *win,
return false;
}
- win->offset = attr->translation_offset;
-
if (addr->producer_consumer == ACPI_PRODUCER)
res->flags |= IORESOURCE_WINDOW;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel
2015-06-23 4:12 ` Jiang Liu
@ 2015-06-23 7:35 ` Ingo Molnar
-1 siblings, 0 replies; 26+ messages in thread
From: Ingo Molnar @ 2015-06-23 7:35 UTC (permalink / raw)
To: Jiang Liu
Cc: Rafael J . Wysocki, Bjorn Helgaas, Boszormenyi Zoltan, Len Brown,
LKML, linux-pci, linux-acpi, x86 @ kernel . org
* Jiang Liu <jiang.liu@linux.intel.com> wrote:
> The data type resource_size_t may be 32 bits or 64 bits depending on
> CONFIG_PHYS_ADDR_T_64BIT. So reject ACPI resource descriptors which
> will cause resource_size_t overflow with 32bit kernel
>
> This issue was triggered on a platform running 32bit kernel with an
> ACPI resource descriptor with address range [0x400000000-0xfffffffff].
> Please refer to https://lkml.org/lkml/2015/6/19/277 for more information.
>
> Reported-by: Boszormenyi Zoltan <zboszor@pr.hu>
> Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation")
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> Cc: stable@vger.kernel.org # 4.0
Yeah, so please use the customary changelog style we use in the kernel:
" Current code does (A), this causes problem (B) when doing (C).
In that case the user notices (D).
We can improve this doing (E), because now the user will experience (F),
which is more desirable."
Please fill in A-F accordingly.
In particular your changelog is missing 'B' and 'D': what exactly is a
'resource_size_t overflow' and what does the user notice from it?
Your changelog is also missing 'F'.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel
@ 2015-06-23 7:35 ` Ingo Molnar
0 siblings, 0 replies; 26+ messages in thread
From: Ingo Molnar @ 2015-06-23 7:35 UTC (permalink / raw)
To: Jiang Liu
Cc: Rafael J . Wysocki, Bjorn Helgaas, Boszormenyi Zoltan, Len Brown,
LKML, linux-pci, linux-acpi, x86 @ kernel . org
* Jiang Liu <jiang.liu@linux.intel.com> wrote:
> The data type resource_size_t may be 32 bits or 64 bits depending on
> CONFIG_PHYS_ADDR_T_64BIT. So reject ACPI resource descriptors which
> will cause resource_size_t overflow with 32bit kernel
>
> This issue was triggered on a platform running 32bit kernel with an
> ACPI resource descriptor with address range [0x400000000-0xfffffffff].
> Please refer to https://lkml.org/lkml/2015/6/19/277 for more information.
>
> Reported-by: Boszormenyi Zoltan <zboszor@pr.hu>
> Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation")
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> Cc: stable@vger.kernel.org # 4.0
Yeah, so please use the customary changelog style we use in the kernel:
" Current code does (A), this causes problem (B) when doing (C).
In that case the user notices (D).
We can improve this doing (E), because now the user will experience (F),
which is more desirable."
Please fill in A-F accordingly.
In particular your changelog is missing 'B' and 'D': what exactly is a
'resource_size_t overflow' and what does the user notice from it?
Your changelog is also missing 'F'.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-06-23 7:35 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-19 13:24 Ethernet chip disappeared from lspci Boszormenyi Zoltan
2015-06-19 13:31 ` Boszormenyi Zoltan
2015-06-19 13:46 ` ACPI regression? Was " Boszormenyi Zoltan
2015-06-19 23:13 ` Rafael J. Wysocki
2015-06-19 23:13 ` Rafael J. Wysocki
2015-06-20 6:38 ` Boszormenyi Zoltan
2015-06-21 10:34 ` Boszormenyi Zoltan
2015-06-21 14:03 ` Bjorn Helgaas
2015-06-21 14:03 ` Bjorn Helgaas
2015-06-21 14:03 ` Bjorn Helgaas
2015-06-21 14:19 ` Boszormenyi Zoltan
2015-06-21 15:37 ` Boszormenyi Zoltan
2015-06-21 15:37 ` Boszormenyi Zoltan
2015-06-21 17:25 ` Jiang Liu
2015-06-21 17:25 ` Jiang Liu
2015-06-21 17:55 ` Jiang Liu
2015-06-21 17:55 ` Jiang Liu
2015-06-21 17:55 ` Jiang Liu
2015-06-21 18:55 ` Boszormenyi Zoltan
2015-06-21 19:59 ` Boszormenyi Zoltan
2015-06-21 19:59 ` Boszormenyi Zoltan
2015-06-23 4:12 ` [Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel Jiang Liu
2015-06-23 4:12 ` Jiang Liu
2015-06-23 7:35 ` Ingo Molnar
2015-06-23 7:35 ` Ingo Molnar
2015-06-21 18:28 ` ACPI regression? Was Re: Ethernet chip disappeared from lspci Boszormenyi Zoltan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.