2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

[Miles Lane]

drivers/built-in.o: In function
`is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined
reference to `is_dock_device'
drivers/built-in.o: In function
`cleanup_bridge':acpiphp_glue.c:(.text+0x12bc4): undefined reference
to `is_dock_device'
:acpiphp_glue.c:(.text+0x12bd3): undefined reference to
`unregister_hotplug_dock_device'
:acpiphp_glue.c:(.text+0x12bdb): undefined reference to
`unregister_dock_notifier'
drivers/built-in.o: In function
`register_slot':acpiphp_glue.c:(.text+0x13ac0): undefined reference to
`is_dock_device'
:acpiphp_glue.c:(.text+0x13cd9): undefined reference to `is_dock_device'
:acpiphp_glue.c:(.text+0x13cf0): undefined reference to
`register_hotplug_dock_device'
:acpiphp_glue.c:(.text+0x13d1d): undefined reference to `register_dock_notifier'
make: *** [.tmp_vmlinux1] Error 1

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_FAKE=y
CONFIG_HOTPLUG_PCI_COMPAQ=y
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=y
CONFIG_HOTPLUG_PCI_CPCI=y
# CONFIG_HOTPLUG_PCI_CPCI_ZT5550 is not set
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=y
CONFIG_HOTPLUG_PCI_SHPC=y
# CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set

Re: 2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

[Adrian Bunk]

On Sun, Jun 25, 2006 at 12:56:44PM -0700, Miles Lane wrote:
> drivers/built-in.o: In function
> `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined
> reference to `is_dock_device'
> drivers/built-in.o: In function
> `cleanup_bridge':acpiphp_glue.c:(.text+0x12bc4): undefined reference
> to `is_dock_device'
> :acpiphp_glue.c:(.text+0x12bd3): undefined reference to
> `unregister_hotplug_dock_device'
> :acpiphp_glue.c:(.text+0x12bdb): undefined reference to
> `unregister_dock_notifier'
> drivers/built-in.o: In function
> `register_slot':acpiphp_glue.c:(.text+0x13ac0): undefined reference to
> `is_dock_device'
> :acpiphp_glue.c:(.text+0x13cd9): undefined reference to `is_dock_device'
> :acpiphp_glue.c:(.text+0x13cf0): undefined reference to
> `register_hotplug_dock_device'
> :acpiphp_glue.c:(.text+0x13d1d): undefined reference to 
> `register_dock_notifier'
> make: *** [.tmp_vmlinux1] Error 1
> 
> #
> # PCI Hotplug Support
> #
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_FAKE=y
> CONFIG_HOTPLUG_PCI_COMPAQ=y
> # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
> CONFIG_HOTPLUG_PCI_ACPI=y
> CONFIG_HOTPLUG_PCI_ACPI_IBM=y
> CONFIG_HOTPLUG_PCI_CPCI=y
> # CONFIG_HOTPLUG_PCI_CPCI_ZT5550 is not set
> CONFIG_HOTPLUG_PCI_CPCI_GENERIC=y
> CONFIG_HOTPLUG_PCI_SHPC=y
> # CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set


You hadn't attached your complete .config, but is it correct when I 
assume you have CONFIG_ACPI_DOCK=m? This would explain the problem.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

[Miles Lane]

Should I attach my entire .config file in the future?  It's large enough that
I try to trim it to avoid bloating people's inboxes.

Yes, that's right.  It is compiled as a module.  So this just needs
a tweaked config rule, right?

Thanks,
         Miles

On 6/25/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Sun, Jun 25, 2006 at 12:56:44PM -0700, Miles Lane wrote:
> > drivers/built-in.o: In function
> > `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined
> > reference to `is_dock_device'
> > drivers/built-in.o: In function
> > `cleanup_bridge':acpiphp_glue.c:(.text+0x12bc4): undefined reference
> > to `is_dock_device'
> > :acpiphp_glue.c:(.text+0x12bd3): undefined reference to
> > `unregister_hotplug_dock_device'
> > :acpiphp_glue.c:(.text+0x12bdb): undefined reference to
> > `unregister_dock_notifier'
> > drivers/built-in.o: In function
> > `register_slot':acpiphp_glue.c:(.text+0x13ac0): undefined reference to
> > `is_dock_device'
> > :acpiphp_glue.c:(.text+0x13cd9): undefined reference to `is_dock_device'
> > :acpiphp_glue.c:(.text+0x13cf0): undefined reference to
> > `register_hotplug_dock_device'
> > :acpiphp_glue.c:(.text+0x13d1d): undefined reference to
> > `register_dock_notifier'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > #
> > # PCI Hotplug Support
> > #
> > CONFIG_HOTPLUG_PCI=y
> > CONFIG_HOTPLUG_PCI_FAKE=y
> > CONFIG_HOTPLUG_PCI_COMPAQ=y
> > # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
> > CONFIG_HOTPLUG_PCI_ACPI=y
> > CONFIG_HOTPLUG_PCI_ACPI_IBM=y
> > CONFIG_HOTPLUG_PCI_CPCI=y
> > # CONFIG_HOTPLUG_PCI_CPCI_ZT5550 is not set
> > CONFIG_HOTPLUG_PCI_CPCI_GENERIC=y
> > CONFIG_HOTPLUG_PCI_SHPC=y
> > # CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set
>
>
> You hadn't attached your complete .config, but is it correct when I
> assume you have CONFIG_ACPI_DOCK=m? This would explain the problem.
>
>
> cu
> Adrian
>
> --
>
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
>
>

Re: 2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

[Adrian Bunk]

On Sun, Jun 25, 2006 at 01:13:04PM -0700, Miles Lane wrote:

> Should I attach my entire .config file in the future?  It's large enough 
> that
> I try to trim it to avoid bloating people's inboxes.

I'm often trying to reproduce compile errors, and it's always a pain in 
the ass when I have to construct a complete .config based on such a 
fragment instead of simply using the complete .config of the reporter.

And people for whom a few kB would matter wouldn't subscribe to 
linux-kernel...

> Yes, that's right.  It is compiled as a module.  So this just needs
> a tweaked config rule, right?

It would be a solution to let HOTPLUG_PCI_ACPI depend on
(ACPI_DOCK || ACPI_DOCK=n), or the #if in 
include/acpi/acpi_drivers.h could be changed to
#if defined(CONFIG_ACPI_DOCK) || (defined(CONFIG_ACPI_DOCK_MODULE) && defined(MODULE))

Which one suits better the intention is better is a question Kristen has 
to answer.

> Thanks,
>         Miles

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

ACPI_DOCK bug: noone cares

[Adrian Bunk]

On Sun, Jun 25, 2006 at 10:40:39PM +0200, Adrian Bunk wrote:
> On Sun, Jun 25, 2006 at 01:13:04PM -0700, Miles Lane wrote:
> 
> > Should I attach my entire .config file in the future?  It's large enough 
> > that
> > I try to trim it to avoid bloating people's inboxes.
> 
> I'm often trying to reproduce compile errors, and it's always a pain in 
> the ass when I have to construct a complete .config based on such a 
> fragment instead of simply using the complete .config of the reporter.
> 
> And people for whom a few kB would matter wouldn't subscribe to 
> linux-kernel...
> 
> > Yes, that's right.  It is compiled as a module.  So this just needs
> > a tweaked config rule, right?
> 
> It would be a solution to let HOTPLUG_PCI_ACPI depend on
> (ACPI_DOCK || ACPI_DOCK=n), or the #if in 
> include/acpi/acpi_drivers.h could be changed to
> #if defined(CONFIG_ACPI_DOCK) || (defined(CONFIG_ACPI_DOCK_MODULE) && defined(MODULE))
> 
> Which one suits better the intention is better is a question Kristen has 
> to answer.


Two weeks ago, we had:
- a bug report
- a detailed description how to possibly fix this issue

What we did NOT have was:
- any reaction by the patch author or any maintainer
  (although with the exception of Linus, the recipients of the problem
   description were exactly the same as the ones in this email)

A few days later, the patch that includes this bug was included in 
Linus' tree.

Two weeks later, the bug is still present in both latest -mm and Linus' 
tree.

Linus, please do a
  git-revert a5e1b94008f2a96abf4a0c0371a55a56b320c13e

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: ACPI_DOCK bug: noone cares

[Linus Torvalds]

On Sun, 9 Jul 2006, Adrian Bunk wrote:
> 
> Two weeks ago, we had:
> - a bug report
> - a detailed description how to possibly fix this issue
> 
> What we did NOT have was:
> - any reaction by the patch author or any maintainer
>   (although with the exception of Linus, the recipients of the problem
>    description were exactly the same as the ones in this email)
> 
> A few days later, the patch that includes this bug was included in 
> Linus' tree.
> 
> Two weeks later, the bug is still present in both latest -mm and Linus' 
> tree.
> 
> Linus, please do a
>   git-revert a5e1b94008f2a96abf4a0c0371a55a56b320c13e

Fair enough. Reverted.

I think I'll stop accepting any ACPI patches at all that add new features, 
as long as there doesn't seem to be anybody who reacts to bug-reports. We 
don't need ACPI features.

We need somebody who answers when people like Andrew asks about patches to 
support things like memory hotplug (which was also a problem over the last 
weeks). Here's a quote from Andrew from a week or so ago: "repeat seven 
times over three months with zero response.".

It's not worth it to accept new stuff if we know it's not going to get any 
attention ever afterwards.

			Linus

Re: 2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

[Keith Owens]

"Miles Lane" (on Sun, 25 Jun 2006 13:13:04 -0700) wrote:
>Should I attach my entire .config file in the future?  It's large enough that
>I try to trim it to avoid bloating people's inboxes.

Mail the result of

  sed -ne 's/^CONFIG_//p' .config

That is typically less than 40% of the full .config size, and it can be
fully regenerated by

  yes '' | make oldconfig

Re: 2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

[Keith Owens]

Keith Owens (on Mon, 26 Jun 2006 15:56:49 +1000) wrote:
>"Miles Lane" (on Sun, 25 Jun 2006 13:13:04 -0700) wrote:
>>Should I attach my entire .config file in the future?  It's large enough that
>>I try to trim it to avoid bloating people's inboxes.
>
>Mail the result of
>
>  sed -ne 's/^CONFIG_//p' .config
>
>That is typically less than 40% of the full .config size, and it can be
>fully regenerated by
>
>  yes '' | make oldconfig

Sorry, that should be

  yes 'n' | make oldconfig

and it turns out that this no longer works.  It used to work with the
old config system, but Kconfig gets confused by choices if the input
.config only has the selected choice and is missing the alternates.
For example, Kconfig accepts this

  CONFIG_X86_PC=y
  # CONFIG_X86_ELAN is not set
  # CONFIG_X86_VOYAGER is not set
  # CONFIG_X86_NUMAQ is not set
  # CONFIG_X86_SUMMIT is not set
  # CONFIG_X86_BIGSMP is not set
  # CONFIG_X86_VISWS is not set
  # CONFIG_X86_GENERICARCH is not set
  # CONFIG_X86_ES7000 is not set
  # CONFIG_M386 is not set
  # CONFIG_M486 is not set
  # CONFIG_M586 is not set
  # CONFIG_M586TSC is not set
  # CONFIG_M586MMX is not set

But will not accept CONFIG_X86_PC=y on its own.  Kconfig insists that
you manually select an option, even though only one valid option has
already been selected.  IOW, .config lines that are commented out
sometimes mean something to Kconfig :(

Re: 2.6.17-mm2 -- drivers/built-in.o: In function `is_pci_dock_device':acpiphp_glue.c:(.text+0x12364): undefined reference to `is_dock_device'

[Roman Zippel]

Hi,

On Mon, 26 Jun 2006, Keith Owens wrote:

> and it turns out that this no longer works.  It used to work with the
> old config system, but Kconfig gets confused by choices if the input
> .config only has the selected choice and is missing the alternates.
> For example, Kconfig accepts this

Choices are not so much the problem, the problems are default. Once the 
setting is gone, it will fall back to the default, which is not always 
'n'.

bye, Roman

RE: ACPI_DOCK bug: noone cares

[Brown, Len]

>> Two weeks ago, we had:
>> - a bug report
>> - a detailed description how to possibly fix this issue
>> 
>> What we did NOT have was:
>> - any reaction by the patch author or any maintainer
>>   (although with the exception of Linus, the recipients of 
>the problem
>>    description were exactly the same as the ones in this email)

Yes, I'm on this list.
No, I don't see all patches or comments unless they get sent directly
to: or cc: to me.

>> A few days later, the patch that includes this bug was included in 
>> Linus' tree.
>> 
>> Two weeks later, the bug is still present in both latest -mm 
>and Linus' 
>> tree.
>> 
>> Linus, please do a
>>   git-revert a5e1b94008f2a96abf4a0c0371a55a56b320c13e
>
>Fair enough. Reverted.

I disagree with this decision, and would like to know what
is necessary to reverse it.

>I think I'll stop accepting any ACPI patches at all that add 
>new features, as long as there doesn't seem to be anybody who reacts to

>bug-reports. We  don't need ACPI features.

If it is a requirement that I see every patch sent to the list
and not directly to me during weekends in July, then I agree
with your decision -- because I can't give you that level of service.
But surely:

1. You can e-mail me directly when you are asking me to do something.
2. deleting the driver is a somewhat Draconian response to what appears
 to be a simple Kconfig issue in rc1.

>We need somebody who answers when people like Andrew asks 
>about patches to support things like memory hotplug (which was also a
problem 
>over the last weeks). Here's a quote from Andrew from a week or so ago:

>"repeat seven times over three months with zero response.".

The memhotplug patches first hit the list March 21st -- the 1st day of
the 2.6.17 integration window.

I would have queued them for 2.6.18-rc1, but they depended
on other patches in -mm that Andrew did not send me.

Yes, I Should have mentioned that to Andrew, and acked
the patches so he could have sorted that out.

However, the only way they could have got into 2.6.18-rc1 any
earlier would be if the 2.6.17 cycle were shorter.

>It's not worth it to accept new stuff if we know it's not 
>going to get any attention ever afterwards.

If you address me directly when you are asking me to do something,
that would really help me help you.

thanks,
-Len

RE: ACPI_DOCK bug: noone cares

[Linus Torvalds]

On Sun, 9 Jul 2006, Brown, Len wrote:
> >
> >Fair enough. Reverted.
> 
> I disagree with this decision, and would like to know what
> is necessary to reverse it.

Mistakes happen. Fair enough. They happen all the time. This time around, 
for the 2.6.18-rc1 thing, I had heard more than the usual "nobody even 
reacted", as Andrew had held up two patch-series of his because of that 
issue..

So that makes me like it even less than usual when I'm told that a problem 
with something I merged was apparently known BEFORE IT WAS MERGED.

So Adrian's report on its own wouldn't have caused a revert. 

> If you address me directly when you are asking me to do something,
> that would really help me help you.

As far as I can tell, you were cc'd on all of these things, along with 
the linux-acpi mailing list.

			Linus

RE: ACPI_DOCK bug: noone cares

[Brown, Len]

 
>If you address me directly when you are asking me to do something,
>that would really help me help you.

oops, I see you did this -- looks like I've got some snags in my mail
sorter.

-Len

RE: ACPI_DOCK bug: noone cares

[Brown, Len]

>> >Fair enough. Reverted.
>> 
>> I disagree with this decision, and would like to know what
>> is necessary to reverse it.
>
>Mistakes happen. Fair enough. They happen all the time. This 
>time around, for the 2.6.18-rc1 thing, I had heard more than
>the usual "nobody even reacted", as Andrew had held up two
>patch-series of his because of that issue..

Dependencies happen too, and that was the case with the memhotplug
patches.  Memhotplug, PCI-hotplug, docking -- these things all
have dependencies between multiple sub-systems, and we don't
really have a good process for making things flow smoothly.
Andrew has set himself up to be the clearing house, and he is
so successful that I think that sometimes we tend to
over-use him for that purpose.

>So that makes me like it even less than usual when I'm told 
>that a problem with something I merged was apparently known
>BEFORE IT WAS MERGED.
>
>So Adrian's report on its own wouldn't have caused a revert. 
>
>> If you address me directly when you are asking me to do something,
>> that would really help me help you.
>
>As far as I can tell, you were cc'd on all of these things, along with 
>the linux-acpi mailing list.

Yes, you are right, I was cc'd.  My inbox knew about this issue
and I hadn't noticed it.  It was my mistake to assume a few days later
that the latest driver needed a patch.

So I ask you.  If I fix the Kconfig issue today, will you accept
a push that restores this driver to 2.6.18?

thanks,
-Len

RE: ACPI_DOCK bug: noone cares

[Linus Torvalds]

On Sun, 9 Jul 2006, Brown, Len wrote:
> 
> So I ask you.  If I fix the Kconfig issue today, will you accept
> a push that restores this driver to 2.6.18?

Sure.

		Linus

Re: ACPI_DOCK bug: noone cares

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Hi.

On Monday 10 July 2006 08:38, Linus Torvalds wrote:
> On Sun, 9 Jul 2006, Brown, Len wrote:
> > So I ask you.  If I fix the Kconfig issue today, will you accept
> > a push that restores this driver to 2.6.18?
>
> Sure.

Great! Sorry Linus from me too - I've been assigned to watch this for Redhat 
and completely missed the feedback as well. We have an open bug that we're 
hoping it will fix, and would like to see it in vanilla.

Regards,

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]