Recent 2.4.x PPP bug? (PPPIOCDETACH file->f_count=3)

[Marek Michalkiewicz]

Hello,

Starting with recent 2.4.19 and 2.4.20 kernels, when any
one (or both) of my two permanent PPP connections goes
down (usually due to the ISP rebooting their equipment),
quite often something bad happens.

Dec 31 16:31:52 alf kernel: PPPIOCDETACH file->f_count=3
Dec 31 16:31:52 alf kernel: PPPIOCDETACH file->f_count=3

Dec 31 16:31:52 alf pppd[31783]: Hangup (SIGHUP)
Dec 31 16:31:52 alf pppd[31783]: Modem hangup
Dec 31 16:31:52 alf pppd[27363]: Hangup (SIGHUP)
Dec 31 16:31:52 alf pppd[27363]: Modem hangup
Dec 31 16:31:52 alf pppd[31783]: Connection terminated.
Dec 31 16:31:52 alf pppd[27363]: Connection terminated.
Dec 31 16:31:52 alf pppd[27363]: Connect time 3961.2 minutes.
Dec 31 16:31:52 alf pppd[27363]: Sent 12744359 bytes, received 11908495 bytes.
Dec 31 16:31:52 alf pppd[31783]: Connect time 3961.2 minutes.
Dec 31 16:31:52 alf pppd[31783]: Sent 13843367 bytes, received 38226866 bytes.
Dec 31 16:31:53 alf pppd[31783]: Couldn't release PPP unit: Invalid argument
Dec 31 16:31:53 alf pppd[27363]: Couldn't release PPP unit: Invalid argument
Dec 31 16:31:54 alf pppd[31783]: Couldn't create new ppp unit: Inappropriate ioctl for device
Dec 31 16:31:54 alf pppd[27363]: Couldn't create new ppp unit: Inappropriate ioctl for device

Then the "Couldn't create new ppp unit" messages are repeated
very often until pppd is killed with SIGKILL (SIGHUP or SIGTERM
don't work).  Killing and restarting pppd seems to be the only
way to restore the connection, despite the pppd "persist" and
"maxfail 0" options.

I've tried to google for the "PPPIOCDETACH file->f_count=3"
message, and found that someone had this problem with PPPoE.
In my case, this is normal PPP over a serial port, which has
always been rock solid for me.

Please help - is this a known problem, which could be fixed
in recent 2.4.21-pre kernels?

Thanks,
Marek