(no subject)

(no subject)

[KLpetronas]

3

(no subject)

[netdev-bounce]

hi

I've got this video server serving video for VoD. problem is the P4 1.8 seems 
to be maxed out by a few system calls. The below output is for ~50 clients 
streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU maxes out.

Does anyone have an idea?

bash-2.05# readprofile | sort -rn +2 | head -30
154203 default_idle                             2409.4219
212723 csum_partial_copy_generic                916.9095
100164 handle_IRQ_event                         695.5833
 24979 system_call                              390.2969
 37300 e1000_intr                               388.5417
119699 ide_intr                                 340.0540
 30598 skb_release_data                         273.1964
 40740 do_softirq                               195.8654
131818 do_wp_page                               164.7725
  9935 fget                                     155.2344
 24747 kfree                                    154.6687
 10911 del_timer                                113.6562
 11683 ip_conntrack_find_get                     91.2734
  4120 sock_poll                                 85.8333
  9357 ip_ct_find_proto                          83.5446
  5194 sock_wfree                                81.1562
  4929 add_wait_queue                            77.0156
  8361 flush_tlb_page                            74.6518
  4571 remove_wait_queue                         71.4219
  2191 __brelse                                  68.4688
 29477 skb_clone                                 68.2338
  8562 do_gettimeofday                           59.4583
  5673 process_timeout                           59.0938
 11097 tcp_v4_send_check                         57.7969
  6124 kfree_skbmem                              54.6786
 17115 tcp_poll                                  53.4844
 21130 nf_hook_slow                              52.8250
  8299 ip_ct_refresh                             51.8687
 15429 __kfree_skb                               50.7533
  1059 lru_cache_del                             46.0435


roy
-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

(no subject)

[netdev-bounce]

On Tue, 22 Oct 2002, Ben Greear wrote:

> No reason not to provide both!  The IOCTL can take care of any drivers
> that don't take module parameters for it, and can do it in a generic
> way.

sure maybe via the ethertool or whatever tool that is being used would
be a good start. The default should still be weight_p.

>
> The tulip driver I am poking at hard-coded it to 16.  64 seems to work
> just as good.
>
> Any idea (other than trial and error) for how to determine a good value
> for this?  Maybe should take the number of active devices into account
> and wiggle things dynamically from user-space?
>

What i recall is 64 was a good number and thats why we had it as default.
I cant remember who changed the value to 16(Robert?), but it does seem to
be a good value as well. If that was the only driver and it had a lot of
packets, it would still get to use all the 300 packets in the budget; it
will just have to do it in 300/16 times ..

cheers,
jamal

(no subject)

[netdev-bounce]

In article <Pine.LNX.4.44.0210231031540.26788-100000@netcore.fi> (at Wed, 23 Oct 2002 10:36:19 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> says:

> Does Bind 9.2.1 work this so that it can receive packets, when IPv6 is
> also enabled, from IPv4 addresses using TCP without
> 'match-mapped-addresses yes', or is that a separate problem?

Bind9 trys to bind :: and all ipv4 addresses on the node.

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

(no subject)

[netdev-bounce]

On Wed, 23 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.44.0210231031540.26788-100000@netcore.fi> (at Wed, 23 Oct 2002 10:36:19 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> says:
> 
> > Does Bind 9.2.1 work this so that it can receive packets, when IPv6 is
> > also enabled, from IPv4 addresses using TCP without
> > 'match-mapped-addresses yes', or is that a separate problem?
> 
> Bind9 trys to bind :: and all ipv4 addresses on the node.

Yes, but binding those IPv4 addresses _for TCP_ failed after binding to 
::, at least previously.  That worked e.g. on BSD.  Does that work now, 
too?

I.e. I have two boxes, both running Bind 9.2.1.  Linux gives:

$ netstat -an | grep :53
tcp        0      0 :::53                   :::*                    LISTEN      
udp        0      0 193.94.160.1:53         0.0.0.0:*                           
udp        0      0 127.0.0.1:53            0.0.0.0:*                           
udp        0      0 :::53                   :::*    

and BSD gives:

# netstat -an | grep .53
tcp6       0      0  ::1.953                *.*                    LISTEN
tcp4       0      0  127.0.0.1.953          *.*                    LISTEN
tcp4       0      0  127.0.0.1.53           *.*                    LISTEN
tcp4       0      0  193.166.4.206.53       *.*                    LISTEN
tcp4       0      0  193.166.187.10.53      *.*                    LISTEN
tcp6       0      0  *.53                   *.*                    LISTEN
udp4       0      0  127.0.0.1.53           *.*                    
udp4       0      0  193.166.4.206.53       *.*                    
udp4       0      0  193.166.187.10.53      *.*                    
udp6       0      0  *.53                   *.*

Will this work too?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

(no subject)

[netdev-bounce]

> >
> > 905182 total                                      0.4741
> > 121426 csum_partial_copy_generic                474.3203
>
> Well, maybe take a look at this func and try to optimize it?

I don't know assembly that good - sorry.

> >  93633 default_idle                             1800.6346
> >  74665 do_wp_page                               111.1086
>
> What's this?

do_wp_page is Defined as a function in: mm/memory.c

comments from the file:

/*
 * This routine handles present pages, when users try to write
 * to a shared page. It is done by copying the page to a new address
 * and decrementing the shared-page counter for the old page.
 *
 * Goto-purists beware: the only reason for goto's here is that it results
 * in better assembly code.. The "default" path will see no jumps at all.
 *
 * Note that this routine assumes that the protection checks have been
 * done by the caller (the low-level page fault routine in most cases).
 * Thus we can safely just mark it writable once we've done any necessary
 * COW.
 *
 * We also mark the page dirty at this point even though the page will
 * change only once the write actually happens. This avoids a few races,
 * and potentially makes it more efficient.
 *
 * We hold the mm semaphore and the page_table_lock on entry and exit
 * with the page_table_lock released.
 */

>
> >  65857 ide_intr                                 184.9916
>
> You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm...
> how large is your readahead? I assume you'd like to fetch
> more sectors from ide per interrupt. (I hope you do DMA ;)

doing DMA - RAID-0 with 1MB chunk size on 4 disks.

> >  53636 handle_IRQ_event                         432.5484
> >  21973 do_softirq                               107.7108
> >  20498 e1000_intr                               244.0238
>
> I know zero about networking, but why 120 000 csum_partial_copy_generic
> and inly 20 000 nic interrupts? That may be abnormal.

sorry
I don't know

-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

(no subject)

[netdev-bounce]

bert hubert wrote:

> > ...adding the whole profile output - sorted by the first column this time...
> >
> > 905182 total                                      0.4741
> > 121426 csum_partial_copy_generic                474.3203
> >  93633 default_idle                             1800.6346
> >  74665 do_wp_page                               111.1086
> 
> Perhaps the 'copy' also entails grabbing the page from disk, leading to
> inflated csum_partial_copy_generic stats?

I think this is strictly a copy from user space->kernel and vice versa.
This shouldnt include the disk access etc. 

thanks,
Nivedita

(no subject)

[netdev-bounce]

On Wednesday 23 October 2002 16:59, Nivedita Singhvi wrote:
> bert hubert wrote:
> > > ...adding the whole profile output - sorted by the first column this
> > > time...
> > >
> > > 905182 total                                      0.4741
> > > 121426 csum_partial_copy_generic                474.3203
> > >  93633 default_idle                             1800.6346
> > >  74665 do_wp_page                               111.1086
> >
> > Perhaps the 'copy' also entails grabbing the page from disk, leading to
> > inflated csum_partial_copy_generic stats?
>
> I think this is strictly a copy from user space->kernel and vice versa.
> This shouldnt include the disk access etc.

hm

I'm doing O_DIRECT read (from disk), so it needs to be user -> kernel, then.

any chance of using O_DIRECT to the socket?

-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

(no subject)

[netdev-bounce]

> The e1000 can very well do hardware checksumming on transmit.
>
> The missing piece of the puzzle is that his application is not
> using sendfile(), without which no transmit checksum offload
> can take place.

As far as I've understood, sendfile() won't do much good with large files. Is 
this right?

We're talking of 3-6GB files here ...

roy
-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

(no subject)

[netdev-bounce]

<HTML>
<HEAD>
<TITLE>=B9=D9=B7=B9=B9=CC=BC=D2</TITLE>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Deuc=
-kr">
<style>
<!--
body, table, tr, td, SELECT,input,DIV,form,TEXTAREA {font-family: =
=B1=BC=B8=B2, =B5=B8=BF=F2 verdana;font-size:9pt;}
a:link, a:active, a:visited { color=3Dblue; text-decoration: none;}
P,blockquote,td,br {font-size:9pt}
a:hover { color=3Dblue; text-decoration: underline; }
font:{class=3Dc style=3D"COLOR: #003269; LINE-HEIGHT: 18px";}
-->
</style>
</HEAD>
<BODY BGCOLOR=3D#ffffff LEFTMARGIN=3D0 TOPMARGIN=3D0 MARGINWIDTH=3D"0=
" MARGINHEIGHT=3D"0">
<TABLE WIDTH=3D755 BORDER=3D0 CELLPADDING=3D0 CELLSPACING=3D0>
=09<TR>
=09=09
    <TD COLSPAN=3D2> <a href=3D"http://www.baremiso.com" target=3D"_b=
lank"><IMG SRC=3D"http://www.bysoulmate.com/mail/baremiso/images/inde=
x_01.gif" WIDTH=3D755 HEIGHT=3D109 ALT=3D"" border=3D"0"></a></TD>
=09</TR>
=09<TR>
=09=09
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_02.gif" WI=
DTH=3D370 HEIGHT=3D187 ALT=3D"" border=3D"0"></a></TD>
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_03.gif" WI=
DTH=3D385 HEIGHT=3D187 ALT=3D"" border=3D"0"></a></TD>
=09</TR>
=09<TR>
=09=09
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_04.gif" WI=
DTH=3D370 HEIGHT=3D169 ALT=3D"" border=3D"0"></a></TD>
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_05.gif" WI=
DTH=3D385 HEIGHT=3D169 ALT=3D"" border=3D"0"></a></TD>
=09</TR>
=09<TR>
=09=09
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_06.gif" WI=
DTH=3D370 HEIGHT=3D167 ALT=3D"" border=3D"0"></a></TD>
=09=09
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_07.gif" WI=
DTH=3D385 HEIGHT=3D167 ALT=3D"" border=3D"0"></a></TD>
=09</TR>
=09<TR>
=09=09
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_08.gif" WI=
DTH=3D370 HEIGHT=3D185 ALT=3D"" border=3D"0"></a></TD>
    <TD> <a href=3D"http://www.baremiso.com" target=3D"_blank"><IMG S=
RC=3D"http://www.bysoulmate.com/mail/baremiso/images/index_09.gif" WI=
DTH=3D385 HEIGHT=3D185 ALT=3D"" border=3D"0"></a></TD>
=09</TR>
=09<TR>
=09=09
    <TD COLSPAN=3D2> <a href=3D"http://www.baremiso.com" target=3D"_b=
lank"><IMG SRC=3D"http://www.bysoulmate.com/mail/baremiso/images/inde=
x_10.gif" WIDTH=3D755 HEIGHT=3D32 ALT=3D"" border=3D"0"></a></TD>
=09</TR>
</TABLE>
<table width=3D"755" border=3D"0" cellspacing=3D"0" cellpadding=3D"0"=
>
  <tr>
    <td height=3D"60">
      <div align=3D"center">=BB=E7=BE=F7=C0=E5=C1=D6=BC=D2 : =BC=AD=
=BF=EF=BD=C3 =B0=AD=B3=B2=B1=B8 =BF=AA=BB=EF=B5=BF 820-10 =B1=DB=B6=
=F3=BD=BA=C5=B8=BF=F6=BA=F4=B5=F9 4=C3=FE<br>
        =B4=EB=C7=A5=C0=FC=C8=AD : 02 - 3452 -7347 / =BC=D2=BA=F1=
=C0=DA=BB=F3=B4=E3=BD=C7 : 031-703 - 5670 / H.P 018 - 310 - 5670<br>
        =BB=E7=BE=F7=C0=DA =B5=EE=B7=CF=B9=F8=C8=A3 : 129-20-18866 / =
=C5=EB=BD=C5=C6=C7=B8=C5=BE=F7=BD=C5=B0=ED =C1=A63849=C8=A3 / =B4=
=EB=C7=A5 : =B9=AE=C0=E7=C3=B6</div>
    </td>
  </tr>
</table>
<table width=3D"755" border=3D"0" cellspacing=3D"0" cellpadding=3D"0"=
>
  <tr>=20
    <td height=3D"60">=20
      <div align=3D"center">=BA=BB =B8=DE=C0=CF=C0=BA =C1=A4=BA=B8=
=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF=A1 =C0=C7=B0=C5 =C1=
=A6=B8=F1=BF=A1 [=B1=A4=B0=ED]=B6=F3 =C7=A5=BD=C3=B5=C8 =B8=DE=C0=
=CF=C0=D4=B4=CF=B4=D9. <br>
        =B1=CD=C7=CF=C0=C7 =B8=DE=C0=CF=C0=BA =C0=A5=BB=F3=BF=A1=BC=
=AD =C3=EB=B5=E6=C7=CF=BF=B4=C0=B8=B8=E7 =C1=D6=BC=D2=BF=DC=BF=A1 =
=BE=EE=B6=B0=C7=D1 =C1=A4=BA=B8=B5=B5 =BA=B8=C0=AF=C7=CF=B0=ED =C0=
=D6=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9. =BF=F8=C4=A1=BE=CA=B4=C2 =B8=DE=
=C0=CF=C0=CC=BE=FA=B4=D9=B8=E9 <br>
        =BE=C6=B7=A1=C0=C7 [=BC=F6=BD=C5=B0=C5=BA=CE]=B8=A6 =B4=AD=
=B7=AF =B1=CD=C7=CF=C0=C7 =B8=DE=C0=CF=C1=D6=BC=D2=B8=A6 =C7=D1 =B9=
=F8=B8=B8 =B9=DD=BC=DB=C7=D8 =C1=D6=BD=CA=BD=C3=BF=C0. =BA=D2=C6=ED=
=C0=BB =B5=E5=B7=C1 =C1=CB=BC=DB=C7=D5=B4=CF=B4=D9.<br>
        (Please click here to remove your address from our mailing li=
st. Sorry=20
        for the trouble.)</div>
    </td>
  </tr>
</table>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;<center><a href=3D'http://itnsoft.com/~mailtouch/user/touch.cgi?cm=
d=3Drefuse_view&usercode=3Dfigjdsip-diiils-Ddihl&group=3D12&name=3D&m=
ail=3Dnetdev@oss.sgi.com'><img src=3D'http://itnsoft.com/~mailtouch/u=
ser/mail-refuse.gif' border=3D0)></center></p>
</BODY>
</HTML>

(no subject)

[netdev-bounce]

> '50 clients *each* streaming at ~4.4MBps', better make that clear,
> otherwise something is *very* broken. Also mention that you have an e1000
> card which does not do outgoing checksumming.

just to clearify

s/MBps/Mbps/
s/bps/bits per second/

> You'd think that a kernel would be able to do 250megabits of TCP checksums
> though.
>
> > ...adding the whole profile output - sorted by the first column this
> > time...
> >
> > 905182 total                                      0.4741
> > 121426 csum_partial_copy_generic                474.3203
> >  93633 default_idle                             1800.6346
> >  74665 do_wp_page                               111.1086
>
> Perhaps the 'copy' also entails grabbing the page from disk, leading to
> inflated csum_partial_copy_generic stats?

I really don't know. Just to clearify a little more - the server app uses 
O_DIRECT to read the data before tossing it to the socket.

> Where are you serving from?

What do you mean?

roy
-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

(no subject)

[netdev-bounce]

On Wed, 23 Oct 2002, Nivedita Singhvi wrote:

> bert hubert wrote:
> 
> > I still refuse to believe that a 1.8GHz Pentium4 can only checksum
> > 250megabits/second. MD Raid5 does better and they probably don't use a
> > checksum as braindead as that used by TCP.
> > 
> > If the checksumming is not the problem, the copying is, which would be a
> > weakness of your hardware. The function profiled does both the copying and
> > the checksumming.
> 
> Yep, its not so much the checksumming as the fact that this is
> done over each byte of data and copied.
> 
> thanks,
> Nivedita

No. It's done over each word (short int) and the actual summation
takes place during the address calculation of the next word. This
gets you a checksum that is practically free.

A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second.
It will copy at 1,549 megabytes per second. Those are megaBYTES!

If you have slow network performance it has nothing to do with
either copy or checksum. Data transmission acts like a low-pass
filter. The dominant pole of that transfer function determines
the speed, that's why it's called dominant. If you measure
a data-rate of 10 megabytes/second. Nothing you do with copy
or checksum will affect it to any significant extent.

If you have a data-rate of 100 megabytes per second, then any
tinkering with copy will have an effective improvement ratio
of 100/1,559 ~= 0.064. If you have a data rate of 100 megabytes
per second and you tinker with checksum, you get an improvement
ratio of 100/685 ~=0.14. These are just not the things that are
affecting your performance.

If you were to double the checksumming speed, you increase the
throughput by 2 * 0.14 = 0.28 with the parameters shown.

The TCP/IP checksum is quite nice. It may have been discovered
by accident, but it's still nice. It works regardless of whether
you have a little endian or big endian machine. It also doesn't
wrap so you don't (usually) show a good checksum when the data
is bad. It does have the characteristic that if all the bits are
inverted, it will checksum good. However, there are not too many
real-world scenarios that would result in this inversion. So it's
not "brain-dead" as you state. A hardware checksum is really
quick because it's really easy.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America

(no subject)

[netdev-bounce]

On Wed, 23 Oct 2002, Nivedita Singhvi wrote:

> "Richard B. Johnson" wrote:
> 
> > No. It's done over each word (short int) and the actual summation
> > takes place during the address calculation of the next word. This
> > gets you a checksum that is practically free.
> 
> Yep, sorry, word, not byte. My bad. The cost is in the fact 
> that this whole process involves loading each word of the data
> stream into a register. Which is why I also used to consider
> the checksum cost as negligible. 
> 
> > A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second.
> > It will copy at 1,549 megabytes per second. Those are megaBYTES!
> 
> But then why the difference in the checksum/copy and copy?
> Are you saying the checksum is not costing you 864 megabytes
> a second??

Costing you 864 megabytes per second?
Lets say the checksum was free. You are then able to INF bytes/per/sec.
So it's costing you INF bytes/per/sec?  No, it's costing you nothing.
If we were not dealing with INF, then 'Cost' is approximately 1/N, not
N. Cost is work_done_without_checksum - work_done_with_checksum. Because
of the low-pass filter pole, these numbers are practically the same.
But, you can get a measurable difference between any two large numbers.
This makes the 'cost' seem high. You need to make it relative to make
any sense, so a 'goodness' can be expressed as a ratio of the cost and
the work having been done.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America

(no subject)

[netdev-bounce]

"Richard B. Johnson" wrote:

> No. It's done over each word (short int) and the actual summation
> takes place during the address calculation of the next word. This
> gets you a checksum that is practically free.

Yep, sorry, word, not byte. My bad. The cost is in the fact 
that this whole process involves loading each word of the data
stream into a register. Which is why I also used to consider
the checksum cost as negligible. 

> A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second.
> It will copy at 1,549 megabytes per second. Those are megaBYTES!

But then why the difference in the checksum/copy and copy?
Are you saying the checksum is not costing you 864 megabytes
a second??

thanks,
Nivedita

(no subject)

[netdev-bounce]

All,

Just tried 2.4.20-pre11 and all NIC issues seem to be resolved.
Both eepro100 and e100 drivers work correctly.

			Paul

-----Original Message-----
From: Donald Becker [mailto:becker@scyld.com]
Sent: Tuesday, October 22, 2002 7:21 PM
To: Felipe W Damasio
Cc: Paul Hernandez; Jeff Garzik; Linux-net; netdev@oss.sgi.com
Subject: RE: NIC on 2.4.19 SMP (mii-diag output)


On 22 Oct 2002, Felipe W Damasio wrote:

> On Mon, 2002-10-21 at 15:16, Paul Hernandez wrote:
> >  I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
> > 10baseT
> >    Advertising no additional info pages.
> >    IEEE 802.3 CSMA/CD protocol.
> >  Link partner capability is 0000:.
> >    Negotiation did not complete.
> 
> 	The link partner is not advertising it's capabilities.

No! There is not link partner.

0000 is the default value for the register when there is no negotiation
going on.
If you have link beat _and_ the register is 0000, then no
autonegotiation took place.
If the link partner advertised "not capable of anything", the register
will report 0001.

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993

(no subject)

[netdev-bounce]

On Wed, 23 Oct 2002, bert hubert wrote:

> On Wed, Oct 23, 2002 at 03:42:48PM +0200, Roy Sigurd Karlsbakk wrote:
> > > The e1000 can very well do hardware checksumming on transmit.
> > >
> > > The missing piece of the puzzle is that his application is not
> > > using sendfile(), without which no transmit checksum offload
> > > can take place.
> > 
> > As far as I've understood, sendfile() won't do much good with large files. Is 
> > this right?
> 
> I still refuse to believe that a 1.8GHz Pentium4 can only checksum
> 250megabits/second. MD Raid5 does better and they probably don't use a
> checksum as braindead as that used by TCP.
> 
> If the checksumming is not the problem, the copying is, which would be a
> weakness of your hardware. The function profiled does both the copying and
> the checksumming.
> 
> But 250megabits/second also seems low.
> 
> Dave? 
> 

Ordinary DUAL Pentium 400 MHz machine does this...


Calculating CPU speed...done
Testing checksum speed...done
Testing RAM copy...done
Testing I/O port speed...done

                     CPU Clock = 400  MHz
                checksum speed = 685  Mb/s
                      RAM copy = 1549 Mb/s
                I/O port speed = 654  kb/s


This is 685 megaBYTES per second.

                checksum speed = 685  Mb/s



Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America

(no subject)

[netdev-bounce]

On Wed, 23 Oct 2002, Kyle C Quest wrote:
> I'm just curious... what happened to the generic option, SO_ONEFAMILY, that
> would replace
> the need for IPV6_V6ONLY?

This kind of thing is only applicable to IPv4 and IPv6 (and badly even 
there), there is no use trying to generalize it -- the idea was discarded.

> > In article <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002
> 19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says:
> >
> > > Actually, it would be great if you said what is wrong in that my patch?
> > > It looks so simple that I am not ready to agree that real one should be
> > > so complicated. :-)
> >
> > Well, I've refered alexey's patch and simplified many if-clauses.
> > Here's the new patch and test results.  seems ok.
> >
> > --------------------
> > Linux IPv6 stack provides the ability for IPv6 applications to
> > interoperate with IPv4 applications.  Port space for TCP (or UDP) is
> > shared by IPv6 and IPv4.  This conforms to RFC2553.
> > However, some kind of applications may want to restrict their use of
> > an IPv6 socket to IPv6 communication only.  IPV6_V6ONLY socket option is
> > defined for such applications in RFC2553bis, which is successor of
> RFC2553.
> > This patch allows to bind both IPv6 and IPv4 sockets with the single
> > port number at the same time if IPV6_V6ONLY socket options is set to
> > the IPv6 socket.
> >
> > Packet delivery strategy is similar to one before, but we prefer
> > IPv4 a bit.
> >
> > Test results and patch against 2.4.20-pre11 follows.
> >
> > *** Test for bind(2) ***
> >
> > [SOCK_DGRAM w/o IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 x x x x
> > :: x x x x
> > 127.1 x x x o
> > ::1 x x o x
> >
> > ==> OK
> >
> > [SOCK_DGRAM w/ IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 x o x o
> > :: o x o x
> > 127.1 x o x o
> > ::1 o x o x
> >
> > ==> OK
> >
> > [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 o o o o
> > :: o o o o
> > 127.1 o o o o
> > ::1 o o o o
> >
> > ==> OK
> >
> > [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 o o o o
> > :: o o o o
> > 127.1 o o o o
> > ::1 o o o o
> >
> > ==> OK
> >
> > [SOCK_STREAM w/o IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 x x x x
> > :: x x x x
> > 127.1 x x x o
> > ::1 x x o x
> >
> > ==> OK
> >
> > [SOCK_STREAM w/ IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 x o x o
> > :: o x o x
> > 127.1 x o x o
> > ::1 o x o x
> >
> > ==> OK
> >
> > [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 o o o o
> > :: o o o o
> > 127.1 o o o o
> > ::1 o o o o
> >
> > ==> OK
> >
> > [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY]
> > 0 :: 127.1 ::1
> > 0 o o o o
> > :: o o o o
> > 127.1 o o o o
> > ::1 o o o o
> >
> > ==> OK
> >
> > *** Test for Receiver ***
> >
> > [IPv6]
> > 1a. :: <- ::1
> > received from ::1
> >
> > 1b. :: w/IPV6_V6ONLY <- ::1
> > received from ::1
> >
> > 2a. :: <- 127.0.0.1
> > received from ::1
> >
> > 2b. :: w/IPV6_V6ONLY <- 127.0.0.1
> > none received
> >
> > 3a. :: <- ff02::1
> > received from fe80::EUI64
> >
> > 3b. :: w/IPV6_V6ONLY <- ff02::1
> > received from fe80::EUI64
> >
> > 4a. :: <- 224.0.0.1
> > received from ::ffff:ipv4addr
> >
> > 4b. :: w/IPV6_V6ONLY <- 224.0.0.1
> > none received
> >
> > ==> OK
> >
> > [IPv4]
> > 1. 0.0.0.0 <- ::1
> > none received
> >
> > 2. 0.0.0.0 <- 127.0.0.1
> > received from 127.0.0.1
> >
> > 3. 0.0.0.0 <- ff02::1
> > none received
> >
> > 4. 0.0.0.0 <- 224.0.0.1
> > received from ipv4addr
> >
> > ==> OK
> >
> > [IPv6 vs IPv4]
> > 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1
> > ipv6 received from ::1
> >
> > 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1
> > ipv4 received from 127.0.0.1
> >
> > 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1
> > ipv6 received from fe80::EUI64
> >
> > 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1
> > ipv4 received from ipv4addra
> >
> > ==> OK
> >
> > -------------------------------------------------------------------
> > Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number
> (IPV6_V6ONLY Support) - Rev.2
> > Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023
> > Patch-Author: YOSHIFUJI Hideaki / USAGI Project <yoshfuji@linux-ipv6.org>
> > Credit: YOSHIFUJI Hideaki / USAGI Project <yoshfuji@linux-ipv6.org>
> > Reference: RFC2553bis
> > -------------------------------------------------------------------
> > Index: Documentation/networking/ip-sysctl.txt
> > ===================================================================
> > RCS file:
> /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt
> ,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.42.1
> > diff -u -r1.1.1.1 -r1.1.1.1.42.1
> > --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000
> 1.1.1.1
> > +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000
> 1.1.1.1.42.1
> > @@ -462,6 +462,15 @@
> >  IPv6 has no global variables such as tcp_*.  tcp_* settings under ipv4/
> also
> >  apply to IPv6 [XXX?].
> >
> > +bindv6only - BOOLEAN
> > + Default value for IPV6_V6ONLY socket option,
> > + which restricts use of the IPv6 socket to IPv6 communication
> > + only.
> > + TRUE: disable IPv4-mapped address feature
> > + FALSE: enable IPv4-mapped address feature
> > +
> > + Default: FALSE (as specified in RFC2553bis)
> > +
> >  conf/default/*:
> >   Change the interface-specific default settings.
> >
> > Index: include/linux/in6.h
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.40.1
> > diff -u -r1.1.1.1 -r1.1.1.1.40.1
> > --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1
> > +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> > @@ -156,6 +156,7 @@
> >  #define IPV6_MTU_DISCOVER 23
> >  #define IPV6_MTU 24
> >  #define IPV6_RECVERR 25
> > +#define IPV6_V6ONLY 26
> >
> >  /* IPV6_MTU_DISCOVER values */
> >  #define IPV6_PMTUDISC_DONT 0
> > Index: include/linux/sysctl.h
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v
> > retrieving revision 1.1.1.2
> > retrieving revision 1.1.1.2.16.1
> > diff -u -r1.1.1.2 -r1.1.1.2.16.1
> > --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2
> > +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1
> > @@ -345,7 +345,8 @@
> >  enum {
> >   NET_IPV6_CONF=16,
> >   NET_IPV6_NEIGH=17,
> > - NET_IPV6_ROUTE=18
> > + NET_IPV6_ROUTE=18,
> > + NET_IPV6_BINDV6ONLY=20,
> >  };
> >
> >  enum {
> > Index: include/net/ipv6.h
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.38.1
> > diff -u -r1.1.1.1 -r1.1.1.1.38.1
> > --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1
> > +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1
> > @@ -88,6 +88,9 @@
> >
> >  #include <net/sock.h>
> >
> > +/* sysctls */
> > +extern int sysctl_ipv6_bindv6only;
> > +
> >  extern struct ipv6_mib ipv6_statistics[NR_CPUS*2];
> >  #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field)
> >  #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field)
> > Index: include/net/sock.h
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.40.1
> > diff -u -r1.1.1.1 -r1.1.1.1.40.1
> > --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1
> > +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> > @@ -171,7 +171,8 @@
> >   __u8 mc_loop:1,
> >                           recverr:1,
> >                           sndflow:1,
> > -                         pmtudisc:2;
> > +                         pmtudisc:2,
> > + ipv6only:1;
> >
> >   struct ipv6_mc_socklist *ipv6_mc_list;
> >   struct ipv6_fl_socklist *ipv6_fl_list;
> > @@ -188,6 +189,12 @@
> >   struct icmp6_filter filter;
> >  };
> >
> > +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only)
> > +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \
> > + (sk)->net_pinfo.af_inet6.ipv6only)
> > +#else
> > +#define __ipv6_only_sock(sk) 0
> > +#define ipv6_only_sock(sk) 0
> >  #endif /* IPV6 */
> >
> >  #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE)
> > Index: net/ipv4/tcp_ipv4.c
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v
> > retrieving revision 1.1.1.2
> > retrieving revision 1.1.1.2.16.2
> > diff -u -r1.1.1.2 -r1.1.1.2.16.2
> > --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2
> > +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2
> > @@ -45,9 +45,13 @@
> >   * Vitaly E. Lavrov : Transparent proxy revived after year coma.
> >   * Andi Kleen : Fix new listen.
> >   * Andi Kleen : Fix accept error reporting.
> > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> > + * allow both IPv4 and IPv6 sockets to bind
> > + * a single port at the same time.
> >   */
> >
> >  #include <linux/config.h>
> > +
> >  #include <linux/types.h>
> >  #include <linux/fcntl.h>
> >  #include <linux/random.h>
> > @@ -182,6 +186,7 @@
> >   for( ; sk2 != NULL; sk2 = sk2->bind_next) {
> >   if (sk != sk2 &&
> >       sk2->reuse <= 1 &&
> > +     !ipv6_only_sock(sk2) &&
> >       sk->bound_dev_if == sk2->bound_dev_if) {
> >   if (!sk_reuse ||
> >       !sk2->reuse ||
> > @@ -418,23 +423,27 @@
> >   struct sock *result = NULL;
> >   int score, hiscore;
> >
> > - hiscore=0;
> > + hiscore=-1;
> >   for(; sk; sk = sk->next) {
> > - if(sk->num == hnum) {
> > + if(sk->num == hnum && !ipv6_only_sock(sk)) {
> >   __u32 rcv_saddr = sk->rcv_saddr;
> >
> > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> > + score = sk->family == PF_INET ? 1 : 0;
> > +#else
> >   score = 1;
> > +#endif
> >   if(rcv_saddr) {
> >   if (rcv_saddr != daddr)
> >   continue;
> > - score++;
> > + score+=2;
> >   }
> >   if (sk->bound_dev_if) {
> >   if (sk->bound_dev_if != dif)
> >   continue;
> > - score++;
> > + score+=2;
> >   }
> > - if (score == 3)
> > + if (score == 5)
> >   return sk;
> >   if (score > hiscore) {
> >   hiscore = score;
> > @@ -456,6 +465,7 @@
> >   if (sk->num == hnum &&
> >       sk->next == NULL &&
> >       (!sk->rcv_saddr || sk->rcv_saddr == daddr) &&
> > +     (sk->family == PF_INET || !ipv6_only_sock(sk)) &&
> >       !sk->bound_dev_if)
> >   goto sherry_cache;
> >   sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif);
> > Index: net/ipv4/udp.c
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.40.1
> > diff -u -r1.1.1.1 -r1.1.1.1.40.1
> > --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> > +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> > @@ -61,6 +61,9 @@
> >   * return ENOTCONN for unconnected sockets (POSIX)
> >   * Janos Farkas : don't deliver multi/broadcasts to a different
> >   * bound-to-device socket
> > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> > + * allow both IPv4 and IPv6 sockets to bind
> > + * a single port at the same time.
> >   *
> >   *
> >   * This program is free software; you can redistribute it and/or
> > @@ -85,6 +88,7 @@
> >  #include <linux/netdevice.h>
> >  #include <net/snmp.h>
> >  #include <net/ip.h>
> > +#include <net/ipv6.h>
> >  #include <net/protocol.h>
> >  #include <linux/skbuff.h>
> >  #include <net/sock.h>
> > @@ -159,6 +163,7 @@
> >        sk2 = sk2->next) {
> >   if (sk2->num == snum &&
> >       sk2 != sk &&
> > +     !ipv6_only_sock(sk2) &&
> >       sk2->bound_dev_if == sk->bound_dev_if &&
> >       (!sk2->rcv_saddr ||
> >        !sk->rcv_saddr ||
> > @@ -215,29 +220,34 @@
> >   int badness = -1;
> >
> >   for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk =
> sk->next) {
> > - if(sk->num == hnum) {
> > - int score = 0;
> > + if(sk->num == hnum && !ipv6_only_sock(sk)) {
> > + int score;
> > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> > + score = sk->family == PF_INET ? 1 : 0;
> > +#else
> > + score = 1;
> > +#endif
> >   if(sk->rcv_saddr) {
> >   if(sk->rcv_saddr != daddr)
> >   continue;
> > - score++;
> > + score+=2;
> >   }
> >   if(sk->daddr) {
> >   if(sk->daddr != saddr)
> >   continue;
> > - score++;
> > + score+=2;
> >   }
> >   if(sk->dport) {
> >   if(sk->dport != sport)
> >   continue;
> > - score++;
> > + score+=2;
> >   }
> >   if(sk->bound_dev_if) {
> >   if(sk->bound_dev_if != dif)
> >   continue;
> > - score++;
> > + score+=2;
> >   }
> > - if(score == 4) {
> > + if(score == 9) {
> >   result = sk;
> >   break;
> >   } else if(score > badness) {
> > @@ -273,6 +283,7 @@
> >       (s->daddr && s->daddr!=rmt_addr) ||
> >       (s->dport != rmt_port && s->dport != 0) ||
> >       (s->rcv_saddr  && s->rcv_saddr != loc_addr) ||
> > +     ipv6_only_sock(s) ||
> >       (s->bound_dev_if && s->bound_dev_if != dif))
> >   continue;
> >   break;
> > Index: net/ipv6/af_inet6.c
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.36.1
> > diff -u -r1.1.1.1 -r1.1.1.1.36.1
> > --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> > +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1
> > @@ -88,6 +88,8 @@
> >  extern void ipv6_sysctl_unregister(void);
> >  #endif
> >
> > +int sysctl_ipv6_bindv6only;
> > +
> >  #ifdef INET_REFCNT_DEBUG
> >  atomic_t inet6_sock_nr;
> >  #endif
> > @@ -173,6 +175,8 @@
> >   sk->net_pinfo.af_inet6.mc_loop   = 1;
> >   sk->net_pinfo.af_inet6.pmtudisc   = IPV6_PMTUDISC_WANT;
> >
> > + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only;
> > +
> >   /* Init the ipv4 part of the socket since we can have sockets
> >   * using v6 API for ipv4.
> >   */
> > Index: net/ipv6/ipv6_sockglue.c
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.36.1
> > diff -u -r1.1.1.1 -r1.1.1.1.36.1
> > --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> > +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1
> > @@ -157,7 +157,8 @@
> >   break;
> >   }
> >
> > - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) {
> > + if (ipv6_only_sock(sk) ||
> > +     !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) {
> >   retv = -EADDRNOTAVAIL;
> >   break;
> >   }
> > @@ -203,6 +204,13 @@
> >   }
> >   goto e_inval;
> >
> > + case IPV6_V6ONLY:
> > + if (sk->num)
> > + goto e_inval;
> > + np->ipv6only = valbool;
> > + retv = 0;
> > + break;
> > +
> >   case IPV6_PKTINFO:
> >   np->rxopt.bits.rxinfo = valbool;
> >   retv = 0;
> > @@ -465,6 +473,10 @@
> >   return -ENOTCONN;
> >   break;
> >   }
> > +
> > + case IPV6_V6ONLY:
> > + val = np->ipv6only;
> > + break;
> >
> >   case IPV6_PKTINFO:
> >   val = np->rxopt.bits.rxinfo;
> > Index: net/ipv6/sysctl_net_ipv6.c
> > ===================================================================
> > RCS file:
> /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v
> > retrieving revision 1.1.1.1
> > retrieving revision 1.1.1.1.40.1
> > diff -u -r1.1.1.1 -r1.1.1.1.40.1
> > --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> > +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> > @@ -17,6 +17,8 @@
> >
> >  ctl_table ipv6_table[] = {
> >   {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table},
> > + {NET_IPV6_BINDV6ONLY, "bindv6only",
> > + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec},
> >   {0}
> >  };
> >
> > Index: net/ipv6/tcp_ipv6.c
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v
> > retrieving revision 1.1.1.2
> > retrieving revision 1.1.1.2.16.1
> > diff -u -r1.1.1.2 -r1.1.1.2.16.1
> > --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2
> > +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1
> > @@ -14,6 +14,9 @@
> >   *
> >   * Fixes:
> >   * Hideaki YOSHIFUJI : sin6_scope_id support
> > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> > + * allow both IPv4 and IPv6 sockets to bind
> > + * a single port at the same time.
> >   *
> >   * This program is free software; you can redistribute it and/or
> >   *      modify it under the terms of the GNU General Public License
> > @@ -148,14 +151,23 @@
> >       !sk2->reuse ||
> >       sk2->state == TCP_LISTEN) {
> >   /* NOTE: IPv6 tw bucket have different format */
> > - if (!sk2->rcv_saddr ||
> > -     addr_type == IPV6_ADDR_ANY ||
> > -     !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> > -    sk2->state != TCP_TIME_WAIT ?
> > -    &sk2->net_pinfo.af_inet6.rcv_saddr :
> > -    &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) ||
> > -     (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET &&
> > -      sk->rcv_saddr==sk2->rcv_saddr))
> > + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) ||
> > +     (sk2->family == AF_INET6 &&
> > +      ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) &&
> > +      !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) ||
> > +     (addr_type == IPV6_ADDR_ANY &&
> > +      (!ipv6_only_sock(sk) ||
> > +       !(sk2->family == AF_INET6 ?
> ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED :
> 1))) ||
> > +     (sk2->family == AF_INET6 &&
> > +      !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> > +     sk2->state != TCP_TIME_WAIT ?
> > +     &sk2->net_pinfo.af_inet6.rcv_saddr :
> > +     &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) ||
> > +     (addr_type == IPV6_ADDR_MAPPED &&
> > +      !ipv6_only_sock(sk2) &&
> > +      (!sk2->rcv_saddr ||
> > +       !sk->rcv_saddr ||
> > +       sk->rcv_saddr == sk2->rcv_saddr)))
> >   break;
> >   }
> >   }
> > @@ -601,6 +613,9 @@
> >   struct sockaddr_in sin;
> >
> >   SOCK_DEBUG(sk, "connect: ipv4 mapped\n");
> > +
> > + if (__ipv6_only_sock(sk))
> > + return -ENETUNREACH;
> >
> >   sin.sin_family = AF_INET;
> >   sin.sin_port = usin->sin6_port;
> > Index: net/ipv6/udp.c
> > ===================================================================
> > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v
> > retrieving revision 1.1.1.2
> > retrieving revision 1.1.1.2.16.1
> > diff -u -r1.1.1.2 -r1.1.1.2.16.1
> > --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2
> > +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1
> > @@ -11,6 +11,9 @@
> >   *
> >   * Fixes:
> >   * Hideaki YOSHIFUJI : sin6_scope_id support
> > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> > + * allow both IPv4 and IPv6 sockets to bind
> > + * a single port at the same time.
> >   *
> >   * This program is free software; you can redistribute it and/or
> >   *      modify it under the terms of the GNU General Public License
> > @@ -106,13 +109,21 @@
> >   if (sk2->num == snum &&
> >       sk2 != sk &&
> >       sk2->bound_dev_if == sk->bound_dev_if &&
> > -     (!sk2->rcv_saddr ||
> > -      addr_type == IPV6_ADDR_ANY ||
> > -      !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> > -     &sk2->net_pinfo.af_inet6.rcv_saddr) ||
> > +     ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) ||
> > +      (sk2->family == AF_INET6 &&
> > +       ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) &&
> > +       !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) ||
> > +      (addr_type == IPV6_ADDR_ANY &&
> > +       (!ipv6_only_sock(sk) ||
> > +        !(sk2->family == AF_INET6 ?
> (ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) :
> 1))) ||
> > +      (sk2->family == AF_INET6 &&
> > +       !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> > +      &sk2->net_pinfo.af_inet6.rcv_saddr)) ||
> >        (addr_type == IPV6_ADDR_MAPPED &&
> > -       sk2->family == AF_INET &&
> > -       sk->rcv_saddr == sk2->rcv_saddr)) &&
> > +       !ipv6_only_sock(sk2) &&
> > +       (!sk2->rcv_saddr ||
> > +        !sk->rcv_saddr ||
> > +        sk->rcv_saddr == sk2->rcv_saddr))) &&
> >       (!sk2->reuse || !sk->reuse))
> >   goto fail;
> >   }
> > @@ -221,6 +232,8 @@
> >   int err;
> >
> >   if (usin->sin6_family == AF_INET) {
> > + if (__ipv6_only_sock(sk))
> > + return -EAFNOSUPPORT;
> >   err = udp_connect(sk, uaddr, addr_len);
> >   goto ipv4_connected;
> >   }
> > @@ -256,6 +269,9 @@
> >   if (addr_type == IPV6_ADDR_MAPPED) {
> >   struct sockaddr_in sin;
> >
> > + if (__ipv6_only_sock(sk))
> > + return -ENETUNREACH;
> > +
> >   sin.sin_family = AF_INET;
> >   sin.sin_addr.s_addr = daddr->s6_addr32[3];
> >   sin.sin_port = usin->sin6_port;
> > @@ -783,8 +799,11 @@
> >   fl.oif = 0;
> >
> >   if (sin6) {
> > - if (sin6->sin6_family == AF_INET)
> > + if (sin6->sin6_family == AF_INET) {
> > + if (__ipv6_only_sock(sk))
> > + return -ENETUNREACH;
> >   return udp_sendmsg(sk, msg, ulen);
> > + }
> >
> >   if (addr_len < SIN6_LEN_RFC2133)
> >   return -EINVAL;
> > @@ -830,6 +849,9 @@
> >
> >   if (addr_type == IPV6_ADDR_MAPPED) {
> >   struct sockaddr_in sin;
> > +
> > + if (__ipv6_only_sock(sk))
> > + return -ENETUNREACH;
> >
> >   sin.sin_family = AF_INET;
> >   sin.sin_addr.s_addr = daddr->s6_addr32[3];
> >
> >
> 
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

(no subject)

[netdev-bounce]

Hi all,

First of all, I hope this is no inconvenience to anyone, but I thought it 
may be of interest to some people on the netdev mailinglist as well.

Just to inform people who may be interested, the ipsysctl tutorial has 
been released in a new version at http://ipsysctl-tutorial.frozentux.net. 

There are a lot of bugfixes in the new version, but no big additions at 
this time. I hope to spend more time the upcoming weeks with adding 
explanations about the route/ and neigh/ part of the sysctl's though. 

Comments are welcome, as always. Before anyone asks this time, no I will
not add explanations of the IPv6 sysctl's at this time since I want to
finish up what I have begun before I even think about that;). However, if
anyone wants to, they are more than welcome to write those sections up
themselves and send to me for inclusion.

Sorry for taking your time, I hope this will be of some help.

----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

(no subject)

[netdev-bounce]

On Wed, 23 Oct 2002 michael@albog.dk wrote:

> - What kernel version have most IPv6 features build-in ?? (Maybe a feature is 
> missing in 2.4.19. I have read an article about patching the kernel: 
> http://project6.ferrara.linux.it/papers/best_ipv6_support_4_linux/best_ipv6_supp
> ort_4_linux.html, it is necessary?).

micheal, that article is a bit obsolete. i will update it as soon as 
possible, but until next week there is no chance i can do it (friday i 
will get my MS degree in electronic engineering and i am __very__ busy 
now).

however, the choice of the kernel to use is quite simple: if you need the 
advanced features in usagi kernel (e.g. ISATAP, drop packets with fake 
ipv4-mapped address, RFC 3041 support, anycast support, allow default 
route when forwarding is enabled, Node Information Queries, IPSEC, MIPv6, 
IPv6-in-IPv6 tunneling) you should install the usagi kit. if not, use the 
standard vanilla kernel.


p.s. i wouldn't spend too much time working on ripng. if you wish 
     to analyze routing protocols, perhaps OSPF and BGP4+ would be 
     better choices.

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			mauro@ferrara.linux.it
				mauro.tortonesi@ing.unife.it
Ferrara Linux Users Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it

(no subject)

[netdev-bounce]

I'm just curious... what happened to the generic option, SO_ONEFAMILY, that
would replace
the need for IPV6_V6ONLY?



> In article <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002
19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says:
>
> > Actually, it would be great if you said what is wrong in that my patch?
> > It looks so simple that I am not ready to agree that real one should be
> > so complicated. :-)
>
> Well, I've refered alexey's patch and simplified many if-clauses.
> Here's the new patch and test results.  seems ok.
>
> --------------------
> Linux IPv6 stack provides the ability for IPv6 applications to
> interoperate with IPv4 applications.  Port space for TCP (or UDP) is
> shared by IPv6 and IPv4.  This conforms to RFC2553.
> However, some kind of applications may want to restrict their use of
> an IPv6 socket to IPv6 communication only.  IPV6_V6ONLY socket option is
> defined for such applications in RFC2553bis, which is successor of
RFC2553.
> This patch allows to bind both IPv6 and IPv4 sockets with the single
> port number at the same time if IPV6_V6ONLY socket options is set to
> the IPv6 socket.
>
> Packet delivery strategy is similar to one before, but we prefer
> IPv4 a bit.
>
> Test results and patch against 2.4.20-pre11 follows.
>
> *** Test for bind(2) ***
>
> [SOCK_DGRAM w/o IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 x x x x
> :: x x x x
> 127.1 x x x o
> ::1 x x o x
>
> ==> OK
>
> [SOCK_DGRAM w/ IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 x o x o
> :: o x o x
> 127.1 x o x o
> ::1 o x o x
>
> ==> OK
>
> [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 o o o o
> :: o o o o
> 127.1 o o o o
> ::1 o o o o
>
> ==> OK
>
> [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 o o o o
> :: o o o o
> 127.1 o o o o
> ::1 o o o o
>
> ==> OK
>
> [SOCK_STREAM w/o IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 x x x x
> :: x x x x
> 127.1 x x x o
> ::1 x x o x
>
> ==> OK
>
> [SOCK_STREAM w/ IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 x o x o
> :: o x o x
> 127.1 x o x o
> ::1 o x o x
>
> ==> OK
>
> [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 o o o o
> :: o o o o
> 127.1 o o o o
> ::1 o o o o
>
> ==> OK
>
> [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY]
> 0 :: 127.1 ::1
> 0 o o o o
> :: o o o o
> 127.1 o o o o
> ::1 o o o o
>
> ==> OK
>
> *** Test for Receiver ***
>
> [IPv6]
> 1a. :: <- ::1
> received from ::1
>
> 1b. :: w/IPV6_V6ONLY <- ::1
> received from ::1
>
> 2a. :: <- 127.0.0.1
> received from ::1
>
> 2b. :: w/IPV6_V6ONLY <- 127.0.0.1
> none received
>
> 3a. :: <- ff02::1
> received from fe80::EUI64
>
> 3b. :: w/IPV6_V6ONLY <- ff02::1
> received from fe80::EUI64
>
> 4a. :: <- 224.0.0.1
> received from ::ffff:ipv4addr
>
> 4b. :: w/IPV6_V6ONLY <- 224.0.0.1
> none received
>
> ==> OK
>
> [IPv4]
> 1. 0.0.0.0 <- ::1
> none received
>
> 2. 0.0.0.0 <- 127.0.0.1
> received from 127.0.0.1
>
> 3. 0.0.0.0 <- ff02::1
> none received
>
> 4. 0.0.0.0 <- 224.0.0.1
> received from ipv4addr
>
> ==> OK
>
> [IPv6 vs IPv4]
> 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1
> ipv6 received from ::1
>
> 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1
> ipv4 received from 127.0.0.1
>
> 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1
> ipv6 received from fe80::EUI64
>
> 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1
> ipv4 received from ipv4addra
>
> ==> OK
>
> -------------------------------------------------------------------
> Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number
(IPV6_V6ONLY Support) - Rev.2
> Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023
> Patch-Author: YOSHIFUJI Hideaki / USAGI Project <yoshfuji@linux-ipv6.org>
> Credit: YOSHIFUJI Hideaki / USAGI Project <yoshfuji@linux-ipv6.org>
> Reference: RFC2553bis
> -------------------------------------------------------------------
> Index: Documentation/networking/ip-sysctl.txt
> ===================================================================
> RCS file:
/cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt
,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.42.1
> diff -u -r1.1.1.1 -r1.1.1.1.42.1
> --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000
1.1.1.1
> +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000
1.1.1.1.42.1
> @@ -462,6 +462,15 @@
>  IPv6 has no global variables such as tcp_*.  tcp_* settings under ipv4/
also
>  apply to IPv6 [XXX?].
>
> +bindv6only - BOOLEAN
> + Default value for IPV6_V6ONLY socket option,
> + which restricts use of the IPv6 socket to IPv6 communication
> + only.
> + TRUE: disable IPv4-mapped address feature
> + FALSE: enable IPv4-mapped address feature
> +
> + Default: FALSE (as specified in RFC2553bis)
> +
>  conf/default/*:
>   Change the interface-specific default settings.
>
> Index: include/linux/in6.h
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.40.1
> diff -u -r1.1.1.1 -r1.1.1.1.40.1
> --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1
> +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> @@ -156,6 +156,7 @@
>  #define IPV6_MTU_DISCOVER 23
>  #define IPV6_MTU 24
>  #define IPV6_RECVERR 25
> +#define IPV6_V6ONLY 26
>
>  /* IPV6_MTU_DISCOVER values */
>  #define IPV6_PMTUDISC_DONT 0
> Index: include/linux/sysctl.h
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v
> retrieving revision 1.1.1.2
> retrieving revision 1.1.1.2.16.1
> diff -u -r1.1.1.2 -r1.1.1.2.16.1
> --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2
> +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1
> @@ -345,7 +345,8 @@
>  enum {
>   NET_IPV6_CONF=16,
>   NET_IPV6_NEIGH=17,
> - NET_IPV6_ROUTE=18
> + NET_IPV6_ROUTE=18,
> + NET_IPV6_BINDV6ONLY=20,
>  };
>
>  enum {
> Index: include/net/ipv6.h
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.38.1
> diff -u -r1.1.1.1 -r1.1.1.1.38.1
> --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1
> +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1
> @@ -88,6 +88,9 @@
>
>  #include <net/sock.h>
>
> +/* sysctls */
> +extern int sysctl_ipv6_bindv6only;
> +
>  extern struct ipv6_mib ipv6_statistics[NR_CPUS*2];
>  #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field)
>  #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field)
> Index: include/net/sock.h
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.40.1
> diff -u -r1.1.1.1 -r1.1.1.1.40.1
> --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1
> +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> @@ -171,7 +171,8 @@
>   __u8 mc_loop:1,
>                           recverr:1,
>                           sndflow:1,
> -                         pmtudisc:2;
> +                         pmtudisc:2,
> + ipv6only:1;
>
>   struct ipv6_mc_socklist *ipv6_mc_list;
>   struct ipv6_fl_socklist *ipv6_fl_list;
> @@ -188,6 +189,12 @@
>   struct icmp6_filter filter;
>  };
>
> +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only)
> +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \
> + (sk)->net_pinfo.af_inet6.ipv6only)
> +#else
> +#define __ipv6_only_sock(sk) 0
> +#define ipv6_only_sock(sk) 0
>  #endif /* IPV6 */
>
>  #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE)
> Index: net/ipv4/tcp_ipv4.c
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v
> retrieving revision 1.1.1.2
> retrieving revision 1.1.1.2.16.2
> diff -u -r1.1.1.2 -r1.1.1.2.16.2
> --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2
> +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2
> @@ -45,9 +45,13 @@
>   * Vitaly E. Lavrov : Transparent proxy revived after year coma.
>   * Andi Kleen : Fix new listen.
>   * Andi Kleen : Fix accept error reporting.
> + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> + * allow both IPv4 and IPv6 sockets to bind
> + * a single port at the same time.
>   */
>
>  #include <linux/config.h>
> +
>  #include <linux/types.h>
>  #include <linux/fcntl.h>
>  #include <linux/random.h>
> @@ -182,6 +186,7 @@
>   for( ; sk2 != NULL; sk2 = sk2->bind_next) {
>   if (sk != sk2 &&
>       sk2->reuse <= 1 &&
> +     !ipv6_only_sock(sk2) &&
>       sk->bound_dev_if == sk2->bound_dev_if) {
>   if (!sk_reuse ||
>       !sk2->reuse ||
> @@ -418,23 +423,27 @@
>   struct sock *result = NULL;
>   int score, hiscore;
>
> - hiscore=0;
> + hiscore=-1;
>   for(; sk; sk = sk->next) {
> - if(sk->num == hnum) {
> + if(sk->num == hnum && !ipv6_only_sock(sk)) {
>   __u32 rcv_saddr = sk->rcv_saddr;
>
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> + score = sk->family == PF_INET ? 1 : 0;
> +#else
>   score = 1;
> +#endif
>   if(rcv_saddr) {
>   if (rcv_saddr != daddr)
>   continue;
> - score++;
> + score+=2;
>   }
>   if (sk->bound_dev_if) {
>   if (sk->bound_dev_if != dif)
>   continue;
> - score++;
> + score+=2;
>   }
> - if (score == 3)
> + if (score == 5)
>   return sk;
>   if (score > hiscore) {
>   hiscore = score;
> @@ -456,6 +465,7 @@
>   if (sk->num == hnum &&
>       sk->next == NULL &&
>       (!sk->rcv_saddr || sk->rcv_saddr == daddr) &&
> +     (sk->family == PF_INET || !ipv6_only_sock(sk)) &&
>       !sk->bound_dev_if)
>   goto sherry_cache;
>   sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif);
> Index: net/ipv4/udp.c
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.40.1
> diff -u -r1.1.1.1 -r1.1.1.1.40.1
> --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> @@ -61,6 +61,9 @@
>   * return ENOTCONN for unconnected sockets (POSIX)
>   * Janos Farkas : don't deliver multi/broadcasts to a different
>   * bound-to-device socket
> + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> + * allow both IPv4 and IPv6 sockets to bind
> + * a single port at the same time.
>   *
>   *
>   * This program is free software; you can redistribute it and/or
> @@ -85,6 +88,7 @@
>  #include <linux/netdevice.h>
>  #include <net/snmp.h>
>  #include <net/ip.h>
> +#include <net/ipv6.h>
>  #include <net/protocol.h>
>  #include <linux/skbuff.h>
>  #include <net/sock.h>
> @@ -159,6 +163,7 @@
>        sk2 = sk2->next) {
>   if (sk2->num == snum &&
>       sk2 != sk &&
> +     !ipv6_only_sock(sk2) &&
>       sk2->bound_dev_if == sk->bound_dev_if &&
>       (!sk2->rcv_saddr ||
>        !sk->rcv_saddr ||
> @@ -215,29 +220,34 @@
>   int badness = -1;
>
>   for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk =
sk->next) {
> - if(sk->num == hnum) {
> - int score = 0;
> + if(sk->num == hnum && !ipv6_only_sock(sk)) {
> + int score;
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> + score = sk->family == PF_INET ? 1 : 0;
> +#else
> + score = 1;
> +#endif
>   if(sk->rcv_saddr) {
>   if(sk->rcv_saddr != daddr)
>   continue;
> - score++;
> + score+=2;
>   }
>   if(sk->daddr) {
>   if(sk->daddr != saddr)
>   continue;
> - score++;
> + score+=2;
>   }
>   if(sk->dport) {
>   if(sk->dport != sport)
>   continue;
> - score++;
> + score+=2;
>   }
>   if(sk->bound_dev_if) {
>   if(sk->bound_dev_if != dif)
>   continue;
> - score++;
> + score+=2;
>   }
> - if(score == 4) {
> + if(score == 9) {
>   result = sk;
>   break;
>   } else if(score > badness) {
> @@ -273,6 +283,7 @@
>       (s->daddr && s->daddr!=rmt_addr) ||
>       (s->dport != rmt_port && s->dport != 0) ||
>       (s->rcv_saddr  && s->rcv_saddr != loc_addr) ||
> +     ipv6_only_sock(s) ||
>       (s->bound_dev_if && s->bound_dev_if != dif))
>   continue;
>   break;
> Index: net/ipv6/af_inet6.c
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.36.1
> diff -u -r1.1.1.1 -r1.1.1.1.36.1
> --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1
> @@ -88,6 +88,8 @@
>  extern void ipv6_sysctl_unregister(void);
>  #endif
>
> +int sysctl_ipv6_bindv6only;
> +
>  #ifdef INET_REFCNT_DEBUG
>  atomic_t inet6_sock_nr;
>  #endif
> @@ -173,6 +175,8 @@
>   sk->net_pinfo.af_inet6.mc_loop   = 1;
>   sk->net_pinfo.af_inet6.pmtudisc   = IPV6_PMTUDISC_WANT;
>
> + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only;
> +
>   /* Init the ipv4 part of the socket since we can have sockets
>   * using v6 API for ipv4.
>   */
> Index: net/ipv6/ipv6_sockglue.c
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.36.1
> diff -u -r1.1.1.1 -r1.1.1.1.36.1
> --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1
> @@ -157,7 +157,8 @@
>   break;
>   }
>
> - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) {
> + if (ipv6_only_sock(sk) ||
> +     !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) {
>   retv = -EADDRNOTAVAIL;
>   break;
>   }
> @@ -203,6 +204,13 @@
>   }
>   goto e_inval;
>
> + case IPV6_V6ONLY:
> + if (sk->num)
> + goto e_inval;
> + np->ipv6only = valbool;
> + retv = 0;
> + break;
> +
>   case IPV6_PKTINFO:
>   np->rxopt.bits.rxinfo = valbool;
>   retv = 0;
> @@ -465,6 +473,10 @@
>   return -ENOTCONN;
>   break;
>   }
> +
> + case IPV6_V6ONLY:
> + val = np->ipv6only;
> + break;
>
>   case IPV6_PKTINFO:
>   val = np->rxopt.bits.rxinfo;
> Index: net/ipv6/sysctl_net_ipv6.c
> ===================================================================
> RCS file:
/cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v
> retrieving revision 1.1.1.1
> retrieving revision 1.1.1.1.40.1
> diff -u -r1.1.1.1 -r1.1.1.1.40.1
> --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1
> +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1
> @@ -17,6 +17,8 @@
>
>  ctl_table ipv6_table[] = {
>   {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table},
> + {NET_IPV6_BINDV6ONLY, "bindv6only",
> + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec},
>   {0}
>  };
>
> Index: net/ipv6/tcp_ipv6.c
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v
> retrieving revision 1.1.1.2
> retrieving revision 1.1.1.2.16.1
> diff -u -r1.1.1.2 -r1.1.1.2.16.1
> --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2
> +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1
> @@ -14,6 +14,9 @@
>   *
>   * Fixes:
>   * Hideaki YOSHIFUJI : sin6_scope_id support
> + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> + * allow both IPv4 and IPv6 sockets to bind
> + * a single port at the same time.
>   *
>   * This program is free software; you can redistribute it and/or
>   *      modify it under the terms of the GNU General Public License
> @@ -148,14 +151,23 @@
>       !sk2->reuse ||
>       sk2->state == TCP_LISTEN) {
>   /* NOTE: IPv6 tw bucket have different format */
> - if (!sk2->rcv_saddr ||
> -     addr_type == IPV6_ADDR_ANY ||
> -     !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> -    sk2->state != TCP_TIME_WAIT ?
> -    &sk2->net_pinfo.af_inet6.rcv_saddr :
> -    &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) ||
> -     (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET &&
> -      sk->rcv_saddr==sk2->rcv_saddr))
> + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) ||
> +     (sk2->family == AF_INET6 &&
> +      ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) &&
> +      !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) ||
> +     (addr_type == IPV6_ADDR_ANY &&
> +      (!ipv6_only_sock(sk) ||
> +       !(sk2->family == AF_INET6 ?
ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED :
1))) ||
> +     (sk2->family == AF_INET6 &&
> +      !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> +     sk2->state != TCP_TIME_WAIT ?
> +     &sk2->net_pinfo.af_inet6.rcv_saddr :
> +     &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) ||
> +     (addr_type == IPV6_ADDR_MAPPED &&
> +      !ipv6_only_sock(sk2) &&
> +      (!sk2->rcv_saddr ||
> +       !sk->rcv_saddr ||
> +       sk->rcv_saddr == sk2->rcv_saddr)))
>   break;
>   }
>   }
> @@ -601,6 +613,9 @@
>   struct sockaddr_in sin;
>
>   SOCK_DEBUG(sk, "connect: ipv4 mapped\n");
> +
> + if (__ipv6_only_sock(sk))
> + return -ENETUNREACH;
>
>   sin.sin_family = AF_INET;
>   sin.sin_port = usin->sin6_port;
> Index: net/ipv6/udp.c
> ===================================================================
> RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v
> retrieving revision 1.1.1.2
> retrieving revision 1.1.1.2.16.1
> diff -u -r1.1.1.2 -r1.1.1.2.16.1
> --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2
> +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1
> @@ -11,6 +11,9 @@
>   *
>   * Fixes:
>   * Hideaki YOSHIFUJI : sin6_scope_id support
> + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which
> + * allow both IPv4 and IPv6 sockets to bind
> + * a single port at the same time.
>   *
>   * This program is free software; you can redistribute it and/or
>   *      modify it under the terms of the GNU General Public License
> @@ -106,13 +109,21 @@
>   if (sk2->num == snum &&
>       sk2 != sk &&
>       sk2->bound_dev_if == sk->bound_dev_if &&
> -     (!sk2->rcv_saddr ||
> -      addr_type == IPV6_ADDR_ANY ||
> -      !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> -     &sk2->net_pinfo.af_inet6.rcv_saddr) ||
> +     ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) ||
> +      (sk2->family == AF_INET6 &&
> +       ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) &&
> +       !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) ||
> +      (addr_type == IPV6_ADDR_ANY &&
> +       (!ipv6_only_sock(sk) ||
> +        !(sk2->family == AF_INET6 ?
(ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) :
1))) ||
> +      (sk2->family == AF_INET6 &&
> +       !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr,
> +      &sk2->net_pinfo.af_inet6.rcv_saddr)) ||
>        (addr_type == IPV6_ADDR_MAPPED &&
> -       sk2->family == AF_INET &&
> -       sk->rcv_saddr == sk2->rcv_saddr)) &&
> +       !ipv6_only_sock(sk2) &&
> +       (!sk2->rcv_saddr ||
> +        !sk->rcv_saddr ||
> +        sk->rcv_saddr == sk2->rcv_saddr))) &&
>       (!sk2->reuse || !sk->reuse))
>   goto fail;
>   }
> @@ -221,6 +232,8 @@
>   int err;
>
>   if (usin->sin6_family == AF_INET) {
> + if (__ipv6_only_sock(sk))
> + return -EAFNOSUPPORT;
>   err = udp_connect(sk, uaddr, addr_len);
>   goto ipv4_connected;
>   }
> @@ -256,6 +269,9 @@
>   if (addr_type == IPV6_ADDR_MAPPED) {
>   struct sockaddr_in sin;
>
> + if (__ipv6_only_sock(sk))
> + return -ENETUNREACH;
> +
>   sin.sin_family = AF_INET;
>   sin.sin_addr.s_addr = daddr->s6_addr32[3];
>   sin.sin_port = usin->sin6_port;
> @@ -783,8 +799,11 @@
>   fl.oif = 0;
>
>   if (sin6) {
> - if (sin6->sin6_family == AF_INET)
> + if (sin6->sin6_family == AF_INET) {
> + if (__ipv6_only_sock(sk))
> + return -ENETUNREACH;
>   return udp_sendmsg(sk, msg, ulen);
> + }
>
>   if (addr_len < SIN6_LEN_RFC2133)
>   return -EINVAL;
> @@ -830,6 +849,9 @@
>
>   if (addr_type == IPV6_ADDR_MAPPED) {
>   struct sockaddr_in sin;
> +
> + if (__ipv6_only_sock(sk))
> + return -ENETUNREACH;
>
>   sin.sin_family = AF_INET;
>   sin.sin_addr.s_addr = daddr->s6_addr32[3];
>
>

(no subject)

[jenil68]

[-- Attachment #1: Type: text/html, Size: 191 bytes --]

(no subject)

[mike obi]

                       STRICTLY CONFIDENTIAL 

>From the Desk of: Dr. Mike Obi
EKO INTERNATIONAL BANK PLC, NIGERIA . 


ATTN: MANAGING DIRECTOR/CEO,


Sir,
 

Permit me to introduce myself to you. My name is Mr Mike Obi, Manager with Eko 
international bank Plc, Lagos-Nigeria. 

I came to know about you in my private search for a reliable person/company to 
handle a confidential transaction on behalf of my Colleagues and myself.As a 
matter of fact, I got your information from the Nigerian Chamber of Commerce and 
Industry/Nigerian Export Promotion Council. 

Proposition 
A German Mr. Wolfgang Schinister, 66 years of age and a prosperous oil merchant 
had in our Bank the sum of US$35.5m in a domiciliary account. He named his wife, 
Mrs. Helga Schinister as the next of kin. Unfortunately, two of them were killed 
in the recent plane crash involving concord AF4590 in Gonesse, France. Efforts 
had been made by the management of my Bank through the German Embassy in Lagos 
to contact any of the deceased children but to no avail, as we were made to 
understand that the couple had no children. Given the skeletal information 
available to the Bank, it has so far been impossible to reach any of the 
relatives. The option left for the Bank management is to declare the deceased 
account dormant and revert the funds to trading on behalf of and in the interest 
of the Bank. 

In Nigeria, and almost all other parts of African continent,when Banks acquire 
funds such as that of Mr.Wolfgang Schinister,they are required by law to donate 
30% of the funds on acquisation to The Trust Fund For Arms And Amunitions. Arms 
and amunitions purchased with funds from the Trust Fund are used to further 
enhance the course of war in Africa and invariably turbulence of some sort in 
the world in general. 

It is therefore in order to avoid/avert and discourage this negative development 
that my Colleagues and I now seek your assistance to have you stand as a distant 
relative to Mr. and Mrs. Wolfgang Schinister, so that the funds would be 
released to you. All documents and proofs to enable you get the funds will be 
carefully packaged once we receive your consent on this proposal. 

May I assured you that this Transaction is 100% safe and risk-free, as we have 
taken care of all necessary modalities to ensure a hitch-free transaction. 

I have the authority of my partners involved in this transaction to propose that 
should you be willing to assist us in the transaction your share would be 20% of 
the US$35.5 million, 70% for us and 10% for taxation and other miscellaneous 
expenses that may be incured in this transaction. 

I have reposed my confidence in you and hope that you will not disappoint me. 

Best Regards. 

Dr. Mike Obi






------------------------------------------------------------
http://Game.37.com/  <--- Free Games
http://newJoke.com/   <---  J O K E S  ! ! !


---------------------------------------------------------------------
Express yourself with a super cool email address from BigMailBox.com.
Hundreds of choices. It's free!
http://www.bigmailbox.com
---------------------------------------------------------------------

(no subject)

[santosh kumar gowda]

Well, i have a Linux machine i686 and an IAD based on MIPS 32-bit 
arch,
both enabled with IPv6.

Linux with 2.4.18-14 based on i686 configured as...
# ip -6 addr add 3ff3:1234::1/64 dev eth0
# ip -6 route add 3ffe:1234/64 dev eth0

IAD with 2.4.5-pre1 kernel based on MIPS 32-bit core configured 
as...
# ip -6 addr add 3ff3:1234::2/64 dev epmac1
# ip -6 route add 3ff3:1234/64dev epmac1
--------------------------------------------------
My IAD has a Flash, where the Linux kernel and the filesystem
images are present.
Flash size = 16MB
Filesystem is jffs2
Generated partitions are...
yamon partition size:2048 Kb
kernel partition size: 1024 Kb
rw image size: 10624 Kb
env partition size:128 Kb

Total: 13824 Kb
------------------------------

These two are connected in a IPv4 based LAN.
When i try to ping6 from Linux machine to the IAD,
my IAD hangs and generates a kernel OOps message.
Below is the snap shot of the message...

Following message is produced at the IAD terminal.....

# Unable to handle kernel paging request at virtual address 
00000000, epc == 802
4ce74, ra == 802592a8
Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 1000fc00 8024ce70 8032bbbc
$4 : 00000000 83cbf120 00000000 83cbf17c
$8 : 00000001 0000000f 8030e000 00000003
$12: 00000416 83f69e18 00000000 8030914b
$16: fffffffd 00000000 00000018 c0026d20
$20: 81120dc0 83cbf17c 83cbf17c 00000000
$24: 00000001 2ac1d440
$28: 80106000 80107d78 83cbf120 802592a8
epc   : 8024ce74
Status: 1000fc03
Cause : 00800008
Process swapper (pid: 0, stackpage=80106000)
Stack: 00000008 00000000 83a00000 00000000 fd010018 83a11860 
8031fd50 00000000
        00000000 8024ca40 00000000 0000002c 8e8e1dac 00000000 
fffffffd 83cbf120
        00000000 83cbf17c c0026d20 00000000 00000000 00000000 
800e1d38 80259b0c
        83a53346 801efd1c 83a53346 839e92a0 00000000 83a118e0 
83a53346 00000000
        8022a1ec 80229e90 00000001 83cbf120 0000000e 8008a0e0 
04000000 00000000
        801f9384 ...
Call Trace: [<8024ca40>] [<c0026d20>] [<80259b0c>] [<801efd1c>] 
[<8022a1ec>] [<8
0229e90>] [<801f9384>] [<8024c97c>] [<8011f6b0>] [<8011f214>] 
[<801f5674>] [<801
1af14>] [<8011f73c>] [<8011ad88>] [<8011aacc>] [<8011aacc>] 
[<801117cc>] [<80111
7cc>] [<8010a478>] [<8010dee8>] [<80107fe0>] [<80125700>] 
[<801117cc>] [<8010600
0>] [<80107f60>] [<8010870c>] [<801086f0>] [<80108a78>] 
[<80115470>] [<802bfffc>
] [<802b7d30>] [<802c0b48>] [<801005e8>]
Code: 03e00008  27bd0030  00803021 <8cc50000> 30a400e0  10800003  
240300e0  1483
0034  24020001

Suggestions/Tips are welcome.

-San
-------------------------------------

Re: (no subject)

[Maciej W. Rozycki]

On 21 Feb 2003, santosh kumar gowda wrote:

> Following message is produced at the IAD terminal.....
> 
> # Unable to handle kernel paging request at virtual address 
> 00000000, epc == 802
> 4ce74, ra == 802592a8
> Oops in fault.c:do_page_fault, line 172:
[...]
> Suggestions/Tips are welcome.

 Decode the oops first or nobody will be able to give any help.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

(no subject)

[sakalra]

Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 65256CEF.00322355 ; Thu, 20 Mar 2003 14:37:38 +0530
X-Lotus-FromDomain: HSS
From: sakalra@hss.hns.com
To: netdev@oss.sgi.com
Message-ID: <65256CEF.003222C0.00@dlfmail1.hss.hns.com>
Date: Thu, 20 Mar 2003 14:53:11 +0530
Subject: unsubscribe

(no subject)

[James Morris]

Hi Dave,

Please pull from bk://kernel.bkbits.net/jmorris/net-2.5 for the followng 
changesets:

ChangeSet@1.1525.1.1, 2003-06-29 20:37:48+10:00, yoshfuji@linux-ipv6.org
  [IPV6] Don't set M flag in last fragment.

ChangeSet@1.1525.1.2, 2003-06-29 20:38:55+10:00, yoshfuji@linux-ipv6.org
  [IPV6] Use macro for M-Flag and clean-up.

ChangeSet@1.1525.1.3, 2003-06-29 20:40:01+10:00, yoshfuji@linux-ipv6.org
  [IPV6] Convert /proc/net/ip6_flowlabel to seq_file.

ChangeSet@1.1528, 2003-06-30 01:53:54+10:00, yoshfuji@linux-ipv6.org
  [XFRM] Fix typo.

ChangeSet@1.1529, 2003-06-30 02:17:41+10:00, herbert@gondor.apana.org.au
  [XFRM] Set SA saddr correctly
  
ChangeSet@1.1525.2.1, 2003-06-30 02:28:59+10:00, herbert@gondor.apana.org.au
  [IPSEC] split xfrm_state_replace + fixes



- James
-- 
James Morris
<jmorris@intercode.com.au>

(no subject)

[David S. Miller]

   From: James Morris <jmorris@intercode.com.au>
   Date: Mon, 30 Jun 2003 09:00:49 +1000 (EST)

   Please pull from bk://kernel.bkbits.net/jmorris/net-2.5 for the followng 
   changesets:

Pulled, thanks James.

(no subject)

[bob.olszewski]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]






Hi,
I caught your name on a site and was wondering if you had any advise on this
scenario.
I'm running HA on multi-networked server, one interface (eth1) 

[-- Attachment #2: Type: text/plain, Size: 469 bytes --]


 is a member of
the HA group that customers connect to, the other (eth0) is where it gets its
feed from ( not running HA).  Problem I have, is if the feed source interface
(eth0) goes down the server can not deliver data.
I can not run eth0 in HA, our app. on the feed source side allows only one
connection.

Is there any way to config heartbeat to recognize that if a non-HA'd interface
goes down to make the interface that "is" in an HA group fail over ?

(no subject)

[mailperson]

(no subject)

[Robert Olsson]

From: Robert Olsson <robert@robur.slu.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16233.64248.666702.679433@robur.slu.se>
Date: Thu, 18 Sep 2003 20:35:36 +0200
To: Andrew Morton <akpm@osdl.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
    davem@redhat.com,
    netdev@oss.sgi.com
Subject: Re: netif_poll_disable() hangs
In-Reply-To: <20030908002914.737122a9.akpm@osdl.org>
References: <20030907232145.6ec197fd.akpm@osdl.org>
	<3F5C2D1A.5050500@pobox.com>
	<20030908002914.737122a9.akpm@osdl.org>
X-Mailer: VM 6.92 under Emacs 21.2.1


Andrew Morton writes:
 > > > 
 > > > 	ifup eth0
 > > > 	ifdown eth0
 > > > 	ifup eth0
 > > > 	ifdown eth0	<- hangs in dev_close -> netif_poll_disable()

 > 2.4 does test_bit, 2.6 does test_and_set_bit.

 
 Yeep. I noticed this too in 2.6.0-test5


--- include/linux/netdevice.h.orig	2003-09-08 21:50:31.000000000 +0200
+++ include/linux/netdevice.h	2003-09-17 17:27:58.000000000 +0200
@@ -830,9 +830,9 @@
 	local_irq_restore(flags);
 }
 
-static inline void netif_poll_disable(struct net_device *dev)
+static inline void netif_poll_sync(struct net_device *dev)
 {
-	while (test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
+	while (test_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
 		/* No hurry. */
 		current->state = TASK_INTERRUPTIBLE;
 		schedule_timeout(1);
--- net/core/dev.c.orig	2003-09-08 21:50:06.000000000 +0200
+++ net/core/dev.c	2003-09-17 17:28:32.000000000 +0200
@@ -841,7 +841,7 @@
 	 * engine, but this requires more changes in devices. */
 
 	smp_mb__after_clear_bit(); /* Commit netif_running(). */
-	netif_poll_disable(dev);
+	netif_poll_sync(dev);
 
 	/*
 	 *	Call the device specific close. This cannot fail.


Cheers.

					--ro

(no subject)

[EBLAZHJ]

X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.0.0-r6961 (2004-03-01) on oss.sgi.com
X-Spam-Report: 
	*  2.0 NO_REAL_NAME From: does not include a real name
	*  4.0 BAYES_90 BODY: Bayesian spam probability is 90 to 99%
	*      [score: 0.9853]
	*  3.0 BIZ_TLD URI: Contains a URL in the BIZ top-level domain
	*  3.0 MISSING_HEADERS Missing To: header
	*  3.0 MSGID_FROM_MTA_SHORT Message-Id was added by a relay
	*  1.3 RCVD_IN_SORBS_MISC RBL: SORBS: sender is open proxy server
	*      [24.20.7.231 listed in dnsbl.sorbs.net]
	*  0.7 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org
	*      [<http://dsbl.org/listing?ip=24.20.7.231>]
	*  0.6 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy
	*      [24.20.7.231 listed in dnsbl.njabl.org]
	*  1.5 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
	*      [Blocked - see <http://www.spamcop.net/bl.shtml?24.20.7.231>]
	*  1.0 URIBL_SBLXBL Contains a URL listed in the SBL/XBL blocklist
	*      [URIs: populardrugs.biz]
	*  1.0 URIBL_SORBS Contains a URL listed in the SORBS blocklist
	*      [URIs: populardrugs.biz]
X-Spam-Status: Yes, score=21.1 required=5.0 tests=BAYES_90,BIZ_TLD,
	MISSING_HEADERS,MSGID_FROM_MTA_SHORT,NO_REAL_NAME,
	RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,
	RCVD_IN_SORBS_MISC,URIBL_SBLXBL,URIBL_SORBS autolearn=spam 
	version=3.0.0-r6961
X-Spam-Level: *********************

dsOKJ3bcp59EUauRT/QJ4PBwtJiDXsEEWpuxBNhea365T
Received: from dossier-zc615.astatine.chello.nl([105.178.211.74]) by
doj7-bv4.chello.nl
with Microsoft SMTPSVC(5.0.2195.6824);
	 Sun, 21 Mar 2004 19:13:39 -0500
From: Augustine Dunn <EBLAZHJ@btopenworld.com>
To: netdev@oss.sgi.com
Subject: Fwd: Screw Physicians. All prescriptions filled. V|a|lium.V1cod1n.v:aGr@.|XANAX|.PSKOQAQT
Date: Mon, 22 Mar 2004 02:20:39 +0200 EST
Message-ID:
<53438480744320.43.9445342518@dna77-hyr60.chello.nl>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--67098397390295058860"

----67098397390295058860
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable


<!DOCTYPE html public "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www=
w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>All the medications You Will Ever Need</TITLE>

</HEAD>
<BODY>

<a href=3D"http://www.populardrugs.biz"><img src=3D"http://populardrugs.bi=
z/viz/4.gif" border=3D"0"></a>

</BODY>
</HTML>

----67098397390295058860--

(no subject)

[ananth]

Hi, 

  I am using a DualProcessor Xeon 2.0GHz with 4 Intel PRO 1000 MT desktop
adapters using latest e1000 driver with NAPI enabled.(Linux 2.4.20-8 smp
kernel). When I tried to send packets through more than one interface at a high
speed (>200 Mbps) using raw sockets, my system is hanging. Is this a kernel bug?
Can anyone please suggest some method to achieve this. 

Thanks in advance,
Ananth. 

(no subject)

[Denis Vlasenko]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

According to my measurements,

ip_vs_control_add() (from include/net/ip_vs.h) is called twice
and
sock_queue_rcv_skb() (from include/net/sock.h) is called 19 times
from various kernel .c files.

Both these includes generate more than 500 bytes of code on x86.

These patches uninline them. Please apply.
--
vda

[-- Attachment #2: net_inline1.patch --]
[-- Type: text/x-diff, Size: 3711 bytes --]

diff -urN linux-2.6.5.orig/include/net/ip_vs.h linux-2.6.5.net_inline/include/net/ip_vs.h
--- linux-2.6.5.orig/include/net/ip_vs.h	Mon Apr 12 15:42:10 2004
+++ linux-2.6.5.net_inline/include/net/ip_vs.h	Mon Apr 12 15:46:43 2004
@@ -766,53 +766,8 @@
 extern void ip_vs_random_dropentry(void);
 extern int ip_vs_conn_init(void);
 extern void ip_vs_conn_cleanup(void);
-
-static inline void ip_vs_control_del(struct ip_vs_conn *cp)
-{
-	struct ip_vs_conn *ctl_cp = cp->control;
-	if (!ctl_cp) {
-		IP_VS_ERR("request control DEL for uncontrolled: "
-			  "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
-			  NIPQUAD(cp->caddr),ntohs(cp->cport),
-			  NIPQUAD(cp->vaddr),ntohs(cp->vport));
-		return;
-	}
-
-	IP_VS_DBG(7, "DELeting control for: "
-		  "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
-		  NIPQUAD(cp->caddr),ntohs(cp->cport),
-		  NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
-
-	cp->control = NULL;
-	if (atomic_read(&ctl_cp->n_control) == 0) {
-		IP_VS_ERR("BUG control DEL with n=0 : "
-			  "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
-			  NIPQUAD(cp->caddr),ntohs(cp->cport),
-			  NIPQUAD(cp->vaddr),ntohs(cp->vport));
-		return;
-	}
-	atomic_dec(&ctl_cp->n_control);
-}
-
-static inline void
-ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp)
-{
-	if (cp->control) {
-		IP_VS_ERR("request control ADD for already controlled: "
-			  "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
-			  NIPQUAD(cp->caddr),ntohs(cp->cport),
-			  NIPQUAD(cp->vaddr),ntohs(cp->vport));
-		ip_vs_control_del(cp);
-	}
-
-	IP_VS_DBG(7, "ADDing control for: "
-		  "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
-		  NIPQUAD(cp->caddr),ntohs(cp->cport),
-		  NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
-
-	cp->control = ctl_cp;
-	atomic_inc(&ctl_cp->n_control);
-}
+extern void ip_vs_control_del(struct ip_vs_conn *cp);
+extern void ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp);
 
 
 /*
diff -urN linux-2.6.5.orig/net/ipv4/ipvs/ip_vs_core.c linux-2.6.5.net_inline/net/ipv4/ipvs/ip_vs_core.c
--- linux-2.6.5.orig/net/ipv4/ipvs/ip_vs_core.c	Sun Apr  4 06:36:13 2004
+++ linux-2.6.5.net_inline/net/ipv4/ipvs/ip_vs_core.c	Mon Apr 12 15:59:10 2004
@@ -199,6 +199,57 @@
 	return 1;
 }
 
+
+void
+ip_vs_control_del(struct ip_vs_conn *cp)
+{
+	struct ip_vs_conn *ctl_cp = cp->control;
+	if (!ctl_cp) {
+		IP_VS_ERR("request control DEL for uncontrolled: "
+			  "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
+			  NIPQUAD(cp->caddr),ntohs(cp->cport),
+			  NIPQUAD(cp->vaddr),ntohs(cp->vport));
+		return;
+	}
+
+	IP_VS_DBG(7, "DELeting control for: "
+		  "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
+		  NIPQUAD(cp->caddr),ntohs(cp->cport),
+		  NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
+
+	cp->control = NULL;
+	if (atomic_read(&ctl_cp->n_control) == 0) {
+		IP_VS_ERR("BUG control DEL with n=0 : "
+			  "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
+			  NIPQUAD(cp->caddr),ntohs(cp->cport),
+			  NIPQUAD(cp->vaddr),ntohs(cp->vport));
+		return;
+	}
+	atomic_dec(&ctl_cp->n_control);
+}
+
+
+void
+ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp)
+{
+	if (cp->control) {
+		IP_VS_ERR("request control ADD for already controlled: "
+			  "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
+			  NIPQUAD(cp->caddr),ntohs(cp->cport),
+			  NIPQUAD(cp->vaddr),ntohs(cp->vport));
+		ip_vs_control_del(cp);
+	}
+
+	IP_VS_DBG(7, "ADDing control for: "
+		  "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
+		  NIPQUAD(cp->caddr),ntohs(cp->cport),
+		  NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
+
+	cp->control = ctl_cp;
+	atomic_inc(&ctl_cp->n_control);
+}
+
+
 /*
  *  IPVS persistent scheduling function
  *  It creates a connection entry according to its template if exists,

[-- Attachment #3: net_inline2.patch --]
[-- Type: text/x-diff, Size: 2731 bytes --]

diff -urN linux-2.6.5.orig/include/net/sock.h linux-2.6.5.net_inline2/include/net/sock.h
--- linux-2.6.5.orig/include/net/sock.h	Sun Apr  4 06:37:37 2004
+++ linux-2.6.5.net_inline2/include/net/sock.h	Mon Apr 12 16:05:03 2004
@@ -898,45 +898,7 @@
 	atomic_add(skb->truesize, &sk->sk_rmem_alloc);
 }
 
-static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
-{
-	int err = 0;
-	int skb_len;
-
-	/* Cast skb->rcvbuf to unsigned... It's pointless, but reduces
-	   number of warnings when compiling with -W --ANK
-	 */
-	if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
-	    (unsigned)sk->sk_rcvbuf) {
-		err = -ENOMEM;
-		goto out;
-	}
-
-	/* It would be deadlock, if sock_queue_rcv_skb is used
-	   with socket lock! We assume that users of this
-	   function are lock free.
-	*/
-	err = sk_filter(sk, skb, 1);
-	if (err)
-		goto out;
-
-	skb->dev = NULL;
-	skb_set_owner_r(skb, sk);
-
-	/* Cache the SKB length before we tack it onto the receive
-	 * queue.  Once it is added it no longer belongs to us and
-	 * may be freed by other threads of control pulling packets
-	 * from the queue.
-	 */
-	skb_len = skb->len;
-
-	skb_queue_tail(&sk->sk_receive_queue, skb);
-
-	if (!sock_flag(sk, SOCK_DEAD))
-		sk->sk_data_ready(sk, skb_len);
-out:
-	return err;
-}
+int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb);
 
 static inline int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
 {
diff -urN linux-2.6.5.orig/net/core/sock.c linux-2.6.5.net_inline2/net/core/sock.c
--- linux-2.6.5.orig/net/core/sock.c	Sun Apr  4 06:37:37 2004
+++ linux-2.6.5.net_inline2/net/core/sock.c	Mon Apr 12 16:05:39 2004
@@ -1138,6 +1138,46 @@
 	atomic_set(&sk->sk_refcnt, 1);
 }
 
+int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+{
+	int err = 0;
+	int skb_len;
+
+	/* Cast skb->rcvbuf to unsigned... It's pointless, but reduces
+	   number of warnings when compiling with -W --ANK
+	 */
+	if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
+	    (unsigned)sk->sk_rcvbuf) {
+		err = -ENOMEM;
+		goto out;
+	}
+
+	/* It would be deadlock, if sock_queue_rcv_skb is used
+	   with socket lock! We assume that users of this
+	   function are lock free.
+	*/
+	err = sk_filter(sk, skb, 1);
+	if (err)
+		goto out;
+
+	skb->dev = NULL;
+	skb_set_owner_r(skb, sk);
+
+	/* Cache the SKB length before we tack it onto the receive
+	 * queue.  Once it is added it no longer belongs to us and
+	 * may be freed by other threads of control pulling packets
+	 * from the queue.
+	 */
+	skb_len = skb->len;
+
+	skb_queue_tail(&sk->sk_receive_queue, skb);
+
+	if (!sock_flag(sk, SOCK_DEAD))
+		sk->sk_data_ready(sk, skb_len);
+out:
+	return err;
+}
+
 void lock_sock(struct sock *sk)
 {
 	might_sleep();

(no subject)

[Kishore A K]

(no subject)

[3акyпки]

[-- Attachment #1: Type: text/html, Size: 11762 bytes --]

(no subject)

[efc5036]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

mnb
Received: from venus
	by mail.ht.net.tw with SMTP id D9D2xIUsas51slhztuXO2;
	Sat, 19 Jun 2004 00:43:27 +0800
Message-ID: <KFOMksW@mail.sysnet.net.tw>
From: gokou@ms31.hinet.net
To: hm7766@ms21.hinet.net
Subject: ³Ò«O¥d¶U¡B«H¥Î¥d¶U¡B²{ª÷¥d¶U¡B¦æ·Ó¶U¡A²Î²Î¶Uµ¹±z¡I¤£¦¬¶O V8CjPROuaqmNFrur
MIME-Version: 1.0
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_qsXXy5nYY5rXFtjT"
X-Priority: 3
X-MSMail-Priority: Normal

This is a multi-part message in MIME format.

------=_NextPart_qsXXy5nYY5rXFtjT
Content-Type: multipart/alternative;
	boundary="----=_NextPart_qsXXy5nYY5rXFtjTAA"


------=_NextPart_qsXXy5nYY5rXFtjTAA
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: base64

PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1MYW5ndWFnZSIgY29u
dGVudD0iemgtdHciPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0
ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRlbnQ9
Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVudD0i
RnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+wLCxer/stlW02qSjpqy2TzwvdGl0
bGU+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQo8cD48aW1nIGhlaWdodD0iMzk0IiBzcmM9Imh0dHA6
Ly9ob21lLnBjaG9tZS5jb20udHcvc2VydmljZS9hcmNoMTcyL21hZ2kxNi5qcGciIHdpZHRoPSI2
MzciPjwvcD4NCjxwPsCwsXq/7LZVtNqko6astk+hSzwvcD4NCjxwPjxiPjxmb250IHNpemU9IjQi
PrF6wdmmYsO6sKrDQqq6snuq96VktGDA9KdRrqe23D88L2ZvbnQ+PC9iPjwvcD4NCjxwPjxiPjxm
b250IHNpemU9IjQiPrdRvuOmWLbcP7dRrNmkVaRApWKquqdRrqe23D88L2ZvbnQ+PC9iPjwvcD4N
CjxwPjxiPjxmb250IHNpemU9IjUiPqFpsOqlwatItlWhajwvZm9udD48L2I+PC9wPg0KPHA+PGI+
PGZvbnQgc2l6ZT0iNCI+snvCvqR1p0C6oaRUrdOk677Ms9KrT6Vkp1mlab/ssnohPC9mb250Pjwv
Yj48L3A+DQo8cD48Yj48Zm9udCBzaXplPSI0Ij6n67PSq0+p86R1t3yqzLqhpLut06TroUGxcajG
q0Sn66tPpHW3fKSnrNvD9qR1p0Cl56VpITwvZm9udD48L2I+PC9wPg0KPHA+PGI+PGZvbnQgc2l6
ZT0iNSI+okk8L2ZvbnQ+PGZvbnQgc2l6ZT0iNCI+pnCn66tPqfPBX6z3pHW3fKFBpdirZaq6pHWn
QKxPpmKm26dVwFywZatLt+0hpeelab/ssnohPC9mb250Pjxmb250IHNpemU9IjUiPqJJPC9mb250
PjwvYj48L3A+DQo8cD48Yj48Zm9udCBzaXplPSI1Ij6haaVkpm6tybFNrtehajwvZm9udD48L2I+
PC9wPg0KPHA+PGI+PGZvbnQgc2l6ZT0iNCI+pKOtrcK+t36hQaSjrN2mrKRKvsyrSKXOpWQouqGk
QKZ+KanOsnuq96VkKLqhpWKmfikhPC9mb250PjwvYj48L3A+DQo8cD48Yj48Zm9udCBzaXplPSI0
Ij6nWajJprMxNbhVqrrDQqvXITwvZm9udD48L2I+PC9wPg0KPHA+pbukSKVptKOo0bZVtNqs28P2
sN3DRKq6p0u2T7/UuN+qQbDIITwvcD4NCjxwPqZVv6Slq6zSxXeq76jTuXGvwaj6pXi3c7vIpuar
SKXOtlW02qXTvdCu0SE8L3A+DQo8cD6yerBdsU2t+yA8Zm9udCBzaXplPSI0Ij7ErLfnp7s8L2Zv
bnQ+uty426ywsXqqQbDIISEgPGZvbnQgc2l6ZT0iNCI+uXG43DwvZm9udD6hRzxiPjxmb250IHNp
emU9IjQiPjA5MTktNjg2NDUzPC9mb250PjwvYj48L3A+DQo8cD6hQDwvcD4NCg0KPC9ib2R5Pg0K
DQo8L2h0bWw+


------=_NextPart_qsXXy5nYY5rXFtjTAA--
------=_NextPart_qsXXy5nYY5rXFtjT--

(no subject)

[Luis R. Rodriguez]

prism54-devel@prism54.org
Bcc: 
Subject: Re: [PATCH 1/6 Linux-2.6.7-bk13] prism54 cleanup functions
Reply-To: 
In-Reply-To: <40E382BF.7060904@pobox.com>
X-Operating-System: 2.4.18-1-686
Organization: Rutgers University Student Linux Users Group

On Wed, Jun 30, 2004 at 11:19:27PM -0400, Jeff Garzik wrote:
> applied patches 1-6
> 

Margit, please commit to prism54 CVS :)

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

(no subject)

[klsxl]

(no subject)

[autoreply]

Dear netdev@oss.sgi.com,

Thank you for sending email to m@mail.tc. 

Sadly Martin gets too much unsolicited at this email address, so
please could you send your mail instead to mjo@adamsnames.tc ?

Yours faithfully,
--
Martin Oldfield
AdamsNames Ltd.

(no subject)

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 751 bytes --]

prism54-devel@prism54.org
Bcc: 
Subject: 
Reply-To: 

prism54-devel@prism54.org
Bcc: 
Subject: Re: [PATCH] prism54: fix printk format warnings
Reply-To: 
In-Reply-To: <20050301212137.57f9532f.rddunlap@osdl.org>
X-Operating-System: 2.4.18-1-686
Organization: Rutgers University Student Linux Users Group

On Tue, Mar 01, 2005 at 09:21:37PM -0800, Randy.Dunlap wrote:
> 
> prism54 build shows some printk format complaints:
> (sparc64 build warning)

Patch applied to prism54 tree, thanks. Jeff, feel free to apply to you tree, I won't be
sending you an update for a while.. WPA advancements have been slow and
still need a lot of testing.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

(no subject)

[l-linux-admin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

Ha enviado un mensaje a '%(list_name)s' con el título:
Date: Tue, 08 Mar 2005 02:51:03 -0400
Message-ID: <20050308065103.8453.42968.Mailman@libertad.velug.org.ve>
Subject: Your message to l-linux awaits moderator approval
From: l-linux-admin@velug.org.ve
To: netdev@oss.sgi.com
X-Ack: no
Sender: l-linux-admin@velug.org.ve
Errors-To: l-linux-admin@velug.org.ve
X-BeenThere: l-linux@velug.org.ve
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:l-linux-request@velug.org.ve?subject=help>
List-Post: <mailto:l-linux@velug.org.ve>
List-Subscribe: <http://www.velug.org.ve/cgi-bin/mailman/listinfo/l-linux>,
	<mailto:l-linux-request@velug.org.ve?subject=subscribe>
List-Id: Consultas Técnicas sobre Linux y Software Libre <l-linux.velug.org.ve>
List-Unsubscribe: <http://www.velug.org.ve/cgi-bin/mailman/listinfo/l-linux>,
	<mailto:l-linux-request@velug.org.ve?subject=unsubscribe>
List-Archive: <http://www.velug.org.ve/pipermail/l-linux/>

    Re: Re: Re: Your document

El mensaje ha sido retenido hasta que el moderador pueda procesarlo.
Ha sido retenido porque:

    Post by non-member to a members-only list

Si el moderador lo aprueba, el mensaje irá directamente a la lista. Si
el moderador lo rechaza, Ud. recibirá una notificación indicando las
razones del rechazo.

(no subject)

[林先生]

尊敬的贵公司经理或财务,你好!!
   本公司成立于1994年,目前在全国已有十多家分公司,经营范围广泛.
本公司按国家规定上税,属于按月定额缴税的形式.现有多余的增值发票,普通发票,
运输发票,广告发票,服务业发票,建筑安装等发票,可以为贵公司代开,点数优惠.查验后付款,欢迎有意者来电洽谈!
愿我们合作成功!!!

祝:商祺!!

公司名称:深圳合展实业发展有限公司(深圳总公司)
联系人:林先生(总经理)
公司电话:0755-22033124
移动电话:13510444201

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 69107FA5F

	for <buffer@sniffo.org>; Tue, 24 May 2005 05:18:55 +0200 (CEST)

Received: from oss (localhost [127.0.0.1])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2eUF3007815;

	Mon, 23 May 2005 19:40:30 -0700

Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 19:39:10 -0700 (PDT)

Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O2d3F3007472

	for <netdev@oss.sgi.com>; Mon, 23 May 2005 19:39:07 -0700

Received: from localhost ([127.0.0.1] ident=davem)

	by sunset.davemloft.net with esmtp (Exim 4.50)

	id 1DaPJB-0000Zl-8x; Mon, 23 May 2005 19:38:17 -0700

Date: Mon, 23 May 2005 19:38:17 -0700 (PDT)

Message-Id: <20050523.193817.112290763.davem@davemloft.net>

To: herbert@gondor.apana.org.au
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] Super TSO v3

From: "David S. Miller" <davem@davemloft.net>
In-Reply-To: <20050524023256.GA29242@gondor.apana.org.au>

References: <20050524003208.GA25778@gondor.apana.org.au>

	<20050523.192917.48530622.davem@davemloft.net>

	<20050524023256.GA29242@gondor.apana.org.au>

X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)

Mime-Version: 1.0

Content-Type: Text/Plain; charset=us-ascii

Content-Transfer-Encoding: 7bit

X-archive-position: 1540

X-ecartis-version: Ecartis v1.0.0

Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: davem@davemloft.net

Precedence: bulk

X-list: netdev

X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com

X-Virus-Status: Clean



From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 24 May 2005 12:32:57 +1000

> True, the Nagle algorithm itself aims to do something different
> from this function.  However, the act of turning Nagle off is
> an indication that the application wants to minimise the latency
> by sending things out ASAP.  So we should either respect that
> here by not delaying the packets to increase the TSO size, or
> we'll need a new socket option to do that for TSO.

Sure, we can check tp->nonagle to turn this deferring off.

But, I bet there are folks who want traditional Nagle turned
off, yet TSO chunking enabled.

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id E2FB1F9E7

	for <buffer@sniffo.org>; Tue, 24 May 2005 04:13:52 +0200 (CEST)

Received: from oss (localhost [127.0.0.1])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1kGF3003197;

	Mon, 23 May 2005 18:46:16 -0700

Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:43:59 -0700 (PDT)

Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1htF3002796

	for <netdev@oss.sgi.com>; Mon, 23 May 2005 18:43:55 -0700

Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88])

	by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux))

	id 1DaORj-00017L-8S; Tue, 24 May 2005 01:43:04 +0000

Message-ID: <429286A3.1060606@pobox.com>

Date: Mon, 23 May 2005 21:42:59 -0400

From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5

X-Accept-Language: en-us, en

MIME-Version: 1.0

To: Michael Chan <mchan@broadcom.com>
Cc: davem@davemloft.net, netdev@oss.sgi.com
Subject: Re: [PATCH 1/6] bnx2: Fix excessive stack usage

References: <1116892439.4908.1.camel@rh4> <1116894307.4908.28.camel@rh4>

In-Reply-To: <1116894307.4908.28.camel@rh4>

Content-Type: text/plain; charset=us-ascii; format=flowed

Content-Transfer-Encoding: 7bit

X-archive-position: 1536

X-ecartis-version: Ecartis v1.0.0

Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com

Precedence: bulk

X-list: netdev

X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com

X-Virus-Status: Clean



Michael Chan wrote:
> diff -Nru 10/drivers/net/bnx2.c 11/drivers/net/bnx2.c
> --- 10/drivers/net/bnx2.c	2005-05-23 10:20:02.000000000 -0700
> +++ 11/drivers/net/bnx2.c	2005-05-23 10:20:20.000000000 -0700
> @@ -1138,13 +1138,20 @@
>  	}
>  }
>  
> -static void
> +static int
>  bnx2_alloc_bad_rbuf(struct bnx2 *bp)
>  {
> -	u16 good_mbuf[512];
> +	u16 *good_mbuf;
>  	u32 good_mbuf_cnt;
>  	u32 val;
>  
> +	good_mbuf = kmalloc(512 * sizeof(u16), GFP_KERNEL);
> +	if (good_mbuf == NULL) {
> +		printk(KERN_ERR PFX "Failed to allocate memory in "
> +				    "bnx2_alloc_bad_rbuf\n");
> +		return -ENOMEM;
> +	}
> +
>  	REG_WR(bp, BNX2_MISC_ENABLE_SET_BITS,
>  		BNX2_MISC_ENABLE_SET_BITS_RX_MBUF_ENABLE);
>  
> @@ -1178,6 +1185,7 @@
>  
>  		REG_WR_IND(bp, BNX2_RBUF_FW_BUF_FREE, val);
>  	}
> +	return 0;
>  }
>  
>  static void

memleak -- you need to free good_mbuf.

	Jeff

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 1C84EFB6B

	for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:41 +0200 (CEST)

Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand

	id S261200AbVEXG0J (ORCPT <rfc822;chiakotay@nexlab.it>);

	Tue, 24 May 2005 02:26:09 -0400

Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261302AbVEXG0J

	(ORCPT <rfc822;linux-kernel-outgoing>);

	Tue, 24 May 2005 02:26:09 -0400

Received: from mail.dvmed.net ([216.237.124.58]:4813 "EHLO mail.dvmed.net")

	by vger.kernel.org with ESMTP id S261200AbVEXGZ5 (ORCPT

	<rfc822;linux-kernel@vger.kernel.org>);

	Tue, 24 May 2005 02:25:57 -0400

Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88])

	by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux))

	id 1DaSrU-0001Og-4d; Tue, 24 May 2005 06:25:56 +0000

Message-ID: <4292C8EF.3090307@pobox.com>

Date:	Tue, 24 May 2005 02:25:51 -0400

From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5

X-Accept-Language: en-us, en

MIME-Version: 1.0

To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates

References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

In-Reply-To: <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

Content-Type: text/plain; charset=us-ascii; format=flowed

Content-Transfer-Encoding: 7bit

X-Spam-Score: 0.0 (/)

Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

X-Mailing-List:	linux-kernel@vger.kernel.org



Linus Torvalds wrote:
> 
> On Tue, 24 May 2005, Jeff Garzik wrote:
> 
> 
>>Please pull the 'for-linus' branch from
>>
>>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> 
> 
> Is this really what you meant to do? There's seven merges there, none of
> which have _any_ information about _what_ you merged, because you've mixed
> everything up in one tree, so that there's absolutely no record of the
> fact that you actually had seven different repositories that you pulled..
> 
> That sucks, Jeff.
> 
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the
> way you work now, it all looks like mush.
> 
> Even if you don't get confused youself, you sure are confusing everybody 
> else with it..

You are getting precisely the same thing you got under BitKeeper:  pull 
from X, you get my tree, which was composed from $N repositories.  The 
tree you pull was created by my running 'bk pull' locally $N times.

Ultimately, you appear to be complaining about:

* your own git-pull-script, which doesn't record the $2 (branch) 
argument in the commit message.

* the fact that my changelog includes the merge csets that were 
present-but-invisible by my BitKeeper submissions.  i.e. I lack a 
shortlog that filters out merge csets.



> Anyway, if you really want to work this way, with one big mushed-together
> thing that has different heads that you keep track of, can you _please_ at
> least make the commit message tell what you're doing. It's not a complex 

Hey, I didn't write git-pull-script, I just use it :)


> script, and you're definitely mis-using it as things stand now by 
> switching heads around inside one repository, and not telling other people 
> about it.

Switching heads around?  It sounds like you did not pull from the branch 
I mentioned.  This is how git-pull-script pulls from a branch:

git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\
  refs/heads/for-linus

	Jeff

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 2366BFB72

	for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:46 +0200 (CEST)

Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand

	id S261334AbVEXGsu (ORCPT <rfc822;chiakotay@nexlab.it>);

	Tue, 24 May 2005 02:48:50 -0400

Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261362AbVEXGst

	(ORCPT <rfc822;linux-kernel-outgoing>);

	Tue, 24 May 2005 02:48:49 -0400

Received: from fire.osdl.org ([65.172.181.4]:20097 "EHLO smtp.osdl.org")

	by vger.kernel.org with ESMTP id S261334AbVEXGsj (ORCPT

	<rfc822;linux-kernel@vger.kernel.org>);

	Tue, 24 May 2005 02:48:39 -0400

Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6])

	by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4O6mWjA025872

	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);

	Mon, 23 May 2005 23:48:32 -0700

Received: from localhost (shell0.pdx.osdl.net [10.9.0.31])

	by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j4O6mVWw012672;

	Mon, 23 May 2005 23:48:31 -0700

Date:	Mon, 23 May 2005 23:50:36 -0700 (PDT)

From: Linus Torvalds <torvalds@osdl.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates

In-Reply-To: <4292CB01.6090506@pobox.com>

Message-ID: <Pine.LNX.4.58.0505232349020.2307@ppc970.osdl.org>

References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

 <4292CB01.6090506@pobox.com>

MIME-Version: 1.0

Content-Type: TEXT/PLAIN; charset=US-ASCII

X-Spam-Status: No, hits=0 required=5 tests=

X-Spam-Checker-Version:	SpamAssassin 2.63-osdl_revision__1.40__

X-MIMEDefang-Filter: osdl$Revision: 1.109 $

X-Scanned-By: MIMEDefang 2.36

Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

X-Mailing-List:	linux-kernel@vger.kernel.org





On Tue, 24 May 2005, Jeff Garzik wrote:
> 
> You really can't beat
> 
> 	cp .git/refs/heads/master .git/refs/heads/new-branch
> 
> as the fastest way to create a new branch off the tip.

So? It's the fastest, but it's also BROKEN. Exactly because the way you do 
things, the merge messages are meaningless.

So fix your merge messages. 

		Linus

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 8C315FB6B

	for <chiakotay@nexlab.it>; Tue, 24 May 2005 10:01:41 +0200 (CEST)

Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand

	id S261350AbVEXGeu (ORCPT <rfc822;chiakotay@nexlab.it>);

	Tue, 24 May 2005 02:34:50 -0400

Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261334AbVEXGeu

	(ORCPT <rfc822;linux-kernel-outgoing>);

	Tue, 24 May 2005 02:34:50 -0400

Received: from mail.dvmed.net ([216.237.124.58]:8141 "EHLO mail.dvmed.net")

	by vger.kernel.org with ESMTP id S261353AbVEXGep (ORCPT

	<rfc822;linux-kernel@vger.kernel.org>);

	Tue, 24 May 2005 02:34:45 -0400

Received: from cpe-065-184-065-144.nc.res.rr.com ([65.184.65.144] helo=[10.10.10.88])

	by mail.dvmed.net with esmtpsa (Exim 4.51 #1 (Red Hat Linux))

	id 1DaT00-0001Ow-FO; Tue, 24 May 2005 06:34:44 +0000

Message-ID: <4292CB01.6090506@pobox.com>

Date:	Tue, 24 May 2005 02:34:41 -0400

From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5

X-Accept-Language: en-us, en

MIME-Version: 1.0

To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, Netdev <netdev@oss.sgi.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] 2.6.x net driver updates

References: <4292BA66.8070806@pobox.com> <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

In-Reply-To: <Pine.LNX.4.58.0505232253160.2307@ppc970.osdl.org>

Content-Type: text/plain; charset=us-ascii; format=flowed

Content-Transfer-Encoding: 7bit

X-Spam-Score: 0.0 (/)

Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

X-Mailing-List:	linux-kernel@vger.kernel.org



Linus Torvalds wrote:
> I don't understand why you don't use different trees, like you did with
> BK. You can share the object directory with the different trees, but the

You really can't beat

	cp .git/refs/heads/master .git/refs/heads/new-branch

as the fastest way to create a new branch off the tip.

	Jeff

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id 346A4FA13

	for <buffer@sniffo.org>; Tue, 24 May 2005 03:28:34 +0200 (CEST)

Received: from oss (localhost [127.0.0.1])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1ScF3000570;

	Mon, 23 May 2005 18:28:39 -0700

Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:27:46 -0700 (PDT)

Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1RhF3032603

	for <netdev@oss.sgi.com>; Mon, 23 May 2005 18:27:43 -0700

Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom

 SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:26:49 -0700

X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA

Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by

 mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID#

 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:26:48

 -0700

Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com

 [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP

 id AZY38167; Mon, 23 May 2005 18:26:47 -0700 (PDT)

Received: from nt-irva-0741.brcm.ad.broadcom.com (

 nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by

 mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16842; Mon, 23

 May 2005 18:26:47 -0700 (PDT)

Received: from 10.7.17.55 ([10.7.17.55]) by

 NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft

 Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:26:47 +0000

Received: from rh4 by nt-irva-0741; 23 May 2005 17:29:03 -0700

Subject: [PATCH 4/6] bnx2: Fix bug in bnx2_close

From: "Michael Chan" <mchan@broadcom.com>
To: davem@davemloft.net
Cc: jgarzik@pobox.com, netdev@oss.sgi.com
In-Reply-To: <1116892439.4908.1.camel@rh4>

References: <1116892439.4908.1.camel@rh4>

Date: Mon, 23 May 2005 17:29:03 -0700

Message-ID: <1116894543.4908.32.camel@rh4>

MIME-Version: 1.0

X-Mailer: Evolution 2.0.2 (2.0.2-3)

X-WSS-ID: 6E8C5D531VO1443816-01-01

Content-Type: multipart/mixed;

 boundary="=-kVtupVzl5sY8iZGVxtrc"

X-archive-position: 1533

X-ecartis-version: Ecartis v1.0.0

Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: mchan@broadcom.com

Precedence: bulk

X-list: netdev

X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com

X-Virus-Status: Clean




--=-kVtupVzl5sY8iZGVxtrc
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Fix bug in bnx2_close() by calling flush_scheduled_work() since we are
using a work queue in netdev watchdog. Also added bnx2_netif_stop() call
in bnx2_close().

Spotted by Jeff Garzik.

Signed-off-by: Michael Chan <mchan@broadcom.com>


--=-kVtupVzl5sY8iZGVxtrc
Content-Disposition: attachment;
 filename=bnx2-14.patch
Content-Type: text/x-patch;
 charset=utf-8;
 name=bnx2-14.patch
Content-Transfer-Encoding: base64

ZGlmZiAtTnJ1IDEzL2RyaXZlcnMvbmV0L2JueDIuYyAxNC9kcml2ZXJzL25ldC9ibngyLmMNCi0t
LSAxMy9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDo1Nzo0MS4wMDAwMDAwMDAgLTA3
MDANCisrKyAxNC9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMzowMTo0NS4wMDAwMDAw
MDAgLTA3MDANCkBAIC00MTcyLDcgKzQxNzIsOCBAQA0KIAlzdHJ1Y3QgYm54MiAqYnAgPSBkZXYt
PnByaXY7DQogCXUzMiByZXNldF9jb2RlOw0KIA0KLQlibngyX2Rpc2FibGVfaW50X3N5bmMoYnAp
Ow0KKwlmbHVzaF9zY2hlZHVsZWRfd29yaygpOw0KKwlibngyX25ldGlmX3N0b3AoYnApOw0KIAlk
ZWxfdGltZXJfc3luYygmYnAtPnRpbWVyKTsNCiAJaWYgKGJwLT53b2wpDQogCQlyZXNldF9jb2Rl
ID0gQk5YMl9EUlZfTVNHX0NPREVfU1VTUEVORF9XT0w7DQo=


--=-kVtupVzl5sY8iZGVxtrc--

(no subject)

[root]

	by smtp.nexlab.net (Postfix) with ESMTP id CE413FA1F

	for <buffer@sniffo.org>; Tue, 24 May 2005 03:30:17 +0200 (CEST)

Received: from oss (localhost [127.0.0.1])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1QmF3031979;

	Mon, 23 May 2005 18:26:48 -0700

Received: with ECARTIS (v1.0.0; list netdev); Mon, 23 May 2005 18:25:08 -0700 (PDT)

Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18])

	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4O1P4F3031331

	for <netdev@oss.sgi.com>; Mon, 23 May 2005 18:25:04 -0700

Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom

 SMTP Relay (Email Firewall v6.1.0)); Mon, 23 May 2005 18:24:08 -0700

X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA

Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by

 mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID#

 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 23 May 2005 18:24:07

 -0700

Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com

 [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP

 id AZY37732; Mon, 23 May 2005 18:24:07 -0700 (PDT)

Received: from nt-irva-0741.brcm.ad.broadcom.com (

 nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by

 mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA16376; Mon, 23

 May 2005 18:24:06 -0700 (PDT)

Received: from 10.7.17.55 ([10.7.17.55]) by

 NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft

 Exchange Server HTTP-DAV ; Tue, 24 May 2005 01:24:06 +0000

Received: from rh4 by nt-irva-0741; 23 May 2005 17:26:23 -0700

Subject: [PATCH 2/6] bnx2: Fix rx checksum

From: "Michael Chan" <mchan@broadcom.com>
To: davem@davemloft.net
Cc: jgarzik@pobox.com, netdev@oss.sgi.com
In-Reply-To: <1116892439.4908.1.camel@rh4>

References: <1116892439.4908.1.camel@rh4>

Date: Mon, 23 May 2005 17:26:23 -0700

Message-ID: <1116894383.4908.29.camel@rh4>

MIME-Version: 1.0

X-Mailer: Evolution 2.0.2 (2.0.2-3)

X-WSS-ID: 6E8C5DB21VO1443376-01-01

Content-Type: multipart/mixed;

 boundary="=-MjP9kNbfLluHpwDwIMre"

X-archive-position: 1531

X-ecartis-version: Ecartis v1.0.0

Sender: netdev-bounce@oss.sgi.com
Errors-To: netdev-bounce@oss.sgi.com
X-original-sender: mchan@broadcom.com

Precedence: bulk

X-list: netdev

X-Virus-Scanned: ClamAV 0.83/892/Mon May 23 10:52:19 2005 on oss.sgi.com

X-Virus-Status: Clean




--=-MjP9kNbfLluHpwDwIMre
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Fix bug in rx checksum by indicating CHECKSUM_UNNECESSARY only when the
hw calculated checksum is 0xffff.

Spotted by Jeff Garzik.

Signed-off-by: Michael Chan <mchan@broadcom.com>


--=-MjP9kNbfLluHpwDwIMre
Content-Disposition: attachment;
 filename=bnx2-12.patch
Content-Type: text/x-patch;
 charset=utf-8;
 name=bnx2-12.patch
Content-Transfer-Encoding: base64

ZGlmZiAtTnJ1IDExL2RyaXZlcnMvbmV0L2JueDIuYyAxMi9kcml2ZXJzL25ldC9ibngyLmMNCi0t
LSAxMS9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyMDoyMC4wMDAwMDAwMDAgLTA3
MDANCisrKyAxMi9kcml2ZXJzL25ldC9ibngyLmMJMjAwNS0wNS0yMyAxMDoyOTowMi4wMDAwMDAw
MDAgLTA3MDANCkBAIC0xNDcwLDkgKzE0NzAsOCBAQA0KIA0KIAkJCXUxNiBja3N1bSA9IHJ4X2hk
ci0+bDJfZmhkcl90Y3BfdWRwX3hzdW07DQogDQotCQkJaWYgKChja3N1bSA9PSAweGZmZmYpIHx8
IChja3N1bSA9PSAwKSkgew0KKwkJCWlmIChja3N1bSA9PSAweGZmZmYpDQogCQkJCXNrYi0+aXBf
c3VtbWVkID0gQ0hFQ0tTVU1fVU5ORUNFU1NBUlk7DQotCQkJfQ0KIAkJfQ0KIA0KICNpZmRlZiBC
Q01fVkxBTg0K


--=-MjP9kNbfLluHpwDwIMre--

(no subject)

[seohai]

(no subject)

[d1187e7720r]

(no subject)

[y5834i4926v]

(no subject)

[d1187e7720r]

(no subject)

[q0960m0638o]

(no subject)

[d1187e7720r]

(no subject)

[d1187e7720r]

(no subject)

[Yasuyuki KOZAKAI]

[-- Attachment #1: Type: Text/Plain, Size: 1862 bytes --]

Subject: Re: nf_conntrack comments
From: Yasuyuki KOZAKAI <kozakai@isl.rdc.toshiba.co.jp>
Fcc: +backup
In-Reply-To: <20051029135524.GQ4479@sunbeam.de.gnumonks.org>
References: <20051018084924.GD20338@sunbeam.de.gnumonks.org>
	<39e6f6c70510282108i60d78df6w9728f40641dccf80@mail.gmail.com>
	<20051029135524.GQ4479@sunbeam.de.gnumonks.org>
X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
----

Hi, Acme and all,

Acme, thank you for reviewing of nf_conntrack.

From: Harald Welte <laforge@netfilter.org>
Date: Sat, 29 Oct 2005 15:55:24 +0200

> > +       if (!h) {
> > +               DEBUGP("icmpv6_error: no match\n");
> > +               return NF_ACCEPT;
> > +       } else {
> > +               if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
> > +                       *ctinfo += IP_CT_IS_REPLY;
> > +       }
> > +
> > +       /* Update skb to refer to this connection */
> > +       skb->nfct = &nf_ct_tuplehash_to_ctrack(h)->ct_general;
> > +       skb->nfctinfo = *ctinfo;
> > +       return -NF_ACCEPT;
> > +}
> > 
> > I noticed that some of the returns are NF_ACCEPT while at leat this last one
> > returns -NF_ACCEPT, is this a special convention or should all be negative? or
> > positive?
>
> I'll check that, looks like a bug to me, too.

If we don't change, the result is same. If this function return NF_ACCEPT,
connection tracking handles packet as normal packet. But it cannot find invert
tuple for it and stop processing after all. Then no problem.

But it may be better to replace NF_ACCEPT with -NF_ACCEPT in this function to
stop processing early.

BTW, this is common issue in nf_conntrack and ip_conntrack. Then it is
necessary to both of them if we want.

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

Netfilter folks, do you have any problem if I change these return value ?

Regards,

--- Yasuyuki Kozakai

[-- Attachment #2: ct-icmp-error.patch --]
[-- Type: Text/Plain, Size: 6212 bytes --]

[NETFILTER] stop tracking ICMP(v6) error at early point

Currently connection tracking handles ICMP(v6) error like normal packets
if it failed to get related connection. But it fails that after all.

This makes connection tracking stop tracking ICMP(v6) error at early point.

Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>

---
commit 45d0380701e4980f1276d3d7d83285e1c4a2e4c9
tree e2ae86189f6c961b1a8db032a2b11b814219e5f5
parent 296d553d2cf7856d37e613ab20b4290dbfe38afa
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Mon, 31 Oct 2005 20:00:31 +0900
committer Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Mon, 31 Oct 2005 20:00:31 +0900

 net/ipv4/netfilter/ip_conntrack_proto_icmp.c   |   10 +++++-----
 net/ipv4/netfilter/nf_conntrack_proto_icmp.c   |   10 +++++-----
 net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c |   12 ++++++------
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c
--- a/net/ipv4/netfilter/ip_conntrack_proto_icmp.c
+++ b/net/ipv4/netfilter/ip_conntrack_proto_icmp.c
@@ -151,13 +151,13 @@ icmp_error_message(struct sk_buff *skb,
 	/* Not enough header? */
 	inside = skb_header_pointer(skb, skb->nh.iph->ihl*4, sizeof(_in), &_in);
 	if (inside == NULL)
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 
 	/* Ignore ICMP's containing fragments (shouldn't happen) */
 	if (inside->ip.frag_off & htons(IP_OFFSET)) {
 		DEBUGP("icmp_error_track: fragment of proto %u\n",
 		       inside->ip.protocol);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	innerproto = ip_conntrack_proto_find_get(inside->ip.protocol);
@@ -166,7 +166,7 @@ icmp_error_message(struct sk_buff *skb,
 	if (!ip_ct_get_tuple(&inside->ip, skb, dataoff, &origtuple, innerproto)) {
 		DEBUGP("icmp_error: ! get_tuple p=%u", inside->ip.protocol);
 		ip_conntrack_proto_put(innerproto);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	/* Ordinarily, we'd expect the inverted tupleproto, but it's
@@ -174,7 +174,7 @@ icmp_error_message(struct sk_buff *skb,
 	if (!ip_ct_invert_tuple(&innertuple, &origtuple, innerproto)) {
 		DEBUGP("icmp_error_track: Can't invert tuple\n");
 		ip_conntrack_proto_put(innerproto);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 	ip_conntrack_proto_put(innerproto);
 
@@ -190,7 +190,7 @@ icmp_error_message(struct sk_buff *skb,
 
 		if (!h) {
 			DEBUGP("icmp_error_track: no match\n");
-			return NF_ACCEPT;
+			return -NF_ACCEPT;
 		}
 		/* Reverse direction from that found */
 		if (DIRECTION(h) != IP_CT_DIR_REPLY)
diff --git a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
--- a/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
+++ b/net/ipv4/netfilter/nf_conntrack_proto_icmp.c
@@ -159,13 +159,13 @@ icmp_error_message(struct sk_buff *skb,
 	/* Not enough header? */
 	inside = skb_header_pointer(skb, skb->nh.iph->ihl*4, sizeof(_in), &_in);
 	if (inside == NULL)
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 
 	/* Ignore ICMP's containing fragments (shouldn't happen) */
 	if (inside->ip.frag_off & htons(IP_OFFSET)) {
 		DEBUGP("icmp_error_message: fragment of proto %u\n",
 		       inside->ip.protocol);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	innerproto = nf_ct_find_proto(PF_INET, inside->ip.protocol);
@@ -176,7 +176,7 @@ icmp_error_message(struct sk_buff *skb,
 			     &nf_conntrack_l3proto_ipv4, innerproto)) {
 		DEBUGP("icmp_error_message: ! get_tuple p=%u",
 		       inside->ip.protocol);
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
         /* Ordinarily, we'd expect the inverted tupleproto, but it's
@@ -184,7 +184,7 @@ icmp_error_message(struct sk_buff *skb,
         if (!nf_ct_invert_tuple(&innertuple, &origtuple,
 				&nf_conntrack_l3proto_ipv4, innerproto)) {
 		DEBUGP("icmp_error_message: no match\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	*ctinfo = IP_CT_RELATED;
@@ -199,7 +199,7 @@ icmp_error_message(struct sk_buff *skb,
 
 		if (!h) {
 			DEBUGP("icmp_error_message: no match\n");
-			return NF_ACCEPT;
+			return -NF_ACCEPT;
 		}
 
 		/* Reverse direction from that found */
diff --git a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
--- a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
+++ b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
@@ -164,14 +164,14 @@ icmpv6_error_message(struct sk_buff *skb
 	hp = skb_header_pointer(skb, icmp6off, sizeof(_hdr), &_hdr);
 	if (hp == NULL) {
 		DEBUGP("icmpv6_error: Can't get ICMPv6 hdr.\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	inip6off = icmp6off + sizeof(_hdr);
 	if (skb_copy_bits(skb, inip6off+offsetof(struct ipv6hdr, nexthdr),
 			  &inprotonum, sizeof(inprotonum)) != 0) {
 		DEBUGP("icmpv6_error: Can't get nexthdr in inner IPv6 header.\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 	inprotoff = nf_ct_ipv6_skip_exthdr(skb,
 					   inip6off + sizeof(struct ipv6hdr),
@@ -182,7 +182,7 @@ icmpv6_error_message(struct sk_buff *skb
 	if ((inprotoff < 0) || (inprotoff > skb->len) ||
 	    (inprotonum == NEXTHDR_FRAGMENT)) {
 		DEBUGP("icmpv6_error: Can't get protocol header in ICMPv6 payload.\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	inproto = nf_ct_find_proto(PF_INET6, inprotonum);
@@ -191,7 +191,7 @@ icmpv6_error_message(struct sk_buff *skb
 	if (!nf_ct_get_tuple(skb, inip6off, inprotoff, PF_INET6, inprotonum,
 			     &origtuple, &nf_conntrack_l3proto_ipv6, inproto)) {
 		DEBUGP("icmpv6_error: Can't get tuple\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	/* Ordinarily, we'd expect the inverted tupleproto, but it's
@@ -199,7 +199,7 @@ icmpv6_error_message(struct sk_buff *skb
 	if (!nf_ct_invert_tuple(&intuple, &origtuple,
 				&nf_conntrack_l3proto_ipv6, inproto)) {
 		DEBUGP("icmpv6_error: Can't invert tuple\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	}
 
 	*ctinfo = IP_CT_RELATED;
@@ -207,7 +207,7 @@ icmpv6_error_message(struct sk_buff *skb
 	h = nf_conntrack_find_get(&intuple, NULL);
 	if (!h) {
 		DEBUGP("icmpv6_error: no match\n");
-		return NF_ACCEPT;
+		return -NF_ACCEPT;
 	} else {
 		if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
 			*ctinfo += IP_CT_IS_REPLY;

Re: (no subject)

[Patrick McHardy]

Yasuyuki KOZAKAI wrote:
> Subject: Re: nf_conntrack comments
> From: Yasuyuki KOZAKAI <kozakai@isl.rdc.toshiba.co.jp>
> Fcc: +backup
> In-Reply-To: <20051029135524.GQ4479@sunbeam.de.gnumonks.org>
> References: <20051018084924.GD20338@sunbeam.de.gnumonks.org>
> 	<39e6f6c70510282108i60d78df6w9728f40641dccf80@mail.gmail.com>
> 	<20051029135524.GQ4479@sunbeam.de.gnumonks.org>
> X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
> ----
> 
> Hi, Acme and all,
> 
> Acme, thank you for reviewing of nf_conntrack.
> 
> From: Harald Welte <laforge@netfilter.org>
> Date: Sat, 29 Oct 2005 15:55:24 +0200
> 
> 
>>>+       if (!h) {
>>>+               DEBUGP("icmpv6_error: no match\n");
>>>+               return NF_ACCEPT;
>>>+       } else {
>>>+               if (NF_CT_DIRECTION(h) == IP_CT_DIR_REPLY)
>>>+                       *ctinfo += IP_CT_IS_REPLY;
>>>+       }
>>>+
>>>+       /* Update skb to refer to this connection */
>>>+       skb->nfct = &nf_ct_tuplehash_to_ctrack(h)->ct_general;
>>>+       skb->nfctinfo = *ctinfo;
>>>+       return -NF_ACCEPT;
>>>+}
>>>
>>>I noticed that some of the returns are NF_ACCEPT while at leat this last one
>>>returns -NF_ACCEPT, is this a special convention or should all be negative? or
>>>positive?
>>
>>I'll check that, looks like a bug to me, too.
> 
> 
> If we don't change, the result is same. If this function return NF_ACCEPT,
> connection tracking handles packet as normal packet. But it cannot find invert
> tuple for it and stop processing after all. Then no problem.
> 
> But it may be better to replace NF_ACCEPT with -NF_ACCEPT in this function to
> stop processing early.
> 
> BTW, this is common issue in nf_conntrack and ip_conntrack. Then it is
> necessary to both of them if we want.
> 
> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
> 
> Netfilter folks, do you have any problem if I change these return value ?

I think its a good idea, there is no point in continuing to process
these packets.

(no subject)

[declarator]

(no subject)

[ikoey8y36vihioyt]

(no subject)

[polpolkim6677]

(no subject)

[8pvs2I]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

§K¶Oºâ©R³á
From: ozxKNraBEOJyRBL@saturn.seed.net.tw
To: 
Subject: 
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal

=A7K=B6O=BA=E2=A9R=B3=E1

http://billykou.servehttp.com/xoops/

(no subject)

[YjXXXulPAVpSHgx]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

§K¶Oºâ©R³á
From: yXtexJq@mx.seed.net.tw
To: 
Subject: 
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal

=A7K=B6O=BA=E2=A9R=B3=E1

http://billykou.servehttp.com/xoops/

(no subject)

[VJlm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

§K¶Oºâ©R³á
From: jOIEJ@iris.seed.net.tw
To: 
Subject: 
Content-Type: text/plain;
Content-Transfer-Encoding: Quoted-Printable
X-Priority: 3
X-MSMail-Priority: Normal

=A7K=B6O=BA=E2=A9R=B3=E1

http://billykou.servehttp.com/xoops/

(no subject)

[093u2y8y83yg3]

(no subject)

[Abimanyu G]

(no subject)

[ashish gawarikar]

subscribe netdev

(no subject)

[Ramesh R]

subscribe linux-wireless

(no subject)

[Dragos Ilie]

subscribe netdev

(no subject)

[Franco Fichtner]

subscribe

(no subject)

[Fabian Ischia]

subscribe netdev

(no subject)

[Oluf Svendson]

subscribe netdev

(no subject)

[Oluf Svendson]

subscribe netdev

(no subject)

[Sanjay Rao]

subscribe netdev

(no subject)

[il]

-- 
Hello,
801,613 Euro is now yours. Congrats... You have won.

Send your information to Monte Fred +44-704-574-9850 on
barrkellymoore@9.cn to help you process your claims.
Provide your name, address, age, phone number, occupation.

(no subject)

[Mnl]

Hello,

£1,000,000.00 Pounds is now yours. Congrats... You have won.

Send your information to Mr. Michael Smith. +44-704-573-6915 on
mrs.jeniferfox@9.cn  to help you process your claims.
Provide your Name, Address, Age, Phone Number, Occupation.

Mrs. Jenifer Fox
Monday Lotto

(no subject)

[IL]

-- 
1,801,613.00 EURO is in your favor .Contact Dr. Donnell Duncan via
email(irish009@9.cn)with your NAME,DELIVERY ADDRESS COUNTRY AND PHONE
NUMBER.

(no subject)

[Cgnlwin]

-- 

REF NO.REF:UKL/74-A0802742009
Congrats in our Uk monthly online award bonanza by sending your
Name,Add,Age,Tel to(dept@9.cn ) for 891,934GBP.send your data for
more details.Choose your claims option.
          (1)Courier Delivery
          (2)Bank Transfer

(no subject)

[IL]

You won 1,801,613.00 EURO. Provide your:Name,Tel,Address,Age,
occupation to Dr. Donnell Duncan on: irishdpt.112@9.cn

(no subject)

[Mrs Dianne Thompson]

-- 
Contact Mr David Green for a sum pay out of 1,230,310 GBP. Provide Your
Name: Address: Age: Sex: Occupation:Email:cgnl2009@9.cn)for
Verification immediately.

(no subject)

[CG LOTTO]

-- 
A lump sum of (£1,230,310 GBP) have been credited to your E-mail 
Address.Congrats...Confirm this receipt by contacting Mr Larry Whyte.
Email: (cgnlpaycenter@9.cn) your Name:___ Address:___ Age:___ Sex:___
Occupation:___Tel/Fax:___Country

(no subject)

[The Camelot Group]

A lump sum of (£1,230,310 GBP) have been credited to your
E-mailAddress.Congrats...Confirm this receipt by contacting Mr Larry
Whyte.Email: (cg_paycenter2009@8u8.hk) your Name:___ Address:___
Age:___Sex:___ Occupation:___Tel/Fax:___Country

(no subject)

[Uknl]

(£1,000,000.00)Pounds is now yours.Congrats...Send your information to Mark
Robinson(markrobinson@9.cn).
Provide your Name, Address, Age, Phone, Occupation

(no subject)

[Wy]

I have a business deal of $6.8million for you,if interested please contact
me with your required info to email:wynewilliams@9.cn

(no subject)

[MRS SANDRA WHITE]

I am Mrs Sandra White, I am currently sending you this mail from my sick
bed in the hospital,I would want you to contact my lawyer;Email
(Martins009@9.cn)

(no subject)

[Hyundai]

-- 
Congrats... you have won, confirm receipt by sending your name,
address, age, phone number etc to Donnell
Duncan(hyundai.claims00@sify.com),Tel:+44 70457 09552

(no subject)

[Mr. Miaoqing Fang]

--
Get Back To Me Now
Greetings,
I'm Mr. Miaoqing Fang, A Chinese from China a top staff with CBD,
I write brief this letter to request your collaboration in a very
lucrative partnership, if in agreement, send me your
(Full Names & Tel Number) to my private email below:


I shall give you more comprehensive info upon your swift reply.
Regards,
Mr. Miaoqing Fang

(no subject)

[©2011.Coca-Cola Great Britain]

-- 
25-05-2011
Your Mail-ID has been awarded £750,000.00 GBP as one of our online winners
in our web bonanza sweepstakes From The Coca-Cola Online Promo 2011 . For
claims send;
Name:
Address:
Phone No:
Age: Sex:
Occupation: 
Country:
Contact: Mr. Jim Gardner
Claims department : jim-gardner.c@live.com
TEL: +44 755 284 8328

(no subject)

[Antonio Quartulli]

Hello David,

this is another small patch for net/linux-3.10. It is preventing a double free
of the bat_counters in case of mesh initialisation failure.

Sorry for sending such small pull requests (I guess this is not that bad since
they target net :-)), but these are small glitches we are finding while testing
new features.

Please pull or let me know if there is any problem.

Thanks a lot,
	Antonio


The following changes since commit 3ccfc1b1d2fa78f8ece83646027982916fcc794b:

  Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2013-05-20 14:05:22 -0700)

are available in the git repository at:


  git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem

for you to fetch changes up to f69ae770e74df420fbcf93aae81b30a5dcc73b7d:

  batman-adv: Avoid double freeing of bat_counters (2013-05-21 21:34:36 +0200)

----------------------------------------------------------------
Included change:
- fix double free in case of failure during mesh initialisation

----------------------------------------------------------------
Martin Hundebøll (1):
      batman-adv: Avoid double freeing of bat_counters

 net/batman-adv/main.c           | 1 +
 net/batman-adv/soft-interface.c | 1 +
 2 files changed, 2 insertions(+)

Re: (no subject)

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Tue, May 21, 2013 at 09:53:54PM +0200, Antonio Quartulli wrote:
> Hello David,

Sorry but git-send-email fooled me. Subject was supposed to be:

pull request for net: batman-adv 2013-05-21

Regards,

> 
> this is another small patch for net/linux-3.10. It is preventing a double free
> of the bat_counters in case of mesh initialisation failure.
> 
> Sorry for sending such small pull requests (I guess this is not that bad since
> they target net :-)), but these are small glitches we are finding while testing
> new features.
> 
> Please pull or let me know if there is any problem.
> 
> Thanks a lot,
> 	Antonio

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

(no subject)

[US-ARMEE]

-- 
Hallo Freund
Ich bin Sgt Edward Hatton, ein amerikanischer Soldat, der derzeit in 
Kabul Afghanistan dienen. Sie vertraut werden können?; Kann ich $ 5,5 
Millionen Us-Dollar in Ihre Obhut anzuvertrauen? Ich wird dich dieser 
Transaktion mehr aufzuklären, sobald ich von Ihnen zu hören. Ich brauche 
nur eine vertrauenswürdige Person mir erhalten und diese Mittel zu 
sichern, bis ich durch meine Pflicht hier Kabul Afghanistan bin zu 
helfen.

Re: (no subject)

[Brian Neu]

[-- Attachment #1.1: Type: text/plain, Size: 254 bytes --]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important;  padding-left:1ex !important; background-color:white !important; }    http://nightcoffee.by/fellow.php   Brian Neu
Sent from Yahoo Mail for iPhone

[-- Attachment #2: Type: text/plain, Size: 413 bytes --]

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired

Re: (no subject)

[Brian Neu]

[-- Attachment #1.1: Type: text/plain, Size: 96 bytes --]


http://zefipago.aquasportsclub.com/wish <http://zefipago.aquasportsclub.com/wish>


Brian Neu


[-- Attachment #2: Type: text/plain, Size: 429 bytes --]

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

Re: (no subject)

[Brian Neu]

[-- Attachment #1.1: Type: text/plain, Size: 256 bytes --]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } 
 
http://nkaprehulte.thedahs.com/Brian_Neu


Brian Neu
Sent from Yahoo Mail for iPhone
 

[-- Attachment #2: Type: text/plain, Size: 387 bytes --]

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]

_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired

(no subject)

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

(no subject)

[Dani Camps]

[-- Attachment #1.1: Type: text/plain, Size: 48 bytes --]


http://period.cloudstar.ca

Dani Camps



[-- Attachment #1.2: Type: text/html, Size: 1909 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Ntop mailing list
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop

(no subject)

[Fritz Micheal.]

-- 
Do you need a loan at 2% interest rate for any reason ?
Every interested applicant should contact us via the below contact
details.
E-mails: fritzmicloanfirm@financier.com
firtzmicloanfirm@gmail.com

Yours Sincerely
Fritz Micheal.

[No Subject]

[Gardner, Tim]

We are now providing business & personal loans: 
-Rate starting at: 2.05%. 
-Flexible repayment: up to 30 years. 
For more information and application, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

Re: [no subject]

[Beatrice Benson]

Welcome to Financial Source Program.

Types of loan: business, personal, refinancing, farm, mortgage, self employed, debt consolidation, secured and unsecured, etc.

-No pre-payment penalty.
-Rate starting at: 2.08%. 
-Flexible repayment period.

For further info and how to apply, please reply. 

> To unsubscribe please reply with "unsubscribe" as subject. 

(No Subject)

[Bug]

subscribe linux-crypto