| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20100209233154.GC12564@us.ibm.com> Date: Tue, 9 Feb 2010 15:31:54 -0800 From: Gary Hade <garyhade@...ibm.com> To: Gary Hade <garyhade@...ibm.com> Cc: "Rafael J. Wysocki" <rjw@...k.pl>, linux-pm@...ts.linux-foundation.org, Linux PCI <linux-pci@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Jesse Barnes <jbarnes@...tuousgeek.org>, "Moore, Robert" <robert.moore@...el.com>, Matthew Garrett <mjg@...hat.com> Subject: Re: [linux-pm] [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7) On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote: > On Tue, Feb 09, 2010 at 09:19:51PM +0100, Rafael J. Wysocki wrote: > > On Tuesday 09 February 2010, Gary Hade wrote: > > > On Tue, Feb 09, 2010 at 08:41:16AM -0800, Gary Hade wrote: > > > > On Tue, Feb 09, 2010 at 01:48:20PM +0100, Rafael J. Wysocki wrote: > > > > > On Tuesday 09 February 2010, Gary Hade wrote: > > > > > > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote: > > > > > > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote: > > > > > > > > On Monday 08 February 2010, Rafael J. Wysocki wrote: > > > > > > > > > On Monday 08 February 2010, Gary Hade wrote: > > > > > > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote: > > > > > > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote: > > > > > > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote: > > > > > > > > > > > > > From: Rafael J. Wysocki <rjw@...k.pl> > > > > > > > > > > > > > > > > > > > > > > > > > > Although the majority of PCI devices can generate PMEs that in > > > > > > > > > > > > > principle may be used to wake up devices suspended at run time, > > > > > > > > > > > > > platform support is generally necessary to convert PMEs into wake-up > > > > > > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this > > > > > > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE > > > > > > > > > > > > > associated with the device to generate an ACPI wake-up event that we > > > > > > > > > > > > > can set up a handler for, provided that everything is configured > > > > > > > > > > > > > correctly. > > > > > > > > > > > > > > > > > > > > > > > > I think acpiphp needs a little attention after this patch. Gary > > > > > > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp > > > > > > > > > > > > complains like this: > > > > > > > > > > > > > > > > > > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > > > > > > > > > > > > acpiphp: Slot [9] registered > > > > > > > > > > > > acpiphp: Slot [10] registered > > > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler > > > > > > > > > > > > acpiphp: Slot [6] registered > > > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler > > > > > > > > > > > > > > > > > > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp > > > > > > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain > > > > > > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch. > > > > > > > > > > > > > > > > > > > > > > I can't see the possible reason looking at the code alone. > > > > > > > > > > > > > > > > > > > > > > Could you add a debug printk() printing the error code returned by > > > > > > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please? > > > > > > > > > > > > > > > > > > > > Rafael, On the system where I ran into the problem it returns > > > > > > > > > > AE_NOT_FOUND. See below. > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > Well, that means there's no struct acpi_device object associated with handle. > > > > > > > > > > > > > > > > > > I must admit I didn't take that into consideration, but it should be easily > > > > > > > > > fixable. I'll send a patch for that later today. > > > > > > > > > > > > > > > > Patch appended. > > > > > > > > > > > > > > > > If the theory is correct, it should fix the issue. Please test. > > > > > > > > > > > > > > Well, acpiphp now loads OK with no disturbing messages: > > > > > > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > > > > > > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > > > > > > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots > > > > > > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01 > > > > > > > [ 247.385519] acpiphp: Slot [1] registered > > > > > > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots > > > > > > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01 > > > > > > > [ 247.386225] acpiphp: Slot [2] registered > > > > > > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0 > > > > > > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00 > > > > > > > [ 247.386902] acpiphp: Slot [3] registered > > > > > > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0 > > > > > > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00 > > > > > > > [ 247.387620] acpiphp: Slot [4] registered > > > > > > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0 > > > > > > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00 > > > > > > > [ 247.388347] acpiphp: Slot [5] registered > > > > > > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0 > > > > > > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00 > > > > > > > [ 247.389114] acpiphp: Slot [6] registered > > > > > > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot > > > > > > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot > > > > > > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot > > > > > > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot > > > > > > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot > > > > > > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot > > > > > > > [ 247.389753] acpiphp_glue: Total 6 slots > > > > > > > > > > > > > > However, I didn't have a chance to confirm that hot-add of a > > > > > > > PCI card works correctly before someone else swiped the system > > > > > > > from me for a while. I will verify this when I get it back, > > > > > > > hopefully later today. > > > > > > > > > > > > I got the system back but unfortunately have some bad news. > > > > > > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable > > > > > > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe > > > > > > card but acpiphp did not seem to see the hot-add event for > > > > > > either card. acpiphp was loaded with debug=1 and issued no > > > > > > messages when I added the cards. > > > > > > > > > > I gather it works without the $subject patch? > > > > > > > > I don't know for sure. Late Friday after running into the handler > > > > registration issue I reverted 8/9 which required hand fixup for > > > > one hunk failure. I then got some compile errors which I assumed > > > > may be related to my non-removal of some of the other patches in the > > > > series. I started reverting the entire series but got a failure right > > > > away with 9/9 but didn't take the time to try to resolve it. > > > > > > > > Since it sounds like you are doubtful that your changes are > > > > responsible for this new issue I will try to make time to fuss > > > > with this more today. > > > > > > Rafael, I think I can approach this from a different direction. > > > Except for a trivial failure with 9/9, the entire series applies > > > to 2.6.33-rc7. I will try hot-add with 2.6.33-rc7 with and without > > > your patches and let you know what happens. > > > > Yes, please, but you may want to test the appended patch first. > > > > If I think correctly what the problem is, it should work. > > OK. I already confirmed that the problem reproduces with your > patches applied. I am now in the process of trying vanilla > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give > your patch a try. The hot-add worked fine with an unpatched 2.6.33-rc7. The new patch when added to the 2.6.33-rc7 tree that included the original patchset unfortunately did not correct the problem. Hot-remove also seems to be acting a little strange. After I echoed 0 to the power file for a card that was present during boot, a read of the power file correctly showed 0, dmesg output showed the normal remove related messages, the green LED next to the slot transitioned from 'on' to 'off' as it normally does, and the amber LED next to the slot transitioned from 'off' to 'blinking on and off' as it normally does. Everything up to this point appeared normal but after I removed the card and closed the latch the amber LED continued 'blinking on and off' which is _not_ normal. It normally transitions to totally 'off' after latch is closed following removal of the card. Gary -- Gary Hade System x Enablement IBM Linux Technology Center 503-578-4503 IBM T/L: 775-4503 garyhade@...ibm.com http://www.ibm.com/linux/ltc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists