Hi folks!
Probleme mit
Extrem langsamen Verbindungen... die erst nach dem Neustart des
Isdn subsystems wieder schneller werden.
Ewig lange Pingzeiten!?
Kernel: evtl ab 2.2 !
Im folgenden eine Mail von mir an den SuseSupport
ueber einen thread in de.alt.comm.isdn4linux!
M.f.G
Benjamin
-----schnippel------
SuSE Support wrote:
> Sehr geehrter Herr Rodewald,
>
> > sorry! die devices waren vorhanden aber nicht funtkionstuechtig!\
> > ich habe jetzt die devices geloescht und dannn mit den oben
genannten
> > Befehelen
> > wieder erstellt.
> > Es ist immernoch nur ttyI0 funktionstuechtig!
>
> Ihre Anfrage geht teilweise über den Installationssupport hinaus.
> Dieser ist in erster Linie gedacht als Hilfe zur grundlegenden
> Einrichtung eines lauffähigen Systems (Anhang H im Handbuch).
> Wir bitten um Ihr Verständnis, daß wir fortgeschrittene Themen
> wie Sie sie ansprechen, nicht erschöpfend beantworten können.
>
> Leider konnte ich dieses Verhalten hier nicht nachvollziehen.
>
tritt bei mehreren Leuten auf....
eine Bedingung fuer das Auftreten ist, das ISDN4linux als modul
kompiliert
wurde.
>
> > > > desweiteren verlangsammt sich meine syncppp verbindung manchal
> > > > erhaeblich. Nach einem reboot ist das letztere Problem fuer
einen
> > > > unbestimmten Zeitraum wieder beseitigt!
>
> Bitte senden Sie mir außerdem den output von
>
> netstat
>
Das Problem wird gerade in de.alt.comm.isdn4linux diskutert....ein Bug!
Ich dachte, dass sie an diesem Thread sicher Interesse haben,
ein paar Mails aus dem Thread sende ich Ihnen anbei!
M.f.G
B.Rodewald
-----------schnippp----- (mail #1) -----------begin---
From:
eis(a)baty.hanse.de (Henner Eisen)
Sender:
owner-isdn4linux(a)listserv.isdn4linux.de
Message-ID:
<199909161736.TAA11019(a)baty.hanse.de>
Date:
Thu, 16 Sep 1999 17:36:21 GMT
Newsgroups:
de.alt.comm.isdn4linux
Subject:
patch: isdn ppp performace problems
Return-Path:
<uucp(a)startrek.franken.de>
Delivered-To:
jrs(a)startrek.franken.de
MBOX-Line:
From listserv.isdn4linux.de!owner-isdn4linux Thu Sep 16
22:40:28 1999 remote from maulwurf
Precedence:
bulk
X-Loop:
isdn4linux
Path:
nntp.wolfsburg.de!news.planetc.com!uucp.muenster.de!newsfeed01.btx.dtag.de!newsfeed.tli.de!blackbush.xlink.net!news.wuecom.de!news.think.de!news.mayn.franken.de!startrek.franken.de!usenet
Xref:
nntp.wolfsburg.de de.alt.comm.isdn4linux:18075
Hi,
as regards the occasionnally observed spurious isdn ppp peformance
decrease
(e.g. the "ping delayed by multiples of a second" and "mppp slow down"
stuff), I detected a possible problem with isdn_ppp tx timeout recovery
that
might be the reason for this.
Could people who can reproduce those problems please try the follong
patch
and report whether it helps, does not help, or breaks something else?
(please add info about HL driver, ISDN_CONFIG options and ppp options
in affect to such a report). (I myself have tested with single link ppp
only). Please also report if you observe "isdn_ppp_xmit: sav_skb
timeout"
warning messages in the syslog.
The same patch applies against 2.2.12 as well as 2.3.18.
(it won't apply against recent 2.2.13pre).
Short description for those interested in the internals:
isdn_ppp maintains an internal queue of length 1 (stored in lp->sav_skb)
which is needed because skbuffs are copied for compression reasons.
Due to this, network device flow control cannot be done like for
usual network devices. I now detected a possible problem that a lost
BSENT statcallback could disturb the standard linux network device
tx timeout recovery. In therory, a lost BSENT statcallback could disturb
single link ppp partially and cause whole channels to die with multilink
ppp.
Anyway, the follwing patch adds a timeout recovery to isdn_ppp's
xmit paths and also prints a warning message if such a timeout condition
is detected.
It's currently unclear under which circumstances this error (missed/lost
BSENT
statcallback) could be actually triggered at all. (In therory, it
should not be possible with the HiSax driver). Thus, I'm very interested
in reports about the observed warning message.
Henner
diff -ur linux/drivers/isdn/isdn_net.c
linux-2.3.18-timeout/drivers/isdn/isdn_net.c
--- linux/drivers/isdn/isdn_net.c Sun Sep 5 20:28:59 1999
+++ linux-2.3.18-timeout/drivers/isdn/isdn_net.c Tue Sep 14
22:14:51
1999
@@ -607,4 +607,11 @@
(!lp->dialstate)) {
lp->stats.tx_packets++;
lp->stats.tx_bytes +=
c->parm.length;
+ /* some HL drivers deliver
+ ISDN_STAT_BSENT from hw
interrupt.
+ Output routines in isdn_ppp
are
now
+ called with irq disabled such
that
+ dequeueing the sav_skb while
another
+ frame is sent will not occur.
+ */
if (lp->p_encap ==
ISDN_NET_ENCAP_SYNCPPP &&
lp->sav_skb) {
diff -ur linux/drivers/isdn/isdn_ppp.c
linux-2.3.18-timeout/drivers/isdn/isdn_ppp.c
--- linux/drivers/isdn/isdn_ppp.c Sun Sep 5 20:28:59 1999
+++ linux-2.3.18-timeout/drivers/isdn/isdn_ppp.c Tue Sep 14
22:32:16
1999
@@ -1004,6 +1004,7 @@
lp->dialstate == 0 &&
(lp->flags & ISDN_NET_CONNECTED)) {
unsigned short hl;
+ unsigned long flags;
int cnt;
struct sk_buff *skb;
/*
@@ -1027,6 +1028,8 @@
isdn_ppp_send_ccp(lp->netdev,lp,skb); /* keeps
CCP/compression states in sync */
+ save_flags(flags);
+ cli();
if ((cnt =
isdn_writebuf_skb_stub(lp->isdn_device,
lp->isdn_channel, 1, skb)) != count) {
if (lp->sav_skb) {
dev_kfree_skb(lp->sav_skb);
@@ -1034,7 +1037,9 @@
} else
printk(KERN_INFO
"isdn_ppp_write:
Can't
write PPP frame to LL (%d,%d)!\n", cnt, count);
lp->sav_skb = skb;
+ lp->sav_time = jiffies;
}
+ restore_flags(flags);
}
}
return count;
@@ -1459,6 +1464,7 @@
isdn_net_dev *nd;
unsigned int proto = PPP_IP; /* 0x21 */
struct ippp_struct *ipt,*ipts;
+ unsigned long flags;
if (mdev)
mlp = (isdn_net_local *) (mdev->priv);
@@ -1511,12 +1517,24 @@
lp = nd->queue; /* get lp on top of queue */
- if (lp->sav_skb) { /* find a non-busy device */
- isdn_net_local *nlp = lp->next;
- while (lp->sav_skb) {
+ { /* find a non-busy device */
+ isdn_net_local *nlp = lp;
+ while (nlp->sav_skb) {
+ /* recover from a missing BSENT statcallback */
+ if( time_after(jiffies,nlp->sav_time+HZ) ){
+ unsigned long flags;
+ printk(KERN_WARNING "isdn_ppp_xmit:
sav_skb
timeout
on %s\n", nlp->name);
+ save_flags(flags);
+ cli();
+ if(nlp->sav_skb){
+ kfree_skb(nlp->sav_skb);
+ nlp->sav_skb = NULL;
+ }
+ restore_flags(flags);
+ }
+ nlp = nd->queue = nd->queue->next;
if (lp == nlp)
return 1;
- nlp = nd->queue = nd->queue->next;
}
lp = nlp;
}
@@ -1654,13 +1672,18 @@
printk(KERN_DEBUG "skb xmit: len: %d\n", (int)
skb->len);
isdn_ppp_frame_log("xmit", skb->data, skb->len,
32,ipt->unit,lp->ppp_slot);
}
+ save_flags(flags);
+ cli();
if (isdn_net_send_skb(netdev, lp, skb)) {
- if (lp->sav_skb) { /* whole sav_skb processing with
disabled
IRQs ?? */
+ if (lp->sav_skb) { /* should never happen as
sav_skb
are sent
with disabled IRQs) */
printk(KERN_ERR "%s: whoops .. there is another
stored
skb!\n", netdev->name);
dev_kfree_skb(skb);
- } else
+ } else {
lp->sav_skb = skb;
+ lp->sav_time = jiffies;
+ }
}
+ restore_flags(flags);
return 0;
}
@@ -2242,6 +2265,7 @@
struct sk_buff *skb;
unsigned char *p;
int count;
+ unsigned long flags;
int cnt = 0;
isdn_net_local *lp = is->lp;
@@ -2284,6 +2308,8 @@
especially dunno what the sav_skb stuff is good for. */
count = skb->len;
+ save_flags(flags);
+ cli();
if ((cnt = isdn_writebuf_skb_stub(lp->isdn_device,
lp->isdn_channel,
1, skb)) != count) {
if (lp->sav_skb) {
@@ -2296,7 +2322,10 @@
"isdn_ppp_write: Can't write PPP frame to
LL
(%d,%d)!\n",
cnt, count);
lp->sav_skb = skb;
+ lp->sav_time = jiffies;
+
}
+ restore_flags(flags);
}
/* Allocate the reset state vector */
@@ -3000,5 +3029,3 @@
}
return -EINVAL;
}
-
-
diff -ur linux/include/linux/isdn.h
linux-2.3.18-timeout/include/linux/isdn.h
--- linux/include/linux/isdn.h Sun Sep 5 20:29:01 1999
+++ linux-2.3.18-timeout/include/linux/isdn.h Tue Sep 14 21:34:21 1999
@@ -591,7 +591,8 @@
struct isdn_net_local_s *last; /* Ptr to last link in bundle
*/
struct isdn_net_dev_s *netdev; /* Ptr to netdev
*/
struct sk_buff *first_skb; /* Ptr to skb that triggers
dialing
*/
- struct sk_buff *sav_skb; /* Ptr to skb, rejected by
LL-driver*/
+ struct sk_buff *volatile sav_skb; /* Ptr to skb, rejected by
LL-driver*/
+ unsigned long sav_time; /* time when last sav_skb was set
*/
/* Ptr to orig.
hard_header_cache
*/
int (*org_hhc)(
struct neighbour *neigh,
---------------------------------------------------
To remove yourself from this mailing list send
email to majordomo(a)listserv.isdn4linux.de containing
"unsubscribe isdn4linux <your_email_address>" in
the message body.
-----------schnippp----- (mail #1) -----------end---
-----------schnippp----- (mail #2) -----------begin---
From:
eis(a)baty.hanse.de (Henner Eisen)
Sender:
owner-isdn4linux(a)listserv.isdn4linux.de
Message-ID:
<oulna2y94t.fsf(a)baty.hanse.de>
Date:
Sun, 19 Sep 1999 19:49:22 GMT
Newsgroups:
de.alt.comm.isdn4linux
Path:
nntp.wolfsburg.de!news.wolfsburg.de!jupiter.NIC.DTAG.DE!news-peer.gip.net!news.gsl.net!gip.net!newshub.northeast.verio.net!newspeer.monmouth.com!colt.net!newsfeed.icl.net!newsfeed.icl.net!newsfeed.nacamar.de!chico.franken.de!news.wuecom.de!news.think.de!news.mayn.franken.de!startrek.franken.de!usenet
References:
<XFMail.990918103028.wilhelm.spickermann(a)t-online.de>
Subject:
Re: patch: isdn ppp performace problems
Return-Path:
<uucp(a)startrek.franken.de>
Delivered-To:
jrs(a)startrek.franken.de
MBOX-Line:
From listserv.isdn4linux.de!owner-isdn4linux
Sun
Sep 19 23:20:22 1999 remote from maulwurf
X-Warning:
Original message contained 8-bit characters,
however during the SMTP transport session the receiving system was
unable
to announce capability of receiving 8-bit SMTP (RFC 1651-1653), and as
this
message does not have MIME headers (RFC 2045-2049) to enable encoding
change, we had very little choices.
X-Warning:
We ASSUME it is less harmful to add the MIME
headers, and convert the text to Quoted-Printable, than not to do so,
and
to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning:
We don't know what character set the user used,
thus we had to write these MIME-headers with our local system default
value.
MIME-Version:
1.0
Content-Transfer-Encoding:
QUOTED-PRINTABLE
Content-Type:
TEXT/PLAIN; charset=ISO-8859-1
X-Mailer:
Gnus v5.5/Emacs 20.3
Precedence:
bulk
X-Loop:
isdn4linux
Xref:
nntp.wolfsburg.de de.alt.comm.isdn4linux:18219
Wilhelm Spickermann <wilhelm.spickermann(a)t-online.de> writes:
Wilhelm> I can reproduce the problems but I´m using a 2.2.10 SuSE
Wilhelm> kernel. And whats more: the last reboot lead to 5 days of
Wilhelm> having no problems at all. Now the problems are easily
Wilhelm> reproducable again. So, I would prefer not to boot again
Wilhelm> ...
Does that mean you have reproduced the problem with my patch applied, or
just that you currently don´t dare to boot a new kernel with the
patch applied?
Wilhelm> I have observed ping packet delays of more than 20
Wilhelm> seconds using a normal ping going out every second. This
Wilhelm> leads to the conclusion, that a buffer of at least 20
This buffer is probably the queue in the linux packet scheduler
(outside isdn4linux), which is currently rather large for isdn devices
(ifconfig reports this as the txqueuelen value, default max len is
currently
30 for isdn).
Wilhelm> Packets is involved. (I don´t know the code and so I just
Wilhelm> react on seeing "length 1") Is this observation a
Wilhelm> possible result of the problem You are talking about?
This is an additional buffer in isdn_ppp (other encapsulations are not
affected by this).
Wilhelm> The kernel I´m using now is the SuSE 2.2.10 with a patch
Wilhelm> from Karsten Keil in ip_output.c line 323:
Wilhelm> "skb_set_owner_w(skb2, sk);" instead of
Wilhelm> "skb_set_owner_w(skb, sk);". It was made with .config
This was also a bug which I detected when hunting for the ippp
performance
problems but which I considered unlikly to be related to that problem.
Thus, your observation proves that it is unrelated.
Wilhelm> If one BSENT statcallback (I don´t know, what it is) is
Hardware level isdn drivers (like hisax) use it to tell the isdn link
layer
that a packet has been sucessfully sent out. The link layer can than
tell
the linux network layer that the isdn network device is ready to accept
more
packets.
Wilhelm> lost, would the effect be permanent? After producing the
Difficult to say. My first impression would be that for single link ppp
it should be possible to recover but for mutilink, a whole channel could
die permanently. But as there might be more complex interactions, I
don´t
know.
Wilhelm> effect, I have never observed it vanishing again.
Yes, when I observed this, it also always remained until I cleared
the isdn connection.
Wilhelm> Hmm, I´m using the HiSax-Driver.
Wilhelm> Using several ping processes concurrently results in the
Wilhelm> sum the delays being the same as before. (Plus the
Wilhelm> additional real delays of each ping)
Do you mean (e.g.) single ping: 4 seconds delay,
two simultaenous pings: 2 seconds each or 1+3 or 0+4
seconds delay?
Wilhelm> Just as a shot into the darkness: Somewhere there is a
Wilhelm> packet buffer with redundant administrative information,
Wilhelm> e.g. a write_pointer, a read_pointer and a count. This
Wilhelm> count variable is used concurrently by at least two
Wilhelm> processes and at least one of them does not update the
Wilhelm> variable atomically and avoiding caching. Or: near to the
Wilhelm> count variable is another variable, which is fetched and
Wilhelm> stored by cpu-instructions which grab the count-variable
Wilhelm> too, this would be an alignment problem. The result
Wilhelm> would be, that the count variable would not reflect the
Wilhelm> difference bewteen the read_pointer and the
Wilhelm> write_pointer. Packets would be read and written
Wilhelm> correctly, while some packets stay in the buffer until
Wilhelm> new packets arrive.
There is no count variable inside isdn_ppp, and the packet queues ouside
isdn use the normal linux packet queues (if such problems existed there,
then much larger problems would be probably observed with lots of
other network protocols). However, the pointer to store one packet
intermediately inside ppp was subject to such a non-atomic update
(could be considered as a boolean conter).
In the patch which I posted here I also included a fix against this
(that latter fix I already checked into CVS and it already in recent
2.2.13pre kernels).
Henner
---------------------------------------------------
To remove yourself from this mailing list send
email to majordomo(a)listserv.isdn4linux.de containing
"unsubscribe isdn4linux <your_email_address>" in
the message body.
-----------schnippp----- (mail #1) -----------end---
-----schnippel------
