From: Jiang Liu <jiang.liu@linux.intel.com>
To: Boszormenyi Zoltan <zboszor@pr.hu>, Bjorn Helgaas <bhelgaas@google.com>
Cc: Andreas Mohr <andi@lisas.de>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
Date: Mon, 22 Jun 2015 01:25:05 +0800 [thread overview]
Message-ID: <5586F371.2040100@linux.intel.com> (raw)
In-Reply-To: <5586C7E2.9070902@pr.hu>
On 2015/6/21 22:19, Boszormenyi Zoltan wrote:
> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
>> [+cc linux-pci]
>>
>> Hi Boszormenyi,
>>
>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>>> 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?
>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>> v3.18.16 dmesg log, so we can compare them?
>
> I collected all 3 for you to compare them, compressed, attached.
>
> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>
>>
>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>> the code to see what might be going on:
>>
>> acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>> ignored
>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>> 0xf0000000-0xfed8ffff window]
>>
>> Bjorn
Hi Bjorn and Boszormenyi,
From the 3.18 kernel, we got a message:
[ 0.126248] acpi PNP0A08:00: host bridge window
[0x400000000-0xfffffffff] (ignored, not CPU addressable)
And from 4.1.-rc8, we got another message:
[ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
That smells like a 32bit overflow or 64bit cut-off issue.
Hi Boszormenyi, could you please help to provide acpidump from the
machine?
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
WARNING: multiple messages have this Message-ID (diff)
From: Jiang Liu <jiang.liu@linux.intel.com>
To: Boszormenyi Zoltan <zboszor@pr.hu>, Bjorn Helgaas <bhelgaas@google.com>
Cc: Andreas Mohr <andi@lisas.de>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci
Date: Mon, 22 Jun 2015 01:25:05 +0800 [thread overview]
Message-ID: <5586F371.2040100@linux.intel.com> (raw)
In-Reply-To: <5586C7E2.9070902@pr.hu>
On 2015/6/21 22:19, Boszormenyi Zoltan wrote:
> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta:
>> [+cc linux-pci]
>>
>> Hi Boszormenyi,
>>
>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan <zboszor@pr.hu> wrote:
>>> 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?
>> This worked in v3.18.16, but not in v4.0.5 or v4.1.0-rc8. You
>> attached a v4.1.0-rc8 dmesg log earlier. Would you mind collecting a
>> v3.18.16 dmesg log, so we can compare them?
>
> I collected all 3 for you to compare them, compressed, attached.
>
> BTW, I browsed git log and found 2ea3d266bab3b497238113b20136f7c3f69ad9c0
> as suspicious. I will try the 4.0/4.1 kernels with this one reverted.
>
>>
>> These (from the v4.1.0-rc8 dmesg) look wrong, but I'll have to look at
>> the code to see what might be going on:
>>
>> acpi PNP0A08:00: host bridge window expanded to [mem
>> 0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window]
>> ignored
>> pci 0000:00:1c.1: can't claim BAR 15 [mem 0xfdf00000-0xfdffffff
>> 64bit pref]: address conflict with PCI Bus 0000:00 [mem
>> 0xf0000000-0xfed8ffff window]
>>
>> Bjorn
Hi Bjorn and Boszormenyi,
From the 3.18 kernel, we got a message:
[ 0.126248] acpi PNP0A08:00: host bridge window
[0x400000000-0xfffffffff] (ignored, not CPU addressable)
And from 4.1.-rc8, we got another message:
[ 0.127051] acpi PNP0A08:00: host bridge window expanded to [mem
0x00000000-0xffffffff window]; [mem 0x00000000-0xffffffff window] ignored
That smells like a 32bit overflow or 64bit cut-off issue.
Hi Boszormenyi, could you please help to provide acpidump from the
machine?
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
next prev parent reply other threads:[~2015-06-21 17:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 13:24 Ethernet chip disappeared from lspci Boszormenyi Zoltan
2015-06-19 13:31 ` Boszormenyi Zoltan
2015-06-19 13:46 ` ACPI regression? Was " Boszormenyi Zoltan
2015-06-19 23:13 ` Rafael J. Wysocki
2015-06-19 23:13 ` Rafael J. Wysocki
2015-06-20 6:38 ` Boszormenyi Zoltan
2015-06-21 10:34 ` Boszormenyi Zoltan
2015-06-21 14:03 ` Bjorn Helgaas
2015-06-21 14:03 ` Bjorn Helgaas
2015-06-21 14:03 ` Bjorn Helgaas
2015-06-21 14:19 ` Boszormenyi Zoltan
2015-06-21 15:37 ` Boszormenyi Zoltan
2015-06-21 15:37 ` Boszormenyi Zoltan
2015-06-21 17:25 ` Jiang Liu [this message]
2015-06-21 17:25 ` Jiang Liu
2015-06-21 17:55 ` Jiang Liu
2015-06-21 17:55 ` Jiang Liu
2015-06-21 17:55 ` Jiang Liu
2015-06-21 18:55 ` Boszormenyi Zoltan
2015-06-21 19:59 ` Boszormenyi Zoltan
2015-06-21 19:59 ` Boszormenyi Zoltan
2015-06-23 4:12 ` [Patch v1] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel Jiang Liu
2015-06-23 4:12 ` Jiang Liu
2015-06-23 7:35 ` Ingo Molnar
2015-06-23 7:35 ` Ingo Molnar
2015-06-21 18:28 ` ACPI regression? Was Re: Ethernet chip disappeared from lspci Boszormenyi Zoltan
-- strict thread matches above, loose matches on Subject: below --
2015-06-20 7:45 Andreas Mohr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5586F371.2040100@linux.intel.com \
--to=jiang.liu@linux.intel.com \
--cc=andi@lisas.de \
--cc=bhelgaas@google.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=zboszor@pr.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.