<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/pci/pcie, branch v2.6.32.45</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>PCI: fix nested spinlock hang in aer_inject</title>
<updated>2010-04-26T14:41:31+00:00</updated>
<author>
<name>Andrew Patterson</name>
<email>andrew.patterson@hp.com</email>
</author>
<published>2010-01-22T21:06:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=90022a26dd2e166ae1ac3953d266ea42f083d65e'/>
<id>90022a26dd2e166ae1ac3953d266ea42f083d65e</id>
<content type='text'>
commit bd1f46deba615971a58193afd0202878cadf19a7 upstream.

The aer_inject module hangs in aer_inject() when checking the device's
error masks.  The hang is due to a recursive use of the aer_inject lock.
The aer_inject() routine grabs the lock while processing the error and then
calls pci_read_config_dword to read the masks. The pci_read_config_dword
routine is earlier overridden by pci_read_aer, which among other things,
grabs the aer_inject lock.

Fixed by moving the pci_read_config_dword calls to read the masks to before
the lock is taken.

Acked-by: Huang Ying &lt;ying.huang@intel.com&gt;
Signed-off-by: Andrew Patterson &lt;andrew.patterson@hp.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Cc: maximilian attems &lt;max@stro.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bd1f46deba615971a58193afd0202878cadf19a7 upstream.

The aer_inject module hangs in aer_inject() when checking the device's
error masks.  The hang is due to a recursive use of the aer_inject lock.
The aer_inject() routine grabs the lock while processing the error and then
calls pci_read_config_dword to read the masks. The pci_read_config_dword
routine is earlier overridden by pci_read_aer, which among other things,
grabs the aer_inject lock.

Fixed by moving the pci_read_config_dword calls to read the masks to before
the lock is taken.

Acked-by: Huang Ying &lt;ying.huang@intel.com&gt;
Signed-off-by: Andrew Patterson &lt;andrew.patterson@hp.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Cc: maximilian attems &lt;max@stro.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCIe AER: prevent AER injection if hardware masks error reporting</title>
<updated>2010-04-26T14:41:30+00:00</updated>
<author>
<name>Youquan Song</name>
<email>youquan.song@linux.intel.com</email>
</author>
<published>2009-12-17T13:22:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9623f6b42a74645cbf05432a57d19363bc072bb2'/>
<id>9623f6b42a74645cbf05432a57d19363bc072bb2</id>
<content type='text'>
commit b49bfd32901625e4adcfee011d2b32a43b4db67d upstream.

The Correcteable/Uncorrectable Error Mask Registers are used by PCIe AER
driver which will controls the reporting of individual errors to PCIe RC
via PCIe error messages.

If hardware masks special error reporting to RC, the aer_inject driver
should not inject aer error.

Acked-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Youquan Song &lt;youquan.song@intel.com&gt;
Acked-by: Ying Huang &lt;ying.huang@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Cc: maximilian attems &lt;max@stro.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b49bfd32901625e4adcfee011d2b32a43b4db67d upstream.

The Correcteable/Uncorrectable Error Mask Registers are used by PCIe AER
driver which will controls the reporting of individual errors to PCIe RC
via PCIe error messages.

If hardware masks special error reporting to RC, the aer_inject driver
should not inject aer error.

Acked-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Youquan Song &lt;youquan.song@intel.com&gt;
Acked-by: Ying Huang &lt;ying.huang@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Cc: maximilian attems &lt;max@stro.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: unconditionally clear AER uncorr status register during cleanup</title>
<updated>2010-04-01T22:58:12+00:00</updated>
<author>
<name>Andrew Patterson</name>
<email>andrew.patterson@hp.com</email>
</author>
<published>2009-12-03T17:28:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1ebf19e8a1402842dcd2f34a4032922170de4218'/>
<id>1ebf19e8a1402842dcd2f34a4032922170de4218</id>
<content type='text'>
commit 6cdfd995a65a52e05b99e3a72a9b979abe73b312 upstream.

The current implementation of pci_cleanup_aer_uncorrect_error_status
only clears either fatal or non-fatal error status bits depending
on the state of the I/O channel. This implementation will then often
leave some bits set after PCI error recovery completes.  The uncleared bit
settings will then be falsely reported the next time an AER interrupt is
generated for that hierarchy. An easy way to illustrate this issue is to
use the aer-inject module to simultaneously inject both an uncorrectable
non-fatal and uncorrectable fatal error.  One of the errors will not be
cleared.

This patch resolves this issue by unconditionally clearing all bits in
the AER uncorrectable status register. All settings and corrective action
strategies are saved and determined before
pci_cleanup_aer_uncorrect_error_status is called, so this change should not
affect errory handling functionality.

Signed-off-by: Andrew Patterson &lt;andrew.patterson@hp.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Cc: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6cdfd995a65a52e05b99e3a72a9b979abe73b312 upstream.

The current implementation of pci_cleanup_aer_uncorrect_error_status
only clears either fatal or non-fatal error status bits depending
on the state of the I/O channel. This implementation will then often
leave some bits set after PCI error recovery completes.  The uncleared bit
settings will then be falsely reported the next time an AER interrupt is
generated for that hierarchy. An easy way to illustrate this issue is to
use the aer-inject module to simultaneously inject both an uncorrectable
non-fatal and uncorrectable fatal error.  One of the errors will not be
cleared.

This patch resolves this issue by unconditionally clearing all bits in
the AER uncorrectable status register. All settings and corrective action
strategies are saved and determined before
pci_cleanup_aer_uncorrect_error_status is called, so this change should not
affect errory handling functionality.

Signed-off-by: Andrew Patterson &lt;andrew.patterson@hp.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Cc: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: AER: fix aer inject result in kernel oops</title>
<updated>2010-01-28T23:01:51+00:00</updated>
<author>
<name>Song Youquan</name>
<email>youquan.song@linux.intel.com</email>
</author>
<published>2009-12-11T23:42:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5172b4b0f1d06dd5cb27f335223131a2f08accb4'/>
<id>5172b4b0f1d06dd5cb27f335223131a2f08accb4</id>
<content type='text'>
commit 46256f83d0d066f99ffde547f27473dfd2a78009 upstream.

If the BIOS does not export _OSC to allow OS take over the PCIe AER, the
pcie aer driver will not initialize the aer service. However, the
aer_inject driver does not check this scenario, which results in a kernel
oops when injecting an aer error into OS.  For example:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000350
IP: [&lt;ffffffff812e08f7&gt;] _spin_lock_irqsave+0xc/0x23
PGD 155c41067 PUD 157fe0067 PMD 0
Oops: 0002 [#1] SMP
Pid: 5119, comm: aer-inject Not tainted 2.6.32-rc8-mce #2
RIP: 0010:[&lt;ffffffff812e08f7&gt;]  [&lt;ffffffff812e08f7&gt;] _spin_lock_irqsave+0xc/0x23
RSP: 0018:ffff880157f81e28  EFLAGS: 00010096
RAX: 0000000000000296 RBX: 0000000000000000 RCX: 0000000000000100
RDX: 0000000000010000 RSI: 0000000000000246 RDI: 0000000000000350
RBP: ffff880157f81e28 R08: 0000000000000004 R09: ffff880157f81dac
R10: ffff88015a666f60 R11: ffff88015a666f40 R12: ffff88015758cc00
R13: 0000000000000350 R14: 0000000000000000 R15: 0000000000000100
FS:  00007f4d4a66e6f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000350 CR3: 000000015661a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process aer-inject (pid: 5119, threadinfo ffff880157f80000, task ffff8801585f4340)
Stack:
 ffff880157f81e78 ffffffff811b1615 ffff880157f81e78 ffffffff81222823
Call Trace:
 [&lt;ffffffff811b1615&gt;] aer_irq+0x38/0x117
 [&lt;ffffffff81222823&gt;] ? device_for_each_child+0x5f/0x6f
 [&lt;ffffffffa00967bf&gt;] aer_inject_write+0x409/0x45e [aer_inject]
 [&lt;ffffffff810eb80e&gt;] vfs_write+0xae/0x16a
 [&lt;ffffffff810eb98e&gt;] sys_write+0x47/0x6e
 [&lt;ffffffff8100ba2b&gt;] system_call_fastpath+0x16/0x1b
RIP  [&lt;ffffffff812e08f7&gt;] _spin_lock_irqsave+0xc/0x23
 RSP &lt;ffff880157f81e28&gt;
CR2: 0000000000000350

So check the _OSC before assuming that AER is available to the OS.

Signed-off-by: Song Youquan &lt;youquan.song@intel.com&gt;
Acked-by: Huang Ying &lt;ying.huang@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 46256f83d0d066f99ffde547f27473dfd2a78009 upstream.

If the BIOS does not export _OSC to allow OS take over the PCIe AER, the
pcie aer driver will not initialize the aer service. However, the
aer_inject driver does not check this scenario, which results in a kernel
oops when injecting an aer error into OS.  For example:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000350
IP: [&lt;ffffffff812e08f7&gt;] _spin_lock_irqsave+0xc/0x23
PGD 155c41067 PUD 157fe0067 PMD 0
Oops: 0002 [#1] SMP
Pid: 5119, comm: aer-inject Not tainted 2.6.32-rc8-mce #2
RIP: 0010:[&lt;ffffffff812e08f7&gt;]  [&lt;ffffffff812e08f7&gt;] _spin_lock_irqsave+0xc/0x23
RSP: 0018:ffff880157f81e28  EFLAGS: 00010096
RAX: 0000000000000296 RBX: 0000000000000000 RCX: 0000000000000100
RDX: 0000000000010000 RSI: 0000000000000246 RDI: 0000000000000350
RBP: ffff880157f81e28 R08: 0000000000000004 R09: ffff880157f81dac
R10: ffff88015a666f60 R11: ffff88015a666f40 R12: ffff88015758cc00
R13: 0000000000000350 R14: 0000000000000000 R15: 0000000000000100
FS:  00007f4d4a66e6f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000350 CR3: 000000015661a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process aer-inject (pid: 5119, threadinfo ffff880157f80000, task ffff8801585f4340)
Stack:
 ffff880157f81e78 ffffffff811b1615 ffff880157f81e78 ffffffff81222823
Call Trace:
 [&lt;ffffffff811b1615&gt;] aer_irq+0x38/0x117
 [&lt;ffffffff81222823&gt;] ? device_for_each_child+0x5f/0x6f
 [&lt;ffffffffa00967bf&gt;] aer_inject_write+0x409/0x45e [aer_inject]
 [&lt;ffffffff810eb80e&gt;] vfs_write+0xae/0x16a
 [&lt;ffffffff810eb98e&gt;] sys_write+0x47/0x6e
 [&lt;ffffffff8100ba2b&gt;] system_call_fastpath+0x16/0x1b
RIP  [&lt;ffffffff812e08f7&gt;] _spin_lock_irqsave+0xc/0x23
 RSP &lt;ffff880157f81e28&gt;
CR2: 0000000000000350

So check the _OSC before assuming that AER is available to the OS.

Signed-off-by: Song Youquan &lt;youquan.song@intel.com&gt;
Acked-by: Huang Ying &lt;ying.huang@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
Signed-off-by: Thomas Renninger &lt;trenn@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI ASPM: fix oops on root port removal</title>
<updated>2009-11-06T22:01:23+00:00</updated>
<author>
<name>Kenji Kaneshige</name>
<email>kaneshige.kenji@jp.fujitsu.com</email>
</author>
<published>2009-11-06T07:22:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=761434a318a64bf521f8abcc920e1d9837640fa2'/>
<id>761434a318a64bf521f8abcc920e1d9837640fa2</id>
<content type='text'>
Fix the following BUG_ON() problem reported by Alex Chiang.

This problem happened when removing PCIe root port using PCI logical
hotplug operation.

The immediate cause of this problem is that the pointer to invalid
data structure is passed to pcie_update_aspm_capable() by
pcie_aspm_exit_link_state(). When pcie_aspm_exit_link_state() received
a pointer to root port link, it unconfigures the root port link and
frees its data structure at first. At this point, there are not links
to configure under the root port and the data structure for root port
link is already freed. So pcie_aspm_exit_link_state() must not call
pcie_update_aspm_capable() and pcie_config_aspm_path().

This patch fixes the problem by changing pcie_aspm_exit_link_state()
not to call pcie_update_aspm_capable() and pcie_config_aspm_path() if
the specified link is root port link.

------------[ cut here ]------------
kernel BUG at drivers/pci/pcie/aspm.c:606!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/pci0000:40/0000:40:13.0/remove
CPU 1
Modules linked in: shpchp
Pid: 9345, comm: sysfsd Not tainted 2.6.32-rc5 #98 ProLiant DL785 G6
RIP: 0010:[&lt;ffffffff811df69b&gt;]  [&lt;ffffffff811df69b&gt;] pcie_update_aspm_capable+0x15/0xbe
RSP: 0018:ffff88082a2f5ca0  EFLAGS: 00010202
RAX: 0000000000000e77 RBX: ffff88182cc3e000 RCX: ffff88082a33d006
RDX: 0000000000000001 RSI: ffffffff811dff4a RDI: ffff88182cc3e000
RBP: ffff88082a2f5cc0 R08: ffff88182cc3e000 R09: 0000000000000000
R10: ffff88182fc00180 R11: ffff88182fc00198 R12: ffff88182cc3e000
R13: 0000000000000000 R14: ffff88182cc3e000 R15: ffff88082a2f5e20
FS:  00007f259a64b6f0(0000) GS:ffff880864600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00007feb53f73da0 CR3: 000000102cc94000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process sysfsd (pid: 9345, threadinfo ffff88082a2f4000, task ffff88082a33cf00)
Stack:
 ffff88182cc3e000 ffff88182cc3e000 0000000000000000 ffff88082a33cf00
&lt;0&gt; ffff88082a2f5cf0 ffffffff811dff52 ffff88082a2f5cf0 ffff88082c525168
&lt;0&gt; ffff88402c9fd2f8 ffff88402c9fd2f8 ffff88082a2f5d20 ffffffff811d7db2
Call Trace:
 [&lt;ffffffff811dff52&gt;] pcie_aspm_exit_link_state+0xf5/0x11e
 [&lt;ffffffff811d7db2&gt;] pci_stop_bus_device+0x76/0x7e
 [&lt;ffffffff811d7d67&gt;] pci_stop_bus_device+0x2b/0x7e
 [&lt;ffffffff811d7e4f&gt;] pci_remove_bus_device+0x15/0xb9
 [&lt;ffffffff811dcb8c&gt;] remove_callback+0x29/0x3a
 [&lt;ffffffff81135aeb&gt;] sysfs_schedule_callback_work+0x15/0x6d
 [&lt;ffffffff81072790&gt;] worker_thread+0x19d/0x298
 [&lt;ffffffff8107273b&gt;] ? worker_thread+0x148/0x298
 [&lt;ffffffff81135ad6&gt;] ? sysfs_schedule_callback_work+0x0/0x6d
 [&lt;ffffffff810765c0&gt;] ? autoremove_wake_function+0x0/0x38
 [&lt;ffffffff810725f3&gt;] ? worker_thread+0x0/0x298
 [&lt;ffffffff8107629e&gt;] kthread+0x7d/0x85
 [&lt;ffffffff8102eafa&gt;] child_rip+0xa/0x20
 [&lt;ffffffff8102e4bc&gt;] ? restore_args+0x0/0x30
 [&lt;ffffffff81076221&gt;] ? kthread+0x0/0x85
 [&lt;ffffffff8102eaf0&gt;] ? child_rip+0x0/0x20
Code: 89 e5 8a 50 48 31 c0 c0 ea 03 83 e2 07 e8 b2 de fe ff c9 48 98 c3 55 48 89 e5 41 56 49 89 fe 41 55 41 54 53 48 83 7f 10 00 74 04 &lt;0f&gt; 0b eb fe 48 8b 05 da 7d 63 00 4c 8d 60 e8 4c 89 e1 eb 24 4c
RIP  [&lt;ffffffff811df69b&gt;] pcie_update_aspm_capable+0x15/0xbe
 RSP &lt;ffff88082a2f5ca0&gt;
---[ end trace 6ae0f65bdeab8555 ]---

Reported-by: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt;
Tested-by: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the following BUG_ON() problem reported by Alex Chiang.

This problem happened when removing PCIe root port using PCI logical
hotplug operation.

The immediate cause of this problem is that the pointer to invalid
data structure is passed to pcie_update_aspm_capable() by
pcie_aspm_exit_link_state(). When pcie_aspm_exit_link_state() received
a pointer to root port link, it unconfigures the root port link and
frees its data structure at first. At this point, there are not links
to configure under the root port and the data structure for root port
link is already freed. So pcie_aspm_exit_link_state() must not call
pcie_update_aspm_capable() and pcie_config_aspm_path().

This patch fixes the problem by changing pcie_aspm_exit_link_state()
not to call pcie_update_aspm_capable() and pcie_config_aspm_path() if
the specified link is root port link.

------------[ cut here ]------------
kernel BUG at drivers/pci/pcie/aspm.c:606!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/pci0000:40/0000:40:13.0/remove
CPU 1
Modules linked in: shpchp
Pid: 9345, comm: sysfsd Not tainted 2.6.32-rc5 #98 ProLiant DL785 G6
RIP: 0010:[&lt;ffffffff811df69b&gt;]  [&lt;ffffffff811df69b&gt;] pcie_update_aspm_capable+0x15/0xbe
RSP: 0018:ffff88082a2f5ca0  EFLAGS: 00010202
RAX: 0000000000000e77 RBX: ffff88182cc3e000 RCX: ffff88082a33d006
RDX: 0000000000000001 RSI: ffffffff811dff4a RDI: ffff88182cc3e000
RBP: ffff88082a2f5cc0 R08: ffff88182cc3e000 R09: 0000000000000000
R10: ffff88182fc00180 R11: ffff88182fc00198 R12: ffff88182cc3e000
R13: 0000000000000000 R14: ffff88182cc3e000 R15: ffff88082a2f5e20
FS:  00007f259a64b6f0(0000) GS:ffff880864600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00007feb53f73da0 CR3: 000000102cc94000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process sysfsd (pid: 9345, threadinfo ffff88082a2f4000, task ffff88082a33cf00)
Stack:
 ffff88182cc3e000 ffff88182cc3e000 0000000000000000 ffff88082a33cf00
&lt;0&gt; ffff88082a2f5cf0 ffffffff811dff52 ffff88082a2f5cf0 ffff88082c525168
&lt;0&gt; ffff88402c9fd2f8 ffff88402c9fd2f8 ffff88082a2f5d20 ffffffff811d7db2
Call Trace:
 [&lt;ffffffff811dff52&gt;] pcie_aspm_exit_link_state+0xf5/0x11e
 [&lt;ffffffff811d7db2&gt;] pci_stop_bus_device+0x76/0x7e
 [&lt;ffffffff811d7d67&gt;] pci_stop_bus_device+0x2b/0x7e
 [&lt;ffffffff811d7e4f&gt;] pci_remove_bus_device+0x15/0xb9
 [&lt;ffffffff811dcb8c&gt;] remove_callback+0x29/0x3a
 [&lt;ffffffff81135aeb&gt;] sysfs_schedule_callback_work+0x15/0x6d
 [&lt;ffffffff81072790&gt;] worker_thread+0x19d/0x298
 [&lt;ffffffff8107273b&gt;] ? worker_thread+0x148/0x298
 [&lt;ffffffff81135ad6&gt;] ? sysfs_schedule_callback_work+0x0/0x6d
 [&lt;ffffffff810765c0&gt;] ? autoremove_wake_function+0x0/0x38
 [&lt;ffffffff810725f3&gt;] ? worker_thread+0x0/0x298
 [&lt;ffffffff8107629e&gt;] kthread+0x7d/0x85
 [&lt;ffffffff8102eafa&gt;] child_rip+0xa/0x20
 [&lt;ffffffff8102e4bc&gt;] ? restore_args+0x0/0x30
 [&lt;ffffffff81076221&gt;] ? kthread+0x0/0x85
 [&lt;ffffffff8102eaf0&gt;] ? child_rip+0x0/0x20
Code: 89 e5 8a 50 48 31 c0 c0 ea 03 83 e2 07 e8 b2 de fe ff c9 48 98 c3 55 48 89 e5 41 56 49 89 fe 41 55 41 54 53 48 83 7f 10 00 74 04 &lt;0f&gt; 0b eb fe 48 8b 05 da 7d 63 00 4c 8d 60 e8 4c 89 e1 eb 24 4c
RIP  [&lt;ffffffff811df69b&gt;] pcie_update_aspm_capable+0x15/0xbe
 RSP &lt;ffff88082a2f5ca0&gt;
---[ end trace 6ae0f65bdeab8555 ]---

Reported-by: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt;
Tested-by: Alex Chiang &lt;achiang@hp.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6</title>
<updated>2009-10-12T21:38:34+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2009-10-12T21:38:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2caa731819a633bec5a56736e64c562b7e193666'/>
<id>2caa731819a633bec5a56736e64c562b7e193666</id>
<content type='text'>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  PCI: Prevent AER driver from being loaded on non-root port PCIE devices
  PCI: get larger bridge ranges when space is available
  PCI: pci.c: fix kernel-doc notation
  PCI quirk: TI XIO200a erroneously reports support for fast b2b transfers
  PCI PM: Read device power state from register after updating it
  PCI: remove pci_assign_resource_fixed()
  PCI: PCIe portdrv: remove "-driver" from driver name
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  PCI: Prevent AER driver from being loaded on non-root port PCIE devices
  PCI: get larger bridge ranges when space is available
  PCI: pci.c: fix kernel-doc notation
  PCI quirk: TI XIO200a erroneously reports support for fast b2b transfers
  PCI PM: Read device power state from register after updating it
  PCI: remove pci_assign_resource_fixed()
  PCI: PCIe portdrv: remove "-driver" from driver name
</pre>
</div>
</content>
</entry>
<entry>
<title>headers: remove sched.h from interrupt.h</title>
<updated>2009-10-11T18:20:58+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2009-10-07T13:09:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d43c36dc6b357fa1806800f18aa30123c747a6d1'/>
<id>d43c36dc6b357fa1806800f18aa30123c747a6d1</id>
<content type='text'>
After m68k's task_thread_info() doesn't refer to current,
it's possible to remove sched.h from interrupt.h and not break m68k!
Many thanks to Heiko Carstens for allowing this.

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After m68k's task_thread_info() doesn't refer to current,
it's possible to remove sched.h from interrupt.h and not break m68k!
Many thanks to Heiko Carstens for allowing this.

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Prevent AER driver from being loaded on non-root port PCIE devices</title>
<updated>2009-10-07T16:28:56+00:00</updated>
<author>
<name>Kenji Kaneshige</name>
<email>kaneshige.kenji@jp.fujitsu.com</email>
</author>
<published>2009-10-07T16:28:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=30fc24b5cbc55f9e6c686e2710cc812419bddc0c'/>
<id>30fc24b5cbc55f9e6c686e2710cc812419bddc0c</id>
<content type='text'>
A bug was seen on boards using a PLX 8518 switch device which advertises
AER on each of it's transparent bridges. The AER driver was loaded for
each bridge and this driver tried to access the AER source ID register
whenever an interrupt occured on the shared PCI INTX lines. The source
ID register does not exist on non root port PCIE device's  which
advertise AER and trying to access this register causes a unsupported
request error on the bridge. Thus, when the next interrupt occurs,
another error is found and the non existent source ID register is
accessed again, and so it goes on.

The result is a spammed dmesg with unsupported request PCI express
errors on the bridge device that the AER driver is loaded against.

Reported-by: Malcolm Crossley &lt;malcolm.crossley2@gefanuc.com&gt;
Signed-off-by: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt;
Tested-by: Malcolm Crossley &lt;malcolm.crossley2@gefanuc.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A bug was seen on boards using a PLX 8518 switch device which advertises
AER on each of it's transparent bridges. The AER driver was loaded for
each bridge and this driver tried to access the AER source ID register
whenever an interrupt occured on the shared PCI INTX lines. The source
ID register does not exist on non root port PCIE device's  which
advertise AER and trying to access this register causes a unsupported
request error on the bridge. Thus, when the next interrupt occurs,
another error is found and the non existent source ID register is
accessed again, and so it goes on.

The result is a spammed dmesg with unsupported request PCI express
errors on the bridge device that the AER driver is loaded against.

Reported-by: Malcolm Crossley &lt;malcolm.crossley2@gefanuc.com&gt;
Signed-off-by: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt;
Tested-by: Malcolm Crossley &lt;malcolm.crossley2@gefanuc.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: PCIe portdrv: remove "-driver" from driver name</title>
<updated>2009-10-06T16:41:48+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bjorn.helgaas@hp.com</email>
</author>
<published>2009-10-05T22:47:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e3fb20f9c8783d6e27cf84389a9606e410733eef'/>
<id>e3fb20f9c8783d6e27cf84389a9606e410733eef</id>
<content type='text'>
No need to include "-driver" in the driver name.

Signed-off-by: Bjorn Helgaas &lt;bjorn.helgaas@hp.com&gt;
CC: Tom Long Nguyen &lt;tom.l.nguyen@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
No need to include "-driver" in the driver name.

Signed-off-by: Bjorn Helgaas &lt;bjorn.helgaas@hp.com&gt;
CC: Tom Long Nguyen &lt;tom.l.nguyen@intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Disable AER with pci=nomsi</title>
<updated>2009-09-17T17:05:27+00:00</updated>
<author>
<name>Andi Kleen</name>
<email>andi@firstfloor.org</email>
</author>
<published>2009-09-16T20:40:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3e77a3f7895e9c20756dc250282afa12f6d259a3'/>
<id>3e77a3f7895e9c20756dc250282afa12f6d259a3</id>
<content type='text'>
When booting with pci=nomsi aer causes lost interrupts and
lockdep inversions.

So check if MSIs are not disabled before initializing the aer
driver.

Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When booting with pci=nomsi aer causes lost interrupts and
lockdep inversions.

So check if MSIs are not disabled before initializing the aer
driver.

Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Jesse Barnes &lt;jbarnes@virtuousgeek.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
