Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due to commit 15863ff3b (powerpc: Make chip-id information available to userspace).
Not surprising, as cpu_to_chip_id() is not exported.
Reverting this commit fixes the problem. Any good idea how to fix it for real ?
Guenter
On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> Hi all,
>
> powerpc allmodconfig build on the latest upstream kernel results in:
>
> ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
>
> This is due to commit 15863ff3b (powerpc: Make chip-id information
> available to userspace).
> Not surprising, as cpu_to_chip_id() is not exported.
>
Apart from the above error, I have a concern on the patch, purely based on the commit message.
(to be honest, I am not familiar with the ppc architecture)
Commit message of 15863ff3b has the following text.
******************
So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
was always default (-1) on ppc64 architecture.
Now, some systems have an ibm,chip-id property in the cpu nodes in
the device tree. On these systems, we now use this information to
display physical_package_id
******************
Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property?
> Reverting this commit fixes the problem. Any good idea how to fix it
> for real ?
>
> Guenter
> --
> 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/
On 09/09/2013 04:55 PM, Asai Thambi S P wrote:
> On 09/08/2013 5:28 PM, Guenter Roeck wrote:
>> Hi all,
>>
>> powerpc allmodconfig build on the latest upstream kernel results in:
>>
>> ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
>>
>> This is due to commit 15863ff3b (powerpc: Make chip-id information available to userspace).
>> Not surprising, as cpu_to_chip_id() is not exported.
>>
> Apart from the above error, I have a concern on the patch, purely based on the commit message.
> (to be honest, I am not familiar with the ppc architecture)
>
> Commit message of 15863ff3b has the following text.
>
> ******************
> So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
> was always default (-1) on ppc64 architecture.
>
> Now, some systems have an ibm,chip-id property in the cpu nodes in
> the device tree. On these systems, we now use this information to
> display physical_package_id
> ******************
>
> Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property?
>
Looking into the code, I think that is what it does. For other platforms
(ie if there is no ibm,chip-id property) it still returns -1.
Question for the fix is what path to take to fix the problem.
Exporting cpu_to_chip_id() might be the easiest solution. Other
platforms export the respective data, so it should not be a problem.
I might submit a patch and see where it goes.
Guenter
>
>> Reverting this commit fixes the problem. Any good idea how to fix it for real ?
>>
>> Guenter
>> --
>> 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/
>
>
>
On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
> On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> > Hi all,
> >
> > powerpc allmodconfig build on the latest upstream kernel results in:
> >
> > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> >
> > This is due to commit 15863ff3b (powerpc: Make chip-id information
> > available to userspace).
> > Not surprising, as cpu_to_chip_id() is not exported.
> >
> Apart from the above error, I have a concern on the patch, purely based on the commit message.
> (to be honest, I am not familiar with the ppc architecture)
>
> Commit message of 15863ff3b has the following text.
>
> ******************
> So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
> was always default (-1) on ppc64 architecture.
>
> Now, some systems have an ibm,chip-id property in the cpu nodes in
> the device tree. On these systems, we now use this information to
> display physical_package_id
> ******************
>
> Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property?
There should be no negative side effect (appart from the missing
EXPORT_SYMBOL of course). If the property is not found in the
device-tree, the new function returns -1, so it should work fine on all
systems.
Cheers,
Ben.
>
> > Reverting this commit fixes the problem. Any good idea how to fix it
> > for real ?
> >
> > Guenter
> > --
> > 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/
On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
> > On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> > > Hi all,
> > >
> > > powerpc allmodconfig build on the latest upstream kernel results in:
> > >
> > > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> > >
> > > This is due to commit 15863ff3b (powerpc: Make chip-id information
> > > available to userspace).
> > > Not surprising, as cpu_to_chip_id() is not exported.
> > >
> > Apart from the above error, I have a concern on the patch, purely based on the commit message.
> > (to be honest, I am not familiar with the ppc architecture)
> >
> > Commit message of 15863ff3b has the following text.
> >
> > ******************
> > So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
> > was always default (-1) on ppc64 architecture.
> >
> > Now, some systems have an ibm,chip-id property in the cpu nodes in
> > the device tree. On these systems, we now use this information to
> > display physical_package_id
> > ******************
> >
> > Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property?
>
> There should be no negative side effect (appart from the missing
> EXPORT_SYMBOL of course). If the property is not found in the
> device-tree, the new function returns -1, so it should work fine on all
> systems.
>
Good. I submitted a patch doing just that yesterday or so.
Hope you'll accept it ;).
Thanks,
Guenter
On 09/11/2013 04:20 AM, Guenter Roeck wrote:
> On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
>>> On 09/08/2013 5:28 PM, Guenter Roeck wrote:
>>>> Hi all,
>>>>
Guenter, Ben,
Sorry for the inconvenience. I never realized my patch could break somewhere :-(
Thanks you very much for identifying and fixing this issue. Other patch looks
good to me.
-Vasant
>>>> powerpc allmodconfig build on the latest upstream kernel results in:
>>>>
>>>> ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
>>>>
>>>> This is due to commit 15863ff3b (powerpc: Make chip-id information
>>>> available to userspace).
>>>> Not surprising, as cpu_to_chip_id() is not exported.
>>>>
>>> Apart from the above error, I have a concern on the patch, purely based on the commit message.
>>> (to be honest, I am not familiar with the ppc architecture)
>>>
>>> Commit message of 15863ff3b has the following text.
>>>
>>> ******************
>>> So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
>>> was always default (-1) on ppc64 architecture.
>>>
>>> Now, some systems have an ibm,chip-id property in the cpu nodes in
>>> the device tree. On these systems, we now use this information to
>>> display physical_package_id
>>> ******************
>>>
>>> Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property?
>>
>> There should be no negative side effect (appart from the missing
>> EXPORT_SYMBOL of course). If the property is not found in the
>> device-tree, the new function returns -1, so it should work fine on all
>> systems.
>>
> Good. I submitted a patch doing just that yesterday or so.
> Hope you'll accept it ;).
>
> Thanks,
> Guenter
> _______________________________________________
> Linuxppc-dev mailing list
> [email protected]
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>