For the message /proc/device-tree: can't find root
KERN_WARNING seems to be more appropriate than KERN_ERR. (Main benefit of the KERN_WARNING level is that Fedora's plymouth bootsplash should now hide it.)
Signed-off-by: Paul Bolle pebolle@tiscali.nl --- fs/proc/proc_devtree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c index d9396a4..71dd779 100644 --- a/fs/proc/proc_devtree.c +++ b/fs/proc/proc_devtree.c @@ -233,7 +233,7 @@ void __init proc_device_tree_init(void) return; root = of_find_node_by_path("/"); if (root == NULL) { - printk(KERN_ERR "/proc/device-tree: can't find root\n"); + printk(KERN_WARNING "/proc/device-tree: can't find root\n"); return; } proc_device_tree_add_node(root, proc_device_tree);
On Thu, Feb 3, 2011 at 5:07 PM, Paul Bolle pebolle@tiscali.nl wrote:
For the message /proc/device-tree: can't find root
KERN_WARNING seems to be more appropriate than KERN_ERR. (Main benefit of the KERN_WARNING level is that Fedora's plymouth bootsplash should now hide it.)
Signed-off-by: Paul Bolle pebolle@tiscali.nl
fs/proc/proc_devtree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c index d9396a4..71dd779 100644 --- a/fs/proc/proc_devtree.c +++ b/fs/proc/proc_devtree.c @@ -233,7 +233,7 @@ void __init proc_device_tree_init(void) return; root = of_find_node_by_path("/"); if (root == NULL) {
- printk(KERN_ERR "/proc/device-tree: can't find root\n");
- printk(KERN_WARNING "/proc/device-tree: can't find root\n");
return;
You should only see this if you are running on a machine that has an OpenFirmware style device tree and CONFIG_OF and CONFIG_PROC_DEVICETREE are set. Given the other patches in your set, I don't think you are running on a PowerPC machine. Unless you have an OLPC, then your config is just adding bloat. (And if you do have an OLPC, that would be odd anyway.)
On machines where this is supposed to be used, it likely is an error.
That being said, you can send this patch to the devicetree-discuss mailing list on list.ozlabs.org for further feedback.
josh
On Thu, Feb 03, 2011 at 09:31:40PM -0500, Josh Boyer wrote:
You should only see this if you are running on a machine that has an OpenFirmware style device tree and CONFIG_OF and CONFIG_PROC_DEVICETREE are set. Given the other patches in your set, I don't think you are running on a PowerPC machine. Unless you have an OLPC, then your config is just adding bloat. (And if you do have an OLPC, that would be odd anyway.)
On machines where this is supposed to be used, it likely is an error.
That being said, you can send this patch to the devicetree-discuss mailing list on list.ozlabs.org for further feedback.
The OLPC config options seem to have mutated, but at any rate, if people are (still) running Fedora on OLPC, then we need to continue with this.
--Kyle
On Thu, Feb 3, 2011 at 9:33 PM, Kyle McMartin kyle@mcmartin.ca wrote:
On Thu, Feb 03, 2011 at 09:31:40PM -0500, Josh Boyer wrote:
You should only see this if you are running on a machine that has an OpenFirmware style device tree and CONFIG_OF and CONFIG_PROC_DEVICETREE are set. Given the other patches in your set, I don't think you are running on a PowerPC machine. Unless you have an OLPC, then your config is just adding bloat. (And if you do have an OLPC, that would be odd anyway.)
On machines where this is supposed to be used, it likely is an error.
That being said, you can send this patch to the devicetree-discuss mailing list on list.ozlabs.org for further feedback.
The OLPC config options seem to have mutated, but at any rate, if people are (still) running Fedora on OLPC, then we need to continue with this.
Paul didn't really give any indication what kernel he was running or what config he was using. I see the latest rawhide kernel has those options set because of selects done on CONFIG_OLPC. That's somewhat unfortunate. Still, devicetree-discuss would be a better place to send this.
josh
On Thu, 2011-02-03 at 21:45 -0500, Josh Boyer wrote:
Paul didn't really give any indication what kernel he was running or what config he was using.
In the cover letter I mentioned i686. Full details are: $ uname -i -m -o -p -r -s -v Linux 2.6.38-0.rc2.git9.1.fc15.i686 #1 SMP Tue Feb 1 03:11:57 UTC 2011 i686 i686 i386 GNU/Linux
Ie, current rawhide, no local patches, no config changes.
I see the latest rawhide kernel has those options set because of selects done on CONFIG_OLPC.
$ grep OLPC.*= /boot/config-2.6.38-0.rc2.git9.1.fc15.i686 CONFIG_PCI_OLPC=y CONFIG_OLPC=y CONFIG_OLPC_XO1=m CONFIG_OLPC_OPENFIRMWARE=y CONFIG_OLPC_OPENFIRMWARE_DT=y CONFIG_MOUSE_PS2_OLPC=y CONFIG_BATTERY_OLPC=y
That's somewhat unfortunate. Still, devicetree-discuss would be a better place to send this.
But wouldn't I there simply get told to disable these OLPC options on non-OLPC hardware?
Paul
On Fri, Feb 4, 2011 at 3:09 AM, Paul Bolle pebolle@tiscali.nl wrote:
On Thu, 2011-02-03 at 21:45 -0500, Josh Boyer wrote:
Paul didn't really give any indication what kernel he was running or what config he was using.
In the cover letter I mentioned i686. Full details are: $ uname -i -m -o -p -r -s -v Linux 2.6.38-0.rc2.git9.1.fc15.i686 #1 SMP Tue Feb 1 03:11:57 UTC 2011 i686 i686 i386 GNU/Linux
Ie, current rawhide, no local patches, no config changes.
I see the latest rawhide kernel has those options set because of selects done on CONFIG_OLPC.
$ grep OLPC.*= /boot/config-2.6.38-0.rc2.git9.1.fc15.i686 CONFIG_PCI_OLPC=y CONFIG_OLPC=y CONFIG_OLPC_XO1=m CONFIG_OLPC_OPENFIRMWARE=y CONFIG_OLPC_OPENFIRMWARE_DT=y CONFIG_MOUSE_PS2_OLPC=y CONFIG_BATTERY_OLPC=y
That's somewhat unfortunate. Still, devicetree-discuss would be a better place to send this.
But wouldn't I there simply get told to disable these OLPC options on non-OLPC hardware?
If you explain the situation fully, maybe not. Grant Likely drives a lot of the work in that area and is rather reasonable in my opinion. Perhaps if you expand the changelog in the patch to point out that distro kernels will turn those options on even though most x86 machines aren't OLPC, a reduction to a KERN_WARN would be ok.
You never really know until you try.
josh
kernel@lists.fedoraproject.org
-
Josh Boyer -
Kyle McMartin -
Paul Bolle