From: Kyle Auble <kyle.auble@zoho.com>
To: linux-pci@vger.kernel.org
Subject: Kernel Changing PCI Config at Startup, Deactivating GPU
Date: Fri, 05 Sep 2014 01:31:47 -0700 [thread overview]
Message-ID: <540974F3.4000507@zoho.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]
Hello, I emailed a while back for some pointers on debugging a PCI
problem and wanted to ask again for feedback.
I was tracking an issue at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1009312,
where my Nvidia 8400M GT [10de:0426], on a Sony VGN-FZ260E, fails to
initialize when the kernel loads, before the video driver even becomes
an issue. I thought it might be a timeout issue, but now I'm thinking
that something is accidentally shutting down the GPU even earlier than
link retraining. I can confirm the problem's still there in v3.17-rc2 of
the x86 kernel.
Recently, through some more googling and debugging, I've figured out
that passing the "pci=bios" kernel parameter gets the GPU to activate.
So I can easily treat the problem for myself now, but I'd like to help
wrap up anything related to an underlying cause. Also, with the
"pci=earlydump" parameter and an init-script (at priority S98) for
running lspci, I've found that something is altering parts of the PCI
config space when the GPU fails. I've included trimmed copies of the
PCIe config space from those two tests (0000:00:01.0 is the bridge in
front of the GPU).
While a lot of the changes seem to just reflect the GPU being off in the
status registers, several other registers get wiped to zero:
1. The SERR driver is disabled in the command register
2. Both cache line size and the subsystem pci id are zeroed out
3. The interrupt line (but not the interrupt pin) goes from 05 to 00
4. The actual memory addresses in the BARs are cleared, but not the
flags like prefetchable or 64-bit.
What's more suspicious to me is the data between the standard config
space and the first extended capability structure (at 0x60). The
subsystem id is repeated at 0x40, plus a flag of some sort at 0x50, both
of which are wiped to zero when the GPU fails to load. There's also a
single digit at 0x54 and some data at 0x58-0x60 that remain in any case.
I've tried studying the ACPI tables some too, but I'm not experienced
with ASL so it doesn't mean much that nothing stood out to me. I
narrowed things down to the DSDT because that seems to be where all the
action is. Outside of some OSI conditionals and events, the other
possibility that popped into my head is that somehow an ACPI mutex and a
kernel lock are colliding. If anyone is interested, I can send a copy of
the DSDT or any other disassembled tables to the list.
Beyond general ideas and advice about the DSDT, I'm wondering if (or
where) the kernel code is wiping these PCI config values, or if the
zeros are all just from the GPU going into hibernation. I've tried a lot
of grepping for variations of pci_write_config calls but haven't found
anything yet. Also, if this is ultimately an issue with the GPU, how
much could I even help with that? I've practiced dumping a video BIOS
but have no clue how to analyze it.
Thanks in advance,
Kyle Auble
[-- Attachment #2: earlydump --]
[-- Type: text/plain, Size: 1416 bytes --]
pci 0000:00:01.0 config space:
00: 86 80 01 2a 07 01 10 00 0c 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 20 20 00 00
20: 00 cc f0 ce 01 d0 f1 df 00 00 00 00 00 00 00 00
30: 00 00 00 00 88 00 00 00 00 00 00 00 05 01 1a 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 90 03 c8 00 00 00 00 0d 80 00 00 4d 10 05 90
90: 05 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 10 00 41 01 00 80 00 00 00 00 00 00 01 2d 01 02
b0: 43 00 01 11 c0 25 0c 00 c0 01 48 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
pci 0000:01:00.0 config space:
00: de 10 26 04 07 01 10 00 a1 00 00 03 10 00 00 00
10: 00 00 00 ce 0c 00 00 d0 00 00 00 00 04 00 00 cc
20: 00 00 00 00 01 20 00 00 00 00 00 00 4d 10 05 90
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 00 00
40: 4d 10 05 90 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 00 00 00 01 00 00 00 ce d6 23 00 00 00 00 00
60: 01 68 02 00 00 00 00 00 05 78 80 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 10 00 01 00 e0 84 2c 01
80: 10 28 00 00 01 3d 01 00 4b 00 01 11 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[-- Attachment #3: init-lspci --]
[-- Type: text/plain, Size: 1728 bytes --]
pci 0000:00:01.0 config space:
00: 86 80 01 2a 07 05 10 00 0c 00 04 06 10 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 20 20 00 20
20: 00 cc f0 ce 01 d0 f1 df 00 00 00 00 00 00 00 00
30: 00 00 00 00 88 00 00 00 00 00 00 00 05 01 1a 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 90 03 c8 00 00 00 00 0d 80 00 00 4d 10 05 90
90: 05 a0 01 00 0c 30 e0 fe 69 41 00 00 00 00 00 00
a0: 10 00 41 01 00 80 00 00 00 00 00 00 01 2d 01 02
b0: 43 00 01 11 c0 25 0c 00 c0 01 48 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 01 84 0c 00 00 a0 90 0f 04 00 31 00 00 00
pci 0000:01:00.0 config space:
00: de 10 26 04 03 00 10 00 a1 00 00 03 00 00 00 00
10: 00 00 00 00 0c 00 00 00 00 00 00 00 04 00 00 00
20: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 00 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 01 00 00 00 ce d6 23 00 00 00 00 00
60: 01 68 02 00 00 00 00 00 05 78 80 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 10 00 01 00 e0 84 2c 01
80: 10 28 0a 00 01 3d 01 00 08 00 01 11 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reply other threads:[~2014-09-05 9:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=540974F3.4000507@zoho.com \
--to=kyle.auble@zoho.com \
--cc=linux-pci@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).