Date: Fri, 30 May 1997 12:02:38 -0400 From: Brian McGovern <bmcgover@cisco.com> To: hackers@freebsd.org Subject: PPP insight needed... Message-ID: <199705301602.MAA04384@bmcgover-pc.cisco.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705301602.MAA04384>