On Tue, 2006-05-23 at 22:03 -0700, Brown, Len wrote:
> Same panic with and without a docking station present?
>
> Does the panic go away with CONFIG_ACPI_DOCK=n?
>
> -Len
>
Can either Pavel or Andreas please try this little debugging patch and
send me the dmesg output? Please enable the CONFIG_DEBUG_KERNEL option
in your .config as well so that I can get additional info.
Len (or anyone),
I had a theory that perhaps I'm having a race condition between the two
drivers, however, I'm not sure if this is even a possibility at boot
time, so I wanted to run this theory by you and see if you thought it
could happen.
The dock driver calls acpi_walk_namespace to check for _DCK method.
When it finds it, it allocates a struct dock_station, and then calls
acpi_walk_namespace again to find all the dependent devices. This is
all done as part of the dock driver's init.
When acpiphp driver is called, it also calls acpi_walk_namespace to
check for pci devices dependent on the dock station. It calls a
function exported from the dock driver (is_dock_device) to determine
this. is_dock_device should only be called *after* the dock driver is
finished it's init, because the driver *must* have completed it's search
for dependent devices before it can answer the question
is_dock_device()?.
My understanding is that if your init routine is marked with the
module_init() macro, then all module init routines will be serialized
with respect to each other. i.e., Can I expect that the function
indicated by module_init() would be completed before the function marked
by acpiphp's module_init() would be called? How does the use of
acpi_walk_namespace affect serialization of the module_init? Does it
allow the possibility that the acpiphp driver may enter it's module_init
before the dock driver has completed it's init?
Thanks,
Kristen
---
drivers/acpi/dock.c | 4 ++++
1 file changed, 4 insertions(+)
--- 2.6-mm.orig/drivers/acpi/dock.c
+++ 2.6-mm/drivers/acpi/dock.c
@@ -190,6 +190,10 @@ static int is_dock(acpi_handle handle)
*/
int is_dock_device(acpi_handle handle)
{
+ if (!dock_station) {
+ printk(KERN_ERR "Dock station not done being initialized!!!\n");
+ return 0;
+ }
if (is_dock(handle) || find_dock_dependent_device(dock_station, handle))
return 1;
On P? 26-05-06 00:12:22, Pavel Machek wrote:
> Hi!
>
> > > Does the panic go away with CONFIG_ACPI_DOCK=n?
>
> > Can either Pavel or Andreas please try this little debugging patch and
> > send me the dmesg output? Please enable the CONFIG_DEBUG_KERNEL option
> > in your .config as well so that I can get additional info.
>
> Yep, you were right... this debugging patch helps.
...and docking +/- works, but it does not look like PCI in docking
station is properly connected:
May 26 00:13:25 amd log1n[1450]: ROOT LOGIN on `tty8'
May 26 00:13:27 amd kernel: ipw2200: version magic
'2.6.17-rc4-g81a95636-dirty SMP mod_unload PENTIUMIII REGPARM gcc-4.0'
should be '2.6.17-rc4-mm3 SMP preempt mod_unload PENTIUMIII REGPARM
gcc-4.0'
May 26 00:13:28 amd postfix/postfix-script: fatal: the Postfix mail
system is already running
May 26 00:13:57 amd kernel: ACPI Exception (acpi_bus-0070):
AE_NOT_FOUND, No context for object [f7fdc3d8] [20060310]
May 26 00:13:57 amd kernel: ACPI: docking
May 26 00:13:57 amd kernel: ACPI Exception (acpi_bus-0070):
AE_NOT_FOUND, No context for object [f7fdc3d8] [20060310]
(and that is it; I'd expect messages about detecting hp100 etc...)
I think my configuration is okay:
#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
CONFIG_HOTPLUG_PCI_IBM=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=y
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > Does the panic go away with CONFIG_ACPI_DOCK=n?
> Can either Pavel or Andreas please try this little debugging patch and
> send me the dmesg output? Please enable the CONFIG_DEBUG_KERNEL option
> in your .config as well so that I can get additional info.
Yep, you were right... this debugging patch helps.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, 2006-05-26 at 00:17 +0200, Pavel Machek wrote:
> On Pá 26-05-06 00:12:22, Pavel Machek wrote:
> > Hi!
> >
> > > > Does the panic go away with CONFIG_ACPI_DOCK=n?
> >
> > > Can either Pavel or Andreas please try this little debugging patch and
> > > send me the dmesg output? Please enable the CONFIG_DEBUG_KERNEL option
> > > in your .config as well so that I can get additional info.
> >
> > Yep, you were right... this debugging patch helps.
>
> ...and docking +/- works, but it does not look like PCI in docking
> station is properly connected:
>
No, I would not expect PCI to work properly with the debug patch -
basically all I did was prevent the oops and confirm that this is the
issue, I did not actually solve the problem.
I need some way to prevent acpiphp from loading before dock is completed
it's init.
I guess I will think about this some more.
Kristen
On Čt 25-05-06 17:04:18, Kristen Accardi wrote:
> On Fri, 2006-05-26 at 00:17 +0200, Pavel Machek wrote:
> > On Pá 26-05-06 00:12:22, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > Does the panic go away with CONFIG_ACPI_DOCK=n?
> > >
> > > > Can either Pavel or Andreas please try this little debugging patch and
> > > > send me the dmesg output? Please enable the CONFIG_DEBUG_KERNEL option
> > > > in your .config as well so that I can get additional info.
> > >
> > > Yep, you were right... this debugging patch helps.
> >
> > ...and docking +/- works, but it does not look like PCI in docking
> > station is properly connected:
> >
>
> No, I would not expect PCI to work properly with the debug patch -
> basically all I did was prevent the oops and confirm that this is the
> issue, I did not actually solve the problem.
>
> I need some way to prevent acpiphp from loading before dock is completed
> it's init.
>
> I guess I will think about this some more.
Using different _init levels? Like putting dock at subsys_initcall()
while acpiphp at late_initcall()?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, 2006-05-26 at 09:15 +0200, Pavel Machek wrote:
> On Čt 25-05-06 17:04:18, Kristen Accardi wrote:
> > On Fri, 2006-05-26 at 00:17 +0200, Pavel Machek wrote:
> > > On Pá 26-05-06 00:12:22, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > Does the panic go away with CONFIG_ACPI_DOCK=n?
> > > >
> > > > > Can either Pavel or Andreas please try this little debugging patch and
> > > > > send me the dmesg output? Please enable the CONFIG_DEBUG_KERNEL option
> > > > > in your .config as well so that I can get additional info.
> > > >
> > > > Yep, you were right... this debugging patch helps.
> > >
> > > ...and docking +/- works, but it does not look like PCI in docking
> > > station is properly connected:
> > >
> >
> > No, I would not expect PCI to work properly with the debug patch -
> > basically all I did was prevent the oops and confirm that this is the
> > issue, I did not actually solve the problem.
> >
> > I need some way to prevent acpiphp from loading before dock is completed
> > it's init.
> >
> > I guess I will think about this some more.
>
> Using different _init levels? Like putting dock at subsys_initcall()
> while acpiphp at late_initcall()?
> Pavel
Can you see if this works for you? Revert the first debug patch I sent
and apply this one instead (against -mm).
Thanks,
Kristen
---
drivers/acpi/dock.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- 2.6-mm.orig/drivers/acpi/dock.c
+++ 2.6-mm/drivers/acpi/dock.c
@@ -190,6 +190,9 @@ static int is_dock(acpi_handle handle)
*/
int is_dock_device(acpi_handle handle)
{
+ if (!dock_station)
+ return 0;
+
if (is_dock(handle) || find_dock_dependent_device(dock_station, handle))
return 1;
@@ -674,5 +677,5 @@ static void __exit dock_exit(void)
dock_remove();
}
-module_init(dock_init);
+postcore_initcall(dock_init);
module_exit(dock_exit);
Hi!
> > > No, I would not expect PCI to work properly with the debug patch -
> > > basically all I did was prevent the oops and confirm that this is the
> > > issue, I did not actually solve the problem.
> > >
> > > I need some way to prevent acpiphp from loading before dock is completed
> > > it's init.
> > >
> > > I guess I will think about this some more.
> >
> > Using different _init levels? Like putting dock at subsys_initcall()
> > while acpiphp at late_initcall()?
> > Pavel
>
> Can you see if this works for you? Revert the first debug patch I sent
> and apply this one instead (against -mm).
Tried it in
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
EXTRAVERSION =-rc4-mm3
...and now kernel hangs, last messages being:
pci_hotplug: ... core version: 0.5
ibmphpd: ... 0.6
acpiphp: ... 0.5
acpiphp: Slot [1] registered
I tried hitting magic sysrq, but it did not seem to respond.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html