vdr.service startet zu früh wenn als VM auf ESX-Host installiert

[HTPC-Schrauber]

Ich habe VDR4Arch in einer VM auf einem ESXi Host laufen. Also TV-Karte nutze ich eine Cine CT V6.

Wenn ich den VDR Service zum automatischen Start aktiviere, dann startet er zu früh. Der VDR wird dann bereits gestartet bevor die CineCT initialisiert ist. Der VDR findet dadurch keine DVB-Karte. Laut Log passiert das alles innerhalb einer Sekunde.

Workaround: ein 'sleep 5' in die /etc/runvdr.conf einfügen

Hier das Log: -- Logs begin at Di 2013-03-12 22:54:07 CET, end at Mi 2013-04-10 22:02:50 CEST. -- Apr 10 22:02:33 archvdr systemd-journal[113]: Allowing runtime journal files to grow to 49.9M. Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys cpuset Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys cpu Apr 10 22:02:33 archvdr kernel: Linux version 3.8.6-1-ARCH (tobias@T-POWA-LX) (gcc version 4.8.0 (GCC) ) #1 SMP PREEMPT Sat Apr 6 07:27:01 CEST 2013 Apr 10 22:02:33 archvdr kernel: Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=276b5bb9-90e3-47a7-9ccc-e6734aff8a23 ro quiet Apr 10 22:02:33 archvdr kernel: Disabled fast string operations Apr 10 22:02:33 archvdr kernel: e820: BIOS-provided physical RAM map: Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x0000000000100000-0x000000003feeffff] usable Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x000000003fef0000-0x000000003fefefff] ACPI data Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x000000003feff000-0x000000003fefffff] ACPI NVS Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x000000003ff00000-0x000000003fffffff] usable Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved Apr 10 22:02:33 archvdr kernel: BIOS-e820: [mem 0x00000000fffe0000-0x00000000ffffffff] reserved Apr 10 22:02:33 archvdr kernel: NX (Execute Disable) protection: active Apr 10 22:02:33 archvdr kernel: SMBIOS 2.4 present. Apr 10 22:02:33 archvdr kernel: DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 06/22/2012 Apr 10 22:02:33 archvdr kernel: Hypervisor detected: VMware Apr 10 22:02:33 archvdr kernel: e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved Apr 10 22:02:33 archvdr kernel: e820: remove [mem 0x000a0000-0x000fffff] usable Apr 10 22:02:33 archvdr kernel: No AGP bridge found Apr 10 22:02:33 archvdr kernel: e820: last_pfn = 0x40000 max_arch_pfn = 0x400000000 Apr 10 22:02:33 archvdr kernel: MTRR default type: uncachable Apr 10 22:02:33 archvdr kernel: MTRR fixed ranges enabled: Apr 10 22:02:33 archvdr kernel: 00000-9FFFF write-back Apr 10 22:02:33 archvdr kernel: A0000-BFFFF uncachable Apr 10 22:02:33 archvdr kernel: C0000-CBFFF write-protect Apr 10 22:02:33 archvdr kernel: CC000-EFFFF uncachable Apr 10 22:02:33 archvdr kernel: F0000-FFFFF write-protect Apr 10 22:02:33 archvdr kernel: MTRR variable ranges enabled: Apr 10 22:02:33 archvdr kernel: 0 base 0000000000 mask FFC0000000 write-back Apr 10 22:02:33 archvdr kernel: 1 disabled Apr 10 22:02:33 archvdr kernel: 2 disabled Apr 10 22:02:33 archvdr kernel: 3 disabled Apr 10 22:02:33 archvdr kernel: 4 disabled Apr 10 22:02:33 archvdr kernel: 5 disabled Apr 10 22:02:33 archvdr kernel: 6 disabled Apr 10 22:02:33 archvdr kernel: 7 disabled Apr 10 22:02:33 archvdr kernel: x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106 Apr 10 22:02:33 archvdr kernel: found SMP MP-table at [mem 0x000f6bf0-0x000f6bff] mapped at [ffff8800000f6bf0] Apr 10 22:02:33 archvdr kernel: initial memory mapped: [mem 0x00000000-0x1fffffff] Apr 10 22:02:33 archvdr kernel: Base memory trampoline at [ffff880000099000] 99000 size 24576 Apr 10 22:02:33 archvdr kernel: init_memory_mapping: [mem 0x00000000-0x3fffffff] Apr 10 22:02:33 archvdr kernel: [mem 0x00000000-0x3fffffff] page 2M Apr 10 22:02:33 archvdr kernel: kernel direct mapping tables up to 0x3fffffff @ [mem 0x1fffe000-0x1fffffff] Apr 10 22:02:33 archvdr kernel: RAMDISK: [mem 0x37a94000-0x37d41fff] Apr 10 22:02:33 archvdr kernel: ACPI: RSDP 00000000000f6b80 00024 (v02 PTLTD ) Apr 10 22:02:33 archvdr kernel: ACPI: XSDT 000000003fef0127 0005C (v01 INTEL 440BX 06040000 VMW 01324272) Apr 10 22:02:33 archvdr kernel: ACPI: FACP 000000003fefee98 000F4 (v04 INTEL 440BX 06040000 PTL 000F4240) Apr 10 22:02:33 archvdr kernel: ACPI: DSDT 000000003fef0367 0EB31 (v01 PTLTD Custom 06040000 MSFT 03000001) Apr 10 22:02:33 archvdr kernel: ACPI: FACS 000000003fefffc0 00040 Apr 10 22:02:33 archvdr kernel: ACPI: BOOT 000000003fef033f 00028 (v01 PTLTD $SBFTBL$ 06040000 LTP 00000001) Apr 10 22:02:33 archvdr kernel: ACPI: APIC 000000003fef02ef 00050 (v01 PTLTD ? APIC 06040000 LTP 00000000) Apr 10 22:02:33 archvdr kernel: ACPI: MCFG 000000003fef02b3 0003C (v01 PTLTD $PCITBL$ 06040000 LTP 00000001) Apr 10 22:02:33 archvdr kernel: ACPI: SRAT 000000003fef0223 00090 (v02 VMWARE MEMPLUG 06040000 VMW 00000001) Apr 10 22:02:33 archvdr kernel: ACPI: HPET 000000003fef01eb 00038 (v01 VMWARE VMW HPET 06040000 VMW 00000001) Apr 10 22:02:33 archvdr kernel: ACPI: WAET 000000003fef01c3 00028 (v01 VMWARE VMW WAET 06040000 VMW 00000001) Apr 10 22:02:33 archvdr kernel: ACPI: Local APIC address 0xfee00000 Apr 10 22:02:33 archvdr kernel: SRAT: PXM 0 -> APIC 0x00 -> Node 0 Apr 10 22:02:33 archvdr kernel: SRAT: Node 0 PXM 0 [mem 0x00000000-0x0009ffff] Apr 10 22:02:33 archvdr kernel: SRAT: Node 0 PXM 0 [mem 0x00100000-0x3fffffff] Apr 10 22:02:33 archvdr kernel: NUMA: Node 0 [mem 0x00000000-0x0009ffff] + [mem 0x00100000-0x3fffffff] -> [mem 0x00000000-0x3fffffff] Apr 10 22:02:33 archvdr kernel: Initmem setup node 0 [mem 0x00000000-0x3fffffff] Apr 10 22:02:33 archvdr kernel: NODE_DATA [mem 0x3fffb000-0x3fffffff] Apr 10 22:02:33 archvdr kernel: [ffffea0000000000-ffffea0000ffffff] PMD -> [ffff88003e600000-ffff88003f5fffff] on node 0 Apr 10 22:02:33 archvdr kernel: Zone ranges: Apr 10 22:02:33 archvdr kernel: DMA [mem 0x00010000-0x00ffffff] Apr 10 22:02:33 archvdr kernel: DMA32 [mem 0x01000000-0xffffffff] Apr 10 22:02:33 archvdr kernel: Normal empty Apr 10 22:02:33 archvdr kernel: Movable zone start for each node Apr 10 22:02:33 archvdr kernel: Early memory node ranges Apr 10 22:02:33 archvdr kernel: node 0: [mem 0x00010000-0x0009efff] Apr 10 22:02:33 archvdr kernel: node 0: [mem 0x00100000-0x3feeffff] Apr 10 22:02:33 archvdr kernel: node 0: [mem 0x3ff00000-0x3fffffff] Apr 10 22:02:33 archvdr kernel: On node 0 totalpages: 262015 Apr 10 22:02:33 archvdr kernel: DMA zone: 64 pages used for memmap Apr 10 22:02:33 archvdr kernel: DMA zone: 6 pages reserved Apr 10 22:02:33 archvdr kernel: DMA zone: 3913 pages, LIFO batch:0 Apr 10 22:02:33 archvdr kernel: DMA32 zone: 4032 pages used for memmap Apr 10 22:02:33 archvdr kernel: DMA32 zone: 254000 pages, LIFO batch:31 Apr 10 22:02:33 archvdr kernel: ACPI: PM-Timer IO Port: 0x1008 Apr 10 22:02:33 archvdr kernel: ACPI: Local APIC address 0xfee00000 Apr 10 22:02:33 archvdr kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Apr 10 22:02:33 archvdr kernel: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) Apr 10 22:02:33 archvdr kernel: ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) Apr 10 22:02:33 archvdr kernel: IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23 Apr 10 22:02:33 archvdr kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) Apr 10 22:02:33 archvdr kernel: ACPI: IRQ0 used by override. Apr 10 22:02:33 archvdr kernel: ACPI: IRQ2 used by override. Apr 10 22:02:33 archvdr kernel: ACPI: IRQ9 used by override. Apr 10 22:02:33 archvdr kernel: Using ACPI (MADT) for SMP configuration information Apr 10 22:02:33 archvdr kernel: ACPI: HPET id: 0x8086af01 base: 0xfed00000 Apr 10 22:02:33 archvdr kernel: smpboot: Allowing 1 CPUs, 0 hotplug CPUs Apr 10 22:02:33 archvdr kernel: nr_irqs_gsi: 40 Apr 10 22:02:33 archvdr kernel: PM: Registered nosave memory: 000000000009f000 - 00000000000a0000 Apr 10 22:02:33 archvdr kernel: PM: Registered nosave memory: 00000000000a0000 - 00000000000dc000 Apr 10 22:02:33 archvdr kernel: PM: Registered nosave memory: 00000000000dc000 - 0000000000100000 Apr 10 22:02:33 archvdr kernel: PM: Registered nosave memory: 000000003fef0000 - 000000003feff000 Apr 10 22:02:33 archvdr kernel: PM: Registered nosave memory: 000000003feff000 - 000000003ff00000 Apr 10 22:02:33 archvdr kernel: e820: [mem 0x40000000-0xdfffffff] available for PCI devices Apr 10 22:02:33 archvdr kernel: Booting paravirtualized kernel on bare hardware Apr 10 22:02:33 archvdr kernel: setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1 nr_node_ids:1 Apr 10 22:02:33 archvdr kernel: PERCPU: Embedded 28 pages/cpu @ffff88003fc00000 s85184 r8192 d21312 u2097152 Apr 10 22:02:33 archvdr kernel: pcpu-alloc: s85184 r8192 d21312 u2097152 alloc=1*2097152 Apr 10 22:02:33 archvdr kernel: pcpu-alloc: [0] 0 Apr 10 22:02:33 archvdr kernel: Built 1 zonelists in Node order, mobility grouping on. Total pages: 257913 Apr 10 22:02:33 archvdr kernel: Policy zone: DMA32 Apr 10 22:02:33 archvdr kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=276b5bb9-90e3-47a7-9ccc-e6734aff8a23 ro quiet Apr 10 22:02:33 archvdr kernel: PID hash table entries: 4096 (order: 3, 32768 bytes) Apr 10 22:02:33 archvdr kernel: __ex_table already sorted, skipping sort Apr 10 22:02:33 archvdr kernel: xsave: enabled xstate_bv 0x7, cntxt size 0x340 Apr 10 22:02:33 archvdr kernel: Checking aperture... Apr 10 22:02:33 archvdr kernel: No AGP bridge found Apr 10 22:02:33 archvdr kernel: Calgary: detecting Calgary via BIOS EBDA area Apr 10 22:02:33 archvdr kernel: Calgary: Unable to locate Rio Grande table in EBDA - bailing! Apr 10 22:02:33 archvdr kernel: Memory: 1017372k/1048576k available (4908k kernel code, 516k absent, 30688k reserved, 4024k data, 820k init) Apr 10 22:02:33 archvdr kernel: SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Apr 10 22:02:33 archvdr kernel: Preemptible hierarchical RCU implementation. Apr 10 22:02:33 archvdr kernel: RCU dyntick-idle grace-period acceleration is enabled. Apr 10 22:02:33 archvdr kernel: Dump stacks of tasks blocking RCU-preempt GP. Apr 10 22:02:33 archvdr kernel: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1. Apr 10 22:02:33 archvdr kernel: NR_IRQS:4352 nr_irqs:256 16 Apr 10 22:02:33 archvdr kernel: Extended CMOS year: 2000 Apr 10 22:02:33 archvdr kernel: Console: colour dummy device 80x25 Apr 10 22:02:33 archvdr kernel: console [tty0] enabled Apr 10 22:02:33 archvdr kernel: allocated 4194304 bytes of page_cgroup Apr 10 22:02:33 archvdr kernel: please try 'cgroup_disable=memory' option if you don't want memory cgroups Apr 10 22:02:33 archvdr kernel: hpet clockevent registered Apr 10 22:02:33 archvdr kernel: TSC freq read from hypervisor : 3200.022 MHz Apr 10 22:02:33 archvdr kernel: tsc: Detected 3200.022 MHz processor Apr 10 22:02:33 archvdr kernel: Calibrating delay loop (skipped) preset value.. 6402.71 BogoMIPS (lpj=10666740) Apr 10 22:02:33 archvdr kernel: pid_max: default: 32768 minimum: 301 Apr 10 22:02:33 archvdr kernel: Security Framework initialized Apr 10 22:02:33 archvdr kernel: AppArmor: AppArmor disabled by boot time parameter Apr 10 22:02:33 archvdr kernel: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Apr 10 22:02:33 archvdr kernel: Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Apr 10 22:02:33 archvdr kernel: Mount-cache hash table entries: 256 Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys cpuacct Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys memory Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys devices Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys freezer Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys net_cls Apr 10 22:02:33 archvdr kernel: Initializing cgroup subsys blkio Apr 10 22:02:33 archvdr kernel: Disabled fast string operations Apr 10 22:02:33 archvdr kernel: CPU: Physical Processor ID: 0 Apr 10 22:02:33 archvdr kernel: [117B blob data] Apr 10 22:02:33 archvdr kernel: mce: CPU supports 0 MCE banks Apr 10 22:02:33 archvdr kernel: [117B blob data] Apr 10 22:02:33 archvdr kernel: Freeing SMP alternatives: 20k freed Apr 10 22:02:33 archvdr kernel: ACPI: Core revision 20121018 Apr 10 22:02:33 archvdr kernel: ftrace: allocating 19310 entries in 76 pages Apr 10 22:02:33 archvdr kernel: ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 Apr 10 22:02:33 archvdr kernel: smpboot: CPU0: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (fam: 06, model: 3a, stepping: 09) Apr 10 22:02:33 archvdr kernel: Performance Events: 16-deep LBR, IvyBridge events, core PMU driver. Apr 10 22:02:33 archvdr kernel: perf_event_intel: CPUID marked event: 'cpu cycles' unavailable Apr 10 22:02:33 archvdr kernel: perf_event_intel: CPUID marked event: 'instructions' unavailable Apr 10 22:02:33 archvdr kernel: perf_event_intel: CPUID marked event: 'bus cycles' unavailable Apr 10 22:02:33 archvdr kernel: perf_event_intel: CPUID marked event: 'cache references' unavailable Apr 10 22:02:33 archvdr kernel: perf_event_intel: CPUID marked event: 'cache misses' unavailable Apr 10 22:02:33 archvdr kernel: perf_event_intel: CPUID marked event: 'branch instructions' unavailable Apr 10 22:02:33 archvdr kernel: perf_event_intel: CPUID marked event: 'branch misses' unavailable Apr 10 22:02:33 archvdr kernel: ... version: 1 Apr 10 22:02:33 archvdr kernel: ... bit width: 48 Apr 10 22:02:33 archvdr kernel: ... generic registers: 8 Apr 10 22:02:33 archvdr kernel: ... value mask: 0000ffffffffffff Apr 10 22:02:33 archvdr kernel: ... max period: 000000007fffffff Apr 10 22:02:33 archvdr kernel: ... fixed-purpose events: 0 Apr 10 22:02:33 archvdr kernel: ... event mask: 00000000000000ff Apr 10 22:02:33 archvdr kernel: Brought up 1 CPUs Apr 10 22:02:33 archvdr kernel: smpboot: Total of 1 processors activated (6402.71 BogoMIPS) Apr 10 22:02:33 archvdr kernel: x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106 Apr 10 22:02:33 archvdr kernel: NMI watchdog: disabled (cpu0): hardware events not enabled Apr 10 22:02:33 archvdr kernel: devtmpfs: initialized Apr 10 22:02:33 archvdr kernel: PM: Registering ACPI NVS region [mem 0x3feff000-0x3fefffff](4096 bytes) Apr 10 22:02:33 archvdr kernel: RTC time: 20:02:32, date: 04/10/13 Apr 10 22:02:33 archvdr kernel: NET: Registered protocol family 16 Apr 10 22:02:33 archvdr kernel: ACPI: bus type pci registered Apr 10 22:02:33 archvdr kernel: PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff](base 0xe0000000) Apr 10 22:02:33 archvdr kernel: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820 Apr 10 22:02:33 archvdr kernel: PCI: Using configuration type 1 for base access Apr 10 22:02:33 archvdr kernel: bio: create slab at 0 Apr 10 22:02:33 archvdr kernel: ACPI: Added _OSI(Module Device) Apr 10 22:02:33 archvdr kernel: ACPI: Added _OSI(Processor Device) Apr 10 22:02:33 archvdr kernel: ACPI: Added _OSI(3.0 _SCP Extensions) Apr 10 22:02:33 archvdr kernel: ACPI: Added _OSI(Processor Aggregator Device) Apr 10 22:02:33 archvdr kernel: ACPI: EC: Look up EC in DSDT Apr 10 22:02:33 archvdr kernel: [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored Apr 10 22:02:33 archvdr kernel: ACPI: Interpreter enabled Apr 10 22:02:33 archvdr kernel: ACPI: (supports S0 S1 S4 S5) Apr 10 22:02:33 archvdr kernel: ACPI: Using IOAPIC for interrupt routing Apr 10 22:02:33 archvdr kernel: ACPI: No dock devices found. Apr 10 22:02:33 archvdr kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug Apr 10 22:02:33 archvdr kernel: ACPI: PCI Root Bridge [PCI0](domain 0000 [bus 00-ff]) Apr 10 22:02:33 archvdr kernel: ACPI: PCI Interrupt Routing Table [SB.PCI0._PRT] Apr 10 22:02:33 archvdr kernel: pci_root PNP0A03:00: Requesting ACPI _OSC control (0x1d) Apr 10 22:02:33 archvdr kernel: pci_root PNP0A03:00: ACPI _OSC control (0x15) granted Apr 10 22:02:33 archvdr kernel: PCI host bridge to bus 0000:00 Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [bus 00-ff] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [mem 0x000cc000-0x000cffff] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [mem 0x40000000-0xfebfffff] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] Apr 10 22:02:33 archvdr kernel: pci_bus 0000:00: root bus resource [io 0x0d00-0xfeff] Apr 10 22:02:33 archvdr kernel: pci 0000:00:00.0: [8086:7190] type 00 class 0x060000 Apr 10 22:02:33 archvdr kernel: pci 0000:00:01.0: [8086:7191] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.0: [8086:7110] type 00 class 0x060100 Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.1: [8086:7111] type 00 class 0x01018a Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.1: reg 20: [io 0x10c0-0x10cf] Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.3: [8086:7113] type 00 class 0x068000 Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.3: quirk: [io 0x1000-0x103f] claimed by PIIX4 ACPI Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.3: quirk: [io 0x1040-0x104f] claimed by PIIX4 SMB Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.7: [15ad:0740] type 00 class 0x088000 Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.7: reg 10: [io 0x1080-0x10bf] Apr 10 22:02:33 archvdr kernel: pci 0000:00:07.7: reg 14: [mem 0xd0000000-0xd0001fff 64bit] Apr 10 22:02:33 archvdr kernel: pci 0000:00:0f.0: [15ad:0405] type 00 class 0x030000 Apr 10 22:02:33 archvdr kernel: pci 0000:00:0f.0: reg 10: [io 0x10d0-0x10df] Apr 10 22:02:33 archvdr kernel: pci 0000:00:0f.0: reg 14: [mem 0xd8000000-0xdbffffff pref] Apr 10 22:02:33 archvdr kernel: pci 0000:00:0f.0: reg 18: [mem 0xd0800000-0xd0ffffff] Apr 10 22:02:33 archvdr kernel: pci 0000:00:0f.0: reg 30: [mem 0x00000000-0x00007fff pref] Apr 10 22:02:33 archvdr kernel: pci 0000:00:11.0: [15ad:0790] type 01 class 0x060401 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.0: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.0: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.1: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.1: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.2: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.2: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.3: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.3: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.4: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.4: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.5: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.5: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.6: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.6: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.7: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:15.7: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:16.0: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:16.0: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:16.1: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:33 archvdr kernel: pci 0000:00:16.1: PME# supported from D0 D3hot D3cold Apr 10 22:02:33 archvdr kernel: pci 0000:00:16.2: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: [15ad:07a0] type 01 class 0x060400 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:00:01.0: PCI bridge to [bus 01] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: PCI bridge to [bus 02](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [io 0x2000-0x3fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0xd1900000-0xd23fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0xdc400000-0xdc9fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0x000a0000-0x000bffff](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0x000cc000-0x000cffff](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0x000d0000-0x000d3fff](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0x000d4000-0x000d7fff](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0x000d8000-0x000dbfff](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0x40000000-0xfebfffff](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [io 0x0000-0x0cf7](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [io 0x0d00-0xfeff](subtractive decode) Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: [15ad:07b0] type 00 class 0x020000 Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: reg 10: [mem 0xd2404000-0xd2404fff] Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: reg 14: [mem 0xd2403000-0xd2403fff] Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: reg 18: [mem 0xd2400000-0xd2401fff] Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: reg 1c: [io 0x4000-0x400f] Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: reg 30: [mem 0x00000000-0x0000ffff pref] Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: supports D1 D2 Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: PCI bridge to [bus 03] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: bridge window [io 0x4000-0x4fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: bridge window [mem 0xd2400000-0xd24fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: PCI bridge to [bus 04] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: bridge window [io 0x8000-0x8fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: bridge window [mem 0xd2800000-0xd28fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: bridge window [mem 0xd4800000-0xd48fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: PCI bridge to [bus 05] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: bridge window [io 0xc000-0xcfff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: bridge window [mem 0xd2c00000-0xd2cfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: bridge window [mem 0xdcb00000-0xdcbfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: PCI bridge to [bus 06] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: bridge window [mem 0xd3000000-0xd30fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: bridge window [mem 0xdcd00000-0xdcdfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: PCI bridge to [bus 07] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: bridge window [mem 0xd3400000-0xd34fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: bridge window [mem 0xdcf00000-0xdcffffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: PCI bridge to [bus 08] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: bridge window [mem 0xd3800000-0xd38fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: bridge window [mem 0xdd100000-0xdd1fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: PCI bridge to [bus 09] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: bridge window [mem 0xd3c00000-0xd3cfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: bridge window [mem 0xdd300000-0xdd3fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: PCI bridge to [bus 0a] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: bridge window [mem 0xd4000000-0xd40fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: bridge window [mem 0xdd500000-0xdd5fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:0b:00.0: [15ad:07c0] type 00 class 0x010700 Apr 10 22:02:34 archvdr kernel: pci 0000:0b:00.0: reg 10: [io 0x5008-0x500f] Apr 10 22:02:34 archvdr kernel: pci 0000:0b:00.0: reg 14: [mem 0xd2500000-0xd2507fff 64bit] Apr 10 22:02:34 archvdr kernel: pci 0000:0b:00.0: reg 30: [mem 0x00000000-0x0000ffff pref] Apr 10 22:02:34 archvdr kernel: pci 0000:0b:00.0: PME# supported from D0 D3hot D3cold Apr 10 22:02:34 archvdr kernel: pci 0000:0b:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: PCI bridge to [bus 0b] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: bridge window [io 0x5000-0x5fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: bridge window [mem 0xd2500000-0xd25fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: bridge window [mem 0xd4500000-0xd45fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: PCI bridge to [bus 0c] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: bridge window [io 0x9000-0x9fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: bridge window [mem 0xd2900000-0xd29fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: bridge window [mem 0xd4900000-0xd49fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: PCI bridge to [bus 0d] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: bridge window [io 0xd000-0xdfff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: bridge window [mem 0xd2d00000-0xd2dfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: bridge window [mem 0xd4b00000-0xd4bfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: PCI bridge to [bus 0e] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: bridge window [mem 0xd3100000-0xd31fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: bridge window [mem 0xd4d00000-0xd4dfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: PCI bridge to [bus 0f] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: bridge window [mem 0xd3500000-0xd35fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: bridge window [mem 0xd4f00000-0xd4ffffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: PCI bridge to [bus 10] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: bridge window [mem 0xd3900000-0xd39fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: bridge window [mem 0xd5100000-0xd51fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: PCI bridge to [bus 11] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: bridge window [mem 0xd3d00000-0xd3dfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: bridge window [mem 0xd5300000-0xd53fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: PCI bridge to [bus 12] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: bridge window [mem 0xd4100000-0xd41fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: bridge window [mem 0xd5500000-0xd55fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:13:00.0: [dd01:0003] type 00 class 0x048000 Apr 10 22:02:34 archvdr kernel: pci 0000:13:00.0: reg 10: [mem 0xd2600000-0xd260ffff 64bit] Apr 10 22:02:34 archvdr kernel: pci 0000:13:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: PCI bridge to [bus 13] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: bridge window [io 0x6000-0x6fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: bridge window [mem 0xd2600000-0xd26fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: bridge window [mem 0xd4600000-0xd46fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: PCI bridge to [bus 14] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: bridge window [io 0xa000-0xafff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: bridge window [mem 0xd2a00000-0xd2afffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: bridge window [mem 0xdca00000-0xdcafffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: PCI bridge to [bus 15] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: bridge window [io 0xe000-0xefff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: bridge window [mem 0xd2e00000-0xd2efffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: bridge window [mem 0xdcc00000-0xdccfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: PCI bridge to [bus 16] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: bridge window [mem 0xd3200000-0xd32fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: bridge window [mem 0xdce00000-0xdcefffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: PCI bridge to [bus 17] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: bridge window [mem 0xd3600000-0xd36fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: bridge window [mem 0xdd000000-0xdd0fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: PCI bridge to [bus 18] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: bridge window [mem 0xd3a00000-0xd3afffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: bridge window [mem 0xdd200000-0xdd2fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: PCI bridge to [bus 19] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: bridge window [mem 0xd3e00000-0xd3efffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: bridge window [mem 0xdd400000-0xdd4fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: PCI bridge to [bus 1a] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: bridge window [mem 0xd4200000-0xd42fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: bridge window [mem 0xdd600000-0xdd6fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: PCI bridge to [bus 1b] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: bridge window [io 0x7000-0x7fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: bridge window [mem 0xd2700000-0xd27fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: bridge window [mem 0xd4700000-0xd47fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: PCI bridge to [bus 1c] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: bridge window [io 0xb000-0xbfff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: bridge window [mem 0xd2b00000-0xd2bfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: bridge window [mem 0xd4a00000-0xd4afffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: PCI bridge to [bus 1d] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: bridge window [io 0xf000-0xffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: bridge window [mem 0xd2f00000-0xd2ffffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: bridge window [mem 0xd4c00000-0xd4cfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: PCI bridge to [bus 1e] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: bridge window [mem 0xd3300000-0xd33fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: bridge window [mem 0xd4e00000-0xd4efffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: PCI bridge to [bus 1f] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: bridge window [mem 0xd3700000-0xd37fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: bridge window [mem 0xd5000000-0xd50fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: PCI bridge to [bus 20] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: bridge window [mem 0xd3b00000-0xd3bfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: bridge window [mem 0xd5200000-0xd52fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: PCI bridge to [bus 21] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: bridge window [mem 0xd3f00000-0xd3ffffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: bridge window [mem 0xd5400000-0xd54fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: PCI bridge to [bus 22] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: bridge window [mem 0xd4300000-0xd43fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: bridge window [mem 0xd5600000-0xd56fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: ACPI: PCI Interrupt Link [LNKA](IRQs 3 4 5 6 7 9 10 11 14 15) Apr 10 22:02:34 archvdr kernel: ACPI: PCI Interrupt Link [LNKB](IRQs 3 4 5 6 7 9 10 11 14 15) 0, disabled. Apr 10 22:02:34 archvdr kernel: ACPI: PCI Interrupt Link [LNKC](IRQs 3 4 5 6 7 9 10 11 14 15) Apr 10 22:02:34 archvdr kernel: ACPI: PCI Interrupt Link [LNKD](IRQs 3 4 5 6 7 9 10 11 14 15) Apr 10 22:02:34 archvdr kernel: vgaarb: device added: PCI:0000:00:0f.0,decodes=io+mem,owns=io+mem,locks=none Apr 10 22:02:34 archvdr kernel: vgaarb: loaded Apr 10 22:02:34 archvdr kernel: vgaarb: bridge control possible 0000:00:0f.0 Apr 10 22:02:34 archvdr kernel: PCI: Using ACPI for IRQ routing Apr 10 22:02:34 archvdr kernel: PCI: pci_cache_line_size set to 64 bytes Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: no compatible bridge window for [io 0xf000-0xffff] Apr 10 22:02:34 archvdr kernel: e820: reserve RAM buffer [mem 0x0009f800-0x0009ffff] Apr 10 22:02:34 archvdr kernel: e820: reserve RAM buffer [mem 0x3fef0000-0x3fffffff] Apr 10 22:02:34 archvdr kernel: NetLabel: Initializing Apr 10 22:02:34 archvdr kernel: NetLabel: domain hash size = 128 Apr 10 22:02:34 archvdr kernel: NetLabel: protocols = UNLABELED CIPSOv4 Apr 10 22:02:34 archvdr kernel: NetLabel: unlabeled traffic allowed by default Apr 10 22:02:34 archvdr kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 Apr 10 22:02:34 archvdr kernel: hpet0: 16 comparators, 64-bit 14.318180 MHz counter Apr 10 22:02:34 archvdr kernel: Switching to clocksource hpet Apr 10 22:02:34 archvdr kernel: pnp: PnP ACPI init Apr 10 22:02:34 archvdr kernel: ACPI: bus type pnp registered Apr 10 22:02:34 archvdr kernel: system 00:00: [io 0x1000-0x103f] has been reserved Apr 10 22:02:34 archvdr kernel: system 00:00: [io 0x1040-0x104f] has been reserved Apr 10 22:02:34 archvdr kernel: system 00:00: [io 0x0cf0-0x0cf1] has been reserved Apr 10 22:02:34 archvdr kernel: system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) Apr 10 22:02:34 archvdr kernel: pnp 00:01: [dma 4] Apr 10 22:02:34 archvdr kernel: pnp 00:01: Plug and Play ACPI device, IDs PNP0200 (active) Apr 10 22:02:34 archvdr kernel: pnp 00:02: Plug and Play ACPI device, IDs PNP0001 (active) Apr 10 22:02:34 archvdr kernel: pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active) Apr 10 22:02:34 archvdr kernel: pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active) Apr 10 22:02:34 archvdr kernel: pnp 00:05: Plug and Play ACPI device, IDs PNP0303 (active) Apr 10 22:02:34 archvdr kernel: pnp 00:06: Plug and Play ACPI device, IDs PNP0f13 (active) Apr 10 22:02:34 archvdr kernel: system 00:07: [mem 0xfed00000-0xfed003ff] has been reserved Apr 10 22:02:34 archvdr kernel: system 00:07: Plug and Play ACPI device, IDs PNP0103 PNP0c01 (active) Apr 10 22:02:34 archvdr kernel: system 00:08: [io 0x1060-0x107f] has been reserved Apr 10 22:02:34 archvdr kernel: system 00:08: [mem 0xe0000000-0xefffffff] has been reserved Apr 10 22:02:34 archvdr kernel: system 00:08: [mem 0xd0200000-0xd03fffff] has been reserved Apr 10 22:02:34 archvdr kernel: system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active) Apr 10 22:02:34 archvdr kernel: pnp: PnP ACPI: found 9 devices Apr 10 22:02:34 archvdr kernel: ACPI: ACPI bus type pnp unregistered Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: bridge window [io 0x1000-0x0fff] to [bus 06] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: bridge window [io 0x1000-0x0fff] to [bus 07] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: bridge window [io 0x1000-0x0fff] to [bus 08] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: bridge window [io 0x1000-0x0fff] to [bus 09] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: bridge window [io 0x1000-0x0fff] to [bus 0a] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: bridge window [io 0x1000-0x0fff] to [bus 0e] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: bridge window [io 0x1000-0x0fff] to [bus 0f] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: bridge window [io 0x1000-0x0fff] to [bus 10] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: bridge window [io 0x1000-0x0fff] to [bus 11] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: bridge window [io 0x1000-0x0fff] to [bus 12] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: bridge window [io 0x1000-0x0fff] to [bus 16] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: bridge window [io 0x1000-0x0fff] to [bus 17] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: bridge window [io 0x1000-0x0fff] to [bus 18] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: bridge window [io 0x1000-0x0fff] to [bus 19] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: bridge window [io 0x1000-0x0fff] to [bus 1a] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: bridge window [io 0x1000-0x0fff] to [bus 1d] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: bridge window [io 0x1000-0x0fff] to [bus 1e] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: bridge window [io 0x1000-0x0fff] to [bus 1f] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: bridge window [io 0x1000-0x0fff] to [bus 20] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: bridge window [io 0x1000-0x0fff] to [bus 21] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: bridge window [io 0x1000-0x0fff] to [bus 22] add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 Apr 10 22:02:34 archvdr kernel: pci 0000:00:0f.0: BAR 6: assigned [mem 0x40000000-0x40007fff pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: BAR 13: can't assign io (size 0x1000) Apr 10 22:02:34 archvdr kernel: pci 0000:00:01.0: PCI bridge to [bus 01] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: PCI bridge to [bus 02] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [io 0x2000-0x3fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0xd1900000-0xd23fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:11.0: bridge window [mem 0xdc400000-0xdc9fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:03:00.0: BAR 6: assigned [mem 0xd4400000-0xd440ffff pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: PCI bridge to [bus 03] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: bridge window [io 0x4000-0x4fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: bridge window [mem 0xd2400000-0xd24fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: PCI bridge to [bus 04] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: bridge window [io 0x8000-0x8fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: bridge window [mem 0xd2800000-0xd28fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.1: bridge window [mem 0xd4800000-0xd48fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: PCI bridge to [bus 05] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: bridge window [io 0xc000-0xcfff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: bridge window [mem 0xd2c00000-0xd2cfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.2: bridge window [mem 0xdcb00000-0xdcbfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: PCI bridge to [bus 06] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: bridge window [mem 0xd3000000-0xd30fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.3: bridge window [mem 0xdcd00000-0xdcdfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: PCI bridge to [bus 07] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: bridge window [mem 0xd3400000-0xd34fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.4: bridge window [mem 0xdcf00000-0xdcffffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: PCI bridge to [bus 08] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: bridge window [mem 0xd3800000-0xd38fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.5: bridge window [mem 0xdd100000-0xdd1fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: PCI bridge to [bus 09] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: bridge window [mem 0xd3c00000-0xd3cfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.6: bridge window [mem 0xdd300000-0xdd3fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: PCI bridge to [bus 0a] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: bridge window [mem 0xd4000000-0xd40fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:15.7: bridge window [mem 0xdd500000-0xdd5fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:0b:00.0: BAR 6: assigned [mem 0xd4500000-0xd450ffff pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: PCI bridge to [bus 0b] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: bridge window [io 0x5000-0x5fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: bridge window [mem 0xd2500000-0xd25fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.0: bridge window [mem 0xd4500000-0xd45fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: PCI bridge to [bus 0c] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: bridge window [io 0x9000-0x9fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: bridge window [mem 0xd2900000-0xd29fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.1: bridge window [mem 0xd4900000-0xd49fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: PCI bridge to [bus 0d] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: bridge window [io 0xd000-0xdfff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: bridge window [mem 0xd2d00000-0xd2dfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.2: bridge window [mem 0xd4b00000-0xd4bfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: PCI bridge to [bus 0e] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: bridge window [mem 0xd3100000-0xd31fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.3: bridge window [mem 0xd4d00000-0xd4dfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: PCI bridge to [bus 0f] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: bridge window [mem 0xd3500000-0xd35fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.4: bridge window [mem 0xd4f00000-0xd4ffffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: PCI bridge to [bus 10] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: bridge window [mem 0xd3900000-0xd39fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.5: bridge window [mem 0xd5100000-0xd51fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: PCI bridge to [bus 11] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: bridge window [mem 0xd3d00000-0xd3dfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.6: bridge window [mem 0xd5300000-0xd53fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: PCI bridge to [bus 12] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: bridge window [mem 0xd4100000-0xd41fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:16.7: bridge window [mem 0xd5500000-0xd55fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: PCI bridge to [bus 13] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: bridge window [io 0x6000-0x6fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: bridge window [mem 0xd2600000-0xd26fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.0: bridge window [mem 0xd4600000-0xd46fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: PCI bridge to [bus 14] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: bridge window [io 0xa000-0xafff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: bridge window [mem 0xd2a00000-0xd2afffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.1: bridge window [mem 0xdca00000-0xdcafffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: PCI bridge to [bus 15] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: bridge window [io 0xe000-0xefff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: bridge window [mem 0xd2e00000-0xd2efffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.2: bridge window [mem 0xdcc00000-0xdccfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: PCI bridge to [bus 16] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: bridge window [mem 0xd3200000-0xd32fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.3: bridge window [mem 0xdce00000-0xdcefffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: PCI bridge to [bus 17] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: bridge window [mem 0xd3600000-0xd36fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.4: bridge window [mem 0xdd000000-0xdd0fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: PCI bridge to [bus 18] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: bridge window [mem 0xd3a00000-0xd3afffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.5: bridge window [mem 0xdd200000-0xdd2fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: PCI bridge to [bus 19] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: bridge window [mem 0xd3e00000-0xd3efffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.6: bridge window [mem 0xdd400000-0xdd4fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: PCI bridge to [bus 1a] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: bridge window [mem 0xd4200000-0xd42fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:17.7: bridge window [mem 0xdd600000-0xdd6fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: PCI bridge to [bus 1b] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: bridge window [io 0x7000-0x7fff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: bridge window [mem 0xd2700000-0xd27fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.0: bridge window [mem 0xd4700000-0xd47fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: PCI bridge to [bus 1c] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: bridge window [io 0xb000-0xbfff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: bridge window [mem 0xd2b00000-0xd2bfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.1: bridge window [mem 0xd4a00000-0xd4afffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: PCI bridge to [bus 1d] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: bridge window [mem 0xd2f00000-0xd2ffffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.2: bridge window [mem 0xd4c00000-0xd4cfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: PCI bridge to [bus 1e] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: bridge window [mem 0xd3300000-0xd33fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.3: bridge window [mem 0xd4e00000-0xd4efffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: PCI bridge to [bus 1f] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: bridge window [mem 0xd3700000-0xd37fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.4: bridge window [mem 0xd5000000-0xd50fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: PCI bridge to [bus 20] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: bridge window [mem 0xd3b00000-0xd3bfffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.5: bridge window [mem 0xd5200000-0xd52fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: PCI bridge to [bus 21] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: bridge window [mem 0xd3f00000-0xd3ffffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.6: bridge window [mem 0xd5400000-0xd54fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: PCI bridge to [bus 22] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: bridge window [mem 0xd4300000-0xd43fffff] Apr 10 22:02:34 archvdr kernel: pci 0000:00:18.7: bridge window [mem 0xd5600000-0xd56fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci 0000:00:01.0: setting latency timer to 64 Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 4 [mem 0x000a0000-0x000bffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 5 [mem 0x000cc000-0x000cffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 6 [mem 0x000d0000-0x000d3fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 7 [mem 0x000d4000-0x000d7fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 8 [mem 0x000d8000-0x000dbfff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 9 [mem 0x40000000-0xfebfffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 10 [io 0x0000-0x0cf7] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:00: resource 11 [io 0x0d00-0xfeff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 0 [io 0x2000-0x3fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 1 [mem 0xd1900000-0xd23fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 2 [mem 0xdc400000-0xdc9fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 4 [mem 0x000a0000-0x000bffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 5 [mem 0x000cc000-0x000cffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 6 [mem 0x000d0000-0x000d3fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 7 [mem 0x000d4000-0x000d7fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 8 [mem 0x000d8000-0x000dbfff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 9 [mem 0x40000000-0xfebfffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 10 [io 0x0000-0x0cf7] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:02: resource 11 [io 0x0d00-0xfeff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:03: resource 0 [io 0x4000-0x4fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:03: resource 1 [mem 0xd2400000-0xd24fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:03: resource 2 [mem 0xd4400000-0xd44fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:04: resource 0 [io 0x8000-0x8fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:04: resource 1 [mem 0xd2800000-0xd28fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:04: resource 2 [mem 0xd4800000-0xd48fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:05: resource 0 [io 0xc000-0xcfff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:05: resource 1 [mem 0xd2c00000-0xd2cfffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:05: resource 2 [mem 0xdcb00000-0xdcbfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:06: resource 1 [mem 0xd3000000-0xd30fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:06: resource 2 [mem 0xdcd00000-0xdcdfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:07: resource 1 [mem 0xd3400000-0xd34fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:07: resource 2 [mem 0xdcf00000-0xdcffffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:08: resource 1 [mem 0xd3800000-0xd38fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:08: resource 2 [mem 0xdd100000-0xdd1fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:09: resource 1 [mem 0xd3c00000-0xd3cfffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:09: resource 2 [mem 0xdd300000-0xdd3fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0a: resource 1 [mem 0xd4000000-0xd40fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0a: resource 2 [mem 0xdd500000-0xdd5fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0b: resource 0 [io 0x5000-0x5fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0b: resource 1 [mem 0xd2500000-0xd25fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0b: resource 2 [mem 0xd4500000-0xd45fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0c: resource 0 [io 0x9000-0x9fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0c: resource 1 [mem 0xd2900000-0xd29fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0c: resource 2 [mem 0xd4900000-0xd49fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0d: resource 0 [io 0xd000-0xdfff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0d: resource 1 [mem 0xd2d00000-0xd2dfffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0d: resource 2 [mem 0xd4b00000-0xd4bfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0e: resource 1 [mem 0xd3100000-0xd31fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0e: resource 2 [mem 0xd4d00000-0xd4dfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0f: resource 1 [mem 0xd3500000-0xd35fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:0f: resource 2 [mem 0xd4f00000-0xd4ffffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:10: resource 1 [mem 0xd3900000-0xd39fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:10: resource 2 [mem 0xd5100000-0xd51fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:11: resource 1 [mem 0xd3d00000-0xd3dfffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:11: resource 2 [mem 0xd5300000-0xd53fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:12: resource 1 [mem 0xd4100000-0xd41fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:12: resource 2 [mem 0xd5500000-0xd55fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:13: resource 0 [io 0x6000-0x6fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:13: resource 1 [mem 0xd2600000-0xd26fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:13: resource 2 [mem 0xd4600000-0xd46fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:14: resource 0 [io 0xa000-0xafff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:14: resource 1 [mem 0xd2a00000-0xd2afffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:14: resource 2 [mem 0xdca00000-0xdcafffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:15: resource 0 [io 0xe000-0xefff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:15: resource 1 [mem 0xd2e00000-0xd2efffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:15: resource 2 [mem 0xdcc00000-0xdccfffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:16: resource 1 [mem 0xd3200000-0xd32fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:16: resource 2 [mem 0xdce00000-0xdcefffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:17: resource 1 [mem 0xd3600000-0xd36fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:17: resource 2 [mem 0xdd000000-0xdd0fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:18: resource 1 [mem 0xd3a00000-0xd3afffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:18: resource 2 [mem 0xdd200000-0xdd2fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:19: resource 1 [mem 0xd3e00000-0xd3efffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:19: resource 2 [mem 0xdd400000-0xdd4fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1a: resource 1 [mem 0xd4200000-0xd42fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1a: resource 2 [mem 0xdd600000-0xdd6fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1b: resource 0 [io 0x7000-0x7fff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1b: resource 1 [mem 0xd2700000-0xd27fffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1b: resource 2 [mem 0xd4700000-0xd47fffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1c: resource 0 [io 0xb000-0xbfff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1c: resource 1 [mem 0xd2b00000-0xd2bfffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1c: resource 2 [mem 0xd4a00000-0xd4afffff 64bit pref] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1d: resource 1 [mem 0xd2f00000-0xd2ffffff] Apr 10 22:02:34 archvdr kernel: pci_bus 0000:1d: resource 2 [mem 0xd4c00000-0xd4cfffff 64

[seahawk1986]

Eine Möglichkeit den Start des VDR zu verzögern, bis beide Adapter bereit sind ist über systemd.devices zu gehen (wenn man dynamite nicht nutzen will): udev-Regel /etc/udev/rules.d/99-dvbdevices.rules: SUBSYSTEM=="dvb", TAG+="systemd"

vdr.service:

[Unit]
Description=Video Disk Recorder
Wants=dev-dvb-adapter0-frontend0.device
Wants=dev-dvb-adapter0-demux0.device
Wants=dev-dvb-adapter0-dvr0.device
Wants=dev-dvb-adapter0-net0.device
After=dev-dvb-adapter0-frontend0.device
After=dev-dvb-adapter0-demux0.device
After=dev-dvb-adapter0-dvr0.device
After=dev-dvb-adapter0-net0.device
Wants=dev-dvb-adapter1-frontend0.device
Wants=dev-dvb-adapter1-demux0.device
Wants=dev-dvb-adapter1-dvr0.device
Wants=dev-dvb-adapter1-net0.device
After=dev-dvb-adapter1-frontend0.device
After=dev-dvb-adapter1-demux0.device
After=dev-dvb-adapter1-dvr0.device
After=dev-dvb-adapter1-net0.device

[Service]
ExecStart=/usr/bin/runvdr
KillMode=process

[Install]
WantedBy=multi-user.target

[CReimer]

Ich schaue später mal drüber. Ihr baut euch aber auch immer die exotischsten Systeme zusammen :smile: Dynamite wird es aber sicherlich nicht geben.

[HTPC-Schrauber]

Was ist so exotisch? Das der VDR in einer VM läuft? Ich glaube nicht, das die CineCT sich ohne VM schneller initialisieren würde. Sie ist per Passthrough direkt an die VM durchgereicht.

Abgesehen davon scheint es sich nur um Millisekunden zu handeln.

Ich werde die Lösung mittels udev-Regel heute abend versuchen.

[CReimer]

seahawk1986: Fällt dir eine Lösung ein, die unabhängig davon ist, wie viele Tuner im System sind? Deine Änderung an der vdr.service Datei geht hängt ja davon ab, dass nur zwei Tuner im System stecken.

[seahawk1986]

Ehrlich gesagt nicht, solange man nicht festlegt wie viele Tuner insgesamt erwartet werden. Ich könnte mir vorstellen, dass man einen allgemeineren Systemd-Service anlegt, der dann die Nummer der Karte als Argument bekommt (ungetestet): /etc/systemd/system/dvb-check@.service

[Unit]
Before=vdr.service
Description=Wait for dvb-tuners
Wants=dev-dvb-adapter%i-frontend0.device
Wants=dev-dvb-adapter%i-demux0.device
Wants=dev-dvb-adapter%i-dvr0.device
Wants=dev-dvb-adapter%i-net0.device
After=dev-dvb-adapter%i-frontend0.device
After=dev-dvb-adapter%i-demux0.device
After=dev-dvb-adapter%i-dvr0.device
After=dev-dvb-adapter%i-net0.device
JobTimeoutSec=120

[Service]
Type=simple
ExecStart=logger -t "Check for dvb-card" "adapter %i ready"

[Install]
WantedBy=multi-user.target

Und für jeden Tuner X dann systemctl enable dvb-waiter@X.service So etwas kann man dann ggf. automatisiert aufrufen (vor dem Shutdown wäre eine Möglichkeit), aber dann hat man Probleme sobald man die Zahl der DVB-Karten ändert.

Dynamite will ich arch4vdr auch gar nicht aufdrängen, da es z.B. mit dvbapi immer noch nicht funktioniert. IMHO ist es aber der praktischere Ansatz wenn der VDR dynamisch Geräte zur Nutzung heranziehen oder freigeben kann (aber die Diskussion gab es ja schon oft ;))

[HTPC-Schrauber]

Ich hatte bereits daran gedacht, das Warten auf die DVB-Devices in der runvdr zu machen. Das wäre auch eine Möglichkeit. Da ist man in der Logik auch frei. So könnte man auch eine Art max-wait implementieren, wenn zwar z.B. 4 Devices erwartet werden, aber innerhalb einer gewissen Zeit nur zwei oder drei bereit sind. Z.B. weil eine Karte aus dem Rechner entfernt wurde.

[olebowle]

Ich denke die Herangehensweise von seahawk1986 mit dem zu übergebenden Parameter ist die flexibelste. Allerdings würde ich das direkt in die vdr.service packen. Weiterhin wird in der Fedora Wiki empfohlen auf Wants/Requires zu verzichten und lieber nur After zu verwenden. Im Falle des Wartens auf Hardware ist das sicherlich auch kein Problem. Weiterhin würde ich nur auf das Device mit der höchsten Nummer warten. Dann ist ja garantiert, dass die anderen schon da sind. Ich denke es reicht auch nur auf das frontend0 zu warten und nicht auf das ganze andere Zeugs. Was meint ihr dazu?

Demzufolge wär mein Vorschlag:

[Unit]
Description=Video Disk Recorder
After=lirc.service
After=eventlircd.service
After=oscam.service
After=sundtek.service
After=dev-dvb-adapter%i-frontend0.device

[Service]
ExecStart=/usr/bin/runvdr
KillMode=process

[Install]
WantedBy=multi-user.target

BTW: Ich hab eventlircd.service anstatt von lirc.service am laufen. Könntest du das auch noch als After hinzufügen? Was passiert eigentlich wenn ich oscam und sundtek nicht installiert hab. Ignoriert es das dann einfach?

[seahawk1986]

Es reicht meiner Erfahrung nach nicht aus nur auf frontend0 zu warten, der VDR und auch oscam/dvbapi nutzen neben dem frontend0 auch andere Geräte des Adapters, die normalerweise erst etwas später dazukommen. Ich weiß nicht, ob das net0 Gerät da immer das letzte ist oder ob das nur bei meiner DVB-Karte der Fall ist.

Die Karten müssen ja auch nicht zwangsläufig in der Reihenfolge, in der sie initialisiert werden nummeriert werden, bei vielen Treibern kann man durchaus bestimmte Nummern für Karten mit einem bestimmten Treiber vorgeben (hier hätte man also wieder eine implizite Vorgabe, statt eine explizite Konfiguration).

Das mit dem %i, das ja ein vdr@.service benötigt ist dem Anwender vermutlich auch nicht einfach zu vermitteln, dann muss man jedes mal wenn sich die Kartenzahl ändert den alten vdr@X.service deaktiveren und einen neuen aktivieren (und wissen was die erwartete letzte Adapternummer ist)...

[seahawk1986]

Zum BTW: systemd hinterlässt eine Logmeldung, wenn angegebene Services nicht existieren und macht normal weiter ohne darauf zu Warten. Eine eventlircd.service habe ich auch, aber da wäre eine Weiche entweder lircd.service oder eventlircd.service IMHO besser (wobei der VDR ja auch schon vor den beiden starten kann, der verbindet sich ja nach ein paar Sekunden wieder mit dem Socket, wenn er ihn nicht erreichen kann). Generell denke ich dass es kein Problem ist seine eigenen *.service-Dateien zu pflegen, systemd trennt hier ja schön zwischen den Dateien aus den Paketen und benutzerdefinierten Units.

[olebowle]

Also beim mir kommt das frontend als letztes hoch. Die Differenz liegt allerdings nur im 1-2 stelligen Milisekundenbereich. Bei dir ist es scheinbar anders, man kann es also nicht einfach so annehmen. Zum Vermitteln der User bezüglich der Parameter in den service Dateien denke ich, dass Arch Benutzer kompetent genug sein sollten das hinzu bekommen oder zumindest wissen sollten, wo man es nachlesen kann. Vielleicht könnte man darauf auch in der README hinweisen oder noch besser bei der Installation von runvdr-extrem. Aber im Grunde hab ich absolut nix gegen ein separates vdr.service in /etc. Läuft im Moment bei mir ohnehin so.

[seahawk1986]

Ich denke das ist sowieso eher etwas für Individual-Lösungen, wenn man das Problem nicht mit dynamite erschlagen will (das ja auch gewisse Einschränkungen mit sich bringt). Wenn jemand dvbapi verwendet muss er ja eigentlich sogar schon beim Start von oscam ansetzen, da das Konstrukt mindestens einen betriebsbereiten DVB-Adapter benötigt.

[CReimer]

Eine Kombination aus seahawks und olebowles Vorschlag fände ich OK. Wobei wie bereits angemerkt wurde, auch auf oscam Rücksicht genommen werden muss.

Was das After für eventlircd angeht: Das ändere ich dann im gleichen Zug mit dem Warten auf die dvb-devices.

In der runvdr.conf könnte man es machen, wenn man oscam außer Acht lässt. Außerdem, wenn ich bereits eine Lösung gefunden hätte, den VDR mit systemd direkt zu starten, wäre runvdr-extreme sowieso nicht mehr da.

Ich lasse euch da mal freie Hand :tongue: Möglichst simpel und gut getestet. Dann kommt es rein.

[seahawk1986]

Also die Plugins und Parameter für den VDR könnte man ja prinzipiell auch nach /etc/conf.d/ schreiben und den Start des X-Servers in einen eigenen Job auslagern oder ihn gleich durch Softhddevice starten lassen. Wenn man den VDR direkt als User vdr laufen lässt, müsste man im Shutdown-Wrapper nur auf das suid(0) verzichten und entweder über sudo und entsprechende Einträge in der /etc/sudoers (oder evtl. auch Polkit) gehen, um die Aufwachzeit in der shutdown.sh zu setzen und den Shutdown auszulösen. Oder übersehe ich da etwas, das fehlt?

[olebowle]

Ich habe gerade nochmal rumgespielt. Es stellt sich raus, dass er ohne Wants= einfach weiter macht, auch wenn das device nicht da ist. Es muss also auch mit in vdr.service rein. Damit wartet er bis zu 90 Sekunden, läuft dann in ein Timeout und startet vdr halt ohne den Adapter.

BTW: Im runvdr-extreme PKGBUILD wird vdr.service als ausfühbar installiert, das ist aber nicht nötig und wird bei allen anderen *.service auch nicht gemacht.

[seahawk1986]

Also dann wäre ein separater Job doch eigentlich das Beste, denn so kann man auch gleich noch die Abhängigkeit zu oscam ermöglichen ohne das mit den DVB-Karten an zwei Stellen behandeln zu müssen.

[HTPC-Schrauber]

Bei mir funktioniert das Ganze jetzt auch. Ich habe allerdings die Wants und Afters in eine: /etc/systemd/system/vdr.service.d/vdr.conf gesteckt Und zwar nur diese Zeilen. Die werden ja dann der urspünglichen Unit hinzugefügt und überschreiben sie nicht.

Letztlich wäre das doch auch für den geneigten User eine Lösung. Es wird ein leeres bzw. Sample-File in /etc/systemd/system/vdr.service.d/ installiert. z.B. ein vdr.conf.template. Das wird dann erst noch ignoriert, weil es nicht .conf heißt. Der User kann dann, so er die Abhängigkeit braucht, das .template in .conf kopieren und seine DVB-Devices eintragen und fertig.

[CReimer]

@seahawk1986: Mich hatte gestört, dass dann die VDR-Parameter selbst zusammengesetzt werden müssen. Ich hätte lieber sowas wie 'AddPlugin' Wenn da aber grundsätzlich Interesse besteht bitte ein neues Issue öffnen. Ganz uninteressiert bin ich auch nicht. runvdr-extreme hat schon den ein oder anderen Patch zu viel.

Ja, ich sehe schon, man kann es nicht allgemein gestalten. Wie will man denn wissen worauf man warten soll. Ich kann ja nicht davon ausgehen, dass überhaupt ein Tuner im System steckt.

Sehe ich das richtig, dass es dann das einfachste ist, wenn man eine vdr.service.d/vdr.conf anlegt? Kompliziertere Servicedateien würde ich dann erst annehmen, wenn es wirklich zu einer 'runvdr-extreme'losen Variante kommen sollte.

[HTPC-Schrauber]

Ich hätte noch einen Ansatz, wie man die Prüfung auf die DVB-Devices automatisieren könnte: Bei Paketinstallation prüft das Install-Script den Inhalt von /dev/dvb und trägt die vorgefundenen Devices in die /etc/systemd/system/vdr.service.d/vdr.conf ein. Solange man die Konfiguration nicht verändert funktioniert das.

Um es zu perfektionieren könnte man ein Script machen, das jedes Mal vor dem Shutdown die DVB-Devices prüft und die vdr.conf anpasst. Wenn der User die Hardwarekonfiguration ändert (eine Karte entfernt), dann würde der Start einmalig 90 Sekunden dauern, weil systemd dann darauf wartet, das ein DVB-Device bereit wird das gar nicht mehr vorhanden ist. Beim nächsten Shutdown wird die vdr.conf dann wieder aktualisiert und beim nächsten Start funktioniert wieder alles ganz normal.

Wenn da Interesse besteht, kann ich ja mal ein entsprechendes Script basteln.

[CReimer]

Das geht zu weit. Stichwort "The Arch Way". Zuviel an den Paketen rumfummeln geht zu weit. Bei Archlinux ist es eigentlich ehr üblich, das in einem Wiki zu beschreiben. Also wie man diese vdr.service.d Config anlegt. Wer will? Ein Wikischreiber könnte ich sowieso noch brauchen :smiley:

[HTPC-Schrauber]

Sorry, Wiki schreiben ist gar nicht mein Thema. Abgesehen davon, das ich bei diesem Thema es nicht einmal wirklich erklären kann, weil ich es selbst nicht ganz verstehe.

Wenn ich nämlich mit 'systemctl list-units' rein schaue, dann heißen meine Devices anders, als in den Wants bzw After Zeilen. Dort steht in den Namen immer noch der PCI-Anschluss usw. mit drin.

Mittels install-Script zumindest aus den vorhandenen Devices ein Template zu erstellen würde ich allerdings durchaus für sinnvoll halten. Die vollautomatische Variante ist, da gebe ich Dir Recht, nicht sehr "Archig". Wobei ich sagen muss, als ich nach einiger Abstinenz-Zeit wieder mit Arch angefangen hab, fand ich einiges nicht mehr wirklich einfach. Aber das ist ein anderes Thema.

[seahawk1986]

Mir war das mit der /etc/systemd/system/vdr.service.d/ auch nicht ganz geläufig, aber das Prinzip ist bereits gut im Arch-Wiki dokumentiert: https://wiki.archlinux.org/index.php/Systemd#Editing_provided_unit_files

Zu den tags für udev - bei mir siehr das so aus (die Vorlage zu dem Ansatz stammt von http://lists.fedoraproject.org/pipermail/devel/2012-January/160917.html bzw. http://www.mythtv.org/wiki/Systemd_mythbackend_Configuration ):

sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb0.demux0.device                  loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb0.demux0
sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb0.dvr0.device                    loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb0.dvr0
sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb0.frontend0.device               loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb0.frontend0
sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb0.net0.device                    loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb0.net0
sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb1.demux0.device                  loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb1.demux0
sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb1.dvr0.device                    loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb1.dvr0
sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb1.frontend0.device               loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb1.frontend0
sys-devices-pci0000:00-0000:00:1c.1-0000:04:00.0-dvb-dvb1.net0.device                    loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/dvb/dvb1.net0

Eigentlich sollte er da die Geräte-Knoten angeben, die unter /dev auftauchen, aber aus irgendeinem Grund nimmt er den syspath...

[HTPC-Schrauber]

Ja, genauso sehen die bei mir auch aus. Wenn ich das aber bei Wants/After eintrage, dann funktioniert das Ganze schlicht nicht. Der Eintrag muss schon so lauten, wie zuerst von Dir gepostet. Warum das so ist, ist mir schleierhaft.

[seahawk1986]

Also in der Manpage von systemd.device(5) steht:

Device units are named after the /sys and /dev paths they control. Example: the device /dev/sda5 is
exposed in systemd as dev-sda5.device

Und in systemd.unit(5):

Some unit names reflect paths existing in the file system name space. Example: a device unit 
dev-sda.device refers to a device with the device node /dev/sda in the file system namespace. If this
applies a special way to escape the path name is used, so that the result is usable as part of a file
name. Basically, given a path, "/" is replaced by "-", and all unprintable characters and the "-" are
replaced by C-style "\x20" escapes. The root directory "/" is encoded as single dash, while otherwise the
initial and ending "/" is removed from all paths during transformation. This escaping is reversible.

[HTPC-Schrauber]

Danke für das mit der Nase drauf hauen ;) Irgendwie fällt mir jetzt erst auf das das ja genau der Pfad ist, nur eben mit Bindestrichen statt Slashes. Manchmal ist man doch echt von Blindheit geschlagen.

[HTPC-Schrauber]

Hier noch die Sache zum anlegen eines vdr.conf Template auf Basis der laufenden Systemkonfiguration: [code] echo '[Unit]' > vdr.conf.template ls -1 /dev/dvb// | sed 's/\//Wants=/' | sed 's/\//-/g' | sed 's/$/.device/' >> vdr.conf.template ls -1 /dev/dvb// | sed 's/\//After=/' | sed 's/\//-/g' | sed 's/$/.device/' >> vdr.conf.template [/code]

Nur falls Du das doch in das PKGBUILD bzw. Install-Script mit aufnehmen willst.

Wiki-Artikel hin oder her. Der User wird i.d.R. erstmal darüber stolpern, das es ein Problem gibt und der VDR zu früh startet. Einen möglichen Wiki-Artikel muss er dann aber überhaupt erstmal finden. Ich meine, ich bin nun nicht gerade ein Linux-Anfänger und auch keine VDR-Einsteiger. Ich habe durchaus Google usw. bemüht. Nur fündig geworden bin ich nicht. Letztlich weiß man gar nicht so richtig nach was man da suchen soll. Von daher würde ich es schon als hilfreich ansehen, wenn dem User zumindest für die Erstkonfiguration ein File hingestellt wird.

Zur Funktion: Mit ls den Inhalt von /dev/dvb listen, dann mit sed den führenden / durch Wants= bzw. beim zweiten durch After= ersetzen. Dann die übrigen / durch - ersetzen und zum Schluss noch ein .device an jede Zeile anhängen.

[CReimer]

Hmm, die Cine CT ist doch baugleich mit der Cine S2 und die Cine S2 ist bei mir innerhalb von Millisekunden betriebsbereit. Lange bevor der VDR gestartet wird.

Kommt das wirklich nur mir komisch vor?

[HTPC-Schrauber]

Möglicherweise hängt es bei mir doch mit dem Setup zusammen, das der VDR als ESXi Gast läuft. Sollte zwar eigentlich nicht sein, aber ist auch nicht ganz von der Hand zu weisen. Wobei so ein Setup zunehmend üblicher wird, würde ich sagen.

In jeder anderen Hinsicht läuft die Karte jedenfalls völlig anstandslos. Umschaltzeiten sind kurz. Aufnahmen sind fehlerfrei. Also ein grundsätzliches Problem scheint nicht zu bestehen.

[seahawk1986]

Es gibt Unterschiede je nach Bridge (ngene, ddbridge), Karten-Version und wie schnell die evtl. benötigte zusätzliche Firmware für den Tuner geladen werden kann. Meine DuoFlex-CT an einer ngene-Bridge braucht da einfach länger beim Start aus S5 (http://www.vdr-portal.de/board18-vdr-hardware/board102-dvb-karten/p1125276-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-cinect-sowie-tt-s2-6400-teil-2/#post1125276) - UFO meint, das könnte an den langsamen i2c-Transfers der ngene-Bridge liegen. Daher nutze ich aktuell hauptsächlich den Standby-Modus für den VDR, da muss die Firmware für die Tuner nicht zeitraubend neu geladen werden:

[ 6869.254007] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
[ 6869.258652] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas
[ 6869.258693] ngene: Found Digital Devices DuoFlex PCIe or miniPCIe
[ 6869.259762] ngene: Device version 1
[ 6869.259817] ngene: Loading firmware file ngene_18.fw.
[ 6869.281611] ngene 0000:04:00.0: irq 50 for MSI/MSI-X
[ 6869.283013] error in i2c_read_reg
[ 6869.283597] No CXD2099 detected at 40
[ 6869.284710] No demod found on chan 0
[ 6869.286288] No demod found on chan 1
[ 6869.288115] drxk: frontend initialized.
[ 6869.289419] tda18271c2dd: i2c write error at addr 96
[ 6869.290086] DVB: registering new adapter (nGene)
[ 6869.290091] ngene 0000:04:00.0: DVB: registering adapter 0 frontend 0 (DRXK)...
[ 6869.316826] drxk: status = 0x639130d9
[ 6869.316831] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
[ 6872.302246] DRXK driver version 0.9.4300
[ 6872.357201] drxk: frontend initialized.
[ 6872.358518] tda18271c2dd: i2c write error at addr 96
[ 6872.359176] DVB: registering new adapter (nGene)
[ 6872.359182] ngene 0000:04:00.0: DVB: registering adapter 1 frontend 0 (DRXK)...
[ 6872.386042] drxk: status = 0x639130d9
[ 6872.386047] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz

[CReimer]

Hmm? Standby-Modus ist doch gar nicht in vdr4arch implementiert?!

Naja wie gesagt ich bin dran. Ich schließe aktuell auch nicht aus eine neue runvdr zu schreiben. Ich habe dazu mal eine Diskussion im VDR-Portal losgetreten. Noch ist es da aber sehr ruhig...

http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1139159-systemd-vdr-service/#post1139159

[seahawk1986]

Ich nehme mir die Freiheit alles an meine Bedürfnisse anzupassen... Die Holzhammer-Methode funktioniert schon mal (wenn der X-Server mal unabhängig von der runvdr-extreme läuft lohnt sich evtl. auch die Nutzung von dynamite - dann müsste man den VDR nicht stopppen, auch wenn wie bei meiner Karte dummerweise nötig die DVB-Module neu geladen werden müssen): Nach einer kleinen Anpassung an der runvdr-extreme (da /tmp offenbar z.T. zu früh geleert wird und das rm dann fehlschlägt)

--- a/runvdr 2013-03-16 13:34:18.250825917 +0100
+++ b/runvdr    2013-04-13 12:47:33.596657485 +0200
@@ -884,7 +884,7 @@ while (true) do
             PID) PID="$arg";;
             RET) RET="$arg";;
         esac ; done < "$PROXYFILE"
-        rm "$PROXYFILE"
+        rm -f "$PROXYFILE"
     fi

     # Remember stop time

kann man "systemctl suspend" nutzen (die shutdown.sh für den VDR muss entsprechend angepasst werden) - der VDR wird vor dem S3 beendet und die Treiber entladen und beim Aufwachen alles wiederhergestellt:

/etc/systemd/system/vdr-suspend.service

[Unit]
Description=vdr suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStartPre=/usr/bin/systemctl stop vdr
ExecStart=/sbin/modprobe -r ngene tda18271c2dd cxd2099 drxk nvidia

[Install]
WantedBy=sleep.target

/etc/systemd/system/vdr-resume.service

[Unit]
Description=vdr resume actions
After=suspend.target

[Service]
Type=simple
ExecStartPre=/sbin/modprobe -a tda18271c2dd cxd2099 drxk ngene nvidia
ExecStart=/usr/bin/systemctl start vdr

[Install]
WantedBy=suspend.target

[CReimer]

OK, ich sehe schon. Ich werde da wohl einiges ändern. Auch wenn das meinem Bruder nicht passt. Der versucht mich nämlich gerade von allen Änderungen in diese Richtung abzuhalten.

[M-Reimer]

Hallo zusammen,

ich möchte bei der Gelegenheit auch mal meine letzten Gedanken zum Thema niederschreiben.

Wenn der zugehörige Treiber sauber geschrieben ist, dann sollte es eigentlich so sein, dass, sobald "modprobe" durch ist, das Device auch verfügbar wird. Wahrscheinlich ist also die hier beschriebene Situation mit der virtuellen Maschine garnicht direkt ein Bug, der von der Virtualisierung abhängt, sondern vielmehr ist es wohl pures Glück, dass es bei nicht-virtualisierter Hardware sauber läuft.

Meine Vermutung ist, dass hier die Parallelisierung von systemd einen Strich durch die Rechnung macht. Ich habe das Gefühl, dass das Laden der Treiber und der Start vom VDR parallel laufen. So wird ein sauberer Start vom VDR unweigerlich extrem zeitkritisch. Zu klären wäre also welches .service oder .target letztlich erstmalig die Treiber lädt um das vdr.service so zu ändern, dass es danach gestartet wird. Worst-Case könnte ich dazu auch mal direkt in der systemd-Mailingliste nachfragen.

Ich habe mal etwas gesucht und bin auf folgende mögliche Lösung gestoßen:

Folgendes bitte zum Test in die vdr.service eintragen (von jemandem, der das Problem mit nicht gefundenen Tunern hat):

Wants=systemd-udev-settle.service After=systemd-udev-settle.service

Das ist zumindest eine erste mögliche Lösungsmöglichkeit auf die man aufbauen kann... Wenn ich das so richtig verstanden habe, ermöglichen diese zwei Zeilen es, das man sicherstellen kann, das unter /dev auch wirklich alle Devices da sind.

[CReimer]

Ein anderes Target gibt es nicht. Es gibt noch eines, das graphical.target. Das läuft aber parallel zum multi-user.target.

Die Unit-Files für Standby scheinen so nicht richtig zu sein. Ich habe bisher kein offizielles Unit File finden können, das mit systemctl stop arbeitet.

[M-Reimer]

Gut zu wissen. Helfen sollte aber dieses "systemd-udev-settle.service". Hoffe ich zumindest...

[seahawk1986]

Also ich habe mal so einen Service erstellt:

[Unit]
Wants=systemd-udev-settle.service
After=systemd-udev-settle.service

[Service]
Type=oneshot
ExecStart=/usr/bin/logger -t "udev settle" "all devices ready"

[Install]
WantedBy=multi-user.target

IMHO wird der udevsettle.service recht spät gestartet - die Regel für die DVB-Adapter schlägt früher zu: https://dl.dropboxusercontent.com/u/960809/test_settle.svg

[M-Reimer]

Man könnte fast meinen die Devices kommen zu einem frei gewählten späteren Zeitpunkt hinzu. Wirklich debuggen kann ich das, mangels systemd-Kenntnissen, nicht. Müsste man ggf. mal in die systemd-Liste posten.

Was mir bezüglich "könnte später dazukommen" gleich in den Sinn gekommen ist, wäre etwas in der Art: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012225

[HTPC-Schrauber]

Der vmware-Link kann es nicht sein. Das bezieht sich auf virtuelle Hardware. Die Karte ist aber per PCI-Passthrough direkt an die VM durchgereicht. ESXi sieht diese Karte nicht einmal mehr. Ich kann das aber gerne Testen. Kein Problem.

Zu dem systemd-udev-settle.dervice: Mir ist so, als hätte ich genau das versucht und es hatte nicht funktioniert. Ich werde das aber nochmals verifizieren.

[M-Reimer]

Wann das Hotplug hier wirkt weiß ich nicht. Kommt auf einen Versuch an. Hardware, die beim Bootvorgang schon vorhanden ist und nicht irgendwann später dazukommt sollte aber durch "udevadm trigger" und "udevadm settle" eigentlich zuverlässig eingebunden werden.

[seahawk1986]

Die Unit-Files für Standby scheinen so nicht richtig zu sein. Ich habe bisher kein offizielles Unit File finden können, das mit systemctl stop arbeitet.

Was würdest du vorschlagen? Ein Conflicts=vdr.service wäre eine mögliche Alternative (habe ich aber auch noch nicht so gesehen), auch wenn das für mich weniger eindeutig ist als da einfach die nötigen Aufgaben abzuarbeiten. Da der VDR keine systemd-Unterstützung mitbringt sieht das leider etwas hässlich aus...

[M-Reimer]

Ich würde vorschlagen hier arbeiten wir erstmal eine mögliche Lösung für dieses "ESX-Problem" aus. In wiefern man dann eventuell ein "Standby" nachrüsten kann, wäre ein eigener Diskussionsfaden.

[CReimer]

Ich wäre mit dem udev-settle zufrieden. An dieser Stelle ist sichergestellt, dass jeder benötigte Hardware vorhanden ist. Wie du selbst schon gesagt hast, ist der VDR nicht ideal für systemd gerüstet.

Es ist auf jeden Fall besser, als irgendwie dynamisch Warteregeln zu erstellen.

[CReimer]

Kann mir erstmal jemand einen analyze plot schicken, so wie es standardmäßig in vdr4arch ist. So kann ich da ja nichts verstehen.

[HTPC-Schrauber]

Kann ich machen, wenn mir jemand sagt wie ich den Plot erstelle.

[seahawk1986]

systemd-analyze plot > mein_bootchart.svg

Siehe auch https://wiki.archlinux.org/index.php/Systemd#Using_systemd-analyze

[HTPC-Schrauber]

So, also mit udev-settle funktioniert es. Zumindest wurde bei 3 Reboots der VDR immer erst gestartet nachdem die Karte komplett initialisiert war.

Wenn das Bootchart noch von Interesse ist, dann hier: Leider ist es etwas komisch formatiert. Ich habe keine Ahnung wie ich das ändern kann.

Ohne udev-settle: http://www.galantgdi.de/downloads/bootchart.svg

Mit udev-settle: http://www.galantgdi.de/downloads/bootchart2.svg

[CReimer]

Dein System ist innerhalb von 3sec durchgebootet?! Da wundert es mich nicht, dass es zu Problemen kommt.

[CReimer]

Damit erkläre ich den Bug als erledigt. Vielen Dank.