Re: [PATCH 0/4, v3] Physical PCI slot objects
Hi Alex-san,
Hi Kenji-san,
* Kenji Kaneshige <[EMAIL PROTECTED]>:
Hi Alex-san,
On my system, hotplug slots themselves can be added, removed
and replaced with the ohter type of I/O box.
Are you talking about some sort of I/O cabinet/chassis that you
can attach to the actual computer? Can the I/O expander unit be
hotplugged? Or do you need to power your machine down to attach
it?
If you can hotplug it, I'm guessing that is why your firmware
presents SxFy objects in the namespace with "weird" _SUN values,
and it's why you have to check _STA to see if the slots are valid
or not. That means the value returned by _SUN will change too,
right? What will it turn into?
Currently, it's not hotpluggable (will be hotpluggable in the future).
Here is a sample AML code to explain what my firmware is doing.
Device (PCI0) {
Device (P2PA) {
Device (P2PB) { // for I/O unit (A)
Name (_ADR, ...)
Method (_STA) { ... }
}
Device (S0F0) { // for I/O unit (B)
Name (_ADR, ...)
Method (_STA) { ... }
Method (_EJx) { ... }
Method (_SUN) { ... }
}
...
}
...
}
If the I/O unit (A) is connected, _STA of P2PB returns as present
and _STA of S0F0 returns as not present.
If the I/O unit (B) is connected, _STA of P2PB returns as not
present and _STA of S0F0 returns as present.
In addtion, I think we should not trust the _SUN value of
non-existing device because the ACPI spec says in "6.5.1 _INI
(Init)" that _INI method is run before _ADR, _CID, _HID, _SUN, and
_UID are run. It means _SUN could be initialized in _INI method
implecitely. And it also says that "If the _STA method indicates
that the device is not present, OSPM will not run the _INI and will
not examine the children of the device for _INI methods.". After all,
_SUN for non-existing device is not reliable because it might not
initialized by _INI method.
This is true, but HP platforms provide _INI at the root
device/host bridge level, not on SxFy objects, so it doesn't seem
that we would need to call _STA before calling _SUN for SxFy.
Does your firmware provide _INI on SxFy objects?
No, it doesn't. But what I wanted to say was we should not use _SUN
value of non-existing device object.
Our firmware teams seem to think that _STA should give the status
of the card for hotplug support and general functional state.
They claim that it doesn't makes much sense to support _STA on
the slot itself unless you can physically change the slot
topology on the machine at runtime, which we can't do (although
maybe you can).
The section of the spec you quoted is correct as long as we are
talking ACPI 2.0 or later. My platforms implement ACPI 1.0b for
legacy reasons. :-/
In ACPI 1.0b, _EJx definition says (section 6.3.2):
For hot removal, the device must be immediately ejected
when the OS calls the _EJ0 control method. The _EJ0
control method does not return until ejection is
complete. After calling _EJ0, the OS will call _STA to
determine whether or not the eject succeeded.
So your firmware implementation does not seem backward compatible
with the 1.0b spec. The different versions of ACPI is part of the
reason why my patch is breaking on your machine.
I think this is the real reason. My platform implements ACPI 2.0 or
later. I didn't notice the chage to_EJx definition. Maybe we need to
check ACPI version in pci_slot driver.
But as long as we are quoting the spec... :)
_SUN evaluates to a DWORD that is the number to be used
in the user interface. This number is required to be
unique among the slots of the same type. It is also
recommended that this number match the slot number
printed on the physical slot whenever possible.
section 6.1.6 of ACPI 2.0c
My question is, why is your firmware returning multiple values of
1023 then? This seems to be the real reason why my patch is
breaking on your machine.
While depending on ACPI 1.0b behavior might be somewhat risky,
returning the same value for _SUN multiple times, for slots of
the same type, definitely seems non-compliant.
The reason is very simple. The reason is your patch is evaluating
invalid _SUN method. We must skip non-existing device object. This
is what your patch is already doing for pci root bridges.
In addition, even if those _SUN method were changed to return unique
number, none of the problems would be solved. Maybe pci_slot driver
would detect many unknown slots.
Thanks,
Kenji Kaneshige
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4, v3] Physical PCI slot objects
Hi Alex-san, On my system, hotplug slots themselves can be added, removed and replaced with the ohter type of I/O box. The ACPI firmware tells OS the presence of those slots using _STA method (That is, it doesn't use 'LoadTable()' AML operator). On the other hand, current pci_slot driver doesn't check _STA. As a result, pci_slot driver tryied to register the invalid (non-existing) slots. The ACPI firmware of my system returns '1023' if the invalid slot's _SUN is evaluated. This is the cause of Call Traces mentioned above. To fix this problem, pci_slot driver need to check _STA when scanning ACPI Namespace. Now this is very curious. The relevant line in pci_slot is: check_slot() status = acpi_evaluate_integer(handle, "_SUN", NULL, sun); if (ACPI_FAILURE(status)) return -1; Why does your firmware return the error information inside sun, instead of returning an error in status? That doesn't seem right to me... Because ACPI spec doesn't provide any way for firmware (AML) to return as error. In addtion, I think we should not trust the _SUN value of non-existing device because the ACPI spec says in "6.5.1 _INI (Init)" that _INI method is run before _ADR, _CID, _HID, _SUN, and _UID are run. It means _SUN could be initialized in _INI method implecitely. And it also says that "If the _STA method indicates that the device is not present, OSPM will not run the _INI and will not examine the children of the device for _INI methods.". After all, _SUN for non-existing device is not reliable because it might not initialized by _INI method. I'm sorry for reporting this so late. I'm attaching the patch to fix the problem. This is against 2.6.24-rc3 with your patches applied. Could you try it? Applying this patch causes me to only detect populated slots in my system, which isn't what I want -- otherwise, I could have just enumerated the PCI bus and found the devices that way. :) Maybe on your machine, checking existence of _STA might do the right thing, but I don't think we should actually be looking at any of the actual bits returned. If we check ACPI_STA_DEVICE_PRESENT, then we will not detect empty slots on my system. Can you try this patch to see if at least the first call to acpi_evaluate_integer helps? If that doesn't help, maybe the second block will help you, but it breaks my machine... Maybe the result is as you guess. The first block doesn't help me (with the first block, all of the slot disappeared. Please see the bottom of this mail for details). The second block helps me. There seems a difference of the interpretation about _STA for PCI hotplug slot between your firmware and my firmware. The difference is: - Your firmware provides the _STA method to represent the presence of PCI adapter card on the slot. - My firmware provides the _STA method to represent the presence of the slot. Providing _STA method to represent the presence of PCI adpater card on the slot (as your firmware does) doesn't seem right to me because of the following reasons. - ACPI spec says "After calling _EJ0, OSPM verifies the device no longer exists to determine if the eject succeeded. For _HID devices, OSPM evaluates the _STA method. For _ADR devices, OSPM checks with the bus driver for that device." in "6.3.3 _EJx (Eject)". Because PCI adapter card on the slot is _ADR device, the presence of the card must be checked with bus driver, not _STA. - ACPI spec provides the example AML code which uses _STA to represent Docking Station (See 6.3.2 _EJD (Ejection Dependent Device)". The usage of this is same as my firmware. What do you think about that? P.S. None of the slots except the strange slot named '1023' were detected with your patch. It would happen on other machines (might including hp machine) too. The reason is _STA evaluation fails on the hotplug slot which doesn't have _STA method. If the device object doesn't have a _STA method, we need to handle it as if it is present. I believe firmware normally doesn't provide _STA method for PCI hotplug slots. Thanks, Kenji Kaneshige -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4, v3] Physical PCI slot objects
> Hi Gary, Kenji-san, et. al, > > * Gary Hade <[EMAIL PROTECTED]>: >> Alex, What I was trying to suggest is a boot-time kernel >> option, not a kernel configuration option. The basic idea is >> to give the user (with a single binary kernel) the ability to >> include your ACPI-PCI slot driver feature changes only when >> they are really needed. In addition to reducing the number of >> system/PCI hotplug driver combinations where your changes would >> need to be validated, I believe would also help alleviate other >> worries (e.g. Andi Kleen's memory consumption concern). I >> believe this goal could also be achieved with the kernel config >> option by making the pci_slot module runtime loadable with the >> PCI hotplug drivers only visiting your new code when the >> pci_slot driver is loaded, although I think this would be more >> difficult to implement. > > I have modified my patch series so that the final patch that > introduces my ACPI-PCI slot driver is a full-fledged module, that > has a tristate Kconfig option. > Thank you for your good job. I tested shpchp and pciehp both with and without pci_slot module. There seems no regression from shpchp and pciehp's point of view. (I had a little concern about the hotplug slots' name that vary depending on whether pci_slot functionality is enabled or disabled. But, now that we can build pci_slot driver as a kernel module, I don't think it is a big problem). Only the problems is that I got Call Traces with the following error messages when pci_slot driver was loaded, and one strange slot named '1023' was registered (other slots are fine). This is the same problem I reported before. sysfs: duplicate filename '1023' can not be created WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() kobject_add failed for 1023 with -EEXIST, don't try to register things with the same name in the same directory. On my system, hotplug slots themselves can be added, removed and replaced with the ohter type of I/O box. The ACPI firmware tells OS the presence of those slots using _STA method (That is, it doesn't use 'LoadTable()' AML operator). On the other hand, current pci_slot driver doesn't check _STA. As a result, pci_slot driver tryied to register the invalid (non-existing) slots. The ACPI firmware of my system returns '1023' if the invalid slot's _SUN is evaluated. This is the cause of Call Traces mentioned above. To fix this problem, pci_slot driver need to check _STA when scanning ACPI Namespace. I'm sorry for reporting this so late. I'm attaching the patch to fix the problem. This is against 2.6.24-rc3 with your patches applied. Could you try it? BTW, acpiphp also seems to have the same problem... Thanks, Kenji Kaneshige --- drivers/acpi/pci_slot.c | 13 + 1 file changed, 13 insertions(+) Index: linux-2.6.24-rc3/drivers/acpi/pci_slot.c === --- linux-2.6.24-rc3.orig/drivers/acpi/pci_slot.c +++ linux-2.6.24-rc3/drivers/acpi/pci_slot.c @@ -113,10 +113,17 @@ register_slot(acpi_handle handle, u32 lv int device; unsigned long sun; char name[KOBJ_NAME_LEN]; + acpi_status status; + struct acpi_device *dummy_device; struct pci_slot *pci_slot; struct pci_bus *pci_bus = context; + /* Skip non-existing device object. */ + status = acpi_bus_get_device(handle, &dummy_device); + if (ACPI_FAILURE(status)) + return AE_OK; + if (check_slot(handle, &device, &sun)) return AE_OK; @@ -150,12 +157,18 @@ walk_p2p_bridge(acpi_handle handle, u32 acpi_status status; acpi_handle dummy_handle; acpi_walk_callback user_function; + struct acpi_device *dummy_device; struct pci_dev *dev; struct pci_bus *pci_bus; struct p2p_bridge_context child_context; struct p2p_bridge_context *parent_context = context; + /* Skip non-existing device object. */ + status = acpi_bus_get_device(handle, &dummy_device); + if (ACPI_FAILURE(status)) + return AE_OK; + pci_bus = parent_context->pci_bus; user_function = parent_context->user_function; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4, v3] Physical PCI slot objects
Gary Hade : On Sat, Nov 17, 2007 at 11:29:54AM -0700, Alex Chiang wrote: Hi all, This is v3 of the pci_slot patch series. The major change is making the ACPI-PCI slot driver a Kconfig option, as per the recommendations of others (Gary, Kenji-san). Alex, What I was trying to suggest is a boot-time kernel option, not a kernel configuration option. The basic idea is to give the user (with a single binary kernel) the ability to include your ACPI-PCI slot driver feature changes only when they are really needed. In addition to reducing the number of system/PCI hotplug driver combinations where your changes would need to be validated, I believe would also help alleviate other worries (e.g. Andi Kleen's memory consumption concern). I believe this goal could also be achieved with the kernel config option by making the pci_slot module runtime loadable with the PCI hotplug drivers only visiting your new code when the pci_slot driver is loaded, although I think this would be more difficult to implement. I agree to Gary very much. Thanks, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5][RFC] Physical PCI slot objects
1be0c20 [] start_kernel_thread+0x20/0x40 sp=e14101befe30 bsp=e14101be0c20 Unable to register kobject 1024<3>pci_slot: pci_create_slot returned -22 Thanks, Kenji Kaneshige Alex Chiang : Hello, [this patch series touches a few subsystems; hopefully I got all the right maintainers] Recently, Matthew Wilcox sent out the following mail about PCI slots: http://marc.info/?l=linux-pci&m=119432330418980&w=2 The following patch series is a rough first cut at implementing the ideas he outlined, namely, that PCI slots are physical objects that we care about, independent of their hotplug capabilities. We introduce a struct pci_slot as a first-class citizen, and turn hotplug_slot into a subsidiary structure. A brief glimpse at the potential for cleanup is given, as we modify the existing hotplug drivers and remove the multiple get_address() methods. Certainly more cleanup can be done with this new structure. Additionally, we introduce an ACPI PCI slot driver, which will detect all physical PCI slots in the system (as described by ACPI). De-coupling the notion of a physical slot from its hotplug capability allows users to understand the physical geography of their machines, whether their slots are hotpluggable or not. This patch series builds heavily on Willy's prior work (with a bit of the typical refresh needed when aiming at the moving target of the kernel). The ACPI PCI slot driver is new. I have tested this series on both ia64 (hp rx6600) and x86 (hp dl380g). On ia64, system firmware provides _SUN methods for the PCI slots and we get entries in /sys/bus/pci/slots/. On my x86 machine, firmware didn't seem to provide a _SUN, so we don't get any entries in /sys/bus/pci/slots/, but nothing really bad happens either. ;) Comments/feedback are appreciated. Thanks. /ac - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5][RFC] Physical PCI slot objects
Matthew Wilcox : On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote: As far as being able to retrieve the slot number (which it seemed from the HP manageablity application perspective is the goal here), that information is available from userspace as well for at least standard PCI and pcie based systems for occupied slots. For standard pci, you have to make something up anyway - for shpchp we just use an incremental number and combine it with the bus number to represent the slot. For pcie, you can get this info from the slot capabilities register. Ummm ... that's not what the /spec/ says. I've never worked on any shpc machines, but the shpc driver reads the slot values from the SLOT_CONFIG register, just like the spec says to. The slot number for shpc slot is like '_'. is the bus number, though I don't know the specific reason why it was added. is slot number decided according to the shpc specification, as you said. Thanks, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards
Mark Lord さんは書きました: > Kenji Kaneshige wrote: >> >> - When the card is inserted *after* modprobing pciehp, the card >>is *not* automatically powered on/detected. So it is very >>natural that the card, which had been inserted before modprobing >>pciehp, is not automatically enabled at the pciehp modprobe time. > > > Not true. Once pciehp is loaded, it automatically detects and handles > inserted and removed cards just fine. Until after the next suspend/resume. > This is because your slot is surprise remove capable. On my slot, which is not surprise remove capable, the card is not enabled even after pciehp is loaded. Thanks, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards
If a PCIe ExpressCard34 is inserted into the slot *before* I modprobe pciehp (with pciehp_force=1), then the card is not detected nor enabled. The patch provided here fixes that. Could you give me answers against the following questions? (1) Did you try "echo 1 > /sys/bus/pci/slots/XXX/power"? (XXX is the slot number to which your card had been inserted) (2) If the answer against (1) is yes, did "echo 1 > ..." work? After 1. inserting the card, and then 2. modprobing pciehp, the value of /sys/bus/pci/slots/XXX/power is already "1". According to pciehp_debug output from you, your slot doesn't have software programmable power controller. So your hardware automatically power on the slot. I think this is why the value of "power" file is already "1". (But I'm not sure if it is correct, especially because your firmware doesn't have _OSC.) On the other hand, my slot has software programmable power controller. So the value of "power" file is "0" in this case. But, yes, doing "echo 1" into it does trigger card detection and things work afterwards. This doesn't really help, because it doesn't happen automatically, unless the kernel patch is applied. (6) I think your slot is surprise removable. Is it correct? Yes, it's an externally accessible ExpressCard slot on a notebook, which is intended to be fully hotpluggable by surprise or otherwise. Ok. I think your patch is trying to solve the following two problems. Right? - When the card is inserted *after* modprobing pciehp, the card is automatically enabled (pciehp tries to automatically enable slot when the card is inserted if the slot is surprise remove capable). But if the card is inserted *before* modprobing pciehp, the card is not automatically enabled even after modprobing pciehp. - When the card is inserted *before* modprobing pciehp, the card is automatically powered on by hardware, but it is not detected by OS. That is, "power" file tells the card is working, but it is not working actually. It is strange. But those are not problems on the slot which is not surprise remove capable and has software programmable power controller because: - When the card is inserted *after* modprobing pciehp, the card is *not* automatically powered on/detected. So it is very natural that the card, which had been inserted before modprobing pciehp, is not automatically enabled at the pciehp modprobe time. - When the card is inserted *before* modprobing pciehp, the card is not automatically powered on by hardware if the slot has sortware programmable power controller. So there is no contradiction. I think your patch has a bad effect to this kind of slots. So I think your patch needs additional checks to see if the slot should be enabled or not. And you need to test your patch on PCIe Native hotplug capable hardware:) Thanks, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards
Hi Mark,
I still don't understand what the problems is very much. Could
you give me answers against the following questions?
(1) Did you try "echo 1 > /sys/bus/pci/slots/XXX/power"?
(XXX is the slot number to which your card had been inserted)
(2) If the answer against (1) is yes, did "echo 1 > ..." work?
(3) If the answer against (1) is no, could you try that?
(4) If the "echo 1 > ..." works, does it solve your problem?
(5) If the "echo 1 > ..." doesn't work, could you give me the
output of "cat /sys/bus/pci/slots/XXX/*"?
(6) I think your slot is surprise removable. Is it correct?
Thanks,
Kenji Kaneshige
(repost to conform with akpm's subject line conventions)
One of three patches to fix PCIe Hotplug so that it works with ExpressCard slots
on Dell notebooks (and others?) in conjunction with modparam of pciehp_force=1.
Fix pciehp_probe() to deal with ExpressCard cards
that were inserted prior to the driver being loaded.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- a/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:30:19.0 -0400
+++ b/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-17 22:29:59.0 -0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_enable_slot(struct slot *p_slot);
static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
--- git12/drivers/pci/hotplug/pciehp.h 2007-10-17 22:30:19.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-17 22:29:59.0 -0400
@@ -161,6 +161,7 @@
extern int pciehp_unconfigure_device(struct slot *p_slot);
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
+int pciehp_enable_slot(struct slot *p_slot);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- git12/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:30:19.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-17 22:36:06.0
-0400
@@ -471,6 +471,11 @@
t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
t_slot->hpc_ops->get_adapter_status(t_slot, &value); /* Check if slot is occupied */
+ if (value) {
+ rc = pciehp_enable_slot(t_slot);
+ if (rc) /* -ENODEV: shouldn't happen, but deal with it */
+ value = 0;
+ }
if ((POWER_CTRL(ctrl->ctrlcap)) && !value) {
rc = t_slot->hpc_ops->power_off_slot(t_slot); /* Power off slot
if not occupied*/
if (rc)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Pcihpd-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pcihpd-discuss
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "Add support for vector domain" breaks boot on x355
2007-07-31 (火) の 15:13 -0700 に Nishanth Aravamudan さんは書きました: > The following commit (4994be1b3fe9120c88022ff5c0c33f6312b17adb) broke > Linus' Tree between 2.6.22-git15 and 2.6.22-git16 on a 2-node 8-way x455 > (Madison procs). Thanks to Ryan Hodges for bisecting down to this > commit. Thank you for reporting. I think this problem might be fixed by the commit 6ffbc82351c62aeb9e817ddf93049353493d. Could you try that? Thanks, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG][PATCH] Fix race condition about network device name allocation
Hi, > How about the following (untested), instead. It hold a removes the sysfs > entries earlier (on unregister_netdevice), but holds a kobject reference. > Then when todo runs the actual last put free happens. I've confirmed the problem is fixed by Stephen's patch on my reproduction environment. Thanks, Kenji Kaneshige 2007-05-11 (金) の 09:25 -0700 に Stephen Hemminger さんは書きました: > On Fri, 11 May 2007 14:40:45 +0900 > Kenji Kaneshige <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I encountered the following error when I was hot-plugging network card > > using pci hotplug driver. > > > > kobject_add failed for eth8 with -EEXIST, don't try to register things with > > the same name in the same directory. > > > > Call Trace: > > [] show_stack+0x40/0xa0 > > sp=e000652cfbf0 bsp=e000652c9450 > > [] dump_stack+0x30/0x60 > > sp=e000652cfdc0 bsp=e000652c9438 > > [] kobject_shadow_add+0x3b0/0x440 > > sp=e000652cfdc0 bsp=e000652c93f0 > > [] kobject_add+0x30/0x60 > > sp=e000652cfdc0 bsp=e000652c93d0 > > [] device_add+0x160/0xf40 > > sp=e000652cfdc0 bsp=e000652c9358 > > [] netdev_register_sysfs+0xc0/0xe0 > > sp=e000652cfdc0 bsp=e000652c9328 > > [] register_netdevice+0x600/0x7e0 > > sp=e000652cfdc0 bsp=e000652c92e8 > > [] register_netdev+0x70/0xc0 > > sp=e000652cfdd0 bsp=e000652c92c0 > > [] e1000_probe+0x1710/0x1a00 [e1000] > > sp=e000652cfdd0 bsp=e000652c9258 > > [] pci_device_probe+0xc0/0x120 > > sp=e000652cfde0 bsp=e000652c9218 > > [] really_probe+0x1c0/0x300 > > sp=e000652cfde0 bsp=e000652c91c8 > > [] driver_probe_device+0x1a0/0x1c0 > > sp=e000652cfde0 bsp=e000652c9198 > > [] __device_attach+0x30/0x60 > > sp=e000652cfde0 bsp=e000652c9170 > > [] bus_for_each_drv+0x80/0x120 > > sp=e000652cfde0 bsp=e000652c9138 > > [] device_attach+0xa0/0x100 > > sp=e000652cfe00 bsp=e000652c9110 > > [] bus_attach_device+0x60/0xe0 > > sp=e000652cfe00 bsp=e000652c90e0 > > [] device_add+0x950/0xf40 > > sp=e000652cfe00 bsp=e000652c9068 > > [] pci_bus_add_device+0x20/0x100 > > sp=e000652cfe00 bsp=e000652c9040 > > [] pci_bus_add_devices+0x50/0x320 > > sp=e000652cfe00 bsp=e000652c9010 > > [] shpchp_configure_device+0x460/0x4a0 [shpchp] > > sp=e000652cfe00 bsp=e000652c8fc0 > > [] board_added+0x720/0x8c0 [shpchp] > > sp=e000652cfe00 bsp=e000652c8f80 > > [] shpchp_enable_slot+0x920/0xa40 [shpchp] > > sp=e000652cfe10 bsp=e000652c8f30 > > [] shpchp_sysfs_enable_slot+0x120/0x220 [shpchp] > > sp=e000652cfe20 bsp=e000652c8ef8 > > [] enable_slot+0x90/0xc0 [shpchp] > > sp=e000652cfe20 bsp=e000652c8ed0 > > [] power_write_file+0x1e0/0x2a0 [pci_hotplug] > > sp=e000652cfe20 bsp=e000652c8ea0 > > [] hotplug_slot_attr_store+0x60/0xa0 [pci_hotplug] > > sp=e000652cfe20 bsp=e000652c8e68 > > [] sysfs_write_file+0x270/0x300 > > sp=e000652cfe20 bsp=e000652c8e18 > > [] vfs_write+0x1b0/0x300 > > sp=e000652cfe20 bsp=e000652c8dc0 > > [] sys_write+0x70/0xe0 > > sp=e000652cfe20 bsp=e000652c8d48 > > [] ia64_ret_from_syscall+0x0/0x20 > > sp=e000652cfe30 bsp=e000652c8d48 > > [] __kernel_syscall_via_break+0x0/0x20 > > sp=e000652d bsp=e000652c8d48 > > > > This error is caused by the race condition between dev_alloc_name() > > and unregistering net device. The dev_alloc_name() function checks > > dev_base list to find a suitable id. The
Re: [BUG][PATCH] Fix race condition about network device name allocation
Hi Stephen, Thank you for comments. I'll try your patch. I have one concern about your patch, though I don't know very much about netdev codes. @@ -3411,6 +3410,9 @@ void unregister_netdevice(struct net_dev > /* Notifier chain MUST detach us from master device. */ > BUG_TRAP(!dev->master); > > + /* Remove entries from sysfs */ > + netdev_unregister_sysfs(dev); > + > /* Finish processing unregister after unlock */ > net_set_todo(dev); > With your patch, the netdev_unregister_sysfs() will be called earlier than now. Does it have no side effect? I'm worrying about if there are somebody that depend on sysfs entry until net_run_todo() is called. Anyway, I'll try your patch. Thanks, Kenji Kaneshige 2007-05-11 (金) の 09:25 -0700 に Stephen Hemminger さんは書きました: > On Fri, 11 May 2007 14:40:45 +0900 > Kenji Kaneshige <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I encountered the following error when I was hot-plugging network card > > using pci hotplug driver. > > > > kobject_add failed for eth8 with -EEXIST, don't try to register things with > > the same name in the same directory. > > > > Call Trace: > > [] show_stack+0x40/0xa0 > > sp=e000652cfbf0 bsp=e000652c9450 > > [] dump_stack+0x30/0x60 > > sp=e000652cfdc0 bsp=e000652c9438 > > [] kobject_shadow_add+0x3b0/0x440 > > sp=e000652cfdc0 bsp=e000652c93f0 > > [] kobject_add+0x30/0x60 > > sp=e000652cfdc0 bsp=e000652c93d0 > > [] device_add+0x160/0xf40 > > sp=e000652cfdc0 bsp=e000652c9358 > > [] netdev_register_sysfs+0xc0/0xe0 > > sp=e000652cfdc0 bsp=e000652c9328 > > [] register_netdevice+0x600/0x7e0 > > sp=e000652cfdc0 bsp=e000652c92e8 > > [] register_netdev+0x70/0xc0 > > sp=e000652cfdd0 bsp=e000652c92c0 > > [] e1000_probe+0x1710/0x1a00 [e1000] > > sp=e000652cfdd0 bsp=e000652c9258 > > [] pci_device_probe+0xc0/0x120 > > sp=e000652cfde0 bsp=e000652c9218 > > [] really_probe+0x1c0/0x300 > > sp=e000652cfde0 bsp=e000652c91c8 > > [] driver_probe_device+0x1a0/0x1c0 > > sp=e000652cfde0 bsp=e000652c9198 > > [] __device_attach+0x30/0x60 > > sp=e000652cfde0 bsp=e000652c9170 > > [] bus_for_each_drv+0x80/0x120 > > sp=e000652cfde0 bsp=e000652c9138 > > [] device_attach+0xa0/0x100 > > sp=e000652cfe00 bsp=e000652c9110 > > [] bus_attach_device+0x60/0xe0 > > sp=e000652cfe00 bsp=e000652c90e0 > > [] device_add+0x950/0xf40 > > sp=e000652cfe00 bsp=e000652c9068 > > [] pci_bus_add_device+0x20/0x100 > > sp=e000652cfe00 bsp=e000652c9040 > > [] pci_bus_add_devices+0x50/0x320 > > sp=e000652cfe00 bsp=e000652c9010 > > [] shpchp_configure_device+0x460/0x4a0 [shpchp] > > sp=e000652cfe00 bsp=e000652c8fc0 > > [] board_added+0x720/0x8c0 [shpchp] > > sp=e000652cfe00 bsp=e000652c8f80 > > [] shpchp_enable_slot+0x920/0xa40 [shpchp] > > sp=e000652cfe10 bsp=e000652c8f30 > > [] shpchp_sysfs_enable_slot+0x120/0x220 [shpchp] > > sp=e000652cfe20 bsp=e000652c8ef8 > > [] enable_slot+0x90/0xc0 [shpchp] > > sp=e000652cfe20 bsp=e000652c8ed0 > > [] power_write_file+0x1e0/0x2a0 [pci_hotplug] > > sp=e000652cfe20 bsp=e000652c8ea0 > > [] hotplug_slot_attr_store+0x60/0xa0 [pci_hotplug] > > sp=e000652cfe20 bsp=e000652c8e68 > > [] sysfs_write_file+0x270/0x300 > > sp=e000652cfe20 bsp=e000652c8e18 > > [] vfs_write+0x1b0/0x300 > > sp=e000652cfe20 bsp=e000652c8dc0 > > [] sys_write+0x70/0xe0 > > sp=e000652cfe20 bsp=e000652c8d48 > > [] ia64_ret_fr
[BUG][PATCH] Fix race condition about network device name allocation
Hi, I encountered the following error when I was hot-plugging network card using pci hotplug driver. kobject_add failed for eth8 with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [] show_stack+0x40/0xa0 sp=e000652cfbf0 bsp=e000652c9450 [] dump_stack+0x30/0x60 sp=e000652cfdc0 bsp=e000652c9438 [] kobject_shadow_add+0x3b0/0x440 sp=e000652cfdc0 bsp=e000652c93f0 [] kobject_add+0x30/0x60 sp=e000652cfdc0 bsp=e000652c93d0 [] device_add+0x160/0xf40 sp=e000652cfdc0 bsp=e000652c9358 [] netdev_register_sysfs+0xc0/0xe0 sp=e000652cfdc0 bsp=e000652c9328 [] register_netdevice+0x600/0x7e0 sp=e000652cfdc0 bsp=e000652c92e8 [] register_netdev+0x70/0xc0 sp=e000652cfdd0 bsp=e000652c92c0 [] e1000_probe+0x1710/0x1a00 [e1000] sp=e000652cfdd0 bsp=e000652c9258 [] pci_device_probe+0xc0/0x120 sp=e000652cfde0 bsp=e000652c9218 [] really_probe+0x1c0/0x300 sp=e000652cfde0 bsp=e000652c91c8 [] driver_probe_device+0x1a0/0x1c0 sp=e000652cfde0 bsp=e000652c9198 [] __device_attach+0x30/0x60 sp=e000652cfde0 bsp=e000652c9170 [] bus_for_each_drv+0x80/0x120 sp=e000652cfde0 bsp=e000652c9138 [] device_attach+0xa0/0x100 sp=e000652cfe00 bsp=e000652c9110 [] bus_attach_device+0x60/0xe0 sp=e000652cfe00 bsp=e000652c90e0 [] device_add+0x950/0xf40 sp=e000652cfe00 bsp=e000652c9068 [] pci_bus_add_device+0x20/0x100 sp=e000652cfe00 bsp=e000652c9040 [] pci_bus_add_devices+0x50/0x320 sp=e000652cfe00 bsp=e000652c9010 [] shpchp_configure_device+0x460/0x4a0 [shpchp] sp=e000652cfe00 bsp=e000652c8fc0 [] board_added+0x720/0x8c0 [shpchp] sp=e000652cfe00 bsp=e000652c8f80 [] shpchp_enable_slot+0x920/0xa40 [shpchp] sp=e000652cfe10 bsp=e000652c8f30 [] shpchp_sysfs_enable_slot+0x120/0x220 [shpchp] sp=e000652cfe20 bsp=e000652c8ef8 [] enable_slot+0x90/0xc0 [shpchp] sp=e000652cfe20 bsp=e000652c8ed0 [] power_write_file+0x1e0/0x2a0 [pci_hotplug] sp=e000652cfe20 bsp=e000652c8ea0 [] hotplug_slot_attr_store+0x60/0xa0 [pci_hotplug] sp=e000652cfe20 bsp=e000652c8e68 [] sysfs_write_file+0x270/0x300 sp=e000652cfe20 bsp=e000652c8e18 [] vfs_write+0x1b0/0x300 sp=e000652cfe20 bsp=e000652c8dc0 [] sys_write+0x70/0xe0 sp=e000652cfe20 bsp=e000652c8d48 [] ia64_ret_from_syscall+0x0/0x20 sp=e000652cfe30 bsp=e000652c8d48 [] __kernel_syscall_via_break+0x0/0x20 sp=e000652d bsp=e000652c8d48 This error is caused by the race condition between dev_alloc_name() and unregistering net device. The dev_alloc_name() function checks dev_base list to find a suitable id. The net device is removed from the dev_base list when net device is unregistered. Those are done with rtnl lock held, so there is no problem. However, removing sysfs entry is delayed until netdev_run_todo() which is outside rtnl lock. Because of this, dev_alloc_name() can create a device name which is duplicated with the existing sysfs entry. The following patch fixes this by changing dev_alloc_name() function to check not only dev_base list but also todo list and snapshot list to find a suitable id. If some devices exists on the todo list or snapshot list, sysfs entries corresponding to them are not deleted yet. Thanks, Kenji Kaneshige --- Fix the race condition between dev_alloc_name() and net device unregistration. dev_alloc_name checks `dev_base' list to find a suitable ID. On the other hand, net devices are removed from that list on net device unregistration. Both of them are done with holding rtnl lock. However, removing sysfs entry is delayed until netdev_run_todo(), which doesn't acquire rtnl lock. Therefore, on dev_alloc_name(), device name could conflict with the device, which is unregistered, but its sysfs entry still exist. To fix this bug, change dev_alloc_name to check not only `dev_base' list but also to
Re: [PATCH][BUG] Fix possible NULL pointer access in 8250 serial driver
> I'd imagine that other serial drivers might get upset having their > ->get_mcrtl() called prior to being opened. Perhaps we should be fixing > this in uart_read_proc()? > I looked at other serial drivers and I could not find any other drivers which accesses port->info in their ->get_mctrl(). This is why we fix this problem in 8250 driver. But if there is a possibility that other drivers accesses port->info in their ->get_mctrl(), we should be fixing this in uart_read_proc(), as you said. How about the following patch? We've also confirmed the problem is fixed by it. Thanks, Kenji Kaneshige This patch fixes the problem that uninitialized (NULL) 'info' member of uart_port structure can be accessed if serial driver is accessed through /proc filesystem before uart_open(), which initializes the 'info' member', is called. Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]> Signed-off-by: Taku Izumi <[EMAIL PROTECTED]> --- drivers/serial/serial_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.21-rc5/drivers/serial/serial_core.c === --- linux-2.6.21-rc5.orig/drivers/serial/serial_core.c +++ linux-2.6.21-rc5/drivers/serial/serial_core.c @@ -1665,7 +1665,7 @@ static int uart_line_info(char *buf, str unsigned int status; int mmio, ret; - if (!port) + if (!port || !port->info) return 0; mmio = port->iotype >= UPIO_MEM; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Update Documentation/pci.txt v7
Grant Grundler wrote: On Sat, Dec 23, 2006 at 11:07:26PM -0700, Grant Grundler wrote: "final" patch v7 and commit log entry appended below. :) v8 adds 2cd round of feedback from Randy Dunlap. Going once...twice... ;) Full pci.txt text is easier to review at: http://www.parisc-linux.org/~grundler/Documentation/ Same place. grant Rewrite Documentation/pci.txt: o restructure document to match how API is used when writing init code. o update to reflect changes in struct pci_driver function pointers. o removed language on "new style vs old style" device discovery. "Old style" is now deprecated. Don't use it. Left description in to document existing driver behaviors. o add section "Legacy I/O Port free driver" by Kenji Kaneshige http://lkml.org/lkml/2006/11/22/25 (renamed to "pci_enable_device_bars() and Legacy I/O Port space") Thank you for updating this. It looks much better. Thank you again, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG][PATCH] pcieport-driver: remove invalid warning message
Hi,
I got the following warning messages on some PCI Express ports.
pcie_portdrv_probe->Dev[1263:10cf] has invalid IRQ. Check vendor BIOS
I think this message is improper because those PCI Express ports don't
use an interrupt pin. This message should not be displayed for devices
which don't use an interrupt pin.
Thanks,
Kenji Kaneshige
The following warning message should not be displayed for devices
which don't use an interrupt pin.
pcie_portdrv_probe->Dev[:] has invalid IRQ. Check vendor BIOS
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
drivers/pci/pcie/portdrv_pci.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.19/drivers/pci/pcie/portdrv_pci.c
===
--- linux-2.6.19.orig/drivers/pci/pcie/portdrv_pci.c2006-12-06
21:31:32.0 +0900
+++ linux-2.6.19/drivers/pci/pcie/portdrv_pci.c 2006-12-06 21:31:38.0
+0900
@@ -90,7 +90,7 @@
return -ENODEV;
pci_set_master(dev);
-if (!dev->irq) {
+if (!dev->irq && dev->pin) {
printk(KERN_WARNING
"%s->Dev[%04x:%04x] has invalid IRQ. Check vendor BIOS\n",
__FUNCTION__, dev->device, dev->vendor);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 2/4] Cleanup - remove unnecessary handle_IRQ_event() prototype (ppc)
The function prototype for handle_IRQ_event() in include/asm-ppc/irq.h seems no longer needed because ppc uses GENERIC_HARDIRQ. This patch removes it. Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]> include/asm-ppc/irq.h |4 1 files changed, 4 deletions(-) Index: linux-2.6.13/include/asm-ppc/irq.h === --- linux-2.6.13.orig/include/asm-ppc/irq.h +++ linux-2.6.13/include/asm-ppc/irq.h @@ -398,9 +398,5 @@ extern unsigned long ppc_cached_irq_mask extern unsigned long ppc_lost_interrupts[NR_MASK_WORDS]; extern atomic_t ppc_n_lost_interrupts; -struct irqaction; -struct pt_regs; -int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *); - #endif /* _ASM_IRQ_H */ #endif /* __KERNEL__ */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 4/4] Cleanup - remove unnecessary handle_IRQ_event() prototype (x86_64)
The function prototype for handle_IRQ_event() in include/asm-x86_64/irq.h seems no longer needed because x86_64 uses GENERIC_HARDIRQ. This patch removes it. Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]> include/asm-x86_64/irq.h |4 1 files changed, 4 deletions(-) Index: linux-2.6.13/include/asm-x86_64/irq.h === --- linux-2.6.13.orig/include/asm-x86_64/irq.h +++ linux-2.6.13/include/asm-x86_64/irq.h @@ -48,10 +48,6 @@ static __inline__ int irq_canonicalize(i #define ARCH_HAS_NMI_WATCHDOG /* See include/linux/nmi.h */ #endif -struct irqaction; -struct pt_regs; -int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *); - #ifdef CONFIG_HOTPLUG_CPU #include extern void fixup_irqs(cpumask_t map); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 3/4] Cleanup - remove unnecessary handle_IRQ_event() prototype (sh)
The function prototype for handle_IRQ_event() in include/asm-sh/irq.h seems no longer needed because sh uses GENERIC_HARDIRQ. This patch removes it. Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]> include/asm-sh/irq.h |4 1 files changed, 4 deletions(-) Index: linux-2.6.13/include/asm-sh/irq.h === --- linux-2.6.13.orig/include/asm-sh/irq.h +++ linux-2.6.13/include/asm-sh/irq.h @@ -587,10 +587,6 @@ static inline int generic_irq_demux(int #define irq_canonicalize(irq) (irq) #define irq_demux(irq) __irq_demux(sh_mv.mv_irq_demux(irq)) -struct irqaction; -struct pt_regs; -int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *); - #if defined(CONFIG_CPU_SUBTYPE_SH73180) #include #endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 1/4] Cleanup - remove unnecessary handle_IRQ_event() prototype (mips)
The function prototype for handle_IRQ_event() in include/asm-mips/irq.h
seems no longer needed because mips uses GENERIC_HARDIRQ. This patch
removes it.
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
include/asm-mips/irq.h |3 ---
1 files changed, 3 deletions(-)
Index: linux-2.6.13/include/asm-mips/irq.h
===
--- linux-2.6.13.orig/include/asm-mips/irq.h
+++ linux-2.6.13/include/asm-mips/irq.h
@@ -49,7 +49,4 @@ do {
\
extern void arch_init_irq(void);
-struct irqaction;
-int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *);
-
#endif /* _ASM_IRQ_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 0/4] Cleanup - remove unnecessary handle_IRQ_event() prototype
Hi,
I think the function prototypes for handle_IRQ_event() in
include/asm-{mips,ppc,sh,x86_64}/irq.h are no longer needed because
these architectures are using GENERIC_HARDIRQ. This series of patches
removes those unnecessary handle_IRQ_event() prototypes.
NOTE: Since I don't have these architectures, these patches are not
tested yet. I hope these patches will be tested by someone who has
these architectures.
Thanks,
Kenji Kaneshige
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]
Hi Bjorn,
Thank you very much for the new patch
and I'm very sorry for troubling you.
The patch looks very good to me.
Thanks,
Kenji Kaneshige
Bjorn Helgaas wrote:
On Tuesday 02 August 2005 7:05 pm, Kenji Kaneshige wrote:
This breaks the following patch that is already included into -mm
tree.
http://sourceforge.net/mailarchive/forum.php?thread_id=7844247&forum_id=6102
I think we need to check if acpi_register_gsi() succeeded or not.
You're absolutely right. I was just based off a Linus tree, non -mm,
and didn't notice that your patch conflicted. How about the following
(based on 2.6.13-rc4-mm1)? I moved the acpi_register_gsi() into
pnpacpi_parse_allocated_irqresource(), which I think is nice because
the test for failure is right next to the call.
PNPACPI: fix types when decoding ACPI resources
Use types that match the ACPI resource structures. Previously
the u64 value from an RSTYPE_ADDRESS64 was passed as an int,
which corrupts the value.
This is one of the things that prevents 8250_pnp from working
on HP ia64 boxes. After 8250_pnp works, we will be able to
remove 8250_acpi.c.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm/drivers/pnp/pnpacpi/rsparser.c
===
--- work-mm.orig/drivers/pnp/pnpacpi/rsparser.c 2005-08-02 09:39:25.0
-0600
+++ work-mm/drivers/pnp/pnpacpi/rsparser.c 2005-08-03 09:31:05.0
-0600
@@ -73,25 +73,28 @@
}
static void
-pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, int irq)
+pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 gsi,
+ int edge_level, int active_high_low)
{
int i = 0;
+ int irq;
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
i < PNP_MAX_IRQ)
i++;
if (i < PNP_MAX_IRQ) {
res->irq_resource[i].flags = IORESOURCE_IRQ; //Also clears
_UNSET flag
+ irq = acpi_register_gsi(gsi, edge_level, active_high_low);
if (irq < 0) {
res->irq_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->irq_resource[i].start =(unsigned long) irq;
- res->irq_resource[i].end = (unsigned long) irq;
+ res->irq_resource[i].start = irq;
+ res->irq_resource[i].end = irq;
}
}
static void
-pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
+pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, u32 dma)
{
int i = 0;
while (i < PNP_MAX_DMA &&
@@ -103,14 +106,14 @@
res->dma_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->dma_resource[i].start =(unsigned long) dma;
- res->dma_resource[i].end = (unsigned long) dma;
+ res->dma_resource[i].start = dma;
+ res->dma_resource[i].end = dma;
}
}
static void
pnpacpi_parse_allocated_ioresource(struct pnp_resource_table * res,
- int io, int len)
+ u32 io, u32 len)
{
int i = 0;
while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
@@ -122,14 +125,14 @@
res->port_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->port_resource[i].start = (unsigned long) io;
- res->port_resource[i].end = (unsigned long)(io + len - 1);
+ res->port_resource[i].start = io;
+ res->port_resource[i].end = io + len - 1;
}
}
static void
pnpacpi_parse_allocated_memresource(struct pnp_resource_table * res,
- int mem, int len)
+ u64 mem, u64 len)
{
int i = 0;
while (!(res->mem_resource[i].flags & IORESOURCE_UNSET) &&
@@ -141,8 +144,8 @@
res->mem_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->mem_resource[i].start = (unsigned long) mem;
- res->mem_resource[i].end = (unsigned long)(mem + len - 1);
+ res->mem_resource[i].start = mem;
+ res->mem_resource[i].end = mem + len - 1;
}
}
@@ -156,10 +159,10 @@
case ACPI_RSTYPE_IRQ:
if ((res->data.irq.number_of_interrupts > 0) &&
valid_IRQ(res->data.irq.interrupts[0])) {
- pnpacpi_parse_allocated_irqresource(res_table,
-acpi_register_gsi(res->data.irq.interrupts[0],
- res->data.irq.edge_level,
- res->data.irq.active_high_low));
+ pnpacpi_parse_allocate
Re: [ACPI] [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]
Hi Bjorn,
static void
-pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, int irq)
+pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 irq)
{
int i = 0;
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
@@ -85,13 +85,13 @@
res->irq_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->irq_resource[i].start =(unsigned long) irq;
- res->irq_resource[i].end = (unsigned long) irq;
+ res->irq_resource[i].start = irq;
+ res->irq_resource[i].end = irq;
}
}
This breaks the following patch that is already included into -mm
tree.
http://sourceforge.net/mailarchive/forum.php?thread_id=7844247&forum_id=6102
I think we need to check if acpi_register_gsi() succeeded or not.
Thanks,
Kenji Kaneshige
Bjorn Helgaas wrote:
Any objections to the patch below? I posted it last Wednesday,
but haven't heard anything. Once we have this fix, 8250_pnp
should have sufficient functionality that we can get rid of
8250_acpi.
Use types that match the ACPI resource structures. Previously
the u64 value from an RSTYPE_ADDRESS64 was passed as an int,
which corrupts the value.
This is one of the things that prevents 8250_pnp from working
on HP ia64 boxes. After 8250_pnp works, we will be able to
remove 8250_acpi.c.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/pnp/pnpacpi/rsparser.c
===
--- work.orig/drivers/pnp/pnpacpi/rsparser.c2005-07-25 15:04:26.0
-0600
+++ work/drivers/pnp/pnpacpi/rsparser.c 2005-07-27 10:02:19.0 -0600
@@ -73,7 +73,7 @@
}
static void
-pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, int irq)
+pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 irq)
{
int i = 0;
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
@@ -85,13 +85,13 @@
res->irq_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->irq_resource[i].start =(unsigned long) irq;
- res->irq_resource[i].end = (unsigned long) irq;
+ res->irq_resource[i].start = irq;
+ res->irq_resource[i].end = irq;
}
}
static void
-pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
+pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, u32 dma)
{
int i = 0;
while (i < PNP_MAX_DMA &&
@@ -103,14 +103,14 @@
res->dma_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->dma_resource[i].start =(unsigned long) dma;
- res->dma_resource[i].end = (unsigned long) dma;
+ res->dma_resource[i].start = dma;
+ res->dma_resource[i].end = dma;
}
}
static void
pnpacpi_parse_allocated_ioresource(struct pnp_resource_table * res,
- int io, int len)
+ u32 io, u32 len)
{
int i = 0;
while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
@@ -122,14 +122,14 @@
res->port_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->port_resource[i].start = (unsigned long) io;
- res->port_resource[i].end = (unsigned long)(io + len - 1);
+ res->port_resource[i].start = io;
+ res->port_resource[i].end = io + len - 1;
}
}
static void
pnpacpi_parse_allocated_memresource(struct pnp_resource_table * res,
- int mem, int len)
+ u64 mem, u64 len)
{
int i = 0;
while (!(res->mem_resource[i].flags & IORESOURCE_UNSET) &&
@@ -141,8 +141,8 @@
res->mem_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->mem_resource[i].start = (unsigned long) mem;
- res->mem_resource[i].end = (unsigned long)(mem + len - 1);
+ res->mem_resource[i].start = mem;
+ res->mem_resource[i].end = mem + len - 1;
}
}
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Acpi-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acpi-devel
-
To unsubscribe from this list: send the line
[PATCH 2.6.13-rc3 4/6] failure of acpi_register_gsi() should be handled properly - change phpacpi driver
This patch adds the error check of acpi_register_gsi() into pnpacpi
driver.
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
linux-2.6.13-rc3-kanesige/drivers/pnp/pnpacpi/rsparser.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/pnp/pnpacpi/rsparser.c~handle-error-acpi_register_gsi-pnpacpi
drivers/pnp/pnpacpi/rsparser.c
---
linux-2.6.13-rc3/drivers/pnp/pnpacpi/rsparser.c~handle-error-acpi_register_gsi-pnpacpi
2005-07-28 01:01:17.0 +0900
+++ linux-2.6.13-rc3-kanesige/drivers/pnp/pnpacpi/rsparser.c2005-07-28
01:01:17.0 +0900
@@ -81,7 +81,7 @@ pnpacpi_parse_allocated_irqresource(stru
i++;
if (i < PNP_MAX_IRQ) {
res->irq_resource[i].flags = IORESOURCE_IRQ; //Also clears
_UNSET flag
- if (irq == -1) {
+ if (irq < 0) {
res->irq_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3 6/6] failure of acpi_register_gsi() should be handled properly - change ia64 iosapic code
Change iosapic_register_intr(), which called by acpi_register_gsi(),
to return negative value on error instead of panic.
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
linux-2.6.13-rc3-kanesige/arch/ia64/kernel/iosapic.c | 20 ---
1 files changed, 13 insertions(+), 7 deletions(-)
diff -puN
arch/ia64/kernel/iosapic.c~handle-error-acpi_register_gsi-remove-panic-iosapic-ia64
arch/ia64/kernel/iosapic.c
---
linux-2.6.13-rc3/arch/ia64/kernel/iosapic.c~handle-error-acpi_register_gsi-remove-panic-iosapic-ia64
2005-07-28 01:01:19.0 +0900
+++ linux-2.6.13-rc3-kanesige/arch/ia64/kernel/iosapic.c2005-07-28
01:01:19.0 +0900
@@ -561,7 +561,7 @@ static inline int vector_is_shared (int
return (iosapic_intr_info[vector].count > 1);
}
-static void
+static int
register_intr (unsigned int gsi, int vector, unsigned char delivery,
unsigned long polarity, unsigned long trigger)
{
@@ -576,7 +576,7 @@ register_intr (unsigned int gsi, int vec
index = find_iosapic(gsi);
if (index < 0) {
printk(KERN_WARNING "%s: No IOSAPIC for GSI %u\n",
__FUNCTION__, gsi);
- return;
+ return -ENODEV;
}
iosapic_address = iosapic_lists[index].addr;
@@ -587,7 +587,7 @@ register_intr (unsigned int gsi, int vec
rte = iosapic_alloc_rte();
if (!rte) {
printk(KERN_WARNING "%s: cannot allocate memory\n",
__FUNCTION__);
- return;
+ return -ENOMEM;
}
rte_index = gsi - gsi_base;
@@ -603,7 +603,7 @@ register_intr (unsigned int gsi, int vec
struct iosapic_intr_info *info = &iosapic_intr_info[vector];
if (info->trigger != trigger || info->polarity != polarity) {
printk (KERN_WARNING "%s: cannot override the
interrupt\n", __FUNCTION__);
- return;
+ return -EINVAL;
}
}
@@ -623,6 +623,7 @@ register_intr (unsigned int gsi, int vec
__FUNCTION__, vector, idesc->handler->typename,
irq_type->typename);
idesc->handler = irq_type;
}
+ return 0;
}
static unsigned int
@@ -710,7 +711,7 @@ int
iosapic_register_intr (unsigned int gsi,
unsigned long polarity, unsigned long trigger)
{
- int vector, mask = 1;
+ int vector, mask = 1, err;
unsigned int dest;
unsigned long flags;
struct iosapic_rte_info *rte;
@@ -738,7 +739,7 @@ again:
if (vector < 0) {
vector = iosapic_find_sharable_vector(trigger, polarity);
if (vector < 0)
- panic("%s: out of interrupt vectors!\n", __FUNCTION__);
+ return -ENOSPC;
}
spin_lock_irqsave(&irq_descp(vector)->lock, flags);
@@ -753,8 +754,13 @@ again:
}
dest = get_target_cpu(gsi, vector);
- register_intr(gsi, vector, IOSAPIC_LOWEST_PRIORITY,
+ err = register_intr(gsi, vector, IOSAPIC_LOWEST_PRIORITY,
polarity, trigger);
+ if (err < 0) {
+ spin_unlock(&iosapic_lock);
+ spin_unlock_irqrestore(&irq_descp(vector)->lock, flags);
+ return err;
+ }
/*
* If the vector is shared and already unmasked for
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3 0/6] failure of acpi_register_gsi() should be handled properly
Hi, Current acpi_register_gsi() function has no way to indicate errors to its callers even though acpi_register_gsi() can fail to register gsi because of some reasons (out of memory, lack of interrupt vectors, incorrect BIOS, and so on). As a result, caller of acpi_register_gsi() cannot handle the case that acpi_register_gsi() fails. I think failure of acpi_register_gsi() should be handled properly. This series of patches changes acpi_register_gsi() to return negative value on error, and also changes callers of acpi_register_gsi() to handle failure of acpi_register_gsi(). Thanks, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3 5/6] failure of acpi_register_gsi() should be handled properly - change acpi based 8250 driver
This patch adds the error check of acpi_register_gsi() into ACPI based
8250 serial driver.
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
linux-2.6.13-rc3-kanesige/drivers/serial/8250_acpi.c | 20 +++
1 files changed, 16 insertions(+), 4 deletions(-)
diff -puN drivers/serial/8250_acpi.c~handle-error-acpi_register_gsi-8250_acpi
drivers/serial/8250_acpi.c
---
linux-2.6.13-rc3/drivers/serial/8250_acpi.c~handle-error-acpi_register_gsi-8250_acpi
2005-07-28 01:01:18.0 +0900
+++ linux-2.6.13-rc3-kanesige/drivers/serial/8250_acpi.c2005-07-28
01:01:18.0 +0900
@@ -47,18 +47,30 @@ static acpi_status acpi_serial_port(stru
static acpi_status acpi_serial_ext_irq(struct uart_port *port,
struct acpi_resource_ext_irq *ext_irq)
{
- if (ext_irq->number_of_interrupts > 0)
- port->irq = acpi_register_gsi(ext_irq->interrupts[0],
+ int rc;
+
+ if (ext_irq->number_of_interrupts > 0) {
+ rc = acpi_register_gsi(ext_irq->interrupts[0],
ext_irq->edge_level, ext_irq->active_high_low);
+ if (rc < 0)
+ return AE_ERROR;
+ port->irq = rc;
+ }
return AE_OK;
}
static acpi_status acpi_serial_irq(struct uart_port *port,
struct acpi_resource_irq *irq)
{
- if (irq->number_of_interrupts > 0)
- port->irq = acpi_register_gsi(irq->interrupts[0],
+ int rc;
+
+ if (irq->number_of_interrupts > 0) {
+ rc = acpi_register_gsi(irq->interrupts[0],
irq->edge_level, irq->active_high_low);
+ if (rc < 0)
+ return AE_ERROR;
+ port->irq = rc;
+ }
return AE_OK;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3 2/6] failure of acpi_register_gsi() should be handled properly - change acpi pci code
This patch adds the error check of acpi_register_gsi() into
acpi_pci_enable_irq().
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
linux-2.6.13-rc3-kanesige/drivers/acpi/pci_irq.c |9 -
1 files changed, 8 insertions(+), 1 deletion(-)
diff -puN
drivers/acpi/pci_irq.c~handle-error-acpi_register_gsi-acpi_pci_enable_irq
drivers/acpi/pci_irq.c
---
linux-2.6.13-rc3/drivers/acpi/pci_irq.c~handle-error-acpi_register_gsi-acpi_pci_enable_irq
2005-07-28 01:01:15.0 +0900
+++ linux-2.6.13-rc3-kanesige/drivers/acpi/pci_irq.c2005-07-28
01:01:15.0 +0900
@@ -392,6 +392,7 @@ acpi_pci_irq_enable (
int edge_level = ACPI_LEVEL_SENSITIVE;
int active_high_low = ACPI_ACTIVE_LOW;
char*link = NULL;
+ int rc;
ACPI_FUNCTION_TRACE("acpi_pci_irq_enable");
@@ -444,7 +445,13 @@ acpi_pci_irq_enable (
}
}
- dev->irq = acpi_register_gsi(irq, edge_level, active_high_low);
+ rc = acpi_register_gsi(irq, edge_level, active_high_low);
+ if (rc < 0) {
+ printk(KERN_WARNING PREFIX "PCI Interrupt %s[%c]: failed "
+ "to register GSI\n", pci_name(dev), ('A' + pin));
+ return_VALUE(rc);
+ }
+ dev->irq = rc;
printk(KERN_INFO PREFIX "PCI Interrupt %s[%c] -> ",
pci_name(dev), 'A' + pin);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3 3/6] failure of acpi_register_gsi() should be handled properly - change hpet driver
This patch adds the error check of acpi_register_gsi() into hpet
driver.
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
linux-2.6.13-rc3-kanesige/drivers/char/hpet.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff -puN drivers/char/hpet.c~handle-error-acpi_register_gsi-hpet
drivers/char/hpet.c
--- linux-2.6.13-rc3/drivers/char/hpet.c~handle-error-acpi_register_gsi-hpet
2005-07-28 01:01:16.0 +0900
+++ linux-2.6.13-rc3-kanesige/drivers/char/hpet.c 2005-07-28
01:01:16.0 +0900
@@ -906,11 +906,15 @@ static acpi_status hpet_resources(struct
if (irqp->number_of_interrupts > 0) {
hdp->hd_nirqs = irqp->number_of_interrupts;
- for (i = 0; i < hdp->hd_nirqs; i++)
- hdp->hd_irq[i] =
+ for (i = 0; i < hdp->hd_nirqs; i++) {
+ int rc =
acpi_register_gsi(irqp->interrupts[i],
irqp->edge_level,
irqp->active_high_low);
+ if (rc < 0)
+ return AE_ERROR;
+ hdp->hd_irq[i] = rc;
+ }
}
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3 1/6] failure of acpi_register_gsi() should be handled properly - change acpi_register_gsi() interface
This patch changes the type of return value of acpi_register_gsi()
from "unsigned int" to "int" to indicate an error. If
acpi_register_gsi() fails to register gsi, it returns negative value.
Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
---
linux-2.6.13-rc3-kanesige/arch/i386/kernel/acpi/boot.c |6 +-
linux-2.6.13-rc3-kanesige/arch/ia64/kernel/acpi.c |6 +-
linux-2.6.13-rc3-kanesige/include/linux/acpi.h |2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
diff -puN arch/i386/kernel/acpi/boot.c~handle-error-acpi_register_gsi
arch/i386/kernel/acpi/boot.c
---
linux-2.6.13-rc3/arch/i386/kernel/acpi/boot.c~handle-error-acpi_register_gsi
2005-07-28 01:01:14.0 +0900
+++ linux-2.6.13-rc3-kanesige/arch/i386/kernel/acpi/boot.c 2005-07-28
01:01:14.0 +0900
@@ -484,7 +484,11 @@ int acpi_gsi_to_irq(u32 gsi, unsigned in
return 0;
}
-unsigned int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)
+/*
+ * success: return IRQ number (>=0)
+ * failure: return < 0
+ */
+int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)
{
unsigned int irq;
unsigned int plat_gsi = gsi;
diff -puN arch/ia64/kernel/acpi.c~handle-error-acpi_register_gsi
arch/ia64/kernel/acpi.c
--- linux-2.6.13-rc3/arch/ia64/kernel/acpi.c~handle-error-acpi_register_gsi
2005-07-28 01:01:14.0 +0900
+++ linux-2.6.13-rc3-kanesige/arch/ia64/kernel/acpi.c 2005-07-28
01:01:14.0 +0900
@@ -563,7 +563,11 @@ acpi_numa_arch_fixup (void)
}
#endif /* CONFIG_ACPI_NUMA */
-unsigned int
+/*
+ * success: return IRQ number (>=0)
+ * failure: return < 0
+ */
+int
acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
{
if (has_8259 && gsi < 16)
diff -puN include/linux/acpi.h~handle-error-acpi_register_gsi
include/linux/acpi.h
--- linux-2.6.13-rc3/include/linux/acpi.h~handle-error-acpi_register_gsi
2005-07-28 01:01:14.0 +0900
+++ linux-2.6.13-rc3-kanesige/include/linux/acpi.h 2005-07-28
01:01:14.0 +0900
@@ -445,7 +445,7 @@ static inline int acpi_boot_table_init(v
#endif /*!CONFIG_ACPI_BOOT*/
-unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low);
+int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low);
int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
/*
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] properly stop devices before poweroff
Hi, I think the patch Tony mentioned (ia64-halt-hangup-fix.patch) was already merged into -mm tree. But as Tony said, it doesn't work and removing reboot notifier of e1000 looks better than changing ia64 version of pcibios_disable_device(). After all, I think ia64-halt-hangup-fix.patch should be removed from -mm tree. Thanks, Kenji Kaneshige Luck, Tony wrote: I started on my OLS homework from Andrew ... and began looking into what is going on here. The story so far: Pavel added calls to device_suspend() to three of the cases in the sys_reboot() path. This stopped ia64 from being able to shutdown. There is a oops with a stacktrace pointing back at the sys_reboot call. Initial analysis from Kenji Kaneshige said that we might fix this by adding a patch to the ia64 version of pcibios_disable_device() to make it check whether the device was enabled before calling acpi_pci_irq_disable(). This might fix things if the issue was simply problems with this being called twice. Pavel sent a "Looks good", Adam said "Is it the right fix?" I just tried it ... it doesn't work, we still see an oops from the sys_reboot() ... so shutdown hangs, and we can sidestep the issue of whether this is ideologically correct. Then I wondered whether it was just an e1000 problem (since Pavel had also commented that we should perhaps removed the reboot notifier from the e1000 driver). So I rebuilt my kernel with e1000 as a module and ran "rmmod e1000" before running shutdown. Which promptly failed with a stack trace that ran through mptscsih driver instead of e1000. [N.B. Kaneshige-san has also noted that his i386 system which has the mptfusion also hangs executing a SYNCHRONIZE_CACHE command]. Code examination in the e1000 case shows that we are a bit confused and call first: notifier_call_chain(reboot_notifier, ...) e1000_notify_reboot(...) e1000_suspend(...) pci_disable_device(...) pci_set_power_state(...) and then: device_suspend(...) suspend_device() == dev->bus->suspend == pci_device_suspend e1000_suspend() pci_disable_device() pciset_power_state() So it looks like Pavel is right ... registering the reboot notifier is bogus in e1000. Commenting out the register/unregister also allows me to get past the e1000 so that I can fail in mptscsih_suspend() path. But the fusion driver doesn't register a reboot notifier, so I can't try the same trick there :-) Andrew: How did you get the squitty font on ia64? The stack trace from the oops flies off the top of the screen. I've tried a few "vga=0x0f07" type options, but I keep getting a big font. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] i386: Per node IDT
Hi, Agreed, the first version was a per cpu one simply so that i could test it on a normal SMP system. Andi seems to be of the same opinion, what do you think of the hotplug cpu case (explained in previous email)? I think we need to migrate interrupts to the other CPU in the hotplug CPU case. Even when we use per node approach, we need to consider interrupt migration between nodes because all CPUs on the node could be hot-removed. Thanks, Kenji Kaneshige - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 'is_enabled' flag should be set/cleared when the device is actually enabled/disabled
Hi,
(B
(BI think 'is_enabled' flag in pci_dev structure should be set/cleared
(Bwhen the device actually enabled/disabled. Especially about
(Bpci_enable_device(), it can be failed. By this change, we will also
(Bget the possibility of refering 'is_enabled' flag from the functions
(Bcalled through pci_enable_device()/pci_disable_device().
(B
(BSigned-off-by: Kenji Kaneshige <[EMAIL PROTECTED]>
(B
(B
(B---
(B
(B linux-2.6.12-rc2-kanesige/drivers/pci/pci.c |7 +++
(B 1 files changed, 3 insertions(+), 4 deletions(-)
(B
(Bdiff -puN drivers/pci/pci.c~fix_update_is_enabled drivers/pci/pci.c
(B--- linux-2.6.12-rc2/drivers/pci/pci.c~fix_update_is_enabled2005-04-07
(B18:59:47.058814755 +0900
(B+++ linux-2.6.12-rc2-kanesige/drivers/pci/pci.c 2005-04-07 19:02:25.843969060
(B+0900
(B@@ -398,10 +398,10 @@ pci_enable_device(struct pci_dev *dev)
(B {
(Bint err;
(B
(B- dev->is_enabled = 1;
(Bif ((err = pci_enable_device_bars(dev, (1 << PCI_NUM_RESOURCES) - 1)))
(Breturn err;
(Bpci_fixup_device(pci_fixup_enable, dev);
(B+ dev->is_enabled = 1;
(Breturn 0;
(B }
(B
(B@@ -427,16 +427,15 @@ pci_disable_device(struct pci_dev *dev)
(B {
(Bu16 pci_command;
(B
(B- dev->is_enabled = 0;
(B- dev->is_busmaster = 0;
(B-
(Bpci_read_config_word(dev, PCI_COMMAND, &pci_command);
(Bif (pci_command & PCI_COMMAND_MASTER) {
(Bpci_command &= ~PCI_COMMAND_MASTER;
(Bpci_write_config_word(dev, PCI_COMMAND, pci_command);
(B}
(B+ dev->is_busmaster = 0;
(B
(Bpcibios_disable_device(dev);
(B+ dev->is_enabled = 0;
(B }
(B
(B /**
(B
(B_
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at http://www.tux.org/lkml/
