This is Bugs.rtf in view mode; [Download] [Up]
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
18 Submitted: perkins Jul 31 1996 00:00
Topic: /PPP-2.x/Kernel Server/Panic/
Status: New Bug
Severity: System Hang/Crash
Priority: Unknown
Possible panics by Chat and kermit
[perkins Wed Jul 31 08:52:54 EDT 1996]
X-POP3-Rcpt: perkins@tsc
Date: Thu, 25 Jul 1996 11:04:32 -0500
Reply-To: gjditchf@cs.UManitoba.CA
Sender: nextppp@chinx1.thoughtport.com
From: Glen Ditchfield <gjditchf@cs.UManitoba.CA>
To: Multiple recipients of list <nextppp@chinx1.thoughtport.com>
Subject: System panic worked around
X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas
X-Comment: To unsubscribe send message to listproc@listproc.thoughtport.com
Some time ago I reported system panics on a NeXTstation with 32 meg of real
memory, running Nextstep 3.2 and ppp 2.2-0.4.6. The panics occurred while
connecting if I used a Kermit macro or the chat program to connect to my
ISP. They didn't occur if I used kermit to connect manually and then ran
pppup.
I switched to PAP authentication, and the panics went away. Here's a
working kermit script:
--------------------
define pppup -
dial 5551212, -
if failure stop 1 No connection, -
!pppd < \v(line) > \v(line) defaultroute
--------------------
and here's a working pppup script. (The commented line caused panics. The
script worked without the -detach option, too.)
--------------------
#!/bin/sh
#
# Create a ppp connection to MBNet
# Use the options in /etc/ppp/options.
#
#/usr/local/bin/pppd -vj connect '/usr/local/bin/chat -v ABORT BUSY ABORT "NO CARRIER" "" ATZ0 OK ATDT5551212 "CONNECT 57600" "" name:--name: gjditchf ssword: ???????? "uit" 1' /dev/cufa 57600
/usr/local/bin/pppd -detach connect '/usr/local/bin/chat -v ABORT BUSY ABORT "NO CARRIER" "" ATZ0 OK ATDT5551212 "CONNECT 57600"' /dev/cufa 57600 exit 0
--------------------
In my case the panics seem to have something to do with the length of the
dialing process -- maybe time elapsed, maybe virtual memory used, ... ?
X-POP3-Rcpt: perkins@tsc
Date: Fri, 26 Jul 1996 11:49:38 -0500
Reply-To: gjditchf@cs.UManitoba.CA
Sender: nextppp@chinx1.thoughtport.com
From: Glen Ditchfield <gjditchf@cs.UManitoba.CA>
To: Multiple recipients of list <nextppp@chinx1.thoughtport.com>
Subject: Re: System panic worked around
X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas
X-Comment: To unsubscribe send message to listproc@listproc.thoughtport.com
> This seems fishy. If your server requires PAP authentication,
> then wouldn't you have to use it to connect?
The server doesn't _require_ PAP authentication, it _allows_ it. The
alternative is a normal Unix login, which automatically starts up a
character-driven menu system. Option 1 on the menu starts a PPP
connection. That's what the long panic-causing scripts were about. I used
that alternative at the start because I could do it by hand, avoiding the
complexities of PAP and automation.
> Running black hardware serial ports at 57600 can cause kernel
> panics ... I finally gave up trying to run at 57600 because of kernel
> panics which stopped occurring at 38400.
I never saw buffer overrun messages. The panics happened at 38400, too.
> Some processes worked fine at 57600 ... whereas others didn't
The panics always occurred while the connection was being established.
There never were any other processes or their traffic involved. You'll
have to look up my original message if you want the logs.
> > !pppd < \v(line) > \v(line) defaultroute
> It seems that running pppd from inside kermit might impose kermit's
> packet and error detection protocol ...
In kermit, `!' runs a program, and \v(line) identifies the communication
device. I don't think Kermit's protocols are involved here.
Not that it matters, since kermit isn't the fatal ingredient in the
mix.
- Using kermit to connect to my ISP by logging in, then typing `1' to
select the ppp menu item, escaping to kermit and typing `!pppd ...' at
the kermit prompt has _never_ led to a system panic.
- Using a kermit macro that does all of the above (connect, send a `1', run
pppd) _always_ leads to a panic.
- A pppd command that uses a chat script to log in and send a `1'
_always_ leads to a panic.
- A pppd command that only uses a chat script to dial the ISP, then uses
PAP authentication, has _never_ led to a panic.
... which makes me suspect that the length of the script has something to
do with it. Why this would be, I have nary a clue, and my condolences to
anyone who has to fix such a problem.
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
19 Submitted: perkins Aug 02 1996 00:00
Topic: /PPP-2.x/Kernel Server/
Status: New Bug
Severity: Suggestion
Priority: Unknown
Consider IP Masquerading if possible
[perkins Fri Aug 02 08:38:21 EDT 1996]
Consider adding IP Masquerading if possible. Here is a pointer:
Regarding: IP Masquerading in linux...
You need to recompile the kernel with the IP_MASQUERADING patch, or get
a version > 1.3.20. You then need to get a program called ipfwadm.
My suggestion to you is to ¬http://www.linux.org/ and read the HOWTO
under NET-2. There is a section just for this purpose and goes through
a step by step process...
I sucessfully use IP_Masquerading and win95, but have not really tried
it through NT or any other type of box. The newer versions of this
patch are really good in allowing you to have full internet connectivity
to multiple machines via 1 IP address.
Good Luck!
Scott Griffith
Network Consultant
¬http://www.cerfnet.com/~sgriff/cypress
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
20 Submitted: perkins Aug 09 1996 00:00
Topic: /PPP-2.x/Documentation/
Status: New Bug
Severity: Suggestion
Priority: Unknown
Check docs in PKG for URL
[perkins Fri Aug 09 07:40:24 EDT 1996]
Sean Russell
ser@javalab.uoregon.edu
You need to put the URL of this web site in the documentation; like,
at the top of the first README. It took me forever to find it; I
didn't even know to look.
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
21 Submitted: perkins Aug 10 1996 00:00
Topic: /PPP-2.x/PPP Daemon/
Status: New Bug
Severity: Suggestion
Priority: Unknown
ip-up and ip-down examples need updating
[perkins Sat Aug 10 09:41:59 EDT 1996]
Update ip-up and ip-down examples.
ams@best.com (Samuel G. Streeper) wrote:
> You need to restart the nameserver on your home system when
> you bring PPP up:
>
> kill -USR2 <nmserver pid>
>
> (You may want to do this in your ppp-up script) I've heard some
> people also do the same with lookupd but that hasn't been necessary
> for me.
Sending the pre-OS 4.0 lookupd a USR2 signal causes it to toggle logging,
but sending it a HUP signal forces it to restart and thus read any new
resolv.conf indo. You shouldn't have to do this unless you need to use
different nameservers when establishing your PPP connection. I need to
connect to several different PPP servers, so I slide in the correct
resolv.conf and send resolv.conf a HUP signal in pppd's ip-up.
Note that sending the OS 4.0 lookupd a HUP signal won't cause it to
restart. Restarting it manually will leave the system unusable until a
reboot :-( NeXT is aware of this problem.
--
Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com
Trego Systems Voice/Fax: +1 408 335 2515
CaseServ: NEXTSTEP/OpenStep Voice Mail: +1 408 335 1154
managed care solutions US Mail: Felton, CA 95018-9442
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
22 Submitted: Mark Trombino Oct 17 1997 00:00
Topic: /PPP-2.x/PPP Daemon/Option Handling/
Status: New Bug
Severity: Suggestion
Priority: Unknown
Options to ip-up and ip-down
[mtrombin@ix.netcom.com Fri Aug 8 13:34:14 CDT 1997]
I would like to pppd send commands other than ip-up and ip-down when ppp is brought up or killed. You could specify other commands on the command line or options file, but have ip-up/down be the defaults.
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
23 Submitted: Juergen Moellenhoff Oct 17 1997 00:00
Topic: /PPP-2.x/Kernel Server/Panic/
Status: New Bug
Severity: System Hang/Crash
Priority: Unknown
Kernel Panic after PPP link started
[jurgen@oic.de Sun Aug 17 19:51:19 CDT 1997]
Hi,
I tried to use PPP-2.3b3 (for NeXT) on a OpenStep 4.2 for Intel system and got a kernel Panic after the PPP link started. I compiled the version on a NEXTSTEP 3.3 system with _no optimization_ turned on, but I got the problem _with optimization_, too. This is the output of hostconfig:
----------------------------------------------------
Mach kernel version:
NeXT Mach 4.2: Wed Apr 16 13:44:57 PDT 1997; root(rcbuilder):Objects/mk-183.34.obj~2/RELEASE_I386
Kernel configured for a single processor only.
1 processor is physically available.
Processor type: I386 (Intel 586)
Processor active: 0
Primary memory available: 96.00 megabytes.
Default processor set: 86 tasks, 171 threads, 1 processors
Load average: 1.00, Mach factor: 0.00
----------------------------------------------------
The last output in the Monitor window was:
-------------------------------------
Memory access exception (1, 1, c617fffc)
-------------------------------------
Sorry, that's all.
Bye,
Juergen Moellenhoff
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
24 Submitted: John A. Kassebaum Oct 17 1997 00:00
Topic: /PPP-2.x/Kernel Server/Panic/
Status: New Bug
Severity: System Hang/Crash
Priority: Unknown
Recurring System Panic during ppp session
[jak@indy.net Mon Aug 18 21:14:54 CDT 1997]
System:
Intel, Pentium Pro, NextStep 3.3 w/ patch, 64 MB RAM
Using new 3.33 version serial port drivers from NeXT (Apple)
Motherboard: TYAN S1668 ATX (dual CPU board)
with only 1 Pentium Pro Processor installed
I have definitely established that the kernel panic is
related to the ppp_reloc and not the bpf_reloc.
Panic always occurs (reliably) within about 10 minutes of
connect. (The wait varies .. but occurs sooner under high
bandwidth usage.)
Also:
* The exact same panic occurs under `PPP-2.2-0.4.6'.
* Newer NeXT Serial Port Drivers do not remove nor do they
cause problem.
* Sytem is otherwise rock-stable - as long as I refrain from
using PPP.
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
25 Submitted: Rene Berber Oct 17 1997 00:00
Topic: /PPP-2.x/Kernel Server/Panic/
Status: New Bug
Severity: System Hang/Crash
Priority: Unknown
kalloc rempty panic
[rberber@spin.com.mx Thu Sep 11 00:41:34 CDT 1997]
Using ppp sometimes results in a system panic with the following message:
zone: "kalloc.2048" rempty
panic: (Cpu 0) zalloc
Other details are:
1. It only happens after running ppp for some time; more than 1/2 hr, I estimate around the 1 hr zone. It only happens while using ppp;
2. It happens only under heavy I/O, i.e. it always occurs when something is being transfered. It seems to happen more often if OmniWeb and RadicalNews are running at the same time, but it also happens with only OW;
3. The machine configuration is:
NeXTStep 3.3p1/Intel running on a Pentium PC @ 166 MHz with
128 MB RAM and plenty of swap space (in fact two disks, one
configured as swap disk for 200 MB, leaving 40 MB free, and the
other with 1.24GB free; the swaping has been tested
independently) using the latest TTYServer and serial drivers.
4. The connection to my ISP is through a Motorola LifeStyle at 28800/V34/V42BIS, the serial port is used at 57600. The speed of IO (seen with "pppstats -d -w 10") peaks around 3.2 for compressed stuf, but after a while it seems to go even above that maintaining 3.4 on files that I don't expect can get much compression in the modem.
5. ppp is using only VJ compression since my ISP doesn't understand BSD or other types of compression.
6. There are no errors reported either to ppp.log or messages.
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
26 Submitted: kiwi Oct 17 1997 00:00
Topic: /PPP-2.x/Kernel Server/Panic/
Status: New Bug
Severity: System Hang/Crash
Priority: Unknown
Bug in nbq.h causes Panic (fix included)
[kiwi Wed Oct 01 07:14:18 BST 1997]
Hi,
I just had another kernel panic using ppp2.3b3 (the fifth in 11 days)
The version is:
Sep 30 09:42:03 nanan mach: PPP version 2.3b3 for NS 3.2 and 3.3
Sep 30 09:42:03 nanan mach: LKS: $Revision: 1.3 $ ($Date: 1996/10/09 21:14:47 $)
(in the Docs it is referred to version numbers like 0.5.0, 0.4.6 - where do I find those in the binary?)
I'm using OPENSTEP4.2/Mach on Intel.
I wrote down the output and by searching for the calll-offsets in ppp_reloc I finally found the call sequence leading to the panic:
ppp_nb_alloc -> ppp_nb_shrink_top -> nb_get_mark -> bcopy -> memcpy -> boom!
It seems that the result of NB_MAP(nb)-NB_EXTRA, which is the first parameter to bcopy is wrong, as an access to this address leads to the memory exception causing the panic (in fact, the result is something like 5151FFC).
ppp_nb_alloc should not be calling NB_SHRINK_TOP (which in turns calls nb_get_mark which accesss memory in front of the buffer. This leads to a panic when the buffer returned by nb_alloc lies on a page boundary). Calling nb_shrink_top fixes the bug (see the following patch)
diff -rc CopyOfNeXT-ppp2.3-0.5_0/NeXT/nbq.h NeXT-ppp2.3-0.5_0/NeXT/nbq.h
*** CopyOfNeXT-ppp2.3-0.5_0/NeXT/nbq.h Tue Sep 30 20:41:20 1997
--- NeXT-ppp2.3-0.5_0/NeXT/nbq.h Tue Sep 30 22:20:57 1997
***************
*** 274,280 ****
size+=NB_EXTRA;
nb=nb_alloc(size);
if(nb) {
! NB_SHRINK_TOP(nb,NB_EXTRA);
NB_SET_NEXT(nb,NULL);
NB_SET_MARK(nb,0);
}
--- 274,280 ----
size+=NB_EXTRA;
nb=nb_alloc(size);
if(nb) {
! nb_shrink_top(nb,NB_EXTRA);
NB_SET_NEXT(nb,NULL);
NB_SET_MARK(nb,0);
}
Regards,
Axel
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.