rote:
> > > > According to the virtio spec[0] the virtio console resize
> > > > struct
> > > > defines
> > > > cols before rows. In the kernel implementation it is the other
> > > > way
> > > > around
> > > > resulting i
On Wed, Mar 19, 2025 at 06:13:08PM +0100, Halil Pasic wrote:
> On Wed, 19 Mar 2025 11:00:06 -0400
> "Michael S. Tsirkin" wrote:
>
> > > > I was mistaken in my earlier reply - I had missed this
> > > > virtio_console_resize definition in the spec. So indeed there's a
> > > > discrepancy in Linux
On Thu, 20 Mar 2025 15:09:57 +0100
Halil Pasic wrote:
> > I already implemented it in my patch v2 (just waiting for Amit to
> > confirm the new commit message). But if you want to split it you can
> > create a seperate patch for it as well (I don't really mind either
> > way).
> >
Your v2 has
mns to columns then
> rows.
It's clearer and cleaner to only describe the issue you're solving
here; the other patch will take care of the other issue.
You can add more info here, like: the console resize messages via the
config space (section 5.3.4) are used for resizing, and that works
t;Make resize control event handling compliant with spec". Just an idea.
> This patch changes the ordering of rows and columns to columns then
> rows.
>
> Fixes: 8345adbf96fc1 ("virtio: console: Accept console size along with
> resize control message") Signed-o
o columns then
> rows.
>
> Fixes: 8345adbf96fc1 ("virtio: console: Accept console size along
> with resize control message")
> Signed-off-by: Maximilian Immanuel Brandtner
> Cc: sta...@vger.kernel.org # v2.6.35+
> ---
> drivers/char/virtio_console.c | 2 +-
endian architectures)(a seperate patch by Halil Pasic will deal with
that issue) and swaps the ordering of columns and rows.
This patch changes the ordering of rows and columns to columns then
rows.
Fixes: 8345adbf96fc1 ("virtio: console: Accept console size along with resize
control message&quo
On Thu, 2025-03-20 at 15:19 +0100, Halil Pasic wrote:
> On Thu, 20 Mar 2025 15:09:57 +0100
> Halil Pasic wrote:
>
> > > I already implemented it in my patch v2 (just waiting for Amit to
> > > confirm the new commit message). But if you want to split it you
> > > can
> > > create a seperate patch
On Thu, 20 Mar 2025 12:53:43 +0100
Maximilian Immanuel Brandtner wrote:
> On Thu, 2025-03-20 at 11:41 +0100, Halil Pasic wrote:
> > On Thu, 20 Mar 2025 08:12:23 +0100
> > Maximilian Immanuel Brandtner wrote:
> >
> > > > Another thing I noticed during looking at this. AFAICT Linux does
> > > >
On Thu, 2025-03-20 at 11:41 +0100, Halil Pasic wrote:
> On Thu, 20 Mar 2025 08:12:23 +0100
> Maximilian Immanuel Brandtner wrote:
>
> > > Another thing I noticed during looking at this. AFAICT Linux does
> > > not
> > > seem to handle endiannes here. And AFAIU the message is supposed
> > > to
> >
On Thu, 20 Mar 2025 08:12:23 +0100
Maximilian Immanuel Brandtner wrote:
> > Another thing I noticed during looking at this. AFAICT Linux does not
> > seem to handle endiannes here. And AFAIU the message is supposed to
> > hold
> > le16 that is little endian u16! Maximilian, is this in your opinio
rote:
> > > > According to the virtio spec[0] the virtio console resize
> > > > struct
> > > > defines
> > > > cols before rows. In the kernel implementation it is the other
> > > > way
> > > > around
> > > > resulting i
On Wed, 2025-03-19 at 18:13 +0100, Halil Pasic wrote:
> On Wed, 19 Mar 2025 11:00:06 -0400
> "Michael S. Tsirkin" wrote:
>
> > > > I was mistaken in my earlier reply - I had missed this
> > > > virtio_console_resize definition in the spec. So indeed
> > > > there's a
> > > > discrepancy in Linux
t; > > > On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel Brandtner
> > > > wrote:
> > > > > According to the virtio spec[0] the virtio console resize
> > > > > struct
> > > > > defines
> > > > > cols before rows
On Wed, 19 Mar 2025 11:00:06 -0400
"Michael S. Tsirkin" wrote:
> > > I was mistaken in my earlier reply - I had missed this
> > > virtio_console_resize definition in the spec. So indeed there's a
> > > discrepancy in Linux kernel and the spec's ordering for the control
> > > message.
> > >
> >
rote:
> > > > According to the virtio spec[0] the virtio console resize
> > > > struct
> > > > defines
> > > > cols before rows. In the kernel implementation it is the other
> > > > way
> > > > around
> > > > resulting i
; > > On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel
> > > > Brandtner
> > > > wrote:
> > > > > According to the virtio spec[0] the virtio console resize
> > > > > struct
> > > > > defines
> > > > > col
On Tue, 2025-03-18 at 11:07 +0100, Maximilian Immanuel Brandtner wrote:
> On Mon, 2025-03-03 at 12:54 +0100, Amit Shah wrote:
> > On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel Brandtner
> > wrote:
> > > According to the virtio spec[0] the virtio console res
On Mon, 2025-03-03 at 12:54 +0100, Amit Shah wrote:
> On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel Brandtner
> wrote:
> > According to the virtio spec[0] the virtio console resize struct
> > defines
> > cols before rows. In the kernel implementation it is
On Mon, 2025-03-10 at 14:04 +0100, Maximilian Immanuel Brandtner wrote:
[...]
> Just to make sure that everyone here is one the same page there is
> indeed a difference between the ordering of the control resize
> message
> and the kernel implementation; however as this bug has been around
> for
t; On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel
> > > > Brandtner
> > > > wrote:
> > > > > According to the virtio spec[0] the virtio console resize
> > > > > struct
> > > > > defines
> > > > > cols
t; On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel
> > > > Brandtner
> > > > wrote:
> > > > > According to the virtio spec[0] the virtio console resize
> > > > > struct
> > > > > defines
> > > > > cols
e:
> > > > According to the virtio spec[0] the virtio console resize struct
> > > > defines
> > > > cols before rows. In the kernel implementation it is the other way
> > > > around
> > > > resulting in the two properties being switched
On Wed, 2025-03-05 at 10:53 +0100, Maximilian Immanuel Brandtner wrote:
> On Mon, 2025-03-03 at 12:54 +0100, Amit Shah wrote:
> > On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel Brandtner
> > wrote:
> > > According to the virtio spec[0] the virtio console res
On Mon, 2025-03-03 at 12:54 +0100, Amit Shah wrote:
> On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel Brandtner
> wrote:
> > According to the virtio spec[0] the virtio console resize struct
> > defines
> > cols before rows. In the kernel implementation it is
From: "Paul E. McKenney"
Kernels built with CONFIG_PREEMPT_RT=y can lose significant console output
and shutdown time, which hides shutdown-time RCU issues from rcutorture.
Therefore, make pr_flush() public and invoke it after then last print
in kernel_power_off().
[ paulmck: Apply J
On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel Brandtner wrote:
> According to the virtio spec[0] the virtio console resize struct
> defines
> cols before rows. In the kernel implementation it is the other way
> around
> resulting in the two properties being switched.
Not
Kernels built with CONFIG_PREEMPT_RT=y can lose significant console output
and shutdown time, which hides shutdown-time RCU issues from rcutorture.
Therefore, make pr_flush() public and invoke it after then last print
in kernel_power_off().
[ paulmck: Apply John Ogness feedback. ]
[ paulmck: Appy
According to the virtio spec[0] the virtio console resize struct defines
cols before rows. In the kernel implementation it is the other way around
resulting in the two properties being switched.
While QEMU doesn't currently support resizing consoles, TinyEMU
does[1](and they implement res
MOTEPROC=m,
> > > > > > VIRTIO_CONSOLE can be y or m. Say virtcons_probe() happens
> > > > > > when
> > > > > > the
> > > > > > remoteproc module isn't yet loaded. Even after later
> > > > > > lo
gt; > > when
> > > > > the
> > > > > remoteproc module isn't yet loaded. Even after later loading
> > > > > remoteproc, virtio console won't do anything interesting with
> > > > > remoteproc.
> > > >
> > > &
ens
> > > > > when
> > > > > the
> > > > > remoteproc module isn't yet loaded. Even after later loading
> > > > > remoteproc, virtio console won't do anything interesting with
> > > > > remoteproc.
&
Shah wrote:
> > > > I'm thinking of the two combinations of interest: REMOTEPROC=m,
> > > > VIRTIO_CONSOLE can be y or m. Say virtcons_probe() happens
> > > > when
> > > > the
> > > > remoteproc module isn't yet loaded. Even af
On Fri, 14 Feb 2025 at 21:27, Thomas Weißschuh
wrote:
>
> The driver for the 8250 console is not used, as no port is found.
> Instead the prom0 bootconsole is used the whole time.
> The prom driver translates '\n' to '\r\n' before handing of the message
>
OTEPROC=m,
> > > VIRTIO_CONSOLE can be y or m. Say virtcons_probe() happens when
> > > the
> > > remoteproc module isn't yet loaded. Even after later loading
> > > remoteproc, virtio console won't do anything interesting with
> > > remote
hen
> > the
> > remoteproc module isn't yet loaded. Even after later loading
> > remoteproc, virtio console won't do anything interesting with
> > remoteproc.
>
> Where does the interesting thing happen if remoteproc is already
> loaded
> at that time? I
gt; remoteproc, virtio console won't do anything interesting with
> remoteproc.
Where does the interesting thing happen if remoteproc is already loaded
at that time? I'm not seeing anything interesting in that case either
...
Best regards
Uwe
signature.asc
Description: PGP signature
rivers/char/virtio_console.i
> > > ...
> > > static bool is_rproc_serial(const struct virtio_device
> > > *vdev)
> > > {
> > >return 1 && vdev->id.device == 11;
> > > }
> > > ...
> > >
> > >
>
ct virtio_device
> > *vdev)
> > {
> > return 1 && vdev->id.device == 11;
> > }
> > ...
> >
> >
> > so is_rproc_enabled is still constant and known at compile time.
>
> Well - so I was replying to your comment about what
device
> *vdev)
> {
>return 1 && vdev->id.device == 11;
> }
> ...
>
>
> so is_rproc_enabled is still constant and known at compile time.
Well - so I was replying to your comment about what else is required.
And if remoteproc becomes a
The driver for the 8250 console is not used, as no port is found.
Instead the prom0 bootconsole is used the whole time.
The prom driver translates '\n' to '\r\n' before handing of the message
off to the firmware. The firmware performs the same translation again.
In the fina
gt;id.device == 11;
}
...
so is_rproc_enabled is still constant and known at compile time.
> That
> caching, after this change, moves to driver init-time. If the rproc
> module is loaded after virtio-console is initialized, there's no way
> it's going to be
e-time. That
caching, after this change, moves to driver init-time. If the rproc
module is loaded after virtio-console is initialized, there's no way
it's going to be used. Only if the rproc module is loaded before
virtio-console will the rproc functionality be used -- whic
virtio_console.c can make use of REMOTEPROC. Therefore it has several
tests evaluating
IS_ENABLED(CONFIG_REMOTEPROC)
. This currently only does the right thing because CONFIG_REMOTEPROC
cannot be modular. Otherwise the configuration
CONFIG_REMOTEPROC=m
CONFIG_VIRTIO_CONSO
On Wed, 2025-02-12 at 12:48 +0100, Thorsten Blum wrote:
> Remove hard-coded strings by using the str_yes_no() helper function.
>
> Signed-off-by: Thorsten Blum
> ---
> drivers/char/virtio_console.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Amit Shah
Remove hard-coded strings by using the str_yes_no() helper function.
Signed-off-by: Thorsten Blum
---
drivers/char/virtio_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 24442485e73e..35af0cc11d
David Reaver wrote:
> kmap_atomic() is deprecated and should be replaced with kmap_local_page()
> [1][2]. kmap_local_page() is faster in kernels with HIGHMEM enabled, can
> take page faults, and allows preemption.
Thanks for taking these on! It is good to see some progress here.
>
> According t
On Wed, 2025-01-08 at 19:59 -0800, David Reaver wrote:
> kmap_atomic() is deprecated and should be replaced with
> kmap_local_page()
> [1][2]. kmap_local_page() is faster in kernels with HIGHMEM enabled,
> can
> take page faults, and allows preemption.
>
> According to [2], this replacement is saf
kmap_atomic() is deprecated and should be replaced with kmap_local_page()
[1][2]. kmap_local_page() is faster in kernels with HIGHMEM enabled, can
take page faults, and allows preemption.
According to [2], this replacement is safe as long as the code between
kmap_atomic() and kunmap_atomic() does
tions to identify possible
concurrency bugs including data races and atomicity violations.
Fixes: 203baab8ba31 ("virtio: console: Introduce function to hand off data from
host to readers")
Cc: sta...@vger.kernel.org
Signed-off-by: Qiu-ji Chen
---
V2:
The logic of the fix ha
On Wed, Oct 09, 2024 at 04:44:24PM +0100, Pavel Begunkov wrote:
> On 10/8/24 16:18, John Ogness wrote:
> > On 2024-10-04, Petr Mladek wrote:
> > > On Fri 2024-10-04 02:08:52, Breno Leitao wrote:
> > > > =
> > > > WARNING: HARDIR
On 10/8/24 16:18, John Ogness wrote:
On 2024-10-04, Petr Mladek wrote:
On Fri 2024-10-04 02:08:52, Breno Leitao wrote:
=
WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
6.12.0-rc1-kbuilder-virtme-00033-g
On 2024-10-04, Petr Mladek wrote:
> On Fri 2024-10-04 02:08:52, Breno Leitao wrote:
>> =
>> WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
>> 6.12.0-rc1-kbuilder-virtme-00033-gd4ac164bde7a #50 Not tainted
>> -
der-virtme-00033-gd4ac164bde7a
> (l...@devvm32600.lla0.foo.com) (clang version 20.0.0git
> (https://github.com/llvm/llvm-project.git
> d0f67773b213383b6e1c9331fb00f2d4c14bfcb2), LLD 18.0.0) #50 SMP
> PREEMPT_DYNAMIC Fri Oct 4 01:54:44 PDT 2024
>Command line: virtme_hostnam
he full log:
Linux version 6.12.0-rc1-kbuilder-virtme-00033-gd4ac164bde7a
(l...@devvm32600.lla0.foo.com) (clang version 20.0.0git
(https://github.com/llvm/llvm-project.git
d0f67773b213383b6e1c9331fb00f2d4c14bfcb2), LLD 18.0.0) #50 SMP PREEMPT_DYNAMIC
Fri Oct 4 01:54:44 PDT 2024
just booted a clean VM, here is the full log:
Linux version 6.11.0-rc1-kbuilder-00044-g152e11f6df29
(l...@devvm32600.lla0.foobar.com) (clang version 20.0.0git
(https://github.com/llvm/llvm-project.git
d0f67773b213383b6e1c9331fb00f2d4c14bfcb2), LLD 18.0.0) #47 SMP Thu Oct 3
07:23:47 PDT 2024
Command line: virtme_
On Thu, Oct 03, 2024 at 07:51:20AM -0700, Breno Leitao wrote:
> Upstream kernel (6.12-rc1) has a new lockdep splat, that I am sharing to
> get more visibility:
>
> WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
>
> This is happening because the HARDIRQ-irq-unsafe "_xmit_ETHER#2
On Thu, Oct 03, 2024 at 07:51:20AM -0700, Breno Leitao wrote:
> Upstream kernel (6.12-rc1) has a new lockdep splat, that I am sharing to
> get more visibility:
>
> WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
>
> This is happening because the HARDIRQ-irq-unsafe "_xmit_ETHER#2
st_init (init/main.c:1461)
kernel_init (init/main.c:1471)
ret_from_fork (arch/x86/kernel/process.c:153)
? rest_init (init/main.c:1461)
ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
printk: legacy console [netcon0] enabled
netconsole
races and atomicity violations.
Fixes: 203baab8ba31 ("virtio: console: Introduce function to hand off data from
host to readers")
Cc: sta...@vger.kernel.org
Signed-off-by: Qiu-ji Chen
---
drivers/char/virtio_console.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff
On 7 Jan 2024, at 19:22, Paul Heidekrüger wrote:
> On 12.12.2023 10:32, Marco Elver wrote:
>> On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger
>> wrote:
>>>
>>> On 12.12.2023 00:37, Andrey Konovalov wrote:
On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
wrote:
>
> Using CON
On 12.12.2023 10:32, Marco Elver wrote:
> On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger
> wrote:
> >
> > On 12.12.2023 00:37, Andrey Konovalov wrote:
> > > On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
> > > wrote:
> > > >
> > > > Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produc
On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger wrote:
>
> On 12.12.2023 00:37, Andrey Konovalov wrote:
> > On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
> > wrote:
> > >
> > > Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produces the same
> > > error
> > > for me.
> > >
> > > So
> >
On 12.12.2023 00:37, Andrey Konovalov wrote:
> On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
> wrote:
> >
> > Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produces the same
> > error
> > for me.
> >
> > So
> >
> > CONFIG_KUNIT=y
> > CONFIG_KUNIT_ALL_TESTS=n
> >
On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
wrote:
>
> Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produces the same error
> for me.
>
> So
>
> CONFIG_KUNIT=y
> CONFIG_KUNIT_ALL_TESTS=n
> CONFIG_FTRACE=y
> CONFIG_KASAN=y
> CONFIG_KASAN_GENERI
On 11.12.2023 23:56, Marco Elver wrote:
> On Mon, 11 Dec 2023 at 23:48, Paul Heidekrüger
> wrote:
> >
> > On 11.12.2023 21:51, Andrey Konovalov wrote:
> > > On Mon, Dec 11, 2023 at 7:59 PM Paul Heidekrüger
> > > wrote:
> > > >
> > > > > Hi Paul,
> > > > >
> > > > > I've been successfully running
On Mon, 11 Dec 2023 at 23:48, Paul Heidekrüger wrote:
>
> On 11.12.2023 21:51, Andrey Konovalov wrote:
> > On Mon, Dec 11, 2023 at 7:59 PM Paul Heidekrüger
> > wrote:
> > >
> > > > Hi Paul,
> > > >
> > > > I've been successfully running KASAN tests with CONFIG_TRACEPOINTS
> > > > enabled on arm64
On 11.12.2023 21:51, Andrey Konovalov wrote:
> On Mon, Dec 11, 2023 at 7:59 PM Paul Heidekrüger
> wrote:
> >
> > > Hi Paul,
> > >
> > > I've been successfully running KASAN tests with CONFIG_TRACEPOINTS
> > > enabled on arm64 since this patch landed.
> >
> > Interesting ...
> >
> > > What happens
On Mon, Dec 11, 2023 at 7:59 PM Paul Heidekrüger
wrote:
>
> > Hi Paul,
> >
> > I've been successfully running KASAN tests with CONFIG_TRACEPOINTS
> > enabled on arm64 since this patch landed.
>
> Interesting ...
>
> > What happens when you try running the tests with .kunitconfig? Does
> > CONFIG_T
Hi Andrey!
On 11.12.2023 18:50, Andrey Konovalov wrote:
> On Mon, Dec 11, 2023 at 5:37 PM Paul Heidekrüger
> wrote:
> >
> > Hi all!
> >
> > On 05.05.2023 09:58, Steven Rostedt wrote:
> > > On Mon, 1 May 2023 15:02:37 -0700
> > > Peter Collingbourne wrote:
> > >
> > > > > > "ftrace" is really for
On Mon, Dec 11, 2023 at 5:37 PM Paul Heidekrüger
wrote:
>
> Hi all!
>
> On 05.05.2023 09:58, Steven Rostedt wrote:
> > On Mon, 1 May 2023 15:02:37 -0700
> > Peter Collingbourne wrote:
> >
> > > > > "ftrace" is really for just the function tracing, but CONFIG_FTRACE
> > > > > really should just be
Hi all!
On 05.05.2023 09:58, Steven Rostedt wrote:
> On Mon, 1 May 2023 15:02:37 -0700
> Peter Collingbourne wrote:
>
> > > > "ftrace" is really for just the function tracing, but CONFIG_FTRACE
> > > > really should just be for the function tracing infrastructure, and
> > > > perhaps not even in
Incorrect characters are observed on console during boot. This issue occurs
when init/main.c is modifying termios settings to open /dev/console on the
rootfs.
This patch adds a waiting loop in set_termios to wait for TX shift register
empty (and TX FIFO if any) before stopping serial port.
Fixes
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk
On Thu 2021-02-18 09:18:17, John Ogness wrote:
> Upon registering a console, safe buffers are activated when setting
> up the sequence number to replay the log. However, these are already
> protected by @console_sem and @syslog_lock. Remove the unnecessary
> safe buffer usage.
>
Incorrect characters are observed on console during boot. This issue occurs
when init/main.c is modifying termios settings to open /dev/console on the
rootfs.
This patch adds a waiting loop in set_termios to wait for TX shift register
empty (and TX FIFO if any) before stopping serial port.
Fixes
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 10 +++---
1
Committer: Paul E. McKenney
CommitterDate: Mon, 04 Jan 2021 14:01:25 -08:00
torture: Remove "Failed to add ttynull console" false positive
Commit 757055ae8ded ("init/console: Use ttynull as a fallback when
there is no console") results in the string "Warning: Failed to add
Hello,
just for record.
On Tue 2021-02-09 13:49:25, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -5.9% regression of unixbench.score due to commit:
>
>
> commit: a91bd6223ecd46addc71ee6fcd432206d39365d2 ("Revert "init/console: Use
> ttyn
broke the tty conversion to write_iter in commit
9bb48c82aced ("tty: implement write_iter"), because the console
redirection didn't actually end up redirecting anything, since the
passed-in file pointer was basically ignored, and the actual write was
done with the original non-redirec
gt;>
>>>> On 2021-01-06, Vineet Gupta wrote:
>>>>> This breaks ARC booting (no output on console).
>>>>
>>>> Could you provide the kernel boot arguments that you use? This series is
>>>> partly about addressing users that ha
please ignore, that was accidentially sent.
On Wed, 13 Jan 2021 00:15:47 +0100
Andreas Kemnade wrote:
> Configuration was correct enough to work with the pre-configuration done by
> uboot. While at it, also document the location.
>
> Signed-off-by: Andreas Kemnade
> ---
> arch/arm/boot/dts/im
Ah, there is a v2. Let's hope this gets merged/processed by robots correctly :)
> Am 13.01.2021 um 00:15 schrieb Andreas Kemnade :
>
> Configuration was correct enough to work with the pre-configuration done by
> uboot. While at it, also document the location.
>
> Signed-off-by: Andreas Kemnade
> Am 13.01.2021 um 00:15 schrieb Andreas Kemnade :
>
> Configuration was correct enough to work with the pre-configuration done by
> uboot. While at it, also document the location.
>
> Signed-off-by: Andreas Kemnade
> ---
> arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 2 +-
seems to have a typ
Configuration was correct enough to work with the pre-configuration done by
uboot. While at it, also document the location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6
Configuration was correct enough to work with the pre-configuration done by
uboot. While at it, also document the location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sl-t
Configuration was correct enough to work with the pre-configuration done by
uboot. While at it, also document the location.
Signed-off-by: Andreas Kemnade
---
arch/arm/boot/dts/imx6sl-tolino-shine3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sl-t
ery clear.
>>> Why?
>>
>> Here, we are supposed to push the pending messages, as I could verify
>> that they don't reach the console until the console_unblank(). So I
>> wanted to push them with panic_flush_to_console() before the possible
>> upcoming _
On Fri, Jan 8, 2021 at 9:45 AM Petr Mladek wrote:
>
> Feel free to push v2 directly.
Thanks, done.
Linus
On 1/8/21 9:45 AM, Petr Mladek wrote:
> On Thu 2021-01-07 11:38:36, Linus Torvalds wrote:
>> On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
>> wrote:
>>> Linus, can you take this directly, or is this going through some other
>>> tree?
>> I was _assuming_ that I'd get it through the normal prin
On Thu 2021-01-07 11:38:36, Linus Torvalds wrote:
> On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
> wrote:
> >
> > Linus, can you take this directly, or is this going through some other
> > tree?
>
> I was _assuming_ that I'd get it through the normal printk pull
> request, it doesn't seem t
Why?
>
> Here, we are supposed to push the pending messages, as I could verify
> that they don't reach the console until the console_unblank(). So I
> wanted to push them with panic_flush_to_console() before the possible
> upcoming __crash_kexec() call.
I do not see how the order
On Mon 2021-01-04 16:15:55, “William Roche wrote:
> From: William Roche
>
> Force push panic messages to the console as panic() can be called from NMI
> interrupt handler functions where printed messages can't always reach the
> console without an expli
This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e.
The commit caused that ttynull was used as the default console
on several systems[1][2][3]. As a result, the console was
blank even when a better alternative existed.
It happened when there was no console configured
on the command
John,
> > > > >
> > > > > On 1/7/21 1:02 AM, John Ogness wrote:
> > > > > > Hi Vineet,
> > > > > >
> > > > > > On 2021-01-06, Vineet Gupta wrote:
> > > > > > > This breaks ARC booting (no
(no output on console).
Could you provide the kernel boot arguments that you use? This series is
partly about addressing users that have used boot arguments that are
technically incorrect (even if had worked). Seeing the boot arguments of
users that are not experiencing problems may help to
> > On 2021-01-06, Vineet Gupta wrote:
> > > > > This breaks ARC booting (no output on console).
> > > >
> > > > Could you provide the kernel boot arguments that you use? This series is
> > > > partly about addressing users that have used
On (21/01/07 17:44), Petr Mladek wrote:
>
> This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e.
>
> The commit caused that ttynull was used as the default console
> on many systems. It happened when there was no console configured
> on the command line and ttynull_in
tatic void panic_print_sys_info(void)
>>ftrace_dump(DUMP_ALL);
>> }
>>
>> +/*
>> + * Force flush messages to the console.
>> + */
>> +static void panic_flush_to_console(void)
>> +{
>> + printk_safe_flush_on_panic();
>> +
1 - 100 of 2784 matches
Mail list logo
