Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #56829 > unrolled thread
| Started by | Paul Menzel <pm.debian@googlemail.com> |
|---|---|
| First post | 2017-01-29 23:30 +0100 |
| Last post | 2018-06-17 21:20 +0200 |
| Articles | 20 on this page of 21 — 12 participants |
Back to article view | Back to linux.debian.kernel
Bug#853122: sp5100_tco: I/O address 0x0cd6 already in use Paul Menzel <pm.debian@googlemail.com> - 2017-01-29 23:30 +0100
Processed: sp5100_tco: I/O address 0x0cd6 already in use owner@bugs.debian.org (Debian Bug Tracking System) - 2017-01-29 23:30 +0100
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Paul Menzel <paulepanter@users.sourceforge.net> - 2017-03-03 10:00 +0100
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Wolfram Sang <wsa@the-dreams.de> - 2017-03-03 11:30 +0100
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Paul Menzel <paulepanter@users.sourceforge.net> - 2017-03-31 09:30 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Guenter Roeck <linux@roeck-us.net> - 2017-03-31 15:20 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Boszormenyi Zoltan <zboszor@pr.hu> - 2017-03-31 16:50 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Guenter Roeck <linux@roeck-us.net> - 2017-03-31 17:10 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Boszormenyi Zoltan <zboszor@pr.hu> - 2017-04-01 12:20 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Guenter Roeck <linux@roeck-us.net> - 2017-04-01 15:40 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Boszormenyi Zoltan <zboszor@pr.hu> - 2017-04-01 18:30 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Boszormenyi Zoltan <zboszor@pr.hu> - 2017-04-01 18:40 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Paul Menzel <paulepanter@users.sourceforge.net> - 2017-04-03 08:40 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Boszormenyi Zoltan <zboszor@pr.hu> - 2017-04-03 10:10 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Boszormenyi Zoltan <zboszor@pr.hu> - 2017-06-27 14:30 +0200
Bug#853122: Same Error Carl N <carlnikolov@gmail.com> - 2017-08-31 04:40 +0200
Bug#853122: Same error sp5100_tco: I/O address 0x0cd6 already in use Sisim Biva <sisimbiva@gmail.com> - 2017-10-02 10:20 +0200
Bug#853122: posts bugs alain BELLEC <alain_bellec@bbox.fr> - 2017-10-02 12:30 +0200
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Gyorgy Kapolnas <rty042@gmail.com> - 2017-11-22 12:30 +0100
Bug#853122: linux-image-4.13.0-0.bpo.1-amd64: Also present at Gigabyte GA-AM1M-S2H Rainer Dorsch <ml@bokomoko.de> - 2017-12-16 21:30 +0100
Bug#853122: This problem not solved until now Ky0ncheng <ky0ncheng@protonmail.ch> - 2018-06-17 21:20 +0200
Page 1 of 2 [1] 2 Next page →
| From | Paul Menzel <pm.debian@googlemail.com> |
|---|---|
| Date | 2017-01-29 23:30 +0100 |
| Subject | Bug#853122: sp5100_tco: I/O address 0x0cd6 already in use |
| Message-ID | <t568V-4lY-7@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
Package: src:linux Version: 4.9.2-2 Severity: normal Tags: upstream Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=170741 Dear Debian folks, The watchdog driver doesn’t load on my ASRock E350M1 anymore. ``` $ journalctl -k […] Jan 29 19:09:45 myasrocke350m1 kernel: piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 Jan 29 19:09:45 myasrocke350m1 kernel: piix4_smbus 0000:00:14.0: Using register 0x2c for SMBus port selection Jan 29 19:09:45 myasrocke350m1 kernel: piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0x8060 […] Jan 29 19:09:45 myasrocke350m1 kernel: sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 Jan 29 19:09:45 myasrocke350m1 kernel: sp5100_tco: PCI Vendor ID: 0x1002, Device ID: 0x4385, Revision ID: 0x42 Jan 29 19:09:45 myasrocke350m1 kernel: sp5100_tco: I/O address 0x0cd6 already in use […] ``` There is already an upstream bug report [1], which has been ignored so far though. Tim Small wrote: > On the AMD Turion N40L and other related SoCs, the i2c-piix4 driver > now claims the 0xcd6 ioport, preventing the sp5100_tco watchdog > driver from loading: > > piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 > piix4_smbus 0000:00:14.0: Using register 0x2c for SMBus port > selection > piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20 > sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 > sp5100_tco: PCI Vendor ID: 0x1002, Device ID: 0x4385, Revision ID: > 0x42 > sp5100_tco: I/O address 0x0cd6 already in use > > > This breaks watchdog operation on existing systems on upgrade and new > deployments unless the i2c-piix4 driver is blacklisted. > > See: > > drivers/watchdog/sp5100_tco.c > > tco_timer_enable(void) > > (SB800_IO_PM_INDEX_REG is defined in drivers/watchdog/sp5100_tco.h) > > This is the commit which prevents the watchdog driver from loading: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2fee61d22e606fc99ade9079fda15fdee83ec33e > > See also AMD docs > > 45483_sb800_bdg_pub_3.03 > > Perhaps a fix is to switch both drivers from static to dynamic > allocation of the IO ports in question, since the watchdog driver > only accesses the port during initialisation (with backoff/retry > maybe to avoid races?). I hope this regression will be fixed upstream, or in Debian. Thanks, Paul [1] https://bugzilla.kernel.org/show_bug.cgi?id=170741 -- Package-specific info: ** Version: Linux version 4.9.0-1-686-pae (debian-kernel@lists.debian.org) (gcc version 6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 (2017-01-12) ** Command line: BOOT_IMAGE=/vmlinuz-4.9.0-1-686-pae root=/dev/mapper/speicher-root ro init=/lib/systemd/systemd-bootchart drm_kms_helper.poll=0 drm.debug=0x06 log_buf_len=2M quiet noisapnp pcie_aspm=force pcie_aspm.policy=powersave radeon.dpm=1 ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information ** Loaded modules: cpuid ctr ccm fuse ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter uinput binfmt_misc xfs arc4 rt2800usb snd_hda_codec_realtek rt2x00usb rt2800lib rt2x00lib mac80211 snd_hda_codec_hdmi snd_hda_codec_generic cfg80211 crc_ccitt rfkill joydev kvm_amd kvm snd_hda_intel snd_hda_codec snd_hda_core radeon snd_hwdep snd_pcm_oss irqbypass evdev snd_mixer_oss k10temp serio_raw snd_pcm snd_timer acpi_cpufreq tpm_tis snd ttm tpm_tis_core shpchp drm_kms_helper tpm drm soundcore sg button i2c_algo_bit nct6775 hwmon_vid loop firewire_sbp2 firewire_core crc_itu_t ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto xts lrw gf128mul ablk_helper cryptd aes_i586 mbcache btrfs ecb cbc algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid0 multipath linear raid1 hid_generic md_mod usbhid hid sd_mod psmouse ahci libahci ohci_pci sp5100_tco libata r8169 mii scsi_mod i2c_piix4 ehci_pci ohci_hcd ehci_hcd usbcore usb_common thermal ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Complex [1022:1510] Subsystem: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Complex [1022:1510] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 27 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at 2000 [size=256] Region 2: Memory at f0100000 (32-bit, non-prefetchable) [size=256K] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: radeon Kernel modules: radeon 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler HDMI Audio [1002:1314] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler HDMI Audio [1002:1314] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 28 Region 0: Memory at f0140000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40) (prog-if 01 [AHCI 1.0]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at 2410 [size=8] Region 1: I/O ports at 2420 [size=4] Region 2: I/O ports at 2418 [size=8] Region 3: I/O ports at 2424 [size=4] Region 4: I/O ports at 2400 [size=16] Region 5: Memory at f014b000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> Kernel driver in use: ahci Kernel modules: ahci 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at f0148000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] (prog-if 20 [EHCI]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 17 Region 0: Memory at f014c000 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] (prog-if 10 [OHCI]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at f0149000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] (prog-if 20 [EHCI]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin B routed to IRQ 17 Region 0: Memory at f014d000 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller [1002:4385] (rev 42) Subsystem: Advanced Micro Devices, Inc. [AMD] SBx00 SMBus Controller [1022:1510] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4, sp5100_tco 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at f0144000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] (rev 40) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge [1002:4384] (rev 40) (prog-if 01 [Subtractive decode]) Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop+ ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00:14.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399] (prog-if 10 [OHCI]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin C routed to IRQ 18 Region 0: Memory at f014a000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) [1002:43a0] (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 24 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 1) [1002:43a1] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 25 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00001000-00001fff Prefetchable memory behind bridge: 00000000f0000000-00000000f00fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 0 [1022:1700] (rev 43) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 1 [1022:1701] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 2 [1022:1702] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 3 [1022:1703] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied> Kernel driver in use: k10temp Kernel modules: k10temp 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 4 [1022:1704] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 6 [1022:1718] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 5 [1022:1716] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 7 [1022:1719] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06) Subsystem: ASRock Incorporation Motherboard (one of many) [1849:8168] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 26 Region 0: I/O ports at 1000 [size=256] Region 2: Memory at f0004000 (64-bit, prefetchable) [size=4K] Region 4: Memory at f0000000 (64-bit, prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: r8169 Kernel modules: r8169 ** USB devices: Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID feed:1307 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 148f:2870 Ralink Technology, Corp. RT2870 Wireless Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 1241:1122 Belkin Typhoon Stream Optical Mouse USB+PS/2 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.9.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.9.0-1-686-pae depends on: ii initramfs-tools [linux-initramfs-tool] 0.127 ii kmod 23-2 ii linux-base 4.5 Versions of packages linux-image-4.9.0-1-686-pae recommends: ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2.2 Versions of packages linux-image-4.9.0-1-686-pae suggests: pn debian-kernel-handbook <none> ii grub-pc 2.02~beta3-4 pn linux-doc-4.9 <none> Versions of packages linux-image-4.9.0-1-686-pae is related to: ii firmware-amd-graphics 20161130-2 pn firmware-atheros <none> pn firmware-bnx2 <none> pn firmware-bnx2x <none> pn firmware-brcm80211 <none> pn firmware-cavium <none> pn firmware-intel-sound <none> pn firmware-intelwimax <none> pn firmware-ipw2x00 <none> pn firmware-ivtv <none> pn firmware-iwlwifi <none> pn firmware-libertas <none> ii firmware-linux-nonfree 20161130-2 ii firmware-misc-nonfree 20161130-2 pn firmware-myricom <none> pn firmware-netxen <none> pn firmware-qlogic <none> ii firmware-realtek 20161130-2 pn firmware-samsung <none> pn firmware-siano <none> pn firmware-ti-connectivity <none> pn xen-hypervisor <none> -- no debconf information
[toc] | [next] | [standalone]
| From | owner@bugs.debian.org (Debian Bug Tracking System) |
|---|---|
| Date | 2017-01-29 23:30 +0100 |
| Subject | Processed: sp5100_tco: I/O address 0x0cd6 already in use |
| Message-ID | <t568W-4lY-27@gated-at.bofh.it> |
| In reply to | #56829 |
Processing control commands: > forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=170741 Bug #853122 [src:linux] sp5100_tco: I/O address 0x0cd6 already in use Set Bug forwarded-to-address to 'https://bugzilla.kernel.org/show_bug.cgi?id=170741'. -- 853122: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853122 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | Paul Menzel <paulepanter@users.sourceforge.net> |
|---|---|
| Date | 2017-03-03 10:00 +0100 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tgRea-75L-13@gated-at.bofh.it> |
| In reply to | #56829 |
[Multipart message — attachments visible in raw view] — view raw
Dear Linux folks, Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for multiplexed main adapter in SB800) [1] caused a regression. Tim reported that to the Linux Kernel Bugtracker as bug #170741 last September [2], but it looks like the affected subsystems don’t use it. So I just copy his report in here, and put all the people in CC mentioned in the commit, the bug report, and in the subsystems I2C/SMBUS CONTROLLER DRIVERS FOR PC and WATCHDOG DEVICE DRIVERS mentioned in the file `MAINTAINERS`. > On the AMD Turion N40L and other related SoCs, the i2c-piix4 driver > now claims the 0xcd6 ioport, preventing the sp5100_tco watchdog > driver from loading: > > piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 > piix4_smbus 0000:00:14.0: Using register 0x2c for SMBus port selection > piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20 > sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 > sp5100_tco: PCI Vendor ID: 0x1002, Device ID: 0x4385, Revision ID: 0x42 > sp5100_tco: I/O address 0x0cd6 already in use > > > This breaks watchdog operation on existing systems on upgrade and new > deployments unless the i2c-piix4 driver is blacklisted. > > See: > > drivers/watchdog/sp5100_tco.c > > tco_timer_enable(void) > > (SB800_IO_PM_INDEX_REG is defined in drivers/watchdog/sp5100_tco.h) > > This is the commit which prevents the watchdog driver from loading: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2fee61d22e606fc99ade9079fda15fdee83ec33e > > See also AMD docs > > 45483_sb800_bdg_pub_3.03 > > Perhaps a fix is to switch both drivers from static to dynamic > allocation of the IO ports in question, since the watchdog driver > only accesses the port during initialisation (with backoff/retry > maybe to avoid races?). Is there somebody having the resources to implement the dynamic allocation to solve this regression? Thanks, Paul [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2fee61d22e606fc99ade9079fda15fdee83ec33e [2] https://bugzilla.kernel.org/show_bug.cgi?id=170741
[toc] | [prev] | [next] | [standalone]
| From | Wolfram Sang <wsa@the-dreams.de> |
|---|---|
| Date | 2017-03-03 11:30 +0100 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tgStA-8ce-41@gated-at.bofh.it> |
| In reply to | #57144 |
[Multipart message — attachments visible in raw view] — view raw
> Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for > multiplexed main adapter in SB800) [1] caused a regression. Tim > reported that to the Linux Kernel Bugtracker as bug #170741 last > September [2], but it looks like the affected subsystems don’t use it. Jean Delvare pointed out this issue amongst others[1] last year already. Let me quote: === 5* The I/O ports used for SMBus configuration and port switching are also needed by a watchdog driver, sp5100_tco. Both drivers request the region, so the first one wins, and the other driver can't be loaded. sp5100_tco was there first, so the changes done to the i2c-piix4 driver recently will cause a regression for some users by preventing them from using the sp5100_tco and i2c-piix4 drivers at the same time. In the long run I guess we will need a helper module to handle this shared resource. Unless IORESOURCE_MUXED can be used for that. Either way, that's more work than I can put into this before kernel v4.5 is released. For the time being, I think we should simply make it non-fatal if the I/O ports can't be requested, and continue without multiplexing (as before.) === Seems nobody had the resources, so far. I don't have the HW and not much experience with non-embedded platforms. I wonder, though, if we really need to convert the drivers to MFD ones, or if we could use the simpler MFD_SYSCON mechanism which helps in exactly such cases for embedded platforms. But I am really lacking details here and am afraid this is probably all the input I can give currently. Regards, Wolfram [1] http://www.spinics.net/lists/linux-i2c/msg23437.html
[toc] | [prev] | [next] | [standalone]
| From | Paul Menzel <paulepanter@users.sourceforge.net> |
|---|---|
| Date | 2017-03-31 09:30 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tqZ0J-1qH-1@gated-at.bofh.it> |
| In reply to | #57145 |
[Multipart message — attachments visible in raw view] — view raw
Dear Wolfram, Thank you for the reply, which we talked about briefly at the Chemnitzer LinuxTage. Am Freitag, den 03.03.2017, 11:17 +0100 schrieb Wolfram Sang: > > Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for > > multiplexed main adapter in SB800) [1] caused a regression. Tim > > reported that to the Linux Kernel Bugtracker as bug #170741 last > > September [2], but it looks like the affected subsystems don’t use it. > > Jean Delvare pointed out this issue amongst others[1] last year already. > Let me quote: > > === > > 5* The I/O ports used for SMBus configuration and port switching are > also needed by a watchdog driver, sp5100_tco. Both drivers request the > region, so the first one wins, and the other driver can't be loaded. > sp5100_tco was there first, so the changes done to the i2c-piix4 driver > recently will cause a regression for some users by preventing them > from using the sp5100_tco and i2c-piix4 drivers at the same time. In > the long run I guess we will need a helper module to handle this shared > resource. Unless IORESOURCE_MUXED can be used for that. Either way, > that's more work than I can put into this before kernel v4.5 is > released. For the time being, I think we should simply make it > non-fatal if the I/O ports can't be requested, and continue without > multiplexing (as before.) > > === > > Seems nobody had the resources, so far. I still don’t understand, why Jean then not immediately reverted the commit to adhere to the Linux Kernel’s no-regression-policy. > I don't have the HW and not much experience with non-embedded > platforms. I wonder, though, if we really need to convert the drivers > to MFD ones, or if we could use the simpler MFD_SYSCON mechanism > which helps in exactly such cases for embedded platforms. But I am > really lacking details here and am afraid this is probably all the > input I can give currently. Zoltan stepped up, and uploaded a patch for review to the Kernel.org Bugzilla [2], also attached to this message. Christian, Tim, and Nehal could you please test and review it? Thanks, Paul > [1] http://www.spinics.net/lists/linux-i2c/msg23437.html [2] https://bugzilla.kernel.org/show_bug.cgi?id=170741
[toc] | [prev] | [next] | [standalone]
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2017-03-31 15:20 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tr4jM-4Kh-15@gated-at.bofh.it> |
| In reply to | #57388 |
Hi Paul,
On 03/31/2017 12:17 AM, Paul Menzel wrote:
> Dear Wolfram,
>
>
> Thank you for the reply, which we talked about briefly at the
> Chemnitzer LinuxTage.
>
>
> Am Freitag, den 03.03.2017, 11:17 +0100 schrieb Wolfram Sang:
>>> Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for
>>> multiplexed main adapter in SB800) [1] caused a regression. Tim
>>> reported that to the Linux Kernel Bugtracker as bug #170741 last
>>> September [2], but it looks like the affected subsystems don’t use it.
>>
>> Jean Delvare pointed out this issue amongst others[1] last year already.
>> Let me quote:
>>
>> ===
>>
>> 5* The I/O ports used for SMBus configuration and port switching are
>> also needed by a watchdog driver, sp5100_tco. Both drivers request the
>> region, so the first one wins, and the other driver can't be loaded.
>> sp5100_tco was there first, so the changes done to the i2c-piix4 driver
>> recently will cause a regression for some users by preventing them
>> from using the sp5100_tco and i2c-piix4 drivers at the same time. In
>> the long run I guess we will need a helper module to handle this shared
>> resource. Unless IORESOURCE_MUXED can be used for that. Either way,
>> that's more work than I can put into this before kernel v4.5 is
>> released. For the time being, I think we should simply make it
>> non-fatal if the I/O ports can't be requested, and continue without
>> multiplexing (as before.)
>>
>> ===
>>
>> Seems nobody had the resources, so far.
>
> I still don’t understand, why Jean then not immediately reverted the
> commit to adhere to the Linux Kernel’s no-regression-policy.
>
>> I don't have the HW and not much experience with non-embedded
>> platforms. I wonder, though, if we really need to convert the drivers
>> to MFD ones, or if we could use the simpler MFD_SYSCON mechanism
>> which helps in exactly such cases for embedded platforms. But I am
>> really lacking details here and am afraid this is probably all the
>> input I can give currently.
>
> Zoltan stepped up, and uploaded a patch for review to the Kernel.org
> Bugzilla [2], also attached to this message.
>
Please don't send patches as attachments.
request_muxed_region() can fail, and literally every other driver
using it checks for that failure. Please do the same.
The sp5100_tco_dev_name change in the watchdog driver is unnecessary.
There are some unnecessary { } in the watchdog driver after the patch
is applied.
Please split the patch into two patches so they can be reviewed and
applied separately.
Thanks,
Guenter
[toc] | [prev] | [next] | [standalone]
| From | Boszormenyi Zoltan <zboszor@pr.hu> |
|---|---|
| Date | 2017-03-31 16:50 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tr62d-5Sb-1@gated-at.bofh.it> |
| In reply to | #57390 |
2017-03-31 14:49 keltezéssel, Guenter Roeck írta:
> Hi Paul,
>
> On 03/31/2017 12:17 AM, Paul Menzel wrote:
>> Dear Wolfram,
>>
>>
>> Thank you for the reply, which we talked about briefly at the
>> Chemnitzer LinuxTage.
>>
>>
>> Am Freitag, den 03.03.2017, 11:17 +0100 schrieb Wolfram Sang:
>>>> Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for
>>>> multiplexed main adapter in SB800) [1] caused a regression. Tim
>>>> reported that to the Linux Kernel Bugtracker as bug #170741 last
>>>> September [2], but it looks like the affected subsystems don’t use it.
>>>
>>> Jean Delvare pointed out this issue amongst others[1] last year already.
>>> Let me quote:
>>>
>>> ===
>>>
>>> 5* The I/O ports used for SMBus configuration and port switching are
>>> also needed by a watchdog driver, sp5100_tco. Both drivers request the
>>> region, so the first one wins, and the other driver can't be loaded.
>>> sp5100_tco was there first, so the changes done to the i2c-piix4 driver
>>> recently will cause a regression for some users by preventing them
>>> from using the sp5100_tco and i2c-piix4 drivers at the same time. In
>>> the long run I guess we will need a helper module to handle this shared
>>> resource. Unless IORESOURCE_MUXED can be used for that. Either way,
>>> that's more work than I can put into this before kernel v4.5 is
>>> released. For the time being, I think we should simply make it
>>> non-fatal if the I/O ports can't be requested, and continue without
>>> multiplexing (as before.)
>>>
>>> ===
>>>
>>> Seems nobody had the resources, so far.
>>
>> I still don’t understand, why Jean then not immediately reverted the
>> commit to adhere to the Linux Kernel’s no-regression-policy.
>>
>>> I don't have the HW and not much experience with non-embedded
>>> platforms. I wonder, though, if we really need to convert the drivers
>>> to MFD ones, or if we could use the simpler MFD_SYSCON mechanism
>>> which helps in exactly such cases for embedded platforms. But I am
>>> really lacking details here and am afraid this is probably all the
>>> input I can give currently.
>>
>> Zoltan stepped up, and uploaded a patch for review to the Kernel.org
>> Bugzilla [2], also attached to this message.
>>
>
> Please don't send patches as attachments.
>
> request_muxed_region() can fail, and literally every other driver
> using it checks for that failure. Please do the same.
In what circumstances can request_muxed_region() fail? As far as
I can see, only if two drivers use the same I/O port base and the
already present region did not use IORESOURCE_MUXED which is
not the case here. When request_muxed_region() is used consistently,
subsequent requests are put on a wait queue and the first one is
woken up when the region is released. So, it's basically a mutex.
Am I missing something here?
Alternatively, the original "piix4_mutex_sb800" mutex can be moved out
to its own file and used by both drivers. This way, request_muxed_region()
would not be needed at all among these two drivers.
The third option is to remove the request_*region() calls and the mutex
completely.
After all, drivers/usb/host/pci-quirks.c::usb_amd_quirk_pll() also uses
this I/O port pair and this is done without request_*region() or locking.
It is for some AMD devices, SB800 included, for which the function
accesses the same I/O ports used by both i2c-piix4 and sp5100_tco.
/*
* The hardware normally enables the A-link power management feature, which
* lets the system lower the power consumption in idle states.
*
* This USB quirk prevents the link going into that lower power state
* during isochronous transfers.
*
* Without this quirk, isochronous stream on OHCI/EHCI/xHCI controllers of
* some AMD platforms may stutter or have breaks occasionally.
*/
static void usb_amd_quirk_pll(int disable)
This function is hidden behind two wrappers: usb_amd_quirk_pll_disable()
and usb_amd_quirk_pll_enable() and these are used from:
drivers/usb/host/ohci-q.c
drivers/usb/host/xhci-ring.c
drivers/usb/host/ehci-sched.c
> The sp5100_tco_dev_name change in the watchdog driver is unnecessary.
request_muxed_region() requires a const char * name to be passed.
sp5100_tco uses a different DEVNAME for the two device generations.
I wanted to preserve this distinction but dev_name is local to
sp5100_tco_setupdevice() and it would have been an overkill to call
tco_has_sp5100_reg_layout() every time the code executes
request_muxed_region().
Are you saying that this distinction is unnecessary, too?
I would prefer a single DEVNAME that just contains the driver name.
Less code, less confusion.
> There are some unnecessary { } in the watchdog driver after the patch
> is applied.
True, there are two places.
> Please split the patch into two patches so they can be reviewed and
> applied separately.
Likely I will, but I would like to hear the others' opinion, too.
1. a single patch with a single goal: protect I/O port access
for SB800 across the whole kernel
2. patch series for same goal for the two drivers separately
(or three if pci-quirks.c needs to change as well)
and
A) a common mutex across the two (three) drivers in the kernel, or
B) request_muxed_region() with retrying in the usual manner if it fails:
#define enter_sb800() \
do { \
} while (!request_muxed_region(...))
Best regards,
Zoltán Böszörményi
[toc] | [prev] | [next] | [standalone]
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2017-03-31 17:10 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tr6lA-6eB-25@gated-at.bofh.it> |
| In reply to | #57399 |
On Fri, Mar 31, 2017 at 04:46:02PM +0200, Boszormenyi Zoltan wrote:
> 2017-03-31 14:49 keltezéssel, Guenter Roeck írta:
> >Hi Paul,
> >
> >On 03/31/2017 12:17 AM, Paul Menzel wrote:
> >>Dear Wolfram,
> >>
> >>
> >>Thank you for the reply, which we talked about briefly at the
> >>Chemnitzer LinuxTage.
> >>
> >>
> >>Am Freitag, den 03.03.2017, 11:17 +0100 schrieb Wolfram Sang:
> >>>>Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for
> >>>>multiplexed main adapter in SB800) [1] caused a regression. Tim
> >>>>reported that to the Linux Kernel Bugtracker as bug #170741 last
> >>>>September [2], but it looks like the affected subsystems don’t use it.
> >>>
> >>>Jean Delvare pointed out this issue amongst others[1] last year already.
> >>>Let me quote:
> >>>
> >>>===
> >>>
> >>>5* The I/O ports used for SMBus configuration and port switching are
> >>>also needed by a watchdog driver, sp5100_tco. Both drivers request the
> >>>region, so the first one wins, and the other driver can't be loaded.
> >>>sp5100_tco was there first, so the changes done to the i2c-piix4 driver
> >>>recently will cause a regression for some users by preventing them
> >>>from using the sp5100_tco and i2c-piix4 drivers at the same time. In
> >>>the long run I guess we will need a helper module to handle this shared
> >>>resource. Unless IORESOURCE_MUXED can be used for that. Either way,
> >>>that's more work than I can put into this before kernel v4.5 is
> >>>released. For the time being, I think we should simply make it
> >>>non-fatal if the I/O ports can't be requested, and continue without
> >>>multiplexing (as before.)
> >>>
> >>>===
> >>>
> >>>Seems nobody had the resources, so far.
> >>
> >>I still don’t understand, why Jean then not immediately reverted the
> >>commit to adhere to the Linux Kernel’s no-regression-policy.
> >>
> >>>I don't have the HW and not much experience with non-embedded
> >>>platforms. I wonder, though, if we really need to convert the drivers
> >>>to MFD ones, or if we could use the simpler MFD_SYSCON mechanism
> >>>which helps in exactly such cases for embedded platforms. But I am
> >>>really lacking details here and am afraid this is probably all the
> >>>input I can give currently.
> >>
> >>Zoltan stepped up, and uploaded a patch for review to the Kernel.org
> >>Bugzilla [2], also attached to this message.
> >>
> >
> >Please don't send patches as attachments.
> >
> >request_muxed_region() can fail, and literally every other driver
> >using it checks for that failure. Please do the same.
>
> In what circumstances can request_muxed_region() fail? As far as
> I can see, only if two drivers use the same I/O port base and the
> already present region did not use IORESOURCE_MUXED which is
> not the case here. When request_muxed_region() is used consistently,
> subsequent requests are put on a wait queue and the first one is
> woken up when the region is released. So, it's basically a mutex.
> Am I missing something here?
>
Yes. failure to allocate the resource is one. The other is that you are
making the assumption that all other requesters have IORESOURCE_MUXED set.
There is no guarantee that this is the case.
Guenter
> Alternatively, the original "piix4_mutex_sb800" mutex can be moved out
> to its own file and used by both drivers. This way, request_muxed_region()
> would not be needed at all among these two drivers.
>
> The third option is to remove the request_*region() calls and the mutex
> completely.
>
> After all, drivers/usb/host/pci-quirks.c::usb_amd_quirk_pll() also uses
> this I/O port pair and this is done without request_*region() or locking.
> It is for some AMD devices, SB800 included, for which the function
> accesses the same I/O ports used by both i2c-piix4 and sp5100_tco.
>
> /*
> * The hardware normally enables the A-link power management feature, which
> * lets the system lower the power consumption in idle states.
> *
> * This USB quirk prevents the link going into that lower power state
> * during isochronous transfers.
> *
> * Without this quirk, isochronous stream on OHCI/EHCI/xHCI controllers of
> * some AMD platforms may stutter or have breaks occasionally.
> */
> static void usb_amd_quirk_pll(int disable)
>
> This function is hidden behind two wrappers: usb_amd_quirk_pll_disable()
> and usb_amd_quirk_pll_enable() and these are used from:
>
> drivers/usb/host/ohci-q.c
> drivers/usb/host/xhci-ring.c
> drivers/usb/host/ehci-sched.c
>
> >The sp5100_tco_dev_name change in the watchdog driver is unnecessary.
>
> request_muxed_region() requires a const char * name to be passed.
> sp5100_tco uses a different DEVNAME for the two device generations.
> I wanted to preserve this distinction but dev_name is local to
> sp5100_tco_setupdevice() and it would have been an overkill to call
> tco_has_sp5100_reg_layout() every time the code executes
> request_muxed_region().
>
> Are you saying that this distinction is unnecessary, too?
> I would prefer a single DEVNAME that just contains the driver name.
> Less code, less confusion.
>
> >There are some unnecessary { } in the watchdog driver after the patch
> >is applied.
>
> True, there are two places.
>
> >Please split the patch into two patches so they can be reviewed and
> >applied separately.
>
> Likely I will, but I would like to hear the others' opinion, too.
>
> 1. a single patch with a single goal: protect I/O port access
> for SB800 across the whole kernel
> 2. patch series for same goal for the two drivers separately
> (or three if pci-quirks.c needs to change as well)
>
> and
>
> A) a common mutex across the two (three) drivers in the kernel, or
> B) request_muxed_region() with retrying in the usual manner if it fails:
>
> #define enter_sb800() \
> do { \
> } while (!request_muxed_region(...))
>
> Best regards,
> Zoltán Böszörményi
>
[toc] | [prev] | [next] | [standalone]
| From | Boszormenyi Zoltan <zboszor@pr.hu> |
|---|---|
| Date | 2017-04-01 12:20 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <troit-1f0-1@gated-at.bofh.it> |
| In reply to | #57400 |
2017-03-31 17:05 keltezéssel, Guenter Roeck írta: > On Fri, Mar 31, 2017 at 04:46:02PM +0200, Boszormenyi Zoltan wrote: >> 2017-03-31 14:49 keltezéssel, Guenter Roeck írta: >>> request_muxed_region() can fail, and literally every other driver >>> using it checks for that failure. Please do the same. >> >> In what circumstances can request_muxed_region() fail? As far as >> I can see, only if two drivers use the same I/O port base and the >> already present region did not use IORESOURCE_MUXED which is >> not the case here. When request_muxed_region() is used consistently, >> subsequent requests are put on a wait queue and the first one is >> woken up when the region is released. So, it's basically a mutex. >> Am I missing something here? >> > > Yes. failure to allocate the resource is one. So, a common mutex should be used. I have also added synchronization to the USB PCI quirks code and have split the patch into three pieces now (USB quirks, i2c-piix4 and sp5100_tco) and they were sent to the relevant mailing lists. I don't know which subsystem wants to take it, all 3 patches are needed at once. Best regards, Zoltán Böszörményi
[toc] | [prev] | [next] | [standalone]
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2017-04-01 15:40 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <trrq1-3jA-3@gated-at.bofh.it> |
| In reply to | #57407 |
On 04/01/2017 03:13 AM, Boszormenyi Zoltan wrote: > 2017-03-31 17:05 keltezéssel, Guenter Roeck írta: >> On Fri, Mar 31, 2017 at 04:46:02PM +0200, Boszormenyi Zoltan wrote: >>> 2017-03-31 14:49 keltezéssel, Guenter Roeck írta: >>>> request_muxed_region() can fail, and literally every other driver >>>> using it checks for that failure. Please do the same. >>> >>> In what circumstances can request_muxed_region() fail? As far as >>> I can see, only if two drivers use the same I/O port base and the >>> already present region did not use IORESOURCE_MUXED which is >>> not the case here. When request_muxed_region() is used consistently, >>> subsequent requests are put on a wait queue and the first one is >>> woken up when the region is released. So, it's basically a mutex. >>> Am I missing something here? >>> >> >> Yes. failure to allocate the resource is one. > > So, a common mutex should be used. > Just because you don't want to check for errors ? I am not on favor of your new solution. I think it violates layering all over the place, and I dislike the idea of having a global mutex as you propose. I won't shut it down, but I'll let others provide feedback on your new series of patches. Guenter > I have also added synchronization to the USB PCI quirks code and > have split the patch into three pieces now (USB quirks, i2c-piix4 and > sp5100_tco) and they were sent to the relevant mailing lists. > > I don't know which subsystem wants to take it, all 3 patches are > needed at once. > > Best regards, > Zoltán Böszörményi >
[toc] | [prev] | [next] | [standalone]
| From | Boszormenyi Zoltan <zboszor@pr.hu> |
|---|---|
| Date | 2017-04-01 18:30 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tru4x-5au-3@gated-at.bofh.it> |
| In reply to | #57408 |
2017-04-01 15:32 keltezéssel, Guenter Roeck írta:
> On 04/01/2017 03:13 AM, Boszormenyi Zoltan wrote:
>> 2017-03-31 17:05 keltezéssel, Guenter Roeck írta:
>>> On Fri, Mar 31, 2017 at 04:46:02PM +0200, Boszormenyi Zoltan wrote:
>>>> 2017-03-31 14:49 keltezéssel, Guenter Roeck írta:
>>>>> request_muxed_region() can fail, and literally every other driver
>>>>> using it checks for that failure. Please do the same.
>>>>
>>>> In what circumstances can request_muxed_region() fail? As far as
>>>> I can see, only if two drivers use the same I/O port base and the
>>>> already present region did not use IORESOURCE_MUXED which is
>>>> not the case here. When request_muxed_region() is used consistently,
>>>> subsequent requests are put on a wait queue and the first one is
>>>> woken up when the region is released. So, it's basically a mutex.
>>>> Am I missing something here?
>>>>
>>>
>>> Yes. failure to allocate the resource is one.
>>
>> So, a common mutex should be used.
>>
>
> Just because you don't want to check for errors ?
>
> I am not on favor of your new solution. I think it violates layering all over
> the place, and I dislike the idea of having a global mutex as you propose.
> I won't shut it down, but I'll let others provide feedback on your new series
> of patches.
It's not because I don't want to check for errors, it's about avoiding them.
It's not my favourite either but there is a lot of weight in existing code.
You cannot avoid layering violations if multiple driver subsystems use
their respective functionality in devices in multiplexed way.
The biggest problem is that quirk functions, including usb_amd_quirk_pll()
has the "void" return type so there is no way to indicate errors to the
callers in case of an error.
The best clean alternative would be add new resource handling infrastructure.
* Expose the currently static alloc_resource() in kernel/resource.c
With this, driver initialization can allocate the resource once
for the lifetime of the driver and it it fails,
* Add a new insert_muxed_region() / __insert_muxed_region() function with
different semantics from request_muxed_region() / __request_region():
1 Accept a pointer to already allocated resource.
2 If the conflicting resource doesn't have IORESOURCE_MUXED set,
complain loudly in the syslog but still go into the wait queue.
The conflicting resource also has the name which can be printed
so the inconsistent resource / region usage can be fixed.
We can also just modify the __request_region() semantics, so:
1 It accepts a pointer to an allocated resource or NULL.
In the second case, the resource is allocated internally and can
still fail.
2 The above second point. But this may cause an error in code that
expects the old semantics.
The window for request_muxed_region()+release_region() is so short
that the requested I/O port range would not show up in /proc/ioports.
All this would be to fix only 3 drivers in a no-error scenario and only
achieving the functionality of a mutex seems to be overkill.
Another alternative is to revert commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
that caused the regression in sp5100_tco in the first place.
Best regards,
Zoltán Böszörményi
[toc] | [prev] | [next] | [standalone]
| From | Boszormenyi Zoltan <zboszor@pr.hu> |
|---|---|
| Date | 2017-04-01 18:40 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <trued-5f3-1@gated-at.bofh.it> |
| In reply to | #57409 |
2017-04-01 18:20 keltezéssel, Boszormenyi Zoltan írta: > The best clean alternative would be add new resource handling infrastructure. > * Expose the currently static alloc_resource() in kernel/resource.c > With this, driver initialization can allocate the resource once > for the lifetime of the driver and it it fails, (unfinished sentence) then the failure is during driver initialization, not during runtime, possibly days or weeks later. > * Add a new insert_muxed_region() / __insert_muxed_region() function with > different semantics from request_muxed_region() / __request_region(): > 1 Accept a pointer to already allocated resource. > 2 If the conflicting resource doesn't have IORESOURCE_MUXED set, > complain loudly in the syslog but still go into the wait queue. > The conflicting resource also has the name which can be printed > so the inconsistent resource / region usage can be fixed. > We can also just modify the __request_region() semantics, so: > 1 It accepts a pointer to an allocated resource or NULL. > In the second case, the resource is allocated internally and can > still fail. > 2 The above second point. But this may cause an error in code that > expects the old semantics. > > The window for request_muxed_region()+release_region() is so short > that the requested I/O port range would not show up in /proc/ioports. > > All this would be to fix only 3 drivers in a no-error scenario and only > achieving the functionality of a mutex seems to be overkill. > > Another alternative is to revert commit 2fee61d22e606fc99ade9079fda15fdee83ec33e > that caused the regression in sp5100_tco in the first place. > > Best regards, > Zoltán Böszörményi >
[toc] | [prev] | [next] | [standalone]
| From | Paul Menzel <paulepanter@users.sourceforge.net> |
|---|---|
| Date | 2017-04-03 08:40 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <ts3OF-3h7-5@gated-at.bofh.it> |
| In reply to | #57407 |
[Multipart message — attachments visible in raw view] — view raw
Dear Zoltán, Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: […] > and have split the patch into three pieces now (USB quirks, i2c-piix4 > and sp5100_tco) and they were sent to the relevant mailing lists. Could you please add me to the receiver list of these patches, so that I can test them? Maybe also Christian (the commit author introducing the regression), Tim (bug reporter), and Nehal from AMD? If you uploaded them to the Kernel.org Bugtracker, that’d also work for me. Thanks, Paul
[toc] | [prev] | [next] | [standalone]
| From | Boszormenyi Zoltan <zboszor@pr.hu> |
|---|---|
| Date | 2017-04-03 10:10 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <ts546-3XB-33@gated-at.bofh.it> |
| In reply to | #57427 |
Hi, 2017-04-03 08:34 keltezéssel, Paul Menzel írta: > Dear Zoltán, > > > Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: > > […] > >> and have split the patch into three pieces now (USB quirks, i2c-piix4 >> and sp5100_tco) and they were sent to the relevant mailing lists. > > Could you please add me to the receiver list of these patches, so that > I can test them? Maybe also Christian (the commit author introducing > the regression), Tim (bug reporter), and Nehal from AMD? > > If you uploaded them to the Kernel.org Bugtracker, that’d also work for > me. did both. Best regards, Zoltán Böszörményi > > > Thanks, > > Paul >
[toc] | [prev] | [next] | [standalone]
| From | Boszormenyi Zoltan <zboszor@pr.hu> |
|---|---|
| Date | 2017-06-27 14:30 +0200 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <tWXjY-8qo-15@gated-at.bofh.it> |
| In reply to | #57429 |
2017-04-03 09:59 keltezéssel, Boszormenyi Zoltan írta: > Hi, > > 2017-04-03 08:34 keltezéssel, Paul Menzel írta: >> Dear Zoltán, >> >> >> Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: >> >> […] >> >>> and have split the patch into three pieces now (USB quirks, i2c-piix4 >>> and sp5100_tco) and they were sent to the relevant mailing lists. >> >> Could you please add me to the receiver list of these patches, so that >> I can test them? Maybe also Christian (the commit author introducing >> the regression), Tim (bug reporter), and Nehal from AMD? >> >> If you uploaded them to the Kernel.org Bugtracker, that’d also work for >> me. > > did both. There's a new set of packages sent to all relevant mailing lists and also attached to the kernel bugtracker at https://bugzilla.kernel.org/show_bug.cgi?id=170741 Hopefully this approach will work for everyone. > > Best regards, > Zoltán Böszörményi > >> >> >> Thanks, >> >> Paul >> >
[toc] | [prev] | [next] | [standalone]
| From | Carl N <carlnikolov@gmail.com> |
|---|---|
| Date | 2017-08-31 04:40 +0200 |
| Subject | Bug#853122: Same Error |
| Message-ID | <uknyG-8ei-1@gated-at.bofh.it> |
| In reply to | #56829 |
[Multipart message — attachments visible in raw view] — view raw
I am getting the same error kernel: sp5100_tco: I/O address 0x0cd6 already in use Is there a solution yet? Carl
[toc] | [prev] | [next] | [standalone]
| From | Sisim Biva <sisimbiva@gmail.com> |
|---|---|
| Date | 2017-10-02 10:20 +0200 |
| Subject | Bug#853122: Same error sp5100_tco: I/O address 0x0cd6 already in use |
| Message-ID | <uw47f-4VO-3@gated-at.bofh.it> |
| In reply to | #56829 |
Hello, I'm having the same issue :( Any update on this bug? Thank you! Config: System: Debian GNU/Linux 9.1 (stretch) CPU: 4.9.0-3-amd64 Motherboard: AMD E-350D APU with Radeon(tm) HD Graphics ASRock E350M1
[toc] | [prev] | [next] | [standalone]
| From | alain BELLEC <alain_bellec@bbox.fr> |
|---|---|
| Date | 2017-10-02 12:30 +0200 |
| Subject | Bug#853122: posts bugs |
| Message-ID | <uw693-66R-3@gated-at.bofh.it> |
| In reply to | #56829 |
pouvez vous cesser de m'envoyer des rapports de bug .merci . Can stop you to send me of the reports of bug .merci.
[toc] | [prev] | [next] | [standalone]
| From | Gyorgy Kapolnas <rty042@gmail.com> |
|---|---|
| Date | 2017-11-22 12:30 +0100 |
| Subject | Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset |
| Message-ID | <uOBo5-7ux-1@gated-at.bofh.it> |
| In reply to | #56829 |
Same issue here :( OS: Debian 9.2 amd64 MoBo: Asus Prime B350M-A (with Ryzen 7 CPU) Linux version 4.9.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28) ... sp5100_tco: I/O address 0x0cd6 already in use
[toc] | [prev] | [next] | [standalone]
| From | Rainer Dorsch <ml@bokomoko.de> |
|---|---|
| Date | 2017-12-16 21:30 +0100 |
| Subject | Bug#853122: linux-image-4.13.0-0.bpo.1-amd64: Also present at Gigabyte GA-AM1M-S2H |
| Message-ID | <uXrfP-72u-9@gated-at.bofh.it> |
| In reply to | #56829 |
Package: src:linux
Version: 4.13.13-1~bpo9+1
Followup-For: Bug #853122
Dear Maintainer,
for reference: this issue is still present in 4.13.13 (which is expected, since upstream did not yet handle Zoltan's patches) and applies to my Gigabyte GA-AM1M-S2H mainboard.
Regards
Rainer
-- Package-specific info:
** Version:
Linux version 4.13.0-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.13.13-1~bpo9+1 (2017-11-22)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.13.0-0.bpo.1-amd64 root=UUID=bd19343e-2b8e-4052-989c-2627246c915f ro quiet
** Not tainted
** Kernel log:
[ 4.022597] [drm] RAM width 128bits DDR
[ 4.032093] [TTM] Zone kernel: Available graphics memory: 1736752 kiB
[ 4.032096] [TTM] Initializing pool allocator
[ 4.032103] [TTM] Initializing DMA pool allocator
[ 4.032147] [drm] radeon: 512M of VRAM memory ready
[ 4.032149] [drm] radeon: 2048M of GTT memory ready.
[ 4.032170] [drm] Loading kabini Microcode
[ 4.032988] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/kabini_pfp.bin
[ 4.033347] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/kabini_me.bin
[ 4.033550] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/kabini_ce.bin
[ 4.033828] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/kabini_mec.bin
[ 4.034051] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/kabini_rlc.bin
[ 4.034370] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/kabini_sdma.bin
[ 4.034379] [drm] Internal thermal controller without fan control
[ 4.035646] [drm] radeon: dpm initialized
[ 4.036687] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/bonaire_uvd.bin
[ 4.036699] [drm] Found UVD firmware Version: 1.64 Family ID: 9
[ 4.037329] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/BONAIRE_vce.bin
[ 4.039173] [drm] Found VCE firmware/feedback version 40.2.2 / 15!
[ 4.039214] [drm] GART: num cpu pages 524288, num gpu pages 524288
[ 4.069861] [drm] PCIE GART of 2048M enabled (table at 0x000000000030E000).
[ 4.070084] radeon 0000:00:01.0: WB enabled
[ 4.070104] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffffa084b742bc00
[ 4.070107] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000020000c04 and cpu addr 0xffffa084b742bc04
[ 4.070109] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000020000c08 and cpu addr 0xffffa084b742bc08
[ 4.070112] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffffa084b742bc0c
[ 4.070114] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000020000c10 and cpu addr 0xffffa084b742bc10
[ 4.071045] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000078d30 and cpu addr 0xffffaf3641c38d30
[ 4.071390] radeon 0000:00:01.0: fence driver on ring 6 use gpu addr 0x0000000020000c18 and cpu addr 0xffffa084b742bc18
[ 4.071393] radeon 0000:00:01.0: fence driver on ring 7 use gpu addr 0x0000000020000c1c and cpu addr 0xffffa084b742bc1c
[ 4.071396] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 4.071397] [drm] Driver supports precise vblank timestamp query.
[ 4.071457] radeon 0000:00:01.0: radeon: using MSI.
[ 4.071495] [drm] radeon: irq initialized.
[ 4.078830] Adding 8378364k swap on /dev/sda5. Priority:-1 extents:1 across:8378364k SSFS
[ 4.090169] [drm] ring test on 0 succeeded in 2 usecs
[ 4.090284] [drm] ring test on 1 succeeded in 3 usecs
[ 4.090306] [drm] ring test on 2 succeeded in 3 usecs
[ 4.090523] [drm] ring test on 3 succeeded in 4 usecs
[ 4.090531] [drm] ring test on 4 succeeded in 4 usecs
[ 4.136627] [drm] ring test on 5 succeeded in 1 usecs
[ 4.157135] [drm] UVD initialized successfully.
[ 4.266822] [drm] ring test on 6 succeeded in 15 usecs
[ 4.266842] [drm] ring test on 7 succeeded in 3 usecs
[ 4.266843] [drm] VCE initialized successfully.
[ 4.269850] [drm] ib test on ring 0 succeeded in 0 usecs
[ 4.429744] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[ 4.573427] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
[ 4.650006] random: crng init done
[ 4.678518] audit: type=1400 audit(1513451935.668:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" pid=458 comm="apparmor_parser"
[ 4.683342] audit: type=1400 audit(1513451935.673:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=459 comm="apparmor_parser"
[ 4.683350] audit: type=1400 audit(1513451935.673:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd" pid=459 comm="apparmor_parser"
[ 4.683355] audit: type=1400 audit(1513451935.673:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd//third_party" pid=459 comm="apparmor_parser"
[ 4.684961] audit: type=1400 audit(1513451935.674:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld-akonadi" pid=461 comm="apparmor_parser"
[ 4.684968] audit: type=1400 audit(1513451935.674:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/mysqld-akonadi///usr/sbin/mysqld" pid=461 comm="apparmor_parser"
[ 4.686819] audit: type=1400 audit(1513451935.676:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/telepathy/mission-control-5" pid=457 comm="apparmor_parser"
[ 4.686825] audit: type=1400 audit(1513451935.676:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/telepathy/telepathy-*" pid=457 comm="apparmor_parser"
[ 4.686829] audit: type=1400 audit(1513451935.676:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/telepathy/telepathy-*//pxgsettings" pid=457 comm="apparmor_parser"
[ 4.796159] [drm] ib test on ring 1 succeeded in 0 usecs
[ 5.274520] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[ 5.276299] r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw
[ 5.308041] [drm] ib test on ring 2 succeeded in 0 usecs
[ 5.308109] [drm] ib test on ring 3 succeeded in 0 usecs
[ 5.308166] [drm] ib test on ring 4 succeeded in 0 usecs
[ 5.327122] usb 7-4: set resolution quirk: cval->res = 384
[ 5.327430] usbcore: registered new interface driver snd-usb-audio
[ 5.394263] r8169 0000:02:00.0 enp2s0: link down
[ 5.394265] r8169 0000:02:00.0 enp2s0: link down
[ 5.395212] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[ 5.852263] [drm] ib test on ring 5 succeeded
[ 5.872978] [drm] ib test on ring 6 succeeded
[ 5.873591] [drm] ib test on ring 7 succeeded
[ 5.874140] [drm] Radeon Display Connectors
[ 5.874142] [drm] Connector 0:
[ 5.874143] [drm] HDMI-A-1
[ 5.874143] [drm] HPD1
[ 5.874146] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[ 5.874146] [drm] Encoders:
[ 5.874147] [drm] DFP1: INTERNAL_UNIPHY
[ 5.874148] [drm] Connector 1:
[ 5.874149] [drm] VGA-1
[ 5.874151] [drm] DDC: 0x65c0 0x65c0 0x65c4 0x65c4 0x65c8 0x65c8 0x65cc 0x65cc
[ 5.874151] [drm] Encoders:
[ 5.874152] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 5.930520] [drm] fb mappable at 0xC0722000
[ 5.930525] [drm] vram apper at 0xC0000000
[ 5.930528] [drm] size 5242880
[ 5.930531] [drm] fb depth is 24
[ 5.930533] [drm] pitch is 5120
[ 5.930866] fbcon: radeondrmfb (fb0) is primary device
[ 5.973965] Console: switching to colour frame buffer device 160x64
[ 5.980230] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[ 6.012208] [drm] Initialized radeon 2.50.0 20080528 for 0000:00:01.0 on minor 0
[ 6.038573] [drm] amdgpu kernel modesetting enabled.
[ 7.573781] r8169 0000:02:00.0 enp2s0: link up
[ 7.573800] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[ 16.093477] usb 7-4: reset high-speed USB device number 2 using xhci_hcd
[ 27.146183] fuse init (API version 7.26)
[ 31.777619] kauditd_printk_skb: 8 callbacks suppressed
[ 31.777622] audit: type=1400 audit(1513451962.767:19): apparmor="DENIED" operation="open" profile="/usr/lib/telepathy/mission-control-5" name="/usr/share/accounts/providers/ktp-jabber.provider" pid=2087 comm="mission-control" requested_mask="r" denied_mask="r" fsuid=2809 ouid=0
** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: AM1M-S2H
product_version: To be filled by O.E.M.
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: F1
board_vendor: Gigabyte Technology Co., Ltd.
board_name: AM1M-S2H
board_version: x.x
** Loaded modules:
fuse
amdgpu
mfd_core
amdkfd
amd_freq_sensitivity
edac_mce_amd
kvm_amd
kvm
irqbypass
crct10dif_pclmul
crc32_pclmul
joydev
radeon
uvcvideo
ttm
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
snd_usb_audio
videobuf2_core
snd_hda_codec_realtek
videodev
media
snd_hda_codec_generic
ghash_clmulni_intel
k10temp
fam15h_power
drm_kms_helper
snd_usbmidi_lib
snd_rawmidi
snd_hda_codec_hdmi
evdev
snd_seq_device
snd_hda_intel
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
snd
pcspkr
soundcore
drm
sg
sp5100_tco
i2c_algo_bit
shpchp
button
acpi_cpufreq
parport_pc
ppdev
lp
sunrpc
parport
loop
dm_crypt
dm_mod
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
btrfs
crc32c_generic
xor
hid_cherry
raid6_pq
hid_generic
usbhid
hid
sd_mod
crc32c_intel
ohci_pci
aesni_intel
aes_x86_64
crypto_simd
cryptd
glue_helper
i2c_piix4
ahci
libahci
xhci_pci
ehci_pci
ohci_hcd
libata
xhci_hcd
ehci_hcd
scsi_mod
r8169
usbcore
mii
usb_common
** Network interface configuration:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
** Network status:
*** IP interfaces and addresses:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 74:d4:35:7b:0d:d8 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.202/24 brd 192.168.0.255 scope global dynamic enp2s0
valid_lft 863279sec preferred_lft 863279sec
inet6 2a02:8070:8982:aa00:c006:ef9b:887:d506/64 scope global temporary dynamic
valid_lft 6938sec preferred_lft 3338sec
inet6 2a02:8070:8982:aa00:76d4:35ff:fe7b:dd8/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 6938sec preferred_lft 3338sec
inet6 fe80::76d4:35ff:fe7b:dd8/64 scope link
valid_lft forever preferred_lft forever
*** Device statistics:
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 15396 194 0 0 0 0 0 0 15396 194 0 0 0 0 0 0
enp2s0: 107558505 87430 0 0 0 0 0 433 8312464 27090 0 0 0 0 0 0
*** Protocol statistics:
Ip:
Forwarding: 2
20252 total packets received
1 with invalid addresses
0 forwarded
0 incoming packets discarded
20251 incoming packets delivered
19399 requests sent out
40 outgoing packets dropped
2 dropped because of missing route
Icmp:
80 ICMP messages received
0 input ICMP message failed
ICMP input histogram:
destination unreachable: 80
80 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 80
IcmpMsg:
InType3: 80
OutType3: 80
Tcp:
534 active connection openings
30 passive connection openings
3 failed connection attempts
136 connection resets received
26 connections established
21054 segments received
18290 segments sent out
85 segments retransmitted
10 bad segments received
477 resets sent
Udp:
7291 packets received
80 packets to unknown port received
0 packet receive errors
7809 packets sent
0 receive buffer errors
0 send buffer errors
IgnoredMulti: 100
UdpLite:
TcpExt:
174 TCP sockets finished time wait in fast timer
372 delayed acks sent
Quick ack mode was activated 51 times
3 packets directly queued to recvmsg prequeue
TCPDirectCopyFromPrequeue: 5
14405 packet headers predicted
1927 acknowledgments not containing data payload received
980 predicted acknowledgments
Detected reordering 2 times using SACK
13 congestion windows recovered without slow start after partial ack
TCPTimeouts: 22
TCPLossProbes: 27
TCPLossProbeRecovery: 1
TCPDSACKOldSent: 51
TCPDSACKRecv: 25
131 connections reset due to unexpected data
127 connections reset due to early user close
3 connections aborted due to timeout
TCPDSACKIgnoredNoUndo: 13
TCPSackShiftFallback: 11
TCPDeferAcceptDrop: 2
TCPRcvCoalesce: 7221
TCPOFOQueue: 483
TCPChallengeACK: 10
TCPSYNChallenge: 10
TCPAutoCorking: 310
TCPFromZeroWindowAdv: 1
TCPToZeroWindowAdv: 1
TCPWantZeroWindowAdv: 1
TCPSynRetrans: 31
TCPOrigDataSent: 3625
TCPKeepAlive: 475
IpExt:
InMcastPkts: 297
OutMcastPkts: 56
InBcastPkts: 103
OutBcastPkts: 3
InOctets: 71510370
OutOctets: 6734142
InMcastOctets: 96690
OutMcastOctets: 10695
InBcastOctets: 8541
OutBcastOctets: 2901
InNoECTPkts: 60852
** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Root Complex [1022:1536]
Subsystem: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Root Complex [1022:1536]
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8400 / R3 Series] [1002:9830] (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd Kabini [Radeon HD 8400 / R3 Series] [1458:d000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 44
Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M]
Region 4: I/O ports at f000 [size=256]
Region 5: Memory at feb00000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu
00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini HDMI/DP Audio [1002:9840]
Subsystem: Gigabyte Technology Co., Ltd Kabini HDMI/DP Audio [1458:a002]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 42
Region 0: Memory at feb64000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Function 0 [1022:1538]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1 [1022:1439] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 25
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: fea00000-feafffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1 [1022:1439] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 27
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fe900000-fe9fffff
Prefetchable memory behind bridge: 00000000d0800000-00000000d08fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
Kernel modules: shpchp
00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7814] (rev 01) (prog-if 30 [XHCI])
Subsystem: Gigabyte Technology Co., Ltd FCH USB XHCI Controller [1458:5004]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at feb68000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7801] (rev 40) (prog-if 01 [AHCI 1.0])
Subsystem: Gigabyte Technology Co., Ltd FCH SATA Controller [AHCI mode] [1458:b002]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Interrupt: pin A routed to IRQ 35
Region 0: I/O ports at f140 [size=8]
Region 1: I/O ports at f130 [size=4]
Region 2: I/O ports at f120 [size=8]
Region 3: I/O ports at f110 [size=4]
Region 4: I/O ports at f100 [size=16]
Region 5: Memory at feb6e000 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ahci
Kernel modules: ahci
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 39) (prog-if 10 [OHCI])
Subsystem: Gigabyte Technology Co., Ltd FCH USB OHCI Controller [1458:5004]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at feb6d000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci
00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 39) (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd FCH USB EHCI Controller [1458:5004]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at feb6c000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller [1022:7807] (rev 39) (prog-if 10 [OHCI])
Subsystem: Gigabyte Technology Co., Ltd FCH USB OHCI Controller [1458:5004]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at feb6b000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci
00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 39) (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd FCH USB EHCI Controller [1458:5004]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at feb6a000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:780b] (rev 3a)
Subsystem: Gigabyte Technology Co., Ltd FCH SMBus Controller [1458:780b]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4, sp5100_tco
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller [1022:780d] (rev 02)
Subsystem: Gigabyte Technology Co., Ltd FCH Azalia Controller [1458:a002]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at feb60000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:780e] (rev 11)
Subsystem: Gigabyte Technology Co., Ltd FCH LPC Bridge [1458:780e]
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Function 0 [1022:1530]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Function 1 [1022:1531]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Function 2 [1022:1532]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Function 3 [1022:1533]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: <access denied>
Kernel driver in use: k10temp
Kernel modules: k10temp
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Function 4 [1022:1534]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Kernel driver in use: fam15h_power
Kernel modules: fam15h_power
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Function 5 [1022:1535]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
01:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03) (prog-if 30 [XHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 24
Region 0: Memory at fea00000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet [1458:e000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 29
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at fe900000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory at d0800000 (64-bit, prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169
** USB devices:
Bus 002 Device 005: ID 046d:c00e Logitech, Inc. M-BJ58/M-BJ69 Optical Wheel Mouse
Bus 002 Device 004: ID 046a:0023 Cherry GmbH CyMotion Master Linux Keyboard G230
Bus 002 Device 003: ID 046d:0a44 Logitech, Inc. Headset H390
Bus 002 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 04b4:fd13 Cypress Semiconductor Corp. Programmable power socket
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 002: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
-- System Information:
Debian Release: 9.3
APT prefers stable
APT policy: (500, 'stable'), (90, 'testing'), (80, 'unstable'), (70, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages linux-image-4.13.0-0.bpo.1-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.130
ii kmod 23-2
ii linux-base 4.5
Versions of packages linux-image-4.13.0-0.bpo.1-amd64 recommends:
ii apparmor 2.11.0-3
ii firmware-linux-free 3.4
ii irqbalance 1.1.0-2.3
Versions of packages linux-image-4.13.0-0.bpo.1-amd64 suggests:
pn debian-kernel-handbook <none>
ii grub-pc 2.02~beta3-5
pn linux-doc-4.13 <none>
Versions of packages linux-image-4.13.0-0.bpo.1-amd64 is related to:
ii firmware-amd-graphics 20161130-3
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
pn firmware-brcm80211 <none>
pn firmware-cavium <none>
pn firmware-intel-sound <none>
pn firmware-intelwimax <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
pn firmware-iwlwifi <none>
pn firmware-libertas <none>
pn firmware-linux-nonfree <none>
pn firmware-misc-nonfree <none>
pn firmware-myricom <none>
pn firmware-netxen <none>
pn firmware-qlogic <none>
ii firmware-realtek 20161130-3
pn firmware-samsung <none>
pn firmware-siano <none>
pn firmware-ti-connectivity <none>
pn xen-hypervisor <none>
-- no debconf information
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.debian.kernel
csiph-web