From: Jan Kiszka <jan.kiszka@web.de>
To: Jason Wessel <jason.wessel@windriver.com>
Cc: kgdb-bugreport@lists.sourceforge.net, Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][KGDB] Re: KGDB: 8250_kgdb warnings
Date: Wed, 30 Jan 2008 00:21:26 +0100 [thread overview]
Message-ID: <479FB4F6.90901@web.de> (raw)
In-Reply-To: <479FAECF.8090308@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]
Jason Wessel wrote:
> Jan Kiszka wrote:
>> Hi Jason,
>>
>> so far I ignored this because it worked, but I know my customer will
>> complain later anyway: What is the deeper meaning of this warning which
>> shows up once per registered UART port on my (x86) boxes?
>>
>> void kgdb8250_add_port(int i, struct uart_port *serial_req)
>> {
>> #ifdef CONFIG_KGDB_SIMPLE_SERIAL
>> if (should_copy_rs_table)
>> printk(KERN_ERR "8250_kgdb: warning will over write serial"
>> " port definitions at kgdb init time\n");
>> #endif
>> ...
>>
>> When I look at kgdb8250_add_platform_port, it starts with a call to
>> kgdb8250_copy_rs_table, and I'm wondering now if that wouldn't be more
>> appropriate here.
>>
>> Jan
>>
>
>
> This was the result of a race condition between the init code of the
> platform vs the init code in kgdb. The init code in the arch platform
> could register serial ports prior to the kgdb module being configured
> by the kernel while the kernel is processing all the __init functions.
> It would have been easy to fix this with another call to
> kgdb8250_copy_rs_table() but you cannot do that because a non-__init
> function cannot call an __init function.
>
>
> We might as well go ahead and fix the problem by adding in some checks
> so as not to overwrite the dynamic registrations, because eventually
> the SERIAL_PORT_DFNS will be gone. Below is the patch with the fix to
> add some saftey checks as well as to remove the warning.
>
> --------Cut here-----------
>
>
> Fix the initialization of the kgdb port structure such that
> dynamically registered ports will not be later overwritten by the
> SERIAL_PORT_DFNS table. With this problem fixed, the printk about the
> overwriting of the kgdb serial definitions at init time can be
> removed.
>
> Also add in additional runtime safety checks to make sure UART_NR was
> statically allocated by the kernel at compile time to be large enough
> for all the dynamic registered ports.
I'm currently preparing to post a larger patch series for KGDB which
also addresses this problem - but quite differently. Therefore this
question in advance:
What use case could not be covered by polling the (8250) config via
serial8250_get_port_def() when there were no kgdb8250_add_port()? That's
in fact what I did in my patch because I found none and the result
appears much more consistent to me. But I'm not claiming to be a UART
expert across all those various embedded platforms.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
prev parent reply other threads:[~2008-01-29 23:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-28 10:19 KGDB: 8250_kgdb warnings Jan Kiszka
2008-01-29 22:55 ` [PATCH][KGDB] Re: [Kgdb-bugreport] " Jason Wessel
2008-01-29 23:21 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=479FB4F6.90901@web.de \
--to=jan.kiszka@web.de \
--cc=jason.wessel@windriver.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.