Possible fix for (Re: Internet problem after recent rewrite of mbuf)

Simon 'corecode' Schubert corecode at fs.ei.tum.de
Tue Aug 10 15:07:05 PDT 2004


On 10.08.2004, at 23:03, Sarunas Vancevicius wrote:
Second bug:

No wonder why my pppd is taking a lot of CPU time, just look
at this(output from command ktrace -p 899 ;sleep 5; ktrace
-C; kdump -R):
   899 pppd     1092167829.271917 CALL  
select(0x6,0xbfbffa10,0,0xbfbffa10,0)
   899 pppd     0.000095 RET   select 1
   899 pppd     0.000014 CALL  read(0x5,0x8062180,0x5e0)
   899 pppd     0.000024 RET   read -1 errno 35 Resource temporarily 
unavailable
   899 pppd     0.000012 CALL  select(0x6,0xbfbffa10,0,0xbfbffa10,0)
   899 pppd     0.000013 RET   select 1
   899 pppd     0.000011 CALL  read(0x5,0x8062180,0x5e0)
   899 pppd     0.000014 RET   read -1 errno 35 Resource temporarily 
unavailable
   899 pppd     0.000011 CALL  select(0x6,0xbfbffa10,0,0xbfbffa10,0)
   899 pppd     0.000013 RET   select 1
   899 pppd     0.000011 CALL  read(0x5,0x8062180,0x5e0)
   899 pppd     0.000013 RET   read -1 errno 35 Resource temporarily 
unavailable
   899 pppd     0.000012 CALL  select(0x6,0xbfbffa10,0,0xbfbffa10,0)
   899 pppd     0.000013 RET   select 1
   899 pppd     0.000010 CALL  read(0x5,0x8062180,0x5e0)
   899 pppd     0.000014 RET   read -1 errno 35 Resource temporarily 
unavailable
   899 pppd     0.000011 CALL  select(0x6,0xbfbffa10,0,0xbfbffa10,0)
   899 pppd     0.000047 RET   select 1
   899 pppd     0.000012 CALL  read(0x5,0x8062180,0x5e0)
   899 pppd     0.000015 RET   read -1 errno 35 Resource temporarily 
unavailable
   899 pppd     0.000011 CALL  select(0x6,0xbfbffa10,0,0xbfbffa10,0)
   899 pppd     0.000014 RET   select 1
   899 pppd     0.000011 CALL  read(0x5,0x8062180,0x5e0)
   899 pppd     0.000014 RET   read -1 errno 35 Resource temporarily 
unavailable
   899 pppd     0.000011 CALL  select(0x6,0xbfbffa10,0,0xbfbffa10,0)
   899 pppd     0.000012 RET   select 1
   899 pppd     0.000011 CALL  read(0x5,0x8062180,0x5e0)

[342376 lines of this in 5 seconds, the output file is 20mb
in size.]
I have no idea what I'm talking about, so it might be total
rubbish, but here is my current understanding of what is
happenning:
pppd calls standard c library function select(), everything
is OK, and it returns 1 which is the number of descriptors
ready to be accessed. But when the returned file descriptor
is read, it cannot be accessed because its unavailable.
So it retries, gets an error, and keeps on retrying all the
time at around 34000 times a second (assuming that there are
2 calls: select and read, and they are repeated around
170000 times for duration of 5 seconds, and thats 34000
select() and read() per second!).
I'm not very good programmer(hell, I cannot even be called a
newbie programmer). But here are possible solution:
o find out why select() returns a invalid file descriptor
o If its valid, find out why it becomes unavailable
o Restrict on how often retry() gets called.
good point. unless you're using demand dialout mode, there is only one 
possible location where read() can fail directly after select():

usr.sbin/pppd/sys-bsd.c:630--

int
read_packet(buf)
    u_char *buf;
{
    int len;
    if ((len = read(ttyfd, buf, PPP_MTU + PPP_HDRLEN)) < 0) {
        if (errno == EWOULDBLOCK || errno == EINTR)
            return -1;
        syslog(LOG_ERR, "read: %m");
        die(1);
    }
    return len;
}
now, this looks totally sane... question is (right as you wrote):
Why does select return a socket which returns EWOULDBLOCK on read?
I'm not sure but I can imagine two cases:
a) there is no data and select is broken
b) there is data and read doesn't want to read it
good question...

cheers
  simon
--
/"\
\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News
Attachment:
PGP.sig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/bugs/attachments/20040810/68bd8fa3/attachment-0020.obj>


More information about the Bugs mailing list