Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 6月, 2008 8 次提交
  3. 31 5月, 2008 1 次提交
  5. 28 5月, 2008 7 次提交
    • K
      pciehp: add message about pciehp_slot_with_bus option · 9e4f2e8d
      由 Kenji Kaneshige 提交于 
      Some (broken?) platform assign the same slot name to multiple hotplug
slots. On such system, slot initialization would fail because of name
collision. The pciehp driver already have a "slot_with_bus" module
option which adds the bus number into the slot name. This patch adds
the message about this module option that will be displayed when slot
name collision is detected.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9e4f2e8d
    • K
      pci hotplug core: add check of duplicate slot name · a86161b3
      由 Kenji Kaneshige 提交于 
      Fix the following errors reported by Jan C. Nordholz in
http://bugzilla.kernel.org/show_bug.cgi?id=10751.

kobject_add_internal failed for 2 with -EEXIST, don't try to register things with the same name in the same directory.
Pid: 1, comm: swapper Tainted: G        W 2.6.26-rc3 #1
 [<c0266980>] kobject_add_internal+0x140/0x190
 [<c0266afd>] kobject_init_and_add+0x2d/0x40
 [<c027bc91>] pci_hp_register+0x81/0x2f0
 [<c027fd07>] pciehp_probe+0x1a7/0x470
 [<c01b3b84>] sysfs_add_one+0x44/0xa0
 [<c01b3c1f>] sysfs_addrm_start+0x3f/0xb0
 [<c01b497a>] sysfs_create_link+0x8a/0xf0
 [<c0279570>] pcie_port_probe_service+0x50/0x80
 [<c02e0545>] driver_sysfs_add+0x55/0x70
 [<c02e0662>] driver_probe_device+0x82/0x180
 [<c02e07cc>] __driver_attach+0x6c/0x70
 [<c02dfe0a>] bus_for_each_dev+0x3a/0x60
 [<c05db2d0>] pcied_init+0x0/0x80
 [<c02e04e6>] driver_attach+0x16/0x20
 [<c02e0760>] __driver_attach+0x0/0x70
 [<c02e0341>] bus_add_driver+0x1a1/0x220
 [<c05db2d0>] pcied_init+0x0/0x80
 [<c02e09cd>] driver_register+0x4d/0x120
 [<c05db050>] ibm_acpiphp_init+0x0/0x190
 [<c0125aab>] printk+0x1b/0x20
 [<c05db2d0>] pcied_init+0x0/0x80
 [<c05db2de>] pcied_init+0xe/0x80
 [<c05c751a>] kernel_init+0x10a/0x300
 [<c0120138>] schedule_tail+0x18/0x50
 [<c0103b9a>] ret_from_fork+0x6/0x1c
 [<c05c7410>] kernel_init+0x0/0x300
 [<c05c7410>] kernel_init+0x0/0x300
 [<c010485b>] kernel_thread_helper+0x7/0x1c
 =======================
pci_hotplug: Unable to register kobject '2'<3>pciehp: pci_hp_register failed with error -22

Slot with the same name can be registered multiple times if shpchp or
pciehp driver is loaded after acpiphp is loaded because ACPI based
hotplug driver and Native OS hotplug driver trying to handle the same
physical slot. In this case, current pci_hotplug core will call
kobject_init_and_add() muliple time with the same name. This is the
cause of this problem. To fix this problem, this patch adds the check
into pci_hp_register() to see if the slot with the same name.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a86161b3
    • K
      pciehp: move msleep after power off · 0711c70e
      由 Kenji Kaneshige 提交于 
      According to the PCI Express specification, we must wait for at least
1 second after turning power off before taking any action that relies
on power having been removed from the slot/adapter. For this, current
pciehp wait for 1 second after issuing the power off command in
hpc_power_off_slot() function. But waiting for 1 second in
hpc_power_off_slot() can make pciehp probing slow-down because pciehp
probe code calls hpc_power_off_slot() if the slot is not occupied just
in case. We don't need to wait for 1 second at the pciehp probe time
because there is no action on that empty slot. So move 1 second wait
from hpc_power_off_slot() to the caller of hpc_power_off_slot().
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0711c70e
    • K
      pciehp: poll cmd completion if hotplug interrupt is disabled · 6592e02a
      由 Kenji Kaneshige 提交于 
      Fix improper long wait for command completion in pciehp probing.

As described in PCI Express specification, software notification is
not generated if the command that occurs as a result of a write to the
Slot Control register that disables software notification of command
completed events. Since pciehp driver doesn't take it into account,
such command is issued in pciehp probing, and it causes improper long
wait for command completion.

This patch changes the pciehp driver to take such command into
account.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6592e02a
    • K
      pciehp: fix slow probing · 5808639b
      由 Kenji Kaneshige 提交于 
      Fix the "pciehp probing slow" problem reported from Jan C. Nordholz in
http://bugzilla.kernel.org/show_bug.cgi?id=10751.

The command completed bit in Slot Status register applies only to
commands issued to control the attention indicator, power indicator,
power controller, or electromechanical interlock. However, writes to
other parts of the Slot Control register would end up writing to the
control fields. Hence, any write to Slot Control register is
considered as a command. However, if the controller doesn't support
any of attention indicator, power indicator, power controller and
electromechanical interlock, command completed bit would not set in
writing to Slot Control register. In this case, we should not wait for
command completed bit set, otherwise all commands would be considered
not completed in timeout seconds (1 sec.).

The cause of the problem is pciehp driver didn't take this situation
into account. This patch changes pciehp to take it into account. This
patch also add the check for "No Command Completed Support" bit in
Slot Capability register. If it is set, we should not wait for command
completed bit set as well.

This problem seems to be revealed by the commit
c27fb883 that fixed the bug that
pciehp did not wait for command completed properly (pciehp just
ignored the command completion event).
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      5808639b
    • K
      pciehp: fix NULL dereference in interrupt handler · dbd79aed
      由 Kenji Kaneshige 提交于 
      Fix the following NULL dereference problem reported from Pierre Ossman
and Ingo Molnar.

pciehp: HPC vendor_id 8086 device_id 27d0 ss_vid 0 ss_did 0
pciehp: pciehp_find_slot: slot (device=0x0) not found
BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
IP: [<ffffffff80494a8b>] pciehp_handle_presence_change+0x7e/0x113
PGD 0
Oops: 0000 [1]
CPU 0
Modules linked in:
Pid: 1, comm: swapper Tainted: G        W 2.6.26-rc3-sched-devel.git-00001-g2b99b26-dirty #170
RIP: 0010:[<ffffffff80494a8b>]  [<ffffffff80494a8b>] pciehp_handle_presence_change+0x7e/0x113
RSP: 0000:ffff81003f83fbb0  EFLAGS: 00010046
RAX: 0000000000000039 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000046
RBP: ffff81003f83fbd0 R08: 0000000000000001 R09: ffffffff80245103
R10: 0000000000000020 R11: 0000000000000000 R12: ffff81003ea53a30
R13: 0000000000000000 R14: 0000000000000011 R15: ffffffff80495926
FS:  0000000000000000(0000) GS:ffffffff80be7400(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000070 CR3: 0000000000201000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff81003f83e000, task ffff81003f840000)
Stack:  0000000000000008 ffff81003f83fbf6 ffff81003ea53a30 0000000000000008
 ffff81003f83fc10 ffffffff80495ab4 0000000000000011 0000000000000002
 0000000000000202 0000000000000202 00000000fffffff4 ffff81003ea53a30
Call Trace:
 [<ffffffff80495ab4>] pcie_isr+0x18e/0x1bc
 [<ffffffff80260831>] request_irq+0x106/0x12f
 [<ffffffff80495fb6>] pcie_init+0x15e/0x6cc
 [<ffffffff804933a3>] pciehp_probe+0x64/0x541
 [<ffffffff8048f4e7>] pcie_port_probe_service+0x4c/0x76
 [<ffffffff8054af70>] driver_probe_device+0xd4/0x1f0
 [<ffffffff8054b108>] __driver_attach+0x7c/0x7e
 [<ffffffff8054b08c>] ? __driver_attach+0x0/0x7e
 [<ffffffff8054a4b6>] bus_for_each_dev+0x53/0x7d
 [<ffffffff8054ad3c>] driver_attach+0x1c/0x1e
 [<ffffffff8054a9c2>] bus_add_driver+0xdd/0x25b
 [<ffffffff80c09d3d>] ? pcied_init+0x0/0x8b
 [<ffffffff8054b288>] driver_register+0x5f/0x13e
 [<ffffffff80c09d3d>] ? pcied_init+0x0/0x8b
 [<ffffffff8048f441>] pcie_port_service_register+0x47/0x49
 [<ffffffff80c09d52>] pcied_init+0x15/0x8b
 [<ffffffff80bf3938>] kernel_init+0x75/0x243
 [<ffffffff808639d2>] ? _spin_unlock_irq+0x2b/0x3a
 [<ffffffff80228d1f>] ? finish_task_switch+0x57/0x9a
 [<ffffffff8020c258>] child_rip+0xa/0x12
 [<ffffffff8020bcec>] ? restore_args+0x0/0x30
 [<ffffffff80bf38c3>] ? kernel_init+0x0/0x243
 [<ffffffff8020c24e>] ? child_rip+0x0/0x12

Code: 83 80 00 00 00 48 39 f0 75 e1 0f b6 c9 48 c7 c2 00 0e 8d 80 48 c7 c6 8a 60 a6 80 48 c7 c7 10 db a8 80 31 c0 e8 3f 8d d9 ff 31 db <48> 8b 43 70 48 8d 75 ef 48 89 df ff 50 30 80 7d ef 00 74 37 48
RIP  [<ffffffff80494a8b>] pciehp_handle_presence_change+0x7e/0x113
 RSP <ffff81003f83fbb0>
CR2: 0000000000000070
Kernel panic - not syncing: Fatal exception

The situation under which it occurs is hw and timing related: it appears
to happen on a system that has PCI hotplug hardware but with no active
hotplug cards, and another interrupt in the same (shared) IRQ line
arrives too early, before the hotplug-slot entry has been set up - as
triggered by CONFIG_DEBUG_SHIRQ=y:

This patch contains the following two fixes.

(1) Clear all events bits in Slot Status register to prevent the pciehp
    driver from detecting the spurious events that would have been occur
    before pciehp loading.

(2) Add check whether slot initialization had been already done.

This is short term fix. We need more structural fixes to install
interrupt handler after slot initialization is done.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      dbd79aed
    • K
      shpchp: add message about shpchp_slot_with_bus option · b3bd307c
      由 Kenji Kaneshige 提交于 
      Some (broken?) platform assign the same slot name to multiple hotplug
slots. On such system, slot initialization would fail because of name
collision. The shpchp driver already have a "slot_with_bus" module
option which adds the bus number into the slot name. This patch adds
the message about this module option that will be displayed when slot
name collision is detected.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b3bd307c
  7. 30 4月, 2008 1 次提交
  9. 26 4月, 2008 11 次提交
  11. 21 4月, 2008 5 次提交
  13. 18 3月, 2008 1 次提交
    • M
      pciehp: don't enable slot unless forced · 9e585824
      由 Mark Lord 提交于 
      This fixes a 2.6.25 regression reported by Alex Chiang.

Invoke pciehp_enable_slot() at startup only when pciehp_force=1.
Some HP equipment apparently cannot cope with it otherwise.

This restores the (previously working) 2.6.24 behaviour here,
while allowing machines that need a kick to use pciehp_force=1.

This was the original design back in October 2007,
but Kristen suggested we try without it first:

   Kristen Carlson Accardi wrote:
   >I think it would be ok to try allowing the slot to be enabled when not
   >using pciehp_force mode.  We can wrap it later if it proves to break things

This ended up breaking one of Alex's setups,
so it's time to put the wrapper back in now.
Signed-off-by: NMark Lord <mlord@pobox.com>
Acked-by: NAlex Chiang <achiang@hp.com>
Acked-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e585824
  15. 11 3月, 2008 1 次提交
    • J
      PCI Hotplug: Fix small mem leak in IBM Hot Plug Controller Driver · b91aac29
      由 Jesper Juhl 提交于 
      In drivers/pci/hotplug/ibmphp_ebda.c::ebda_rsrc_controller(), storage is
allocated with kzalloc() and assigned to 'tmp_slot'.  Then lots of
stuff, like ->flag, ->supported_speed etc is set in tmp_slot.  A bit
further down there's then this test :

  if (!bus_info_ptr1) {
    rc = -ENODEV;
    goto error;
  }

At this point, tmp_slot has not been assigned to anything, so when
erroring-out we want to free it, but nothing at the 'error:' label
free's 'tmp_slot' - and we can't really free 'tmp_slot' at 'error:'
since we may jump to that label later when 'tmp_slot' *has* been used
and we do not want it freed. So, the only sane option left seems to be
to kfree(tmp_slot) just before jumping to the 'error:' label in the one
place where this is what actually makes sense. The following patch does
just that and thus kills off a tiny potential memory leak.
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b91aac29
  17. 05 3月, 2008 2 次提交
  19. 22 2月, 2008 2 次提交
  21. 02 2月, 2008 1 次提交
    • I
      PCI: Fix fakephp deadlock · 5c796ae7
      由 Ian Abbott 提交于 
      If the fakephp driver is used to emulate removal of a PCI device by
writing text string "0" to the "power" sysfs attribute file, this causes
its parent directory and its contents (including the "power" file) to be
deleted before the write operation returns.  Unfortunately, it ends up
in a deadlock waiting for itself to complete.

The deadlock is as follows: sysfs_write_file calls flush_write_buffer
which calls sysfs_get_active_two before calling power_write_file in
pci_hotplug_core.c via the sysfs store operation. The power_write_file
function calls disable_slot in fakephp.c via the slot operation.  The
disable_slot function calls remove_slot which calls pci_hp_deregister
(back in pci_hotplug_core.c) which calls fs_remove_slot which calls
sysfs_remove_file to remove the "power" file. The sysfs_remove_file
function calls sysfs_hash_and_remove which calls sysfs_addrm_finish
which calls sysfs_deactivate. The sysfs_deactivate function sees that
something has an active reference on the sysfs_dirent (from the
previous call to sysfs_get_active_two back up the call stack somewhere)
so waits for the active reference to go away, which is of course
impossible.

The problem has been present since 2.6.21.

This patch breaks the deadlock by queuing work queue items on a single-
threaded work queue to remove a slot from sysfs, and to rescan the PCI
buses.  There is also some protection against disabling a slot that is
already being removed.
Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
Cc: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5c796ae7