Re: [2.6 patch] the scheduled eepro100 removal

uot;IPMI card sharing the 100Mbit/s NIC" onboard? What exactly is shared? Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - To unsubscribe from this list: send the line "unsubscribe netdev" in the b

Re: [PATCH] shutting down an interface should remove ipv4 addresses

ain. Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Window shrinking (was Linux v2.6.16-rc6)

rt to netdev in this case. Chances are slim though, since they only have one Packeteer so far and no test network to perform test conducts, so erroneous tests would cause major downtime for a lot of this ISP's customers. My 2 cents, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%

Re: [PATCH] [IPVS] Shrink ip_vs_*.c includes

oring the fact mentioned by Herbert because of its small chance of happening) and my suggestion was/is to move it to ip_vs.h. I'll ping Arnaldo regarding this cleanup, since he's done it before and certainly has some scripts to automate this. Thanks for the review and discussion, Rober

Re: [PATCH][RFC] Shrink ip_vs_*.c includes

will get built when > a given header is touched, where perhaps only half of it needed > to be built. Well, it does not happen so ofter that a core network related header is touched to my avail. > So with that in mind, could you continue in the vein of > your original patch? Sure thing.

Re: [PATCH][RFC] Shrink ip_vs_*.c includes

eclared here (not in > a function) > net/ipv4/ipvs/ip_vs_conn.c:761: error: 'seq_read' undeclared here (not in a > function) > net/ipv4/ipvs/ip_vs_conn.c:762: error: 'seq_lseek' undeclared here (not in a > func

[PATCH][RFC] Shrink ip_vs_*.c includes

r includes. Signed-off-by: Roberto Nibali <[EMAIL PROTECTED]> Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc diff --git a/net/ipv4/ipvs/ip_vs_app.c b/net/ipv4/ipvs/ip_vs_app.c index 9b176a9..9f5676b 100644 --- a

Re: how to obtain detailed e1000 stats?

qfile ;). Meanwhile I've found your work on your OSS part of candelatech. Very interesting to me. Yep..my consolidated patches are there... A 2.6.15 patch will show up when I figure out why pktgen is crashing on 2.6.15.. The standard one in the kernel or your additions? Best regard

Re: how to obtain detailed e1000 stats?

-stats 2 rx_bytes eth0.rx_bytes 1264755 I also notice that the lib/libnetlink.c file is GPL instead of LGPL, so I can't use it in my application anyway... https://svn.suug.ch/repos/tgr/libnl/COPYING Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb31350

Re: how to obtain detailed e1000 stats?

egrated into ethtool per default? Again..I'd love to see it in Meanwhile I've found your work on your OSS part of candelatech. Very interesting to me. Cheers, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc -

Re: how to obtain detailed e1000 stats?

ethtool_get_netdev_stats(dev, useraddr); +default: +break; +} + + if (!dev->ethtool_ops) + goto ioctl; + switch (ethcmd) { case ETHTOOL_GSET: Thanks for this patch, I wonder if this should be integrated into ethtool per default? Be

Re: how to obtain detailed e1000 stats?

ats struct and copy it directly to user-space. This is easier and most likely more efficient than parsing the /proc/net/dev file. Yes, please ;). I'd be interested in this patch as well. Regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb313507179010176854228757843

Re: [2.6 patch] fix ipvs compilation

and lust and haven't gone through the ../ipvs/ directory yet, your excellent cleanups are also very much appreciated :). Cheers, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - To unsubscribe from this list: send the line

Re: [2.6 patch] fix ipvs compilation

e since my local copy of IPVS still works. But to be honest, I would like to clean up the IPVS headers in general. I believe we can cut short maybe half of the includes in the various ip_vs* modules. Regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287

Re: [Q: 2.4 vs. 2.6] nf_conntrack_get() semantics in copy_skb_header()

e_cleanup() returns NULL. After x HZ () of endless schedule() we decrement ip_conntrack_untracked.ct_general.use or ip_conntrack_count if the atomic counter > 1. Don't laugh, please ;). Cheers, Roberto Nibali, ratz -- - addr://K

Re: [Patch] 2.4.32 - Neighbour Cache (ARP) State machine bug Fixed

igh_suspect(n); > + } > + If this is really a problem, why not simply call neigh_sync()? Your patch also seems to be whitespace damaged. >write_unlock(&n->lock); > > next_elt: I've cc'd netdev since this is where such patches sho

Re: [Q: 2.4 vs. 2.6] nf_conntrack_get() semantics in copy_skb_header()

7;s without a clear documentation as to why (ipv4/ip_input.c:ip_call_ra_chain() for 2.6 kernel, maybe for skb_clone()'d packets), which makes it very hard to understand. - Where exactly do we need to nf_conntrack_put()/nf_reset() skb's? I wonder if the remaining references should just

[Q: 2.4 vs. 2.6] nf_conntrack_get() semantics in copy_skb_header()

following difference in core/skbuff.h:copy_skb_header: 2.6.x: nf_conntrack_get(old->nfct); 2.4.x: nf_conntrack_get(new->nfct); Since the rest of the assignments match I was left wondering, which one is correct? Regards, Robe

Re: [PATCH 6/6] [NETLINK]: Generic netlink family

t the code to your netlink API or will we be able to interact freely with nfnetlink/ctnetlink messages? Hey Thomas, let's get together this weekend or the next one somewhere in mountains to ride (just fixed my snowboard) and hack some code. What about Zermatt? Cheers, Roberto Nibali, ra