linux-kernel - Re: [PATCH 0/4, v3] Physical PCI slot objects

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071130191022.GA6189@us.ibm.com>
Date:	Fri, 30 Nov 2007 11:10:22 -0800
From:	Gary Hade <garyhade@...ibm.com>
To:	Alex Chiang <achiang@...com>
Cc:	Gary Hade <garyhade@...ibm.com>,
	Kristen Carlson Accardi <kristen.c.accardi@...el.com>,
	Matthew Wilcox <matthew@....cx>, gregkh@...e.de,
	lenb@...nel.org, rick.jones2@...com, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz, kaneshige.kenji@...fujitsu.com,
	pcihpd-discuss@...ts.sourceforge.net, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 0/4, v3] Physical PCI slot objects

On Thu, Nov 29, 2007 at 06:19:41PM -0700, Alex Chiang wrote:

  < snip >

> >  [<ffffffff802499bc>] kthread+0x47/0x73
> >  [<ffffffff8020cc98>] child_rip+0xa/0x12
> >  [<ffffffff80249975>] kthread+0x0/0x73
> >  [<ffffffff8020cc8e>] child_rip+0x0/0x12
> 
> Maybe we're trying to kick off a hotplug event on the wrong slot?
> I really have no idea...

One hotplug event related difference that I believe I 
noticed between the x3850 were I did not see the problem and
the x3950 is the hotplug event arrival location.  On the
x3850 the handler receives the handle for the transparent
p2p bridge above the slot.  On the x3950 I believe the handler
is receiving the handle for the root bridge (directly above
the transparent p2p bridge).  acpiphp installs a handler for
each of these possible arrival locations.  pci_slot installs
a handler for neither location which seems like it should be
okay.

I notice that acpi_pci_register_driver() was only being
used by acpiphp before pci_slot.  Perhaps your changes are
flushing out some sort of ACPI core coexistence issue not
seen previously because there was only a single user?

My silly idea is probably no better than your no idea. :)

> 
> > Code: ff ff ff ff 40 23 2c 88 ff ff ff ff 00 c8 c6 3b 10 81 ff ff 
> > RIP  [<ffffffff882c2344>] :pci_slot:__this_module+0x21c4/0xfffffffffffff204
> >  RSP <ffff81103fa43ea8>
> 
> Can you apply this debug patch on top of your tree, and send me
> the output?
> 
> I'd be curious to see the output for your failure case:
> 
>   # modprobe pci_slot debug=1
>   # modprobe acpiphp debug=1

Someone else is using the system right now so I may not
be able to do this until next week.

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/