linux-kernel - Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

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: <55869329.4040908@pr.hu>
Date:	Sun, 21 Jun 2015 12:34:17 +0200
From:	Boszormenyi Zoltan <zboszor@...hu>
To:	Andreas Mohr <andi@...as.de>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

Hi,

please, cc me, I am not subscribed to lkml.

> Hi,
>
> [lkml.org still broken --> no accurate mail header info possible...]
>
> Just to ask the obvious:
> I assume using /sys/bus/pci/rescan does not help once it's broken?
> (since the machine comes up empty at initial-boot scan, too)

I will try it, too, but I am not sure it would work.

Currently I can't test it because the last time I completely discharged
the battery. I also disconnected it to be able to get the realtek chip back
immediately for faster testing. Now, that I have reconnected the battery,
I need to wait for it to be charged somewhat to be able to reproduce
losing the network chip.

> Also, you could try diffing lspci -vvxxx -s.... output
> of working vs. "distorting" kernel version - perhaps some register setup
> has been changed (e.g. due to power management improvements or some such),
> which may encourage the card
> to get a problematic/corrupt state.

I attached a tarball that contains lspci -vvxxx for
- all devices / only the network chip
- before / after "modprobe r8169"
- for all 3 kernel versions tested.

I figured out that if I type the modprobe and lspci in the same command line,
I can get diagnostics out of the machine, after all.

It's not just the Realtek chip that has changed parameters.

(Vague idea) I noticed that some devices have changed like this:

-       Memory behind bridge: 80000000-801fffff
-       Prefetchable memory behind bridge: 0000000080200000-00000000803fffff
+       Memory behind bridge: ff000000-ff1fffff
+       Prefetchable memory behind bridge: 00000000ff200000-00000000ff3fffff

Can't this cause a problem? E.g. programming the bridge with an address range
that the bridge doesn't actually support?

>
> > Upon powering off the system,
> > the r8169 driver compained about "rtl_eriar_cond = 1 loop 100"
>
> Yup, that seems to be
> rtl_eri_read() in ethernet/realtek/r8169.c
> waiting on low condition of
>     RTL_R32(ERIAR) & ERIAR_FLAG;

I found that, too, and I think it is a symptom of instead of the cause.

Thanks for your efforts,
Zoltán Böszörményi

Download attachment "lspci.tgz" of type "application/x-compressed-tar" (22851 bytes)