* Re: What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?
From: Evgeniy Polyakov @ 2007-12-14 6:33 UTC (permalink / raw)
To: Kevin Wilson; +Cc: David Miller, netdev
In-Reply-To: <B1F576FE19C55C43B8D2E31F061B50C04E60B2@exchange.comtrol.com>
Hi Kevin.
On Thu, Dec 13, 2007 at 04:00:02PM -0600, Kevin Wilson (Kevin.Wilson@comtrol.com) wrote:
> I see your point but it just so happens it is a GPL'd driver, as is all of our Linux code we produce for our hardware. Granted it is out of tree, and after you saw it you would want it to stay that way. However, I would have sent you the whole thing if that is a pre-req to cordial exchanges on this list.
>
> Nonetheless, a somewhat recent change in your tree, that I could not pinpoint on my own, caused the driver to stop functioning properly. So after much searching in git/google/sources with no luck, I decided to ask for a little assistance, maybe just a hint as to where the culprit may be in the tree so I could investigate for myself. For SNGs I tried the method that now works but I am still at a loss as to (can't find) what changes in the tree caused it to fail.
Without having your code it is virtually impossible to say, why you have
a bug. And do not express your frustration telling 'zero people
responded to my bug report'. This was not a bug report at all, but empty
message about 'my code stopped working after some network changes, which
broke the stuff.
>Now in 2.6.22 and later kernels you must use the higher level SOCKET to
>make a call to PROTO_OPS then to sendmsg(). e.g., socket->ops->sendmsg().
It was done because of bug found in inet_sendmsg(), which tried to
autobind socket it should not try.
--
Evgeniy Polyakov
^ permalink raw reply
* [BUG] Kernel Bugzilla: networking bugs
From: Natalie Protasevich @ 2007-12-14 5:19 UTC (permalink / raw)
To: netdev, David Miller
Hello,
Here are few networking bugs from bugzilla.kernel.org. Could someone
take a look please?
Thanks!
(net forcedeth) frequent network ups and downs
http://bugzilla.kernel.org/show_bug.cgi?id=9200
Kernel: 2.6.23
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
rtl8187 very unreliable (wireless)
http://bugzilla.kernel.org/show_bug.cgi?id=9143
Kernel: 2.6.23
John Linville started looking in it
Unable to associate rt25xx USB key with a WPA AP (wireless)
http://bugzilla.kernel.org/show_bug.cgi?id=9388
Kernel: 2.6.24-rc2
D-Link DWL-G122 Wifi 11b/g USB key
^ permalink raw reply
* Re: [RFC] mac80211: clean up frame receive handling
From: Jouni Malinen @ 2007-12-14 5:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Michael Wu, Tomas Winkler
In-Reply-To: <1197483844.6558.158.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Wed, Dec 12, 2007 at 07:24:04PM +0100, Johannes Berg wrote:
> This cleans up the frame receive handling. After this patch
> * EAPOL frames addressed to us or the EAPOL group address are
> always accepted regardless of whether they are encrypted or not
> * other frames from a station are dropped if PAE is enabled and
> the station is not authorized
Is there any way for an user space application to figure out whether a
received EAPOL frame was encrypted? In theory, WPA/WPA2 Authenticators
(e.g., hostapd) should verify that the frame was encrypted if pairwise
keys are set (whereas IEEE 802.1X Authenticator accepts unencrypted
EAPOL frames).
Did you/someone already verify that the Linux bridge code does not
bridge EAPOL frames? The use of a separate interface for this removed
the need for doing such filtering based on ethertype, but with EAPOL
frames using the same netdev with other data frames, the bridge code
should filter these out (mainly the PAE group addressed ones, but if I
remember correctly, IEEE 802.1X specified all frames using EAPOL
ethertype not to be bridged).
I haven't looked into the current implementations and/or proposed
patches on for TX part, but I would assume that it is possible to select
whether an EAPOL frame will be encrypted when injecting it(?).
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: use rx-clock-name and tx-clock-name device tree properties
From: Kumar Gala @ 2007-12-14 5:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev list, Timur Tabi
In-Reply-To: <1196716685975-git-send-email-timur@freescale.com>
On Dec 3, 2007, at 3:17 PM, Timur Tabi wrote:
> Updates the ucc_geth device driver to check the new rx-clock-name and
> tx-clock-name properties first. If present, it uses the new function
> qe_clock_source() to obtain the clock source. Otherwise, it checks
> the
> deprecated rx-clock and tx-clock properties.
>
> Update the device trees for 832x, 836x, and 8568 to contain the new
> property
> names only.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch applies to Kumar's for-2.6.25 branch. ucc_geth will
> compile but not
> run if my other patch, "qe: add function qe_clock_source" has not
> also been
> applied.
Jeff, I'll take this patch via powerpc.git if you don't have any issue
since its just touching probe/setup bits.
- k
> arch/powerpc/boot/dts/mpc832x_mds.dts | 8 ++--
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 8 ++--
> arch/powerpc/boot/dts/mpc836x_mds.dts | 8 ++--
> arch/powerpc/boot/dts/mpc8568mds.dts | 8 ++--
> drivers/net/ucc_geth.c | 55 ++++++++++++++++++++++++
> ++++++--
> 5 files changed, 67 insertions(+), 20 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/
> boot/dts/mpc832x_mds.dts
> index c64f303..fe54489 100644
> --- a/arch/powerpc/boot/dts/mpc832x_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
> @@ -223,8 +223,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <19>;
> - tx-clock = <1a>;
> + rx-clock-name = "clk9";
> + tx-clock-name = "clk10";
> phy-handle = < &phy3 >;
> pio-handle = < &pio3 >;
> };
> @@ -244,8 +244,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <17>;
> - tx-clock = <18>;
> + rx-clock-name = "clk7";
> + tx-clock-name = "clk8";
> phy-handle = < &phy4 >;
> pio-handle = < &pio4 >;
> };
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/
> boot/dts/mpc832x_rdb.dts
> index 388c8a7..e68a08b 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -202,8 +202,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <20>;
> - tx-clock = <13>;
> + rx-clock-name = "clk16";
> + tx-clock-name = "clk3";
> phy-handle = <&phy00>;
> pio-handle = <&ucc2pio>;
> };
> @@ -223,8 +223,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <19>;
> - tx-clock = <1a>;
> + rx-clock-name = "clk9";
> + tx-clock-name = "clk10";
> phy-handle = <&phy04>;
> pio-handle = <&ucc3pio>;
> };
> diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/
> boot/dts/mpc836x_mds.dts
> index 0b2d2b5..bfd48d0 100644
> --- a/arch/powerpc/boot/dts/mpc836x_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
> @@ -254,8 +254,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <0>;
> - tx-clock = <19>;
> + rx-clock-name = "none";
> + tx-clock-name = "clk9";
> phy-handle = < &phy0 >;
> phy-connection-type = "rgmii-id";
> pio-handle = < &pio1 >;
> @@ -276,8 +276,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <0>;
> - tx-clock = <14>;
> + rx-clock-name = "none";
> + tx-clock-name = "clk4";
> phy-handle = < &phy1 >;
> phy-connection-type = "rgmii-id";
> pio-handle = < &pio2 >;
> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/
> boot/dts/mpc8568mds.dts
> index 5439437..cf45aab 100644
> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
> @@ -333,8 +333,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <0>;
> - tx-clock = <20>;
> + rx-clock-name = "none";
> + tx-clock-name = "clk16";
> pio-handle = <&pio1>;
> phy-handle = <&phy0>;
> phy-connection-type = "rgmii-id";
> @@ -355,8 +355,8 @@
> */
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> - rx-clock = <0>;
> - tx-clock = <20>;
> + rx-clock-name = "none";
> + tx-clock-name = "clk16";
> pio-handle = <&pio2>;
> phy-handle = <&phy1>;
> phy-connection-type = "rgmii-id";
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index a3ff270..a93342e 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3814,6 +3814,7 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma
> int err, ucc_num, max_speed = 0;
> const phandle *ph;
> const unsigned int *prop;
> + const char *sprop;
> const void *mac_addr;
> phy_interface_t phy_interface;
> static const int enet_to_speed[] = {
> @@ -3846,10 +3847,56 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma
>
> ug_info->uf_info.ucc_num = ucc_num;
>
> - prop = of_get_property(np, "rx-clock", NULL);
> - ug_info->uf_info.rx_clock = *prop;
> - prop = of_get_property(np, "tx-clock", NULL);
> - ug_info->uf_info.tx_clock = *prop;
> + sprop = of_get_property(np, "rx-clock-name", NULL);
> + if (sprop) {
> + ug_info->uf_info.rx_clock = qe_clock_source(sprop);
> + if ((ug_info->uf_info.rx_clock < QE_CLK_NONE) ||
> + (ug_info->uf_info.rx_clock > QE_CLK24)) {
> + printk(KERN_ERR
> + "ucc_geth: invalid rx-clock-name property\n");
> + return -EINVAL;
> + }
> + } else {
> + prop = of_get_property(np, "rx-clock", NULL);
> + if (!prop) {
> + /* If both rx-clock-name and rx-clock are missing,
> + we want to tell people to use rx-clock-name. */
> + printk(KERN_ERR
> + "ucc_geth: missing rx-clock-name property\n");
> + return -EINVAL;
> + }
> + if ((*prop < QE_CLK_NONE) || (*prop > QE_CLK24)) {
> + printk(KERN_ERR
> + "ucc_geth: invalid rx-clock propperty\n");
> + return -EINVAL;
> + }
> + ug_info->uf_info.rx_clock = *prop;
> + }
> +
> + sprop = of_get_property(np, "tx-clock-name", NULL);
> + if (sprop) {
> + ug_info->uf_info.tx_clock = qe_clock_source(sprop);
> + if ((ug_info->uf_info.tx_clock < QE_CLK_NONE) ||
> + (ug_info->uf_info.tx_clock > QE_CLK24)) {
> + printk(KERN_ERR
> + "ucc_geth: invalid tx-clock-name property\n");
> + return -EINVAL;
> + }
> + } else {
> + prop = of_get_property(np, "rx-clock", NULL);
> + if (!prop) {
> + printk(KERN_ERR
> + "ucc_geth: mising tx-clock-name property\n");
> + return -EINVAL;
> + }
> + if ((*prop < QE_CLK_NONE) || (*prop > QE_CLK24)) {
> + printk(KERN_ERR
> + "ucc_geth: invalid tx-clock property\n");
> + return -EINVAL;
> + }
> + ug_info->uf_info.tx_clock = *prop;
> + }
> +
> err = of_address_to_resource(np, 0, &res);
> if (err)
> return -EINVAL;
> --
> 1.5.2.4
^ permalink raw reply
* Re: [PATCH] PS3: gelic: Add wireless support for PS3
From: Masakazu Mokuno @ 2007-12-14 5:07 UTC (permalink / raw)
To: Dan Williams
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
geoffrey.levand-mEdOJwZ7QcZBDgjK7y7TUQ, Geert Uytterhoeven
In-Reply-To: <1197560003.2528.36.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Thu, 13 Dec 2007 10:33:22 -0500
Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> You'll need to emit more NULL IWAP events on association failure. For
> example, gelic_wl_assoc_worker() should probably send one right before
> both instances of 'goto scan_lock_out' in that function (the first where
> there are no scan results, and the second where no compatible BSS can be
> found). Also, gelic_wl_associate_bss() needs to send a disassociation
> event in the failure case where it sets GELIC_WL_ASSOC_STAT_DISCONN.
Thank you for your reviewing.
I'll fix and submit revised version in next week.
--
Masakazu MOKUNO
^ permalink raw reply
* Re: [PATCH] PS3: gelic: Add wireless support for PS3
From: Masakazu Mokuno @ 2007-12-14 5:03 UTC (permalink / raw)
To: Dan Williams
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
geoffrey.levand-mEdOJwZ7QcZBDgjK7y7TUQ, Geert Uytterhoeven
In-Reply-To: <1197580418.14270.6.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Thu, 13 Dec 2007 16:13:38 -0500
Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> One more question; does the driver work with wpa_supplicant for WPA, or
> does the firmware capture the EAPOL frames and handle the 4 way
> handshake internally? Ideally the firmware would have the ability to
> pass those frames up unmodified so the driver would at least have a
> _hope_ of 802.1x capability. Does the firmware handle Dynamic WEP at
> all?
>
> Basically, what happens when the AP you've just associated with starts
> sending you EAPOL traffic to start the 802.1x process?
The PS3 wireless device does the association and 4way handshake in its
firmware/hypervisor. No interventions between them are allowed to the guest
OSes.
All frames which are sent/received from/to before the connection process
completed seems to be dropped by the hardware. Only the static WEP is
supported.
--
Masakazu MOKUNO
^ permalink raw reply
* Re: [PATCH 1/7] : e1000 Fix possible causing oops of net_rx_action
From: Joonwoo Park @ 2007-12-14 2:41 UTC (permalink / raw)
To: David Miller
Cc: auke-jan.h.kok, netdev, linux-kernel, jesse.brandeburg, jgarzik,
shemminger
In-Reply-To: <20071213.053354.82143565.davem@davemloft.net>
2007/12/13, David Miller <davem@davemloft.net>:
> From: "Joonwoo Park" <joonwpark81@gmail.com>
> Date: Thu, 13 Dec 2007 19:18:56 +0900
>
> > Just blowing netif_running up is not best solution I think, it makes
> > ifconfig down hang at least for e1000.
>
> It hangs because the packet receive rate is so high that NAPI
> poll never exits.
Certainly I'm aware it
>
> I think we need a cheap solution to something so obscure and
> almost not worth explicitly even coding for. Really, if you
> setup silly situations like that, you get what you asked for.
>
I can agree that we need good solution for that.
BUT I don't think I didn't setup *silly* situation. my customers who
are reporting this problem, running firewall on linux which is
forwarding packets with high rate.
I don't want to say 'don't ifconfig down, don't reboot, don't
shutdown' it would introduce problem on your such *sily* sitution'.
In addition, my laptop is just connected to another *linux* machine
which is generating 300mbps 64byte udp packets infinitely.
Joonwoo
^ permalink raw reply
* Re: 2.6.24-rc5-mm1
From: Herbert Xu @ 2007-12-14 2:08 UTC (permalink / raw)
To: David Miller; +Cc: benjamin.thery, pierre.peiffer, akpm, linux-kernel, netdev
In-Reply-To: <20071213.094554.136920553.davem@davemloft.net>
On Thu, Dec 13, 2007 at 09:45:54AM -0800, David Miller wrote:
> From: Benjamin Thery <benjamin.thery@bull.net>
> Date: Thu, 13 Dec 2007 16:01:34 +0100
>
> > The problem comes from the new macro UDPX_INC_STATS_BH introduced
> > by Herbert, which was a nice addition to increment the correct
> > UDP MIB depending on the socket family, but unfortunately
> > the use of this macro from kernel code (I mean code not compiled
> > as module) requires that IPv6 is also compiled in kernel
> > (CONFIG_IPv6=y) in order to have udp_stats_in6 defined at link
> > time.
>
> Herbert, please take a look at this, thanks!
OK, let's just move udp_stats_in6 into net/ipv4/udp.c. It's only
40 bytes or less.
[UDP]: Move udp_stats_in6 into net/ipv4/udp.c
Now that external users may increment the counters directly, we need to
ensure that udp_stats_in6 is always available. Otherwise we'd either
have to requrie the external users to be built as modules or ipv6 to be
built-in.
This isn't too bad because udp_stats_in6 is just a pair of pointers plus
an EXPORT, e.g., just 40 (16 + 24) bytes on x86-64.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 9ed6393..3d60215 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -112,6 +112,9 @@
DEFINE_SNMP_STAT(struct udp_mib, udp_statistics) __read_mostly;
EXPORT_SYMBOL(udp_statistics);
+DEFINE_SNMP_STAT(struct udp_mib, udp_stats_in6) __read_mostly;
+EXPORT_SYMBOL(udp_stats_in6);
+
struct hlist_head udp_hash[UDP_HTABLE_SIZE];
DEFINE_RWLOCK(udp_hash_lock);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 8cbdcc9..7db5a9d 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -51,9 +51,6 @@
#include <linux/seq_file.h>
#include "udp_impl.h"
-DEFINE_SNMP_STAT(struct udp_mib, udp_stats_in6) __read_mostly;
-EXPORT_SYMBOL(udp_stats_in6);
-
static inline int udp_v6_get_port(struct sock *sk, unsigned short snum)
{
return udp_get_port(sk, snum, ipv6_rcv_saddr_equal);
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [RFC] net: napi fix
From: Joonwoo Park @ 2007-12-14 2:06 UTC (permalink / raw)
To: Andrew Gallatin
Cc: Kok, Auke, David Miller, netdev, linux-kernel, jgarzik,
shemminger, Jesse Brandeburg
In-Reply-To: <47613E22.6060705@myri.com>
2007/12/13, Andrew Gallatin <gallatin@myri.com>:
>
> If the netif_running() check is indeed required to make a device break
> out of napi polling and respond to an ifconfig down, then I think the
> netif_running() check should be moved up into net_rx_action() to avoid
> potential for driver complexity and bugs like the ones you found.
>
> Drew
>
Yep, It looks good.
Joonwoo
^ permalink raw reply
* Regression: Wireshark sees no packets in 2.6.24-rc3
From: Ray Lee @ 2007-12-14 1:46 UTC (permalink / raw)
To: netdev, LKML
tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just
fine. A quick scan of the log between 2.6.24-rc3 and current tip
(-rc5) doesn't show any obvious fixes, but then again, what do I know.
I'll check current tip on the weekend when I'll have the luxury to
have my main system down long enough for a test. Right now I'm kinda
up against a deadline, but didn't want to leave it unreported. Should
be easy for someone else to confirm or deny whether current tip has
the problem.
Ray
^ permalink raw reply
* [PATCHES 0/3]: DCCP patches for 2.6.25
From: Arnaldo Carvalho de Melo @ 2007-12-14 1:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, dccp
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.25
Best Regards,
- Arnaldo
net/dccp/ccid.c | 8 ++++----
net/dccp/ccid.h | 37 ++++++++++++++++++++++++++++++-------
net/dccp/ccids/ccid2.c | 2 +-
net/dccp/ccids/ccid3.c | 2 +-
net/dccp/output.c | 30 +++++++++++++++++++++++-------
5 files changed, 59 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH 1/3] [DCCP]: Documentation for CCID operations
From: Arnaldo Carvalho de Melo @ 2007-12-14 1:42 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, dccp, Gerrit Renker, Ian McDonald,
Arnaldo Carvalho de Melo
In-Reply-To: <1197596522-14600-1-git-send-email-acme@redhat.com>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
This adds documentation for the ccid_operations structure.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
net/dccp/ccid.h | 35 ++++++++++++++++++++++++++++-------
1 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/net/dccp/ccid.h b/net/dccp/ccid.h
index c65cb24..e3cdd8a 100644
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -23,14 +23,35 @@
struct tcp_info;
+/**
+ * struct ccid_operations - Interface to Congestion-Control Infrastructure
+ *
+ * @ccid_id: numerical CCID ID (up to %CCID_MAX, cf. table 5 in RFC 4340, 10.)
+ * @ccid_name: alphabetical identifier string for @ccid_id
+ * @ccid_owner: module which implements/owns this CCID
+ * @ccid_hc_{r,t}x_slab: memory pool for the receiver/sender half-connection
+ * @ccid_hc_{r,t}x_obj_size: size of the receiver/sender half-connection socket
+ *
+ * @ccid_hc_{r,t}x_init: CCID-specific initialisation routine (before startup)
+ * @ccid_hc_{r,t}x_exit: CCID-specific cleanup routine (before destruction)
+ * @ccid_hc_rx_packet_recv: implements the HC-receiver side
+ * @ccid_hc_{r,t}x_parse_options: parsing routine for CCID/HC-specific options
+ * @ccid_hc_{r,t}x_insert_options: insert routine for CCID/HC-specific options
+ * @ccid_hc_tx_packet_recv: implements feedback processing for the HC-sender
+ * @ccid_hc_tx_send_packet: implements the sending part of the HC-sender
+ * @ccid_hc_tx_packet_sent: does accounting for packets in flight by HC-sender
+ * @ccid_hc_{r,t}x_get_info: INET_DIAG information for HC-receiver/sender
+ * @ccid_hc_{r,t}x_getsockopt: socket options specific to HC-receiver/sender
+ */
struct ccid_operations {
- unsigned char ccid_id;
- const char *ccid_name;
- struct module *ccid_owner;
- struct kmem_cache *ccid_hc_rx_slab;
- __u32 ccid_hc_rx_obj_size;
- struct kmem_cache *ccid_hc_tx_slab;
- __u32 ccid_hc_tx_obj_size;
+ unsigned char ccid_id;
+ const char *ccid_name;
+ struct module *ccid_owner;
+ struct kmem_cache *ccid_hc_rx_slab,
+ *ccid_hc_tx_slab;
+ __u32 ccid_hc_rx_obj_size,
+ ccid_hc_tx_obj_size;
+ /* Interface Routines */
int (*ccid_hc_rx_init)(struct ccid *ccid, struct sock *sk);
int (*ccid_hc_tx_init)(struct ccid *ccid, struct sock *sk);
void (*ccid_hc_rx_exit)(struct sock *sk);
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/3] [CCID]: More informative registration
From: Arnaldo Carvalho de Melo @ 2007-12-14 1:42 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, dccp, Gerrit Renker, Ian McDonald,
Arnaldo Carvalho de Melo
In-Reply-To: <1197596522-14600-2-git-send-email-acme@redhat.com>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
The patch makes the registration messages of CCID 2/3 a bit more
informative: instead of repeating the CCID number as currently done,
"CCID: Registered CCID 2 (ccid2)" or
"CCID: Registered CCID 3 (ccid3)",
the descriptive names of the CCID's (from RFCs) are now used:
"CCID: Registered CCID 2 (TCP-like)" and
"CCID: Registered CCID 3 (TCP-Friendly Rate Control)".
To allow spaces in the name, the slab name string has been changed to
refer to the numeric CCID identifier, using the same format as before.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
net/dccp/ccid.c | 8 ++++----
net/dccp/ccids/ccid2.c | 2 +-
net/dccp/ccids/ccid3.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/dccp/ccid.c b/net/dccp/ccid.c
index c45088b..4809753 100644
--- a/net/dccp/ccid.c
+++ b/net/dccp/ccid.c
@@ -92,15 +92,15 @@ int ccid_register(struct ccid_operations *ccid_ops)
ccid_ops->ccid_hc_rx_slab =
ccid_kmem_cache_create(ccid_ops->ccid_hc_rx_obj_size,
- "%s_hc_rx_sock",
- ccid_ops->ccid_name);
+ "ccid%u_hc_rx_sock",
+ ccid_ops->ccid_id);
if (ccid_ops->ccid_hc_rx_slab == NULL)
goto out;
ccid_ops->ccid_hc_tx_slab =
ccid_kmem_cache_create(ccid_ops->ccid_hc_tx_obj_size,
- "%s_hc_tx_sock",
- ccid_ops->ccid_name);
+ "ccid%u_hc_tx_sock",
+ ccid_ops->ccid_id);
if (ccid_ops->ccid_hc_tx_slab == NULL)
goto out_free_rx_slab;
diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c
index 48eeb44..b5b52eb 100644
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -770,7 +770,7 @@ static void ccid2_hc_rx_packet_recv(struct sock *sk, struct sk_buff *skb)
static struct ccid_operations ccid2 = {
.ccid_id = DCCPC_CCID2,
- .ccid_name = "ccid2",
+ .ccid_name = "TCP-like",
.ccid_owner = THIS_MODULE,
.ccid_hc_tx_obj_size = sizeof(struct ccid2_hc_tx_sock),
.ccid_hc_tx_init = ccid2_hc_tx_init,
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
index a818a1e..876c747 100644
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -943,7 +943,7 @@ static int ccid3_hc_rx_getsockopt(struct sock *sk, const int optname, int len,
static struct ccid_operations ccid3 = {
.ccid_id = DCCPC_CCID3,
- .ccid_name = "ccid3",
+ .ccid_name = "TCP-Friendly Rate Control",
.ccid_owner = THIS_MODULE,
.ccid_hc_tx_obj_size = sizeof(struct ccid3_hc_tx_sock),
.ccid_hc_tx_init = ccid3_hc_tx_init,
--
1.5.3.4
^ permalink raw reply related
* [PATCH 3/3] [DCCP]: Introducing CCMPS
From: Arnaldo Carvalho de Melo @ 2007-12-14 1:42 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, dccp, Gerrit Renker, Ian McDonald,
Arnaldo Carvalho de Melo
In-Reply-To: <1197596522-14600-3-git-send-email-acme@redhat.com>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
This introduces a CCMPS field for setting a CCID-specific upper bound on the application payload
size, as is defined in RFC 4340, section 14.
Only the TX CCID is considered in setting this limit, since the RX CCID generates comparatively
small (DCCP-Ack) feedback packets. The CCMPS field includes network and transport layer header
lengths. The only current CCMPS customer is CCID4 (via RFC 4828).
A wrapper is used to allow querying the CCMPS even at times where the CCID modules may not have
been fully negotiated yet.
In dccp_sync_mss() the variable `mss_now' has been renamed into `cur_mps', to reflect that we are
dealing with an MPS, but not an MSS.
Since the DCCP code closely follows the TCP code, the identifiers `dccp_sync_mss' and
`dccps_mss_cache' have been kept, as they have direct TCP counterparts.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
net/dccp/ccid.h | 2 ++
net/dccp/output.c | 30 +++++++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/net/dccp/ccid.h b/net/dccp/ccid.h
index e3cdd8a..fdeae7b 100644
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -27,6 +27,7 @@ struct tcp_info;
* struct ccid_operations - Interface to Congestion-Control Infrastructure
*
* @ccid_id: numerical CCID ID (up to %CCID_MAX, cf. table 5 in RFC 4340, 10.)
+ * @ccid_ccmps: the CCMPS including network/transport headers (0 when disabled)
* @ccid_name: alphabetical identifier string for @ccid_id
* @ccid_owner: module which implements/owns this CCID
* @ccid_hc_{r,t}x_slab: memory pool for the receiver/sender half-connection
@@ -45,6 +46,7 @@ struct tcp_info;
*/
struct ccid_operations {
unsigned char ccid_id;
+ __u32 ccid_ccmps;
const char *ccid_name;
struct module *ccid_owner;
struct kmem_cache *ccid_hc_rx_slab,
diff --git a/net/dccp/output.c b/net/dccp/output.c
index 5589a5e..3b763db 100644
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -133,15 +133,31 @@ static int dccp_transmit_skb(struct sock *sk, struct sk_buff *skb)
return -ENOBUFS;
}
+/**
+ * dccp_determine_ccmps - Find out about CCID-specfic packet-size limits
+ * We only consider the HC-sender CCID for setting the CCMPS (RFC 4340, 14.),
+ * since the RX CCID is restricted to feedback packets (Acks), which are small
+ * in comparison with the data traffic. A value of 0 means "no current CCMPS".
+ */
+static u32 dccp_determine_ccmps(const struct dccp_sock *dp)
+{
+ const struct ccid *tx_ccid = dp->dccps_hc_tx_ccid;
+
+ if (tx_ccid == NULL || tx_ccid->ccid_ops == NULL)
+ return 0;
+ return tx_ccid->ccid_ops->ccid_ccmps;
+}
+
unsigned int dccp_sync_mss(struct sock *sk, u32 pmtu)
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct dccp_sock *dp = dccp_sk(sk);
- int mss_now = (pmtu - icsk->icsk_af_ops->net_header_len -
- sizeof(struct dccp_hdr) - sizeof(struct dccp_hdr_ext));
+ u32 ccmps = dccp_determine_ccmps(dp);
+ int cur_mps = ccmps ? min(pmtu, ccmps) : pmtu;
- /* Now subtract optional transport overhead */
- mss_now -= icsk->icsk_ext_hdr_len;
+ /* Account for header lengths and IPv4/v6 option overhead */
+ cur_mps -= (icsk->icsk_af_ops->net_header_len + icsk->icsk_ext_hdr_len +
+ sizeof(struct dccp_hdr) + sizeof(struct dccp_hdr_ext));
/*
* FIXME: this should come from the CCID infrastructure, where, say,
@@ -151,13 +167,13 @@ unsigned int dccp_sync_mss(struct sock *sk, u32 pmtu)
* make it a multiple of 4
*/
- mss_now -= ((5 + 6 + 10 + 6 + 6 + 6 + 3) / 4) * 4;
+ cur_mps -= ((5 + 6 + 10 + 6 + 6 + 6 + 3) / 4) * 4;
/* And store cached results */
icsk->icsk_pmtu_cookie = pmtu;
- dp->dccps_mss_cache = mss_now;
+ dp->dccps_mss_cache = cur_mps;
- return mss_now;
+ return cur_mps;
}
EXPORT_SYMBOL_GPL(dccp_sync_mss);
--
1.5.3.4
^ permalink raw reply related
* Re: [patch 02/10] forcedeth: power down phy when interface is down
From: Andrew Morton @ 2007-12-14 1:07 UTC (permalink / raw)
To: Ed Swierk; +Cc: AAbdulla, jeff, netdev
In-Reply-To: <e6c711510712131653p3c871115r6e9cf33e0c984772@mail.gmail.com>
On Thu, 13 Dec 2007 16:53:58 -0800
"Ed Swierk" <eswierk@arastra.com> wrote:
> On 12/13/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> > Does this patch actually fix any observeable problem?
>
> Without the patch, ifconfig down leaves the physical link up, which
> confuses datacenter users who expect the link lights both on the NIC
> and the switch to go out when they bring an interface down.
>
> Furthermore, even though the phy is powered on, autonegotiation stops
> working, so a normally gigabit link might suddenly become 100 Mbit
> half-duplex when the interface goes down, and become gigabit when it
> comes up again.
>
OK, thanks, I added that text to the changelog along with Ayaz's objection
and shall continue to bug people with it until we have a fix merged.
^ permalink raw reply
* SCTP Notification
From: senthil kumar @ 2007-12-14 1:07 UTC (permalink / raw)
To: bidulock, sigtran; +Cc: linux-net, netdev
[-- Attachment #1.1: Type: text/plain, Size: 1162 bytes --]
Hi,
I am using SCTP(libsctp) in linux 2.6.9. I have subscribed for
Notifications. However, i am not getting any notification when sctp
association is established or peer is shutdown. Is there any correction in
my method of subscription? setsockopt system call is returning success. i
used getsockopt to verify the same.
struct sockaddr_in stSrcIPAddress;
socklen_t Addlen=sizeof(sockaddr_in);
int iFlags=-1,iRet=-1;
struct sctp_sndrcvinfo sndrcvinfo;
struct sctp_event_subscribe events;
memset( (void *)&events, 0, sizeof(events) );
events.sctp_data_io_event = 1;
events.sctp_association_event = 1;
events.sctp_send_failure_event = 1;
events.sctp_shutdown_event = 1;
events.sctp_peer_error_event = 1;
ret = setsockopt( iconnSock, IPPROTO_SCTP, SCTP_EVENTS,(const void
*)&events, sizeof(events) );
while(1)
{
iRet = sctp_recvmsg(iconnSock, (void *)pacbuffer,600, (struct sockaddr
*)&stSrcIPAddress, &Addlen, &sndrcvinfo, &iFlags );
if ( iRet < 0)
{
}
if(iFlags & MSG_NOTIFICATION )//Notification/event is received.
{
}
if (iRet> 0)
{
}
}
with regards,
senthil
[-- Attachment #1.2: Type: text/html, Size: 1740 bytes --]
[-- Attachment #2: Type: text/plain, Size: 133 bytes --]
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
^ permalink raw reply
* RE: [patch 02/10] forcedeth: power down phy when interface is down
From: Brandeburg, Jesse @ 2007-12-14 0:51 UTC (permalink / raw)
To: Andrew Morton, Ayaz Abdulla; +Cc: jeff, netdev, eswierk
In-Reply-To: <20071213163046.c2e9d340.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Thu, 13 Dec 2007 16:11:55 -0800
> "Ayaz Abdulla" <AAbdulla@nvidia.com> wrote:
>
>> I would not include this patch until further testing is performed.
>> NVIDIA MCP chips use 3rd party PHY vendors. By powering down the
>> phy, it could have adverse affects on certain phys.
>>
>> Ayaz
>>
>>
>> -----Original Message-----
>> From: akpm@linux-foundation.org [mailto:akpm@linux-foundation.org]
>> Sent: Thursday, December 13, 2007 4:03 PM
>> To: jeff@garzik.org
>> Cc: netdev@vger.kernel.org; akpm@linux-foundation.org;
>> eswierk@arastra.com; Ayaz Abdulla
>> Subject: [patch 02/10] forcedeth: power down phy when interface is
>> down
>>
>>
>> From: "Ed Swierk" <eswierk@arastra.com>
>>
>> Bring the physical link down when the interface is down by placing
>> the PHY in power-down state, unless WOL is enabled. This mirrors
>> the behavior of other drivers including e1000 and tg3.
>
> Does this patch actually fix any observeable problem?
as a side note this one feature has caused more bugs than almost any
feature I can think of in e1000. If Linux had a decent power manager
that handled PCI device D-states (D0/D3) then most hardware that is able
to be certified in M$ OSes would already implement power savings just by
going to D3 when it was not being used. In e1000's case all the "power
down phy" logic would become useless because the hardware already has a
huge dependency tree that it walks when going to D3 to decide if it can
power down the link, or go to a lower power link (like 100Mb or 10Mb)
/rant
Jesse
^ permalink raw reply
* Re: [patch 02/10] forcedeth: power down phy when interface is down
From: Ed Swierk @ 2007-12-14 0:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ayaz Abdulla, jeff, netdev
In-Reply-To: <20071213163046.c2e9d340.akpm@linux-foundation.org>
On 12/13/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> Does this patch actually fix any observeable problem?
Without the patch, ifconfig down leaves the physical link up, which
confuses datacenter users who expect the link lights both on the NIC
and the switch to go out when they bring an interface down.
Furthermore, even though the phy is powered on, autonegotiation stops
working, so a normally gigabit link might suddenly become 100 Mbit
half-duplex when the interface goes down, and become gigabit when it
comes up again.
--Ed
^ permalink raw reply
* RE: What was the reason for 2.6.22 SMP kernels to change how sendmsg is called?
From: Brandeburg, Jesse @ 2007-12-14 0:45 UTC (permalink / raw)
To: Kevin Wilson; +Cc: netdev
In-Reply-To: <B1F576FE19C55C43B8D2E31F061B50C04E60B2@exchange.comtrol.com>
Kevin Wilson wrote:
> Nonetheless, a somewhat recent change in your tree, that I could not
> pinpoint on my own, caused the driver to stop functioning properly.
> So after much searching in git/google/sources with no luck, I decided
> to ask for a little assistance, maybe just a hint as to where the
> culprit may be in the tree so I could investigate for myself. For
> SNGs I tried the method that now works but I am still at a loss as to
> (can't find) what changes in the tree caused it to fail.
Kevin, could you give git-bisect a shot? if you have two kernel
versions or -rcX tags that work and don't work, then you can use bisect
to help find the patch that causes it.
you can search for from:torvalds and git-bisect to see lots of
instructions from Linus on how to do it. If you have a fast machine and
a few hours and an automatable test it can go really fast, probably less
than 12 rebuilds.
Good Luck,
Jesse
^ permalink raw reply
* Re: [patch 02/10] forcedeth: power down phy when interface is down
From: Andrew Morton @ 2007-12-14 0:30 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: jeff, netdev, eswierk
In-Reply-To: <F72FA20C31DD4F4C997B91C5B3690A091A990D@hqemmail07.nvidia.com>
On Thu, 13 Dec 2007 16:11:55 -0800
"Ayaz Abdulla" <AAbdulla@nvidia.com> wrote:
> I would not include this patch until further testing is performed.
> NVIDIA MCP chips use 3rd party PHY vendors. By powering down the phy, it
> could have adverse affects on certain phys.
>
> Ayaz
>
>
> -----Original Message-----
> From: akpm@linux-foundation.org [mailto:akpm@linux-foundation.org]
> Sent: Thursday, December 13, 2007 4:03 PM
> To: jeff@garzik.org
> Cc: netdev@vger.kernel.org; akpm@linux-foundation.org;
> eswierk@arastra.com; Ayaz Abdulla
> Subject: [patch 02/10] forcedeth: power down phy when interface is down
>
>
> From: "Ed Swierk" <eswierk@arastra.com>
>
> Bring the physical link down when the interface is down by placing the
> PHY
> in power-down state, unless WOL is enabled. This mirrors the behavior
> of
> other drivers including e1000 and tg3.
Does this patch actually fix any observeable problem?
^ permalink raw reply
* RE: [patch 02/10] forcedeth: power down phy when interface is down
From: Ayaz Abdulla @ 2007-12-14 0:11 UTC (permalink / raw)
To: akpm, jeff; +Cc: netdev, eswierk
In-Reply-To: <200712140002.lBE02qo1025508@imap1.linux-foundation.org>
I would not include this patch until further testing is performed.
NVIDIA MCP chips use 3rd party PHY vendors. By powering down the phy, it
could have adverse affects on certain phys.
Ayaz
-----Original Message-----
From: akpm@linux-foundation.org [mailto:akpm@linux-foundation.org]
Sent: Thursday, December 13, 2007 4:03 PM
To: jeff@garzik.org
Cc: netdev@vger.kernel.org; akpm@linux-foundation.org;
eswierk@arastra.com; Ayaz Abdulla
Subject: [patch 02/10] forcedeth: power down phy when interface is down
From: "Ed Swierk" <eswierk@arastra.com>
Bring the physical link down when the interface is down by placing the
PHY
in power-down state, unless WOL is enabled. This mirrors the behavior
of
other drivers including e1000 and tg3.
Signed-off-by: Ed Swierk <eswierk@arastra.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/forcedeth.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff -puN
drivers/net/forcedeth.c~forcedeth-power-down-phy-when-interface-is-down
drivers/net/forcedeth.c
---
a/drivers/net/forcedeth.c~forcedeth-power-down-phy-when-interface-is-dow
n
+++ a/drivers/net/forcedeth.c
@@ -1312,9 +1312,9 @@ static int phy_init(struct net_device *d
/* some phys clear out pause advertisment on reset, set it back
*/
mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
- /* restart auto negotiation */
+ /* restart auto negotiation, power down phy */
mii_control = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ);
- mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE);
+ mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE | BMCR_PDOWN);
if (mii_rw(dev, np->phyaddr, MII_BMCR, mii_control)) {
return PHY_ERROR;
}
@@ -4798,6 +4798,10 @@ static int nv_open(struct net_device *de
dprintk(KERN_DEBUG "nv_open: begin\n");
+ /* power up phy */
+ mii_rw(dev, np->phyaddr, MII_BMCR,
+ mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ) &
~BMCR_PDOWN);
+
/* erase previous misconfiguration */
if (np->driver_data & DEV_HAS_POWER_CNTRL)
nv_mac_reset(dev);
@@ -4980,6 +4984,10 @@ static int nv_close(struct net_device *d
if (np->wolenabled) {
writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base +
NvRegPacketFilterFlags);
nv_start_rx(dev);
+ } else {
+ /* power down phy */
+ mii_rw(dev, np->phyaddr, MII_BMCR,
+ mii_rw(dev, np->phyaddr, MII_BMCR,
MII_READ)|BMCR_PDOWN);
}
/* FIXME: power down nic */
_
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* [patch 07/10] e100: free IRQ to remove warning when rebooting
From: akpm @ 2007-12-14 0:02 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, ianw, auke-jan.h.kok, jesse.brandeburg
From: Ian Wienand <ianw@gelato.unsw.edu.au>
When rebooting today I got
Will now restart.
ACPI: PCI interrupt for device 0000:00:03.0 disabled
GSI 20 (level, low) -> CPU 1 (0x0100) vector 53 unregistered
Destroying IRQ53 without calling free_irq
WARNING: at /home/insecure/ianw/programs/git-kernel/linux-2.6/kernel/irq/chip.c:76 dynamic_irq_cleanup()
Call Trace:
[<a000000100014340>] show_stack+0x40/0xa0
sp=e00000407c927b40 bsp=e00000407c920eb8
[<a0000001000143d0>] dump_stack+0x30/0x60
sp=e00000407c927d10 bsp=e00000407c920ea0
[<a0000001000e58e0>] dynamic_irq_cleanup+0x160/0x1e0
sp=e00000407c927d10 bsp=e00000407c920e70
[<a0000001000106b0>] destroy_and_reserve_irq+0x30/0xc0
sp=e00000407c927d10 bsp=e00000407c920e40
[<a0000001000508f0>] iosapic_unregister_intr+0x5b0/0x5e0
sp=e00000407c927d10 bsp=e00000407c920dd8
[<a00000010000aa70>] acpi_unregister_gsi+0x30/0x60
sp=e00000407c927d10 bsp=e00000407c920db8
[<a00000010042e300>] acpi_pci_irq_disable+0x140/0x160
sp=e00000407c927d10 bsp=e00000407c920d88
[<a000000100774200>] pcibios_disable_device+0xa0/0xc0
sp=e00000407c927d20 bsp=e00000407c920d68
[<a0000001003778d0>] pci_disable_device+0x130/0x160
sp=e00000407c927d20 bsp=e00000407c920d38
[<a000000100525d20>] e100_shutdown+0x1c0/0x220
sp=e00000407c927d30 bsp=e00000407c920d08
[<a00000010037d0e0>] pci_device_shutdown+0x80/0xc0
sp=e00000407c927d30 bsp=e00000407c920ce8
[<a0000001004ecb70>] device_shutdown+0xf0/0x180
sp=e00000407c927d30 bsp=e00000407c920cc8
[<a0000001000ac4e0>] kernel_restart+0x60/0x120
sp=e00000407c927d30 bsp=e00000407c920ca8
[<a0000001000ac990>] sys_reboot+0x3b0/0x480
sp=e00000407c927d30 bsp=e00000407c920c30
[<a00000010000b4e0>] ia64_ret_from_syscall+0x0/0x20
sp=e00000407c927e30 bsp=e00000407c920c30
[<a000000000010620>] ia64_ivt+0xffffffff00010620/0x400
sp=e00000407c928000 bsp=e00000407c920c30
Restarting system.
I think the solution might be to free the IRQ before the pci_device_shutdown
Signed-off-by: Ian Wienand <ianw@gelato.unsw.edu.au>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/e100.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/net/e100.c~e100-free-irq-to-remove-warning-when-rebooting drivers/net/e100.c
--- a/drivers/net/e100.c~e100-free-irq-to-remove-warning-when-rebooting
+++ a/drivers/net/e100.c
@@ -2852,6 +2852,7 @@ static void e100_shutdown(struct pci_dev
pci_enable_wake(pdev, PCI_D3cold, 0);
}
+ free_irq(pdev->irq, netdev);
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
}
_
^ permalink raw reply
* [patch 06/10] Net: ibm_newemac, remove SPIN_LOCK_UNLOCKED
From: akpm @ 2007-12-14 0:02 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, jirislaby, jgarzik
From: Jiri Slaby <jirislaby@gmail.com>
SPIN_LOCK_UNLOCKED is deprecated, use DEFINE_SPINLOCK instead
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/ibm_newemac/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/ibm_newemac/debug.c~net-ibm_newemac-remove-spin_lock_unlocked drivers/net/ibm_newemac/debug.c
--- a/drivers/net/ibm_newemac/debug.c~net-ibm_newemac-remove-spin_lock_unlocked
+++ a/drivers/net/ibm_newemac/debug.c
@@ -21,7 +21,7 @@
#include "core.h"
-static spinlock_t emac_dbg_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(emac_dbg_lock);
static void emac_desc_dump(struct emac_instance *p)
{
_
^ permalink raw reply
* [patch 09/10] bnx2x depends on ZLIB_INFLATE
From: akpm @ 2007-12-14 0:02 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, Lee.Schermerhorn, eliezert, lee.schermerhorn
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
The bnx2x module depends on the zlib_inflate functions. The build will
fail if ZLIB_INFLATE has not been selected manually or by building another
module that automatically selects it.
Modify BNX2X config option to 'select ZLIB_INFLATE' like BNX2
and others. This seems to fix it.
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
Acked-by: Eliezer Tamir <eliezert@broadcom.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/net/Kconfig~bnx2x-depends-on-zlib_inflate drivers/net/Kconfig
--- a/drivers/net/Kconfig~bnx2x-depends-on-zlib_inflate
+++ a/drivers/net/Kconfig
@@ -2607,6 +2607,7 @@ config TEHUTI
config BNX2X
tristate "Broadcom NetXtremeII 10Gb support"
depends on PCI
+ select ZLIB_INFLATE
help
This driver supports Broadcom NetXtremeII 10 gigabit Ethernet cards.
To compile this driver as a module, choose M here: the module
_
^ permalink raw reply
* [patch 05/10] pcmcia net: use roundup_pow_of_two() macro instead of grotesque loop
From: akpm @ 2007-12-14 0:02 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, rpjday, linux
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/pcmcia/pcnet_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/net/pcmcia/pcnet_cs.c~pcmcia-net-use-roundup_pow_of_two-macro-instead-of-grotesque-loop drivers/net/pcmcia/pcnet_cs.c
--- a/drivers/net/pcmcia/pcnet_cs.c~pcmcia-net-use-roundup_pow_of_two-macro-instead-of-grotesque-loop
+++ a/drivers/net/pcmcia/pcnet_cs.c
@@ -38,6 +38,7 @@
#include <linux/delay.h>
#include <linux/ethtool.h>
#include <linux/netdevice.h>
+#include <linux/log2.h>
#include "../8390.h"
#include <pcmcia/cs_types.h>
@@ -1484,8 +1485,7 @@ static int setup_shmem_window(struct pcm
window_size = 32 * 1024;
/* Make sure it's a power of two. */
- while ((window_size & (window_size - 1)) != 0)
- window_size += window_size & ~(window_size - 1);
+ window_size = roundup_pow_of_two(window_size);
/* Allocate a memory window */
req.Attributes = WIN_DATA_WIDTH_16|WIN_MEMORY_TYPE_CM|WIN_ENABLE;
_
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox