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

[Sarunas Vancevicius <vsarunas@xxxxxxxxxx>]

On 10:46, Tue 10 Aug 04, Matthew Dillon wrote:
>     Ok, I found a bug.  It looks like the PPP code is stealing some flag
>     bugs from the MBUF's m_flags.  The recent MBUF changes allocated more
>     flags and there is now a collision.  (And for those programmers out 
>     there, this code is a great example of how not to steal flags from
>     a system structure!).
> 
>     Please try this patch.
> 
> 					    -Matt
> 
> Index: if_ppp.c
> ===================================================================
> RCS file: /cvs/src/sys/net/ppp/if_ppp.c,v
> retrieving revision 1.18
> diff -u -r1.18 if_ppp.c
> --- if_ppp.c	2 Jun 2004 14:42:58 -0000	1.18
> +++ if_ppp.c	10 Aug 2004 17:43:23 -0000
> @@ -166,8 +166,8 @@
>   * We steal two bits in the mbuf m_flags, to mark high-priority packets
>   * for output, and received packets following lost/corrupted packets.
>   */
> -#define M_HIGHPRI	0x2000	/* output packet for sc_fastq */
> -#define M_ERRMARK	0x4000	/* steal a bit in mbuf m_flags */
> +#define M_HIGHPRI	M_PROTO2	/* output packet for sc_fastq */
> +#define M_ERRMARK	M_PROTO3	/* steal a bit in mbuf m_flags */
>  
>  
>  #ifdef PPP_COMPRESS

That fixes the problem of not being able to access some
sites.


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.

# end of rubbish.

-- 
Sarunas Vancevicius