lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:  <878whethh7.fsf@nemi.mork.no>
Date:	Thu, 20 Aug 2009 21:25:56 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	linux-kernel@...r.kernel.org
Cc:	netdev@...r.kernel.org
Subject:  Re: e1000e: why does pci_enable_pcie_error_reporting() fail on my hp2510p?

Frans Pop <elendil@...net.nl> writes:

> - if broken hardware is common, should the kernel complain at all,
>   or at least maybe show a slightly "friendlier" message?

FWIW, I see the same message on resume on slighly different hardware, so
it's at least more common than just a single configuration:

[80885.498749] e1000e 0000:00:19.0: PCI INT A disabled
[80885.498755] e1000e 0000:00:19.0: PME# enabled
[80885.498763] e1000e 0000:00:19.0: wake-up capability enabled by ACPI
[80887.614545] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[80887.614548] e1000e 0000:00:19.0: pci_enable_pcie_error_reporting failed 0xfffffffb
[80887.614554] e1000e 0000:00:19.0: setting latency timer to 64
[80887.614559] e1000e 0000:00:19.0: wake-up capability disabled by ACPI
[80887.614565] e1000e 0000:00:19.0: PME# disabled
[80887.614567] e1000e 0000:00:19.0: wake-up capability disabled by ACPI
[80887.614572] e1000e 0000:00:19.0: PME# disabled
[80887.614626] e1000e 0000:00:19.0: irq 26 for MSI/MSI-X

nemi:/etc/apt# lspci -vvnns 00:19.0
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
        Subsystem: Lenovo Device [17aa:20ee]
        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
        Interrupt: pin A routed to IRQ 26
        Region 0: Memory at f0600000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at f0625000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 1840 [size=32]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
                Address: 00000000fee0300c  Data: 41b2
        Capabilities: [e0] PCIe advanced features <?>
        Kernel driver in use: e1000e
        Kernel modules: e1000e


The system is a Lenovo Thinkpad X301. The chipset is ICH9M.

I guess the "non-fatal, continue" comment is a pretty strong indication
that dev_err() is overkill here?


	/* AER (Advanced Error Reporting) hooks */
	err = pci_enable_pcie_error_reporting(pdev);
	if (err) {
		dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
		        "0x%x\n", err);
		/* non-fatal, continue */
	}




Bjørn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ