heh :) I'll give a try to just try an address from random_ether_addr(), it might work Thanks! -- Inaky --

It doesn't really work, because it is for the "from" end of the connection; as said somewhere else in the thread, the WiMAX link is P2P, IP only. The card has a local address, that we use for the "to" field, but for the from, we need to fake an address from the network -- which is not necessarily an intel device :) So maybe local addresses would not be the right choice, and clearly Intel assigned ones neither :) Thanks, -- Inaky --

On Wed, 22 Apr 2009 15:38:10 -0700 Then don't bridge. --

CONFIG_DUET doesn't exist anymore, remove all the code that exists to support it. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> --- * Removed stale comment that went along w/DUET support drivers/net/fs_enet/fs_enet-main.c | 35 +---------------------------------- drivers/net/fs_enet/fs_enet.h | 5 ----- drivers/net/fs_enet/mac-fec.c | 34 ---------------------------------- 3 files changed, 1 insertions(+), 73 deletions(-) diff --git ...

Please remove the comment that goes with the code being removed. Otherwise, ACK. -Scott --

On Wed, 22 Apr 2009 13:48:27 -0700 You want really want hw to have real mac, but if not use random_ether_addr() --

Hi All The Intel i2400m WiMAX driver behaves as an ethernet device, and currently when sending packets to the netdev stack, it fakes an ethernet header, sets the "from" mac address to zeroes and the "to" to it's own MAC address. The WiMAX network can be considered to be a point-to-point (up to the gateway) connection, all IP based, so there are not MAC addresses from our gateway (not to mention that it can change behind us). The problem with using a zero mac address is that it ...

Here are the results of udp ping pong tests. Tests were done with between two machines. The first box was running a 2.6.22 kernel with the nic IRQ and udpping pinned to processor 4. The second box ran the various kernel versions. NIC irq pinned to cpu 4. Then the pinning of udpping (see gentwo.org/ll) was varied 1. Pinned to the same processor (cpu4) 2. Pinned to a processor that shares the L2 cache (cpu5) 3. Pinned to a processor not sharing L2 (cpu6) Results follow (a nice diagram is ...

Hello, folks. As seen recently, I've sent a bugfix for the e100 shutdown in the same lines as the patches proposed by RWJ to e1000, e1000e and some other network devices. I would like to get some light about the need to disable wake when suspending if there is no WOL support, if most, if not all, resume and probe code already do it. If it is really needed, perhaps, an utility helper function could be written and most drivers migrated to it. But another issue is that, in some particular ...

Add some useful documentation for the ISDN subsystem. Orignal patches are from Tilman Schmidt. I fixed some whitespace issues and added the URL for the CAPI 2.0 spec. Karsten Keil (1): Add reference to CAPI 2.0 standard Tilman Schmidt (2): update Documentation/isdn/00-INDEX Documentation/isdn/INTERFACE.CAPI Documentation/isdn/00-INDEX | 17 +++- Documentation/isdn/INTERFACE.CAPI | 208 +++++++++++++++++++++++++++++++++++++ drivers/isdn/capi/kcapi.c | 171 ...

Date: Tue, 21 Apr 2009 11:18:52 +0200 isdn: document Kernel CAPI driver interface Create a file Documentation/isdn/INTERFACE.CAPI describing the interface between the kernel CAPI subsystem and ISDN device drivers, analogous to the existing Documentation/isdn/INTERFACE for the old isdn4linux subsystem. Also add kerneldoc comments to the exported functions in drivers/isdn/capi/kcapi.c. Impact: Documentation Signed-off-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: Karsten Keil ...

Hi, But NI65 is properly guarded against ISA bus non-support already: config NI65 tristate "NI6510 support" depends on NET_VENDOR_RACAL && ISA && ISA_DMA_API help If you have a network (Ethernet) card of this type, say Y and read the Ethernet-HOWTO, available from <http://www.tldp.org/docs.html#howto>. To compile this driver as a module, choose M here. The module will be called ni65. And powerpc _does_ offer ISA ...

Hi, Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it. Any help with this kinda problem? Thanks, Shawn -------------- Y. D. 2009-04-22 --

I guess this is to work around a problem with hardware that's already in production? The best solution would be to swap the byte lanes in hardware, as the device's endian swapping features only affect registers (not the FIFOs). The very latest devices in this family (such as the LAN9221) can swap both independently, but this driver has to also support older parts. Performance will be suboptimal with this software byteswapping, so I think we should also add a comment to stress that this ...

>From now on FW will be downloaded from the binary file using request_firmware. There will be different files for every supported chip. Currently 57710 (e1) and 57711 (e1h). File names have the following format: bnx2x-<chip version>-<FW version>.fw. ihex versions of current FW files are submitted in the next patch. Each binary file has a header in the following format: struct bnx2x_fw_file_section { __be32 len; __be32 offset; } struct bnx2x_fw_file_hdr { struct ...

You have won £750,000 GBP. contact with your name, age, country and address to, Dr Joseph Patrick Email agenttoffices@gmail.com --

1) The usual assortment of several small wired driver fixes. CXGB3 link fault, workqueue lockup, MSI-X leak, EEH fixes from Divy Le Ray MACB retry limit and interrupt status loss fixes from Eric Waling UCC_GETH RMII PHY mode fix from Heiko Schocher TG3 final fix for the endian-corrupted MAC issue from Matt Carlson. IXGBE chip settings fix for 82599 from P. J. Waskiewicz. "(!x & y)" --> "(!(x & y))" fix in IXGBE from Tony Breeds TX queue restart fix in e1000e from Jesse ...

From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> This patch provides the socket type SOCK_SEQPACKET in addition to SOCK_STREAM. AF_IUCV sockets of type SOCK_SEQPACKET supports an 1:1 mapping of socket read or write operations to complete IUCV messages. Socket data or IUCV message data is not fragmented as this is the case for SOCK_STREAM sockets. The intention is to help application developers who write applications or device drivers using native IUCV interfaces (Linux kernel or ...

Dave, thanks for applying our critical af_iucv bug fixes to net-2.6. Here is now the series of iucv / af_iucv patches for the current development cycle. The patches are based on top of the current net-next-2.6 kernel (2.6.30-rc1). Hendrik Brueckner (7) af_iucv: sync sk shutdown flag if iucv path is quiesced af_iucv: add sockopt() to enable/disable use of IPRM_DATA msgs af_iucv: Support data in IUCV msg parameter lists (IPRMDATA) af_iucv: Modify iucv msg target class using ...

From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Provide the socket operations getsocktopt() and setsockopt() to enable/disable sending of data in the parameter list of IUCV messages. The patch sets respective flag only. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> --- include/linux/socket.h | 1 include/net/iucv/af_iucv.h | 4 ++ net/iucv/af_iucv.c | 79 ...

From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> The SO_MSGLIMIT socket option modifies the message limit for new IUCV communication paths. The message limit specifies the maximum number of outstanding messages that are allowed for connections. This setting can be lowered by z/VM when an IUCV connection is established. Expects an integer value in the range of 1 to 65535. The default value is 65535. The message limit must be set before calling connect() or listen() for ...

From: Ursula Braun <ursula.braun@de.ibm.com> Some of the IUCV commands can be invoked in interrupt context. Those commands need a different per-cpu IUCV command parameter block, otherwise they might overwrite an IUCV command parameter of a not yet finished IUCV command invocation in process context. Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> --- net/iucv/iucv.c | 41 +++++++++++++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 10 deletions(-) diff -urpN ...

The 2d3d.co.za domain does not seem to exist. -- Gilles. --

While this is a very old chip it is still in use on some embedded boards. I see myself unable to fix the in Kernel driver to bring it to driver model support, so this patch adds a new driver designed to replace the old one, at least for non-ISA hardware. Sascha --

These REV_B / REV_C / REV_D defines are not used, and in fact depend This will report incorrectly for CS8900 (not CS8900A), and for CS8900A rev. F: According to the CS8900A and CS8920A datasheets, the product ID should be interpreted as: 0x0700 CS8900A rev. B 0x0800 CS8900A rev. C 0x0900 CS8900A rev. D 0x0A00 CS8900A rev. F 0x6100 CS8920 rev. B 0x6200 CS8920 rev. C 0x6300 CS8920 rev. D 0x6400 CS8920A rev. A/B 0x6500 CS8920A rev. C (I couldn't find the datasheet for the ...

I'll set him on cc in the next round. I changed the module author nonetheless as it's better when mails regarding this driver go to me instead of Abraham (who wrote this driver in 2.4 days and probably has not much interest in it anymore) Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht ...

Ok, I'll just put myself as the module author and leave the credits to Abraham in the header, just removing his email address. I can't find any newer pointers to Abraham besides a facebook profile. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: ...

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Applied to net-next-2.6, thanks. --

From: "John W. Linville" <linville@tuxdriver.com> Pulled, thanks John. --

Hi, thanks Paul! --

Well, looking now at the patch again, I think you cannot add new fields without breaking existing apps. My previous review stoped at this _BH thing wihthout looking further :) Also, it seems some RFC4293 items are already handled, since commit d831666e from Mitsuru Chinen. Check net/ipv4/proc.c, line 114 /* Following RFC4293 items are displayed in /proc/net/netstat */ static const struct snmp_mib snmp4_ipextstats_list[] = { SNMP_MIB_ITEM("InNoRoutes", IPSTATS_MIB_INNOROUTES), ...

I suppose, I'm just trying to avoid collecting data for stats that the snmp Yeah, that makes sense, and I like the way it looks a bit better. I'll update the patch later this evening Thanks! --

Yes, I found it on page 7, on diagram. OutBcastPkts (1) Legend (1) is : (1) The HC counters and octet counters are also found at these points but have been left out for clarity. So apparently RFC forgot OutBcastOctets/InBcastOctets somewhere, oh well... We actually have IpExt: InNoRoutes InTruncatedPkts InMcastPkts OutMcastPkts InBcastPkts OutBcastPkts It would make sense to add : InOctets OutOctets InMcastOctets OutMcastOctets InBcastOctets OutBcastOctets Even if not ...

Hmm... I read RFC4293 and it mentions (3.2.3. IP Statistics Tables) (1) The HC counters and octet counters are also found at these points but have been left out for clarity. (1) counters are : InReceives, InMcastPkts, OutMcastPkts, OutBcastPkts, OutTransmits So RFC4293 tells corresponding Octets variables should be supported : InOctets, InMcastOctets, OutMcastOctets, OutBcastOctets, OutOctets And I dont see them in /proc/net/snmp or /proc/net/netstat Mitsuru added : ...

Hey all- New patch, taking Erics commentary pointing out my prior stupidity into account :). The IP MIB (RFC 4293) defines stats for InOctets, OutOctets, InMcastOctets and OutMcastOctets: http://tools.ietf.org/html/rfc4293 But it seems we don't track those in any way that easy to separate from other protocols. This patch adds those missing counters to the stats file. Tested successfully by me Signed-off-by: Neil Horman <nhorman@tuxdriver.com> include/linux/snmp.h | 4 ++++ ...

From: Ursula Braun <ursula.braun@de.ibm.com> All applied, thanks. --

And while we are at it : you should probably add lockdep annotation to this new lock. I never thought I would say this, but following the discussion going on about netfilter locking, I am starting to think that the RCU approach might be more simple and elegant that the nestable per-cpu rwlock approches proposed so far. ;) Plus, there is much fewer name calling involved in the making. :) Cheers, -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE ...

From: Jiri Kosina <jkosina@suse.cz> Applied to net-next-2.6, thanks. --

On Wed, Apr 22, 2009 at 12:37 PM, Thadeu Lima de Souza Cascardo Correct, that would be overkill. If Rafael wants his Ack or Reviewed-by added, he will let us know. Once we have done some regression testing on the patch, I will add my signed-off-by before sending it to Dave. -- Cheers, Jeff --

After experimenting with kexec with the last merges after 2.6.29, I've had some problems when probing e100. It would not read the eeprom. After some bisects, I realized this has been like that since forever (at least 2.6.18). The problem is that shutdown is doing the same thing that suspend does and puts the device in D3 state. I couldn't find a way to get the device back to a sane state in the probe function. So, based on some similar patches from Rafael J. Wysocki for e1000, e1000e and ixgbe, I ...

On Tue, Apr 21, 2009 at 9:38 PM, Thadeu Lima de Souza Cascardo Thanks, I will add it to my queue of patches for e100. Also, just FYI, Auke is no longer a maintainer for e100/e1000/e1000e/igb/ixgb/ixgbe devices, so I have removed him from the thread. -- Cheers, Jeff --

Yup, emac and sungem predate phylib. I had a quick look at what it would take to port at least emac over, the main issue was that I want to be able to sleep (ie, take a mutex) in my mdio read/write functions, and back then, phylib wouldn't let me do that due to spinlock and timer/softirq usage. Ben. --

Its runtime adjustable, so its easy to try out. The HTB classify hash has a scalability issue in kernels below 2.6.26. Patrick McHardy fixes that up in 2.6.26. What kernel version are you using? Could you explain how you do classification? And perhaps outline where you possible scalability issue is located? If you are interested how I do scalable classification, see my presentation from Netfilter Workshop 2008: http://nfws.inl.fr/en/?p=115 Yes, htb_hysteresis basically is ...

Herbert Xu wrote: > > In the mean time, can you see if there is any disparity in the > number of aggregated segments and ACKs between GRO and LRO? > netstat -s should be sufficient to measure this (TCP segments > received and sent). I booted the sender into a kernel.org 2.6.18.2 so as to try to have results as close to yours as possible (I was running 2.6.22 on the sender before). I ran 2 sets of experiments, with different CPU bindings. First I bound the netserver and IRQ to the ...

I will send a new signed patch after review in few hours. Thanks to Tilman for this work. Karsten --

It applies on top of my mis-dated patch Subject: [PATCH v2] update Documentation/isdn/00-INDEX Date: Mon, 17 Nov 2008 14:01:32 +0100 which I sent in fact on 7 Apr 2009. Somehow I thought you had already applied that. If it helps, I can re-send that one with the correct date, or alternatively merge both of these patches into one. Regards, Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten ...

I have no idea what you meant by a "hard" error. Note that I also discussed EAGAIN, which appears to happen commonly historically and today, and appears to be what the security module folks would want to have happen and you're rejecting. Do you consider that to be a hard error? I'm betting not. -- greg --

From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> So what does your TOMOTO stuff do if the mapping changes again and that incoming connection that became unacceptable is now acceptable? We've lost the connection, and can never get it back. These semantics don't make any sense at all, and the point at which you make your choices here is totally arbitrary. Read that carefully: the point at which you are making this drop decision is arbitrary. --

From: Greg Lindahl <greg@blekko.com> I said explicitly that hard errors are allows (out of file descriptors, memory allocation failure) Feel free to ignore what I'm saying, and I'll feel free to ignore you too. --

From: Greg Lindahl <greg@blekko.com> EAGAIN does not happen if the application calls poll(), gets an indication that connections are available, and then immediately calls accept() on the indicated FD. It can only happen if it calls accept() multiple times after such a poll() call _OR_ it does not control multi-threaded access to the listen file descriptor. This new behavior from TOMOYO would make accept() return -EAGAIN in cases which are of no fault of the application. It is ...

From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Fine. FWIW I do not agree with TOMOYO conceptually. But if people are generally going to let such a scheme into the kernel, I guess I have to accept these socket layer hacks :-/ --

From: Greg Lindahl <greg@blekko.com> People use poll() to avoid -EAGAIN and blocking, they expect the bits to tell them what fd's they can work on to do real work. But this whole task_struct based security is bogus from the start. If I dup a file descriptor for a listening socket, and accept() in the "wrong" task, the other task has no way to accept() that connection even if it's security settings allow it. The connection is lost forever. The realm of file descriptors overlaps that of ...

I was suggested to use that approach in the past discussion. I want to make policy decisions based on the "task_struct" who picks up the connection/datagram. The netfilter can't predict which "task_struct" will pick up the connection/datagram. Nobody can predict it. Even security_socket_accept() and security_socket_recvmsg() can't predict it. If TOMOYO is allowed to make policy decisions based on the "task_struct" who picks up the connection/datagram, the only possible approach is to ...

No application is permitted to assume that accept() returns a connection if poll() says that connections are available even if there is an assumption that none of sock->ops->accept(), newsock->ops->getname(), move_addr_to_user() fails, for there is security_socket_accept() hook which can interrupt between "poll()" and "accept()". There is a possibility that LSM module's policy changes from "allow picking the connection up from the listening socket" to "deny picking the connection up from the ...

TOMOYO won't keep the connection. That's fine. TOMOYO thinks that dropping the connection/datagram is better than choking the queue/buffer by keeping the connection/datagram for future policy changes. I browsed the poll() logic for TCP/IPv4's listening socket. SYSCALL_DEFINE3(poll, struct pollfd __user *, ufds, unsigned int, nfds, long, timeout_msecs) { int do_sys_poll(struct pollfd __user *ufds, unsigned int nfds, struct timespec *end_time) { ...

Linus, I actually sent *one* buggy patch, and you already gave your feedback and NACK. Fine I even relayed this to Stephen suggesting him not calling this a recursive lock. (Note how I use 'suggesting' here) So, what do you want from me ? Should I copy 100 times : "I should not call it a recursive lock. I shall not invent new locking infra. I am a moron." "I should not call it a recursive lock. I shall not invent new locking infra. I am a moron." "I should not call it a recursive ...

You might disagree with me on an honest technical basis, but note that this kind of childish, knee-jerk reaction against dissenting people is what gives netdev its bad reputation. Ingo --

Again ... i dont know this code well, but you yourself describe it as "a_central_and_damn_rwlock" above. "Central and damn" locks of any type, anywhere tend to cause such trouble. Often they are mini-BKL's in the making. Here's some historic patterns: 1- First there's a convenient lock around a popular and useful piece of data and code. 2- As popularity (and reach of code) grows, and some non-trivial interaction ensues, a little bit of self-recursion is added to ...

Looks good from a concurrency viewpoint! This is very good -- gets rid of problems with preemption nesting depth limitations and lockdep limitations. In addition, it gets rid of the period of time during which all packet processing might otherwise be blocked. Not a big deal on a small machine, but could be a real problem on a large one. Good, you do indeed need to prevent migration before you acquire this CPU's lock. Otherwise, you could have more than one CPU attempting to Good. ...

The netfilter case is real simple Ingo, (note I did not use "obvious" here ;) ) netfilter in 2.6.2[0-9] used : CPU 1 sofirq handles one packet from a NIC ipt_do_table() /* to handle INPUT table for example, or FORWARD */ read_lock_bh(&a_central_and_damn_rwlock) ... parse rules -> calling some netfilter sub-function re-entering network IP stack to send some packet (say a RST packet) ... ipt_do_table() /* to handle OUPUT table rules for example */ ...

You don't _understand_ do you? There is a huge difference between recursive code, and a recursive lock. The netfilter code may need to occasionally re-enter itself. Nobody ever contested _that_ part. What I have disagreed with the whole time is (a) doing local ad-hoc locking primitives without any comments what-so-ever. (b) Doing them _wrong_ in many cases (c) Calling the _lock_ a "recursive" lock. The fact that a lock works with recursion doesn't make it ...

Ack on the code. But the comment is _still_ crap. Please update. It's not a recursive lock, as clearly shown by the code itself. It's a per-cpu read-write lock, and only the reader is "recursive" (but that's how read-write locks with in Linux, and that has nothing to do with anything). So make the explanations match the code and the intent. Write it something like This version of x_tables (ip/ip6/arp) locking uses a per-cpu reader-writer lock lock where the readers can ...

Any news on this? It is still badly broken in 2.6.30-rc3. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." --

We are doing the pre-demux, and it works well. The additional benefit is that the hash result or the the sk itself could be cached in the skb for the upper layer protocol. One caveat though is that if the device provides a hash, ie. Toeplitz, we really want to use that in the CPU look-up to avoid the cache miss on the header. We considered using the Toeplitz hash as the inet hash, but it's incredibly expensive to do in software being about 20x slower than inet_ehashfn is best we could do. ...

This is also very important for routing performance. Experiences from practical 10GbE routing tests (done by Roberts team and my self), reveals that we can only achieve (close to) 10Gbit/s routing performance when carefully making sure that the rx-queue and tx-queue runs on the same CPU. (Not doing so really kills performance). Currently I'm using some patches by Jens L

Yeah, given the above the app was broken. We just didn't run into any cases where the assumption caused any problems. Also, it's not so much that we were relying on the offset value for anything, so much as we were parsing the file and had made some assumptions about valid offsets for anonymous memory. Anyways, we'll fix it going forward to simply ignore the offset for anonymous memory. Chris --