Re: TCP stalls in current git, possibly splice related
On Fri, Jul 13 2007, Jens Axboe wrote: On Thu, Jul 12 2007, James Morris wrote: On Thu, 12 Jul 2007, David Miller wrote: From: James Morris [EMAIL PROTECTED] Date: Thu, 12 Jul 2007 16:12:25 -0400 (EDT) I'm seeing TCP connection stalls with current git, and a bisect found the following as a possible cause: To add to this James is seeing this with distcc I believe. Correct. I'll try and reproduce. You didn't happen to get a sysrq-t backtrace of that distcc being hung, did you? -- Jens Axboe - 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: [2.6.23 PATCH 13/18] dm: netlink
On 7/13/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Thu, Jul 12, 2007 at 04:31:15PM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: Need a dependency on NET there? It's really sad to make DM dependent on the network layer. Yes, it would be somewhat sad. However one can presumably continue to use DM, just without DM netlink events. On my machine device mapper (lvm, raid) does not work without sockets, (maybe not dm, but hotplug, which creates nodes, or configuration) so it already depends on it. Hotplug depends on networking. You missed the day when everyone started to depend on networking :) Right, uevents (udev) depend on networking. One could still use the /sbin/hotplug fork-bomb, but boxes that don't want networking are often that small, that the amount of events the kernel creates today, leads immediately to OOM, because of too many event processes forked at the same time. Kay - 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: [2.6.23 PATCH 13/18] dm: netlink
On Thu, Jul 12, 2007 at 04:31:15PM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: Need a dependency on NET there? It's really sad to make DM dependent on the network layer. Yes, it would be somewhat sad. However one can presumably continue to use DM, just without DM netlink events. On my machine device mapper (lvm, raid) does not work without sockets, (maybe not dm, but hotplug, which creates nodes, or configuration) so it already depends on it. Hotplug depends on networking. You missed the day when everyone started to depend on networking :) -- Evgeniy Polyakov - 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
a question about the reord
Dear all: I'm reading the code about the Congestion Control.Now I'm confused about the variable reord in the function tcp_sacktag_write_queue(). The reord is initialized as the tp-packets_out, I think, which is a max threshold of the reordering. If it detect a hole or D-SACK ,set the reord to : --- reord = min(fack_count, reord); Finally,the code may update the reordering by: --- tcp_update_reordering(sk, ((tp-fackets_out + 1) - reord), 0); The questions are : 1 What's the purpose of the reord ? 2 Why use the ((tp-fackets_out + 1) - reord) to update the reordering. Do I need to study some more RFC about this ? If yes,please tell me ,thanks . - 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: [Cbe-oss-dev] [PATCH] spidernet: don't use debug flag
Linas-san, p.s. I tested ifdown/ifup, and didn't see any problems. Does your bug happen immediately, or does it take many attempts to trigger it? Thanks for your testing. It happens immediately in our environment. It may be celleb specific. Best regards, Kou Ishizaki - 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: [2.6 patch] EP93XX_ETH must select MII
On Fri, Jul 13, 2007 at 02:12:08AM +0200, Adrian Bunk wrote: From: John Donoghue [EMAIL PROTECTED] CONFIG_EP93XX_ETH=y, CONFIG_MII=n results in an obvious link error. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Lennert Buytenhek [EMAIL PROTECTED] - 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: [PATCH] 7990 : Various fixes and cleanups
On Tue, Jul 10, 2007 at 12:38:45PM -0400, Jeff Garzik wrote: Philippe De Muyter wrote: This patch - avoids 7990 blocking when no tx buffer is available, [...] diff -r 6c0a10cc415a drivers/net/7990.c --- a/drivers/net/7990.c Thu Jul 5 16:10:16 2007 -0700 +++ b/drivers/net/7990.c Fri Jul 6 11:27:20 2007 +0200 [...] @@ -541,9 +546,6 @@ int lance_start_xmit (struct sk_buff *sk static int outs; unsigned long flags; -if (!TX_BUFFS_AVAIL) -return -1; - netif_stop_queue (dev); skblen = skb-len; NAK It avoids by removing an overrun check in hard_start_xmit that should not be removed. Yup, sorry. The real fact is still that this prevents/fixes lance/driver blocking on my board, while the tx_timeout mechanism does not succeed at that, and that on my board the driver is blocked when we return -1 on !TX_BUFFS_AVAIL. I'll investigate why. Philippe PS : did you apply the rest of the patch ? -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 - 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: [NET]: gen_estimator deadlock fix
On Fri, 2007-07-13 at 14:17 +0200, Jarek Poplawski wrote: On Thu, Jul 12, 2007 at 08:48:45PM +0300, Ranko Zivojnovic wrote: ... Ok - here's the patch for a review - it compiles clean ... and that's as much as it has been tested - I'll try give it a run later today or definitely tomorrow. ... Ranko, you have some powers! Alas, I definitely need more time. I hope I'll manage to check this till monday. Of course, if testing will be OK and somebody will check and ack this earlier I don't see any reason in waiting on my opinion. Don't bother - just tested and it is a no-go (it would have been a wander if it worked from the first time :)) - have to resolve the issues with qdiscs that do not calculate/use rates... I'm not sure if it is desirable to have rates available on all qdiscs - even on pfifo_fast... that way, when you issue... # tc -s qdisc show dev eth0 qdisc pfifo_fast 0: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 115971059 bytes 196761 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ...you will not get the 'rate 0bit'. R. - 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: [NET]: gen_estimator deadlock fix
On Thu, Jul 12, 2007 at 08:48:45PM +0300, Ranko Zivojnovic wrote: ... Ok - here's the patch for a review - it compiles clean ... and that's as much as it has been tested - I'll try give it a run later today or definitely tomorrow. ... Ranko, you have some powers! Alas, I definitely need more time. I hope I'll manage to check this till monday. Of course, if testing will be OK and somebody will check and ack this earlier I don't see any reason in waiting on my opinion. Thanks good weekend, Jarek P. - 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: d80211 deadlock with wpa_supplicant and rmmod
On 7/12/07, Johannes Berg [EMAIL PROTECTED] wrote: On Wed, 2007-07-11 at 19:41 -0400, John W. Linville wrote: I believe we have a deadlock in d80211. I have it too. But I'm using iwl3945 driver, in-kernel mac80211, and a gentoo kernel (basically a patched vanilla-2.6.22.1). My machine is a x86_64 core 2 duo. The following triggers it on my 2way SMT machine with preempt. modprobe bcm43xx-d80211 add sta0 ifconfig sta0 up start wpa_supplicant on the interface rmmod bcm43xx-d80211 Sounds like the bug with the scheduled work locking. See the mac80211/bcm43xx deadlock thread, there's a patch, report back if you can/can not reproduce with the patch. Hello, sorry for the delay but I only managed to try it out today.. I've applied the patch and tortured the system as far as I could, and no hang at all :) I've read the thread and it apparently replaces one bad problem for a lesser one, so I understand if it's not applied.. But at least there is a place in the code to point as the culprit :) Thanks, Renato Caldas - 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: [PATCH] IPROUTE2: Fix bug in display of ipv6 cloned/cached routes
Sridhar Samudrala wrote: I found an issue with my original patch. If cache/cloned is specified, it dumps the cloned routes irrespective of the table specified. I think this is a better fix and also should address the case you were mentioning above. Your patch looks good, thanks. - 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: [PATCH v2 -mm 8/9] netconsole: Support multiple logging targets
Hi Satyam, From: Satyam Sharma [EMAIL PROTECTED] [8/9] netconsole: Support multiple logging targets This patch introduces support for multiple targets: Let's keep this out of CONFIG_NETCONSOLE_DYNAMIC as well -- this is useful even in the default case and (including the infrastructure introduced in previous patches) doesn't really add too many bytes to module text. All the complexity (and size) comes with the dynamic reconfigurability / userspace interface patch, and so it's plausible users may want to keep this enabled but that disabled (say to avoid a dep on CONFIG_CONFIGFS_FS too). Also update documentation to mention the use of ; separator to specify multiple logging targets in the boot/module option string. Brief overview: We maintain a target_list (and corresponding lock). Get rid of the static default_target and introduce allocation and release functions for our netconsole_target objects (but keeping sure to preserve previous behaviour such as default values). During init_netconsole(), ; is used as the separator to identify multiple target specifications in the boot/module option string. The target specifications are parsed and netpolls setup. During exit, the target_list is torn down and all items released. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Keiichi Kii [EMAIL PROTECTED] Signed-off-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [PATCH v2 -mm 6/9] netconsole: Introduce netconsole_netdev_notifier
Hi Satyam,
From: Satyam Sharma [EMAIL PROTECTED]
[6/9] netconsole: Introduce netconsole_netdev_notifier
To update fields of underlying netpoll structure at runtime on
corresponding NETDEV_CHANGEADDR or NETDEV_CHANGENAME notifications.
ioctl(SIOCSIFHWADDR) {or ioctl(SIOCSIFNAME)} could be used to change the
hardware/MAC address {or name} of the local interface that our netpoll is
attached to. Whenever this happens, netdev notifier chain is called out
with the NETDEV_CHANGEADDR {or NETDEV_CHANGENAME} event message. We respond
to that and update the local_mac {or dev_name} field of the struct netpoll.
This makes sense anyway, but is especially required for dynamic netconsole
because the netpoll structure's internal members become user visible files
when either sysfs or configfs are used. So this helps us to keep up with the
MAC address / name changes and keep the values in struct netpoll uptodate.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Cc: Keiichi Kii [EMAIL PROTECTED]
Signed-off-by: Keiichi Kii [EMAIL PROTECTED]
Thanks
--
Keiichi KII
NEC Corporation OSS Platform Development Division
E-mail: [EMAIL PROTECTED]
-
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: [PATCH v2 -mm 7/9] netconsole: Use netif_running() in write_msg()
Hi Satyam, From: Satyam Sharma [EMAIL PROTECTED] [7/9] netconsole: Use netif_running() in write_msg() Avoid unnecessarily disabling interrupts and calling netpoll_send_udp() if the corresponding local interface is not up. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Keiichi Kii [EMAIL PROTECTED] Acked-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [PATCH v2 (updated) -mm 4/9] netconsole: Add some useful tips to documentation
Hi Satyam, [4/9 (updated)] netconsole: Add some useful tips to documentation Add some useful general-purpose tips. Also suggest solution for the frequent problem of console_loglevel set too low numerically (i.e. for high priority messages only) on the sender. Cc: Matt Mackall [EMAIL PROTECTED] Cc: Jesper Juhl [EMAIL PROTECTED] Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Acked-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [PATCH v2 -mm 5/9] netconsole: Introduce netconsole_target
Hi Satyam, From: Satyam Sharma [EMAIL PROTECTED] [5/9] netconsole: Introduce netconsole_target Introduce a wrapper structure over netpoll to represent logging targets configured in netconsole. This will get extended with other members in further patches. The original patchset did this along with (and inside the #ifdef) of CONFIG_NETCONSOLE_DYNAMIC itself. I decided otherwise, and was able to drastically cut down on the #ifdef-complexity of final netconsole.c. Also, struct netconsole_target would be required for multiple targets support also, and not just dynamic reconfigurability. Previously these two things were coupled, but I want to de-link that (more on this later). Note that this patch in itself looks quite redundant / stupid, but it is purposefully made this way, so further patches are more readable. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Keiichi Kii [EMAIL PROTECTED] Signed-off-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [PATCH v2 -mm 3/9] netconsole: Simplify boot/module option setup logic
Hi Satyam, From: Satyam Sharma [EMAIL PROTECTED] [3/9] netconsole: Simplify boot/module option setup logic Presently, for built-in netconsole: __setup(..., option_setup) ensures that the option_setup() function is called at boot-time from obsolete_checksetup() with the string matching netconsole= passed to it from the kernel's command line. We call the netpoll_parse_options() from in there, and populate the netpoll struct with the passed values. Then, when init_netconsole() is called during the initcall phase, strlen(config) fails, thus skipping option_setup(). For modular netconsole: module_param_string() ensures that the string corresponding to the netconsole module parameter passed from the modprobe command line is copied into the config static variable. This time, when the module is being initialized, strlen(config) is true and so option_setup() is called on config from init_netconsole() and the input string is parsed and the netpoll struct populated. Hence, quite different things happen in the copying and parsing of the passed netpoll parameters for the modular / built-in cases. This patch makes both of them similar by doing exactly the equivalent of a module_param_string() in option_setup() also -- just copying the param string passed from the kernel command line into the config static variable. So, init_netconsole() parses (using netpoll_parse_options()) it in both the cases, and makes the logic somewhat simpler. Now, option_setup() is only ever called / used for the built-in case, so we put it inside a #ifndef MODULE, otherwise gcc will complain about option_setup() being defined but not used. Also, the configured variable is redundant with this patch and so removed. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Keiichi Kii [EMAIL PROTECTED] Signed-off-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [PATCH v2 -mm 2/9] netconsole: Remove bogus check
Hi Satyam, From: Satyam Sharma [EMAIL PROTECTED] [2/9] netconsole: Remove bogus check The (!np.dev) check in write_msg() is bogus (always false), because: np.dev is set by netpoll_setup(), which is called by the target init code in init_netconsole() _before_ register_console() = write_msg() cannot be triggered unless netpoll_setup() returns with success. And that will not happen if netpoll_setup() failed to set np.dev. Also np.dev cannot go from under us while netconsole is loaded. This is because netpoll_setup() grabs a reference for us on that dev. So let's remove the pointless check. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Keiichi Kii [EMAIL PROTECTED] Acked-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [PATCH v2 -mm 1/9] netconsole: Cleanups, codingstyle, prettyfication
Hi Satyam, From: Satyam Sharma [EMAIL PROTECTED] [1/9] netconsole: Cleanups, codingstyle, prettyfication (1) Remove unwanted headers. (2) Mark __init and __exit as appropriate. (3) Various trivial codingstyle and prettification stuff. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Keiichi Kii [EMAIL PROTECTED] Signed-off-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [RFC][PATCH v2 -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability
Hi Satyam, [0/9] netconsole: Multiple targets and dynamic reconfigurability This patchset is a rework of the original idea and patches posted by Keiichi Kii and Takayoshi Kochi at: http://lkml.org/lkml/2007/6/13/72 This is v2 of the patchset, the previous version is available at: http://lkml.org/lkml/2007/7/4/107 This is diffed against 2.6.22-rc6-mm1 + the earlier netpoll fixlet and the configfs cleanup patches (those are already merged in -mm AFAIK, and hence not reproduced here). [1/9] netconsole: Cleanups, codingstyle, prettyfication [2/9] netconsole: Remove bogus check [3/9] netconsole: Simplify boot/module option setup logic [4/9] netconsole: Add some useful tips to documentation [5/9] netconsole: Introduce netconsole_target [6/9] netconsole: Introduce netconsole_netdev_notifier [7/9] netconsole: Use netif_running() in write_msg() [8/9] netconsole: Support multiple logging targets [9/9] netconsole: Support dynamic reconfiguration using configfs I tested your v2 patches on the x86/IA64 architecture. There was no problem on my tests. Signed-off-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: [NET]: gen_estimator deadlock fix
On Fri, Jul 13, 2007 at 03:26:42PM +0300, Ranko Zivojnovic wrote: On Fri, 2007-07-13 at 14:17 +0200, Jarek Poplawski wrote: On Thu, Jul 12, 2007 at 08:48:45PM +0300, Ranko Zivojnovic wrote: ... Ok - here's the patch for a review - it compiles clean ... and that's as much as it has been tested - I'll try give it a run later today or definitely tomorrow. ... Ranko, you have some powers! Alas, I definitely need more time. I hope I'll manage to check this till monday. Of course, if testing will be OK and somebody will check and ack this earlier I don't see any reason in waiting on my opinion. Don't bother - just tested and it is a no-go (it would have been a wander if it worked from the first time :)) - have to resolve the issues with qdiscs that do not calculate/use rates... I'm not sure if it is desirable to have rates available on all qdiscs - even on pfifo_fast... that way, when you issue... # tc -s qdisc show dev eth0 qdisc pfifo_fast 0: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 115971059 bytes 196761 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ...you will not get the 'rate 0bit'. I've been a bit tight on time today, and only now I see that maybe you have done too much. Of course, you can do it your way, but I think it should be easier not change too much at once, so if possible only include structs bstats and rate_est into struct gen_estimator and do otherwise in these few sch_'s and act_'s which use this plus all acceses and allocs changed appropriately. So it should be only 6 or 7 files affected. It seems no changes about gen_stats are necessary now (next patch?). I really can't check more now (or answer until monday). Bye, Jarek P. PS: I'm in a little hurry now so I hope I'm not very wrong above... - 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: [PATCH][RFC] network splice receive v3
On Thu, Jul 12 2007, Evgeniy Polyakov wrote: On Wed, Jul 11, 2007 at 11:19:27AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: Hi, Hi Jens. Here's an updated implementation of tcp network splice receive support. It actually works for me now, no data corruption seen. For the original announcement and how to test it, see: http://marc.info/?l=linux-netdevm=118103093400770w=2 The splice core changes needed to support this are now merged in 2.6.22-git, so the patchset shrinks to just two patches - one for adding a release hook, and one for the networking changes. The code is also available in the splice-net branch here: git://git.kernel.dk/data/git/linux-2.6-block.git splice-net There's a third experimental patch in there that allows vmsplice directly to user memory, that still needs some work though. Comments, testing welcome! It looks like you included all bits we found in the previous runs, so likely it will work good, but so far I have conflicts merging todays git and your tree in include/linux/splice.h, fs/ext2/file.c, fs/splice.c and mm/filemap_xip.c. This can be a problem with my tree though. Hmm, the patch should apply directly to the tree as of when I posted this original mail, or any later one. I just tried a rebase, and it rebased fine on top of the current -git as well. So I think the issue is with your tree, sorry! It really looks like the last tree we tested, so if you think additional one will not hurt, feel free to ping, so I will completely rebase testing tree. It would be great if you could retest! There are some minor changes in there, and some extra testing definitely will not hurt. -- Jens Axboe - 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: [PATCH v2 -mm 9/9] netconsole: Support dynamic reconfiguration using configfs
Hi Satyam, From: Satyam Sharma [EMAIL PROTECTED] [9/9] netconsole: Support dynamic reconfiguration using configfs This patch introduces support for dynamic reconfiguration (adding, removing and/or modifying parameters of netconsole targets at runtime) using a userspace interface exported via configfs. Documentation is also updated accordingly. Issues and brief design overview: (1) Kernel-initiated creation / destruction of kernel objects is not possible with configfs -- the lifetimes of the config items is managed exclusively from userspace. But netconsole must support boot/module params too, and these are parsed in kernel and hence netpolls must be setup from the kernel. Joel Becker suggested to separately manage the lifetimes of the two kinds of netconsole_target objects -- those created via configfs mkdir(2) from userspace and those specified from the boot/module option string. This adds complexity and some redundancy here and also means that boot/module param-created targets are not exposed through the configfs namespace (and hence cannot be updated / destroyed dynamically). However, this saves us from locking / refcounting complexities that would need to be introduced in configfs to support kernel-initiated item creation / destroy there. Also, this is similar to present behaviour in any case so not really a problem. (2) In configfs, item creation takes place in the call chain of the mkdir(2) syscall in the driver subsystem. If we used an ioctl(2) to create / destroy objects from userspace, the special userspace program is able to fill out the structure to be passed into the ioctl and hence specify attributes such as local interface that are required at the time we set up the netpoll. For configfs, this information is not available at the time of mkdir(2). So, we keep all newly-created targets (via configfs) disabled by default. The user is expected to set various attributes appropriately (including the local network interface if required) and then write(2) 1 to the enabled attribute. Thus, netpoll_setup() is then called on the set parameters in the context of _this_ write(2) on the enabled attribute itself. This design enables the user to reconfigure existing netconsole targets at runtime to be attached to newly-come-up interfaces that may not have existed when netconsole was loaded or when the targets were actually created. This all enables us to get rid of custom ioctls. (3) Ultra-paranoid configfs attribute show() and store() operations, with sanity and input range checking, using only safe string primitives, and compliant with the recommendations in Documentation/filesystems/sysfs.txt. (4) A new function netpoll_print_options() is created in the netpoll API, that just prints out the configured parameters for a netpoll structure. netpoll_parse_options() is modified to use that and it is also exported to be used from netconsole. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: Keiichi Kii [EMAIL PROTECTED] Acked-by: Keiichi Kii [EMAIL PROTECTED] Thanks -- Keiichi KII NEC Corporation OSS Platform Development Division E-mail: [EMAIL PROTECTED] - 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: TCP stalls in current git, possibly splice related
On Fri, 13 Jul 2007, Jens Axboe wrote: On Fri, Jul 13 2007, Johannes Berg wrote: On Thu, 2007-07-12 at 16:12 -0400, James Morris wrote: I'm seeing TCP connection stalls with current git, and a bisect found the following as a possible cause: I'm also seeing stalls with synergy. Please try the below. Works for me. -- James Morris [EMAIL PROTECTED] - 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: TCP stalls in current git, possibly splice related
On Fri, Jul 13 2007, Johannes Berg wrote:
On Thu, 2007-07-12 at 16:12 -0400, James Morris wrote:
I'm seeing TCP connection stalls with current git, and a bisect found the
following as a possible cause:
I'm also seeing stalls with synergy.
Please try the below.
diff --git a/fs/splice.c b/fs/splice.c
index ed2ce99..92646aa 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -491,7 +491,7 @@ ssize_t generic_file_splice_read(struct file *in, loff_t
*ppos,
ret = 0;
spliced = 0;
- while (len) {
+ while (len !spliced) {
ret = __generic_file_splice_read(in, ppos, pipe, len, flags);
if (ret 0)
@@ -1051,15 +1051,10 @@ ssize_t splice_direct_to_actor(struct file *in, struct
splice_desc *sd,
sd-flags = ~SPLICE_F_NONBLOCK;
while (len) {
- size_t read_len, max_read_len;
-
- /*
-* Do at most PIPE_BUFFERS pages worth of transfer:
-*/
- max_read_len = min(len, (size_t)(PIPE_BUFFERS*PAGE_SIZE));
+ size_t read_len;
- ret = do_splice_to(in, sd-pos, pipe, max_read_len, flags);
- if (unlikely(ret 0))
+ ret = do_splice_to(in, sd-pos, pipe, len, flags);
+ if (unlikely(ret = 0))
goto out_release;
read_len = ret;
@@ -1071,26 +1066,17 @@ ssize_t splice_direct_to_actor(struct file *in, struct
splice_desc *sd,
* could get stuck data in the internal pipe:
*/
ret = actor(pipe, sd);
- if (unlikely(ret 0))
+ if (unlikely(ret = 0))
goto out_release;
bytes += ret;
len -= ret;
- /*
-* In nonblocking mode, if we got back a short read then
-* that was due to either an IO error or due to the
-* pagecache entry not being there. In the IO error case
-* the _next_ splice attempt will produce a clean IO error
-* return value (not a short read), so in both cases it's
-* correct to break out of the loop here:
-*/
- if ((flags SPLICE_F_NONBLOCK) (read_len max_read_len))
- break;
+ if (ret read_len)
+ goto out_release;
}
pipe-nrbufs = pipe-curbuf = 0;
-
return bytes;
out_release:
@@ -1152,10 +1138,12 @@ long do_splice_direct(struct file *in, loff_t *ppos,
struct file *out,
.pos= *ppos,
.u.file = out,
};
- size_t ret;
+ long ret;
ret = splice_direct_to_actor(in, sd, direct_splice_actor);
- *ppos = sd.pos;
+ if (ret 0)
+ *ppos += ret;
+
return ret;
}
--
Jens Axboe
-
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: [PATCH] ps3: gigabit ethernet driver for PS3, take3
Hi Sthephen, Thank you for your review. I'll submit the patches which would fix these issues. -- Masakazu MOKUNO - 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: TCP stalls in current git, possibly splice related
On Fri, Jul 13 2007, Jens Axboe wrote:
On Fri, Jul 13 2007, Jens Axboe wrote:
On Thu, Jul 12 2007, James Morris wrote:
On Thu, 12 Jul 2007, David Miller wrote:
From: James Morris [EMAIL PROTECTED]
Date: Thu, 12 Jul 2007 16:12:25 -0400 (EDT)
I'm seeing TCP connection stalls with current git, and a bisect found
the
following as a possible cause:
To add to this James is seeing this with distcc I believe.
Correct.
I'll try and reproduce.
You didn't happen to get a sysrq-t backtrace of that distcc being hung,
did you?
Does this work for you?
diff --git a/fs/splice.c b/fs/splice.c
index ed2ce99..92646aa 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -491,7 +491,7 @@ ssize_t generic_file_splice_read(struct file *in, loff_t
*ppos,
ret = 0;
spliced = 0;
- while (len) {
+ while (len !spliced) {
ret = __generic_file_splice_read(in, ppos, pipe, len, flags);
if (ret 0)
@@ -1051,15 +1051,10 @@ ssize_t splice_direct_to_actor(struct file *in, struct
splice_desc *sd,
sd-flags = ~SPLICE_F_NONBLOCK;
while (len) {
- size_t read_len, max_read_len;
-
- /*
-* Do at most PIPE_BUFFERS pages worth of transfer:
-*/
- max_read_len = min(len, (size_t)(PIPE_BUFFERS*PAGE_SIZE));
+ size_t read_len;
- ret = do_splice_to(in, sd-pos, pipe, max_read_len, flags);
- if (unlikely(ret 0))
+ ret = do_splice_to(in, sd-pos, pipe, len, flags);
+ if (unlikely(ret = 0))
goto out_release;
read_len = ret;
@@ -1071,26 +1066,17 @@ ssize_t splice_direct_to_actor(struct file *in, struct
splice_desc *sd,
* could get stuck data in the internal pipe:
*/
ret = actor(pipe, sd);
- if (unlikely(ret 0))
+ if (unlikely(ret = 0))
goto out_release;
bytes += ret;
len -= ret;
- /*
-* In nonblocking mode, if we got back a short read then
-* that was due to either an IO error or due to the
-* pagecache entry not being there. In the IO error case
-* the _next_ splice attempt will produce a clean IO error
-* return value (not a short read), so in both cases it's
-* correct to break out of the loop here:
-*/
- if ((flags SPLICE_F_NONBLOCK) (read_len max_read_len))
- break;
+ if (ret read_len)
+ goto out_release;
}
pipe-nrbufs = pipe-curbuf = 0;
-
return bytes;
out_release:
@@ -1152,10 +1138,12 @@ long do_splice_direct(struct file *in, loff_t *ppos,
struct file *out,
.pos= *ppos,
.u.file = out,
};
- size_t ret;
+ long ret;
ret = splice_direct_to_actor(in, sd, direct_splice_actor);
- *ppos = sd.pos;
+ if (ret 0)
+ *ppos += ret;
+
return ret;
}
--
Jens Axboe
-
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: [2.6.23 PATCH 14/18] dm: netlink add to core
On Wed, 2007-07-11 at 17:40 -0700, Mike Anderson wrote: The pid is a hold over from older code. If this will cause issue for other users I can switch to using nlmsg_multicast (genlmsg_multicast depending on the comment if I need to switch to the genl interface) and remove this code all together. Another possible genl multicast user :) Has anybody had a chance to look at my patches for this? johannes signature.asc Description: This is a digitally signed message part
[patch 1/3] From: Jennifer Hunt [EMAIL PROTECTED]
[PATCH] s390: iucv Kconfig. Improve description of IUCV and AFIUCV configuration options. Signed-off-by: Jennifer Hunt [EMAIL PROTECTED] Signed-off-by: Ursula Braun [EMAIL PROTECTED] Acked-by: Frank Pavlic [EMAIL PROTECTED] --- net/iucv/Kconfig |8 1 files changed, 4 insertions(+), 4 deletions(-) Index: net-2.6-uschi/net/iucv/Kconfig === --- net-2.6-uschi.orig/net/iucv/Kconfig +++ net-2.6-uschi/net/iucv/Kconfig @@ -1,13 +1,13 @@ config IUCV - tristate IUCV support (VM only) + tristate IUCV support (S390 - z/VM only) depends on S390 help - Select this option if you want to use inter-user communication under - VM or VIF sockets. If you run on z/VM, say Y to enable a fast + Select this option if you want to use inter-user communication + under VM or VIF. If you run on z/VM, say Y to enable a fast communication link between VM guests. config AFIUCV - tristate AF_IUCV support (VM only) + tristate AF_IUCV support (S390 - z/VM only) depends on IUCV help Select this option if you want to use inter-user communication under -- - 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
[patch 2/3] s390: iucv - avoid deadlock between iucv_path_connect and tasklet
From: Ursula Braun [EMAIL PROTECTED]
An iucv deadlock may occur, where one CPU is spinning on the
iucv_table_lock for iucv_tasklet_fn(), while another CPU is holding
the iucv_table_lock for an iucv_path_connect() and is waiting for
the first CPU in an smp_call_function.
Solution: replace spin_lock in iucv_tasklet_fn by spin_trylock and
reschedule tasklet in case of non-granted lock.
Signed-off-by: Ursula Braun [EMAIL PROTECTED]
Acked-by: Frank Pavlic [EMAIL PROTECTED]
---
net/iucv/iucv.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
Index: net-2.6-uschi/net/iucv/iucv.c
===
--- net-2.6-uschi.orig/net/iucv/iucv.c
+++ net-2.6-uschi/net/iucv/iucv.c
@@ -1494,7 +1494,10 @@ static void iucv_tasklet_fn(unsigned lon
struct iucv_irq_list *p, *n;
/* Serialize tasklet, iucv_path_sever and iucv_path_connect. */
- spin_lock(iucv_table_lock);
+ if (!spin_trylock(iucv_table_lock)) {
+ tasklet_schedule(iucv_tasklet);
+ return;
+ }
iucv_active_cpu = smp_processor_id();
spin_lock_irq(iucv_queue_lock);
--
-
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: sky2 hangs without any messages
On 12/07/07, Stephen Hemminger [EMAIL PROTECTED] wrote: On Thu, 12 Jul 2007 22:29:50 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: On 12/07/07, Stephen Hemminger [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007 23:55:29 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: Please try again with post 2.6.22 git version (1.16)? Reproduced with 2.6.22 w/ sky2 1.16 from git. We observe this characteristic failure on the NFS server (always around 2-3GB of transmit): $ ifconfig lan0 lan0 Link encap:Ethernet HWaddr 00:03:2D:05:9C:27 inet addr:192.168.0.250 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:24007220 errors:1 dropped:1 overruns:0 frame:1 TX packets:13886495 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:171026170 (163.1 MiB) TX bytes:2262910580 (2.1 GiB) Interrupt:16 I'll rebuild with debugfs and grab the debug you've exported. In quiescent state [1] and in failure state [2]. This time, 2 framing failures [3]; took 3.6GB of transmit to hit the window. Since the IRQ workaround has a timeout of 100ms. I observed cases where the TCP connection dropped (because of lost packets), but the network device then recovered. Can you ping the other side after it hangs? Or reconnect? Ifconfig lumps a bunch of different errors together so it can confuse the issue. Preference is for: ip -s -s link show eth0 or grep -v '^0' /sys/class/net/eth0/statistics/* If the framing error does reproduce with the hang, perhaps the chip needs some receive flush logic to recover. Receive errors normally put a message in syslog output, did you look there? Daniel --- [1] # cat sky2/lan0 IRQ src=0 mask=c01d control=0 Status ring (empty) Tx ring pending=191...191 report=191 done=191 Rx ring hw get=956 put=61 last=1023 --- [2] # cat sky2/lan0 IRQ src=0 mask=c01d control=0 Status ring (empty) Tx ring pending=251...251 report=251 done=251 Rx ring hw get=1020 put=160 last=1023 --- [3] $ ifconfig lan0 lan0 Link encap:Ethernet HWaddr 00:03:2D:05:9C:27 inet addr:192.168.0.250 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13304841 errors:1 dropped:1 overruns:0 frame:2 TX packets:7493765 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:232720755 (221.9 MiB) TX bytes:3964088142 (3.6 GiB) Interrupt:16 You aren't hung because of lost IRQ. When than happens the debugfs output will have a bunch of Tx packets stuck (not cleaned up), and Status messages, and receive packets. I'll grab the above info when I next get chance. The vendor driver recovery process may be worthwhile taking a look at; I guess you've seen the code near the bottom of skge.c (under 'case SK_DRV_RECOVER')? The driver kicks the chip with SK_PNMI_EVT_XMAC_RESET and calls SkYuk2RestartRxBmu - perhaps something like this sequence is needed for a more targetted approach? That code triggers (falsely) on an idle or barely active link. It won't work. It is covering over a bunch of problems in the vendor driver that like improper flow control. Yes. Although my point was about how it resets the relevant parts of the chip; the OS just sees a netif_stop_queue and a netif_wake_queue, rather than marking the interface down etc. Daniel -- Daniel J Blueman - 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
[patch 0/3] [AF_IUCV/IUCV] fixes for net-2.6.23
-- Dave, following three small patches contain: - a configuration improvement for AF_IUCV socket support - two fixes for iucv, the base code for IUCV related actions in z/VM Thank you. Ursula - 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: Races in net_rx_action vs netpoll?
On Thu, Jul 12, 2007 at 03:54:32PM +0200, Olaf Kirch wrote:
Hi Jarek,
On Thursday 12 July 2007 14:59, Jarek Poplawski wrote:
+#ifdef CONFIG_NETPOLL
+ /* Prevent race with netpoll - yes, this is a kludge.
+ * But at least it doesn't penalize the non-netpoll
+ * code path. */
Alas, this can penalize those who have it enabled (e.g. by distro),
but don't use.
Well, the test_bit is actually cheap; it's not atomic, and has no memory
ordering requirements by all I know. The costly thing is set_bit/clear_bit
in poll_napi; and you only ever get there when you *use* netpoll.
I've only meant it doesn't penalize isn't too precise here,
at least if you take it mathematically. But, e.g. politically
it's 110% right, of course.
And it looks like _netif_rx_complete should be a better place,
at least considering such cards as: 8139too, skge, sungem and
maybe more (according to 2.6.22).
Why?
It seems I miss something, but if it's to be called from dev-poll,
these drivers use __netif_rx_complete instead of netif_rx_complete.
+ set_bit(__LINK_STATE_POLL_LIST_FROZEN, np-dev-state);
npinfo-rx_flags |= NETPOLL_RX_DROP;
I wonder, why this flag cannot be used for this check?
I tried, but it made the patch rather icky. netpoll_info is defined
in netpoll.h, which includes netdevice.h. So you cannot inline the
check, and have to use an out-of-line function instead, along the
lines of
extern int am_i_being_called_by_poll_napi(struct net_device *);
netif_rx_complete(struct net_device *dev)
{
#ifdef CONFIG_NETPOLL
if (unlikely(dev-npinfo am_i_being_called_by_poll_napi(dev))
return;
#endif
...
}
If you don't mind that, yes - this flag (or better, a newly introduced
NETPOLL_RX_NAPI) may work as well.
One thing I was a little worried about was whether dev-npinfo can
go away all of a sudden. It's really just protected by an rcu_readlock...
I didn't think about this struct netpoll_info vs. inlining,
but I'm glad you did, so adding a new flag looks more reasonably
if we don't want to mess to much with netdevice.h.
BTW, I don't think there could be any problem with rcu (if it's
all about calling dev-poll from poll_napi) because then poll_napi
should have the same problem.
BTW, I'd be very glad if somebody could hint me what is the main
reason for such troublesome function as poll_napi: if it's about
performance isn't this enough to increase budget for netpoll in
net_rx_action?
I think one reason is that you want to get the kernel oops out even
when the machine is so hosed that it doesn't even service softirqs
anymore.
Thanks! So, I have to think about this more. Of course, such idea
is fine if it doesn't collide with normal service, which I'm not
sure is true now. I mean this problem here, and e.g. needles
servicing of not netconsole packets by different cpus, but also
some unclear to me things like calling this from find_skb when
there is a problem with alloc_skb (I wonder how a card driver
manages to get these skbs for receiving?).
Cheers,
Jarek P.
-
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
[patch 3/3] s390: af_iucv: add lock when updating accept_q
From: Ursula Braun [EMAIL PROTECTED]
The accept_queue of an af_iucv socket will be corrupted, if
adding and deleting of entries in this queue occurs at the
same time (connect request from one client, while accept call
is processed for another client).
Solution: add locking when updating accept_q
Signed-off-by: Ursula Braun [EMAIL PROTECTED]
Acked-by: Frank Pavlic [EMAIL PROTECTED]
---
include/net/iucv/af_iucv.h |1 +
net/iucv/af_iucv.c | 16 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
Index: net-2.6-uschi/include/net/iucv/af_iucv.h
===
--- net-2.6-uschi.orig/include/net/iucv/af_iucv.h
+++ net-2.6-uschi/include/net/iucv/af_iucv.h
@@ -60,6 +60,7 @@ struct iucv_sock {
chardst_user_id[8];
chardst_name[8];
struct list_headaccept_q;
+ spinlock_t accept_q_lock;
struct sock *parent;
struct iucv_path*path;
struct sk_buff_head send_skb_q;
Index: net-2.6-uschi/net/iucv/af_iucv.c
===
--- net-2.6-uschi.orig/net/iucv/af_iucv.c
+++ net-2.6-uschi/net/iucv/af_iucv.c
@@ -219,6 +219,7 @@ static struct sock *iucv_sock_alloc(stru
sock_init_data(sock, sk);
INIT_LIST_HEAD(iucv_sk(sk)-accept_q);
+ spin_lock_init(iucv_sk(sk)-accept_q_lock);
skb_queue_head_init(iucv_sk(sk)-send_skb_q);
skb_queue_head_init(iucv_sk(sk)-backlog_skb_q);
iucv_sk(sk)-send_tag = 0;
@@ -274,15 +275,25 @@ void iucv_sock_unlink(struct iucv_sock_l
void iucv_accept_enqueue(struct sock *parent, struct sock *sk)
{
+ unsigned long flags;
+ struct iucv_sock *par = iucv_sk(parent);
+
sock_hold(sk);
- list_add_tail(iucv_sk(sk)-accept_q, iucv_sk(parent)-accept_q);
+ spin_lock_irqsave(par-accept_q_lock, flags);
+ list_add_tail(iucv_sk(sk)-accept_q, par-accept_q);
+ spin_unlock_irqrestore(par-accept_q_lock, flags);
iucv_sk(sk)-parent = parent;
parent-sk_ack_backlog++;
}
void iucv_accept_unlink(struct sock *sk)
{
+ unsigned long flags;
+ struct iucv_sock *par = iucv_sk(iucv_sk(sk)-parent);
+
+ spin_lock_irqsave(par-accept_q_lock, flags);
list_del_init(iucv_sk(sk)-accept_q);
+ spin_unlock_irqrestore(par-accept_q_lock, flags);
iucv_sk(sk)-parent-sk_ack_backlog--;
iucv_sk(sk)-parent = NULL;
sock_put(sk);
@@ -298,8 +309,8 @@ struct sock *iucv_accept_dequeue(struct
lock_sock(sk);
if (sk-sk_state == IUCV_CLOSED) {
- release_sock(sk);
iucv_accept_unlink(sk);
+ release_sock(sk);
continue;
}
@@ -879,6 +890,7 @@ static int iucv_callback_connreq(struct
/* Find out if this path belongs to af_iucv. */
read_lock(iucv_sk_list.lock);
iucv = NULL;
+ sk = NULL;
sk_for_each(sk, node, iucv_sk_list.head)
if (sk-sk_state == IUCV_LISTEN
!memcmp(iucv_sk(sk)-src_name, src_name, 8)) {
--
-
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: TCP stalls in current git, possibly splice related
On Thu, 2007-07-12 at 16:12 -0400, James Morris wrote: I'm seeing TCP connection stalls with current git, and a bisect found the following as a possible cause: I'm also seeing stalls with synergy. johannes signature.asc Description: This is a digitally signed message part
Re: [2.6 patch] more ACSI removal
On Fri, 13 Jul 2007, Adrian Bunk wrote:
This patch removes some code that became dead code after the ATARI_ACSI
removal.
When was it removed? Nobody seems to have informed the m68k people...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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: [PATCH 2.6.22-rc7] 8139cp: dev-tx_timeout
Hmm... that's strange. I just tested again and got it applied perfectly to
vanilla 2.6.22-rc7. The git version must be just that much different.
Can you test this one, this time it's made against the netdev-2.6 version.
There indeed is a slight offset in the line numbers.
By the way, we just got the problem recurred again. The timeout reset did
enable the traffic to flow again after a hang, so this patch clearly helps.
The problem requires very heavy network load when the tx queue is
constantly quite full.
-Mika
Jeff Garzik [EMAIL PROTECTED] wrote on 10.07.2007 19:42:21:
[EMAIL PROTECTED] wrote:
(Resending the patch against 2.6.22-rc7)
This patch implements the missing dev-tx_timeout for 8139cp driver
Signed-off-by: Mika Lansirinne [EMAIL PROTECTED]
ACK but still fails to apply
---
This patch implements the missing dev-tx_timeout for 8139cp driver
Signed-off-by: Mika Lansirinne [EMAIL PROTECTED]
---
--- netdev-2.6/drivers/net/8139cp.c 2007-07-11 13:19:56.0 +0300
+++ netdev-2.6_8139cp-tx_timeout/drivers/net/8139cp.c 2007-07-11
13:26:44.0 +0300
@@ -26,7 +26,6 @@
TODO:
* Test Tx checksumming thoroughly
- * Implement dev-tx_timeout
Low priority TODO:
* Complete reset on PciErr
@@ -1218,6 +1217,30 @@ static int cp_close (struct net_device *
return 0;
}
+static void cp_tx_timeout(struct net_device *dev)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ int rc;
+ unsigned long flags;
+
+printk (KERN_WARNING %s: Transmit timeout, status %2x %4x %4x %4x\n,
+dev-name, cpr8(Cmd), cpr16(CpCmd),
+cpr16(IntrStatus), cpr16(IntrMask));
+
+ spin_lock_irqsave(cp-lock, flags);
+
+ cp_stop_hw(cp);
+ cp_clean_rings(cp);
+ rc = cp_init_rings(cp);
+ cp_start_hw(cp);
+
+ netif_wake_queue(dev);
+
+ spin_unlock_irqrestore(cp-lock, flags);
+
+ return;
+}
+
#ifdef BROKEN
static int cp_change_mtu(struct net_device *dev, int new_mtu)
{
@@ -1923,10 +1946,8 @@ static int cp_init_one (struct pci_dev *
dev-change_mtu = cp_change_mtu;
#endif
dev-ethtool_ops = cp_ethtool_ops;
-#if 0
dev-tx_timeout = cp_tx_timeout;
dev-watchdog_timeo = TX_TIMEOUT;
-#endif
#if CP_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
-
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: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Ilpo Järvinen wrote: On Thu, 12 Jul 2007, Rick Jones wrote: One question is why the RTO gets so large that it limits failover? If Linux TCP is working correctly, RTO should be srtt + 2*rttvar So either there is a huge srtt or variance, or something is going wrong with RTT estimation. Given some reasonable maximums of Srtt = 500ms and rttvar = 250ms, that would cause RTO to be 1second. I suspect that what is happening here is that a link goes down in a trunk somewhere for some number of seconds, resulting in a given TCP segment being retransmitted several times, with the doubling of the RTO each time. But that's a back-off for the retransmissions, the doubling is temporary... Once you return to normal conditions, the accumulated backoff multiplier will be immediately cut back to normal. So you should then be back to 1 second (like in the example or whatever) again... Fine, but so? I suspect the point of the patch is to provide a lower cap on the accumulated backoff so data starts flowing over the connection within that lower cap once the link is restored/failed-over. rick jones - 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: [RFC][PATCH v2 -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability
Hi Keiichi, On Fri, 13 Jul 2007, KII Keiichi wrote: Hi Satyam, [0/9] netconsole: Multiple targets and dynamic reconfigurability This patchset is a rework of the original idea and patches posted by Keiichi Kii and Takayoshi Kochi at: http://lkml.org/lkml/2007/6/13/72 This is v2 of the patchset, the previous version is available at: http://lkml.org/lkml/2007/7/4/107 This is diffed against 2.6.22-rc6-mm1 + the earlier netpoll fixlet and the configfs cleanup patches (those are already merged in -mm AFAIK, and hence not reproduced here). [1/9] netconsole: Cleanups, codingstyle, prettyfication [2/9] netconsole: Remove bogus check [3/9] netconsole: Simplify boot/module option setup logic [4/9] netconsole: Add some useful tips to documentation [5/9] netconsole: Introduce netconsole_target [6/9] netconsole: Introduce netconsole_netdev_notifier [7/9] netconsole: Use netif_running() in write_msg() [8/9] netconsole: Support multiple logging targets [9/9] netconsole: Support dynamic reconfiguration using configfs I tested your v2 patches on the x86/IA64 architecture. There was no problem on my tests. Signed-off-by: Keiichi Kii [EMAIL PROTECTED] Ok, thanks! I'll send out the next series (with the various few fixes and cleanups suggested this time) with your Sign-offs/Acks. Satyam - 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: [PATCH v2 (updated) -mm 4/9] netconsole: Add some useful tips to documentation
On Wed, Jul 11, 2007 at 03:49:29AM +0530, Satyam Sharma wrote: [4/9 (updated)] netconsole: Add some useful tips to documentation Add some useful general-purpose tips. Also suggest solution for the frequent problem of console_loglevel set too low numerically (i.e. for high priority messages only) on the sender. Cc: Matt Mackall [EMAIL PROTECTED] Cc: Jesper Juhl [EMAIL PROTECTED] Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Thanks. Acked-by: Matt Mackall [EMAIL PROTECTED] -- Mathematics is the supreme nostalgia of our time. - 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: [Bugme-new] [Bug 8747] New: MSG_ERRQUEUE messages do not pass to connected raw sockets
On Fri, 13 Jul 2007 09:56:20 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8747
Summary: MSG_ERRQUEUE messages do not pass to connected raw
sockets
Product: Networking
Version: 2.5
KernelVersion: 2.6.22
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV6
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Problem Description:
It is related to the possibility to obtain MSG_ERRQUEUE messages from the udp
and raw sockets, both connected and unconnected.
There is a little typo in net/ipv6/icmp.c code, which prevents such messages
to
be delivered to the errqueue of the correspond raw socket, when the socket is
CONNECTED. The typo is due to swap of local/remote addresses.
Consider __raw_v6_lookup() function from net/ipv6/raw.c. When a raw socket is
looked up usual way, it is something like:
sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr, IP6CB(skb)-iif);
where daddr is a destination address of the incoming packet (IOW our local
address), saddr is a source address of the incoming packet (the remote end).
But when the raw socket is looked up for some icmp error report, in
net/ipv6/icmp.c:icmpv6_notify() , daddr/saddr are obtained from the echoed
fragment of the bad packet, i.e. daddr is the original destination address
of that packet, saddr is our local address. Hence, for icmpv6_notify() must
use saddr, daddr in its arguments, not daddr, saddr ...
Steps to reproduce:
Create some raw socket, connect it to an address, and cause some error
situation: f.e. set ttl=1 where the remote address is more than 1 hop to
reach.
Set IPV6_RECVERR .
Then send something and wait for the error (f.e. poll() with POLLERR|POLLIN).
You should receive time exceeded icmp message (because of ttl=1), but the
socket do not receive it.
If you do not connect your raw socket, you will receive MSG_ERRQUEUE
successfully. (The reason is that for unconnected socket there are no actual
checks for local/remote addresses).
This bugzilla report includes a patch, which is below.
Dmitry, please don't send patches via bugzilla: we very much prefer that
they be emailed directly as per Documentation/SubmittingPatches, thanks.
--- net/ipv6/icmp.c 2007-02-04 21:44:54.0 +0300
+++ net/ipv6/icmp.c.OK 2007-07-13 20:57:37.0 +0400
@@ -600,7 +600,7 @@
read_lock(raw_v6_lock);
if ((sk = sk_head(raw_v6_htable[hash])) != NULL) {
- while((sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr,
+ while((sk = __raw_v6_lookup(sk, nexthdr, saddr, daddr,
IP6CB(skb)-iif))) {
rawv6_err(sk, skb, NULL, type, code, inner_offset,
info);
sk = sk_next(sk);
-
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
[PATCH 0/1] myri10ge update for 2.6.23
Hi Jeff, Almost nothing new regarding myri10ge in 2.6.23 for now, just a single patch to remove some non-sensical code in the tx done routine. Please apply, thanks, Brice - 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
[PATCH 1/1] myri10ge: Remove nonsensical limit in the tx done routine
Remove nonsensical limit in the tx done routine. Specifically,
the loop will always terminate after processing = 1 rings worth
of frames, as the mcp index is not refetched, so the removed
conditional could never be true.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c |6 --
1 file changed, 6 deletions(-)
Index: linux-2.6.22/drivers/net/myri10ge/myri10ge.c
===
--- linux-2.6.22.orig/drivers/net/myri10ge/myri10ge.c 2007-07-09
01:32:17.0 +0200
+++ linux-2.6.22/drivers/net/myri10ge/myri10ge.c2007-07-12
11:21:29.0 +0200
@@ -1059,7 +1059,6 @@
struct myri10ge_tx_buf *tx = mgp-tx;
struct sk_buff *skb;
int idx, len;
- int limit = 0;
while (tx-pkt_done != mcp_index) {
idx = tx-done tx-mask;
@@ -1090,11 +1089,6 @@
bus), len,
PCI_DMA_TODEVICE);
}
-
- /* limit potential for livelock by only handling
-* 2 full tx rings per call */
- if (unlikely(++limit 2 * tx-mask))
- break;
}
/* start the queue if we've stopped it */
if (netif_queue_stopped(mgp-dev)
-
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: [PATCH] 7990 : Various fixes and cleanups
Philippe De Muyter wrote: On Tue, Jul 10, 2007 at 12:38:45PM -0400, Jeff Garzik wrote: Philippe De Muyter wrote: This patch - avoids 7990 blocking when no tx buffer is available, [...] diff -r 6c0a10cc415a drivers/net/7990.c --- a/drivers/net/7990.cThu Jul 5 16:10:16 2007 -0700 +++ b/drivers/net/7990.cFri Jul 6 11:27:20 2007 +0200 [...] @@ -541,9 +546,6 @@ int lance_start_xmit (struct sk_buff *sk static int outs; unsigned long flags; -if (!TX_BUFFS_AVAIL) -return -1; - netif_stop_queue (dev); skblen = skb-len; NAK It avoids by removing an overrun check in hard_start_xmit that should not be removed. Yup, sorry. The real fact is still that this prevents/fixes lance/driver blocking on my board, while the tx_timeout mechanism does not succeed at that, and that on my board the driver is blocked when we return -1 on !TX_BUFFS_AVAIL. Note that it should be returning a NETDEV_TX_xxx return value, which may be confusing the net stack. You have to let it know what happened to the skb passed to -hard_start_xmit(), which is normally the responsibility of the -hard_start_xmit() hook to free or queue as conditions warrant. Yeah, you will need to investigate further what's going on here. PS : did you apply the rest of the patch ? No, I don't apply partial patches. You are welcome to resubmit a patch containing the non-controversial changes. In fact, it's normal and encouraged in Linux to submit multiple patches for different logical changes. Splitting cleanups and a TX code path change into two separate patches is certainly the best way to go. If there is a problem, that allows users to use 'git bisect' to quickly locate which specific patch caused the problem. If patches are split up properly, good-or-bad changes are identified more rapidly. Jeff - 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
[PATCH] try parent numa_node at first before using default v2
[PATCH] try parent numa_node at first before using default v2
For pci_device, pcibios_scan_root and pci_scan_root will call pci_device_add.
pci_device_add will call device_initialize and set_dev_node(dev-dev,
pcibus_to_node(bus)).
other device such as netdev, and usb_device, set_dev_node is never be
used. So that field numa_node always is -1.
So for netdev, it will need to use dev-parent to get pci_device to
use it's numa_node. esp in netdev_alloc_skb()
not sure how other device such as infiniband do that.
Actually before patch
[PATCH 1/2] x86_64: get mp_bus_to_node as early
there is a bug about squence of bus-sysdata and using pcibus_to_node.
the numa_node of pci_dev-dev is never set correctly...always 0.
So some device have to use pcibus_to_node(to_pci_dev(dev)-bus) directly
such as dma_alloc_pages in arch/x86_64/kernel/pci-dma.c.
or hwif_to_node in include/linux/ide.h
According to Stefan Richter
- Change all subsystems to set dev-parent before device_initialize().
*Document* that the device_initialize() API has this requirement.
This is counter-intuitive, amounts to some work across the kernel,
and could be gotten wrong again in future code because it's a
counter-intuitive API.
- Move your code from device_initialize() to device_add(). One minor
drawback is that node-specific allocations based on the device's
numa_node would not be optimized before device_add(), but there is
probably no need for this. Driver probes come after device_add().
- Let subsystems explicitly call set_dev_node() on their own.
this patch is using second method.
Also we don't need call set_dev_node in pci_device_add anymore. but need to
make sure every pci root bus's bridge device numa is set.
with this patch, we could use device-numa_node direclty for all device.
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..c029ffc 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -935,7 +938,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
*bus)
dev-dev.release = pci_release_dev;
pci_dev_get(dev);
- set_dev_node(dev-dev, pcibus_to_node(bus));
dev-dev.dma_mask = dev-dma_mask;
dev-dev.coherent_dma_mask = 0xull;
@@ -1096,6 +1098,9 @@ struct pci_bus * pci_create_bus(struct device *parent,
goto dev_reg_err;
b-bridge = get_device(dev);
+ if (!parent)
+ set_dev_node(b-bridge, pcibus_to_node(b));
+
b-class_dev.class = pcibus_class;
sprintf(b-class_dev.class_id, %04x:%02x, pci_domain_nr(b), bus);
error = class_device_register(b-class_dev);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0455aa7..d8b063b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -672,6 +672,11 @@ int device_add(struct device *dev)
if (error)
goto Error;
+ /* use parent numa_node */
+ if (parent) {
+ set_dev_node(dev, dev_to_node(parent));
+ }
+
/* first, register with generic layer. */
kobject_set_name(dev-kobj, %s, dev-bus_id);
error = kobject_add(dev-kobj);
@@ -1269,8 +1274,11 @@ int device_move(struct device *dev, struct device
*new_parent)
dev-parent = new_parent;
if (old_parent)
klist_remove(dev-knode_parent);
- if (new_parent)
+ if (new_parent) {
klist_add_tail(dev-knode_parent, new_parent-klist_children);
+ set_dev_node(dev, dev_to_node(new_parent));
+ }
+
if (!dev-class)
goto out_put;
error = device_move_class_links(dev, old_parent, new_parent);
@@ -1280,9 +1288,12 @@ int device_move(struct device *dev, struct device
*new_parent)
if (!kobject_move(dev-kobj, old_parent-kobj)) {
if (new_parent)
klist_remove(dev-knode_parent);
- if (old_parent)
+ dev-parent = old_parent;
+ if (old_parent) {
klist_add_tail(dev-knode_parent,
old_parent-klist_children);
+ set_dev_node(dev, dev_to_node(old_parent));
+ }
}
put_device(new_parent);
goto out;
-
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
[PATCH] crash in 2.6.22-git2 sysctl_set_parent()
This is a patch ( bug report) for a crash in sysctl_set_parent()
in 2.6.22-git2.
Problem: 2.6.22-git2 crashes with a stack trace
[c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
[c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
[c1d0fc30] c065e710 .devinet_init+0x88/0xb0
[c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
[c1d0fd70] c065deec .ip_init+0x10/0x34
[c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
[c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
A bit of poking around makes it clear what the problem is:
In sysctl_set_parent(), the for loop
for (; table-ctl_name || table-procname; table++) {
walks off the end of the table, and into garbage. Basically,
this for-loop iterator expects all table arrays to be
null terminated. However, net/ipv4/devinet.c statically
declares an array that is not null-terminated. The patch
below fixes that; it works for me. Its somewhat conservative;
if one wishes to assume that the compiler will always zero out
the empty parts of the structure, then this pach can be shrunk
to one line: + ctl_table devinet_root_dir[3];
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
I tried to audit some of the code to see where else there
might be similar badly-formed static declarations. This is hard,
as there's a lot of code. Most seems fine.
net/core/neighbour.c |4
net/ipv4/devinet.c |7 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
Index: linux-2.6.22-git2/net/ipv4/devinet.c
===
--- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.0
-0500
+++ linux-2.6.22-git2/net/ipv4/devinet.c2007-07-13 14:24:15.0
-0500
@@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
- ctl_table devinet_root_dir[2];
+ ctl_table devinet_root_dir[3];
} devinet_sysctl = {
.devinet_vars = {
DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, forwarding,
@@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
.data = ipv4_devconf.loop,
.maxlen = sizeof(int),
.mode = 0644,
+ .child = 0x0,
.proc_handler = proc_dointvec,
},
+ {
+ .ctl_name = 0,
+ .procname = 0,
+ },
},
};
-
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: [dm-devel] Re: [2.6.23 PATCH 13/18] dm: netlink
On Thu, 12 Jul 2007 19:00:59 PDT, Mike Anderson said: No, all admin tools and interfaces function as they do today. The dm-netlink patch series only contains 9 deletions (actual just one true deletion of existing kernel code the others are due to break up of the patch into compilable chunks). The intent was not to break users or force migration. OK, I'll bite - if the admin tools function as before, who is *using* the code? Or do the admin tools have a preferred netlink component and a fallback set of code if that fails? pgpNP3lE0pyDp.pgp Description: PGP signature
Re: [PATCH 2.6.22-rc7] 8139cp: dev-tx_timeout
[EMAIL PROTECTED] [EMAIL PROTECTED] : [...] Can you test this one, this time it's made against the netdev-2.6 version. There indeed is a slight offset in the line numbers. It still fails. Fixed version follow. -- Ueimor - 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
[PATCH 1/1] 8139cp: implement the missing dev-tx_timeout
Signed-off-by: Mika Lansirinne [EMAIL PROTECTED]
---
drivers/net/8139cp.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 807e699..e970e64 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -26,7 +26,6 @@
TODO:
* Test Tx checksumming thoroughly
- * Implement dev-tx_timeout
Low priority TODO:
* Complete reset on PciErr
@@ -1218,6 +1217,30 @@ static int cp_close (struct net_device *dev)
return 0;
}
+static void cp_tx_timeout(struct net_device *dev)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ printk(KERN_WARNING %s: Transmit timeout, status %2x %4x %4x %4x\n,
+ dev-name, cpr8(Cmd), cpr16(CpCmd),
+ cpr16(IntrStatus), cpr16(IntrMask));
+
+ spin_lock_irqsave(cp-lock, flags);
+
+ cp_stop_hw(cp);
+ cp_clean_rings(cp);
+ rc = cp_init_rings(cp);
+ cp_start_hw(cp);
+
+ netif_wake_queue(dev);
+
+ spin_unlock_irqrestore(cp-lock, flags);
+
+ return;
+}
+
#ifdef BROKEN
static int cp_change_mtu(struct net_device *dev, int new_mtu)
{
@@ -1920,10 +1943,8 @@ static int cp_init_one (struct pci_dev *pdev, const
struct pci_device_id *ent)
dev-change_mtu = cp_change_mtu;
#endif
dev-ethtool_ops = cp_ethtool_ops;
-#if 0
dev-tx_timeout = cp_tx_timeout;
dev-watchdog_timeo = TX_TIMEOUT;
-#endif
#if CP_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
--
1.5.2.1
-
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: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)
Jeff Garzik wrote: Kok, Auke wrote: I would strongly vote for taking a stripped down e1000new then, mask out all the pci id's except ich9, remove all code for pre-pci-e silicon and remove the most annoying and needlessly complexing code like the semi-implemented multiqueue code that is in there. I'm fine for that as a path forward. I would think that would zap a lot of the hooks. How we are going to improve the internal api then can subsequently be done upstream in steps: implement using phylib, reorganize the code. This would give the community a view on the progress. I fear that if I spend yet another 2 months offline working on making a minimal ich9 driver I will lose even more time and patience: Even though the current driver (with pre-pci-e stripped) might not be as nice as you want, at least we can work together on it. I would rather go with something I know that works, isn't too bad, and we have time and start reviewing upstream immediately. minimal ich9 driver is more a metaphor, describing the seed from which a clean driver would logically grow: imagine a minimal ich9 driver, then add TSO, add support for other PCI-e phys, etc. Whether you do this exercise in your head or on the computer makes no difference, as long as you can see what the end result should look like. Not asking for yet another driver... Start with e1000new or whatever base you like. Post driver for review, get feedback, update, lather, rinse, repeat. If we're all responsive, it should not take long at all to get something upstream-mergeable. Solve the big potato issues especially :) Agreed. All current e1000 pci-e hardware is based on the same mac, so it's the logical split. The differences are PHYs and manageability, but OK Sorry for not replying to this earlier (I was on vacation for 2 days). We had some internal discussions and all the noses appear to be facing in the proper direction. I'm very happy with this and it will be my highest priority to make this work. I will attempt to get a quick start on this and come with a start point driver as soon as I can. Thanks to everyones who commented! Auke - 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: d80211 deadlock with wpa_supplicant and rmmod
On Fri, 2007-07-13 at 13:05 +0100, seventh guardian wrote: Hello, sorry for the delay but I only managed to try it out today.. I've applied the patch and tortured the system as far as I could, and no hang at all :) I've read the thread and it apparently replaces one bad problem for a lesser one, so I understand if it's not applied.. But at least there is a place in the code to point as the culprit :) It definitely should be applied anyway :) I guess John just hasn't caught up with all threads yet. John: This is about the patch in the mac80211/bcm43xx deadlock thread from Michael, it kills some rtnl_lock()/unlock() that causes this deadlock. johannes signature.asc Description: This is a digitally signed message part
Re: TCP stalls in current git, possibly splice related
On Fri, 2007-07-13 at 13:05 +0200, Jens Axboe wrote: On Fri, Jul 13 2007, Johannes Berg wrote: On Thu, 2007-07-12 at 16:12 -0400, James Morris wrote: I'm seeing TCP connection stalls with current git, and a bisect found the following as a possible cause: I'm also seeing stalls with synergy. Please try the below. Thanks. I already had your mail in the other part of the thread marked, I'll give it a try on Monday or Tuesday; I'm away from the setup where I always see the problem right now. johannes signature.asc Description: This is a digitally signed message part
Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)
Kok, Auke wrote: Sorry for not replying to this earlier (I was on vacation for 2 days). We had some internal discussions and all the noses appear to be facing in the proper direction. I'm very happy with this and it will be my highest priority to make this work. I will attempt to get a quick start on this and come with a start point driver as soon as I can. Thanks to everyones who commented! Sounds good to me. My only further comment would be to agree and encourage posting of quick-start soon. Don't worry about much beyond it works tests before posting the first public version. We'll inevitably need a couple more minor revisions before merging, as with all new drivers. We all seem to be going in the right direction, so the process should not take months. I'll make it a priority to review each revision as soon as possible. Jeff - 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: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)
Jeff Garzik wrote: Kok, Auke wrote: Sorry for not replying to this earlier (I was on vacation for 2 days). We had some internal discussions and all the noses appear to be facing in the proper direction. I'm very happy with this and it will be my highest priority to make this work. I will attempt to get a quick start on this and come with a start point driver as soon as I can. Thanks to everyones who commented! Sounds good to me. My only further comment would be to agree and encourage posting of quick-start soon. Don't worry about much beyond it works tests before posting the first public version. We'll inevitably need a couple more minor revisions before merging, as with all new drivers. We all seem to be going in the right direction, so the process should not take months. I'll make it a priority to review each revision as soon as possible. absolutely. I personally hope to have a draft ich9 version next week ready. Let's see if I make that - a lot of people would be happy to get it that soon ;) Auke - 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: [PATCH 2.6.22 1/4]S2IO: Adding checks to check the return value of pci mapping function
Veena Parat [EMAIL PROTECTED] :
- Adding checks to check the return value of pci mapping function
Signed-off-by: Veena Parat [EMAIL PROTECTED]
---
diff -Nurp 2.0.23.1/drivers/net/s2io.c 2.0.23.1P1/drivers/net/s2io.c
--- 2.0.23.1/drivers/net/s2io.c 2007-07-03 08:54:02.0 -0700
+++ 2.0.23.1P1/drivers/net/s2io.c 2007-07-03 11:39:24.0 -0700
[...]
@@ -2236,10 +2237,19 @@ static int fill_rxd_3buf(struct s2io_nic
(nic-pdev, skb-data, l3l4hdr_size + 4,
PCI_DMA_FROMDEVICE);
+ if struct RxD3*)rxdp)-Buffer1_ptr == 0) ||
+ (((struct RxD3*)rxdp)-Buffer1_ptr == DMA_ERROR_CODE)) {
^^
It does not seem to compile against current git kernel.
@@ -2256,6 +2266,11 @@ static int fill_rxd_3buf(struct s2io_nic
((struct RxD3*)rxdp)-Buffer2_ptr = pci_map_single(nic-pdev,
frag_list-data, dev-mtu,
PCI_DMA_FROMDEVICE);
+ if struct RxD3*)rxdp)-Buffer2_ptr == 0) ||
+ (((struct RxD3*)rxdp)-Buffer2_ptr == DMA_ERROR_CODE)) {
+ nic-mac_control.stats_info-sw_stat.pci_map_fail_cnt++;
+ return -ENOMEM;
+ }
Please sprinkle a few 'struct RxD3 *rd = (struct RxD3 *) rxdp;' here and
there. The code will look better.
rxdp-Control_2 |= SET_BUFFER1_SIZE_3(l3l4hdr_size + 4);
rxdp-Control_2 |= SET_BUFFER2_SIZE_3(dev-mtu);
@@ -2388,6 +2403,16 @@ static int fill_rx_buffers(struct s2io_n
((struct RxD1*)rxdp)-Buffer0_ptr = pci_map_single
(nic-pdev, skb-data, size - NET_IP_ALIGN,
PCI_DMA_FROMDEVICE);
+ if struct RxD1*)rxdp)-Buffer0_ptr == 0) ||
+ (((struct RxD1*)rxdp)-Buffer0_ptr ==
+ DMA_ERROR_CODE)) {
+ nic-mac_control.stats_info-sw_stat.
+ pci_map_fail_cnt++;
+ nic-mac_control.stats_info-sw_stat.mem_freed
+ += skb-truesize;
A 'struct swStat *stats = nic-mac_control.stats_info-sw_stat;' would
not hurt either.
[...]
@@ -2644,7 +2696,8 @@ static int s2io_poll(struct net_device *
for (i = 0; i config-rx_ring_num; i++) {
if (fill_rx_buffers(nic, i) == -ENOMEM) {
- DBG_PRINT(INFO_DBG, %s:Out of memory, dev-name);
+ DBG_PRINT(INFO_DBG, %s - %s:Out of memory,
+ __FUNCTION__, dev-name);
DBG_PRINT(INFO_DBG, in Rx Poll!!\n);
break;
}
@@ -2661,7 +2714,8 @@ no_rx:
for (i = 0; i config-rx_ring_num; i++) {
if (fill_rx_buffers(nic, i) == -ENOMEM) {
- DBG_PRINT(INFO_DBG, %s:Out of memory, dev-name);
+ DBG_PRINT(INFO_DBG, %s - %s:Out of memory,
+ __FUNCTION__, dev-name);
DBG_PRINT(INFO_DBG, in Rx Poll!!\n);
break;
}
@@ -2711,7 +2765,8 @@ static void s2io_netpoll(struct net_devi
for (i = 0; i config-rx_ring_num; i++) {
if (fill_rx_buffers(nic, i) == -ENOMEM) {
- DBG_PRINT(INFO_DBG, %s:Out of memory, dev-name);
+ DBG_PRINT(INFO_DBG, %s - %s:Out of memory,
+ __FUNCTION__, dev-name);
DBG_PRINT(INFO_DBG, in Rx Netpoll!!\n);
break;
}
Unrelated changes.
@@ -2792,24 +2847,27 @@ static void rx_intr_handler(struct ring_
HEADER_SNAP_SIZE,
PCI_DMA_FROMDEVICE);
} else if (nic-rxd_mode == RXD_MODE_3B) {
- pci_dma_sync_single_for_cpu(nic-pdev, (dma_addr_t)
+ pci_unmap_single(nic-pdev, (dma_addr_t)
((struct RxD3*)rxdp)-Buffer0_ptr,
BUF0_LEN, PCI_DMA_FROMDEVICE);
pci_unmap_single(nic-pdev, (dma_addr_t)
+ ((struct RxD3*)rxdp)-Buffer1_ptr,
+ BUF1_LEN, PCI_DMA_FROMDEVICE);
+ pci_unmap_single(nic-pdev, (dma_addr_t)
((struct RxD3*)rxdp)-Buffer2_ptr,
dev-mtu + 4,
PCI_DMA_FROMDEVICE);
} else {
- pci_dma_sync_single_for_cpu(nic-pdev, (dma_addr_t)
- ((struct RxD3*)rxdp)-Buffer0_ptr,
BUF0_LEN,
- PCI_DMA_FROMDEVICE);
pci_unmap_single(nic-pdev, (dma_addr_t)
- ((struct
Re: PATCH 2.6.22 3/4]S2IO: Removing 3 buffer mode support from the driver
Veena Parat [EMAIL PROTECTED] : - Removed 3 buffer mode support from driver - unused feature Please make it the first patch in the serie. It will avoid modifying fill_rxd_3buf() needlessly in the previous patches. -- Ueimor - 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: [PATCH 2.6.22 4/4]S2IO: Implementing review comments from old patches
Veena Parat [EMAIL PROTECTED] :
Implementation of review comments
- Incorporated Jeff Garzik's comments on coding standards
- Incorporated Andreas Schwab's comments on redundant condition check
Signed-off-by: Veena Parat [EMAIL PROTECTED]
[...]
diff -Nurp 2.0.23.1P3/drivers/net/s2io.h 2.0.23.1P4/drivers/net/s2io.h
--- 2.0.23.1P3/drivers/net/s2io.h 2007-07-03 23:58:40.0 -0700
+++ 2.0.23.1P4/drivers/net/s2io.h 2007-07-04 02:54:29.0 -0700
@@ -464,7 +464,7 @@ struct TxD {
#define TXD_LIST_OWN_XENA BIT(7)
#define TXD_T_CODE (BIT(12)|BIT(13)|BIT(14)|BIT(15))
#define TXD_T_CODE_OK(val) (|(val TXD_T_CODE))
-#define GET_TXD_T_CODE(val) ((val TXD_T_CODE)12)
+#define GET_TXD_T_CODE(val) ((val TXD_T_CODE) 48)
#define TXD_GATHER_CODE (BIT(22) | BIT(23))
#define TXD_GATHER_CODE_FIRST BIT(22)
#define TXD_GATHER_CODE_LASTBIT(23)
@@ -503,6 +503,7 @@ struct RxD_t {
u64 Control_1;
#define RXD_OWN_XENABIT(7)
#define RXD_T_CODE (BIT(12)|BIT(13)|BIT(14)|BIT(15))
+#define GET_RXD_T_CODE(val) ((val RXD_T_CODE) 48)
#define RXD_FRAME_PROTO vBIT(0x,24,8)
#define RXD_FRAME_PROTO_IPV4BIT(27)
#define RXD_FRAME_PROTO_IPV6BIT(28)
I must be more dense than usual tonight but it does not seem related to
the description of the patch.
--
Ueimor
-
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: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Fri, 13 Jul 2007 15:05:15 -0500
This is a patch ( bug report) for a crash in sysctl_set_parent()
in 2.6.22-git2.
Problem: 2.6.22-git2 crashes with a stack trace
[c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
[c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
[c1d0fc30] c065e710 .devinet_init+0x88/0xb0
[c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
[c1d0fd70] c065deec .ip_init+0x10/0x34
[c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
[c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
A bit of poking around makes it clear what the problem is:
In sysctl_set_parent(), the for loop
for (; table-ctl_name || table-procname; table++) {
walks off the end of the table, and into garbage. Basically,
this for-loop iterator expects all table arrays to be
null terminated. However, net/ipv4/devinet.c statically
declares an array that is not null-terminated. The patch
below fixes that; it works for me. Its somewhat conservative;
if one wishes to assume that the compiler will always zero out
the empty parts of the structure, then this pach can be shrunk
to one line: +ctl_table devinet_root_dir[3];
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Thanks for tracking this down, I'll apply your patch.
-
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
ANNOUNCE: igb: Intel 82575 Gigabit Ethernet driver (PCI-Express)
All, We are pleased to announce a new Gigabit Ethernet product and its driver to the linux community. This product is the Intel(R) 82575 Gigabit Ethernet adapter family. Physical adapters will be available to the public soon. These adapters come in 2- and 4-port versions (copper PHY) currently. Other variants will be available later. The 82575 chipset supports significantly different features that warrant a new driver. The descriptor format is (just like the ixgbe driver) different. The device can use multiple MSI-X vectors and multiple queues for both send and receive. This allows us to optimize some of the driver code specifically as well compared to the e1000-supported devices. This driver was forked from e1000 several months ago and extensively reworked and cleaned up since. The driver was also tested on several platforms in our validation labs. Allthough some of the codebase is currently shared with the e1000 driver (this igb driver has a copy of that code where needed), we realize that many of the changes that we are discussing for e1000 (the pci-express adapters that e1000 supports particularly) will also apply to this driver. However, since this is a completely new driver that is relatively free of all old NIC support, we feel that it is currently the right time to post this driver. Unfortunately, the patch to insert this driver is too large to send to netdev. I have therefore posted the patch on http: http://foo-projects.org/~sofar/igb.patch [558K] http://foo-projects.org/~sofar/igb.patch.bz2 [98K] And also put up the patch in a git tree for those who want to pull: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.6 igb Please review and provide comments! Current issues: There are several discussions ongoing about multiqueue and NAPI that also apply to this driver, so several TODO items already exist (remove fake netdevs for instance). As we get to these issues with the new e1000e and ixgbe driver, we will try to address them in this igb driver as well, but feel free to raise them early and now as well. Thanks, Auke Kok - 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
[PATCH] zd1211rw: Add ID for Planex GW-US54GXS
From: Masakazu Mokuno [EMAIL PROTECTED]
This patch adds the ID for Planex GW-US54GXS USB wireless adapter sold in
Japan.
Since this device returns the regulatory region as 0x49,
the patch 'Allow channels 1-11 for unrecognised regulatory domains' is
required.
Tested by Masakazu Mokuno
zd1211b chip 2019:5303 v4810 high 00-90-cc AL2230_RF pa0 ---N-
Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED]
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/zd_usb.c b/zd_usb.c
index 1e9c9ce..95c99a7 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -72,6 +72,7 @@ static struct usb_device_id usb_ids[] = {
{ USB_DEVICE(0x0586, 0x3413), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0053, 0x5301), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0411, 0x00da), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x2019, 0x5303), .driver_info = DEVICE_ZD1211B },
/* Driverless devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
{ USB_DEVICE(0x0ace, 0x20ff), .driver_info = DEVICE_INSTALLER },
--
1.5.2.2
-
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
[PATCH] zd1211rw: Add ID for Siemens Gigaset USB Stick 54
Tested by David Santinoli
zd1211b chip 129b:1667 v4810 high 00-01-e3 AL2230S_RF pa0 ---N-
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Index: linux/drivers/net/wireless/zd1211rw/zd_usb.c
===
--- linux.orig/drivers/net/wireless/zd1211rw/zd_usb.c
+++ linux/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -73,6 +73,7 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x0053, 0x5301), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0411, 0x00da), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x2019, 0x5303), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x129b, 0x1667), .driver_info = DEVICE_ZD1211B },
/* Driverless devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
{ USB_DEVICE(0x0ace, 0x20ff), .driver_info = DEVICE_INSTALLER },
-
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: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
Hi,
I'm totally confuzed by this patch ...
On 7/14/07, Linas Vepstas [EMAIL PROTECTED] wrote:
This is a patch ( bug report) for a crash in sysctl_set_parent()
in 2.6.22-git2.
Are you sure you saw this crash on 22-git2 (Linus' tree) ???
Problem: 2.6.22-git2 crashes with a stack trace
[c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
[c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
[c1d0fc30] c065e710 .devinet_init+0x88/0xb0
[c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
[c1d0fd70] c065deec .ip_init+0x10/0x34
[c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
[c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
Please post the full dmesg output, if possible.
A bit of poking around makes it clear what the problem is:
In sysctl_set_parent(), the for loop
for (; table-ctl_name || table-procname; table++) {
Yup, but note that the table there is a struct ctl_table * ...
walks off the end of the table, and into garbage. Basically,
this for-loop iterator expects all table arrays to be
null terminated. However, net/ipv4/devinet.c statically
declares an array that is not null-terminated.
Whereas the not null-terminated array you're talking about
in devinet.c is a struct devinet_sysctl_table, whose *members*
are ctl_table structs.
Also note that all those members have already been declared
as arrays: struct ctl_table xxx[2]; *precisely* because the
second element (which is left un-initialized, hence will get
zeroed-out being static) is what will protect us from running
out into garbage in sysctl_set_parent().
The patch
below fixes that; it works for me.
Now I'm even more confuzed ...
Its somewhat conservative;
if one wishes to assume that the compiler will always zero out
the empty parts of the structure,
You can always safely assume that.
Off-topic, but note that unintialized static variables being automagically
initialized to zero / NULL is guaranteed by C (the language) itself, so
nothing left in the hands of compiler implementations here. [6.7.8:10]
then this pach can be shrunk
to one line: + ctl_table devinet_root_dir[3];
But that's pointless. It was already [2] for the reason I mentioned.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
[...]
net/core/neighbour.c |4
net/ipv4/devinet.c |7 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
Weirder. diffstat does not match the patch ...
Index: linux-2.6.22-git2/net/ipv4/devinet.c
===
--- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.0
-0500
+++ linux-2.6.22-git2/net/ipv4/devinet.c2007-07-13 14:24:15.0
-0500
@@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
- ctl_table devinet_root_dir[2];
+ ctl_table devinet_root_dir[3];
} devinet_sysctl = {
.devinet_vars = {
DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, forwarding,
@@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
And Linus' latest -git doesn't even have this stuff at line 1493.
.data = ipv4_devconf.loop,
.maxlen = sizeof(int),
.mode = 0644,
+ .child = 0x0,
.proc_handler = proc_dointvec,
},
+ {
+ .ctl_name = 0,
+ .procname = 0,
+ },
},
};
Well, as I said, I'm totally confuzed ...
Satyam
-
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: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
[EMAIL PROTECTED] (Linas Vepstas) writes:
This is a patch ( bug report) for a crash in sysctl_set_parent()
in 2.6.22-git2.
Problem: 2.6.22-git2 crashes with a stack trace
[c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
[c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
[c1d0fc30] c065e710 .devinet_init+0x88/0xb0
[c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
[c1d0fd70] c065deec .ip_init+0x10/0x34
[c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
[c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
A bit of poking around makes it clear what the problem is:
In sysctl_set_parent(), the for loop
for (; table-ctl_name || table-procname; table++) {
walks off the end of the table, and into garbage. Basically,
this for-loop iterator expects all table arrays to be
null terminated. However, net/ipv4/devinet.c statically
declares an array that is not null-terminated. The patch
below fixes that; it works for me. Its somewhat conservative;
if one wishes to assume that the compiler will always zero out
the empty parts of the structure, then this pach can be shrunk
to one line: +ctl_table devinet_root_dir[3];
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
I tried to audit some of the code to see where else there
might be similar badly-formed static declarations. This is hard,
as there's a lot of code. Most seems fine.
Right. I believe I performed a similar audit not to long ago
when everything was converted to C99 initializers and everything
was fine then.
net/core/neighbour.c |4
net/ipv4/devinet.c |7 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
Index: linux-2.6.22-git2/net/ipv4/devinet.c
===
--- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.0
-0500
+++ linux-2.6.22-git2/net/ipv4/devinet.c 2007-07-13 14:24:15.0 -0500
@@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
- ctl_table devinet_root_dir[2];
+ ctl_table devinet_root_dir[3];
} devinet_sysctl = {
.devinet_vars = {
DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, forwarding,
@@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
.data = ipv4_devconf.loop,
.maxlen = sizeof(int),
.mode = 0644,
+ .child = 0x0,
.proc_handler = proc_dointvec,
},
Where did this entry above in devinet_sysctl come from?
+ {
+ .ctl_name = 0,
+ .procname = 0,
+ },
I probably would have just done:
+ {},
},
};
What added the additional entry to devinet_root_dir? I don't see that
in Linus' tree?
The result may be fine but if it isn't named in a per network device
manner we are adding duplicate entries to the root /proc/sys directory
which is wrong.
Actually come to think of it I am concerned that someone added a
settable entry into /proc/sys/ it should at least be in /proc/sys/net/
where it won't conflict with other uses of that directory. Especially
as things like network devices have user controlled names.
Eric
-
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
[NET]: Add ethtool support for NETIF_F_IPV6_CSUM devices.
[NET]: Add ethtool support for NETIF_F_IPV6_CSUM devices.
Add ethtool utility function to set or clear IPV6_CSUM feature flag.
Modify tg3.c and bnx2.c to use this function when doing ethtool -K
to change tx checksum.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 4e5e1cb..d23861c 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6218,7 +6218,7 @@ bnx2_set_tx_csum(struct net_device *dev, u32 data)
struct bnx2 *bp = netdev_priv(dev);
if (CHIP_NUM(bp) == CHIP_NUM_5709)
- return (ethtool_op_set_tx_hw_csum(dev, data));
+ return (ethtool_op_set_tx_ipv6_csum(dev, data));
else
return (ethtool_op_set_tx_csum(dev, data));
}
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 32e4037..5ee1476 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8318,7 +8318,7 @@ static int tg3_set_tx_csum(struct net_device *dev, u32
data)
if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5755 ||
GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5787)
- ethtool_op_set_tx_hw_csum(dev, data);
+ ethtool_op_set_tx_ipv6_csum(dev, data);
else
ethtool_op_set_tx_csum(dev, data);
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index f2d248f..3a63224 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -265,6 +265,7 @@ u32 ethtool_op_get_link(struct net_device *dev);
u32 ethtool_op_get_tx_csum(struct net_device *dev);
int ethtool_op_set_tx_csum(struct net_device *dev, u32 data);
int ethtool_op_set_tx_hw_csum(struct net_device *dev, u32 data);
+int ethtool_op_set_tx_ipv6_csum(struct net_device *dev, u32 data);
u32 ethtool_op_get_sg(struct net_device *dev);
int ethtool_op_set_sg(struct net_device *dev, u32 data);
u32 ethtool_op_get_tso(struct net_device *dev);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 8d5e5a0..0b531e9 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -52,6 +52,17 @@ int ethtool_op_set_tx_hw_csum(struct net_device *dev, u32
data)
return 0;
}
+
+int ethtool_op_set_tx_ipv6_csum(struct net_device *dev, u32 data)
+{
+ if (data)
+ dev-features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+ else
+ dev-features = ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
+
+ return 0;
+}
+
u32 ethtool_op_get_sg(struct net_device *dev)
{
return (dev-features NETIF_F_SG) != 0;
@@ -980,5 +991,6 @@ EXPORT_SYMBOL(ethtool_op_set_sg);
EXPORT_SYMBOL(ethtool_op_set_tso);
EXPORT_SYMBOL(ethtool_op_set_tx_csum);
EXPORT_SYMBOL(ethtool_op_set_tx_hw_csum);
+EXPORT_SYMBOL(ethtool_op_set_tx_ipv6_csum);
EXPORT_SYMBOL(ethtool_op_set_ufo);
EXPORT_SYMBOL(ethtool_op_get_ufo);
-
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
[2.6 patch] cleanup congestion control options
This patch contains the following cleanups: - note in the prompt if an option depends on EXPERIMENTAL - remove default ns that didn't have any effect - remove default ms from options under TCP_CONG_ADVANCED: if you manually choose congestion control modules you should know which ones you want Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- net/ipv4/Kconfig | 27 --- 1 file changed, 8 insertions(+), 19 deletions(-) --- linux-2.6.22-rc6-mm1/net/ipv4/Kconfig.old 2007-07-13 11:00:22.0 +0200 +++ linux-2.6.22-rc6-mm1/net/ipv4/Kconfig 2007-07-13 11:07:34.0 +0200 @@ -423,7 +423,6 @@ config TCP_CONG_BIC tristate Binary Increase Congestion (BIC) control - default m ---help--- BIC-TCP is a sender-side only change that ensures a linear RTT fairness under large windows while offering both scalability and @@ -445,7 +444,6 @@ config TCP_CONG_WESTWOOD tristate TCP Westwood+ - default m ---help--- TCP Westwood+ is a sender-side only modification of the TCP Reno protocol stack that optimizes the performance of TCP congestion @@ -459,7 +457,6 @@ config TCP_CONG_HTCP tristate H-TCP -default m ---help--- H-TCP is a send-side only modifications of the TCP Reno protocol stack that optimizes the performance of TCP @@ -469,9 +466,8 @@ other Reno and H-TCP flows. config TCP_CONG_HSTCP - tristate High Speed TCP + tristate High Speed TCP (EXPERIMENTAL) depends on EXPERIMENTAL - default n ---help--- Sally Floyd's High Speed TCP (RFC 3649) congestion control. A modification to TCP's congestion control mechanism for use @@ -480,9 +476,8 @@ For more detail see http://www.icir.org/floyd/hstcp.html config TCP_CONG_HYBLA - tristate TCP-Hybla congestion control algorithm + tristate TCP-Hybla congestion control algorithm (EXPERIMENTAL) depends on EXPERIMENTAL - default n ---help--- TCP-Hybla is a sender-side only change that eliminates penalization of long-RTT, large-bandwidth connections, like when satellite legs are @@ -490,9 +485,8 @@ terrestrial connections. config TCP_CONG_VEGAS - tristate TCP Vegas + tristate TCP Vegas (EXPERIMENTAL) depends on EXPERIMENTAL - default n ---help--- TCP Vegas is a sender-side only change to TCP that anticipates the onset of congestion by estimating the bandwidth. TCP Vegas @@ -501,9 +495,8 @@ not as aggressive as TCP Reno. config TCP_CONG_SCALABLE - tristate Scalable TCP + tristate Scalable TCP (EXPERIMENTAL) depends on EXPERIMENTAL - default n ---help--- Scalable TCP is a sender-side only change to TCP which uses a MIMD congestion control algorithm which has some nice scaling @@ -511,9 +504,8 @@ See http://www.deneholme.net/tom/scalable/ config TCP_CONG_LP - tristate TCP Low Priority + tristate TCP Low Priority (EXPERIMENTAL) depends on EXPERIMENTAL - default n ---help--- TCP Low Priority (TCP-LP), a distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the @@ -521,9 +513,8 @@ See http://www-ece.rice.edu/networks/TCP-LP/ config TCP_CONG_VENO - tristate TCP Veno + tristate TCP Veno (EXPERIMENTAL) depends on EXPERIMENTAL - default n ---help--- TCP Veno is a sender-side only enhancement of TCP to obtain better throughput over wireless networks. TCP Veno makes use of state @@ -533,10 +524,9 @@ See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf config TCP_CONG_YEAH - tristate YeAH TCP + tristate YeAH TCP (EXPERIMENTAL) depends on EXPERIMENTAL select TCP_CONG_VEGAS - default n ---help--- YeAH-TCP is a sender-side high-speed enabled TCP congestion control algorithm, which uses a mixed loss/delay approach to compute the @@ -548,9 +538,8 @@ http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf config TCP_CONG_ILLINOIS - tristate TCP Illinois + tristate TCP Illinois (EXPERIMENTAL) depends on EXPERIMENTAL - default n ---help--- TCP-Illinois is a sender-side modificatio of TCP Reno for high speed long delay links. It uses round-trip-time to - 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: [2.6 patch] eepro100 resume patch
[adding netdev]
David Fries wrote:
When I did a software suspend to disk then resumed the Intel network
card using eepro100 driver would be unable to transmit packets. I
tracked this down and found a register write after the print message
DP83840 specific setup which wasn't being executed when the system
was restored. This fix moves that write and another write which
forces the link speed and duplex.
After doing this work and preparing the patch I checked out the
mailing list only to find a patch that removes the eepro100. I then
updated Kconfig, though I wonder why it didn't have a similar message
in it long time ago.
I too had tried the e100 driver some time ago and it didn't work,
That argument is pretty useless right now. Please *test* e100 and *report
issues*. I recently did some very intensive suspend/resume testing (and fixes)
on e100 and I have yet to hear of any problems with it since... that was 2.6.18
or so even.
eepro100 did and I've been using it so long that I've almost forgotten
about that. I just gave the e100 driver a try and I've been running
for about an hour now without any problems and it does resume after a
suspend to disk operation.
Signed-off-by: David Fries [EMAIL PROTECTED]
I don't think I need to NAK this. I doubt that Jeff Garzik will apply this in
the first place. eepro100 is on it's way out, so let's focus on what matters.
Auke
Index: drivers/net/Kconfig
===
RCS file:
/home/david/kernel/k/spacedout/patches/linux/drivers/net/Attic/Kconfig,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 Kconfig
--- drivers/net/Kconfig 13 Jul 2007 23:16:36 - 1.1.2.1
+++ drivers/net/Kconfig 13 Jul 2007 23:31:29 -
@@ -1467,6 +1467,11 @@
depends on NET_PCI PCI
select MII
help
+ ** Warning ** eepro100 (this driver) has been requested to be
+ removed from the kernel source tree. Please use e100 and report
+ any bugs as that is the driver that will be supported going
+ forward.
+
If you have an Intel EtherExpress PRO/100 PCI network (Ethernet)
card, say Y and read the Ethernet-HOWTO, available from
http://www.tldp.org/docs.html#howto.
Index: drivers/net/eepro100.c
===
RCS file: /home/david/kernel/k/spacedout/patches/linux/drivers/net/eepro100.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- drivers/net/eepro100.c 10 Jul 2007 23:56:54 - 1.4
+++ drivers/net/eepro100.c 13 Jul 2007 22:10:16 - 1.5
@@ -446,6 +446,7 @@
unsigned short partner; /* Link partner caps. */
struct mii_if_info mii_if; /* MII API hooks, info */
u32 msg_enable; /* debug message level */
+ int option; /* Module options for this card
*/
};
/* The parameters for a CmdConfigure operation.
@@ -717,6 +718,8 @@
/* we must initialize this early, for mdio_{read,write} */
sp-regs = ioaddr;
+ /* store override options for later use. */
+ sp-option = option;
#if 1 || defined(kernel_bloat)
/* OK, this is pure kernel bloat. I don't like it when other drivers
@@ -743,20 +746,22 @@
phys[(eeprom[7]8)7]);
if (((eeprom[6]8) 0x3f) == DP83840
|| ((eeprom[6]8) 0x3f) == DP83840A) {
- int mdi_reg23 = mdio_read(dev, eeprom[6] 0x1f, 23) |
0x0422;
+ int mdi_reg23_orig = mdio_read(dev, eeprom[6] 0x1f,
23);
+ int mdi_reg23 = mdi_reg23_orig | 0x0422;
if (congenb)
mdi_reg23 |= 0x0100;
- printk(KERN_INFO DP83840 specific setup, setting register
23 to %4.4x.\n,
- mdi_reg23);
- mdio_write(dev, eeprom[6] 0x1f, 23, mdi_reg23);
+ /* Print the message here, write in speedo_resume, which
+* is called both on module load and from
+* eepro100_resume.
+*/
+ printk(KERN_INFO DP83840 specific setup, setting register
23 to %4.4x, was %4.4x.\n,
+ mdi_reg23, mdi_reg23_orig);
}
if ((option = 0) (option 0x70)) {
+ /* Print here, write in speedo_resume. */
printk(KERN_INFO Forcing %dMbs %s-duplex
operation.\n,
(option 0x20 ? 100 : 10),
(option 0x10 ? full : half));
- mdio_write(dev, eeprom[6] 0x1f, MII_BMCR,
- ((option 0x20) ? 0x2000 : 0) |
/* 100mbps? */
-
Re: [2.6 patch] cleanup congestion control options
On Sat, 14 Jul 2007 06:09:54 +0200, Adrian Bunk said: This patch contains the following cleanups: - note in the prompt if an option depends on EXPERIMENTAL Who decided whether a particular option is 'experimental' or not? Lawrence S. Brakmo and Larry L. Peterson. TCP Vegas: end to end congestion avoidance on a global Internet. IEEE Journal on Selected Areas in Communications, 13(8), October 1995. config TCP_CONG_VEGAS - tristate TCP Vegas + tristate TCP Vegas (EXPERIMENTAL) depends on EXPERIMENTAL I think the *right* fix here is '- depends on EXPERIMENTAL'. 1995. Geez. :) (Probably *all* of the 'experimental' tags for congestion control need an in-depth review - but Vegas struck me as particularly egregious.) pgpBt2EQzjYrW.pgp Description: PGP signature
