From owner-freebsd-hackers  Fri May 30 09:03:13 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA22379
          for hackers-outgoing; Fri, 30 May 1997 09:03:13 -0700 (PDT)
Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22374
          for <hackers@freebsd.org>; Fri, 30 May 1997 09:03:11 -0700 (PDT)
Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12835 for <hackers@freebsd.org>; Fri, 30 May 1997 11:56:57 -0400 (EDT)
Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1])
	by bmcgover-pc.cisco.com (8.8.5/8.8.5) with ESMTP id MAA04384
	for <hackers@freebsd.org>; Fri, 30 May 1997 12:02:38 -0400 (EDT)
Message-Id: <199705301602.MAA04384@bmcgover-pc.cisco.com>
To: hackers@freebsd.org
Subject: PPP insight needed...
Date: Fri, 30 May 1997 12:02:38 -0400
From: Brian McGovern <bmcgover@cisco.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I'm trying to do some testing on a serial driver that has been working in
character mode. I am, however, seeing a problem with PPP (pppd) that I haven't
been able to track down in my driver, and I'm hoping someone might be able 
to go "Oh, yeah, thats it". BTW, this is with 2.2.1-RELEASE. The sio
driver appears to work ok.

Anyhow, the issue I'm seeing concerns the flags field at the entry points
of the driver. When running PPP to open a port and dial out, the "flags"
field to the open() call are set to 3 (hex). On subsequent calls to ioctl()
and read(), the flags are set to 10(hex), which is the O_NONBLOCK flag,
from my interpretation.

Having done a kernel trace, the PPP packet code does a check against 
(flag & IO_NDELAY), which after much tracing, seems to have IO_NDELAY set
if O_NONBLOCK is set in the flags field.

This is causing PPP to spin completely out of control, and use up all
available CPU time. Obviously, this is bad.

I guess, firstly, my question is, is this supposed to happen? Probably
not, but you never know... :)

Next, is there an out-of-driver structure that I can look at to keep
an eye on the flags field? It appears to be changing between the open() call
and the first ioctl()?

Thirdly, is there any way (outside of a driver) that this value can be
changed? I see it for open(), but none of the other calls. Thanks.
	-Brian