"of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer get console / kernel messages output on the hdmi output of my ARM board / on tty0
This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
Reverting this commit fixes this for me.
What is happening here is that the "add_preferred_console("stdout-path", 0, NULL);" happens before the tty0 registers stopping tty0 from becoming part of the console list since there already is a preferred console at that time.
This is an undesirable behavior change caused by the commit in question, on boards where there is both video output, and a serial console configured through stdout-path we want to have console output on both as we do not know which of the 2 will actually be hooked up by the user.
Regards,
Hans
Hi Hans,
Quoted 10 lines · Hans de Goede
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer get console / kernel messages output on the hdmi output of my ARM board / on tty0
This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51dReverting this commit fixes this for me.
Quoted 8 lines
What is happening here is that the "
add_preferred_console("stdout-path", 0, NULL);" happens before the tty0 registers stopping tty0 from becoming part of the console list since there already is a preferred console at that time.This is an undesirable behavior change caused by the commit in question, on boards where there is both video output, and a serial console configured through stdout-path we want to have console output on both as we do not know which of the 2 will actually be hooked up by the user.
I don't see this as a regression, but rather a misconfiguration.
1. Your DT indicates the stdout device is a serial console; that is the expected outcome. Here's what ePAPR has to say on the chosen/stdout-path property node:
"A string that specifies the full path to the node representing the device to be used for boot console output. If the character ":" is present in the value it terminates the path. The value may be an alias."
If the serial console is not the stdout device then the DT should not claim it is.
2. The tty0 console is not now, and has never been, always enabled.
The tty0 console is only enabled when either,
a) there is no other console
b) when specified on the command line (ie., "console=tty0") or by prom/dt.
Your situation is akin to adding the serial console to the command line; if "console=tty0" is not also explicitly added, there is no boot console output to tty0.
3. This same breakage will happen if any other device registers a console matching the stdout-path at console_init() time (ie, with console_initcall() macro) before the dummy console. The order in which consoles are inited via console_initcall() is dependent on link order, so essentially not controllable across different subsystems (or if there were consoles defined with the arch itself).
That said, I'll look into fixing your use-case automagically without requiring configuration changes.
Regards,
Peter Hurley
A message that is not in the archive (sent off-list or not yet received): 550717A0.3060603-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org
Hi,
Quoted 17 lines · Peter Hurley
Hi Hans,
Quoted 14 lines · Hans de Goede
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer get console / kernel messages output on the hdmi output of my ARM board / on tty0
This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51dReverting this commit fixes this for me.
What is happening here is that the "
add_preferred_console("stdout-path", 0, NULL);" happens before the tty0 registers stopping tty0 from becoming part of the console list since there already is a preferred console at that time.
Quoted 6 lines
Quoted 4 lines
This is an undesirable behavior change caused by the commit in question, on boards where there is both video output, and a serial console configured through stdout-path we want to have console output on both as we do not know which of the 2 will actually be hooked up by the user.
I don't see this as a regression, but rather a misconfiguration.
As said it is an undesirable behavior change, whether you want to call that a regression or not is not all that interesting. Fixing it however is important, as e.g. Fedora ARM images rely on this behavior, both "regular" arm as well as aarch64.
Quoted 22 lines
1. Your DT indicates the stdout device is a serial console; that is the expected outcome. Here's what ePAPR has to say on the chosen/stdout-path property node:
"A string that specifies the full path to the node representing the device to be used for boot console output. If the character ":" is present in the value it terminates the path. The value may be an alias."
If the serial console is not the stdout device then the DT should not claim it is.
2. The tty0 console is not now, and has never been, always enabled.
The tty0 console is only enabled when either,
a) there is no other console
b) when specified on the command line (ie., "console=tty0") or by prom/dt.Your situation is akin to adding the serial console to the command line; if "console=tty0" is not also explicitly added, there is no boot console output to tty0.
Quoted 8 lines
3. This same breakage will happen if any other device registers a console matching the stdout-path at
console_init()time (ie, withconsole_initcall()macro) before the dummy console. The order in which consoles are inited viaconsole_initcall()is dependent on link order, so essentially not controllable across different subsystems (or if there were consoles defined with the arch itself).That said, I'll look into fixing your use-case automagically without requiring configuration changes.
Thanks!
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 25 lines · Hans de Goede
Hi,
Quoted 22 lines · Peter Hurley
Hi Hans,
Quoted 18 lines · Hans de Goede
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer get console / kernel messages output on the hdmi output of my ARM board / on tty0
This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51dReverting this commit fixes this for me.
What is happening here is that the "
add_preferred_console("stdout-path", 0, NULL);" happens before the tty0 registers stopping tty0 from becoming part of the console list since there already is a preferred console at that time.This is an undesirable behavior change caused by the commit in question, on boards where there is both video output, and a serial console configured through stdout-path we want to have console output on both as we do not know which of the 2 will actually be hooked up by the user.
Quoted 5 lines
Quoted 1 line
I don't see this as a regression, but rather a misconfiguration.
As said it is an undesirable behavior change, whether you want to call that a regression or not is not all that interesting. Fixing it however is important, as e.g. Fedora ARM images rely on this behavior, both "regular" arm as well as aarch64.
What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 26 lines · Peter Hurley
Quoted 25 lines · Hans de Goede
Hi,
Quoted 22 lines · Peter Hurley
Hi Hans,
Quoted 18 lines · Hans de Goede
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer get console / kernel messages output on the hdmi output of my ARM board / on tty0
This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51dReverting this commit fixes this for me.
What is happening here is that the "
add_preferred_console("stdout-path", 0, NULL);" happens before the tty0 registers stopping tty0 from becoming part of the console list since there already is a preferred console at that time.This is an undesirable behavior change caused by the commit in question, on boards where there is both video output, and a serial console configured through stdout-path we want to have console output on both as we do not know which of the 2 will actually be hooked up by the user.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
I don't see this as a regression, but rather a misconfiguration.
As said it is an undesirable behavior change, whether you want to call that a regression or not is not all that interesting. Fixing it however is important, as e.g. Fedora ARM images rely on this behavior, both "regular" arm as well as aarch64.
What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?
This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, currently the setting of stdout-path on these boards is done by (an unmodified) upstream u-boot.
To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using machines, those will also output to both a serial tty and tty0 when the acpi equivalent of stdout-path is present and points to a serial tty.
Regards,
Hans
Quoted 3 lines · Hans de Goede
To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using machines, those will also output to both a serial tty and tty0 when the acpi equivalent of stdout-path is present and points to a serial tty.
I already made comments addressing the unsuitability of the license for the aarch64 acpi console; the proposed SPCR table format is patented by Microsoft and licensed incompatibly with GPLv2.
That said, the aarch64 acpi console should be treated like any other prom that starts a console and so won't suffer from this breakage.
Regards,
Peter Hurley
A message that is not in the archive (sent off-list or not yet received): 5507332B.5020504-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org
Quoted 7 lines · Peter Hurley
Quoted 3 lines · Hans de Goede
To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using machines, those will also output to both a serial tty and tty0 when the acpi equivalent of stdout-path is present and points to a serial tty.
I already made comments addressing the unsuitability of the license for the aarch64 acpi console;
Yes, you did. However, I believe you might have outdated information. Have you read the SPCR in the past few months, or are you looking at a version prior to update that was made in October of 2014?
Quoted 2 lines
the proposed SPCR table format is patented by Microsoft and licensed incompatibly with GPLv2.
Can you be specific about your concerns? The license has already been changed once (I instigated the request that lead to that change to drop several pages of terse terms that used to cover the first few pages). I have found the Microsoft team extremely responsive and amenable to resolving issues, so if you would do us the service of articulating what the concern is, I'll reach back out and get that addressed. I have a direct line into their server and legal teams to discuss this issue.
Jon.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jon,
Quoted 6 lines · Jon Masters
Quoted 5 lines · Peter Hurley
Quoted 3 lines · Hans de Goede
To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using machines, those will also output to both a serial tty and tty0 when the acpi equivalent of stdout-path is present and points to a serial tty.
Quoted 6 lines
Quoted 2 lines
I already made comments addressing the unsuitability of the license for the aarch64 acpi console;
Yes, you did. However, I believe you might have outdated information. Have you read the SPCR in the past few months, or are you looking at a version prior to update that was made in October of 2014?
The version of the Serial Port Console Redirection Table specification I was referring to is downloadable here:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132%28v=vs.85%29.aspx
That page says Last Updated: October 21, 2014
The cover page of that downloaded specification has this text:
"
Patent Notice. Microsoft provides you certain patent rights for implementations of this specification under the terms of Microsoft’s Community Promise, available at http://www.microsoft.com/openspecifications/en/us/programs/community-promise/default.aspx.
Version 1.02 — October 9, 2014
"
Quoted 10 lines
Quoted 2 lines
the proposed SPCR table format is patented by Microsoft and licensed incompatibly with GPLv2.
Can you be specific about your concerns? The license has already been changed once (I instigated the request that lead to that change to drop several pages of terse terms that used to cover the first few pages). I have found the Microsoft team extremely responsive and amenable to resolving issues, so if you would do us the service of articulating what the concern is, I'll reach back out and get that addressed. I have a direct line into their server and legal teams to discuss this issue.
Well, I'm deducing somewhat here because the code that would use the SPCR table format has not been submitted. So I don't _know_ what license(s) you intend to submit with.
But assuming you're using some part of the SPCR specification to implement the aarch64 acpi console, then my concern stems from the incompatibility between GPL v2 and the Microsoft Community Promise license.
In order for you to submit code to mainline, you (or rather, the submitter) must certify that you have the legal right to do so. That's spelled out in Documentation/SubmittingPatches, under 'Developer's Certficate of Origin 1.1'.
So if you and Microsoft have worked out some deal where Microsoft has licensed the SPCR spec to you under GPL v2 terms, then, great! there is no problem.
However, if Microsoft is licensing your use of the SPCR specification under the Microsoft Community Promise and you intend license your submission with the same, then the problem is that the Microsoft Community Promise License asserts additional limitations which are not compatible with GPL v2; specifically, this text:
[from https://msdn.microsoft.com/en-us/openspecifications/dn646766 ]
"If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you."
IOW, if I sue Microsoft for patent infringement ste,ming from their use of Microsoft XML Document Object Model Level 1 Standards Support Document (which infringes on patents I own), then my embedded aarch64 kernel - which merely contains your implementation - is no longer covered under the terms of the license.
Now, that's just my interpretation of it; maybe the Linux Foundation's lawyers would see it differently.
Regards,
Peter Hurley
A message that is not in the archive (sent off-list or not yet received): 550868AF.8050201-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org
Hi Peter,
Quoted 14 lines · Peter Hurley
Quoted 6 lines · Jon Masters
Quoted 5 lines · Peter Hurley
Quoted 3 lines · Hans de Goede
To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using machines, those will also output to both a serial tty and tty0 when the acpi equivalent of stdout-path is present and points to a serial tty.
Quoted 6 lines
Quoted 2 lines
I already made comments addressing the unsuitability of the license for the aarch64 acpi console;
Yes, you did. However, I believe you might have outdated information. Have you read the SPCR in the past few months, or are you looking at a version prior to update that was made in October of 2014?
Quoted 6 lines
The version of the Serial Port Console Redirection Table specification I was referring to is downloadable here:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132%28v=vs.85%29.aspx
That page says Last Updated: October 21, 2014
Ok. You've got the most recent version :) Let me predicate the following with the assertion that I am not a lawyer and I am not offering legal advice. But I have worked with Microsoft (and many other large hardware and software vendors) for some time on topics related to standardization of ARM and I am offering to reach back out to them to resolve any legitimate concerns arising here. The thing we need to ascertain is whether there is a legitimate concern.
Quoted 11 lines
Quoted 7 lines
Can you be specific about your concerns? The license has already been changed once (I instigated the request that lead to that change to drop several pages of terse terms that used to cover the first few pages). I have found the Microsoft team extremely responsive and amenable to resolving issues, so if you would do us the service of articulating what the concern is, I'll reach back out and get that addressed. I have a direct line into their server and legal teams to discuss this issue.
Well, I'm deducing somewhat here because the code that would use the SPCR table format has not been submitted. So I don't _know_ what license(s) you intend to submit with.
Fair enough. I wrote an initial quick and dirty implementation of SPCR parsing which I handed off to a colleague to cleanup. They are indeed planning such a submission. So such an implementation does in fact exist and there is an intent to submit. Ultimately, ACPI based ARM systems (and even x86 ones) will be better off for supporting SPCR. While not required, it does obviate the need for both "console=" and "earlycon=" kernel command line parameters, and thus improves end user experience by making console setup automatic. We decided to include SPCR in the SBBR rather than writing a new table on the understanding that writing a new table was otherwise the default, and a wasted effort when such a specification already existed. The concern you raise was anticipated, and the changes mentioned were already made. I'm sure we'll be able to ask for additional clarification and changes also.
Quoted 3 lines
So if you and Microsoft have worked out some deal where Microsoft has licensed the SPCR spec to you under GPL v2 terms, then, great! there is no problem.
I am willing to assist in brokering a discussion on this. But first we should ascertain what is necessary here and articulate that succinctly.
<snip>
Quoted 2 lines
Now, that's just my interpretation of it; maybe the Linux Foundation's lawyers would see it differently.
Who ultimately is going to make the legal call on this one? In other words, would an opinion from LF be the best thing to pursue? I can reach out and connect a few people off-list for some conversation.
Ultimately, I believe Microsoft are willing to have a productive conversation with us on these topics. I have found them very amenable and professional when collaborating on ARM related standardization topics and I am sure we can resolve any issues arising here.
Jon.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 41 lines · Jon Masters
Hi Peter,
Quoted 14 lines · Peter Hurley
Quoted 6 lines · Jon Masters
Quoted 5 lines · Peter Hurley
Quoted 3 lines · Hans de Goede
To be clear about my aarch64 remark, that relates to the behavior of aarch64 acpi using machines, those will also output to both a serial tty and tty0 when the acpi equivalent of stdout-path is present and points to a serial tty.
Quoted 6 lines
Quoted 2 lines
I already made comments addressing the unsuitability of the license for the aarch64 acpi console;
Yes, you did. However, I believe you might have outdated information. Have you read the SPCR in the past few months, or are you looking at a version prior to update that was made in October of 2014?
Quoted 6 lines
The version of the Serial Port Console Redirection Table specification I was referring to is downloadable here:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132%28v=vs.85%29.aspx
That page says Last Updated: October 21, 2014
Ok. You've got the most recent version :) Let me predicate the following with the assertion that I am not a lawyer and I am not offering legal advice. But I have worked with Microsoft (and many other large hardware and software vendors) for some time on topics related to standardization of ARM and I am offering to reach back out to them to resolve any legitimate concerns arising here. The thing we need to ascertain is whether there is a legitimate concern.
Quoted 8 lines
Quoted 7 lines
Can you be specific about your concerns? The license has already been changed once (I instigated the request that lead to that change to drop several pages of terse terms that used to cover the first few pages). I have found the Microsoft team extremely responsive and amenable to resolving issues, so if you would do us the service of articulating what the concern is, I'll reach back out and get that addressed. I have a direct line into their server and legal teams to discuss this issue.
Quoted 8 lines
Quoted 3 lines
Well, I'm deducing somewhat here because the code that would use the SPCR table format has not been submitted. So I don't _know_ what license(s) you intend to submit with.
Fair enough. I wrote an initial quick and dirty implementation of SPCR parsing which I handed off to a colleague to cleanup. They are indeed planning such a submission. So such an implementation does in fact exist and there is an intent to submit.
I assumed that because I received no reply to my first email that this effort had been abandoned, so I didn't bother to raise the technical issues that plague the devicetree hack.
Quoted 5 lines
Ultimately, ACPI based ARM systems
(and even x86 ones) will be better off for supporting SPCR. While not required, it does obviate the need for both "console=" and "earlycon=" kernel command line parameters, and thus improves end user experience by making console setup automatic.
Sure; there are several platforms/arches that already do this from proms.
Quoted 7 lines
We decided to include SPCR in the SBBR
rather than writing a new table on the understanding that writing a new table was otherwise the default, and a wasted effort when such a specification already existed. The concern you raise was anticipated, and the changes mentioned were already made. I'm sure we'll be able to ask for additional clarification and changes also.
Quoted 6 lines
Quoted 3 lines
So if you and Microsoft have worked out some deal where Microsoft has licensed the SPCR spec to you under GPL v2 terms, then, great! there is no problem.
I am willing to assist in brokering a discussion on this. But first we should ascertain what is necessary here and articulate that succinctly.
The kernel source is licensed under GPL v2 (see ./COPYING), so contributions are expected to be licensed under compatible terms.
Patent retaliation provisions are not compatible with GPL v2, because those provisions assert limitations that don't exist in GPL v2. For example, the Apache 2.0 license and the original Eclipse 1.0 license both have patent retaliation provisions that make them incompatible with GPL v2.
The Free Software Foundation maintains a list of free and non-free software licenses at http://www.gnu.org/philosophy/license-list.html with commentary on each regarding their compatibility and provisions. FSF also maintains a licensing and compliance lab which you can contact at [email protected]
The new(er) Microsoft Open Specification licenses are not reviewed on that page; contacting FSF licensing is probably the best next step.
Quoted 8 lines
<snip>
Quoted 2 lines
Now, that's just my interpretation of it; maybe the Linux Foundation's lawyers would see it differently.
Who ultimately is going to make the legal call on this one? In other words, would an opinion from LF be the best thing to pursue? I can reach out and connect a few people off-list for some conversation.
Any license outside the typical free-software licenses like GPL v2, MIT, public domain statements, etc. will face an uphill battle at submission time.
That said, there's no harm done in submitting the work and addressing these issues at that time. Either it will be accepted or it won't with an explanation of why not.
Regards,
Peter Hurley
Hi Peter,
Quoted 14 lines · Peter Hurley
Quoted 12 lines · Jon Masters
Quoted 11 lines
Quoted 7 lines
Can you be specific about your concerns? The license has already been changed once (I instigated the request that lead to that change to drop several pages of terse terms that used to cover the first few pages). I have found the Microsoft team extremely responsive and amenable to resolving issues, so if you would do us the service of articulating what the concern is, I'll reach back out and get that addressed. I have a direct line into their server and legal teams to discuss this issue.
Well, I'm deducing somewhat here because the code that would use the SPCR table format has not been submitted. So I don't _know_ what license(s) you intend to submit with.
Quoted 8 lines
Quoted 4 lines
Fair enough. I wrote an initial quick and dirty implementation of SPCR parsing which I handed off to a colleague to cleanup. They are indeed planning such a submission. So such an implementation does in fact exist and there is an intent to submit.
I assumed that because I received no reply to my first email that this effort had been abandoned, so I didn't bother to raise the technical issues that plague the devicetree hack.
I apologize for that. These patches are currently being developed against an internal tree and we'll get them posted for review.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
So if you and Microsoft have worked out some deal where Microsoft has licensed the SPCR spec to you under GPL v2 terms, then, great! there is no problem.
I am willing to assist in brokering a discussion on this. But first we should ascertain what is necessary here and articulate that succinctly.
The kernel source is licensed under GPL v2 (see ./COPYING), so contributions are expected to be licensed under compatible terms.
Just a sidenote, that this is a data structure, not code. There are plenty of other specifications and standards that the kernel uses that are licensed under a variety of terms. The specific issue seems to be the potential for conflict over the patent language in that document as possibly pertaining to implementations, not the specific license of the document per se. I'll ping a few and get a conversation going.
Jon.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Jon Masters
Just a sidenote, that this is a data structure, not code. There are plenty of other specifications and standards that the kernel uses that are licensed under a variety of terms. The specific issue seems to be the potential for conflict over the patent language in that document as possibly pertaining to implementations, not the specific license of the document per se. I'll ping a few and get a conversation going.
Strictly speaking, only the patent claim(s) are relevant.
Either,
a. your code infringes on the claim(s), in which case, the specific license
from Microsoft is required, or
b. your code does not infringe, in which case, no license is necessary.
In case (a), all of my previous email applies; ie., the terms of the license should be GPL v2 compatible.
In case (b), there is no actual problem. Yes, the patent notice in the specification is a barrier, and it would be helpful to your cause if Microsoft cited the patent numbers, but you could also just explain these in your cover letter at submission time.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 35 lines · Hans de Goede
Hi,
Quoted 32 lines · Peter Hurley
Quoted 30 lines · Hans de Goede
Hi,
Quoted 17 lines · Peter Hurley
Hi Hans,
Quoted 14 lines · Hans de Goede
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer get console / kernel messages output on the hdmi output of my ARM board / on tty0
This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51dReverting this commit fixes this for me.
What is happening here is that the "
add_preferred_console("stdout-path", 0, NULL);" happens before the tty0 registers stopping tty0 from becoming part of the console list since there already is a preferred console at that time.Quoted 6 lines
Quoted 4 lines
This is an undesirable behavior change caused by the commit in question, on boards where there is both video output, and a serial console configured through stdout-path we want to have console output on both as we do not know which of the 2 will actually be hooked up by the user.
I don't see this as a regression, but rather a misconfiguration.
As said it is an undesirable behavior change, whether you want to call that a regression or not is not all that interesting. Fixing it however is important, as e.g. Fedora ARM images rely on this behavior, both "regular" arm as well as aarch64.
Quoted 5 lines
Quoted 2 lines
What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, currently the setting of stdout-path on these boards is done by (an unmodified) upstream u-boot.
You forgot to mention my patch is not very likely to break anything in the wild since _you_ upstreamed the dependency only 3 weeks ago [1].
And what "Fedora ARM images rely on this behavior"?
I don't appreciate the deception.
Regards,
Peter Hurley
[1] git log from u-boot repo
commit f3133962f469a8b6b9ba237ba670f0ca7c88a02e
Author: Hans de Goede <[email protected]> Date: Fri Feb 20 16:55:12 2015 +0100
sunxi: Set the /chosen/stdout-path fdt property for sunxi boards
While discussing with some people how to get the Linux kernel to do the right thing wrt sending output to both the serial console and the hdmi out / lcd screen when booting on ARM devices, Grant Likely pointed out that there already is a solution for this.
All we need to do is set the /chosen/stdout-path fdt property, and if no console= arguments were specified on the kernel commandline the kernel will honor this and add this device as a console (next to the primary video output on hdmi).
And u-boot already has support for setting this, all we need to do is define OF_STDOUT_PATH and then everything will just work ootb, without people needing to meddle with adding console= arguments in extlinux.conf .
include/configs/sunxi-common.h +14 -0
@@ -210,6 +210,20 @@ extern int soft_i2c_gpio_scl;#define CONFIG_CONS_INDEX 1/* UART0 */ #endif +#if CONFIG_CONS_INDEX ==1 +#ifdef CONFIG_MACH_SUN9I +#define OF_STDOUT_PATH "/soc/serial@07000000:115200" +#else +#define OF_STDOUT_PATH "/soc@01c00000/serial@01c28000:115200" +#endif +#elif CONFIG_CONS_INDEX ==2 && defined(CONFIG_MACH_SUN5I ) +#define OF_STDOUT_PATH "/soc@01c00000/serial@01c28400:115200" +#elif CONFIG_CONS_INDEX ==5 && defined(CONFIG_MACH_SUN8I ) +#define OF_STDOUT_PATH "/soc@01c00000/serial@01f02800:115200" +#else +#error Unsupported console port nr. Please fix stdout-path in sunxi-common.h. +#endif +/* GPIO */ #define CONFIG_SUNXI_GPIO #define CONFIG_SPL_GPIO_SUPPORT
Hi,
Quoted 36 lines · Peter Hurley
Quoted 35 lines · Hans de Goede
Hi,
Quoted 32 lines · Peter Hurley
Quoted 30 lines · Hans de Goede
Hi,
Quoted 17 lines · Peter Hurley
Hi Hans,
Quoted 14 lines · Hans de Goede
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer get console / kernel messages output on the hdmi output of my ARM board / on tty0
This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51dReverting this commit fixes this for me.
What is happening here is that the "
add_preferred_console("stdout-path", 0, NULL);" happens before the tty0 registers stopping tty0 from becoming part of the console list since there already is a preferred console at that time.Quoted 6 lines
Quoted 4 lines
This is an undesirable behavior change caused by the commit in question, on boards where there is both video output, and a serial console configured through stdout-path we want to have console output on both as we do not know which of the 2 will actually be hooked up by the user.
I don't see this as a regression, but rather a misconfiguration.
As said it is an undesirable behavior change, whether you want to call that a regression or not is not all that interesting. Fixing it however is important, as e.g. Fedora ARM images rely on this behavior, both "regular" arm as well as aarch64.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, currently the setting of stdout-path on these boards is done by (an unmodified) upstream u-boot.
You forgot to mention my patch is not very likely to break anything in the wild since _you_ upstreamed the dependency only 3 weeks ago [1].
I contacted Grant Likely a while ago about how to get the same behavior we have on aarch64 (console on both video output/tty0 and a serial tty by default) on devicetree based platforms and he pointed to stdout-path, and then I wrote the patch.
I did this after talking to several Fedora ARM people about the problems we've with boards where we have both a video output and a serial console, such as on eg also Rasberry Pi-s, and the conclusion was that there is no single way for users to use these boards, so we must show boot messages on both, so that if things fail the user gets a chance to see how / why things fail. And passing a console= argument does not work here, we (the distro) need something which will just work everywhere, and we had that until your patch broke things.
Quoted 1 line
And what "Fedora ARM images rely on this behavior"?
All of them, Fedora ARM images are generic and use a multi-platform kernel, so any supported board which has a serial console connector + video output needs this to work.
More specifically the Fedora nightly composes of F-22 which contain u-boot v2015.04-rc3 which contains the sunxi commit I gave *as an example*.
Quoted 1 line
I don't appreciate the deception.
There is no deception sunxi happens to be the ARM SOC I do a lot of work on, but it is hardly the only user of stdout-path while also having video-output / tty0.
Note that my initial mail did not mention sunxi at all. You asked for an example, and now providing the example is deception ???
I can understand that your unhappy to hear that your patch breaks things, but please stop blaming the messenger.
I've been in your shoes were a kernel patch of mine caused a behavioral changed and people saw that as a regression. In my case it had to escalate to Linus, and Linus ordered the subsys maintainer to revert my patch, before I saw that I was wrong. I had to cool off a bit after that before I realized that Linus was actually right, the no regressions policy we have in the kernel is a very sensible one, and you cannot just go and change behavior people rely on, because that indeed is a REGRESSION.
TBH I do not understand why we're even arguing here, AFAICT the behavior change is an unwanted side-effect of your patch, so the solution is to rewrite the patch so that we get the same end result (not turning off bootconsole-s too early) without the unwanted side-effect, and you agreed to work on that ?
Regards,
Hans
Quoted 135 lines · Hans de Goede
Hi,
Quoted 60 lines · Peter Hurley
Quoted 58 lines · Hans de Goede
Hi,
Quoted 52 lines · Peter Hurley
Quoted 40 lines · Hans de Goede
Hi,
Quoted 33 lines · Peter Hurley
Hi Hans,
Quoted 20 lines · Hans de Goede
Hi All,
While updating my local working tree to 4.0-rc4 this morning I noticed that I no longer
get console / kernel messages output on the hdmi output of my ARM board / on tty0This is caused by:
Reverting this commit fixes this for me.
What is happening here is that the "
add_preferred_console("stdout-path", 0, NULL);"
happens before the tty0 registers stopping tty0 from becoming part of the console list
since there already is a preferred console at that time.Quoted 7 lines
This is an undesirable behavior change caused by the commit in question, on boards
where there is both video output, and a serial console configured through stdout-path
we want to have console output on both as we do not know which of the 2 will actually
be hooked up by the user.Quoted 1 line
I don't see this as a regression, but rather a misconfiguration.
Quoted 6 lines
As said it is an undesirable behavior change, whether you want to call that a regression
or not is not all that interesting. Fixing it however is important, as e.g. Fedora
ARM images rely on this behavior, both "regular" arm as well as aarch64.What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?Quoted 8 lines
Quoted 4 lines
This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, currently
the setting of stdout-path on these boards is done by (an unmodified) upstream u-boot.You forgot to mention my patch is not very likely to break anything in the wild since _you_ upstreamed the dependency only 3 weeks ago [1].
I contacted Grant Likely a while ago about how to get the same behavior we have on aarch64 (console on both video output/tty0 and a serial tty by default)
on devicetree based platforms and he pointed to stdout-path, and then I wrote
the patch.I did this after talking to several Fedora ARM people about the problems we've with boards
where we have both a video output and a serial console, such as on eg also Rasberry Pi-s,
and the conclusion was that there is no single way for users to use these boards, so we
must show boot messages on both, so that if things fail the user gets a chance to see
how / why things fail. And passing a console= argument does not work here, we (the
distro) need something which will just work everywhere, and we had that until your
patch broke things.Quoted 1 line
And what "Fedora ARM images rely on this behavior"?
All of them, Fedora ARM images are generic and use a multi-platform kernel, so any
supported board which has a serial console connector + video output needs this to work.More specifically the Fedora nightly composes of F-22 which contain u-boot v2015.04-rc3 which contains the sunxi commit I gave *as an example*.
Quoted 1 line
I don't appreciate the deception.
There is no deception sunxi happens to be the ARM SOC I do a lot of work on, but it
is hardly the only user of stdout-path while also having video-output / tty0.Note that my initial mail did not mention sunxi at all. You asked for an example, and
now providing the example is deception ???I can understand that your unhappy to hear that your patch breaks things, but please
stop blaming the messenger.I've been in your shoes were a kernel patch of mine caused a behavioral changed and
people saw that as a regression. In my case it had to escalate to Linus, and Linus
ordered the subsys maintainer to revert my patch, before I saw that I was wrong.
I had to cool off a bit after that before I realized that Linus was actually right,
the no regressions policy we have in the kernel is a very sensible one, and you
cannot just go and change behavior people rely on, because that indeed is a REGRESSION.
Quoted 7 lines
TBH I do not understand why we're even arguing here, AFAICT the behavior change
is an unwanted side-effect of your patch, so the solution is to rewrite the patch
so that we get the same end result (not turning off bootconsole-s too early) without
the unwanted side-effect, and you agreed to work on that ?
I intend to revert this if we don't have a fix soon.
I think we just need a flag saying we've enabled the earlycon from stdout-path or not and then add the preferred console based on that. I assume with "earlycon" only on the command-line, getting console only on stdout-path is okay.
Rob
A message that is not in the archive (sent off-list or not yet received): CAL_Jsq+dA3RDbakrkeMY07czs13bFFKCyETEXTzWxf+h1umBPQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Hi,
Quoted 1 line · Rob Herring
On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <[email protected]> wrote:
<snip>
Quoted 8 lines
Quoted 7 lines
TBH I do not understand why we're even arguing here, AFAICT the behavior change
is an unwanted side-effect of your patch, so the solution is to rewrite the patch
so that we get the same end result (not turning off bootconsole-s too early) without
the unwanted side-effect, and you agreed to work on that ?
Quoted 6 lines
I intend to revert this if we don't have a fix soon.
I think we just need a flag saying we've enabled the earlycon from stdout-path or not and then add the preferred console based on that. I assume with "earlycon" only on the command-line, getting console only on stdout-path is okay.
Yes, if a user explicitly specifies something like "earlycon" on the commandline then not automatically getting console output on tty0 is fine AFAICT. The use case important for me / distros is when no console= (or related) arguments are present on the cmdline at all, then the desired behavior is to have console output on tty0 as well as on any serial console specified with stdout-path.
Thanks & Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 22 lines · Hans de Goede
Hi,
Quoted 1 line · Rob Herring
On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <[email protected]> wrote:
<snip>
Quoted 8 lines
Quoted 7 lines
TBH I do not understand why we're even arguing here, AFAICT the behavior change
is an unwanted side-effect of your patch, so the solution is to rewrite the patch
so that we get the same end result (not turning off bootconsole-s too early) without
the unwanted side-effect, and you agreed to work on that ?Quoted 6 lines
I intend to revert this if we don't have a fix soon.
I think we just need a flag saying we've enabled the earlycon from stdout-path or not and then add the preferred console based on that. I assume with "earlycon" only on the command-line, getting console only on stdout-path is okay.
Quoted 6 lines
Yes, if a user explicitly specifies something like "earlycon" on the commandline then not automatically getting console output on tty0 is fine AFAICT. The use case important for me / distros is when no console= (or related) arguments are present on the cmdline at all, then the desired behavior is to have console output on tty0 as well as on any serial console specified with stdout-path.
The issues raised by this patch have nothing to do with earlycon.
1. PowerPC boot crash - the report with the most troubleshooting info right now implicates some buffer overflow or console mismanagement triggered by simply having defined a preferred console. This needs to be figured out regardless, and this is what I'm working right now.
2. Hans' use-case was _already broken_ even before this patch; _any_ driver that adds a preferred console before the vt console driver will cause this problem. So again, this needs to be fixed regardless.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 32 lines · Peter Hurley
Quoted 22 lines · Hans de Goede
Hi,
Quoted 1 line · Rob Herring
On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <[email protected]> wrote:
<snip>
Quoted 8 lines
Quoted 7 lines
TBH I do not understand why we're even arguing here, AFAICT the behavior change
is an unwanted side-effect of your patch, so the solution is to rewrite the patch
so that we get the same end result (not turning off bootconsole-s too early) without
the unwanted side-effect, and you agreed to work on that ?Quoted 6 lines
I intend to revert this if we don't have a fix soon.
I think we just need a flag saying we've enabled the earlycon from stdout-path or not and then add the preferred console based on that. I assume with "earlycon" only on the command-line, getting console only on stdout-path is okay.
Quoted 6 lines
Yes, if a user explicitly specifies something like "earlycon" on the commandline then not automatically getting console output on tty0 is fine AFAICT. The use case important for me / distros is when no console= (or related) arguments are present on the cmdline at all, then the desired behavior is to have console output on tty0 as well as on any serial console specified with stdout-path.
The issues raised by this patch have nothing to do with earlycon.
Quoted 8 lines
1. PowerPC boot crash - the report with the most troubleshooting info right now implicates some buffer overflow or console mismanagement triggered by simply having defined a preferred console. This needs to be figured out regardless, and this is what I'm working right now.
2. Hans' use-case was
_alreadybroken_even before this patch; _any_ driver that adds a preferred console before the vt console driver will cause this problem. So again, this needs to be fixed regardless.
Rob,
You're right; this patch will need to be reverted. I'll send you a revert.
Regards,
Peter Hurley
Quoted 1 line · Peter Hurley
I don't see this as a regression, but rather a misconfiguration.
It breaks booting on PowerMac.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
I don't see this as a regression, but rather a misconfiguration.
It breaks booting on PowerMac.
It doesn't boot?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Peter Hurley
Quoted 5 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
I don't see this as a regression, but rather a misconfiguration.
It breaks booting on PowerMac.
It doesn't boot?
Yes.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 5 lines · Andreas Schwab
Quoted 3 lines · Peter Hurley
Quoted 2 lines · Andreas Schwab
Peter Hurley <[email protected]> writes:
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
I don't see this as a regression, but rather a misconfiguration.
It breaks booting on PowerMac.
It doesn't boot?
Yes.
Ok, thanks for the report.
Can you attach
1) your .dts
2) your .config
3) complete dmesg from 4.0-rc4 boot with that patch reverted?
Do you have a serial console hooked up?
Regards,
Peter Hurley
Quoted 8 lines · Peter Hurley
Quoted 7 lines · Andreas Schwab
Quoted 6 lines · Peter Hurley
Quoted 4 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
I don't see this as a regression, but rather a misconfiguration.
It breaks booting on PowerMac.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
It doesn't boot?
Yes.
Ok, thanks for the report.
Can you attach
1) your .dts
Note that this is a PowerMac, so there's no DTS, only a real DT passed by the Firmware.
Quoted 1 line
Do you have a serial console hooked up?
Most probably, the chosen/stdout-path is provided automatically by the firmware, even if no serial console is present. Andreas, is that correct?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 2 lines · Geert Uytterhoeven
Most probably, the chosen/stdout-path is provided automatically by the firmware, even if no serial console is present. Andreas, is that correct?
There is only chosen/linux,stdout-path, pointing to the display device.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 1 line · Peter Hurley
It doesn't boot?
It boots right into user space, but the initrd doesn't like something (perhaps the missing console) and exits. Note that the framebuffer console does work, but all I see are the penguins.
[ 6.235604] Warning: unable to open an initial console. [ 6.237611] Freeing unused kernel memory: 2156K (c000000000a0a000 - c000000000c25000) [ 6.262059] mount (70) used greatest stack depth: 10064 bytes left [ 6.298795] mkdir (76) used greatest stack depth: 9760 bytes left [ 6.376450] sysrq: SysRq : Changing Loglevel [ 6.376513] sysrq: Loglevel set to 1 [ 6.430512] systemd-udevd[111]: starting version 208 [ 6.488367] udevadm (112) used greatest stack depth: 9312 bytes left [ 6.605581] ata_id (127) used greatest stack depth: 8400 bytes left [ 8.578710] btrfs (217) used greatest stack depth: 8032 bytes left [ 8.700698] PM: Starting manual resume from disk [ 13.354795] EXT4-fs (dm-1): mounting ext3 file system using the ext4 subsystem [ 13.391899] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) [ 23.852033] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 23.852033] [ 23.852067] CPU: 1 PID: 1 Comm: run-init Not tainted 4.0.0-rc4-test #27 [ 23.852078] Call Trace: [ 23.852095] [c0000001ee0bbb30] [c0000000006f8f64] .dump_stack+0x88/0xa8 (unreliable) [ 23.852118] [c0000001ee0bbbb0] [c0000000006f52f8] .panic+0xe8/0x284 [ 23.852139] [c0000001ee0bbc50] [c000000000045b38] .do_exit+0x550/0xa08 [ 23.852156] [c0000001ee0bbd30] [c000000000047178] .do_group_exit+0x48/0xbc [ 23.852173] [c0000001ee0bbdc0] [c000000000047200] .__wake_up_parent+0x0/0x38 [ 23.852192] [c0000001ee0bbe30] [c000000000007d18] system_call+0x38/0xd0
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 9 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
It doesn't boot?
It boots right into user space, but the initrd doesn't like something (perhaps the missing console) and exits. Note that the framebuffer console does work, but all I see are the penguins.
[ 6.235604] Warning: unable to open an initial console.
Thanks, Andreas. I had figured out from your earlier email that your specific breakage was the absence of any console.
Regards,
Peter Hurley
Quoted 5 lines · Peter Hurley
Quoted 4 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
It doesn't boot?
Quoted 8 lines
Quoted 5 lines
It boots right into user space, but the initrd doesn't like something (perhaps the missing console) and exits. Note that the framebuffer console does work, but all I see are the penguins.
[ 6.235604] Warning: unable to open an initial console.Thanks, Andreas. I had figured out from your earlier email that your specific breakage was the absence of any console.
Would you share what the actual prom stdout string value is? (linux,stdout-path is equivalent)
Regards,
Peter Hurley
Quoted 2 lines · Peter Hurley
Would you share what the actual prom stdout string value is? (linux,stdout-path is equivalent)
You mean the contents of chosen/linux,stdout-path?
"/pci@0,f0000000/NVDA,Parent@10/NVDA,Display-B@1"
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Hi,
Quoted 5 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
I don't see this as a regression, but rather a misconfiguration.
It breaks booting on PowerMac.
Actually that is more likely to be caused by:
Try reverting that one, also see:
http://www.spinics.net/lists/stable/msg82872.html
Note that if either if these patches are the culprit likely your system is still booting you're just not getting any messages on either video output (caused by the commit discussed in this thread) nor on a serial console (caused by the 106937e8 commit). If you've a network interface which comes up automatically try pinging it.
Regards,
Hans
Quoted 10 lines · Hans de Goede
Quoted 5 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
I don't see this as a regression, but rather a misconfiguration.
It breaks booting on PowerMac.
Actually that is more likely to be caused by:
If so, I would appreciate a test of my proposed fix:
http://www.spinics.net/lists/stable/msg82878.html
Regards,
Leif
A message that is not in the archive (sent off-list or not yet received): 20150317100917.GM4278-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org
Hi,
Quoted 6 lines · Leif Lindholm
Quoted 5 lines · Hans de Goede
Quoted 4 lines · Andreas Schwab
Quoted 1 line · Peter Hurley
I don't see this as a regression, but rather a misconfiguration.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
It breaks booting on PowerMac.
Actually that is more likely to be caused by:
If so, I would appreciate a test of my proposed fix:
http://www.spinics.net/lists/stable/msg82878.html
Yeah I have testing that on my todo list for today :)
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Hans de Goede
Actually that is more likely to be caused by:
Try reverting that one, also see:
That doesn't help.
Quoted 3 lines
Note that if either if these patches are the culprit likely your system is still booting you're just not getting any messages on either video output
No, it is panicking.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."