headers
James Carlson | 1 Dec 19:18

Re: No packets get through after a while

Robert Voigt writes:
> I have a ppp connection from an embedded board with Fedora 7 (ppp 2.4.4,
> stock kernel-2.6.21) over null modem cable to a FC6 PC (ppp 2.4.4,
> kernel 2.6.18). I'm pinging from the board to the PC. After a while, it
> can be a few minutes or several hours, no packets from ping or anything
> else get through. It works again when I restart pppd on the board.

That sounds a lot like a flow control bug.  Have you tried running
without flow control enabled?

Do you have access to a serial line analyzer?

> The only thing I notice is when I start pppd on the commandline, when it
> hangs and I Ctrl-C it, it does not return. On the second Ctrl-C it says:
> tcsetattr: Interrupted system call (line 1001)
> It returns on the third Ctrl-C.

Ioctls that hang in the driver are, in my experience, typically the
result of flow control problems.

> I have tried a debug version of ppp 2.4.4. When it hangs the backtrace
> shows the last line in ppp code is sys-linux.c:1051
> void wait_input(struct timeval *timo)
> {
> ...
>     n = select(max_in_fd + 1, &ready, NULL, &exc, timo);
> ...
> }

That's the normal idle loop for pppd.  It _should_ be there while it's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Kaehlcke | 8 Dec 16:09
Picon

[PATCH] PPP synchronous tty: convert dead_sem to completion

PPP synchronous tty channel driver: convert the semaphore dead_sem to
a completion

Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke <at> gmail.com>

--

diff --git a/drivers/net/ppp_synctty.c b/drivers/net/ppp_synctty.c
index f0c6a19..f7472c8 100644
--- a/drivers/net/ppp_synctty.c
+++ b/drivers/net/ppp_synctty.c
@@ -42,9 +42,9 @@
 #include <linux/if_ppp.h>
 #include <linux/ppp_channel.h>
 #include <linux/spinlock.h>
+#include <linux/completion.h>
 #include <linux/init.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>

 #define PPP_VERSION	"2.4.2"

@@ -70,7 +70,7 @@ struct syncppp {
 	struct tasklet_struct tsk;

 	atomic_t	refcnt;
-	struct semaphore dead_sem;
+	struct completion dead_cmp;
 	struct ppp_channel chan;	/* interface to generic ppp layer */
 };
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Brady | 9 Dec 18:04
Picon
Picon

Re: [PATCH] PPP synchronous tty: convert dead_sem to completion


On Sat, 8 Dec 2007, Matthias Kaehlcke wrote:

> PPP synchronous tty channel driver: convert the semaphore dead_sem to
> a completion
>
> Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke <at> gmail.com>

Excuse my ignorance please, but why is this a good idea? Should we not 
record the reason for changes?
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Matthias Kaehlcke | 9 Dec 20:53
Picon

Re: [PATCH] PPP synchronous tty: convert dead_sem to completion

El Sun, Dec 09, 2007 at 12:04:48PM -0500 Charlie Brady ha dit:

>
> On Sat, 8 Dec 2007, Matthias Kaehlcke wrote:
>
>> PPP synchronous tty channel driver: convert the semaphore dead_sem to
>> a completion
>>
>> Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke <at> gmail.com>
>
> Excuse my ignorance please, but why is this a good idea? Should we not 
> record the reason for changes?

Semaphores can be used to signal completion of a job, but aren't the
optimal way to do so. According to LDD3 semaphores are optimized for
the 'available' case and performance suffers when using them as
completion. 

It is also clearer to use each synchronization mechanism according to
its purpose, i.e. semaphores for protection of critical sections and
completions for signalling that a job is done.

--

-- 
Matthias Kaehlcke
Linux System Developer
Barcelona

              You can't separate peace from freedom because no
               one can be at peace unless he has his freedom
                              (Malcolm X)
(Continue reading)

Permalink | Reply | 0 comments |
headers
ipcpblues | 12 Dec 22:15
Picon

IPCP-Nak doesn't do anything


Hi,

I'm trying to get two PPP devices to work together to setup a PPP
connection.  I have control over one of them - meaning I can set whatever
options I please - but I can't control the other device, it's options are
hard-wired.

I think I've almost got them working because they pass the LCP request - ack
stage and enter the IPCP stage.  In the IPCP stage, my IPCP-Req is Ack'd, so
I'm halfway there.  Their IPCP-Req is received by me with IP-addr=0.0.0.0
and I respond with IPCP-Nak IP-addr=192.168.20.50.  All this seems correct
to me, but then the device doesn't accept my Nak and either re-sends its
original IPCP-Req or goes back to the LCP-Req stage.  

Does any have ideas on why this could happen or something I can try?

My log is below, Thanks for reading :)

# pppd file options.pppBCM nodetach
pppd options in effect:
debug           # (from options.pppBCM)
nodetach                # (from command line)
dump            # (from options.pppBCM)
noauth          # (from options.pppBCM)
/dev/ttyUSB1            # (from options.pppBCM)
9600            # (from options.pppBCM)
lock            # (from options.pppBCM)
nocrtscts               # (from options.pppBCM)
asyncmap ffffffff               # (from options.pppBCM)
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Carlson | 12 Dec 22:36

Re: IPCP-Nak doesn't do anything

ipcpblues writes:
> I think I've almost got them working because they pass the LCP request - ack
> stage and enter the IPCP stage.  In the IPCP stage, my IPCP-Req is Ack'd, so
> I'm halfway there.  Their IPCP-Req is received by me with IP-addr=0.0.0.0
> and I respond with IPCP-Nak IP-addr=192.168.20.50.  All this seems correct
> to me, but then the device doesn't accept my Nak and either re-sends its
> original IPCP-Req or goes back to the LCP-Req stage.  

The peer is free to ignore your suggested IP address for any reason it
wants.  You cannot make it accept an address that it doesn't want.

Assuming you can't get debug logs out of the peer (in order to find
out why it doesn't like that address), I think the only thing you
could do would be to refuse to negotiate the addresses by adding
"ipcp-no-address ipcp-no-addresses".

> sent [LCP ConfReq id=0x1 <magic 0xec2490cf> <pcomp> <accomp>]
> rcvd [LCP ConfAck id=0x1 <magic 0xec2490cf> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <magic 0xec2490cf> <pcomp> <accomp>]
> rcvd [LCP ConfAck id=0x1 <magic 0xec2490cf> <pcomp> <accomp>]

This part is pretty suspicious and likely points to communications
errors on the path ...

> sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.30.1>]
> rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 192.168.30.1>]
> sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.30.1>]
> rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 192.168.30.1>]

... as does this.  Are you sure that the underlying link works and is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Unruh | 12 Dec 22:29
Picon
Picon
Favicon

Re: IPCP-Nak doesn't do anything

On Wed, 12 Dec 2007, ipcpblues wrote:

>
> Hi,
>
> I'm trying to get two PPP devices to work together to setup a PPP
> connection.  I have control over one of them - meaning I can set whatever
> options I please - but I can't control the other device, it's options are
> hard-wired.
>
> I think I've almost got them working because they pass the LCP request - ack
> stage and enter the IPCP stage.  In the IPCP stage, my IPCP-Req is Ack'd, so
> I'm halfway there.  Their IPCP-Req is received by me with IP-addr=0.0.0.0
> and I respond with IPCP-Nak IP-addr=192.168.20.50.  All this seems correct
> to me, but then the device doesn't accept my Nak and either re-sends its
> original IPCP-Req or goes back to the LCP-Req stage.
>
> Does any have ideas on why this could happen or something I can try?
>
> My log is below, Thanks for reading :)
>
> # pppd file options.pppBCM nodetach
> pppd options in effect:
> debug           # (from options.pppBCM)
> nodetach                # (from command line)

Why dump?

> dump            # (from options.pppBCM)
> noauth          # (from options.pppBCM)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Perches | 17 Dec 20:40

[PATCH] drivers/net/: Spelling fixes


Signed-off-by: Joe Perches <joe <at> perches.com>
---
 drivers/net/82596.c                            |    2 +-
 drivers/net/amd8111e.c                         |    8 ++++----
 drivers/net/amd8111e.h                         |    2 +-
 drivers/net/appletalk/ltpc.c                   |    2 +-
 drivers/net/atl1/atl1_hw.c                     |    2 +-
 drivers/net/atl1/atl1_main.c                   |    2 +-
 drivers/net/bonding/bond_3ad.c                 |    4 ++--
 drivers/net/chelsio/sge.c                      |    2 +-
 drivers/net/chelsio/subr.c                     |    2 +-
 drivers/net/cxgb3/t3_hw.c                      |    2 +-
 drivers/net/e1000/e1000_hw.c                   |    4 ++--
 drivers/net/e1000/e1000_hw.h                   |    2 +-
 drivers/net/e1000/e1000_main.c                 |    2 +-
 drivers/net/e1000e/netdev.c                    |    2 +-
 drivers/net/eepro.c                            |    2 +-
 drivers/net/ehea/ehea.h                        |    2 +-
 drivers/net/forcedeth.c                        |    2 +-
 drivers/net/hamachi.c                          |    4 ++--
 drivers/net/hp100.c                            |    2 +-
 drivers/net/hp100.h                            |    4 ++--
 drivers/net/ibm_emac/ibm_emac.h                |    2 +-
 drivers/net/ibm_newemac/emac.h                 |    2 +-
 drivers/net/ibmlana.c                          |    2 +-
 drivers/net/ibmlana.h                          |    2 +-
 drivers/net/ipg.c                              |    4 ++--
 drivers/net/irda/ali-ircc.c                    |    6 +++---
 drivers/net/irda/ali-ircc.h                    |    4 ++--
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Woodhouse | 17 Dec 22:15
Favicon

Re: [PATCH] drivers/net/: Spelling fixes

On Mon, 2007-12-17 at 11:40 -0800, Joe Perches wrote:
>  drivers/net/wireless/libertas/cmd.c            |    4 ++--
>  drivers/net/wireless/libertas/scan.c           |    4 ++--

I will apply these to the libertas tree; please remove them from any
resend of this patch.

If we were using git properly, it wouldn't matter -- I could just let
the patch go in upstream and when it gets merged, it'll be fine. But for
some reason we don't use git for network driver development; we pretend
it's the 1990s and we deal with sets of patches instead. So having this
simple change applied in an upstream tree would cause lots of pain, as
far as I can tell.

--

-- 
dwmw2

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Permalink | Reply | 0 comments |
headers
Joe Perches | 17 Dec 20:40

[PATCH] drivers/net/: Spelling fixes


Signed-off-by: Joe Perches <joe <at> perches.com>
---
 drivers/net/82596.c                            |    2 +-
 drivers/net/amd8111e.c                         |    8 ++++----
 drivers/net/amd8111e.h                         |    2 +-
 drivers/net/appletalk/ltpc.c                   |    2 +-
 drivers/net/atl1/atl1_hw.c                     |    2 +-
 drivers/net/atl1/atl1_main.c                   |    2 +-
 drivers/net/bonding/bond_3ad.c                 |    4 ++--
 drivers/net/chelsio/sge.c                      |    2 +-
 drivers/net/chelsio/subr.c                     |    2 +-
 drivers/net/cxgb3/t3_hw.c                      |    2 +-
 drivers/net/e1000/e1000_hw.c                   |    4 ++--
 drivers/net/e1000/e1000_hw.h                   |    2 +-
 drivers/net/e1000/e1000_main.c                 |    2 +-
 drivers/net/e1000e/netdev.c                    |    2 +-
 drivers/net/eepro.c                            |    2 +-
 drivers/net/ehea/ehea.h                        |    2 +-
 drivers/net/forcedeth.c                        |    2 +-
 drivers/net/hamachi.c                          |    4 ++--
 drivers/net/hp100.c                            |    2 +-
 drivers/net/hp100.h                            |    4 ++--
 drivers/net/ibm_emac/ibm_emac.h                |    2 +-
 drivers/net/ibm_newemac/emac.h                 |    2 +-
 drivers/net/ibmlana.c                          |    2 +-
 drivers/net/ibmlana.h                          |    2 +-
 drivers/net/ipg.c                              |    4 ++--
 drivers/net/irda/ali-ircc.c                    |    6 +++---
 drivers/net/irda/ali-ircc.h                    |    4 ++--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane