OK to checkin.
-Amit
On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
> Hello. When we use kgdboe, we can't use it until do_basic_setup() is done.
> So we have two options, not allow kgdboe to use the initial breakpoint
> or move debugger_entry() to be past the point where kgdboe will be usable.
> I've opted for the latter, as if an earlier breakpoint is needed you can
> still use serial and throw kgdb_schedule_breakpoint/breakpoint where
> desired.
>
> --- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
> +++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17 11:33:51.854388988 -0700
> @@ -581,6 +582,7 @@ static int init(void * unused)
>
> smp_init();
> do_basic_setup();
> + debugger_entry();
>
> prepare_namespace();
Amit S. Kale wrote:
> OK to checkin.
>
> -Amit
>
> On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
>
>>Hello. When we use kgdboe, we can't use it until do_basic_setup() is done.
>>So we have two options, not allow kgdboe to use the initial breakpoint
>>or move debugger_entry() to be past the point where kgdboe will be usable.
>>I've opted for the latter, as if an earlier breakpoint is needed you can
>>still use serial and throw kgdb_schedule_breakpoint/breakpoint where
>>desired.
>>
>>--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
>>+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17 11:33:51.854388988 -0700
>>@@ -581,6 +582,7 @@ static int init(void * unused)
>>
>> smp_init();
>> do_basic_setup();
>>+ debugger_entry();
>>
It would be nice to not need this. Could it be a side effect of configuring the
interface or some such so we don't have to patch init/main.c
-g
>> prepare_namespace();
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Wednesday 03 Mar 2004 6:38 am, George Anzinger wrote:
> Amit S. Kale wrote:
> > OK to checkin.
> >
> > -Amit
> >
> > On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
> >>Hello. When we use kgdboe, we can't use it until do_basic_setup() is
> >> done. So we have two options, not allow kgdboe to use the initial
> >> breakpoint or move debugger_entry() to be past the point where kgdboe
> >> will be usable. I've opted for the latter, as if an earlier breakpoint
> >> is needed you can still use serial and throw
> >> kgdb_schedule_breakpoint/breakpoint where desired.
> >>
> >>--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
> >>+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17 11:33:51.854388988 -0700
> >>@@ -581,6 +582,7 @@ static int init(void * unused)
> >>
> >> smp_init();
> >> do_basic_setup();
> >>+ debugger_entry();
>
> It would be nice to not need this. Could it be a side effect of
> configuring the interface or some such so we don't have to patch
> init/main.c
I attempted doing this when I was trying to code a netpoll independent
ethernet interface. I couldn't do without it. I needed one hook to kgdb in
init to mark completion of smp_init. If an interface was ready, that hook
called breakpoint. A similar hook was placed in interface initialization
code, it called breakpoint, if kgdb core was ready on account of smp_init
completion.
-Amit
> -g
>
> >> prepare_namespace();
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
Amit S. Kale wrote:
> On Wednesday 03 Mar 2004 6:38 am, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>OK to checkin.
>>>
>>>-Amit
>>>
>>>On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
>>>
>>>>Hello. When we use kgdboe, we can't use it until do_basic_setup() is
>>>>done. So we have two options, not allow kgdboe to use the initial
>>>>breakpoint or move debugger_entry() to be past the point where kgdboe
>>>>will be usable. I've opted for the latter, as if an earlier breakpoint
>>>>is needed you can still use serial and throw
>>>>kgdb_schedule_breakpoint/breakpoint where desired.
>>>>
>>>>--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
>>>>+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17 11:33:51.854388988 -0700
>>>>@@ -581,6 +582,7 @@ static int init(void * unused)
>>>>
>>>> smp_init();
>>>> do_basic_setup();
>>>>+ debugger_entry();
>>
>>It would be nice to not need this. Could it be a side effect of
>>configuring the interface or some such so we don't have to patch
>>init/main.c
>
>
> I attempted doing this when I was trying to code a netpoll independent
> ethernet interface. I couldn't do without it. I needed one hook to kgdb in
> init to mark completion of smp_init. If an interface was ready, that hook
> called breakpoint. A similar hook was placed in interface initialization
> code, it called breakpoint, if kgdb core was ready on account of smp_init
> completion.
>
I guess the real question is why do you need to wait so long? What is it that
needs to be done prior to this call?
On the other hand, I have a late call (I use module init) to set up the
interrupt handler for the UART, which needs to happen after malloc is working.
This, however, does not cause, of it self, a break.
> -Amit
>
>
>
>
>>-g
>>
>>
>>>> prepare_namespace();
>>>
>>>-
>>>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>>>in the body of a message to [email protected]
>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>Please read the FAQ at http://www.tux.org/lkml/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Thu, Mar 11, 2004 at 01:24:59PM -0800, George Anzinger wrote:
> Amit S. Kale wrote:
> >On Wednesday 03 Mar 2004 6:38 am, George Anzinger wrote:
> >
> >>Amit S. Kale wrote:
> >>
> >>>OK to checkin.
> >>>
> >>>-Amit
> >>>
> >>>On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
> >>>
> >>>>Hello. When we use kgdboe, we can't use it until do_basic_setup() is
> >>>>done. So we have two options, not allow kgdboe to use the initial
> >>>>breakpoint or move debugger_entry() to be past the point where kgdboe
> >>>>will be usable. I've opted for the latter, as if an earlier breakpoint
> >>>>is needed you can still use serial and throw
> >>>>kgdb_schedule_breakpoint/breakpoint where desired.
> >>>>
> >>>>--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
> >>>>+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17
> >>>>11:33:51.854388988 -0700
> >>>>@@ -581,6 +582,7 @@ static int init(void * unused)
> >>>>
> >>>> smp_init();
> >>>> do_basic_setup();
> >>>>+ debugger_entry();
> >>
> >>It would be nice to not need this. Could it be a side effect of
> >>configuring the interface or some such so we don't have to patch
> >>init/main.c
> >
> >
> >I attempted doing this when I was trying to code a netpoll independent
> >ethernet interface. I couldn't do without it. I needed one hook to kgdb in
> >init to mark completion of smp_init. If an interface was ready, that hook
> >called breakpoint. A similar hook was placed in interface initialization
> >code, it called breakpoint, if kgdb core was ready on account of smp_init
> >completion.
> >
> I guess the real question is why do you need to wait so long? What is it
> that needs to be done prior to this call?
For kgdboe, you need to wait for the ethernet driver, networking, etc.
Without going and trying to do some big special case, that's when it has
to be, for kgdboe.
For serial, esp if you make kgdb_arch_init() handle kgdb_serial pointer,
it can happen much earlier. In fact, in that case you could probably
throw breakpoint() in as first line of C (PPC32) or close to it (some
mappings needed i386, sh, others, generally speaking).
--
Tom Rini
http://gate.crashing.org/~trini/
Tom Rini wrote:
> On Thu, Mar 11, 2004 at 01:24:59PM -0800, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>On Wednesday 03 Mar 2004 6:38 am, George Anzinger wrote:
>>>
>>>
>>>>Amit S. Kale wrote:
>>>>
>>>>
>>>>>OK to checkin.
>>>>>
>>>>>-Amit
>>>>>
>>>>>On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
>>>>>
>>>>>
>>>>>>Hello. When we use kgdboe, we can't use it until do_basic_setup() is
>>>>>>done. So we have two options, not allow kgdboe to use the initial
>>>>>>breakpoint or move debugger_entry() to be past the point where kgdboe
>>>>>>will be usable. I've opted for the latter, as if an earlier breakpoint
>>>>>>is needed you can still use serial and throw
>>>>>>kgdb_schedule_breakpoint/breakpoint where desired.
>>>>>>
>>>>>>--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
>>>>>>+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17
>>>>>>11:33:51.854388988 -0700
>>>>>>@@ -581,6 +582,7 @@ static int init(void * unused)
>>>>>>
>>>>>> smp_init();
>>>>>> do_basic_setup();
>>>>>>+ debugger_entry();
>>>>
>>>>It would be nice to not need this. Could it be a side effect of
>>>>configuring the interface or some such so we don't have to patch
>>>>init/main.c
>>>
>>>
>>>I attempted doing this when I was trying to code a netpoll independent
>>>ethernet interface. I couldn't do without it. I needed one hook to kgdb in
>>>init to mark completion of smp_init. If an interface was ready, that hook
>>>called breakpoint. A similar hook was placed in interface initialization
>>>code, it called breakpoint, if kgdb core was ready on account of smp_init
>>>completion.
>>>
>>
>>I guess the real question is why do you need to wait so long? What is it
>>that needs to be done prior to this call?
>
>
> For kgdboe, you need to wait for the ethernet driver, networking, etc.
> Without going and trying to do some big special case, that's when it has
> to be, for kgdboe.
>
> For serial, esp if you make kgdb_arch_init() handle kgdb_serial pointer,
> it can happen much earlier. In fact, in that case you could probably
> throw breakpoint() in as first line of C (PPC32) or close to it (some
> mappings needed i386, sh, others, generally speaking).
So the question is do we cater to the worst or the best? If I put kgdb or what
ever on the command line, I would like to see the connection ASAP what ever the
connection is. So possibly, the command line parse part of kgdb sets a flag it
it can not do the break NOW. The late bloomer code finds this flag when doing
the kgdboe or what ever set up and enters at that time. Puts a little more
smarts in the command line part, but gets things rolling ASAP regardless of the
interface. This, of course, assumes that the kgdboe or what ever has an
independent way of getting entered as soon as it can be set up, i.e. its
prerequisites are satisfied.
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Thu, Mar 11, 2004 at 02:49:16PM -0800, George Anzinger wrote:
> Tom Rini wrote:
[snip]
> >For kgdboe, you need to wait for the ethernet driver, networking, etc.
> >Without going and trying to do some big special case, that's when it has
> >to be, for kgdboe.
> >
> >For serial, esp if you make kgdb_arch_init() handle kgdb_serial pointer,
> >it can happen much earlier. In fact, in that case you could probably
> >throw breakpoint() in as first line of C (PPC32) or close to it (some
> >mappings needed i386, sh, others, generally speaking).
>
> So the question is do we cater to the worst or the best? If I put kgdb or
> what ever on the command line, I would like to see the connection ASAP what
> ever the connection is. So possibly, the command line parse part of kgdb
> sets a flag it it can not do the break NOW. The late bloomer code finds
> this flag when doing the kgdboe or what ever set up and enters at that
> time. Puts a little more smarts in the command line part, but gets things
> rolling ASAP regardless of the interface. This, of course, assumes that
> the kgdboe or what ever has an independent way of getting entered as soon
> as it can be set up, i.e. its prerequisites are satisfied.
This sound like what I passed along from dwmw2 a week ago I think. :)
--
Tom Rini
http://gate.crashing.org/~trini/
On Friday 12 Mar 2004 2:54 am, George Anzinger wrote:
> Amit S. Kale wrote:
> > On Wednesday 03 Mar 2004 6:38 am, George Anzinger wrote:
> >>Amit S. Kale wrote:
> >>>OK to checkin.
> >>>
> >>>-Amit
> >>>
> >>>On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
> >>>>Hello. When we use kgdboe, we can't use it until do_basic_setup() is
> >>>>done. So we have two options, not allow kgdboe to use the initial
> >>>>breakpoint or move debugger_entry() to be past the point where kgdboe
> >>>>will be usable. I've opted for the latter, as if an earlier breakpoint
> >>>>is needed you can still use serial and throw
> >>>>kgdb_schedule_breakpoint/breakpoint where desired.
> >>>>
> >>>>--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
> >>>>+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17 11:33:51.854388988
> >>>> -0700 @@ -581,6 +582,7 @@ static int init(void * unused)
> >>>>
> >>>> smp_init();
> >>>> do_basic_setup();
> >>>>+ debugger_entry();
> >>
> >>It would be nice to not need this. Could it be a side effect of
> >>configuring the interface or some such so we don't have to patch
> >>init/main.c
> >
> > I attempted doing this when I was trying to code a netpoll independent
> > ethernet interface. I couldn't do without it. I needed one hook to kgdb
> > in init to mark completion of smp_init. If an interface was ready, that
> > hook called breakpoint. A similar hook was placed in interface
> > initialization code, it called breakpoint, if kgdb core was ready on
> > account of smp_init completion.
>
> I guess the real question is why do you need to wait so long? What is it
> that needs to be done prior to this call?
2.4.x kgdb legacy code! That was needed in some early 2.4 kgdbs. Perhaps we
can move it earlier now. If someone tests the patch on an smp machine and
confirms that it works, I'll be happy change it.
The earlier kgdb is initialized, the better it is.
-Amit
>
> On the other hand, I have a late call (I use module init) to set up the
> interrupt handler for the UART, which needs to happen after malloc is
> working. This, however, does not cause, of it self, a break.
>
> > -Amit
> >
> >>-g
> >>
> >>>> prepare_namespace();
> >>>
> >>>-
> >>>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> >>>in the body of a message to [email protected]
> >>>More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>Please read the FAQ at http://www.tux.org/lkml/
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
On Fri, Mar 12, 2004 at 10:12:34AM +0530, Amit S. Kale wrote:
> On Friday 12 Mar 2004 2:54 am, George Anzinger wrote:
> > Amit S. Kale wrote:
> > > On Wednesday 03 Mar 2004 6:38 am, George Anzinger wrote:
> > >>Amit S. Kale wrote:
> > >>>OK to checkin.
> > >>>
> > >>>-Amit
> > >>>
> > >>>On Saturday 28 Feb 2004 3:24 am, Tom Rini wrote:
> > >>>>Hello. When we use kgdboe, we can't use it until do_basic_setup() is
> > >>>>done. So we have two options, not allow kgdboe to use the initial
> > >>>>breakpoint or move debugger_entry() to be past the point where kgdboe
> > >>>>will be usable. I've opted for the latter, as if an earlier breakpoint
> > >>>>is needed you can still use serial and throw
> > >>>>kgdb_schedule_breakpoint/breakpoint where desired.
> > >>>>
> > >>>>--- linux-2.6.3-rc4/init/main.c 2004-02-17 09:51:19.000000000 -0700
> > >>>>+++ linux-2.6.3-rc4-kgdb/init/main.c 2004-02-17 11:33:51.854388988
> > >>>> -0700 @@ -581,6 +582,7 @@ static int init(void * unused)
> > >>>>
> > >>>> smp_init();
> > >>>> do_basic_setup();
> > >>>>+ debugger_entry();
> > >>
> > >>It would be nice to not need this. Could it be a side effect of
> > >>configuring the interface or some such so we don't have to patch
> > >>init/main.c
> > >
> > > I attempted doing this when I was trying to code a netpoll independent
> > > ethernet interface. I couldn't do without it. I needed one hook to kgdb
> > > in init to mark completion of smp_init. If an interface was ready, that
> > > hook called breakpoint. A similar hook was placed in interface
> > > initialization code, it called breakpoint, if kgdb core was ready on
> > > account of smp_init completion.
> >
> > I guess the real question is why do you need to wait so long? What is it
> > that needs to be done prior to this call?
>
> 2.4.x kgdb legacy code! That was needed in some early 2.4 kgdbs. Perhaps we
> can move it earlier now. If someone tests the patch on an smp machine and
> confirms that it works, I'll be happy change it.
It's only legacy code under the following conditions (with current code):
- You don't care about getting an initial break from kgdboe (fixable...)
- kgdb_arch_init sets up kgdb_serial to an I/O that is suitably used
early on.
--
Tom Rini
http://gate.crashing.org/~trini/