AX25 patches and how it affects the end user

AX25 patches and how it affects the end user

[Douglas Cole]

If all could bear with my ignorance, but with all these patches flying
around in the last few weeks, if I were to install the latest Debian
unstable downloaded ISO would that include all this work, so that when
I do the install I will have a working AX25 setup using kissattach? Or
do I still have to learn how to patch again (haven't done any patching
in 6 years)?


And thanks to all for the input on my previous thread, I have decided
to plunge into the world of Debian for my Amateur radio station setup,
I just hope I can keep my head above the water...

73


--
Douglas Cole
N7BFS

RE: AX25 patches and how it affects the end user

[Mike McCarthy, W1NR]

Hi Douglas,
   Your best bet is to run the latest "stable" release.  Unstable's are for
those with time and expertise to "hack".
   It all depends on when Debian updates it's kernel.  The patches have gone
into the latest "git" on Kernel.org.  When Debian fetches the kernel from
there is anyone's guess.  In about another week, SuSE will release 10.1
Beta1.  I don't even know if it will get into that.  You can always install
Debian and get the kernel source from kernel.org and build it.  I would at
least wait until 2.6.15.1 (in kernel.org's numbering) instead of trying to
patch things.
   If Debian is running the 2.6.14 kernel, then you are probably OK.  The
changes that broke it are not in that version.  These "patches" that you see
are due to recent changes for multiprocessor hardware, but other things got
broken at the same time.

Mike, W1NR

-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Douglas Cole
Sent: Wednesday, January 11, 2006 12:46 PM
To: linux-hams@vger.kernel.org
Subject: AX25 patches and how it affects the end user

If all could bear with my ignorance, but with all these patches flying
around in the last few weeks, if I were to install the latest Debian
unstable downloaded ISO would that include all this work, so that when I do
the install I will have a working AX25 setup using kissattach? Or do I still
have to learn how to patch again (haven't done any patching in 6 years)?


And thanks to all for the input on my previous thread, I have decided to
plunge into the world of Debian for my Amateur radio station setup, I just
hope I can keep my head above the water...

73


--
Douglas Cole
N7BFS
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: AX25 patches and how it affects the end user

[Douglas Cole]

On 1/11/06, Mike McCarthy, W1NR <lists@w1nr.net> wrote:
> Hi Douglas,
>    Your best bet is to run the latest "stable" release.  Unstable's are for
> those with time and expertise to "hack".
>    It all depends on when Debian updates it's kernel.  The patches have gone
> into the latest "git" on Kernel.org.  When Debian fetches the kernel from
> there is anyone's guess.  In about another week, SuSE will release 10.1
> Beta1.  I don't even know if it will get into that.  You can always install
> Debian and get the kernel source from kernel.org and build it.  I would at
> least wait until 2.6.15.1 (in kernel.org's numbering) instead of trying to
> patch things.
>    If Debian is running the 2.6.14 kernel, then you are probably OK.  The
> changes that broke it are not in that version.  These "patches" that you see
> are due to recent changes for multiprocessor hardware, but other things got
> broken at the same time.
>
> Mike, W1NR
Thanks Mike for the input, that helps :)
Unfortunately one of the machines will have an SMP setup, and so that
may be an issue for me, but I don't really want to run "stable" since
it seems to be soo far behind, either that or I am confused as to how
it all goes together, since what I saw on the Debian site was that
"stable" is still using kernel 2.4.xx, and of course I will not go
back to that, so the thought of using "unstable" and also as folks off
this list have told me that "unstable" was still "useable" which may
not mean useable for me, but maybe so...

I really don't want to try and compile a kernel, and its not so much
that I can't figure it out, as that I just don't have the time to
learn, which was why I went to SuSE so long ago, as I could get away
with never recompiling the kernel and make all things I wanted to
work...
So it goes I guess, if I want to continue on my adventure with Linux
and Amateur Radio I may have to spend more time computing and less
time talking (sigh)...

Thanks again for the input, and I will try and sort out the actual
kernel version that Deb' is using and try and make it work...

73
Doug
N7BFS

>
> -----Original Message-----
> From: linux-hams-owner@vger.kernel.org
> [mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Douglas Cole
> Sent: Wednesday, January 11, 2006 12:46 PM
> To: linux-hams@vger.kernel.org
> Subject: AX25 patches and how it affects the end user
>
> If all could bear with my ignorance, but with all these patches flying
> around in the last few weeks, if I were to install the latest Debian
> unstable downloaded ISO would that include all this work, so that when I do
> the install I will have a working AX25 setup using kissattach? Or do I still
> have to learn how to patch again (haven't done any patching in 6 years)?
>
>
> And thanks to all for the input on my previous thread, I have decided to
> plunge into the world of Debian for my Amateur radio station setup, I just
> hope I can keep my head above the water...

Re: AX25 patches and how it affects the end user

[Ralf Baechle DL5RB]

On Wed, Jan 11, 2006 at 05:14:05PM -0500, Mike McCarthy, W1NR wrote:

> Hi Douglas,
>    Your best bet is to run the latest "stable" release.  Unstable's are for
> those with time and expertise to "hack".
>    It all depends on when Debian updates it's kernel.  The patches have gone
> into the latest "git" on Kernel.org.  When Debian fetches the kernel from
> there is anyone's guess.  In about another week, SuSE will release 10.1
> Beta1.  I don't even know if it will get into that.  You can always install
> Debian and get the kernel source from kernel.org and build it.  I would at
> least wait until 2.6.15.1 (in kernel.org's numbering) instead of trying to
> patch things.
>    If Debian is running the 2.6.14 kernel, then you are probably OK.  The
> changes that broke it are not in that version.  These "patches" that you see
> are due to recent changes for multiprocessor hardware, but other things got
> broken at the same time.

Not quite.  The locking bugs in mkiss were introduced when adding SMACK
support.  When a little later the locking code - really only relevant to
multiprocessor or preemptable kernels - was changed, the bugs started to
show up on uniprocessor kernels as well.

Shit happens - but better let's fix it.

  Ralf

Re: AX25 patches and how it affects the end user

[Bernard Pidoux]

Hi,

After applying mkiss patch to kernel 2.6.15.1 I compiled it for a 3 GHz 
Xeon P4 configuring it for SMP and multithread plus lock options.

The SMP kernel seems very sensitive to AX25 configuration errors and it 
locks up quite soon in that case when loading applications.

However when ax25 is carefully initialized, mkiss, kissattach, ax25ipd 
and ROSE/FPAC switch software suite) are running without problem.

But there is still a spinlock lockup when shutting down the system.

Here is a copy of the sequence I made by hand (subject to errors) :

Spinlock lockup on CPU#0, kissattach / 5048, f8d68714
EIP <c01e3ba5>
rose_remove_neigh + 0x30/0xb0 [rose]
rose_rt_device_down + 0xeb / 0x120 [rose]
rose_device_event + 0x42/0x50 [rose]
notifier_call_chain + 0x2/0x50 [rose]
dev_close + 0x7b/0xb0
unregister_netdevice + 0x19e/0x250
unregister_netdev+0x16/0x1d
mkiss_close + 0x4a /0xa0 [mkiss]
release_dev....
tty_release ...

Hope this can help.
Please suggest any more test to be done.

-----------------

Ralf Baechle DL5RB wrote :
> On Wed, Jan 11, 2006 at 05:14:05PM -0500, Mike McCarthy, W1NR wrote:
> 
> 
>>Hi Douglas,
>>   Your best bet is to run the latest "stable" release.  Unstable's are for
>>those with time and expertise to "hack".
>>   It all depends on when Debian updates it's kernel.  The patches have gone
>>into the latest "git" on Kernel.org.  When Debian fetches the kernel from
>>there is anyone's guess.  In about another week, SuSE will release 10.1
>>Beta1.  I don't even know if it will get into that.  You can always install
>>Debian and get the kernel source from kernel.org and build it.  I would at
>>least wait until 2.6.15.1 (in kernel.org's numbering) instead of trying to
>>patch things.
>>   If Debian is running the 2.6.14 kernel, then you are probably OK.  The
>>changes that broke it are not in that version.  These "patches" that you see
>>are due to recent changes for multiprocessor hardware, but other things got
>>broken at the same time.
> 
> 
> Not quite.  The locking bugs in mkiss were introduced when adding SMACK
> support.  When a little later the locking code - really only relevant to
> multiprocessor or preemptable kernels - was changed, the bugs started to
> show up on uniprocessor kernels as well.
> 
> Shit happens - but better let's fix it.
> 
>   Ralf

-- 

73 de Bernard, f6bvp

http://f6bvp.free.fr
http://f6bvp.org (mirror)
http://rose.fpac.free.fr/

Re: AX25 patches and how it affects the end user

[Ralf Baechle DL5RB]

On Tue, Jan 17, 2006 at 05:59:33PM +0100, Bernard Pidoux wrote:

> After applying mkiss patch to kernel 2.6.15.1 I compiled it for a 3 GHz 
> Xeon P4 configuring it for SMP and multithread plus lock options.
> 
> The SMP kernel seems very sensitive to AX25 configuration errors and it 
> locks up quite soon in that case when loading applications.
> 
> However when ax25 is carefully initialized, mkiss, kissattach, ax25ipd 
> and ROSE/FPAC switch software suite) are running without problem.
> 
> But there is still a spinlock lockup when shutting down the system.
> 
> Here is a copy of the sequence I made by hand (subject to errors) :

Thanks.  Btw, in some cases digital cameras have served well to catch
messages from screens without types - just make sure the images aren't
larger than necessary to be readable.

> Spinlock lockup on CPU#0, kissattach / 5048, f8d68714
> EIP <c01e3ba5>
> rose_remove_neigh + 0x30/0xb0 [rose]
> rose_rt_device_down + 0xeb / 0x120 [rose]
> rose_device_event + 0x42/0x50 [rose]
> notifier_call_chain + 0x2/0x50 [rose]
> dev_close + 0x7b/0xb0
> unregister_netdevice + 0x19e/0x250
> unregister_netdev+0x16/0x1d
> mkiss_close + 0x4a /0xa0 [mkiss]
> release_dev....
> tty_release ...
> 
> Hope this can help.
> Please suggest any more test to be done.

I think the ROSE routing code is beyond recovery.  The current data
structures requires extensive locking code that is easily prone to
deadlocks like this.  It also is slow - fortunately nobody is using ROSE
on highspeed links ...

Anyway, the problem is pretty obvious in your traceback and I'll cook a
patch for you to test.

73,

  Ralf

Re: ROSE lockup fix

[Ralf Baechle DL5RB]

On Wed, Jan 18, 2006 at 01:08:43AM +0000, Ralf Baechle DL5RB wrote:

> Anyway, the problem is pretty obvious in your traceback and I'll cook a
> patch for you to test.

Can you test the patch below?

  Ralf

 net/rose/rose_route.c |    7 -------
 1 files changed, 7 deletions(-)

Index: linux-mips/net/rose/rose_route.c
===================================================================
--- linux-mips.orig/net/rose/rose_route.c
+++ linux-mips/net/rose/rose_route.c
@@ -48,8 +48,6 @@ static DEFINE_SPINLOCK(rose_route_list_l
 
 struct rose_neigh *rose_loopback_neigh;
 
-static void rose_remove_neigh(struct rose_neigh *);
-
 /*
  *	Add a new route to a node, and in the process add the node and the
  *	neighbour if it is new.
@@ -235,11 +233,8 @@ static void rose_remove_neigh(struct ros
 
 	skb_queue_purge(&rose_neigh->queue);
 
-	spin_lock_bh(&rose_neigh_list_lock);
-
 	if ((s = rose_neigh_list) == rose_neigh) {
 		rose_neigh_list = rose_neigh->next;
-		spin_unlock_bh(&rose_neigh_list_lock);
 		kfree(rose_neigh->digipeat);
 		kfree(rose_neigh);
 		return;
@@ -248,7 +243,6 @@ static void rose_remove_neigh(struct ros
 	while (s != NULL && s->next != NULL) {
 		if (s->next == rose_neigh) {
 			s->next = rose_neigh->next;
-			spin_unlock_bh(&rose_neigh_list_lock);
 			kfree(rose_neigh->digipeat);
 			kfree(rose_neigh);
 			return;
@@ -256,7 +250,6 @@ static void rose_remove_neigh(struct ros
 
 		s = s->next;
 	}
-	spin_unlock_bh(&rose_neigh_list_lock);
 }
 
 /*

Re: ROSE lockup fix

[Bernard Pidoux]

Hi Ralf,

Sorry but I applied the patch and it did not change the problem.
When shutting down the system there is still a spinlock error.

I made some pictures of the different trials in order to compare.

The message actually starts with for example :

BUG: spinlock recursion on CPU#1, kissattach/5094
  lock: f8d68714, .magic: dead4ead, .owner: kissattach/5094, .owner_cpu: 1

Even if the name of the program may change i.e. kissattach or ax25ipd, 
the associated /5094 and address after lock remains the same.
Also it can be CPU#0 or CPU#1

The rest of the track displays exactly the same sequence I reported on 
the previous message.

Do we have another chance to track this "spinlock recursion" ?

---------------

Ralf Baechle DL5RB a écrit :
> On Wed, Jan 18, 2006 at 01:08:43AM +0000, Ralf Baechle DL5RB wrote:
> 
> 
>>Anyway, the problem is pretty obvious in your traceback and I'll cook a
>>patch for you to test.
> 
> 
> Can you test the patch below?
> 
>   Ralf
> 
>  net/rose/rose_route.c |    7 -------
>  1 files changed, 7 deletions(-)
> 
> Index: linux-mips/net/rose/rose_route.c
> ===================================================================
> --- linux-mips.orig/net/rose/rose_route.c
> +++ linux-mips/net/rose/rose_route.c
> @@ -48,8 +48,6 @@ static DEFINE_SPINLOCK(rose_route_list_l
>  
>  struct rose_neigh *rose_loopback_neigh;
>  
> -static void rose_remove_neigh(struct rose_neigh *);
> -
>  /*
>   *	Add a new route to a node, and in the process add the node and the
>   *	neighbour if it is new.
> @@ -235,11 +233,8 @@ static void rose_remove_neigh(struct ros
>  
>  	skb_queue_purge(&rose_neigh->queue);
>  
> -	spin_lock_bh(&rose_neigh_list_lock);
> -
>  	if ((s = rose_neigh_list) == rose_neigh) {
>  		rose_neigh_list = rose_neigh->next;
> -		spin_unlock_bh(&rose_neigh_list_lock);
>  		kfree(rose_neigh->digipeat);
>  		kfree(rose_neigh);
>  		return;
> @@ -248,7 +243,6 @@ static void rose_remove_neigh(struct ros
>  	while (s != NULL && s->next != NULL) {
>  		if (s->next == rose_neigh) {
>  			s->next = rose_neigh->next;
> -			spin_unlock_bh(&rose_neigh_list_lock);
>  			kfree(rose_neigh->digipeat);
>  			kfree(rose_neigh);
>  			return;
> @@ -256,7 +250,6 @@ static void rose_remove_neigh(struct ros
>  
>  		s = s->next;
>  	}
> -	spin_unlock_bh(&rose_neigh_list_lock);
>  }
>  
>  /*
> 
> 

-- 

73 de Bernard, f6bvp

http://f6bvp.free.fr
http://f6bvp.org (mirror)
http://rose.fpac.free.fr/
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ROSE lockup fix

[Bernard Pidoux]

Hi Ralf,

I applied your rose patch to the more recent kernel 2.6.15.2 and it 
seems to work fine as there are no more spinlock recursion related to 
rose when killall during reboot process.

However I observed a new problem only once.

Here is the screen dump copied from a digital photo
(I did not copy the <numbers> but only symbolic names) :

Sending all processes the TERM signal...
BUG: spinlock bad magic on CPU#0, ax25ipd/4703
  lock: ea6b4318, .magic: 00000000, .owner: <none>/-1, .owner_cpu:0
dump_stack
spin_bug
_raw_spin_lock
_spin_lock_irqsave
__wake_up
sock_def_write_space
sock_wfree
__kfree_skb
skb_queue_purge
ax25_clear_queues   [ax25]
ax25_disconnect     [ax25]
ax25_kill_by_device [ax25]
ax25_device_event   [ax25]
notifier_call_chain
dev_close
unregister_netdevice
unregister_netdev
mkiss_close         [mkiss]
release_dev
tty_release
__fput
fput
filp_close
put_files_struct
do_exit
do_group_exit
sys_exit_group
sysenter_past_esp

---------------------------

Ralf Baechle DL5RB wrote :
> On Wed, Jan 18, 2006 at 01:08:43AM +0000, Ralf Baechle DL5RB wrote:
> 
> 
>>Anyway, the problem is pretty obvious in your traceback and I'll cook a
>>patch for you to test.
> 
> 
> Can you test the patch below?
> 
>   Ralf
> 
>  net/rose/rose_route.c |    7 -------
>  1 files changed, 7 deletions(-)
> 
> Index: linux-mips/net/rose/rose_route.c
> ===================================================================
> --- linux-mips.orig/net/rose/rose_route.c
> +++ linux-mips/net/rose/rose_route.c
> @@ -48,8 +48,6 @@ static DEFINE_SPINLOCK(rose_route_list_l
>  
>  struct rose_neigh *rose_loopback_neigh;
>  
> -static void rose_remove_neigh(struct rose_neigh *);
> -
>  /*
>   *	Add a new route to a node, and in the process add the node and the
>   *	neighbour if it is new.
> @@ -235,11 +233,8 @@ static void rose_remove_neigh(struct ros
>  
>  	skb_queue_purge(&rose_neigh->queue);
>  
> -	spin_lock_bh(&rose_neigh_list_lock);
> -
>  	if ((s = rose_neigh_list) == rose_neigh) {
>  		rose_neigh_list = rose_neigh->next;
> -		spin_unlock_bh(&rose_neigh_list_lock);
>  		kfree(rose_neigh->digipeat);
>  		kfree(rose_neigh);
>  		return;
> @@ -248,7 +243,6 @@ static void rose_remove_neigh(struct ros
>  	while (s != NULL && s->next != NULL) {
>  		if (s->next == rose_neigh) {
>  			s->next = rose_neigh->next;
> -			spin_unlock_bh(&rose_neigh_list_lock);
>  			kfree(rose_neigh->digipeat);
>  			kfree(rose_neigh);
>  			return;
> @@ -256,7 +250,6 @@ static void rose_remove_neigh(struct ros
>  
>  		s = s->next;
>  	}
> -	spin_unlock_bh(&rose_neigh_list_lock);
>  }
>  
>  /*
> -
> To unsubscribe from this list: send the line "unsubscribe linux-hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 

73 de Bernard, f6bvp

http://f6bvp.free.fr
http://f6bvp.org (mirror)
http://rose.fpac.free.fr/

Re: AX25 patches and how it affects the end user

[Chuck Hast]

On 1/17/06, Ralf Baechle DL5RB <ralf@linux-mips.org> wrote:
> On Tue, Jan 17, 2006 at 05:59:33PM +0100, Bernard Pidoux wrote:
>
> > After applying mkiss patch to kernel 2.6.15.1 I compiled it for a 3 GHz
> > Xeon P4 configuring it for SMP and multithread plus lock options.
> >
> > The SMP kernel seems very sensitive to AX25 configuration errors and it
> > locks up quite soon in that case when loading applications.
> >
> > However when ax25 is carefully initialized, mkiss, kissattach, ax25ipd
> > and ROSE/FPAC switch software suite) are running without problem.
> >
> > But there is still a spinlock lockup when shutting down the system.
> >
> > Here is a copy of the sequence I made by hand (subject to errors) :
>
> Thanks.  Btw, in some cases digital cameras have served well to catch
> messages from screens without types - just make sure the images aren't
> larger than necessary to be readable.
>
> > Spinlock lockup on CPU#0, kissattach / 5048, f8d68714
> > EIP <c01e3ba5>
> > rose_remove_neigh + 0x30/0xb0 [rose]
> > rose_rt_device_down + 0xeb / 0x120 [rose]
> > rose_device_event + 0x42/0x50 [rose]
> > notifier_call_chain + 0x2/0x50 [rose]
> > dev_close + 0x7b/0xb0
> > unregister_netdevice + 0x19e/0x250
> > unregister_netdev+0x16/0x1d
> > mkiss_close + 0x4a /0xa0 [mkiss]
> > release_dev....
> > tty_release ...
> >
> > Hope this can help.
> > Please suggest any more test to be done.
>
> I think the ROSE routing code is beyond recovery.  The current data
> structures requires extensive locking code that is easily prone to
> deadlocks like this.  It also is slow - fortunately nobody is using ROSE
> on highspeed links ...
>
> Anyway, the problem is pretty obvious in your traceback and I'll cook a
> patch for you to test.
>

What do you consider high speed links? We will be doing so in Florida
as we move the switches around the state to Linux. Some of these devices
will be linked over 802.11 type links.

--
Chuck Hast  -- KP4DJT --
To paraphrase my flight instructor;
"the only dumb question is the one you DID NOT ask resulting in my going
out and having to identify your bits and pieces in the midst of torn
and twisted metal."

Re: AX25 patches and how it affects the end user

[Ralf Baechle DL5RB]

On Wed, Jan 18, 2006 at 07:26:45AM -0500, Chuck Hast wrote:

> > > After applying mkiss patch to kernel 2.6.15.1 I compiled it for a 3 GHz
> > > Xeon P4 configuring it for SMP and multithread plus lock options.
> > >
> > > The SMP kernel seems very sensitive to AX25 configuration errors and it
> > > locks up quite soon in that case when loading applications.
> > >
> > > However when ax25 is carefully initialized, mkiss, kissattach, ax25ipd
> > > and ROSE/FPAC switch software suite) are running without problem.
> > >
> > > But there is still a spinlock lockup when shutting down the system.
> > >
> > > Here is a copy of the sequence I made by hand (subject to errors) :
> >
> > Thanks.  Btw, in some cases digital cameras have served well to catch
> > messages from screens without types - just make sure the images aren't
> > larger than necessary to be readable.
> >
> > > Spinlock lockup on CPU#0, kissattach / 5048, f8d68714
> > > EIP <c01e3ba5>
> > > rose_remove_neigh + 0x30/0xb0 [rose]
> > > rose_rt_device_down + 0xeb / 0x120 [rose]
> > > rose_device_event + 0x42/0x50 [rose]
> > > notifier_call_chain + 0x2/0x50 [rose]
> > > dev_close + 0x7b/0xb0
> > > unregister_netdevice + 0x19e/0x250
> > > unregister_netdev+0x16/0x1d
> > > mkiss_close + 0x4a /0xa0 [mkiss]
> > > release_dev....
> > > tty_release ...
> > >
> > > Hope this can help.
> > > Please suggest any more test to be done.
> >
> > I think the ROSE routing code is beyond recovery.  The current data
> > structures requires extensive locking code that is easily prone to
> > deadlocks like this.  It also is slow - fortunately nobody is using ROSE
> > on highspeed links ...
> >
> > Anyway, the problem is pretty obvious in your traceback and I'll cook a
> > patch for you to test.
> >
> 
> What do you consider high speed links? We will be doing so in Florida
> as we move the switches around the state to Linux. Some of these devices
> will be linked over 802.11 type links.

That certainly would be a fast link.  There are not only the limits of
the code itself but also the design limits of the connected mode protocols
themselves which become a theoretical limit for what is possible with
AX.25.

  Ralf