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

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

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
Description: This is a digitally signed message part