kgdb: fix kgdbeth compilation and make it init late enough

kgdb: fix kgdbeth compilation and make it init late enough

[Pavel Machek]

Hi!

CONFIG_NO_KGDB_CPUS can not be found anywhere in the patches => its
probably not needd any more. init_kgdboe can't be module_initcall; in
such cases it initializes after tg3 network card (and that's bad).

Okay to commit?
								Pavel

--- clean-mm/drivers/net/kgdb_eth.c	2004-03-01 22:03:55.000000000 +0100
+++ linux-mm/drivers/net/kgdb_eth.c	2004-03-01 23:00:07.000000000 +0100
@@ -157,15 +157,6 @@
 
 static int init_kgdboe(void)
 {
-#ifdef CONFIG_SMP
-	if (num_online_cpus() > CONFIG_NO_KGDB_CPUS) {
-		printk
-		    ("kgdb: too manu cpus. Cannot enable debugger with more than %d cpus\n",
-		     CONFIG_NO_KGDB_CPUS);
-		return -1;
-	}
-#endif
-
 	if (!np.remote_ip || netpoll_setup(&np))
 		return 1;
 
@@ -176,4 +167,4 @@
 	return 0;
 }
 
-module_init(init_kgdboe);
+late_initcall(init_kgdboe);		/* This needs to be done after netcard is initialized */ 

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: kgdb: fix kgdbeth compilation and make it init late enough

[Tom Rini]

On Tue, Mar 02, 2004 at 12:25:00PM +0100, Pavel Machek wrote:

> Hi!
> 
> CONFIG_NO_KGDB_CPUS can not be found anywhere in the patches => its
> probably not needd any more.

I don't know if we can do that.  There's some funky locking stuff done
on SMP, which for some reason can't be done to NR_CPUS (or, no one has
tried doing that).

> init_kgdboe can't be module_initcall; in
> such cases it initializes after tg3 network card (and that's bad).

Ah, that's an even better fix than trying to enforce link order.

> Okay to commit?

Second half, yes.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: kgdb: fix kgdbeth compilation and make it init late enough

[Pavel Machek]

Hi!

> > CONFIG_NO_KGDB_CPUS can not be found anywhere in the patches => its
> > probably not needd any more.
> 
> I don't know if we can do that.  There's some funky locking stuff done
> on SMP, which for some reason can't be done to NR_CPUS (or, no one has
> tried doing that).

There was no CONFIG_NO_KGDB_CPUS anywhere else in the CVS, that means
that test could not have been right.

This could be related:

+#ifndef KGDB_MAX_NO_CPUS
+#if CONFIG_NR_CPUS > 8
+#error KGDB can handle max 8 CPUs
+#endif
+#define KGDB_MAX_NO_CPUS 8
+#endif

> > init_kgdboe can't be module_initcall; in
> > such cases it initializes after tg3 network card (and that's bad).
> 
> Ah, that's an even better fix than trying to enforce link order.
> 
> > Okay to commit?
> 
> Second half, yes.

I already commited both, sorry. 

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: kgdb: fix kgdbeth compilation and make it init late enough

[Tom Rini]

On Tue, Mar 02, 2004 at 11:28:27PM +0100, Pavel Machek wrote:

> Hi!
> 
> > > CONFIG_NO_KGDB_CPUS can not be found anywhere in the patches => its
> > > probably not needd any more.
> > 
> > I don't know if we can do that.  There's some funky locking stuff done
> > on SMP, which for some reason can't be done to NR_CPUS (or, no one has
> > tried doing that).
> 
> There was no CONFIG_NO_KGDB_CPUS anywhere else in the CVS, that means
> that test could not have been right.

That doesn't mean the right answer is to remove it.  However, after
talking with George (who might speak up now anyhow) for 2.6 we can just
do the SMP locking stuff at NR_CPUS, since that's configurable.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: kgdb: fix kgdbeth compilation and make it init late enough

[George Anzinger]

Tom Rini wrote:
> On Tue, Mar 02, 2004 at 11:28:27PM +0100, Pavel Machek wrote:
> 
> 
>>Hi!
>>
>>
>>>>CONFIG_NO_KGDB_CPUS can not be found anywhere in the patches => its
>>>>probably not needd any more.
>>>
>>>I don't know if we can do that.  There's some funky locking stuff done
>>>on SMP, which for some reason can't be done to NR_CPUS (or, no one has
>>>tried doing that).
>>
>>There was no CONFIG_NO_KGDB_CPUS anywhere else in the CVS, that means
>>that test could not have been right.
> 
> 
> That doesn't mean the right answer is to remove it.  However, after
> talking with George (who might speak up now anyhow) for 2.6 we can just
> do the SMP locking stuff at NR_CPUS, since that's configurable.

The old CONFIG_NO_KGDB_CPUS only affected the kgdb_info array.  Its only purpose 
was to shorten the array as it I displayed it fairly often and having a bunch of 
unused stuff at the end was a bother.  Now that 2.6 lets you define this, it is 
no longer needed.

> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: kgdb: fix kgdbeth compilation and make it init late enough

[Pavel Machek]

Hi!

> > CONFIG_NO_KGDB_CPUS can not be found anywhere in the patches => its
> > probably not needd any more.
> 
> I don't know if we can do that.  There's some funky locking stuff done
> on SMP, which for some reason can't be done to NR_CPUS (or, no one has
> tried doing that).

There seems to be KGDB_MAX_NO_CPUS, but as 8250 patch does not check
it, I believe that eth has no business checking it either.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: kgdb: fix kgdbeth compilation and make it init late enough

[George Anzinger]

Pavel Machek wrote:
> Hi!
> 
> 
>>>CONFIG_NO_KGDB_CPUS can not be found anywhere in the patches => its
>>>probably not needd any more.
>>
>>I don't know if we can do that.  There's some funky locking stuff done
>>on SMP, which for some reason can't be done to NR_CPUS (or, no one has
>>tried doing that).
> 
> 
> There seems to be KGDB_MAX_NO_CPUS, but as 8250 patch does not check
> it, I believe that eth has no business checking it either.

I have not seen this one before.  It must be from Amit's patch base.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml