* kmemleak reports unreferenced object 0xf2bee080 (size 96)
From: Paul Menzel @ 2018-06-07 15:54 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI; +Cc: netdev, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1478 bytes --]
Dear Linux folks,
With Linux 4.17+, Linux reports the memory leak below on an ASRock E350M1.
```
$ git describe
v4.17-6625-g1c8c5a9d38f6
$ dmesg
[…]
[ 677.139874] PM: suspend exit
[ 678.490993] kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
[ 679.517022] r8169 0000:03:00.0 enp3s0: link up
[…]
$ sudo more /sys/kernel/debug/kmemleak
unreferenced object 0xf2bee080 (size 96):
comm "systemd-network", pid 209, jiffies 4294894477 (age 851.812s)
hex dump (first 32 bytes):
00 00 00 00 dc 05 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<fb9b1020>] kmem_cache_alloc_trace+0x195/0x3a0
[<bbe5d9f4>] ip6_convert_metrics+0x4a/0xe0
[<4d869f67>] ip6_route_info_create+0x294/0xd10
[<2f08c8d0>] ip6_route_add+0x1d/0x90
[<304de076>] inet6_rtm_newroute+0x72/0x80
[<f9e280dd>] rtnetlink_rcv_msg+0x2df/0x4f0
[<9287c3cf>] netlink_rcv_skb+0x8f/0x130
[<fbddd35b>] rtnetlink_rcv+0x12/0x20
[<60ffd06b>] netlink_unicast+0x1ab/0x2b0
[<4260e680>] netlink_sendmsg+0x2b5/0x5c0
[<ec0cda7b>] sock_sendmsg+0x5a/0xa0
[<08adf1a5>] __sys_sendto+0xea/0x170
[<93e4f4e1>] sys_socketcall+0x1f4/0x380
[<dcd25cae>] do_fast_syscall_32+0xd3/0x360
[<0ce0c28f>] entry_SYSENTER_32+0x4e/0x7c
[<2324e043>] 0xffffffff
```
Please find the Linux messages attached.
Kind regards,
Paul
[-- Attachment #1.2: 20180607–linux_4.17+–dmesg.txt --]
[-- Type: text/plain, Size: 94779 bytes --]
[ 676.139094] input input2: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 676.139142] usb usb4: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 129, parent: 0000:00:13.0
[ 676.139239] leds input0::scrolllock: calling led_suspend+0x0/0x50 @ 497, parent: input0
[ 676.139248] leds input0::scrolllock: led_suspend+0x0/0x50 returned 0 after 3 usecs
[ 676.139254] leds input0::capslock: calling led_suspend+0x0/0x50 @ 497, parent: input0
[ 676.139261] leds input0::capslock: led_suspend+0x0/0x50 returned 0 after 2 usecs
[ 676.139267] leds input0::numlock: calling led_suspend+0x0/0x50 @ 497, parent: input0
[ 676.139274] leds input0::numlock: led_suspend+0x0/0x50 returned 0 after 2 usecs
[ 676.139282] input input0: calling input_dev_suspend+0x0/0x80 @ 497, parent: serio0
[ 676.139290] input input0: input_dev_suspend+0x0/0x80 returned 0 after 3 usecs
[ 676.139301] platform microcode: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 676.139309] platform microcode: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 676.139350] rtc rtc0: calling rtc_suspend+0x0/0x20 @ 497, parent: 00:00
[ 676.139357] rtc rtc0: rtc_suspend+0x0/0x20 returned 0 after 2 usecs
[ 676.139364] atkbd serio0: calling serio_suspend+0x0/0x20 @ 497, parent: i8042
[ 676.139406] usb usb2: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 520, parent: 0000:00:13.2
[ 676.139533] usb usb1: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 509, parent: 0000:00:12.2
[ 676.139639] snd_hda_codec_realtek hdaudioC1D0: calling pm_runtime_force_suspend+0x0/0x120 @ 128, parent: 0000:00:14.2
[ 676.139683] usb 3-2: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 825 usecs
[ 676.139725] snd_hda_codec_hdmi hdaudioC0D0: calling pm_runtime_force_suspend+0x0/0x120 @ 130, parent: 0000:00:01.1
[ 676.139793] usb usb3: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 532, parent: 0000:00:12.0
[ 676.139855] sd 0:0:0:0: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 511, parent: target0:0:0
[ 676.139913] scsi host5: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 546, parent: ata6
[ 676.139934] scsi host5: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 676.139957] scsi host4: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 546, parent: ata5
[ 676.140009] usb usb3: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 140 usecs
[ 676.140025] scsi host4: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 676.140067] scsi host3: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 532, parent: ata4
[ 676.140083] scsi host2: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 546, parent: ata3
[ 676.140115] scsi host3: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 6 usecs
[ 676.140131] scsi host2: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 676.140165] scsi host1: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 532, parent: ata2
[ 676.140186] ata6: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 541, parent: 0000:00:11.0
[ 676.140218] scsi host1: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 5 usecs
[ 676.140236] ata5: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 535, parent: 0000:00:11.0
[ 676.140270] ata4: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 532, parent: 0000:00:11.0
[ 676.140387] ata3: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 531, parent: 0000:00:11.0
[ 676.140460] ata2: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 530, parent: 0000:00:11.0
[ 676.140522] ata2: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 43 usecs
[ 676.140559] ata4: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 247 usecs
[ 676.140575] ata5: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 289 usecs
[ 676.140602] ata3: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 194 usecs
[ 676.140627] ata6: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 413 usecs
[ 676.142622] atkbd serio0: serio_suspend+0x0/0x20 returned 0 after 3147 usecs
[ 676.142653] i8042 i8042: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 676.145684] i8042 i8042: platform_pm_suspend+0x0/0xa0 returned 0 after 2952 usecs
[ 676.145703] serial8250 serial8250: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 676.145716] serial8250 serial8250: platform_pm_suspend+0x0/0xa0 returned 0 after 7 usecs
[ 676.145761] alarmtimer alarmtimer: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 676.145771] alarmtimer alarmtimer: platform_pm_suspend+0x0/0xa0 returned 0 after 4 usecs
[ 676.145780] platform platform-framebuffer.0: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 676.145788] platform platform-framebuffer.0: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 676.145795] pcspkr pcspkr: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 676.145822] pcspkr pcspkr: platform_pm_suspend+0x0/0xa0 returned 0 after 20 usecs
[ 676.145949] i8042 aux 00:04: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 676.145959] i8042 aux 00:04: pnp_bus_suspend+0x0/0x20 returned 0 after 4 usecs
[ 676.145966] i8042 kbd 00:03: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 676.145974] i8042 kbd 00:03: pnp_bus_suspend+0x0/0x20 returned 0 after 2 usecs
[ 676.145981] i8042 aux 00:02: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 676.145991] i8042 aux 00:02: pnp_bus_suspend+0x0/0x20 returned 0 after 5 usecs
[ 676.145998] i8042 kbd 00:01: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 676.146006] i8042 kbd 00:01: pnp_bus_suspend+0x0/0x20 returned 0 after 2 usecs
[ 676.146014] rtc_cmos 00:00: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 676.146124] rtc_cmos 00:00: pnp_bus_suspend+0x0/0x20 returned 0 after 101 usecs
[ 676.146141] button LNXPWRBN:00: calling acpi_button_suspend+0x0/0x40 [button] @ 497, parent: LNXSYSTM:00
[ 676.146149] button LNXPWRBN:00: acpi_button_suspend+0x0/0x40 [button] returned 0 after 3 usecs
[ 676.146165] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_suspend+0x0/0x70 @ 497, parent: platform
[ 676.146175] coreboot_table_acpi BOOT0000:00: acpi_subsys_suspend+0x0/0x70 returned 0 after 4 usecs
[ 676.146181] platform PNP0C0C:00: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 676.146189] platform PNP0C0C:00: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 676.146195] platform PNP0C04:00: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: 0000:00:14.3
[ 676.146203] platform PNP0C04:00: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 676.146209] platform PNP0800:00: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: 0000:00:14.3
[ 676.146216] platform PNP0800:00: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 676.146326] button PNP0C0C:00: calling acpi_button_suspend+0x0/0x40 [button] @ 497, parent: LNXSYBUS:00
[ 676.146334] button PNP0C0C:00: acpi_button_suspend+0x0/0x40 [button] returned 0 after 3 usecs
[ 676.146390] thermal LNXTHERM:00: calling acpi_thermal_suspend+0x0/0x20 [thermal] @ 497, parent: device:0b
[ 676.146401] thermal LNXTHERM:00: acpi_thermal_suspend+0x0/0x20 [thermal] returned 0 after 5 usecs
[ 676.146467] r8169 0000:03:00.0: calling pci_pm_suspend+0x0/0x1e0 @ 535, parent: 0000:00:15.1
[ 676.146551] pci 0000:00:18.7: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146561] pci 0000:00:18.7: pci_pm_suspend+0x0/0x1e0 returned 0 after 4 usecs
[ 676.146576] pci 0000:00:18.6: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146584] pci 0000:00:18.6: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 676.146592] pci 0000:00:18.5: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146599] pci 0000:00:18.5: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 676.146607] pci 0000:00:18.4: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146614] pci 0000:00:18.4: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 676.146624] k10temp 0000:00:18.3: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146632] k10temp 0000:00:18.3: pci_pm_suspend+0x0/0x1e0 returned 0 after 3 usecs
[ 676.146640] pci 0000:00:18.2: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146647] pci 0000:00:18.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 676.146655] pci 0000:00:18.1: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146662] pci 0000:00:18.1: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 676.146670] pci 0000:00:18.0: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.146677] pci 0000:00:18.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 676.146728] pci 0000:00:14.4: calling pci_pm_suspend+0x0/0x1e0 @ 530, parent: pci0000:00
[ 676.146736] pci 0000:00:14.4: pci_pm_suspend+0x0/0x1e0 returned 0 after 3 usecs
[ 676.146744] pci 0000:00:14.3: calling pci_pm_suspend+0x0/0x1e0 @ 530, parent: pci0000:00
[ 676.146751] pci 0000:00:14.3: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 676.146773] piix4_smbus 0000:00:14.0: calling pci_pm_suspend+0x0/0x1e0 @ 508, parent: pci0000:00
[ 676.146781] piix4_smbus 0000:00:14.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 3 usecs
[ 676.146816] ohci-pci 0000:00:12.0: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 676.146838] ohci-pci 0000:00:12.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 17 usecs
[ 676.146869] pci 0000:00:00.0: calling pci_pm_suspend+0x0/0x1e0 @ 544, parent: pci0000:00
[ 676.146877] pci 0000:00:00.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 3 usecs
[ 676.146952] r8169 0000:03:00.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 454 usecs
[ 676.147138] pcieport 0000:00:15.1: calling pci_pm_suspend+0x0/0x1e0 @ 531, parent: pci0000:00
[ 676.147249] pcieport 0000:00:15.1: pci_pm_suspend+0x0/0x1e0 returned 0 after 99 usecs
[ 676.154508] usb usb2: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 14700 usecs
[ 676.154731] ehci-pci 0000:00:13.2: calling pci_pm_suspend+0x0/0x1e0 @ 508, parent: pci0000:00
[ 676.158055] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 676.158734] sd 0:0:0:0: [sda] Stopping disk
[ 676.165255] sd 0:0:0:0: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 24741 usecs
[ 676.165429] scsi target0:0:0: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 512, parent: host0
[ 676.165475] scsi target0:0:0: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 9 usecs
[ 676.165547] scsi host0: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 546, parent: ata1
[ 676.165584] scsi host0: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 14 usecs
[ 676.165812] ata1: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 7, parent: 0000:00:11.0
[ 676.165994] ata1: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 136 usecs
[ 676.166067] ahci 0000:00:11.0: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 676.166161] ahci 0000:00:11.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 81 usecs
[ 676.166627] usb usb1: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 26431 usecs
[ 676.166685] ehci-pci 0000:00:12.2: calling pci_pm_suspend+0x0/0x1e0 @ 523, parent: pci0000:00
[ 676.174096] ehci-pci 0000:00:13.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 18878 usecs
[ 676.185964] ehci-pci 0000:00:12.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 18799 usecs
[ 676.214527] usb usb5: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 73680 usecs
[ 676.214650] usb usb4: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 73692 usecs
[ 676.214668] ohci-pci 0000:00:14.5: calling pci_pm_suspend+0x0/0x1e0 @ 532, parent: pci0000:00
[ 676.214702] ohci-pci 0000:00:13.0: calling pci_pm_suspend+0x0/0x1e0 @ 506, parent: pci0000:00
[ 676.214769] ohci-pci 0000:00:13.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 59 usecs
[ 676.214779] ohci-pci 0000:00:14.5: pci_pm_suspend+0x0/0x1e0 returned 0 after 95 usecs
[ 676.246099] snd_hda_codec_hdmi hdaudioC0D0: pm_runtime_force_suspend+0x0/0x120 returned 0 after 103841 usecs
[ 676.246312] snd_hda_intel 0000:00:01.1: calling pci_pm_suspend+0x0/0x1e0 @ 541, parent: pci0000:00
[ 676.246477] snd_hda_intel 0000:00:01.1: pci_pm_suspend+0x0/0x1e0 returned 0 after 150 usecs
[ 676.246572] radeon 0000:00:01.0: calling pci_pm_suspend+0x0/0x1e0 @ 519, parent: pci0000:00
[ 676.367131] snd_hda_codec_realtek hdaudioC1D0: pm_runtime_force_suspend+0x0/0x120 returned 0 after 222120 usecs
[ 676.367222] snd_hda_intel 0000:00:14.2: calling pci_pm_suspend+0x0/0x1e0 @ 530, parent: pci0000:00
[ 676.368673] snd_hda_intel 0000:00:14.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 1379 usecs
[ 676.482031] radeon 0000:00:01.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 229912 usecs
[ 676.483369] snd_hda_intel 0000:00:01.1: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483383] snd_hda_intel 0000:00:01.1: pci_pm_suspend_late+0x0/0x40 returned 0 after 7 usecs
[ 676.483478] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_suspend_late+0x0/0x80 @ 497, parent: platform
[ 676.483509] coreboot_table_acpi BOOT0000:00: acpi_subsys_suspend_late+0x0/0x80 returned 0 after 11 usecs
[ 676.483629] pci 0000:00:18.7: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483638] pci 0000:00:18.7: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 676.483649] pci 0000:00:18.6: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483657] pci 0000:00:18.6: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483667] pci 0000:00:18.5: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483675] pci 0000:00:18.5: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483685] pci 0000:00:18.4: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483692] pci 0000:00:18.4: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483703] k10temp 0000:00:18.3: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483714] k10temp 0000:00:18.3: pci_pm_suspend_late+0x0/0x40 returned 0 after 5 usecs
[ 676.483724] pci 0000:00:18.2: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483731] pci 0000:00:18.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483740] pci 0000:00:18.1: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483747] pci 0000:00:18.1: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483756] pci 0000:00:18.0: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.483763] pci 0000:00:18.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483792] ohci-pci 0000:00:14.5: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483800] ohci-pci 0000:00:14.5: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 676.483810] pci 0000:00:14.4: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483817] pci 0000:00:14.4: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483828] pci 0000:00:14.3: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483835] pci 0000:00:14.3: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483845] snd_hda_intel 0000:00:14.2: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483853] snd_hda_intel 0000:00:14.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483866] piix4_smbus 0000:00:14.0: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483873] piix4_smbus 0000:00:14.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483883] ehci-pci 0000:00:13.2: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483891] ehci-pci 0000:00:13.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483901] ohci-pci 0000:00:13.0: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483908] ohci-pci 0000:00:13.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483920] ehci-pci 0000:00:12.2: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483928] ehci-pci 0000:00:12.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 676.483956] ahci 0000:00:11.0: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.483970] ohci-pci 0000:00:12.0: calling pci_pm_suspend_late+0x0/0x40 @ 128, parent: pci0000:00
[ 676.483974] ahci 0000:00:11.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 676.483992] ohci-pci 0000:00:12.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 9 usecs
[ 676.483997] radeon 0000:00:01.0: calling pci_pm_suspend_late+0x0/0x40 @ 544, parent: pci0000:00
[ 676.484005] radeon 0000:00:01.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 676.484014] pci 0000:00:00.0: calling pci_pm_suspend_late+0x0/0x40 @ 128, parent: pci0000:00
[ 676.484023] r8169 0000:03:00.0: calling pci_pm_suspend_late+0x0/0x40 @ 519, parent: 0000:00:15.1
[ 676.484031] pci 0000:00:00.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 5 usecs
[ 676.484036] r8169 0000:03:00.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 676.484053] pcieport 0000:00:15.1: calling pci_pm_suspend_late+0x0/0x40 @ 530, parent: pci0000:00
[ 676.484061] pcieport 0000:00:15.1: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 676.485200] snd_hda_intel 0000:00:01.1: calling pci_pm_suspend_noirq+0x0/0x310 @ 519, parent: pci0000:00
[ 676.485246] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_suspend_noirq+0x0/0xb0 @ 497, parent: platform
[ 676.485264] coreboot_table_acpi BOOT0000:00: acpi_subsys_suspend_noirq+0x0/0xb0 returned 0 after 7 usecs
[ 676.485324] r8169 0000:03:00.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 544, parent: 0000:00:15.1
[ 676.485546] pci 0000:00:18.7: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.485597] pci 0000:00:18.7: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 38 usecs
[ 676.485611] pci 0000:00:18.6: calling pci_pm_suspend_noirq+0x0/0x310 @ 541, parent: pci0000:00
[ 676.485702] pci 0000:00:18.5: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.485771] pci 0000:00:18.5: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 55 usecs
[ 676.485777] pci 0000:00:18.6: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 146 usecs
[ 676.485790] pci 0000:00:18.4: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.485801] k10temp 0000:00:18.3: calling pci_pm_suspend_noirq+0x0/0x310 @ 541, parent: pci0000:00
[ 676.485846] pci 0000:00:18.4: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 44 usecs
[ 676.485851] k10temp 0000:00:18.3: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 42 usecs
[ 676.485865] pci 0000:00:18.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.485870] pci 0000:00:18.1: calling pci_pm_suspend_noirq+0x0/0x310 @ 541, parent: pci0000:00
[ 676.485929] pci 0000:00:18.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 51 usecs
[ 676.485934] pci 0000:00:18.1: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 48 usecs
[ 676.485949] pci 0000:00:18.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.485969] ohci-pci 0000:00:14.5: calling pci_pm_suspend_noirq+0x0/0x310 @ 128, parent: pci0000:00
[ 676.486068] pci 0000:00:18.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 105 usecs
[ 676.486088] pci 0000:00:14.4: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.486136] pci 0000:00:14.4: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 37 usecs
[ 676.486154] pci 0000:00:14.3: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.486180] ohci-pci 0000:00:14.5: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 198 usecs
[ 676.486193] snd_hda_intel 0000:00:14.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 128, parent: pci0000:00
[ 676.486203] pci 0000:00:14.3: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 37 usecs
[ 676.486224] piix4_smbus 0000:00:14.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.486273] piix4_smbus 0000:00:14.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 38 usecs
[ 676.486306] ehci-pci 0000:00:13.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 530, parent: pci0000:00
[ 676.489797] ohci-pci 0000:00:13.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 130, parent: pci0000:00
[ 676.490024] ohci-pci 0000:00:13.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 210 usecs
[ 676.490053] ehci-pci 0000:00:12.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 130, parent: pci0000:00
[ 676.490351] ohci-pci 0000:00:12.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 532, parent: pci0000:00
[ 676.490502] ohci-pci 0000:00:12.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 141 usecs
[ 676.490521] ahci 0000:00:11.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 532, parent: pci0000:00
[ 676.490631] ahci 0000:00:11.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 101 usecs
[ 676.490659] pci 0000:00:00.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 506, parent: pci0000:00
[ 676.490683] pci 0000:00:00.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 18 usecs
[ 676.506056] r8169 0000:03:00.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 20213 usecs
[ 676.506199] snd_hda_intel 0000:00:14.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 19529 usecs
[ 676.506220] pcieport 0000:00:15.1: calling pci_pm_suspend_noirq+0x0/0x310 @ 541, parent: pci0000:00
[ 676.506348] snd_hda_intel 0000:00:01.1: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 20641 usecs
[ 676.506373] radeon 0000:00:01.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 532, parent: pci0000:00
[ 676.506382] radeon 0000:00:01.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 3 usecs
[ 676.509935] ehci-pci 0000:00:13.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 23044 usecs
[ 676.510060] ehci-pci 0000:00:12.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 19530 usecs
[ 676.525948] pcieport 0000:00:15.1: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 19238 usecs
[ 676.526078] ACPI: Preparing to enter system sleep state S3
[ 676.533755] PM: Saving platform NVS memory
[ 676.533769] Disabling non-boot CPUs ...
[ 676.677748] smpboot: CPU 1 is now offline
[ 676.678744] PM: Calling kvm_suspend+0x0/0x30 [kvm]
[ 676.678754] PM: Calling mce_syscore_suspend+0x0/0x30
[ 676.678760] PM: Calling ledtrig_cpu_syscore_suspend+0x0/0x20
[ 676.678767] PM: Calling timekeeping_suspend+0x0/0x500
[ 676.678871] PM: Calling irq_gc_suspend+0x0/0x90
[ 676.678876] PM: Calling save_ioapic_entries+0x0/0x260
[ 676.678936] PM: Calling i8259A_suspend+0x0/0x30
[ 676.678942] PM: Calling perf_ibs_suspend+0x0/0x20
[ 676.678948] PM: Calling fw_suspend+0x0/0x20
[ 676.678953] PM: Calling acpi_save_bm_rld+0x0/0x20
[ 676.678963] PM: Calling lapic_suspend+0x0/0x310
[ 676.679213] ACPI: Low-level resume complete
[ 676.679451] PM: Restoring platform NVS memory
[ 676.679475] PM: Calling bsp_resume+0x0/0x30
[ 676.679481] PM: Calling lapic_resume+0x0/0x4c0
[ 676.679499] PM: Calling acpi_restore_bm_rld+0x0/0x60
[ 676.679506] PM: Calling irqrouter_resume+0x0/0x60
[ 676.679512] PM: Calling perf_ibs_resume+0x0/0x2c
[ 676.679516] LVT offset 0 assigned for vector 0x400
[ 676.679520] PM: Calling i8259A_resume+0x0/0x30
[ 676.679721] PM: Calling i8237A_resume+0x0/0xc0
[ 676.679776] PM: Calling ioapic_resume+0x0/0x1e0
[ 676.679791] PM: Calling irq_gc_resume+0x0/0x90
[ 676.679796] PM: Calling irq_pm_syscore_resume+0x0/0x20
[ 676.679825] PM: Calling timekeeping_resume+0x0/0x420
[ 676.679894] PM: Calling ledtrig_cpu_syscore_resume+0x0/0x20
[ 676.679899] PM: Calling mce_syscore_resume+0x0/0x30
[ 676.679913] PM: Calling mc_bp_resume+0x0/0x140
[ 676.679965] PM: Calling kvm_resume+0x0/0x40 [kvm]
[ 676.680092] Enabling non-boot CPUs ...
[ 676.683301] x86: Booting SMP configuration:
[ 676.683305] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 676.683452] Initializing CPU#1
[ 676.686934] cache: parent cpu1 should not be sleeping
[ 676.687684] microcode: CPU1: patch_level=0x05000119
[ 676.688577] CPU1 is up
[ 676.689116] ACPI: Waking up from system sleep state S3
[ 676.690586] pci 0000:00:00.0: calling pci_pm_resume_noirq+0x0/0x130 @ 506, parent: pci0000:00
[ 676.690689] pci 0000:00:00.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 89 usecs
[ 676.690702] radeon 0000:00:01.0: calling pci_pm_resume_noirq+0x0/0x130 @ 506, parent: pci0000:00
[ 676.690734] ahci 0000:00:11.0: calling pci_pm_resume_noirq+0x0/0x130 @ 541, parent: pci0000:00
[ 676.690848] ahci 0000:00:11.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 105 usecs
[ 676.690858] ohci-pci 0000:00:12.0: calling pci_pm_resume_noirq+0x0/0x130 @ 541, parent: pci0000:00
[ 676.690895] ohci-pci 0000:00:12.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 31 usecs
[ 676.690904] ehci-pci 0000:00:12.2: calling pci_pm_resume_noirq+0x0/0x130 @ 541, parent: pci0000:00
[ 676.690927] ohci-pci 0000:00:13.0: calling pci_pm_resume_noirq+0x0/0x130 @ 130, parent: pci0000:00
[ 676.690964] ohci-pci 0000:00:13.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 30 usecs
[ 676.690973] ehci-pci 0000:00:13.2: calling pci_pm_resume_noirq+0x0/0x130 @ 130, parent: pci0000:00
[ 676.690995] piix4_smbus 0000:00:14.0: calling pci_pm_resume_noirq+0x0/0x130 @ 530, parent: pci0000:00
[ 676.691031] piix4_smbus 0000:00:14.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 30 usecs
[ 676.691040] snd_hda_intel 0000:00:14.2: calling pci_pm_resume_noirq+0x0/0x130 @ 530, parent: pci0000:00
[ 676.691062] pci 0000:00:14.3: calling pci_pm_resume_noirq+0x0/0x130 @ 532, parent: pci0000:00
[ 676.691099] pci 0000:00:14.3: pci_pm_resume_noirq+0x0/0x130 returned 0 after 31 usecs
[ 676.691117] pci 0000:00:14.4: calling pci_pm_resume_noirq+0x0/0x130 @ 532, parent: pci0000:00
[ 676.691142] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_resume_noirq+0x0/0x50 @ 497, parent: platform
[ 676.691157] coreboot_table_acpi BOOT0000:00: acpi_subsys_resume_noirq+0x0/0x50 returned 0 after 6 usecs
[ 676.691161] pci 0000:00:14.4: pci_pm_resume_noirq+0x0/0x130 returned 0 after 35 usecs
[ 676.691171] ohci-pci 0000:00:14.5: calling pci_pm_resume_noirq+0x0/0x130 @ 532, parent: pci0000:00
[ 676.691209] i8042 i8042: calling i8042_pm_resume_noirq+0x0/0x30 @ 497, parent: platform
[ 676.691213] ohci-pci 0000:00:14.5: pci_pm_resume_noirq+0x0/0x130 returned 0 after 30 usecs
[ 676.691218] i8042 i8042: i8042_pm_resume_noirq+0x0/0x30 returned 0 after 2 usecs
[ 676.691225] pcieport 0000:00:15.1: calling pci_pm_resume_noirq+0x0/0x130 @ 532, parent: pci0000:00
[ 676.691249] pci 0000:00:18.0: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691278] pci 0000:00:18.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 23 usecs
[ 676.691287] pci 0000:00:18.1: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691313] pci 0000:00:18.1: pci_pm_resume_noirq+0x0/0x130 returned 0 after 20 usecs
[ 676.691322] pci 0000:00:18.2: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691348] pci 0000:00:18.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 20 usecs
[ 676.691359] k10temp 0000:00:18.3: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691387] k10temp 0000:00:18.3: pci_pm_resume_noirq+0x0/0x130 returned 0 after 22 usecs
[ 676.691396] pci 0000:00:18.4: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691423] pci 0000:00:18.4: pci_pm_resume_noirq+0x0/0x130 returned 0 after 21 usecs
[ 676.691433] pci 0000:00:18.5: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691459] pci 0000:00:18.5: pci_pm_resume_noirq+0x0/0x130 returned 0 after 20 usecs
[ 676.691468] pci 0000:00:18.6: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691494] pci 0000:00:18.6: pci_pm_resume_noirq+0x0/0x130 returned 0 after 20 usecs
[ 676.691503] pci 0000:00:18.7: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: pci0000:00
[ 676.691529] pci 0000:00:18.7: pci_pm_resume_noirq+0x0/0x130 returned 0 after 20 usecs
[ 676.710976] snd_hda_intel 0000:00:14.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 19444 usecs
[ 676.711146] ehci-pci 0000:00:13.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 19692 usecs
[ 676.711394] pcieport 0000:00:15.1: pci_pm_resume_noirq+0x0/0x130 returned 0 after 19689 usecs
[ 676.711461] ehci-pci 0000:00:12.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 20068 usecs
[ 676.711585] radeon 0000:00:01.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 20387 usecs
[ 676.711605] snd_hda_intel 0000:00:01.1: calling pci_pm_resume_noirq+0x0/0x130 @ 128, parent: pci0000:00
[ 676.711624] r8169 0000:03:00.0: calling pci_pm_resume_noirq+0x0/0x130 @ 519, parent: 0000:00:15.1
[ 676.730895] snd_hda_intel 0000:00:01.1: pci_pm_resume_noirq+0x0/0x130 returned 0 after 18813 usecs
[ 676.731149] r8169 0000:03:00.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 19059 usecs
[ 676.731823] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_resume_early+0x0/0x20 @ 497, parent: platform
[ 676.731842] coreboot_table_acpi BOOT0000:00: acpi_subsys_resume_early+0x0/0x20 returned 0 after 7 usecs
[ 676.732071] pci 0000:00:00.0: calling pci_pm_resume+0x0/0x100 @ 544, parent: pci0000:00
[ 676.732093] pci 0000:00:00.0: pci_pm_resume+0x0/0x100 returned 0 after 13 usecs
[ 676.732102] radeon 0000:00:01.0: calling pci_pm_resume+0x0/0x100 @ 544, parent: pci0000:00
[ 676.732397] thermal LNXTHERM:00: calling acpi_thermal_resume+0x0/0x280 [thermal] @ 497, parent: device:0b
[ 676.732419] thermal LNXTHERM:00: acpi_thermal_resume+0x0/0x280 [thermal] returned 0 after 13 usecs
[ 676.732462] button PNP0C0C:00: calling acpi_button_resume+0x0/0x90 [button] @ 497, parent: LNXSYBUS:00
[ 676.732472] button PNP0C0C:00: acpi_button_resume+0x0/0x90 [button] returned 0 after 3 usecs
[ 676.732478] [drm] Found smc ucode version: 0x00010601
[ 676.732534] ahci 0000:00:11.0: calling pci_pm_resume+0x0/0x100 @ 519, parent: pci0000:00
[ 676.733732] ahci 0000:00:11.0: pci_pm_resume+0x0/0x100 returned 0 after 1164 usecs
[ 676.733745] ohci-pci 0000:00:12.0: calling pci_pm_resume+0x0/0x100 @ 519, parent: pci0000:00
[ 676.733948] ehci-pci 0000:00:12.2: calling pci_pm_resume+0x0/0x100 @ 128, parent: pci0000:00
[ 676.734106] ohci-pci 0000:00:13.0: calling pci_pm_resume+0x0/0x100 @ 506, parent: pci0000:00
[ 676.734255] ehci-pci 0000:00:13.2: calling pci_pm_resume+0x0/0x100 @ 509, parent: pci0000:00
[ 676.734408] piix4_smbus 0000:00:14.0: calling pci_pm_resume+0x0/0x100 @ 524, parent: pci0000:00
[ 676.734418] piix4_smbus 0000:00:14.0: pci_pm_resume+0x0/0x100 returned 0 after 4 usecs
[ 676.734426] snd_hda_intel 0000:00:14.2: calling pci_pm_resume+0x0/0x100 @ 524, parent: pci0000:00
[ 676.734550] pci 0000:00:14.3: calling pci_pm_resume+0x0/0x100 @ 546, parent: pci0000:00
[ 676.734559] pci 0000:00:14.3: pci_pm_resume+0x0/0x100 returned 0 after 4 usecs
[ 676.734575] pci 0000:00:14.4: calling pci_pm_resume+0x0/0x100 @ 546, parent: pci0000:00
[ 676.734583] pci 0000:00:14.4: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.734592] ohci-pci 0000:00:14.5: calling pci_pm_resume+0x0/0x100 @ 546, parent: pci0000:00
[ 676.734863] pcieport 0000:00:15.1: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734885] pcieport 0000:00:15.1: pci_pm_resume+0x0/0x100 returned 0 after 16 usecs
[ 676.734893] pci 0000:00:18.0: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734902] pci 0000:00:18.0: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.734909] pci 0000:00:18.1: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734918] pci 0000:00:18.1: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.734926] pci 0000:00:18.2: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734935] pci 0000:00:18.2: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.734943] k10temp 0000:00:18.3: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734952] k10temp 0000:00:18.3: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.734959] pci 0000:00:18.4: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734967] pci 0000:00:18.4: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.734974] pci 0000:00:18.5: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734983] pci 0000:00:18.5: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.734991] pci 0000:00:18.6: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.734999] pci 0000:00:18.6: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.735006] pci 0000:00:18.7: calling pci_pm_resume+0x0/0x100 @ 508, parent: pci0000:00
[ 676.735014] pci 0000:00:18.7: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 676.735022] r8169 0000:03:00.0: calling pci_pm_resume+0x0/0x100 @ 508, parent: 0000:00:15.1
[ 676.741507] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
[ 676.741714] radeon 0000:00:01.0: WB enabled
[ 676.741722] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000018000c00 and cpu addr 0x2ebc320d
[ 676.741727] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000018000c0c and cpu addr 0xb29a6da6
[ 676.742518] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0x53642260
[ 676.742565] platform PNP0800:00: calling platform_pm_resume+0x0/0x80 @ 497, parent: 0000:00:14.3
[ 676.742575] platform PNP0800:00: platform_pm_resume+0x0/0x80 returned 0 after 3 usecs
[ 676.742581] platform PNP0C04:00: calling platform_pm_resume+0x0/0x80 @ 497, parent: 0000:00:14.3
[ 676.742591] platform PNP0C04:00: platform_pm_resume+0x0/0x80 returned 0 after 4 usecs
[ 676.742597] platform PNP0C0C:00: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.742605] platform PNP0C0C:00: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 676.742614] button LNXPWRBN:00: calling acpi_button_resume+0x0/0x90 [button] @ 497, parent: LNXSYSTM:00
[ 676.742640] button LNXPWRBN:00: acpi_button_resume+0x0/0x90 [button] returned 0 after 18 usecs
[ 676.742652] rtc_cmos 00:00: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 676.742810] rtc_cmos 00:00: pnp_bus_resume+0x0/0x100 returned 0 after 148 usecs
[ 676.742816] i8042 kbd 00:01: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 676.742825] i8042 kbd 00:01: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 676.742831] i8042 aux 00:02: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 676.742839] i8042 aux 00:02: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 676.742845] i8042 kbd 00:03: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 676.742853] i8042 kbd 00:03: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 676.742859] i8042 aux 00:04: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 676.742867] i8042 aux 00:04: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 676.742906] pcspkr pcspkr: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.742914] pcspkr pcspkr: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 676.742920] platform platform-framebuffer.0: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.742928] platform platform-framebuffer.0: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 676.742936] alarmtimer alarmtimer: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.742945] alarmtimer alarmtimer: platform_pm_resume+0x0/0x80 returned 0 after 4 usecs
[ 676.742958] serial8250 serial8250: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.742970] serial8250 serial8250: platform_pm_resume+0x0/0x80 returned 0 after 6 usecs
[ 676.742979] i8042 i8042: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.746219] i8042 i8042: platform_pm_resume+0x0/0x80 returned 0 after 3158 usecs
[ 676.746240] atkbd serio0: calling serio_resume+0x0/0xd0 @ 497, parent: i8042
[ 676.746263] atkbd serio0: serio_resume+0x0/0xd0 returned 0 after 17 usecs
[ 676.746358] rtc rtc0: calling rtc_resume+0x0/0x20 @ 497, parent: 00:00
[ 676.746366] rtc rtc0: rtc_resume+0x0/0x20 returned 0 after 3 usecs
[ 676.746387] platform microcode: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.746394] platform microcode: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 676.746404] input input0: calling input_dev_resume+0x0/0x50 @ 497, parent: serio0
[ 676.746421] input input0: input_dev_resume+0x0/0x50 returned 0 after 11 usecs
[ 676.746438] leds input0::numlock: calling led_resume+0x0/0x50 @ 497, parent: input0
[ 676.746446] leds input0::numlock: led_resume+0x0/0x50 returned 0 after 3 usecs
[ 676.746451] leds input0::capslock: calling led_resume+0x0/0x50 @ 497, parent: input0
[ 676.746458] leds input0::capslock: led_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.746464] leds input0::scrolllock: calling led_resume+0x0/0x50 @ 497, parent: input0
[ 676.746471] leds input0::scrolllock: led_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.746501] input input2: calling input_dev_resume+0x0/0x50 @ 497, parent: PNP0C0C:00
[ 676.746509] input input2: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.746515] input input3: calling input_dev_resume+0x0/0x50 @ 497, parent: LNXPWRBN:00
[ 676.746523] input input3: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.746609] ata1: calling ata_port_pm_resume+0x0/0x60 [libata] @ 523, parent: 0000:00:11.0
[ 676.746677] ata1: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 49 usecs
[ 676.746697] ata2: calling ata_port_pm_resume+0x0/0x60 [libata] @ 523, parent: 0000:00:11.0
[ 676.746725] ata2: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 11 usecs
[ 676.746744] ata3: calling ata_port_pm_resume+0x0/0x60 [libata] @ 523, parent: 0000:00:11.0
[ 676.746771] ata3: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 10 usecs
[ 676.746789] ata4: calling ata_port_pm_resume+0x0/0x60 [libata] @ 523, parent: 0000:00:11.0
[ 676.746816] ata4: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 10 usecs
[ 676.746835] ata5: calling ata_port_pm_resume+0x0/0x60 [libata] @ 523, parent: 0000:00:11.0
[ 676.746864] ata5: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 12 usecs
[ 676.746883] ata6: calling ata_port_pm_resume+0x0/0x60 [libata] @ 523, parent: 0000:00:11.0
[ 676.746910] ata6: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 10 usecs
[ 676.746936] scsi host0: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: ata1
[ 676.746957] scsi host0: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 676.746981] scsi host1: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: ata2
[ 676.747001] scsi host1: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 676.747024] scsi host2: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: ata3
[ 676.747044] scsi host2: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 676.747066] scsi host3: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: ata4
[ 676.747086] scsi host3: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 676.747107] scsi host4: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: ata5
[ 676.747127] scsi host4: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 676.747150] scsi host5: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: ata6
[ 676.747169] scsi host5: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 676.747191] scsi target0:0:0: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: host0
[ 676.747211] scsi target0:0:0: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 676.747231] sd 0:0:0:0: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 523, parent: target0:0:0
[ 676.747465] snd_hda_intel 0000:00:14.2: pci_pm_resume+0x0/0x100 returned 0 after 12724 usecs
[ 676.752054] snd_hda_codec_realtek hdaudioC1D0: calling pm_runtime_force_resume+0x0/0x170 @ 527, parent: 0000:00:14.2
[ 676.758732] ohci-pci 0000:00:13.0: pci_pm_resume+0x0/0x100 returned 0 after 24027 usecs
[ 676.758773] ohci-pci 0000:00:12.0: pci_pm_resume+0x0/0x100 returned 0 after 24433 usecs
[ 676.758885] ehci-pci 0000:00:13.2: pci_pm_resume+0x0/0x100 returned 0 after 24045 usecs
[ 676.758914] ehci-pci 0000:00:12.2: pci_pm_resume+0x0/0x100 returned 0 after 24374 usecs
[ 676.758962] usb usb1: calling usb_dev_resume+0x0/0x20 [usbcore] @ 506, parent: 0000:00:12.2
[ 676.759107] usb usb2: calling usb_dev_resume+0x0/0x20 [usbcore] @ 535, parent: 0000:00:13.2
[ 676.759346] usb usb3: calling usb_dev_resume+0x0/0x20 [usbcore] @ 129, parent: 0000:00:12.0
[ 676.759507] usb usb4: calling usb_dev_resume+0x0/0x20 [usbcore] @ 521, parent: 0000:00:13.0
[ 676.759712] sd 0:0:0:0: [sda] Starting disk
[ 676.760017] usb usb2: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 863 usecs
[ 676.760104] [drm] ring test on 0 succeeded in 1 usecs
[ 676.760114] [drm] ring test on 3 succeeded in 3 usecs
[ 676.762733] ohci-pci 0000:00:14.5: pci_pm_resume+0x0/0x100 returned 0 after 27463 usecs
[ 676.770090] usb usb5: calling usb_dev_resume+0x0/0x20 [usbcore] @ 534, parent: 0000:00:14.5
[ 676.778735] r8169 0000:03:00.0: pci_pm_resume+0x0/0x100 returned 0 after 42666 usecs
[ 676.787072] usb usb1: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 27412 usecs
[ 676.806092] [drm] ring test on 5 succeeded in 1 usecs
[ 676.808881] r8169 0000:03:00.0 enp3s0: link down
[ 676.826049] [drm] UVD initialized successfully.
[ 676.826183] [drm] ib test on ring 0 succeeded in 0 usecs
[ 676.826346] [drm] ib test on ring 3 succeeded in 0 usecs
[ 676.837872] usb usb4: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 76503 usecs
[ 676.846922] usb usb5: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 74991 usecs
[ 676.850439] usb usb3: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 88934 usecs
[ 676.850813] usb 3-2: calling usb_dev_resume+0x0/0x20 [usbcore] @ 133, parent: usb3
[ 676.852005] [drm] ib test on ring 5 succeeded
[ 676.919137] snd_hda_codec_realtek hdaudioC1D0: pm_runtime_force_resume+0x0/0x170 returned 0 after 163139 usecs
[ 676.956713] radeon 0000:00:01.0: pci_pm_resume+0x0/0x100 returned 0 after 219320 usecs
[ 676.956780] snd_hda_intel 0000:00:01.1: calling pci_pm_resume+0x0/0x100 @ 7, parent: pci0000:00
[ 676.956816] usb 3-2: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 103487 usecs
[ 676.959534] snd_hda_intel 0000:00:01.1: pci_pm_resume+0x0/0x100 returned 0 after 2658 usecs
[ 676.959623] input input4: calling input_dev_resume+0x0/0x50 @ 497, parent: card0
[ 676.959640] snd_hda_codec_hdmi hdaudioC0D0: calling pm_runtime_force_resume+0x0/0x170 @ 524, parent: 0000:00:01.1
[ 676.959648] input input4: input_dev_resume+0x0/0x50 returned 0 after 12 usecs
[ 676.959672] sp5100-tco sp5100-tco: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 676.959685] sp5100-tco sp5100-tco: platform_pm_resume+0x0/0x80 returned 0 after 3 usecs
[ 676.959699] input input5: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959735] input input5: input_dev_resume+0x0/0x50 returned 0 after 21 usecs
[ 676.959749] input input6: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959757] input input6: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959768] input input7: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959776] input input7: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959782] input input8: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959788] snd_hda_codec_hdmi hdaudioC0D0: pm_runtime_force_resume+0x0/0x170 returned 0 after 133 usecs
[ 676.959793] input input8: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959800] input input9: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959807] input input9: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959814] input input10: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959853] input input10: input_dev_resume+0x0/0x50 returned 0 after 32 usecs
[ 676.959860] input input11: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959868] input input11: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959875] input input12: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959882] input input12: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959889] input input13: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 676.959897] input input13: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959907] input input14: calling input_dev_resume+0x0/0x50 @ 497, parent: pcspkr
[ 676.959925] input input14: input_dev_resume+0x0/0x50 returned 0 after 12 usecs
[ 676.959951] input input16: calling input_dev_resume+0x0/0x50 @ 497, parent: 0003:1241:1122.0001
[ 676.959959] input input16: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 676.959980] serio serio1: calling serio_resume+0x0/0xd0 @ 497, parent: i8042
[ 676.960006] serio serio1: serio_resume+0x0/0xd0 returned 0 after 19 usecs
[ 677.059339] ata4: SATA link down (SStatus 0 SControl 300)
[ 677.059401] ata3: SATA link down (SStatus 0 SControl 300)
[ 677.059439] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 677.059483] ata5: SATA link down (SStatus 0 SControl 300)
[ 677.062297] ata1.00: configured for UDMA/133
[ 677.063101] sd 0:0:0:0: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 308435 usecs
[ 677.066891] ata2: SATA link down (SStatus 0 SControl 300)
[ 677.066946] ata6: SATA link down (SStatus 0 SControl 300)
[ 677.077954] OOM killer enabled.
[ 677.077957] Restarting tasks ... done.
[ 677.139874] PM: suspend exit
[ 678.490993] kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
[ 679.517022] r8169 0000:03:00.0 enp3s0: link up
[ 688.588511] PM: suspend entry (deep)
[ 688.588523] PM: Syncing filesystems ... done.
[ 689.396658] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 689.398570] OOM killer disabled.
[ 689.398597] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 689.400244] Suspending console(s) (use no_console_suspend to debug)
[ 689.401859] serio serio1: calling serio_suspend+0x0/0x20 @ 497, parent: i8042
[ 689.401873] serio serio1: serio_suspend+0x0/0x20 returned 0 after 6 usecs
[ 689.401908] input input16: calling input_dev_suspend+0x0/0x80 @ 497, parent: 0003:1241:1122.0001
[ 689.401918] input input16: input_dev_suspend+0x0/0x80 returned 0 after 4 usecs
[ 689.402223] input input14: calling input_dev_suspend+0x0/0x80 @ 497, parent: pcspkr
[ 689.402233] input input14: input_dev_suspend+0x0/0x80 returned 0 after 4 usecs
[ 689.402300] usb 3-2: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 533, parent: usb3
[ 689.402305] input input13: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402314] input input13: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402321] input input12: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402329] input input12: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402337] input input11: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402344] input input11: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402352] input input10: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402359] input input10: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402367] input input9: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402374] input input9: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402381] input input8: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402389] input input8: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402397] input input7: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402404] input input7: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402411] input input6: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402419] input input6: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402430] input input5: calling input_dev_suspend+0x0/0x80 @ 497, parent: card1
[ 689.402438] input input5: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402452] sp5100-tco sp5100-tco: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.402460] sp5100-tco sp5100-tco: platform_pm_suspend+0x0/0xa0 returned 0 after 3 usecs
[ 689.402469] input input4: calling input_dev_suspend+0x0/0x80 @ 497, parent: card0
[ 689.402477] input input4: input_dev_suspend+0x0/0x80 returned 0 after 2 usecs
[ 689.402526] usb usb5: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 523, parent: 0000:00:14.5
[ 689.402531] input input3: calling input_dev_suspend+0x0/0x80 @ 497, parent: LNXPWRBN:00
[ 689.402540] input input3: input_dev_suspend+0x0/0x80 returned 0 after 3 usecs
[ 689.402547] input input2: calling input_dev_suspend+0x0/0x80 @ 497, parent: PNP0C0C:00
[ 689.402555] input input2: input_dev_suspend+0x0/0x80 returned 0 after 3 usecs
[ 689.402900] usb usb2: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 133, parent: 0000:00:13.2
[ 689.402973] usb usb1: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 7, parent: 0000:00:12.2
[ 689.403112] snd_hda_codec_realtek hdaudioC1D0: calling pm_runtime_force_suspend+0x0/0x120 @ 559, parent: 0000:00:14.2
[ 689.403166] usb usb4: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 544, parent: 0000:00:13.0
[ 689.403265] snd_hda_codec_hdmi hdaudioC0D0: calling pm_runtime_force_suspend+0x0/0x120 @ 507, parent: 0000:00:01.1
[ 689.403353] sd 0:0:0:0: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 527, parent: target0:0:0
[ 689.403382] scsi host5: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 131, parent: ata6
[ 689.403405] scsi host5: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 4 usecs
[ 689.403451] usb 3-2: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 1073 usecs
[ 689.403469] scsi host4: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 131, parent: ata5
[ 689.403489] scsi host4: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 689.403525] scsi host3: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 533, parent: ata4
[ 689.403543] scsi host2: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 131, parent: ata3
[ 689.403576] scsi host3: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 6 usecs
[ 689.403593] scsi host2: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 689.403628] scsi host1: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 533, parent: ata2
[ 689.403656] ata6: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 518, parent: 0000:00:11.0
[ 689.403689] scsi host1: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 5 usecs
[ 689.403753] usb usb3: calling usb_dev_suspend+0x0/0x20 [usbcore] @ 524, parent: 0000:00:12.0
[ 689.403814] ata6: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 137 usecs
[ 689.403873] usb usb3: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 69 usecs
[ 689.403987] ata5: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 524, parent: 0000:00:11.0
[ 689.404005] ata4: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 518, parent: 0000:00:11.0
[ 689.404072] ata3: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 533, parent: 0000:00:11.0
[ 689.404177] ata2: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 510, parent: 0000:00:11.0
[ 689.404269] ata5: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 239 usecs
[ 689.404286] ata2: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 66 usecs
[ 689.404321] ata3: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 209 usecs
[ 689.404338] ata4: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 283 usecs
[ 689.404383] leds input0::scrolllock: calling led_suspend+0x0/0x50 @ 497, parent: input0
[ 689.404392] leds input0::scrolllock: led_suspend+0x0/0x50 returned 0 after 3 usecs
[ 689.404399] leds input0::capslock: calling led_suspend+0x0/0x50 @ 497, parent: input0
[ 689.404407] leds input0::capslock: led_suspend+0x0/0x50 returned 0 after 2 usecs
[ 689.404413] leds input0::numlock: calling led_suspend+0x0/0x50 @ 497, parent: input0
[ 689.404420] leds input0::numlock: led_suspend+0x0/0x50 returned 0 after 2 usecs
[ 689.404430] input input0: calling input_dev_suspend+0x0/0x80 @ 497, parent: serio0
[ 689.404442] input input0: input_dev_suspend+0x0/0x80 returned 0 after 6 usecs
[ 689.404455] platform microcode: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.404463] platform microcode: platform_pm_suspend+0x0/0xa0 returned 0 after 3 usecs
[ 689.404504] rtc rtc0: calling rtc_suspend+0x0/0x20 @ 497, parent: 00:00
[ 689.404512] rtc rtc0: rtc_suspend+0x0/0x20 returned 0 after 3 usecs
[ 689.404520] atkbd serio0: calling serio_suspend+0x0/0x20 @ 497, parent: i8042
[ 689.408081] atkbd serio0: serio_suspend+0x0/0x20 returned 0 after 3452 usecs
[ 689.408104] i8042 i8042: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.411244] i8042 i8042: platform_pm_suspend+0x0/0xa0 returned 0 after 3058 usecs
[ 689.411262] serial8250 serial8250: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.411275] serial8250 serial8250: platform_pm_suspend+0x0/0xa0 returned 0 after 7 usecs
[ 689.411329] alarmtimer alarmtimer: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.411339] alarmtimer alarmtimer: platform_pm_suspend+0x0/0xa0 returned 0 after 4 usecs
[ 689.411349] platform platform-framebuffer.0: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.411356] platform platform-framebuffer.0: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 689.411364] pcspkr pcspkr: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.411419] pcspkr pcspkr: platform_pm_suspend+0x0/0xa0 returned 0 after 48 usecs
[ 689.411509] i8042 aux 00:04: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 689.411519] i8042 aux 00:04: pnp_bus_suspend+0x0/0x20 returned 0 after 4 usecs
[ 689.411526] i8042 kbd 00:03: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 689.411535] i8042 kbd 00:03: pnp_bus_suspend+0x0/0x20 returned 0 after 3 usecs
[ 689.411542] i8042 aux 00:02: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 689.411550] i8042 aux 00:02: pnp_bus_suspend+0x0/0x20 returned 0 after 2 usecs
[ 689.411556] i8042 kbd 00:01: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 689.411564] i8042 kbd 00:01: pnp_bus_suspend+0x0/0x20 returned 0 after 2 usecs
[ 689.411572] rtc_cmos 00:00: calling pnp_bus_suspend+0x0/0x20 @ 497, parent: pnp0
[ 689.411681] rtc_cmos 00:00: pnp_bus_suspend+0x0/0x20 returned 0 after 101 usecs
[ 689.411698] button LNXPWRBN:00: calling acpi_button_suspend+0x0/0x40 [button] @ 497, parent: LNXSYSTM:00
[ 689.411707] button LNXPWRBN:00: acpi_button_suspend+0x0/0x40 [button] returned 0 after 3 usecs
[ 689.411723] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_suspend+0x0/0x70 @ 497, parent: platform
[ 689.411733] coreboot_table_acpi BOOT0000:00: acpi_subsys_suspend+0x0/0x70 returned 0 after 4 usecs
[ 689.411740] platform PNP0C0C:00: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: platform
[ 689.411747] platform PNP0C0C:00: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 689.411754] platform PNP0C04:00: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: 0000:00:14.3
[ 689.411761] platform PNP0C04:00: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 689.411767] platform PNP0800:00: calling platform_pm_suspend+0x0/0xa0 @ 497, parent: 0000:00:14.3
[ 689.411774] platform PNP0800:00: platform_pm_suspend+0x0/0xa0 returned 0 after 2 usecs
[ 689.411890] button PNP0C0C:00: calling acpi_button_suspend+0x0/0x40 [button] @ 497, parent: LNXSYBUS:00
[ 689.411899] button PNP0C0C:00: acpi_button_suspend+0x0/0x40 [button] returned 0 after 3 usecs
[ 689.411953] thermal LNXTHERM:00: calling acpi_thermal_suspend+0x0/0x20 [thermal] @ 497, parent: device:0b
[ 689.411964] thermal LNXTHERM:00: acpi_thermal_suspend+0x0/0x20 [thermal] returned 0 after 5 usecs
[ 689.412014] r8169 0000:03:00.0: calling pci_pm_suspend+0x0/0x1e0 @ 510, parent: 0000:00:15.1
[ 689.412129] pci 0000:00:18.7: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412139] pci 0000:00:18.7: pci_pm_suspend+0x0/0x1e0 returned 0 after 4 usecs
[ 689.412159] pci 0000:00:18.6: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412167] pci 0000:00:18.6: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412175] pci 0000:00:18.5: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412182] pci 0000:00:18.5: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412190] pci 0000:00:18.4: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412197] pci 0000:00:18.4: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412206] k10temp 0000:00:18.3: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412214] k10temp 0000:00:18.3: pci_pm_suspend+0x0/0x1e0 returned 0 after 3 usecs
[ 689.412222] pci 0000:00:18.2: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412229] pci 0000:00:18.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412237] pci 0000:00:18.1: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412244] pci 0000:00:18.1: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412253] pci 0000:00:18.0: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412260] pci 0000:00:18.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412295] pci 0000:00:14.4: calling pci_pm_suspend+0x0/0x1e0 @ 515, parent: pci0000:00
[ 689.412303] pci 0000:00:14.4: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412311] pci 0000:00:14.3: calling pci_pm_suspend+0x0/0x1e0 @ 515, parent: pci0000:00
[ 689.412318] pci 0000:00:14.3: pci_pm_suspend+0x0/0x1e0 returned 0 after 2 usecs
[ 689.412339] piix4_smbus 0000:00:14.0: calling pci_pm_suspend+0x0/0x1e0 @ 530, parent: pci0000:00
[ 689.412347] piix4_smbus 0000:00:14.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 3 usecs
[ 689.412496] r8169 0000:03:00.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 453 usecs
[ 689.412563] ohci-pci 0000:00:12.0: calling pci_pm_suspend+0x0/0x1e0 @ 510, parent: pci0000:00
[ 689.412639] ohci-pci 0000:00:12.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 63 usecs
[ 689.412682] pcieport 0000:00:15.1: calling pci_pm_suspend+0x0/0x1e0 @ 524, parent: pci0000:00
[ 689.412719] pci 0000:00:00.0: calling pci_pm_suspend+0x0/0x1e0 @ 534, parent: pci0000:00
[ 689.412737] pci 0000:00:00.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 7 usecs
[ 689.412797] pcieport 0000:00:15.1: pci_pm_suspend+0x0/0x1e0 returned 0 after 103 usecs
[ 689.415523] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 689.415920] sd 0:0:0:0: [sda] Stopping disk
[ 689.419049] usb usb2: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 15724 usecs
[ 689.419158] ehci-pci 0000:00:13.2: calling pci_pm_suspend+0x0/0x1e0 @ 530, parent: pci0000:00
[ 689.422459] sd 0:0:0:0: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 18593 usecs
[ 689.422608] scsi target0:0:0: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 129, parent: host0
[ 689.422735] scsi target0:0:0: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 101 usecs
[ 689.422939] scsi host0: calling scsi_bus_suspend+0x0/0x20 [scsi_mod] @ 131, parent: ata1
[ 689.422997] scsi host0: scsi_bus_suspend+0x0/0x20 [scsi_mod] returned 0 after 18 usecs
[ 689.423169] ata1: calling ata_port_pm_suspend+0x0/0x80 [libata] @ 518, parent: 0000:00:11.0
[ 689.423388] ata1: ata_port_pm_suspend+0x0/0x80 [libata] returned 0 after 180 usecs
[ 689.423463] ahci 0000:00:11.0: calling pci_pm_suspend+0x0/0x1e0 @ 510, parent: pci0000:00
[ 689.423486] ahci 0000:00:11.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 12 usecs
[ 689.433084] usb usb1: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 29332 usecs
[ 689.433237] ehci-pci 0000:00:12.2: calling pci_pm_suspend+0x0/0x1e0 @ 516, parent: pci0000:00
[ 689.439106] ehci-pci 0000:00:13.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 19453 usecs
[ 689.451089] ehci-pci 0000:00:12.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 17402 usecs
[ 689.479414] usb usb4: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 74414 usecs
[ 689.479472] usb usb5: usb_dev_suspend+0x0/0x20 [usbcore] returned 0 after 75037 usecs
[ 689.479484] ohci-pci 0000:00:13.0: calling pci_pm_suspend+0x0/0x1e0 @ 542, parent: pci0000:00
[ 689.479583] ohci-pci 0000:00:13.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 91 usecs
[ 689.479611] ohci-pci 0000:00:14.5: calling pci_pm_suspend+0x0/0x1e0 @ 545, parent: pci0000:00
[ 689.479627] ohci-pci 0000:00:14.5: pci_pm_suspend+0x0/0x1e0 returned 0 after 9 usecs
[ 689.511078] snd_hda_codec_hdmi hdaudioC0D0: pm_runtime_force_suspend+0x0/0x120 returned 0 after 105244 usecs
[ 689.511300] snd_hda_intel 0000:00:01.1: calling pci_pm_suspend+0x0/0x1e0 @ 533, parent: pci0000:00
[ 689.511467] snd_hda_intel 0000:00:01.1: pci_pm_suspend+0x0/0x1e0 returned 0 after 153 usecs
[ 689.511562] radeon 0000:00:01.0: calling pci_pm_suspend+0x0/0x1e0 @ 537, parent: pci0000:00
[ 689.632112] snd_hda_codec_realtek hdaudioC1D0: pm_runtime_force_suspend+0x0/0x120 returned 0 after 223592 usecs
[ 689.632257] snd_hda_intel 0000:00:14.2: calling pci_pm_suspend+0x0/0x1e0 @ 515, parent: pci0000:00
[ 689.633505] snd_hda_intel 0000:00:14.2: pci_pm_suspend+0x0/0x1e0 returned 0 after 1204 usecs
[ 689.746877] radeon 0000:00:01.0: pci_pm_suspend+0x0/0x1e0 returned 0 after 229772 usecs
[ 689.748273] snd_hda_intel 0000:00:01.1: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748303] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_suspend_late+0x0/0x80 @ 497, parent: platform
[ 689.748310] snd_hda_intel 0000:00:01.1: pci_pm_suspend_late+0x0/0x40 returned 0 after 14 usecs
[ 689.748335] coreboot_table_acpi BOOT0000:00: acpi_subsys_suspend_late+0x0/0x80 returned 0 after 12 usecs
[ 689.748455] pci 0000:00:18.7: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748465] pci 0000:00:18.7: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 689.748476] pci 0000:00:18.6: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748484] pci 0000:00:18.6: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748493] pci 0000:00:18.5: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748501] pci 0000:00:18.5: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748511] pci 0000:00:18.4: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748519] pci 0000:00:18.4: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748530] k10temp 0000:00:18.3: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748538] k10temp 0000:00:18.3: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 689.748548] pci 0000:00:18.2: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748555] pci 0000:00:18.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748565] pci 0000:00:18.1: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748572] pci 0000:00:18.1: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748584] pci 0000:00:18.0: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748591] pci 0000:00:18.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748624] ohci-pci 0000:00:14.5: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748633] ohci-pci 0000:00:14.5: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 689.748643] pci 0000:00:14.4: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748650] pci 0000:00:14.4: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748661] pci 0000:00:14.3: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748668] pci 0000:00:14.3: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748678] snd_hda_intel 0000:00:14.2: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748686] snd_hda_intel 0000:00:14.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748698] piix4_smbus 0000:00:14.0: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748706] piix4_smbus 0000:00:14.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 689.748715] ehci-pci 0000:00:13.2: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748723] ehci-pci 0000:00:13.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748732] ohci-pci 0000:00:13.0: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748739] ohci-pci 0000:00:13.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748786] ohci-pci 0000:00:12.0: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748800] ehci-pci 0000:00:12.2: calling pci_pm_suspend_late+0x0/0x40 @ 559, parent: pci0000:00
[ 689.748804] ohci-pci 0000:00:12.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748816] ahci 0000:00:11.0: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748825] ehci-pci 0000:00:12.2: pci_pm_suspend_late+0x0/0x40 returned 0 after 9 usecs
[ 689.748829] ahci 0000:00:11.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 689.748841] pci 0000:00:00.0: calling pci_pm_suspend_late+0x0/0x40 @ 534, parent: pci0000:00
[ 689.748853] radeon 0000:00:01.0: calling pci_pm_suspend_late+0x0/0x40 @ 559, parent: pci0000:00
[ 689.748858] pci 0000:00:00.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 2 usecs
[ 689.748871] radeon 0000:00:01.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 6 usecs
[ 689.748876] r8169 0000:03:00.0: calling pci_pm_suspend_late+0x0/0x40 @ 537, parent: 0000:00:15.1
[ 689.748885] r8169 0000:03:00.0: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 689.748902] pcieport 0000:00:15.1: calling pci_pm_suspend_late+0x0/0x40 @ 515, parent: pci0000:00
[ 689.748910] pcieport 0000:00:15.1: pci_pm_suspend_late+0x0/0x40 returned 0 after 3 usecs
[ 689.749862] snd_hda_intel 0000:00:01.1: calling pci_pm_suspend_noirq+0x0/0x310 @ 534, parent: pci0000:00
[ 689.749902] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_suspend_noirq+0x0/0xb0 @ 497, parent: platform
[ 689.749914] coreboot_table_acpi BOOT0000:00: acpi_subsys_suspend_noirq+0x0/0xb0 returned 0 after 4 usecs
[ 689.750027] r8169 0000:03:00.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 537, parent: 0000:00:15.1
[ 689.750166] pci 0000:00:18.7: calling pci_pm_suspend_noirq+0x0/0x310 @ 515, parent: pci0000:00
[ 689.750238] pci 0000:00:18.7: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 64 usecs
[ 689.750261] pci 0000:00:18.6: calling pci_pm_suspend_noirq+0x0/0x310 @ 515, parent: pci0000:00
[ 689.750283] pci 0000:00:18.5: calling pci_pm_suspend_noirq+0x0/0x310 @ 533, parent: pci0000:00
[ 689.750288] pci 0000:00:18.6: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 20 usecs
[ 689.750296] pci 0000:00:18.4: calling pci_pm_suspend_noirq+0x0/0x310 @ 515, parent: pci0000:00
[ 689.750347] pci 0000:00:18.5: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 49 usecs
[ 689.750351] pci 0000:00:18.4: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 40 usecs
[ 689.750362] pci 0000:00:18.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 515, parent: pci0000:00
[ 689.750371] k10temp 0000:00:18.3: calling pci_pm_suspend_noirq+0x0/0x310 @ 533, parent: pci0000:00
[ 689.750395] pci 0000:00:18.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 26 usecs
[ 689.750404] pci 0000:00:18.1: calling pci_pm_suspend_noirq+0x0/0x310 @ 515, parent: pci0000:00
[ 689.750428] k10temp 0000:00:18.3: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 43 usecs
[ 689.750436] pci 0000:00:18.1: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 25 usecs
[ 689.750447] pci 0000:00:18.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 533, parent: pci0000:00
[ 689.750491] pci 0000:00:18.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 31 usecs
[ 689.750532] ohci-pci 0000:00:14.5: calling pci_pm_suspend_noirq+0x0/0x310 @ 533, parent: pci0000:00
[ 689.750997] ohci-pci 0000:00:14.5: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 439 usecs
[ 689.751029] pci 0000:00:14.4: calling pci_pm_suspend_noirq+0x0/0x310 @ 533, parent: pci0000:00
[ 689.751149] pci 0000:00:14.4: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 105 usecs
[ 689.751176] pci 0000:00:14.3: calling pci_pm_suspend_noirq+0x0/0x310 @ 533, parent: pci0000:00
[ 689.751296] pci 0000:00:14.3: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 105 usecs
[ 689.751325] snd_hda_intel 0000:00:14.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 533, parent: pci0000:00
[ 689.751484] piix4_smbus 0000:00:14.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 559, parent: pci0000:00
[ 689.751528] ehci-pci 0000:00:13.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 507, parent: pci0000:00
[ 689.751634] piix4_smbus 0000:00:14.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 135 usecs
[ 689.751667] ohci-pci 0000:00:13.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 559, parent: pci0000:00
[ 689.751770] ehci-pci 0000:00:12.2: calling pci_pm_suspend_noirq+0x0/0x310 @ 545, parent: pci0000:00
[ 689.751847] ohci-pci 0000:00:13.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 162 usecs
[ 689.751866] ohci-pci 0000:00:12.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 559, parent: pci0000:00
[ 689.751978] ahci 0000:00:11.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 542, parent: pci0000:00
[ 689.752023] ahci 0000:00:11.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 37 usecs
[ 689.752079] ohci-pci 0000:00:12.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 194 usecs
[ 689.752109] pci 0000:00:00.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 559, parent: pci0000:00
[ 689.752151] pci 0000:00:00.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 30 usecs
[ 689.767287] snd_hda_intel 0000:00:01.1: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 16985 usecs
[ 689.767316] r8169 0000:03:00.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 16831 usecs
[ 689.767338] radeon 0000:00:01.0: calling pci_pm_suspend_noirq+0x0/0x310 @ 542, parent: pci0000:00
[ 689.767351] radeon 0000:00:01.0: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 6 usecs
[ 689.767379] pcieport 0000:00:15.1: calling pci_pm_suspend_noirq+0x0/0x310 @ 515, parent: pci0000:00
[ 689.771052] ehci-pci 0000:00:12.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 18802 usecs
[ 689.771080] ehci-pci 0000:00:13.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 19037 usecs
[ 689.775051] snd_hda_intel 0000:00:14.2: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 23130 usecs
[ 689.787034] pcieport 0000:00:15.1: pci_pm_suspend_noirq+0x0/0x310 returned 0 after 19167 usecs
[ 689.787212] ACPI: Preparing to enter system sleep state S3
[ 689.788432] PM: Saving platform NVS memory
[ 689.788450] Disabling non-boot CPUs ...
[ 689.805907] smpboot: CPU 1 is now offline
[ 689.806903] PM: Calling kvm_suspend+0x0/0x30 [kvm]
[ 689.806914] PM: Calling mce_syscore_suspend+0x0/0x30
[ 689.806920] PM: Calling ledtrig_cpu_syscore_suspend+0x0/0x20
[ 689.806926] PM: Calling timekeeping_suspend+0x0/0x500
[ 689.807027] PM: Calling irq_gc_suspend+0x0/0x90
[ 689.807033] PM: Calling save_ioapic_entries+0x0/0x260
[ 689.807092] PM: Calling i8259A_suspend+0x0/0x30
[ 689.807099] PM: Calling perf_ibs_suspend+0x0/0x20
[ 689.807104] PM: Calling fw_suspend+0x0/0x20
[ 689.807110] PM: Calling acpi_save_bm_rld+0x0/0x20
[ 689.807119] PM: Calling lapic_suspend+0x0/0x310
[ 689.807369] ACPI: Low-level resume complete
[ 689.807606] PM: Restoring platform NVS memory
[ 689.807628] PM: Calling bsp_resume+0x0/0x30
[ 689.807633] PM: Calling lapic_resume+0x0/0x4c0
[ 689.807652] PM: Calling acpi_restore_bm_rld+0x0/0x60
[ 689.807659] PM: Calling irqrouter_resume+0x0/0x60
[ 689.807665] PM: Calling perf_ibs_resume+0x0/0x2c
[ 689.807669] LVT offset 0 assigned for vector 0x400
[ 689.807673] PM: Calling i8259A_resume+0x0/0x30
[ 689.807874] PM: Calling i8237A_resume+0x0/0xc0
[ 689.807929] PM: Calling ioapic_resume+0x0/0x1e0
[ 689.807944] PM: Calling irq_gc_resume+0x0/0x90
[ 689.807948] PM: Calling irq_pm_syscore_resume+0x0/0x20
[ 689.807978] PM: Calling timekeeping_resume+0x0/0x420
[ 689.808048] PM: Calling ledtrig_cpu_syscore_resume+0x0/0x20
[ 689.808053] PM: Calling mce_syscore_resume+0x0/0x30
[ 689.808066] PM: Calling mc_bp_resume+0x0/0x140
[ 689.808118] PM: Calling kvm_resume+0x0/0x40 [kvm]
[ 689.808244] Enabling non-boot CPUs ...
[ 689.811366] x86: Booting SMP configuration:
[ 689.811371] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 689.811517] Initializing CPU#1
[ 689.814543] cache: parent cpu1 should not be sleeping
[ 689.815073] microcode: CPU1: patch_level=0x05000119
[ 689.815736] CPU1 is up
[ 689.816194] ACPI: Waking up from system sleep state S3
[ 689.817330] pci 0000:00:00.0: calling pci_pm_resume_noirq+0x0/0x130 @ 559, parent: pci0000:00
[ 689.817377] pci 0000:00:00.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 37 usecs
[ 689.817390] radeon 0000:00:01.0: calling pci_pm_resume_noirq+0x0/0x130 @ 559, parent: pci0000:00
[ 689.817423] ahci 0000:00:11.0: calling pci_pm_resume_noirq+0x0/0x130 @ 515, parent: pci0000:00
[ 689.817537] ahci 0000:00:11.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 105 usecs
[ 689.817548] ohci-pci 0000:00:12.0: calling pci_pm_resume_noirq+0x0/0x130 @ 515, parent: pci0000:00
[ 689.817585] ohci-pci 0000:00:12.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 31 usecs
[ 689.817595] ehci-pci 0000:00:12.2: calling pci_pm_resume_noirq+0x0/0x130 @ 515, parent: pci0000:00
[ 689.817617] ohci-pci 0000:00:13.0: calling pci_pm_resume_noirq+0x0/0x130 @ 533, parent: pci0000:00
[ 689.817655] ohci-pci 0000:00:13.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 31 usecs
[ 689.817664] ehci-pci 0000:00:13.2: calling pci_pm_resume_noirq+0x0/0x130 @ 533, parent: pci0000:00
[ 689.817688] piix4_smbus 0000:00:14.0: calling pci_pm_resume_noirq+0x0/0x130 @ 507, parent: pci0000:00
[ 689.817725] piix4_smbus 0000:00:14.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 30 usecs
[ 689.817734] snd_hda_intel 0000:00:14.2: calling pci_pm_resume_noirq+0x0/0x130 @ 507, parent: pci0000:00
[ 689.817765] pci 0000:00:14.3: calling pci_pm_resume_noirq+0x0/0x130 @ 545, parent: pci0000:00
[ 689.817783] pci 0000:00:14.4: calling pci_pm_resume_noirq+0x0/0x130 @ 542, parent: pci0000:00
[ 689.817839] pci 0000:00:14.3: pci_pm_resume_noirq+0x0/0x130 returned 0 after 64 usecs
[ 689.817848] pci 0000:00:14.4: pci_pm_resume_noirq+0x0/0x130 returned 0 after 57 usecs
[ 689.817860] ohci-pci 0000:00:14.5: calling pci_pm_resume_noirq+0x0/0x130 @ 545, parent: pci0000:00
[ 689.817865] pcieport 0000:00:15.1: calling pci_pm_resume_noirq+0x0/0x130 @ 542, parent: pci0000:00
[ 689.817900] pci 0000:00:18.1: calling pci_pm_resume_noirq+0x0/0x130 @ 534, parent: pci0000:00
[ 689.817904] ohci-pci 0000:00:14.5: pci_pm_resume_noirq+0x0/0x130 returned 0 after 35 usecs
[ 689.817914] pci 0000:00:18.2: calling pci_pm_resume_noirq+0x0/0x130 @ 545, parent: pci0000:00
[ 689.817934] pci 0000:00:18.1: pci_pm_resume_noirq+0x0/0x130 returned 0 after 27 usecs
[ 689.817944] k10temp 0000:00:18.3: calling pci_pm_resume_noirq+0x0/0x130 @ 534, parent: pci0000:00
[ 689.817949] pci 0000:00:18.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 26 usecs
[ 689.817958] pci 0000:00:18.4: calling pci_pm_resume_noirq+0x0/0x130 @ 545, parent: pci0000:00
[ 689.817981] k10temp 0000:00:18.3: pci_pm_resume_noirq+0x0/0x130 returned 0 after 29 usecs
[ 689.817990] pci 0000:00:18.5: calling pci_pm_resume_noirq+0x0/0x130 @ 534, parent: pci0000:00
[ 689.817994] pci 0000:00:18.4: pci_pm_resume_noirq+0x0/0x130 returned 0 after 27 usecs
[ 689.818003] pci 0000:00:18.6: calling pci_pm_resume_noirq+0x0/0x130 @ 545, parent: pci0000:00
[ 689.818022] pci 0000:00:18.5: pci_pm_resume_noirq+0x0/0x130 returned 0 after 25 usecs
[ 689.818031] pci 0000:00:18.7: calling pci_pm_resume_noirq+0x0/0x130 @ 534, parent: pci0000:00
[ 689.818035] pci 0000:00:18.6: pci_pm_resume_noirq+0x0/0x130 returned 0 after 25 usecs
[ 689.818058] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_resume_noirq+0x0/0x50 @ 497, parent: platform
[ 689.818063] pci 0000:00:18.7: pci_pm_resume_noirq+0x0/0x130 returned 0 after 21 usecs
[ 689.818069] coreboot_table_acpi BOOT0000:00: acpi_subsys_resume_noirq+0x0/0x50 returned 0 after 4 usecs
[ 689.818146] pci 0000:00:18.0: calling pci_pm_resume_noirq+0x0/0x130 @ 537, parent: pci0000:00
[ 689.818176] pci 0000:00:18.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 23 usecs
[ 689.818199] i8042 i8042: calling i8042_pm_resume_noirq+0x0/0x30 @ 497, parent: platform
[ 689.818208] i8042 i8042: i8042_pm_resume_noirq+0x0/0x30 returned 0 after 3 usecs
[ 689.840148] ehci-pci 0000:00:12.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 22000 usecs
[ 689.840186] pcieport 0000:00:15.1: pci_pm_resume_noirq+0x0/0x130 returned 0 after 21772 usecs
[ 689.840254] r8169 0000:03:00.0: calling pci_pm_resume_noirq+0x0/0x130 @ 545, parent: 0000:00:15.1
[ 689.840420] snd_hda_intel 0000:00:14.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 22146 usecs
[ 689.840431] radeon 0000:00:01.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 22493 usecs
[ 689.840463] snd_hda_intel 0000:00:01.1: calling pci_pm_resume_noirq+0x0/0x130 @ 534, parent: pci0000:00
[ 689.840491] ehci-pci 0000:00:13.2: pci_pm_resume_noirq+0x0/0x130 returned 0 after 22284 usecs
[ 689.860097] snd_hda_intel 0000:00:01.1: pci_pm_resume_noirq+0x0/0x130 returned 0 after 19148 usecs
[ 689.860210] r8169 0000:03:00.0: pci_pm_resume_noirq+0x0/0x130 returned 0 after 19462 usecs
[ 689.860937] coreboot_table_acpi BOOT0000:00: calling acpi_subsys_resume_early+0x0/0x20 @ 497, parent: platform
[ 689.860950] coreboot_table_acpi BOOT0000:00: acpi_subsys_resume_early+0x0/0x20 returned 0 after 5 usecs
[ 689.861315] pci 0000:00:00.0: calling pci_pm_resume+0x0/0x100 @ 545, parent: pci0000:00
[ 689.861337] pci 0000:00:00.0: pci_pm_resume+0x0/0x100 returned 0 after 13 usecs
[ 689.861349] radeon 0000:00:01.0: calling pci_pm_resume+0x0/0x100 @ 545, parent: pci0000:00
[ 689.861529] thermal LNXTHERM:00: calling acpi_thermal_resume+0x0/0x280 [thermal] @ 497, parent: device:0b
[ 689.861549] thermal LNXTHERM:00: acpi_thermal_resume+0x0/0x280 [thermal] returned 0 after 12 usecs
[ 689.861585] button PNP0C0C:00: calling acpi_button_resume+0x0/0x90 [button] @ 497, parent: LNXSYBUS:00
[ 689.861595] button PNP0C0C:00: acpi_button_resume+0x0/0x90 [button] returned 0 after 3 usecs
[ 689.861639] ahci 0000:00:11.0: calling pci_pm_resume+0x0/0x100 @ 514, parent: pci0000:00
[ 689.861770] [drm] Found smc ucode version: 0x00010601
[ 689.861791] ahci 0000:00:11.0: pci_pm_resume+0x0/0x100 returned 0 after 142 usecs
[ 689.861801] ohci-pci 0000:00:12.0: calling pci_pm_resume+0x0/0x100 @ 514, parent: pci0000:00
[ 689.862784] ehci-pci 0000:00:12.2: calling pci_pm_resume+0x0/0x100 @ 544, parent: pci0000:00
[ 689.862985] ohci-pci 0000:00:13.0: calling pci_pm_resume+0x0/0x100 @ 534, parent: pci0000:00
[ 689.863161] ehci-pci 0000:00:13.2: calling pci_pm_resume+0x0/0x100 @ 537, parent: pci0000:00
[ 689.863319] piix4_smbus 0000:00:14.0: calling pci_pm_resume+0x0/0x100 @ 525, parent: pci0000:00
[ 689.863329] piix4_smbus 0000:00:14.0: pci_pm_resume+0x0/0x100 returned 0 after 4 usecs
[ 689.863338] snd_hda_intel 0000:00:14.2: calling pci_pm_resume+0x0/0x100 @ 525, parent: pci0000:00
[ 689.863470] pci 0000:00:14.3: calling pci_pm_resume+0x0/0x100 @ 524, parent: pci0000:00
[ 689.863479] pci 0000:00:14.3: pci_pm_resume+0x0/0x100 returned 0 after 4 usecs
[ 689.863493] pci 0000:00:14.4: calling pci_pm_resume+0x0/0x100 @ 524, parent: pci0000:00
[ 689.863502] pci 0000:00:14.4: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.863509] ohci-pci 0000:00:14.5: calling pci_pm_resume+0x0/0x100 @ 524, parent: pci0000:00
[ 689.863774] platform PNP0800:00: calling platform_pm_resume+0x0/0x80 @ 497, parent: 0000:00:14.3
[ 689.863783] platform PNP0800:00: platform_pm_resume+0x0/0x80 returned 0 after 3 usecs
[ 689.863790] platform PNP0C04:00: calling platform_pm_resume+0x0/0x80 @ 497, parent: 0000:00:14.3
[ 689.863797] platform PNP0C04:00: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 689.863803] platform PNP0C0C:00: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 689.863810] platform PNP0C0C:00: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 689.863819] button LNXPWRBN:00: calling acpi_button_resume+0x0/0x90 [button] @ 497, parent: LNXSYSTM:00
[ 689.863829] button LNXPWRBN:00: acpi_button_resume+0x0/0x90 [button] returned 0 after 5 usecs
[ 689.863840] rtc_cmos 00:00: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 689.863983] rtc_cmos 00:00: pnp_bus_resume+0x0/0x100 returned 0 after 134 usecs
[ 689.863989] i8042 kbd 00:01: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 689.863998] i8042 kbd 00:01: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 689.864004] i8042 aux 00:02: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 689.864012] i8042 aux 00:02: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 689.864018] i8042 kbd 00:03: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 689.864025] i8042 kbd 00:03: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 689.864031] i8042 aux 00:04: calling pnp_bus_resume+0x0/0x100 @ 497, parent: pnp0
[ 689.864039] i8042 aux 00:04: pnp_bus_resume+0x0/0x100 returned 0 after 2 usecs
[ 689.864075] pcieport 0000:00:15.1: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864080] pcspkr pcspkr: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 689.864088] pcspkr pcspkr: platform_pm_resume+0x0/0x80 returned 0 after 3 usecs
[ 689.864094] platform platform-framebuffer.0: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 689.864102] platform platform-framebuffer.0: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 689.864109] alarmtimer alarmtimer: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 689.864118] alarmtimer alarmtimer: platform_pm_resume+0x0/0x80 returned 0 after 3 usecs
[ 689.864131] serial8250 serial8250: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 689.864143] serial8250 serial8250: platform_pm_resume+0x0/0x80 returned 0 after 6 usecs
[ 689.864153] i8042 i8042: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 689.864168] pcieport 0000:00:15.1: pci_pm_resume+0x0/0x100 returned 0 after 84 usecs
[ 689.864177] pci 0000:00:18.0: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864185] pci 0000:00:18.0: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864193] pci 0000:00:18.1: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864201] pci 0000:00:18.1: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864208] pci 0000:00:18.2: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864215] pci 0000:00:18.2: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864224] k10temp 0000:00:18.3: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864231] k10temp 0000:00:18.3: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864239] pci 0000:00:18.4: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864247] pci 0000:00:18.4: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864254] pci 0000:00:18.5: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864262] pci 0000:00:18.5: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864269] pci 0000:00:18.6: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864276] pci 0000:00:18.6: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864283] pci 0000:00:18.7: calling pci_pm_resume+0x0/0x100 @ 540, parent: pci0000:00
[ 689.864290] pci 0000:00:18.7: pci_pm_resume+0x0/0x100 returned 0 after 3 usecs
[ 689.864297] r8169 0000:03:00.0: calling pci_pm_resume+0x0/0x100 @ 540, parent: 0000:00:15.1
[ 689.867104] i8042 i8042: platform_pm_resume+0x0/0x80 returned 0 after 2876 usecs
[ 689.867125] atkbd serio0: calling serio_resume+0x0/0xd0 @ 497, parent: i8042
[ 689.867145] atkbd serio0: serio_resume+0x0/0xd0 returned 0 after 14 usecs
[ 689.867170] rtc rtc0: calling rtc_resume+0x0/0x20 @ 497, parent: 00:00
[ 689.867178] rtc rtc0: rtc_resume+0x0/0x20 returned 0 after 3 usecs
[ 689.867198] platform microcode: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 689.867205] platform microcode: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 689.867214] input input0: calling input_dev_resume+0x0/0x50 @ 497, parent: serio0
[ 689.867231] input input0: input_dev_resume+0x0/0x50 returned 0 after 10 usecs
[ 689.867247] leds input0::numlock: calling led_resume+0x0/0x50 @ 497, parent: input0
[ 689.867254] leds input0::numlock: led_resume+0x0/0x50 returned 0 after 3 usecs
[ 689.867260] leds input0::capslock: calling led_resume+0x0/0x50 @ 497, parent: input0
[ 689.867267] leds input0::capslock: led_resume+0x0/0x50 returned 0 after 2 usecs
[ 689.867272] leds input0::scrolllock: calling led_resume+0x0/0x50 @ 497, parent: input0
[ 689.867279] leds input0::scrolllock: led_resume+0x0/0x50 returned 0 after 2 usecs
[ 689.867309] input input2: calling input_dev_resume+0x0/0x50 @ 497, parent: PNP0C0C:00
[ 689.867316] input input2: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 689.867323] input input3: calling input_dev_resume+0x0/0x50 @ 497, parent: LNXPWRBN:00
[ 689.867330] input input3: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 689.871743] ata1: calling ata_port_pm_resume+0x0/0x60 [libata] @ 527, parent: 0000:00:11.0
[ 689.871782] ata1: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 21 usecs
[ 689.871801] ata2: calling ata_port_pm_resume+0x0/0x60 [libata] @ 527, parent: 0000:00:11.0
[ 689.871828] ata2: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 10 usecs
[ 689.871847] ata3: calling ata_port_pm_resume+0x0/0x60 [libata] @ 527, parent: 0000:00:11.0
[ 689.871872] ata3: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 9 usecs
[ 689.871891] ata4: calling ata_port_pm_resume+0x0/0x60 [libata] @ 527, parent: 0000:00:11.0
[ 689.871917] ata4: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 10 usecs
[ 689.871937] ata5: calling ata_port_pm_resume+0x0/0x60 [libata] @ 527, parent: 0000:00:11.0
[ 689.871962] ata5: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 9 usecs
[ 689.871981] ata6: calling ata_port_pm_resume+0x0/0x60 [libata] @ 527, parent: 0000:00:11.0
[ 689.872006] ata6: ata_port_pm_resume+0x0/0x60 [libata] returned 0 after 9 usecs
[ 689.872031] scsi host0: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: ata1
[ 689.872052] scsi host0: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 3 usecs
[ 689.872074] scsi host1: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: ata2
[ 689.872094] scsi host1: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 689.872117] scsi host2: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: ata3
[ 689.872136] scsi host2: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 689.872160] scsi host3: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: ata4
[ 689.872182] scsi host3: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 5 usecs
[ 689.872204] scsi host4: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: ata5
[ 689.872223] scsi host4: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 689.872245] scsi host5: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: ata6
[ 689.872264] scsi host5: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 689.872288] scsi target0:0:0: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: host0
[ 689.872307] scsi target0:0:0: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 2 usecs
[ 689.872327] sd 0:0:0:0: calling scsi_bus_resume+0x0/0x20 [scsi_mod] @ 527, parent: target0:0:0
[ 689.872575] snd_hda_intel 0000:00:14.2: pci_pm_resume+0x0/0x100 returned 0 after 9012 usecs
[ 689.872593] snd_hda_codec_realtek hdaudioC1D0: calling pm_runtime_force_resume+0x0/0x170 @ 525, parent: 0000:00:14.2
[ 689.874705] sd 0:0:0:0: [sda] Starting disk
[ 689.877102] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
[ 689.877411] radeon 0000:00:01.0: WB enabled
[ 689.877420] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000018000c00 and cpu addr 0x2ebc320d
[ 689.877425] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000018000c0c and cpu addr 0xb29a6da6
[ 689.878185] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0x53642260
[ 689.894572] ohci-pci 0000:00:12.0: pci_pm_resume+0x0/0x100 returned 0 after 31988 usecs
[ 689.894607] ohci-pci 0000:00:14.5: pci_pm_resume+0x0/0x100 returned 0 after 30362 usecs
[ 689.894685] ohci-pci 0000:00:13.0: pci_pm_resume+0x0/0x100 returned 0 after 30933 usecs
[ 689.894720] ehci-pci 0000:00:12.2: pci_pm_resume+0x0/0x100 returned 0 after 31180 usecs
[ 689.894762] usb usb3: calling usb_dev_resume+0x0/0x20 [usbcore] @ 543, parent: 0000:00:12.0
[ 689.894764] [drm] ring test on 0 succeeded in 1 usecs
[ 689.894774] [drm] ring test on 3 succeeded in 3 usecs
[ 689.894881] usb usb5: calling usb_dev_resume+0x0/0x20 [usbcore] @ 512, parent: 0000:00:14.5
[ 689.894991] ehci-pci 0000:00:13.2: pci_pm_resume+0x0/0x100 returned 0 after 31077 usecs
[ 689.895029] usb usb4: calling usb_dev_resume+0x0/0x20 [usbcore] @ 519, parent: 0000:00:13.0
[ 689.895131] usb usb1: calling usb_dev_resume+0x0/0x20 [usbcore] @ 523, parent: 0000:00:12.2
[ 689.895187] usb usb2: calling usb_dev_resume+0x0/0x20 [usbcore] @ 518, parent: 0000:00:13.2
[ 689.895529] usb usb2: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 310 usecs
[ 689.911811] r8169 0000:03:00.0: pci_pm_resume+0x0/0x100 returned 0 after 46376 usecs
[ 689.920213] usb usb1: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 24453 usecs
[ 689.940703] [drm] ring test on 5 succeeded in 1 usecs
[ 689.943787] r8169 0000:03:00.0 enp3s0: link down
[ 689.960660] [drm] UVD initialized successfully.
[ 689.960886] [drm] ib test on ring 0 succeeded in 0 usecs
[ 689.960955] [drm] ib test on ring 3 succeeded in 0 usecs
[ 689.968155] usb usb5: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 71517 usecs
[ 689.968393] usb usb4: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 71621 usecs
[ 689.979430] usb usb3: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 82642 usecs
[ 689.979524] usb 3-2: calling usb_dev_resume+0x0/0x20 [usbcore] @ 751, parent: usb3
[ 690.040509] snd_hda_codec_realtek hdaudioC1D0: pm_runtime_force_resume+0x0/0x170 returned 0 after 163956 usecs
[ 690.053420] usb 3-2: usb_dev_resume+0x0/0x20 [usbcore] returned 0 after 72122 usecs
[ 690.186663] ata3: SATA link down (SStatus 0 SControl 300)
[ 690.186717] ata2: SATA link down (SStatus 0 SControl 300)
[ 690.186757] ata4: SATA link down (SStatus 0 SControl 300)
[ 690.186790] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 690.186824] ata6: SATA link down (SStatus 0 SControl 300)
[ 690.186857] ata5: SATA link down (SStatus 0 SControl 300)
[ 690.189323] ata1.00: configured for UDMA/133
[ 690.189697] sd 0:0:0:0: scsi_bus_resume+0x0/0x20 [scsi_mod] returned 0 after 309900 usecs
[ 690.504086] [drm] ib test on ring 5 succeeded
[ 690.596026] radeon 0000:00:01.0: pci_pm_resume+0x0/0x100 returned 0 after 717432 usecs
[ 690.596215] snd_hda_intel 0000:00:01.1: calling pci_pm_resume+0x0/0x100 @ 133, parent: pci0000:00
[ 690.599348] snd_hda_intel 0000:00:01.1: pci_pm_resume+0x0/0x100 returned 0 after 3029 usecs
[ 690.599547] input input4: calling input_dev_resume+0x0/0x50 @ 497, parent: card0
[ 690.599569] input input4: input_dev_resume+0x0/0x50 returned 0 after 12 usecs
[ 690.599579] sp5100-tco sp5100-tco: calling platform_pm_resume+0x0/0x80 @ 497, parent: platform
[ 690.599587] sp5100-tco sp5100-tco: platform_pm_resume+0x0/0x80 returned 0 after 2 usecs
[ 690.599596] input input5: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599705] input input5: input_dev_resume+0x0/0x50 returned 0 after 100 usecs
[ 690.599715] input input6: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599723] input input6: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599729] input input7: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599737] input input7: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599743] input input8: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599750] input input8: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599756] input input9: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599763] input input9: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599770] input input10: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599777] input input10: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599784] input input11: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599793] snd_hda_codec_hdmi hdaudioC0D0: calling pm_runtime_force_resume+0x0/0x170 @ 533, parent: 0000:00:01.1
[ 690.599798] input input11: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599804] input input12: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599812] input input12: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599818] input input13: calling input_dev_resume+0x0/0x50 @ 497, parent: card1
[ 690.599825] input input13: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599836] input input14: calling input_dev_resume+0x0/0x50 @ 497, parent: pcspkr
[ 690.599921] input input14: input_dev_resume+0x0/0x50 returned 0 after 78 usecs
[ 690.599948] input input16: calling input_dev_resume+0x0/0x50 @ 497, parent: 0003:1241:1122.0001
[ 690.599955] input input16: input_dev_resume+0x0/0x50 returned 0 after 2 usecs
[ 690.599977] serio serio1: calling serio_resume+0x0/0xd0 @ 497, parent: i8042
[ 690.600003] serio serio1: serio_resume+0x0/0xd0 returned 0 after 20 usecs
[ 690.600011] snd_hda_codec_hdmi hdaudioC0D0: pm_runtime_force_resume+0x0/0x170 returned 0 after 203 usecs
[ 690.601808] OOM killer enabled.
[ 690.601810] Restarting tasks ... done.
[ 690.619744] PM: suspend exit
[ 692.577123] r8169 0000:03:00.0 enp3s0: link up
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* [PATCH 3/3] net: phy: xgmiitorgmii: Check read_status results
From: Brandon Maier @ 2018-06-07 15:53 UTC (permalink / raw)
To: netdev
Cc: andrew, f.fainelli, davem, michal.simek, clayton.shotwell,
kristopher.cory, linux-kernel, Brandon Maier
In-Reply-To: <20180607155348.149665-1-brandon.maier@rockwellcollins.com>
We're ignoring the result of the attached phy device's read_status().
Return it so we can detect errors.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
---
drivers/net/phy/xilinx_gmii2rgmii.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c b/drivers/net/phy/xilinx_gmii2rgmii.c
index d6f8b64cddbe..74a8782313cf 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -42,8 +42,11 @@ static int xgmiitorgmii_read_status(struct phy_device *phydev)
struct mii_bus *bus = priv->mdio->bus;
int addr = priv->mdio->addr;
u16 val = 0;
+ int err;
- priv->phy_drv->read_status(phydev);
+ err = priv->phy_drv->read_status(phydev);
+ if (err < 0)
+ return err;
val = mdiobus_read(bus, addr, XILINX_GMII2RGMII_REG);
val &= ~XILINX_GMII2RGMII_SPEED_MASK;
--
2.14.3
^ permalink raw reply related
* [PATCH 2/3] net: phy: xgmiitorgmii: Use correct mdio bus
From: Brandon Maier @ 2018-06-07 15:53 UTC (permalink / raw)
To: netdev
Cc: andrew, f.fainelli, davem, michal.simek, clayton.shotwell,
kristopher.cory, linux-kernel, Brandon Maier
In-Reply-To: <20180607155348.149665-1-brandon.maier@rockwellcollins.com>
The xgmiitorgmii is using the mii_bus of the device it's attached too,
instead of the bus it was given during probe.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
---
drivers/net/phy/xilinx_gmii2rgmii.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c b/drivers/net/phy/xilinx_gmii2rgmii.c
index 04c8bec1c4c1..d6f8b64cddbe 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -33,17 +33,19 @@ struct gmii2rgmii {
struct phy_device *phy_dev;
struct phy_driver *phy_drv;
struct phy_driver conv_phy_drv;
- int addr;
+ struct mdio_device *mdio;
};
static int xgmiitorgmii_read_status(struct phy_device *phydev)
{
struct gmii2rgmii *priv = phydev->priv;
+ struct mii_bus *bus = priv->mdio->bus;
+ int addr = priv->mdio->addr;
u16 val = 0;
priv->phy_drv->read_status(phydev);
- val = mdiobus_read(phydev->mdio.bus, priv->addr, XILINX_GMII2RGMII_REG);
+ val = mdiobus_read(bus, addr, XILINX_GMII2RGMII_REG);
val &= ~XILINX_GMII2RGMII_SPEED_MASK;
if (phydev->speed == SPEED_1000)
@@ -53,7 +55,7 @@ static int xgmiitorgmii_read_status(struct phy_device *phydev)
else
val |= BMCR_SPEED10;
- mdiobus_write(phydev->mdio.bus, priv->addr, XILINX_GMII2RGMII_REG, val);
+ mdiobus_write(bus, addr, XILINX_GMII2RGMII_REG, val);
return 0;
}
@@ -86,7 +88,7 @@ static int xgmiitorgmii_probe(struct mdio_device *mdiodev)
return -EPROBE_DEFER;
}
- priv->addr = mdiodev->addr;
+ priv->mdio = mdiodev;
priv->phy_drv = priv->phy_dev->drv;
memcpy(&priv->conv_phy_drv, priv->phy_dev->drv,
sizeof(struct phy_driver));
--
2.14.3
^ permalink raw reply related
* [PATCH 1/3] net: phy: Check phy_driver ready before accessing
From: Brandon Maier @ 2018-06-07 15:53 UTC (permalink / raw)
To: netdev
Cc: andrew, f.fainelli, davem, michal.simek, clayton.shotwell,
kristopher.cory, linux-kernel, Brandon Maier
Since a phy_device is added to the global mdio_bus list during
phy_device_register(), but a phy_device's phy_driver doesn't get
attached until phy_probe(). It's possible of_phy_find_device() in
xgmiitorgmii will return a valid phy with a NULL phy_driver. Leading to
a NULL pointer access during the memcpy().
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
---
drivers/net/phy/xilinx_gmii2rgmii.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c b/drivers/net/phy/xilinx_gmii2rgmii.c
index 2e5150b0b8d5..04c8bec1c4c1 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -81,6 +81,11 @@ static int xgmiitorgmii_probe(struct mdio_device *mdiodev)
return -EPROBE_DEFER;
}
+ if (!priv->phy_dev->drv) {
+ dev_info(dev, "Attached phy not ready\n");
+ return -EPROBE_DEFER;
+ }
+
priv->addr = mdiodev->addr;
priv->phy_drv = priv->phy_dev->drv;
memcpy(&priv->conv_phy_drv, priv->phy_dev->drv,
--
2.14.3
^ permalink raw reply related
* Re: [PATCH net] failover: eliminate callback hell
From: Michael S. Tsirkin @ 2018-06-07 15:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Alexander Duyck, Samudrala, Sridhar, Jiri Pirko, KY Srinivasan,
Haiyang Zhang, David Miller, Netdev, Stephen Hemminger
In-Reply-To: <20180607075112.76deca08@xeon-e3>
On Thu, Jun 07, 2018 at 07:51:12AM -0700, Stephen Hemminger wrote:
> On Thu, 7 Jun 2018 07:17:51 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
> > On Wed, Jun 6, 2018 at 3:25 PM, Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > > On Wed, 6 Jun 2018 14:54:04 -0700
> > > "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote:
> > >
> > >> On 6/6/2018 2:24 PM, Stephen Hemminger wrote:
> > >> > On Wed, 6 Jun 2018 15:30:27 +0300
> > >> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >> >
> > >> >> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> > >> >>> Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
> > >> >>>> The net failover should be a simple library, not a virtual
> > >> >>>> object with function callbacks (see callback hell).
> > >> >>> Why just a library? It should do a common things. I think it should be a
> > >> >>> virtual object. Looks like your patch again splits the common
> > >> >>> functionality into multiple drivers. That is kind of backwards attitude.
> > >> >>> I don't get it. We should rather focus on fixing the mess the
> > >> >>> introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> > >> >>> model.
> > >> >> So it seems that at least one benefit for netvsc would be better
> > >> >> handling of renames.
> > >> >>
> > >> >> Question is how can this change to 3-netdev happen? Stephen is
> > >> >> concerned about risk of breaking some userspace.
> > >> >>
> > >> >> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> > >> >> address, and you said then "why not use existing network namespaces
> > >> >> rather than inventing a new abstraction". So how about it then? Do you
> > >> >> want to find a way to use namespaces to hide the PV device for netvsc
> > >> >> compatibility?
> > >> >>
> > >> > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> > >> > startups that all demand eth0 always be present. And VF may come and go.
> > >> > After this history, there is a strong motivation not to change how kernel
> > >> > behaves. Switching to 3 device model would be perceived as breaking
> > >> > existing userspace.
> > >>
> > >> I think it should be possible for netvsc to work with 3 dev model if the only
> > >> requirement is that eth0 will always be present. With net_failover, you will
> > >> see eth0 and eth0nsby OR with older distros eth0 and eth1. It may be an issue
> > >> if somehow there is userspace requirement that there can be only 2 netdevs, not 3
> > >> when VF is plugged.
> > >>
> > >> eth0 will be the net_failover device and eth0nsby/eth1 will be the netvsc device
> > >> and the IP address gets configured on eth0. Will this be an issue?
> > >
> > > DPDK drivers in 18.05 depend on 2 device model. Yes it is a bit of mess
> > > but that is the way it is.
> >
> > Why would DPDK care what we do in the kernel? Isn't it just slapping
> > vfio-pci on the netdevs it sees?
>
> Alex, you are correct for Intel devices; but DPDK on Azure is not Intel based.,.
> The DPDK support uses:
> * Mellanox MLX5 which uses the Infinband hooks to do DMA directly to
> userspace. This means VF netdev device must exist and be visible.
> * Slow path using kernel netvsc device, TAP and BPF to get exception
> path packets to userspace.
> * A autodiscovery mechanism that to set all this up that relies on
> 2 device model and sysfs.
Could you describe what does it look for exactly? What will break if
instead of MLX5 being a child of the PV, it's a child of the failover
device?
> In this version, there is no VFIO-PCI. And also Hyper-V does not have virtual
> IOMMU so VFIO will not work there at all.
>
^ permalink raw reply
* [PATCH bpf] bpf: reject passing modified ctx to helper functions
From: Daniel Borkmann @ 2018-06-07 15:40 UTC (permalink / raw)
To: ast; +Cc: netdev, ecree, Daniel Borkmann
As commit 28e33f9d78ee ("bpf: disallow arithmetic operations on
context pointer") already describes, f1174f77b50c ("bpf/verifier:
rework value tracking") removed the specific white-listed cases
we had previously where we would allow for pointer arithmetic in
order to further generalize it, and allow e.g. context access via
modified registers. While the dereferencing of modified context
pointers had been forbidden through 28e33f9d78ee, syzkaller did
recently manage to trigger several KASAN splats for slab out of
bounds access and use after frees by simply passing a modified
context pointer to a helper function which would then do the bad
access since verifier allowed it in adjust_ptr_min_max_vals().
Rejecting arithmetic on ctx pointer in adjust_ptr_min_max_vals()
generally could break existing programs as there's a valid use
case in tracing in combination with passing the ctx to helpers as
bpf_probe_read(), where the register then becomes unknown at
verification time due to adding a non-constant offset to it. An
access sequence may look like the following:
offset = args->filename; /* field __data_loc filename */
bpf_probe_read(&dst, len, (char *)args + offset); // args is ctx
There are two options: i) we could special case the ctx and as
soon as we add a constant or bounded offset to it (hence ctx type
wouldn't change) we could turn the ctx into an unknown scalar, or
ii) we generalize the sanity test for ctx member access into a
small helper and assert it on the ctx register that was passed
as a function argument. Fwiw, latter is more obvious and less
complex at the same time, and one case that may potentially be
legitimate in future for ctx member access at least would be for
ctx to carry a const offset. Therefore, fix follows approach
from ii) and adds test cases to BPF kselftests.
Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Reported-by: syzbot+3d0b2441dbb71751615e@syzkaller.appspotmail.com
Reported-by: syzbot+c8504affd4fdd0c1b626@syzkaller.appspotmail.com
Reported-by: syzbot+e5190cb881d8660fb1a3@syzkaller.appspotmail.com
Reported-by: syzbot+efae31b384d5badbd620@syzkaller.appspotmail.com
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 48 +++++++++++++++---------
tools/testing/selftests/bpf/test_verifier.c | 58 ++++++++++++++++++++++++++++-
2 files changed, 88 insertions(+), 18 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d6403b5..cced0c1 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1617,6 +1617,30 @@ static int get_callee_stack_depth(struct bpf_verifier_env *env,
}
#endif
+static int check_ctx_reg(struct bpf_verifier_env *env,
+ const struct bpf_reg_state *reg, int regno)
+{
+ /* Access to ctx or passing it to a helper is only allowed in
+ * its original, unmodified form.
+ */
+
+ if (reg->off) {
+ verbose(env, "dereference of modified ctx ptr R%d off=%d disallowed\n",
+ regno, reg->off);
+ return -EACCES;
+ }
+
+ if (!tnum_is_const(reg->var_off) || reg->var_off.value) {
+ char tn_buf[48];
+
+ tnum_strn(tn_buf, sizeof(tn_buf), reg->var_off);
+ verbose(env, "variable ctx access var_off=%s disallowed\n", tn_buf);
+ return -EACCES;
+ }
+
+ return 0;
+}
+
/* truncate register to smaller size (in bytes)
* must be called with size < BPF_REG_SIZE
*/
@@ -1686,24 +1710,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
verbose(env, "R%d leaks addr into ctx\n", value_regno);
return -EACCES;
}
- /* ctx accesses must be at a fixed offset, so that we can
- * determine what type of data were returned.
- */
- if (reg->off) {
- verbose(env,
- "dereference of modified ctx ptr R%d off=%d+%d, ctx+const is allowed, ctx+const+const is not\n",
- regno, reg->off, off - reg->off);
- return -EACCES;
- }
- if (!tnum_is_const(reg->var_off) || reg->var_off.value) {
- char tn_buf[48];
- tnum_strn(tn_buf, sizeof(tn_buf), reg->var_off);
- verbose(env,
- "variable ctx access var_off=%s off=%d size=%d",
- tn_buf, off, size);
- return -EACCES;
- }
+ err = check_ctx_reg(env, reg, regno);
+ if (err < 0)
+ return err;
+
err = check_ctx_access(env, insn_idx, off, size, t, ®_type);
if (!err && t == BPF_READ && value_regno >= 0) {
/* ctx access returns either a scalar, or a
@@ -1984,6 +1995,9 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 regno,
expected_type = PTR_TO_CTX;
if (type != expected_type)
goto err_type;
+ err = check_ctx_reg(env, reg, regno);
+ if (err < 0)
+ return err;
} else if (arg_type_is_mem_ptr(arg_type)) {
expected_type = PTR_TO_STACK;
/* One exception here. In case function allows for NULL to be
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index 7cb1d74..2ecd27b 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -8647,7 +8647,7 @@ static struct bpf_test tests[] = {
offsetof(struct __sk_buff, mark)),
BPF_EXIT_INSN(),
},
- .errstr = "dereference of modified ctx ptr R1 off=68+8, ctx+const is allowed, ctx+const+const is not",
+ .errstr = "dereference of modified ctx ptr",
.result = REJECT,
.prog_type = BPF_PROG_TYPE_SCHED_CLS,
},
@@ -12258,6 +12258,62 @@ static struct bpf_test tests[] = {
.result = ACCEPT,
.retval = 5,
},
+ {
+ "pass unmodified ctx pointer to helper",
+ .insns = {
+ BPF_MOV64_IMM(BPF_REG_2, 0),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ BPF_FUNC_csum_update),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .result = ACCEPT,
+ },
+ {
+ "pass modified ctx pointer to helper, 1",
+ .insns = {
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -612),
+ BPF_MOV64_IMM(BPF_REG_2, 0),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ BPF_FUNC_csum_update),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .result = REJECT,
+ .errstr = "dereference of modified ctx ptr",
+ },
+ {
+ "pass modified ctx pointer to helper, 2",
+ .insns = {
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -612),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ BPF_FUNC_get_socket_cookie),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .result_unpriv = REJECT,
+ .result = REJECT,
+ .errstr_unpriv = "dereference of modified ctx ptr",
+ .errstr = "dereference of modified ctx ptr",
+ },
+ {
+ "pass modified ctx pointer to helper, 3",
+ .insns = {
+ BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1, 0),
+ BPF_ALU64_IMM(BPF_AND, BPF_REG_3, 4),
+ BPF_ALU64_REG(BPF_ADD, BPF_REG_1, BPF_REG_3),
+ BPF_MOV64_IMM(BPF_REG_2, 0),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
+ BPF_FUNC_csum_update),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .result = REJECT,
+ .errstr = "variable ctx access var_off=(0x0; 0x4)",
+ },
};
static int probe_filter_length(const struct bpf_insn *fp)
--
2.9.5
^ permalink raw reply related
* Re: Re: KMSAN: uninit-value in _copy_to_iter (2)
From: syzbot @ 2018-06-07 15:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: avagin, davem, dingtianhong, edumazet, elena.reshetova, jasowang,
kvm, linux-kernel, matthew, mingo, mst, netdev, pabeni,
syzkaller-bugs, viro, virtualization, willemb
In-Reply-To: <20180607183627-mutt-send-email-mst@kernel.org>
> #syz test: https://github.com/google/kmsan.git/master
> d2d741e5d1898dfde1a75ea3d29a9a3e2edf0617
"https://github.com/google/kmsan.git/master" does not look like a valid git
repo address.
> Subject: vhost: fix info leak
> Fixes: CVE-2018-1118
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index f0be5f35ab28..9beefa6ed1ce 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2345,6 +2345,9 @@ struct vhost_msg_node *vhost_new_msg(struct
> vhost_virtqueue *vq, int type)
> struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
> if (!node)
> return NULL;
> +
> + /* Make sure all padding within the structure is initialized. */
> + memset(&node->msg, 0, sizeof node->msg);
> node->vq = vq;
> node->msg.type = type;
> return node;
^ permalink raw reply
* Re: KMSAN: uninit-value in _copy_to_iter (2)
From: Michael S. Tsirkin @ 2018-06-07 15:38 UTC (permalink / raw)
To: syzbot
Cc: willemb, avagin, kvm, netdev, matthew, linux-kernel, mingo,
syzkaller-bugs, edumazet, viro, dingtianhong, pabeni,
virtualization, davem, elena.reshetova
In-Reply-To: <000000000000cf4578056ab12452@google.com>
#syz test: https://github.com/google/kmsan.git/master d2d741e5d1898dfde1a75ea3d29a9a3e2edf0617
Subject: vhost: fix info leak
Fixes: CVE-2018-1118
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f0be5f35ab28..9beefa6ed1ce 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2345,6 +2345,9 @@ struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
+
+ /* Make sure all padding within the structure is initialized. */
+ memset(&node->msg, 0, sizeof node->msg);
node->vq = vq;
node->msg.type = type;
return node;
^ permalink raw reply related
* Re: general protection fault in __vfs_write
From: Matthew Wilcox @ 2018-06-07 15:28 UTC (permalink / raw)
To: syzbot
Cc: linux-fsdevel, linux-kernel, syzkaller-bugs, netdev,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <000000000000973c2c056e0ecddd@google.com>
I would suggest this is a BPF problem, not a VFS problem.
On Thu, Jun 07, 2018 at 08:19:01AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7170e6045a6a strparser: Add __strp_unpause and use it in k..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=14bde74f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a601a80fec461d44
> dashboard link: https://syzkaller.appspot.com/bug?extid=7ade6c94abb2774c0fee
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+7ade6c94abb2774c0fee@syzkaller.appspotmail.com
>
> bpfilter: read fail -512
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 4590 Comm: syz-executor7 Not tainted 4.17.0-rc7+ #82
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:file_write_hint include/linux/fs.h:1925 [inline]
> RIP: 0010:init_sync_kiocb include/linux/fs.h:1935 [inline]
> RIP: 0010:new_sync_write fs/read_write.c:470 [inline]
> RIP: 0010:__vfs_write+0x4a6/0x960 fs/read_write.c:487
> RSP: 0018:ffff88019b5c7850 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: ffff8801d2117c80 RCX: ffffffff81bfc6bb
> RDX: 0000000000000019 RSI: ffffffff81bfc6ca RDI: 00000000000000c8
> RBP: ffff88019b5c79c8 R08: ffff88019b5ba540 R09: fffffbfff12cae69
> R10: ffff88019b5c7a10 R11: ffffffff8965734b R12: 0000000000000000
> R13: ffff88019b5c79a0 R14: 0000000000000000 R15: ffff88019b5c7a88
> FS: 0000000002a11940(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000700138 CR3: 000000019b410000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __kernel_write+0x10c/0x380 fs/read_write.c:506
> __bpfilter_process_sockopt+0x1d8/0x35b net/bpfilter/bpfilter_kern.c:66
> bpfilter_mbox_request+0x4d/0xb0 net/ipv4/bpfilter/sockopt.c:25
> bpfilter_ip_get_sockopt+0x6b/0x90 net/ipv4/bpfilter/sockopt.c:42
> ip_getsockopt+0x238/0x2a0 net/ipv4/ip_sockglue.c:1563
> tcp_getsockopt+0x93/0xe0 net/ipv4/tcp.c:3543
> sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:3018
> __sys_getsockopt+0x1a5/0x370 net/socket.c:1940
> __do_sys_getsockopt net/socket.c:1951 [inline]
> __se_sys_getsockopt net/socket.c:1948 [inline]
> __x64_sys_getsockopt+0xbe/0x150 net/socket.c:1948
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4584ea
> RSP: 002b:0000000000a3e328 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> RAX: ffffffffffffffda RBX: 0000000000a3e350 RCX: 00000000004584ea
> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000013
> RBP: 0000000000705f20 R08: 0000000000a3e34c R09: 0000000000004000
> R10: 0000000000a3e350 R11: 0000000000000246 R12: 0000000000000013
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000705860
> Code: 48 c1 ea 03 80 3c 02 00 0f 85 1b 04 00 00 48 b8 00 00 00 00 00 fc ff
> df 4c 8b 63 20 49 8d bc 24 c8 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84
> c0 74 08 3c 03 0f 8e ec 02 00 00 41 8b 84 24 c8
> RIP: file_write_hint include/linux/fs.h:1925 [inline] RSP: ffff88019b5c7850
> RIP: init_sync_kiocb include/linux/fs.h:1935 [inline] RSP: ffff88019b5c7850
> RIP: new_sync_write fs/read_write.c:470 [inline] RSP: ffff88019b5c7850
> RIP: __vfs_write+0x4a6/0x960 fs/read_write.c:487 RSP: ffff88019b5c7850
> ---[ end trace 556c3fc867e1de54 ]---
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Stephen Hemminger @ 2018-06-07 15:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jiri Pirko, kys, haiyangz, davem, sridhar.samudrala, netdev,
Stephen Hemminger
In-Reply-To: <20180607172244-mutt-send-email-mst@kernel.org>
On Thu, 7 Jun 2018 17:57:50 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Jun 06, 2018 at 03:24:08PM -0700, Stephen Hemminger wrote:
> > On Thu, 7 Jun 2018 00:47:52 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> > > On Wed, Jun 06, 2018 at 02:24:47PM -0700, Stephen Hemminger wrote:
> > > > On Wed, 6 Jun 2018 15:30:27 +0300
> > > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > >
> > > > > On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> > > > > > Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
> > > > > > >The net failover should be a simple library, not a virtual
> > > > > > >object with function callbacks (see callback hell).
> > > > > >
> > > > > > Why just a library? It should do a common things. I think it should be a
> > > > > > virtual object. Looks like your patch again splits the common
> > > > > > functionality into multiple drivers. That is kind of backwards attitude.
> > > > > > I don't get it. We should rather focus on fixing the mess the
> > > > > > introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> > > > > > model.
> > > > >
> > > > > So it seems that at least one benefit for netvsc would be better
> > > > > handling of renames.
> > > > >
> > > > > Question is how can this change to 3-netdev happen? Stephen is
> > > > > concerned about risk of breaking some userspace.
> > > > >
> > > > > Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> > > > > address, and you said then "why not use existing network namespaces
> > > > > rather than inventing a new abstraction". So how about it then? Do you
> > > > > want to find a way to use namespaces to hide the PV device for netvsc
> > > > > compatibility?
> > > > >
> > > >
> > > > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> > > > startups that all demand eth0 always be present. And VF may come and go.
> > >
> > > Well failover seems to maintain this invariant with the 3 dev model.
> > >
> > > > After this history, there is a strong motivation not to change how kernel
> > > > behaves. Switching to 3 device model would be perceived as breaking
> > > > existing userspace.
> > >
> > > I feel I'm misunderstood. I was asking whether a 3-rd device can be
> > > hidden so that userspace does not know that you switched to a 3 device
> > > model. It will think there are 2 devices and will keep working.
> > >
> > > If you do that, then there won't be anything that
> > > would be perceived as breaking existing userspace, will there?
> >
> > DPDK now knows about the netvsc 2 device model and drivers in userspace
> > depend on it.
>
> Interesting but I'm not sure how this answers the question. How would
> DPDK care that there's a hidden device? If you can point out the
> code in question, maybe a way can be found to make changes while
> keeping it working.
See http://dpdk.org/browse/dpdk/tree/drivers/net/vdev_netvsc/vdev_netvsc.c
I am working to eliminate the necessity of this complex model in DPDK.
Having a 3 device model inside DPDK has just as many problems as in the
kernel.
^ permalink raw reply
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
From: Jonas Mark (BT-FIR/ENG1) @ 2018-06-07 15:20 UTC (permalink / raw)
To: Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, hs@denx.de,
ZHU Yi (BT-FIR/ENG1-Zhu)
Hi Oliver,
> >> Please place the companion driver in
> >>
> >> drivers/net/can/spi/companion.c
> >>
> >> It also makes more sense in the Kconfig structure.
> >>
> >> Probably this naming scheme also makes sense for
> >>
> >> linux/drivers/char/spi/companion.c
> >>
> >> then ...
> >>
> >> If not it should be named at least
> >>
> >> drivers/char/companion-spi.c
> >>
> >> or
> >>
> >> drivers/char/spi-companion.c
> >
> > We intentionally left out the spi in the driver path / name because
> > only the drivers/spi/companion/* driver knows that that it is connected
> > to SPI. The others (drivers/net/can/companion-can.c and
> > drivers/char/companion-char.c) only know the API. This could also be
> > supplied by a driver which talks to the Companion via a different
> > interface. Actually, we started with a UART connection but switched to
> > SPI due to latency issues.
>
> Ok, got it.
>
> > Should we still change it?
>
> At least I would then vote for
>
> drivers/char/companion.c
> drivers/net/can/companion.c
>
> instead of
>
> drivers/char/companion-char.c
> drivers/net/can/companion-can.c
Sounds good, will be changed.
> as you would have companion-users in different driver subsystems that
> are already clearly referenced by their path.
>
> The modules itself should still be named with companion-can of course
> (as-is right now).
>
> Btw.
>
> +#define DRIVER_NAME "bosch,companion-can"
>
> +static const struct can_bittiming_const companion_can_bittiming_const = {
> + .name = "bosch,companion",
>
>
> Is there any reason why it's not only "companion-can" or "companion"?
> The fact that the driver is provided by Bosch is visible in the source code.
Hmm, I guess we mixed up the naming scheme used in devicetree. We will
sleep a night over it and then clean it up. I think the result will be
that the devicetree entry is "bosch,companion-can" and all other uses
are "companion-can".
Greetings,
Mark
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply
* Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
From: Jonas Mark (BT-FIR/ENG1) @ 2018-06-07 15:14 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Wolfgang Grandegger, Marc Kleine-Budde, linux-can@vger.kernel.org,
netdev, Linux Kernel Mailing List, Heiko Schocher,
ZHU Yi (BT-FIR/ENG1-Zhu)
Hi Andy,
> > The functionality bases on an external peripheral chip named Companion.
> > It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as
> > well as one receive FIFO. Besides CAN, undisclosed additional functions
> > can be accessed through the char device.
> >
> > A standard SPI interface with two additional lines for flow control is
> > used. The Companion chip is the SPI slave.
>
> Can remoteproc API be utilized here?
So far I wasn't aware of the remoteproc API. It appears to me that is
limited to power on/off and loading firmware in an AMP scenario. Here,
the Companion has a fixed firmware in it. It must already be running
quickly after power-up, even before the boot loader.
Does remoteproc also contain a communication framework?
Do you mean rpmsg? Here, I do not see how we could benefit from it.
Can you point me to an example where rpmsg is used over SPI?
Greetings,
Mark
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply
* AW: [PATCH 2/5] spi: implement companion-spi driver
From: Jonas Mark (BT-FIR/ENG1) @ 2018-06-07 14:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Wolfgang Grandegger, Marc Kleine-Budde, linux-can@vger.kernel.org,
netdev, Linux Kernel Mailing List, Heiko Schocher,
ZHU Yi (BT-FIR/ENG1-Zhu)
In-Reply-To: <CAHp75Vd0xqKwJCYqOWvFTpMy8iH4PPf_HXX4dkx=KER4UD13fA@mail.gmail.com>
Hello Andy,
Thank you very much for your feedback.
> > + /*TODO: support mutiple packets in one write in future*/
>
> Hmm... Either fix this, or remove comment?
Agreed, we will manage ideas for future changes at a different place.
> > + if (copy_from_user(p.data, buf, sizeof(p)) == 0) {
> > + if (is_can_type(&p))
> > + return -EINVAL;
> > + } else {
> > + dev_info(parent, "copy from user not succeed in one call\n");
>
> Shouldn't it return immediately?
Yes, it should. Will be changed.
>
> > + }
>
> > +
> > + error = qm_io_txq_in(&priv->pm.qm, buf, count, &copied);
>
> ...what the point to call if we got garbage from user space?
Will be changed with the code above.
> > + if (!error) {
>
> The usual pattern is to check for errors first.
Understood, will be changed.
> > + wake_up_interruptible(&priv->wait);
> > + priv->pm.stats.io_tx++;
> > + return copied;
> > + } else {
> > + priv->pm.stats.io_tx_overflows++;
> > + }
> > + return error;
> > +}
>
> > + ... qm_io_rxq_out(&priv->pm.qm, buf, count, &copied);
>
> > + ... pm_can_data_tx(&priv->pm, port, prio, cf);
>
> Oh, oh, oh.
>
> These namespaces are too generic, moreover pm is kinda occupied by
> power management. You bring a lot of confusion here, I think.
We agree and we started thinking about better names. We will send a proposal.
> > + err = pm_can_get_txq_status(pm, port);
> > + if (!err) {
>
> if (err)
> return err;
Yes, will be changed.
> > + }
> > + return err;
>
>
> > + int ret, value;
> > +
> > + ret = sscanf(buf, "%d", &value);
> > + if (ret != 1) {
>
> > + }
>
> You have to be consistent in your code.
>
> I've already noticed
>
> err
> error
>
> and now
>
> ret
>
> Choose one and stick with it.
Yes, will be changed.
> Also check your entire patch series' code for consistency.
We will have a look.
> > +static DEVICE_ATTR(dump_packets, S_IRUGO | S_IWUSR,
> > + show_dump_packets, store_dump_packets);
>
> We have helpers, like DEVICE_ATTR_RW().
Will be changed.
> > + ret = snprintf(buf + pos, PAGE_SIZE - pos,
> > + "\ntx: %u, rx: %u, err: %u\n\n",
> > + total,
> > + priv->pm.stats.can_rx_overflows[i],
> > + priv->pm.stats.can_err_overflows[i]);
>
> Please, avoid leading '\n'.
We think we will stick to the existing. Otherweise we would have to
insert another pair of sprint() and pos += ret. Is it worth that?
>
> > + gpio_set_value(priv->cs_gpios, priv->cs_gpios_assert);
>
> > + gpio_set_value(priv->cs_gpios, !priv->cs_gpios_assert);
>
> Can you switch to GPIO descriptor API?
Yes, we are working on it.
> > + unsigned int count = READY_POLL_US / READY_POLL_US_GRAN;
> > + while (count--) {
>
> For counting like this better to have
> do {
> } while (--count);
>
> The rationale, reader at first glance will know that the loop will
> iterate at least once.
Agreed, will be changed.
> > + if (slave_is_not_busy(priv))
> > + return 0;
> > +
>
> > + udelay(READY_POLL_US_GRAN);
>
> Should it be atomic?
> Can it use read_poll_* type of helpers instead?
Yes, it shall be atomic because we need to reduce the latency at
detecting the de-assertion of the busy signal. We accept that this will
cost CPU time.
In case the Companion itself is very busy and does not reply quickly we
are have second polling loop below which sleeps longer and is non-atomic.
> Above comments applicable to entire code you have.
We will look at it.
> > +static void companion_spi_cpu_to_be32(char *buf)
> > +{
> > + u32 *buf32 = (u32*)buf;
> > + int i;
> > +
> > + for (i = 0; i < (BCP_PACKET_SIZE / sizeof(u32)); i++, buf32++)
> > + *buf32 = cpu_to_be32(*buf32);
> > +}
>
> This entire function should be replaced by one of the helpers from
> include/linux/byteorder/generic.h
>
> I guess cpu_to_be32_array() is a right one.
Correct. We are testing the driver against 4.14 and that function is not
available there. It will be changed later.
> > +static void companion_spi_be32_to_cpu(char *buf)
> > +{
> > + u32 *buf32 = (u32*)buf;
> > + int i;
> > +
> > + for (i = 0; i < (BCP_PACKET_SIZE / sizeof(u32)); i++, buf32++)
> > + *buf32 = be32_to_cpu(*buf32);
> > +}
>
> Ditto.
>
> Recommendation: check your code against existing helpers.
Yes, every kernel release brings new helpers. We will have to learn how
to keep track of the additions.
> > + p = (const struct companion_packet*)transfer->tx_buf;
>
> > + companion_spi_cpu_to_be32((char*)transfer->tx_buf);
>
> If tx_buf is type of void * all these castings are redundant.
The type is const void*. So the first cast is superfluous, the second
is not.
> Also looking at the function, did you consider to use whatever SPI
> core provides, like CS handling, messages handling and so on?
SPI CS has to be done manually in our case because we need to wait
until the Companion signals that it is ready for the transfer.
Do you have concrete proposals regarding messages handling?
> > +static int companion_spi_thread(void *data)
> > +{
> > + struct companion_spi_priv *priv = data;
> > + struct companion_packet tx_packet;
> > + struct companion_packet rx_packet;
> > + struct spi_message message;
> > + struct spi_transfer transfer;
> > +
> > + memset(&transfer, 0, sizeof(transfer));
> > + transfer.tx_buf = tx_packet.data;
> > + transfer.rx_buf = rx_packet.data;
> > + transfer.len = sizeof(struct companion_packet);
>
> > + transfer.cs_change = 0;
>
> Redundant.
Yes, it is redundant. We want to explicitly show here that the CS
handling is done manually.
> > + for (;;) {
>
> Infinite loops are evil in most of the cases.
> I see here
>
> do {
> } while (kthread_should_stop());
Yes, will be fixed.
> > +static const struct of_device_id companion_spi_of_match[] = {
> > + { .compatible = DRIVER_NAME, .data = NULL, },
> > + { /* sentinel */ },
>
> terminators better without commas.
Yes, will be fixed.
> > + .owner = THIS_MODULE,
>
> This is redundant, macro you are using below sets that.
Will be fixed.
> Something wrong with indentation in this file.
Yes, we will need to work on the indentation. We will do it in a
following round.
> > +#define CHECK_SIZE(x) BUILD_BUG_ON(sizeof(struct companion_packet) != \
> > + sizeof(x))
>
> Better to split like
> _SIZE(x) \
> BUILD_BUG_ON()
Will be fixed.
> > +void pm_init(struct companion_protocol_manager *pm)
>
> Unfortunately, horrible name for the function.
> Namespace is kinda occupied, name itself way too generic.
Yes, we will send a proposal.
> > + if (ctrl & CAN_CTRLMODE_LISTENONLY)
> > + p.mode = BCP_CAN_MODE_LISTEN;
> > + else
> > + return -EOPNOTSUPP;
>
> if (!(cond))
> return -ERRNO;
Will be fixed.
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
>
> Do you still need this text?
Do you mean the SPDX is enough? Then, yes, we can remove it.
> > + * TODO: add more statistics fields and export to sysfs
>
> Do it or remove the comment?
>
> > + * TODO: re-think the data structure for handle CAN response
>
> Ditto.
We will handle future improvement ideas in a different place.
> > +/**
> > + * BCP status field definitions
> > + */
> > +#define BCP_STATUS_SUCCESS 0x00u
> > +#define BCP_STATUS_UNKNOWN 0x01u
> > +#define BCP_STATUS_OTHER 0x02u
>
> BIT() ?
No, these are fixed numbers, not bit fields.
> > +struct companion_packet {
> > + __u8 data[BCP_PACKET_SIZE];
> > +};
>
> Is it going from / to user space? Otherwise why __ kind of type?
Will be fixed.
> > +#define CAN_MAX_IN_A_ROW 8
> > +
> > +
> > +
>
> Too many blank lines.
Yes. Will be fixed.
> > +int companion_do_can_err(struct device *parent,
> > + u8 port,
> > + struct can_berr_counter *bec,
> > + u8 *state,
> > + u8 *code);
>
> + blank line here.
Will be fixed.
>
> > +#define COMPANION_CAN_STATE_WARNING 0x01u
> > +#define COMPANION_CAN_STATE_PASSIVE 0x02u
> > +#define COMPANION_CAN_STATE_BUS_OFF 0x04u
> > +#define COMPANION_CAN_ERROR_STUFF 0x01u
> > +#define COMPANION_CAN_ERROR_FORM 0x02u
> > +#define COMPANION_CAN_ERROR_ACK 0x04u
> > +#define COMPANION_CAN_ERROR_BIT1 0x08u
> > +#define COMPANION_CAN_ERROR_BIT0 0x10u
> > +#define COMPANION_CAN_ERROR_CRC 0x20u
> > +#define COMPANION_CAN_ERROR_RXOV 0x80u
>
> BIT() ?
Yes, this is a bit field. Will be fixed.
Greetings,
Mark
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Michael S. Tsirkin @ 2018-06-07 14:57 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jiri Pirko, kys, haiyangz, davem, sridhar.samudrala, netdev,
Stephen Hemminger
In-Reply-To: <20180606152408.30b9e833@xeon-e3>
On Wed, Jun 06, 2018 at 03:24:08PM -0700, Stephen Hemminger wrote:
> On Thu, 7 Jun 2018 00:47:52 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Wed, Jun 06, 2018 at 02:24:47PM -0700, Stephen Hemminger wrote:
> > > On Wed, 6 Jun 2018 15:30:27 +0300
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >
> > > > On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> > > > > Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
> > > > > >The net failover should be a simple library, not a virtual
> > > > > >object with function callbacks (see callback hell).
> > > > >
> > > > > Why just a library? It should do a common things. I think it should be a
> > > > > virtual object. Looks like your patch again splits the common
> > > > > functionality into multiple drivers. That is kind of backwards attitude.
> > > > > I don't get it. We should rather focus on fixing the mess the
> > > > > introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> > > > > model.
> > > >
> > > > So it seems that at least one benefit for netvsc would be better
> > > > handling of renames.
> > > >
> > > > Question is how can this change to 3-netdev happen? Stephen is
> > > > concerned about risk of breaking some userspace.
> > > >
> > > > Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> > > > address, and you said then "why not use existing network namespaces
> > > > rather than inventing a new abstraction". So how about it then? Do you
> > > > want to find a way to use namespaces to hide the PV device for netvsc
> > > > compatibility?
> > > >
> > >
> > > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> > > startups that all demand eth0 always be present. And VF may come and go.
> >
> > Well failover seems to maintain this invariant with the 3 dev model.
> >
> > > After this history, there is a strong motivation not to change how kernel
> > > behaves. Switching to 3 device model would be perceived as breaking
> > > existing userspace.
> >
> > I feel I'm misunderstood. I was asking whether a 3-rd device can be
> > hidden so that userspace does not know that you switched to a 3 device
> > model. It will think there are 2 devices and will keep working.
> >
> > If you do that, then there won't be anything that
> > would be perceived as breaking existing userspace, will there?
>
> DPDK now knows about the netvsc 2 device model and drivers in userspace
> depend on it.
Interesting but I'm not sure how this answers the question. How would
DPDK care that there's a hidden device? If you can point out the
code in question, maybe a way can be found to make changes while
keeping it working.
> >
> >
> > > With virtio you can work it out with the distro's yourself.
> > > There is no pre-existing semantics to deal with.
> > >
> > > For the virtio, I don't see the need for IFF_HIDDEN.
> > > With 3-dev model as long as you mark the PV and VF devices
> > > as slaves, then userspace knows to leave them alone. Assuming userspace
> > > is already able to deal with team and bond devices.
> >
> > That's clear enough.
> >
> > > Any time you introduce new UAPI behavior something breaks.
> >
> > Not if we do it right.
> >
> > > On the rename front, I really don't care if VF can be renamed.
> >
> > OK that's nice.
> >
> > > And for
> > > netvsc want to allow the PV device to be renamed.
> >
> > That's because of the 2 device model, right? So that explains why even
> > if the delayed hack is good for the goose it might not be good for the
> > gander :)
>
> You are bringing up the VF right away. How does the 3-device initialization
> state machine work? Do you give a window for udev to possibly rename the
> VF? Do you rely on that?
>
> >
> > > Udev developers want that
> > > but have not found a stable/persistent value to expose to userspace
> > > to allow it.
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Stephen Hemminger @ 2018-06-07 14:51 UTC (permalink / raw)
To: Alexander Duyck
Cc: Samudrala, Sridhar, Michael S. Tsirkin, Jiri Pirko, KY Srinivasan,
Haiyang Zhang, David Miller, Netdev, Stephen Hemminger
In-Reply-To: <CAKgT0UcJ=pbAjK6CoL8wbbqBdgeUP4xhs6uwZ0-i7X8+0Suwng@mail.gmail.com>
On Thu, 7 Jun 2018 07:17:51 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 3:25 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Wed, 6 Jun 2018 14:54:04 -0700
> > "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote:
> >
> >> On 6/6/2018 2:24 PM, Stephen Hemminger wrote:
> >> > On Wed, 6 Jun 2018 15:30:27 +0300
> >> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >
> >> >> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> >> >>> Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
> >> >>>> The net failover should be a simple library, not a virtual
> >> >>>> object with function callbacks (see callback hell).
> >> >>> Why just a library? It should do a common things. I think it should be a
> >> >>> virtual object. Looks like your patch again splits the common
> >> >>> functionality into multiple drivers. That is kind of backwards attitude.
> >> >>> I don't get it. We should rather focus on fixing the mess the
> >> >>> introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> >> >>> model.
> >> >> So it seems that at least one benefit for netvsc would be better
> >> >> handling of renames.
> >> >>
> >> >> Question is how can this change to 3-netdev happen? Stephen is
> >> >> concerned about risk of breaking some userspace.
> >> >>
> >> >> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> >> >> address, and you said then "why not use existing network namespaces
> >> >> rather than inventing a new abstraction". So how about it then? Do you
> >> >> want to find a way to use namespaces to hide the PV device for netvsc
> >> >> compatibility?
> >> >>
> >> > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> >> > startups that all demand eth0 always be present. And VF may come and go.
> >> > After this history, there is a strong motivation not to change how kernel
> >> > behaves. Switching to 3 device model would be perceived as breaking
> >> > existing userspace.
> >>
> >> I think it should be possible for netvsc to work with 3 dev model if the only
> >> requirement is that eth0 will always be present. With net_failover, you will
> >> see eth0 and eth0nsby OR with older distros eth0 and eth1. It may be an issue
> >> if somehow there is userspace requirement that there can be only 2 netdevs, not 3
> >> when VF is plugged.
> >>
> >> eth0 will be the net_failover device and eth0nsby/eth1 will be the netvsc device
> >> and the IP address gets configured on eth0. Will this be an issue?
> >
> > DPDK drivers in 18.05 depend on 2 device model. Yes it is a bit of mess
> > but that is the way it is.
>
> Why would DPDK care what we do in the kernel? Isn't it just slapping
> vfio-pci on the netdevs it sees?
Alex, you are correct for Intel devices; but DPDK on Azure is not Intel based.,.
The DPDK support uses:
* Mellanox MLX5 which uses the Infinband hooks to do DMA directly to
userspace. This means VF netdev device must exist and be visible.
* Slow path using kernel netvsc device, TAP and BPF to get exception
path packets to userspace.
* A autodiscovery mechanism that to set all this up that relies on
2 device model and sysfs.
In this version, there is no VFIO-PCI. And also Hyper-V does not have virtual
IOMMU so VFIO will not work there at all.
^ permalink raw reply
* Fw: [Bug 199963] New: UDP rx_queue incorrect calculation in /proc/net/udp
From: Stephen Hemminger @ 2018-06-07 14:39 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 07 Jun 2018 13:21:23 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199963] New: UDP rx_queue incorrect calculation in /proc/net/udp
https://bugzilla.kernel.org/show_bug.cgi?id=199963
Bug ID: 199963
Summary: UDP rx_queue incorrect calculation in /proc/net/udp
Product: Networking
Version: 2.5
Kernel Version: Kernels >= 4.15
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: trevor.francis@46labs.com
Regression: No
since upgrading to any kernel >= 4.15 the rx_queue in /proc/net/udp is now
reporting a queue, regardless of system load and regardless of what
applications are running on it. The tx_queue is always 0, but rx_queue has
seemingly random spikes of udp queueing. This is observed across hundreds of
servers with either varying or no workload.
netstat -nl|grep ^udp
udp 4352 0 0.0.0.0:68 0.0.0.0:*
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid
timeout inode ref pointer drops
14645: 3500007F:0035 00000000:0000 07 00000000:0000C900 00:00000000 00000000
101 0 3367 2 ffff8da177fdcc00 0
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Geert Uytterhoeven @ 2018-06-07 14:36 UTC (permalink / raw)
To: Michael Schmitz
Cc: netdev, Andrew Lunn, Finn Thain, Florian Fainelli, Linux/m68k,
Michael Karcher, Michael Karcher
In-Reply-To: <1524103526-12240-10-git-send-email-schmitzmic@gmail.com>
Hi Michael,
On Thu, Apr 19, 2018 at 4:05 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
>
> Add platform device driver to populate the ax88796 platform data from
> information provided by the XSurf100 zorro device driver. The ax88796
> module will be loaded through this module's probe function.
>
> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
This is now commit 861928f4e60e826c ("net-next: New ax88796 platform
driver for Amiga X-Surf 100 Zorro board (m68k)").
> --- /dev/null
> +++ b/drivers/net/ethernet/8390/xsurf100.c
> +#define __NS8390_init ax_NS8390_init
[...]
> +#include "lib8390.c"
drivers/net/ethernet/8390/lib8390.c:202: warning: ‘__ei_open’ defined
but not used
drivers/net/ethernet/8390/lib8390.c:231: warning: ‘__ei_close’ defined
but not used
drivers/net/ethernet/8390/lib8390.c:255: warning: ‘__ei_tx_timeout’
defined but not used
drivers/net/ethernet/8390/lib8390.c:302: warning: ‘__ei_start_xmit’
defined but not used
drivers/net/ethernet/8390/lib8390.c:510: warning: ‘__ei_poll’ defined
but not used
drivers/net/ethernet/8390/lib8390.c:851: warning: ‘__ei_get_stats’
defined but not used
drivers/net/ethernet/8390/lib8390.c:951: warning:
‘__ei_set_multicast_list’ defined but not used
drivers/net/ethernet/8390/lib8390.c:989: warning:
‘____alloc_ei_netdev’ defined but not used
So I was wondering: why is this file included, as XSURF100 selects AX88796,
while ax88796.c includes lib8390.c anyway?
Apparently lib8390.c is included for register definitions (provided by
8390.h, and can easily be fixed), and for the __NS8390_init()
implementation, called below.
> +static void xs100_block_output(struct net_device *dev, int count,
> + const unsigned char *buf, const int start_page)
> +{
[...]
> + while ((ei_inb(nic_base + EN0_ISR) & ENISR_RDC) == 0) {
> + if (jiffies - dma_start > 2 * HZ / 100) { /* 20ms */
> + netdev_warn(dev, "timeout waiting for Tx RDC.\n");
> + ei_local->reset_8390(dev);
> + ax_NS8390_init(dev, 1);
> + break;
> + }
> + }
> +
> + ei_outb(ENISR_RDC, nic_base + EN0_ISR); /* Ack intr. */
> + ei_local->dmaing &= ~0x01;
> +}
Can we get rid of the inclusion of lib8390.c, and the related warnings?
Perhaps ax88796.c can export its ax_NS8390_init(), iff the implementation
is identical? Or is there a better solution?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Alexander Duyck @ 2018-06-07 14:17 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Samudrala, Sridhar, Michael S. Tsirkin, Jiri Pirko, KY Srinivasan,
Haiyang Zhang, David Miller, Netdev, Stephen Hemminger
In-Reply-To: <20180606152516.5edd5893@xeon-e3>
On Wed, Jun 6, 2018 at 3:25 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Wed, 6 Jun 2018 14:54:04 -0700
> "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote:
>
>> On 6/6/2018 2:24 PM, Stephen Hemminger wrote:
>> > On Wed, 6 Jun 2018 15:30:27 +0300
>> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> >
>> >> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
>> >>> Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
>> >>>> The net failover should be a simple library, not a virtual
>> >>>> object with function callbacks (see callback hell).
>> >>> Why just a library? It should do a common things. I think it should be a
>> >>> virtual object. Looks like your patch again splits the common
>> >>> functionality into multiple drivers. That is kind of backwards attitude.
>> >>> I don't get it. We should rather focus on fixing the mess the
>> >>> introduction of netvsc-bonding caused and switch netvsc to 3-netdev
>> >>> model.
>> >> So it seems that at least one benefit for netvsc would be better
>> >> handling of renames.
>> >>
>> >> Question is how can this change to 3-netdev happen? Stephen is
>> >> concerned about risk of breaking some userspace.
>> >>
>> >> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
>> >> address, and you said then "why not use existing network namespaces
>> >> rather than inventing a new abstraction". So how about it then? Do you
>> >> want to find a way to use namespaces to hide the PV device for netvsc
>> >> compatibility?
>> >>
>> > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
>> > startups that all demand eth0 always be present. And VF may come and go.
>> > After this history, there is a strong motivation not to change how kernel
>> > behaves. Switching to 3 device model would be perceived as breaking
>> > existing userspace.
>>
>> I think it should be possible for netvsc to work with 3 dev model if the only
>> requirement is that eth0 will always be present. With net_failover, you will
>> see eth0 and eth0nsby OR with older distros eth0 and eth1. It may be an issue
>> if somehow there is userspace requirement that there can be only 2 netdevs, not 3
>> when VF is plugged.
>>
>> eth0 will be the net_failover device and eth0nsby/eth1 will be the netvsc device
>> and the IP address gets configured on eth0. Will this be an issue?
>
> DPDK drivers in 18.05 depend on 2 device model. Yes it is a bit of mess
> but that is the way it is.
Why would DPDK care what we do in the kernel? Isn't it just slapping
vfio-pci on the netdevs it sees?
^ permalink raw reply
* [PATCH] ieee802154: add rx LQI from userspace
From: Clément Péron @ 2018-06-07 14:08 UTC (permalink / raw)
To: Romuald Cari, linux-wpan
Cc: Alexander Aring, Stefan Schmidt, David S . Miller, netdev,
linux-kernel, Clément Peron
From: Romuald CARI <romuald.cari@devialet.com>
The Link Quality Indication data exposed by drivers could not be accessed from
userspace. Since this data is per-datagram received, it makes sense to make it
available to userspace application through the ancillary data mechanism in
recvmsg rather than through ioctls. This can be activated using the socket
option WPAN_WANTLQI under SOL_IEEE802154 protocol.
This LQI data is available in the ancillary data buffer under the SOL_IEEE802154
level as the type WPAN_LQI. The value is an unsigned byte indicating the link
quality with values ranging 0-255.
Signed-off-by: Romuald Cari <romuald.cari@devialet.com>
Signed-off-by: Clément Peron <clement.peron@devialet.com>
---
include/net/af_ieee802154.h | 1 +
net/ieee802154/socket.c | 17 +++++++++++++++++
2 files changed, 18 insertions(+)
diff --git a/include/net/af_ieee802154.h b/include/net/af_ieee802154.h
index a5563d27a3eb..8003a9f6eb43 100644
--- a/include/net/af_ieee802154.h
+++ b/include/net/af_ieee802154.h
@@ -56,6 +56,7 @@ struct sockaddr_ieee802154 {
#define WPAN_WANTACK 0
#define WPAN_SECURITY 1
#define WPAN_SECURITY_LEVEL 2
+#define WPAN_WANTLQI 3
#define WPAN_SECURITY_DEFAULT 0
#define WPAN_SECURITY_OFF 1
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index a60658c85a9a..bc6b912603f1 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -25,6 +25,7 @@
#include <linux/termios.h> /* For TIOCOUTQ/INQ */
#include <linux/list.h>
#include <linux/slab.h>
+#include <linux/socket.h>
#include <net/datalink.h>
#include <net/psnap.h>
#include <net/sock.h>
@@ -452,6 +453,7 @@ struct dgram_sock {
unsigned int bound:1;
unsigned int connected:1;
unsigned int want_ack:1;
+ unsigned int want_lqi:1;
unsigned int secen:1;
unsigned int secen_override:1;
unsigned int seclevel:3;
@@ -486,6 +488,7 @@ static int dgram_init(struct sock *sk)
struct dgram_sock *ro = dgram_sk(sk);
ro->want_ack = 1;
+ ro->want_lqi = 0;
return 0;
}
@@ -713,6 +716,7 @@ static int dgram_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
size_t copied = 0;
int err = -EOPNOTSUPP;
struct sk_buff *skb;
+ struct dgram_sock *ro = dgram_sk(sk);
DECLARE_SOCKADDR(struct sockaddr_ieee802154 *, saddr, msg->msg_name);
skb = skb_recv_datagram(sk, flags, noblock, &err);
@@ -744,6 +748,13 @@ static int dgram_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
*addr_len = sizeof(*saddr);
}
+ if (ro->want_lqi) {
+ err = put_cmsg(msg, SOL_IEEE802154, WPAN_WANTLQI,
+ sizeof(uint8_t), &(mac_cb(skb)->lqi));
+ if (err)
+ goto done;
+ }
+
if (flags & MSG_TRUNC)
copied = skb->len;
done:
@@ -847,6 +858,9 @@ static int dgram_getsockopt(struct sock *sk, int level, int optname,
case WPAN_WANTACK:
val = ro->want_ack;
break;
+ case WPAN_WANTLQI:
+ val = ro->want_lqi;
+ break;
case WPAN_SECURITY:
if (!ro->secen_override)
val = WPAN_SECURITY_DEFAULT;
@@ -892,6 +906,9 @@ static int dgram_setsockopt(struct sock *sk, int level, int optname,
case WPAN_WANTACK:
ro->want_ack = !!val;
break;
+ case WPAN_WANTLQI:
+ ro->want_lqi = !!val;
+ break;
case WPAN_SECURITY:
if (!ns_capable(net->user_ns, CAP_NET_ADMIN) &&
!ns_capable(net->user_ns, CAP_NET_RAW)) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next v5 00/10] BTF: BPF Type Format
From: Arnaldo Carvalho de Melo @ 2018-06-07 14:03 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180607135401.GE30317@kernel.org>
Em Thu, Jun 07, 2018 at 10:54:01AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jun 05, 2018 at 02:25:48PM -0700, Martin KaFai Lau escreveu:
> > [ btw, the latest commit (1 commit) should be 94a11b59e592 ].
So, the commit log message for the pahole patch is non-existent:
https://github.com/iamkafai/pahole/commit/94a11b59e5920908085bfc8d24c92f95c8ffceaf
we should do better in describing what is done and how, I'm staring
with a message you sent to the kernel part:
--
This patch introduces BPF Type Format (BTF).
BTF (BPF Type Format) is the meta data format which describes
the data types of BPF program/map. Hence, it basically focus
on the C programming language which the modern BPF is primary
using. The first use case is to provide a generic pretty print
capability for a BPF map.
^ permalink raw reply
* Re: [PATCH bpf-next v5 00/10] BTF: BPF Type Format
From: Arnaldo Carvalho de Melo @ 2018-06-07 13:54 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180605212548.lwtaw4svvydo2lhy@kafai-mbp.dhcp.thefacebook.com>
Em Tue, Jun 05, 2018 at 02:25:48PM -0700, Martin KaFai Lau escreveu:
> On Thu, Apr 19, 2018 at 04:40:34PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Apr 18, 2018 at 03:55:56PM -0700, Martin KaFai Lau escreveu:
> > > This patch introduces BPF Type Format (BTF).
> > >
> > > BTF (BPF Type Format) is the meta data format which describes
> > > the data types of BPF program/map. Hence, it basically focus
> > > on the C programming language which the modern BPF is primary
> > > using. The first use case is to provide a generic pretty print
> > > capability for a BPF map.
> > >
> > > A modified pahole that can convert dwarf to BTF is here:
> > > https://github.com/iamkafai/pahole/tree/btf
> > > (Arnaldo, there is some BTF_KIND numbering changes on
> > > Apr 18th, d61426c1571)
> >
> > Thanks for letting me know, I'm starting to look at this,
> Hi Arnaldo,
>
> Do you have a chance to take a look and pull it? The kernel
> changes will be in 4.18, so it will be handy if it is available in
> the pahole repository.
>
> [ btw, the latest commit (1 commit) should be 94a11b59e592 ].
Yeah, the one I had before had:
It also raises the number of types (and functions) limit from 0x7fff to
0x7fffffff.
----
And on this last one I see that:
/* Max # of type identifier */
-#define BTF_MAX_TYPE 0x7fffffff
+#define BTF_MAX_TYPE 0x0000ffff
/* Max offset into the string section */
-#define BTF_MAX_NAME_OFFSET 0x7fffffff
+#define BTF_MAX_NAME_OFFSET 0x0000ffff
So somehow (still reading) you'll be able to get more space, if we find
necessary, to have more types and names, ok.
Continuing...
- Arnaldo
> >
> > - Arnaldo
> >
> > > Please see individual patch for details.
> > >
> > > v5:
> > > - Remove BTF_KIND_FLOAT and BTF_KIND_FUNC which are not
> > > currently used. They can be added in the future.
> > > Some bpf_df_xxx() are removed together.
> > > - Add comment in patch 7 to clarify that the new bpffs_map_fops
> > > should not be extended further.
> > >
> > > v4:
> > > - Fix warning (remove unneeded semicolon)
> > > - Remove a redundant variable (nr_bytes) from btf_int_check_meta() in
> > > patch 1. Caught by W=1.
> > >
> > > v3:
> > > - Rebase to bpf-next
> > > - Fix sparse warning (by adding static)
> > > - Add BTF header logging: btf_verifier_log_hdr()
> > > - Fix the alignment test on btf->type_off
> > > - Add tests for the BTF header
> > > - Lower the max BTF size to 16MB. It should be enough
> > > for some time. We could raise it later if it would
> > > be needed.
> > >
> > > v2:
> > > - Use kvfree where needed in patch 1 and 2
> > > - Also consider BTF_INT_OFFSET() in the btf_int_check_meta()
> > > in patch 1
> > > - Fix an incorrect goto target in map_create() during
> > > the btf-error-path in patch 7
> > > - re-org some local vars to keep the rev xmas tree in btf.c
> > >
> > > Martin KaFai Lau (10):
> > > bpf: btf: Introduce BPF Type Format (BTF)
> > > bpf: btf: Validate type reference
> > > bpf: btf: Check members of struct/union
> > > bpf: btf: Add pretty print capability for data with BTF type info
> > > bpf: btf: Add BPF_BTF_LOAD command
> > > bpf: btf: Add BPF_OBJ_GET_INFO_BY_FD support to BTF fd
> > > bpf: btf: Add pretty print support to the basic arraymap
> > > bpf: btf: Sync bpf.h and btf.h to tools/
> > > bpf: btf: Add BTF support to libbpf
> > > bpf: btf: Add BTF tests
> > >
> > > include/linux/bpf.h | 20 +-
> > > include/linux/btf.h | 48 +
> > > include/uapi/linux/bpf.h | 12 +
> > > include/uapi/linux/btf.h | 130 ++
> > > kernel/bpf/Makefile | 1 +
> > > kernel/bpf/arraymap.c | 50 +
> > > kernel/bpf/btf.c | 2064 ++++++++++++++++++++++++++
> > > kernel/bpf/inode.c | 156 +-
> > > kernel/bpf/syscall.c | 51 +-
> > > tools/include/uapi/linux/bpf.h | 12 +
> > > tools/include/uapi/linux/btf.h | 130 ++
> > > tools/lib/bpf/Build | 2 +-
> > > tools/lib/bpf/bpf.c | 92 +-
> > > tools/lib/bpf/bpf.h | 16 +
> > > tools/lib/bpf/btf.c | 374 +++++
> > > tools/lib/bpf/btf.h | 22 +
> > > tools/lib/bpf/libbpf.c | 148 +-
> > > tools/lib/bpf/libbpf.h | 3 +
> > > tools/testing/selftests/bpf/Makefile | 26 +-
> > > tools/testing/selftests/bpf/test_btf.c | 1669 +++++++++++++++++++++
> > > tools/testing/selftests/bpf/test_btf_haskv.c | 48 +
> > > tools/testing/selftests/bpf/test_btf_nokv.c | 43 +
> > > 22 files changed, 5076 insertions(+), 41 deletions(-)
> > > create mode 100644 include/linux/btf.h
> > > create mode 100644 include/uapi/linux/btf.h
> > > create mode 100644 kernel/bpf/btf.c
> > > create mode 100644 tools/include/uapi/linux/btf.h
> > > create mode 100644 tools/lib/bpf/btf.c
> > > create mode 100644 tools/lib/bpf/btf.h
> > > create mode 100644 tools/testing/selftests/bpf/test_btf.c
> > > create mode 100644 tools/testing/selftests/bpf/test_btf_haskv.c
> > > create mode 100644 tools/testing/selftests/bpf/test_btf_nokv.c
> > >
> > > --
> > > 2.9.5
^ permalink raw reply
* [PATCH net] net/sched: act_simple: fix parsing of TCA_DEFDATA
From: Davide Caratti @ 2018-06-07 13:46 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko; +Cc: David S. Miller, netdev
use nla_strlcpy() to avoid copying data beyond the length of TCA_DEFDATA
netlink attribute, in case it is less than SIMP_MAX_DATA and it does not
end with '\0' character.
Fixes: 0eff683f737b ("net/sched: potential data corruption")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_simple.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
index 9618b4a83cee..98c4afe7c15b 100644
--- a/net/sched/act_simple.c
+++ b/net/sched/act_simple.c
@@ -53,22 +53,22 @@ static void tcf_simp_release(struct tc_action *a)
kfree(d->tcfd_defdata);
}
-static int alloc_defdata(struct tcf_defact *d, char *defdata)
+static int alloc_defdata(struct tcf_defact *d, const struct nlattr *defdata)
{
d->tcfd_defdata = kzalloc(SIMP_MAX_DATA, GFP_KERNEL);
if (unlikely(!d->tcfd_defdata))
return -ENOMEM;
- strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
+ nla_strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
return 0;
}
-static void reset_policy(struct tcf_defact *d, char *defdata,
+static void reset_policy(struct tcf_defact *d, const struct nlattr *defdata,
struct tc_defact *p)
{
spin_lock_bh(&d->tcf_lock);
d->tcf_action = p->action;
memset(d->tcfd_defdata, 0, SIMP_MAX_DATA);
- strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
+ nla_strlcpy(d->tcfd_defdata, defdata, SIMP_MAX_DATA);
spin_unlock_bh(&d->tcf_lock);
}
@@ -87,7 +87,6 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
struct tcf_defact *d;
bool exists = false;
int ret = 0, err;
- char *defdata;
if (nla == NULL)
return -EINVAL;
@@ -110,8 +109,6 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
return -EINVAL;
}
- defdata = nla_data(tb[TCA_DEF_DATA]);
-
if (!exists) {
ret = tcf_idr_create(tn, parm->index, est, a,
&act_simp_ops, bind, false);
@@ -119,7 +116,7 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
return ret;
d = to_defact(*a);
- ret = alloc_defdata(d, defdata);
+ ret = alloc_defdata(d, tb[TCA_DEF_DATA]);
if (ret < 0) {
tcf_idr_release(*a, bind);
return ret;
@@ -133,7 +130,7 @@ static int tcf_simp_init(struct net *net, struct nlattr *nla,
if (!ovr)
return -EEXIST;
- reset_policy(d, defdata, parm);
+ reset_policy(d, tb[TCA_DEF_DATA], parm);
}
if (ret == ACT_P_CREATED)
--
2.17.0
^ permalink raw reply related
* Re: [RFC net-next] ipv4: Don't promote secondaries when flushing addresses
From: Michal Kubecek @ 2018-06-07 13:44 UTC (permalink / raw)
To: netdev; +Cc: Phil Sutter, Jakub Sitnicki
In-Reply-To: <20180607123539.GH16785@orbyte.nwl.cc>
On Thu, Jun 07, 2018 at 02:35:39PM +0200, Phil Sutter wrote:
> Yes, I agree with Michal. IIRC, flushing a specific primary along with
> all it's secondaries from an interface is not even supported by
> iproute2, so no need to optimize for that I guess. OTOH, if your
> solution allowed to get rid of that nasty loop in ipaddr_flush(), I owe
> you one extra beer at the next occasion. :)
I'm afraid it will have to stay as fallback for older kernels not
supporting flush requests. But there would be no need to actually use
it. If we know RTM_DELADDR request for zero address is guaranteed to
fail with current and older kernels, we could do
- use RTM_DELADDR with IFA_F_FLUSH and zero address
- if it fails, get the list and run the loop
If not, it could still be
- use RTM_DELADDR with IFA_F_FLUSH and zero address
- get the list of addresses (empty if first step worked)
- run the loop
Michal Kubecek
^ permalink raw reply
* [PATCH] xsk: Fix umem fill/completion queue mmap on 32-bit
From: Geert Uytterhoeven @ 2018-06-07 13:37 UTC (permalink / raw)
To: David S . Miller, Björn Töpel, Magnus Karlsson,
Alexei Starovoitov
Cc: Arnd Bergmann, Andrew Morton, netdev, linux-mm, linux-kernel,
Geert Uytterhoeven
With gcc-4.1.2 on 32-bit:
net/xdp/xsk.c:663: warning: integer constant is too large for ‘long’ type
net/xdp/xsk.c:665: warning: integer constant is too large for ‘long’ type
Add the missing "ULL" suffixes to the large XDP_UMEM_PGOFF_*_RING values
to fix this.
net/xdp/xsk.c:663: warning: comparison is always false due to limited range of data type
net/xdp/xsk.c:665: warning: comparison is always false due to limited range of data type
"unsigned long" is 32-bit on 32-bit systems, hence the offset is
truncated, and can never be equal to any of the XDP_UMEM_PGOFF_*_RING
values. Use loff_t (and the required cast) to fix this.
Fixes: 423f38329d267969 ("xsk: add umem fill queue support and mmap")
Fixes: fe2308328cd2f26e ("xsk: add umem completion queue support and mmap")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Compile-tested only.
---
include/uapi/linux/if_xdp.h | 4 ++--
net/xdp/xsk.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/if_xdp.h b/include/uapi/linux/if_xdp.h
index 1fa0e977ea8d0224..caed8b1614ffc0aa 100644
--- a/include/uapi/linux/if_xdp.h
+++ b/include/uapi/linux/if_xdp.h
@@ -63,8 +63,8 @@ struct xdp_statistics {
/* Pgoff for mmaping the rings */
#define XDP_PGOFF_RX_RING 0
#define XDP_PGOFF_TX_RING 0x80000000
-#define XDP_UMEM_PGOFF_FILL_RING 0x100000000
-#define XDP_UMEM_PGOFF_COMPLETION_RING 0x180000000
+#define XDP_UMEM_PGOFF_FILL_RING 0x100000000ULL
+#define XDP_UMEM_PGOFF_COMPLETION_RING 0x180000000ULL
/* Rx/Tx descriptor */
struct xdp_desc {
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index c6ed2454f7ce55e8..36919a254ba370c3 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -643,7 +643,7 @@ static int xsk_getsockopt(struct socket *sock, int level, int optname,
static int xsk_mmap(struct file *file, struct socket *sock,
struct vm_area_struct *vma)
{
- unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
+ loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
unsigned long size = vma->vm_end - vma->vm_start;
struct xdp_sock *xs = xdp_sk(sock->sk);
struct xsk_queue *q = NULL;
--
2.7.4
^ permalink raw reply related
* [PATCH] net: mscc: ocelot: Fix uninitialized error in ocelot_netdevice_event()
From: Geert Uytterhoeven @ 2018-06-07 13:10 UTC (permalink / raw)
To: Alexandre Belloni, David S . Miller, Andrew Lunn
Cc: Arnd Bergmann, netdev, linux-kernel, Geert Uytterhoeven
With gcc-4.1.2:
drivers/net/ethernet/mscc/ocelot.c: In function ‘ocelot_netdevice_event’:
drivers/net/ethernet/mscc/ocelot.c:1129: warning: ‘ret’ may be used uninitialized in this function
If the list iterated over by netdev_for_each_lower_dev() is empty, ret
is never initialized, and converted into a notifier return value.
Fix this by preinitializing ret to zero.
Fixes: a556c76adc052c97 ("net: mscc: Add initial Ocelot switch support")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This may be unlikely to happen, but given the notifier is called for any
(also non-ocelot) network device, better be safe than sorry.
---
drivers/net/ethernet/mscc/ocelot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index c8c74aa548d96e00..fb2c8f8071e64d3b 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1126,7 +1126,7 @@ static int ocelot_netdevice_event(struct notifier_block *unused,
{
struct netdev_notifier_changeupper_info *info = ptr;
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
- int ret;
+ int ret = 0;
if (netif_is_lag_master(dev)) {
struct net_device *slave;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox