* Re: [PATCH 4/6] tg3: Add reset_phy parameter to chip reset functions
From: David S. Miller @ 2006-04-30 1:59 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1146267368.4780.17.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Apr 2006 16:36:08 -0700
> Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
> the full chip reset during MAC address change, the automatic PHY reset
> during chip reset will cause a link down and bonding will not work
> properly as a result. With this reset_phy parameter, we can do a chip
> reset without link down when changing MAC address or MTU.
>
> Signed-off-by: Gary Zambrano <zambrano@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
Doesn't the signalling interface between the MAC and the
PHY get reset during a chip reset and couldn't that cause
problems if we bypass the PHY reset?
Thanks.
^ permalink raw reply
* Re: [PATCH 5/6] tg3: Fix bug in nvram write
From: David S. Miller @ 2006-04-30 2:00 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1146267381.4780.18.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Apr 2006 16:36:21 -0700
> Fix bug in nvram write function. If the starting nvram address offset
> happens to be the last dword of the page, the NVRAM_CMD_LAST bit will
> not get set in the existing code. This patch fixes the bug by changing
> the "else if" to "if" so that the last dword condition always gets
> checked.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Good catch, applied.
Thanks.
^ permalink raw reply
* Re: [PATCH 6/6] tg3: Update version and reldate
From: David S. Miller @ 2006-04-30 2:01 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1146267390.4780.19.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 28 Apr 2006 16:36:30 -0700
> Update version to 3.57.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* tw32_f() in tg3_write_mem()
From: David S. Miller @ 2006-04-30 2:22 UTC (permalink / raw)
To: mchan; +Cc: netdev
At least for the TG3PCI_MEM_WIN_DATA register, I don't know how safe
it is to use tw32_f() there. Reads from a location can have side
effects, so doing a forced readback after a write could be dangerous.
And it isn't needed, as the tw32_f() done as we set the
TG3PCI_MEM_WIN_BASE_ADDR back to zero will flush all posted
writes.
Agreed?
^ permalink raw reply
* [PATCH] Interface Stat Clearing Framework, skge support, ethtool support
From: Phil Dibowitz @ 2006-04-30 3:16 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1: Type: text/plain, Size: 1305 bytes --]
Hey folks,
A few months back I posted an in-progress patch for adding a clear_stats
framework similar to the get_stats framework and implimenting support
for it in the skge driver (the one NIC I have access to), as well as
adding the ethtool support for it.
While a few people said they didn't see the need for it, other people
did see the need for it, and I know it's a common request on many
sysadmin mailing lists I'm on.
Since no one seemed to have any technical issue with the patch, I've
cleaned up the patch, tested it, and fixed a few minor issues.
Unless someone has an objection, I'd think this would be useful to a lot
of people.
There are two patches attached:
interface_stats_clear.patch - the kernel patch against 2.6.17-rc3-git2
ethtool3-clearstats.patch - the ethtool patch to add the -z flag to
support it.
If the kernel patch gets accepted I'll send a more complete ethtool
patch with documentation updates, etc.
Thanks.
--
Phil Dibowitz phil@ipom.com
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind."
- Dr. Suess
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: interface_stats_clear.patch --]
[-- Type: text/x-patch; name="interface_stats_clear.patch", Size: 6417 bytes --]
This patch adds support for clearing interface statistics using the ethtool interface adding a new 0x23 command. It adds a clear_stats function pointer to the net_device struct, and then impliments local functions in the driver much the say get_stats works. The ethtool funtion pointer points to the same functions. The driver-local functions are currently only implimented in the skge driver.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
---
diff -puN include/linux/netdevice.h~interface_stats_clear include/linux/netdevice.h
--- linux-2.6.17-rc3-git2/include/linux/netdevice.h~interface_stats_clear 2006-04-29 19:44:41.000000000 -0700
+++ linux-2.6.17-rc3-git2-phil/include/linux/netdevice.h 2006-04-29 19:44:41.000000000 -0700
@@ -319,6 +319,7 @@ struct net_device
struct net_device_stats* (*get_stats)(struct net_device *dev);
+ void (*clear_stats)(struct net_device *dev);
struct iw_statistics* (*get_wireless_stats)(struct net_device *dev);
/* List of functions to handle Wireless Extensions (instead of ioctl).
diff -puN drivers/net/skge.c~interface_stats_clear drivers/net/skge.c
--- linux-2.6.17-rc3-git2/drivers/net/skge.c~interface_stats_clear 2006-04-29 19:44:41.000000000 -0700
+++ linux-2.6.17-rc3-git2-phil/drivers/net/skge.c 2006-04-29 19:44:41.000000000 -0700
@@ -44,7 +44,7 @@
#include "skge.h"
#define DRV_NAME "skge"
-#define DRV_VERSION "1.5"
+#define DRV_VERSION "1.6"
#define PFX DRV_NAME " "
#define DEFAULT_TX_RING_SIZE 128
@@ -97,6 +97,8 @@ static int xm_phy_write(struct skge_hw *
static int gm_phy_write(struct skge_hw *hw, int port, u16 reg, u16 val);
static void genesis_get_stats(struct skge_port *skge, u64 *data);
static void yukon_get_stats(struct skge_port *skge, u64 *data);
+static void genesis_clear_stats(struct skge_port *skge);
+static void yukon_clear_stats(struct skge_port *skge);
static void yukon_init(struct skge_hw *hw, int port);
static void genesis_mac_init(struct skge_hw *hw, int port);
static void genesis_link_up(struct skge_port *skge);
@@ -366,6 +368,15 @@ static struct net_device_stats *skge_get
return &skge->net_stats;
}
+static void skge_clear_stats(struct net_device *dev)
+{
+ struct skge_port *skge = netdev_priv(dev);
+ if (skge->hw->chip_id == CHIP_ID_GENESIS)
+ genesis_clear_stats(skge);
+ else
+ yukon_clear_stats(skge);
+}
+
static void skge_get_strings(struct net_device *dev, u32 stringset, u8 *data)
{
int i;
@@ -722,6 +733,7 @@ static struct ethtool_ops skge_ethtool_o
.phys_id = skge_phys_id,
.get_stats_count = skge_get_stats_count,
.get_ethtool_stats = skge_get_ethtool_stats,
+ .clear_ethtool_stats = skge_clear_stats,
.get_perm_addr = ethtool_op_get_perm_addr,
};
@@ -1383,6 +1395,20 @@ static void genesis_get_stats(struct skg
data[i] = xm_read32(hw, port, skge_stats[i].xmac_offset);
}
+static void genesis_clear_stats(struct skge_port *skge)
+{
+ struct skge_hw *hw = skge->hw;
+ int port = skge->port;
+
+ /*
+ * This is based on reading other parts of the driver
+ * and is not yet tested.
+ */
+
+ xm_write16(hw, port, XM_STAT_CMD, 0 | XM_SC_CLR_RXC
+ | XM_SC_CLR_TXC);
+}
+
static void genesis_mac_intr(struct skge_hw *hw, int port)
{
struct skge_port *skge = netdev_priv(hw->dev[port]);
@@ -1871,6 +1897,21 @@ static void yukon_get_stats(struct skge_
skge_stats[i].gma_offset);
}
+static void yukon_clear_stats(struct skge_port *skge)
+{
+ struct skge_hw *hw = skge->hw;
+ int port = skge->port;
+ u16 reg;
+ int i;
+
+ reg = gma_read16(hw, port, GM_PHY_ADDR);
+ /* this read is important, or we sometimes get no effect */
+ gma_write16(hw, port, GM_PHY_ADDR, reg | GM_PAR_MIB_CLR);
+ for (i = 0; i < GM_MIB_CNT_SIZE; i++)
+ gma_read16(hw, port, GM_MIB_CNT_BASE + 8*i);
+ gma_write16(hw, port, GM_PHY_ADDR, reg);
+}
+
static void yukon_mac_intr(struct skge_hw *hw, int port)
{
struct net_device *dev = hw->dev[port];
@@ -3183,6 +3224,7 @@ static struct net_device *skge_devinit(s
dev->do_ioctl = skge_ioctl;
dev->hard_start_xmit = skge_xmit_frame;
dev->get_stats = skge_get_stats;
+ dev->clear_stats = skge_clear_stats;
if (hw->chip_id == CHIP_ID_GENESIS)
dev->set_multicast_list = genesis_set_multicast;
else
diff -puN include/linux/ethtool.h~interface_stats_clear include/linux/ethtool.h
--- linux-2.6.17-rc3-git2/include/linux/ethtool.h~interface_stats_clear 2006-04-29 19:44:41.000000000 -0700
+++ linux-2.6.17-rc3-git2-phil/include/linux/ethtool.h 2006-04-29 19:44:41.000000000 -0700
@@ -365,6 +365,7 @@ struct ethtool_ops {
int (*phys_id)(struct net_device *, u32);
int (*get_stats_count)(struct net_device *);
void (*get_ethtool_stats)(struct net_device *, struct ethtool_stats *, u64 *);
+ void (*clear_ethtool_stats)(struct net_device *);
int (*get_perm_addr)(struct net_device *, struct ethtool_perm_addr *, u8 *);
int (*begin)(struct net_device *);
void (*complete)(struct net_device *);
@@ -408,6 +409,7 @@ struct ethtool_ops {
#define ETHTOOL_GPERMADDR 0x00000020 /* Get permanent hardware address */
#define ETHTOOL_GUFO 0x00000021 /* Get UFO enable (ethtool_value) */
#define ETHTOOL_SUFO 0x00000022 /* Set UFO enable (ethtool_value) */
+#define ETHTOOL_CSTATS 0x00000023 /* Clear NIC-specific statistics */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff -puN net/core/ethtool.c~interface_stats_clear net/core/ethtool.c
--- linux-2.6.17-rc3-git2/net/core/ethtool.c~interface_stats_clear 2006-04-29 19:44:41.000000000 -0700
+++ linux-2.6.17-rc3-git2-phil/net/core/ethtool.c 2006-04-29 19:44:41.000000000 -0700
@@ -741,6 +741,17 @@ static int ethtool_get_stats(struct net_
return ret;
}
+static int ethtool_clear_stats(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_ops *ops = dev->ethtool_ops;
+ if (!ops->clear_ethtool_stats)
+ return -EOPNOTSUPP;
+
+ ops->clear_ethtool_stats(dev);
+
+ return 0;
+}
+
static int ethtool_get_perm_addr(struct net_device *dev, void __user *useraddr)
{
struct ethtool_perm_addr epaddr;
@@ -906,6 +917,9 @@ int dev_ethtool(struct ifreq *ifr)
case ETHTOOL_SUFO:
rc = ethtool_set_ufo(dev, useraddr);
break;
+ case ETHTOOL_CSTATS:
+ rc = ethtool_clear_stats(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
_
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: ethtool3-clearstats.patch --]
[-- Type: text/x-patch; name="ethtool3-clearstats.patch", Size: 3683 bytes --]
--- ethtool-3/ethtool.c.b4phil 2006-04-29 19:01:18.000000000 -0700
+++ ethtool-3/ethtool.c 2006-04-29 19:01:36.000000000 -0700
@@ -66,6 +66,7 @@
static int do_goffload(int fd, struct ifreq *ifr);
static int do_soffload(int fd, struct ifreq *ifr);
static int do_gstats(int fd, struct ifreq *ifr);
+static int do_cstats(int fd, struct ifreq *ifr);
static int send_ioctl(int fd, struct ifreq *ifr);
static int check_for_pre24_kernel();
@@ -242,6 +243,7 @@
MODE_GOFFLOAD,
MODE_SOFFLOAD,
MODE_GSTATS,
+ MODE_CSTATS,
} mode = MODE_GSET;
static int goffload_changed = 0;
@@ -470,6 +472,8 @@
mode = MODE_TEST;
else if (!strcmp(argp[i], "-S"))
mode = MODE_GSTATS;
+ else if (!strcmp(argp[i], "-z"))
+ mode = MODE_CSTATS;
else if (!strcmp(argp[i], "-h"))
show_usage(0);
else
@@ -492,6 +496,7 @@
(mode == MODE_GOFFLOAD) ||
(mode == MODE_SOFFLOAD) ||
(mode == MODE_GSTATS) ||
+ (mode == MODE_CSTATS) ||
(mode == MODE_PHYS_ID)) {
devname = argp[i];
break;
@@ -1266,6 +1271,8 @@
return do_soffload(fd, &ifr);
} else if (mode == MODE_GSTATS) {
return do_gstats(fd, &ifr);
+ } else if (mode == MODE_CSTATS) {
+ return do_cstats(fd, &ifr);
}
return 69;
@@ -2010,6 +2017,79 @@
return 0;
}
+static int do_cstats(int fd, struct ifreq *ifr)
+{
+ struct ethtool_drvinfo drvinfo;
+ struct ethtool_gstrings *strings;
+ struct ethtool_stats *stats;
+ unsigned int n_stats, sz_str, sz_stats, i;
+ int err;
+
+ drvinfo.cmd = ETHTOOL_GDRVINFO;
+ ifr->ifr_data = (caddr_t)&drvinfo;
+ err = send_ioctl(fd, ifr);
+ if (err < 0) {
+ perror("Cannot get driver information");
+ return 71;
+ }
+
+ n_stats = drvinfo.n_stats;
+ if (n_stats < 1) {
+ fprintf(stderr, "no stats available\n");
+ return 94;
+ }
+
+ sz_str = n_stats * ETH_GSTRING_LEN;
+ sz_stats = n_stats * sizeof(u64);
+
+ strings = calloc(1, sz_str + sizeof(struct ethtool_gstrings));
+ stats = calloc(1, sz_stats + sizeof(struct ethtool_stats));
+ if (!strings || !stats) {
+ fprintf(stderr, "no memory available\n");
+ return 95;
+ }
+
+ strings->cmd = ETHTOOL_GSTRINGS;
+ strings->string_set = ETH_SS_STATS;
+ strings->len = n_stats;
+ ifr->ifr_data = (caddr_t) strings;
+ err = send_ioctl(fd, ifr);
+ if (err < 0) {
+ perror("Cannot get stats strings information");
+ free(strings);
+ free(stats);
+ return 96;
+ }
+
+ stats->cmd = ETHTOOL_CSTATS;
+ stats->n_stats = n_stats;
+ ifr->ifr_data = (caddr_t) stats;
+ err = send_ioctl(fd, ifr);
+ if (err < 0) {
+ perror("Cannot get stats information");
+ free(strings);
+ free(stats);
+ return 97;
+ }
+
+ /* todo - pretty-print the strings per-driver */
+ /*
+ fprintf(stdout, "NIC statistics:\n");
+ for (i = 0; i < n_stats; i++) {
+ char s[ETH_GSTRING_LEN];
+
+ strncpy(s, &strings->data[i * ETH_GSTRING_LEN],
+ ETH_GSTRING_LEN);
+ fprintf(stdout, " %s: %llu\n",
+ s, stats->data[i]);
+ }
+ */
+ free(strings);
+ free(stats);
+
+ return 0;
+}
+
static int send_ioctl(int fd, struct ifreq *ifr)
{
int err;
--- ethtool-3/ethtool-copy.h.b4phil 2006-04-29 19:01:26.000000000 -0700
+++ ethtool-3/ethtool-copy.h 2006-04-29 19:01:36.000000000 -0700
@@ -283,6 +283,7 @@
#define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */
#define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */
#define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */
+#define ETHTOOL_CSTATS 0x00000023 /* get NIC-specific statistics */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: Fw: Bug: PPP dropouts in >=2.6.16 - updates
From: Nuri Jawad @ 2006-04-30 4:31 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060421010809.6c3cfc34.akpm@osdl.org>
Some more info:
- turning off Hyper Threading and using a uniprocessor kernel
did not improve things
- so didn't using 2.6.17rc3, in fact the bug manifested after
only 4 minutes with a 43 seconds gap
- those kernel debug watchdog routines don't detect anything
Going to try kernel PPPoE next time. Btw, at least with rp-pppoe
it requires HDLC and that dependency isn't caught in menuconfig.
I would try to roll back some patches between 2.6.15.7 and 2.6.16 but
that changelog is pretty large. I'm sure there are good reasons for
the current development model, but with the old unstable/stable
system and its few changes between stable versions, the right
one could've been spotted easily :/.
Regards, Nuri
^ permalink raw reply
* Re: determine outgoing interface (eth0,eth1) for a packet according to the dest IP
From: Lennert Buytenhek @ 2006-04-30 9:17 UTC (permalink / raw)
To: Herbert Xu; +Cc: John Que, ak, netdev
In-Reply-To: <E1FYkWm-0003MM-00@gondolin.me.apana.org.au>
On Wed, Apr 26, 2006 at 11:58:00PM +1000, Herbert Xu wrote:
> > I had spent time trying to write something which
> > uses RTA_SRC and RTA_DST and got some problems.
> > (I probably made something stupid.)
> > I googled for such examples and did not get much.
> > I saw that the zebra project and iproute uses
> > netlinks but it is complex.,
>
> Have a look at
>
> http://gondor.apana.org.au/~herbert/findsaddr-linux.c
>
> which I wrote for traceroute some years back.
A fragile and ugly but easier/shorter way of getting the source address
(which I've used a couple of times in the past) is to open a SOCK_DGRAM
socket, connect() it to the intended destination, and then do
getsockname().
(That doesn't give you the interface, though.)
--L
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Pekka Enberg @ 2006-04-30 9:26 UTC (permalink / raw)
To: David Gómez; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <1146342905.11271.3.camel@localhost>
On Sat, 2006-04-29 at 14:21 +0200, David Gómez wrote:
> > I already had it modified, just needed to create the patch... Anyway,
> > have you submitted it to netdev?
On Sat, 2006-04-29 at 23:35 +0300, Pekka Enberg wrote:
> No, I haven't. I don't have the hardware, so I can't test the driver.
> Furthermore, there's plenty of stuff to fix before it's in any shape for
> submission. If someone wants to give this patch a spin, I would love to
> hear the results.
I killed the I/O write/read macros and switched the driver to iomap.
Pekka
Subject: [PATCH] IP1000 Gigabit Ethernet device driver
This is a cleaned up fork of the IP1000A device driver:
<http://www.icplus.com.tw/driver-pp-IP1000A.html>
Open issues include but are not limited to:
- ipg_probe() looks really fishy and doesn't handle all errors
(e.g. ioremap failing).
- ipg_nic_do_ioctl() is playing games with user-space pointer.
We should use ethtool ioctl instead as suggested by Arjan.
- For multiple devices, the driver uses a global root_dev and
ipg_remove() play some tricks which look fishy.
I don't have the hardware, so I don't know if I broke anything.
The patch is 138 KB in size, so I am not including it in this
mail. You can find the patch here:
http://www.cs.helsinki.fi/u/penberg/linux/ip1000-driver.patch
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
^ permalink raw reply
* Re: [PATCH 3/3] Eleminate HZ from ROSE kernel interfaces
From: Bernard Pidoux @ 2006-04-30 9:35 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David S. Miller, netdev, linux-hams
In-Reply-To: <20060429141924.GA2941@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
Ralf Baechle wrote :
> Index: linux-net.git/net/rose/af_rose.c
> ===================================================================
> --- linux-net.git.orig/net/rose/af_rose.c 2006-04-29 01:54:21.000000000 +0100
> +++ linux-net.git/net/rose/af_rose.c 2006-04-29 11:37:34.000000000 +0100
While patching af_rose.c, would you consider the following patch
ROSE/FPAC users have introduced a year ago with good success.
73 de Bernard, f6bvp
http://f6bvp.org
http://rose.fpac.free.fr/MINI-HOWTO/
http://rose.fpac.free.fr/MINI-HOWTO-FR/
[-- Attachment #2: af_rose.diff --]
[-- Type: text/x-patch, Size: 716 bytes --]
--- linux/net/rose/af_rose.c.orig 2006-04-30 11:30:48.000000000 +0200
+++ linux/net/rose/af_rose.c 2006-04-30 11:27:35.000000000 +0200
@@ -753,6 +753,7 @@
rose_insert_socket(sk); /* Finish the bind */
}
+rose_try_next_neigh:
rose->dest_addr = addr->srose_addr;
rose->dest_call = addr->srose_call;
rose->rand = ((long)rose & 0xFFFF) + rose->lci;
@@ -810,6 +811,11 @@
}
if (sk->sk_state != TCP_ESTABLISHED) {
+ /* Try next neighbour */
+ rose->neighbour = rose_get_neigh(&addr->srose_addr, &cause, &diagnostic);
+ if (rose->neighbour)
+ goto rose_try_next_neigh;
+ /* No more neighbour */
sock->state = SS_UNCONNECTED;
return sock_error(sk); /* Always set at this point */
}
^ permalink raw reply
* Re: Fw: Bug: PPP dropouts in >=2.6.16
From: theosch @ 2006-04-30 11:43 UTC (permalink / raw)
To: netdev
In-Reply-To: <Pine.LNX.4.58.0604202217450.4014@pc>
Maybe this is an issue of the e100 driver?
I observed a 1-2 sec stalling behaviour for the complete system every
10 seconds or so _seemingly_ only when my ADSL connection was up. That
was after I had changed the ethernet driver for a card _not_ connected
to the modem from eepro100 to e100.
After a lot of fiddling around with git-bisect trying to find the
erroneous patch I realized I had changed the driver when upgrading the
kernel to 2.6.14. The problem also existed in later kernel versions.
Going back to e100 helped.
Cheers
Arnold
If you have any question, please Cc to theosch at gmx.net as I am not
subscibed to the list.
+ + + + +
Using Kernel pppoe
PCI-Rev: Don't know (well, it says "PCI: PCI BIOS revision 2.10...")
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
First ethernet (connected to ADSL modem):
PCI: Found IRQ 11 for device 0000:00:0c.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:00:0c.0: 3Com PCI 3c905B Cyclone 100baseTx at e0800000. Vers LK1.1.19
Second ethernet (local LAN):
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
PCI: Found IRQ 10 for device 0000:00:0b.0
eth1: 0000:00:0b.0, 00:D0:B7:83:58:26, IRQ 10.
Board assembly 721383-009, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
^ permalink raw reply
* Re: [AX25, ROSE] Remove useless SET_MODULE_OWNER calls.
From: Dan Williams @ 2006-04-30 12:03 UTC (permalink / raw)
To: Ralf Baechle DL5RB; +Cc: David S. Miller, netdev, linux-hams
In-Reply-To: <20060429142943.GA4402@linux-mips.org>
On Sat, 2006-04-29 at 15:29 +0100, Ralf Baechle DL5RB wrote:
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>
> --
>
> net/netrom/nr_dev.c | 1 -
> net/rose/rose_dev.c | 1 -
> 2 files changed, 2 deletions(-)
>
> Index: linux-net.git/net/netrom/nr_dev.c
> ===================================================================
> --- linux-net.git.orig/net/netrom/nr_dev.c 2006-04-29 01:43:47.000000000 +0100
> +++ linux-net.git/net/netrom/nr_dev.c 2006-04-29 11:38:00.000000000 +0100
> @@ -185,7 +185,6 @@ static struct net_device_stats *nr_get_s
>
> void nr_setup(struct net_device *dev)
> {
> - SET_MODULE_OWNER(dev);
> dev->mtu = NR_MAX_PACKET_SIZE;
> dev->hard_start_xmit = nr_xmit;
> dev->open = nr_open;
Are these done by anything else now? Did something change to make
SET_MODULE_OWNER useless in individual drivers? I'm asking because I
was fairly sure that SET_MODULE_OWNER set up some sysfs links and such
that HAL depends on to figure out information about the driver and
hardware device, much like SET_NETDEV_DEV.
Dan
^ permalink raw reply
* Re: Fw: Bug: PPP dropouts in >=2.6.16
From: theosch @ 2006-04-30 12:05 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060430114356.GA9810@ats.dyn.bawue.de>
> Going back to e100 helped
Sorry, I meant: Going back to eepro100 helped
^ permalink raw reply
* Re: wireless-dev: warnings while removing bcm43xx-d80211
From: Jiri Benc @ 2006-04-30 12:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Broadcom Linux
In-Reply-To: <1146308425.5019.38.camel@localhost>
Sat, 29 Apr 2006 13:00:25 +0200, Johannes Berg pise:
> This didn't look too good to me, maybe someone can investigate?
>
> [24070.841580] Badness in remove_proc_entry at fs/proc/generic.c:732
> [24070.841593] Call Trace:
> [...]
I know about this (also mentioned it at Wireless summit), I'm working on
it.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: wireless-dev: warnings while removing bcm43xx-d80211
From: Michael Buesch @ 2006-04-30 12:49 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, Broadcom Linux, Johannes Berg
In-Reply-To: <20060430141520.5f0ef66a@logostar.upir.cz>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Sunday 30 April 2006 14:15, you wrote:
> Sat, 29 Apr 2006 13:00:25 +0200, Johannes Berg pise:
> > This didn't look too good to me, maybe someone can investigate?
> >
> > [24070.841580] Badness in remove_proc_entry at fs/proc/generic.c:732
> > [24070.841593] Call Trace:
> > [...]
>
> I know about this (also mentioned it at Wireless summit), I'm working on
> it.
Hm, seems like I did not listen to you. :P
How does this happen? I never saw it.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: determine outgoing interface (eth0,eth1) for a packet according to the dest IP
From: Herbert Xu @ 2006-04-30 12:55 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: John Que, ak, netdev
In-Reply-To: <20060430091711.GL24458@xi.wantstofly.org>
On Sun, Apr 30, 2006 at 11:17:11AM +0200, Lennert Buytenhek wrote:
>
> A fragile and ugly but easier/shorter way of getting the source address
> (which I've used a couple of times in the past) is to open a SOCK_DGRAM
> socket, connect() it to the intended destination, and then do
> getsockname().
Yes you're quite right that this would've been a much simpler solution.
I suppose I was quite fond of the netlink hammer at the time :)
--
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
* Re: [AX25, ROSE] Remove useless SET_MODULE_OWNER calls.
From: Herbert Xu @ 2006-04-30 13:38 UTC (permalink / raw)
To: Dan Williams; +Cc: ralf, davem, netdev, linux-hams
In-Reply-To: <1146398606.2252.1.camel@localhost.localdomain>
Dan Williams <dcbw@redhat.com> wrote:
>
> Are these done by anything else now? Did something change to make
> SET_MODULE_OWNER useless in individual drivers? I'm asking because I
SET_MODULE_OWNER has been a no-op ever since Dave made live network
device driver modules unloadable nearly three years ago.
> was fairly sure that SET_MODULE_OWNER set up some sysfs links and such
> that HAL depends on to figure out information about the driver and
> hardware device, much like SET_NETDEV_DEV.
For PCI drivers the module information is injected by pci_register_driver.
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
* Re: Fw: Bug: PPP dropouts in >=2.6.16
From: Nuri Jawad @ 2006-04-30 14:10 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060430114356.GA9810@ats.dyn.bawue.de>
On Sun, 30 Apr 2006, theosch@gmx.net wrote:
> I observed a 1-2 sec stalling behaviour for the complete system every
> 10 seconds or so _seemingly_ only when my ADSL connection was up.
I had that idea too, but that sounds different from what I have here. I
have also transfered lots of data at >900 MBits/s with the e1000 and
never had a single problem. The packets are not vanishing on the wire and
the system does not stall, there's just nothing appearing on ppp0 tx at
all. That sounds like an unrelated issue to me.
BTW, there was no dropout in the last 8 hours, only after I started some
tx load a while ago one of them came up within minutes.
> erroneous patch I realized I had changed the driver when upgrading the
> kernel to 2.6.14.
What does 2.6.14 have to do with it? The ppp problem appeared exactly with
*2.6.16*. It looks like it will also be in 2.6.17 because nobody is
stepping on the brake :/. All this with code that had worked perfectly
fine for ages. I'm getting a bit frustrated here.
Well, I might try disabling the onboard e1000 and replacing it with a
"good" old Realtek.
Regards, Nuri
^ permalink raw reply
* VLAN subinterfaces, bridges and udev
From: Marco d'Itri @ 2006-04-30 14:29 UTC (permalink / raw)
To: netdev
[Please Cc me, I am not subscribed to netdev.]
Can I rely on the presence of the $DEVPATH/driver symlink (e.g.
/sys/class/net/eth0/driver) to check if a network interface is a "real"
device insteaf of a VLAN or a bridge?
----- Forwarded message from Marco d'Itri <md@Linux.IT> -----
To: linux-hotplug-devel@lists.sourceforge.net
Subject: VLAN subinterfaces
From: Marco d'Itri <md@Linux.IT>
I wrote a script to handle persistent rules for network interfaces, but
I noticed that VLAN subinterfaces have the same MAC address of the
parent interface and I could not find in sysfs anything evident which I
could use in a rule. The only difference I noticed is that the VLAN
subinterfaces lack the device and drivers symlinks.
This problem affects anybody using VLANs, is there a good solution?
--
ciao,
Marco
----- End forwarded message -----
----- Forwarded message from Marco d'Itri <md@Linux.IT> -----
To: linux-hotplug-devel@lists.sourceforge.net
Subject: Re: VLAN subinterfaces
From: Marco d'Itri <md@Linux.IT>
On Apr 23, Marco d'Itri <md@Linux.IT> wrote:
> I wrote a script to handle persistent rules for network interfaces, but
> I noticed that VLAN subinterfaces have the same MAC address of the
> parent interface and I could not find in sysfs anything evident which I
> could use in a rule. The only difference I noticed is that the VLAN
> subinterfaces lack the device and drivers symlinks.
> This problem affects anybody using VLANs, is there a good solution?
Another user (Debian bug #365248) reported that this applies to bridges
too. Is adding DRIVER=="?*" to the rules the correct workaround?
--
ciao,
Marco
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
----- End forwarded message -----
--
ciao,
Marco
^ permalink raw reply
* Re: [AX25, ROSE] Remove useless SET_MODULE_OWNER calls.
From: Dan Williams @ 2006-04-30 17:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: ralf, davem, netdev, linux-hams
In-Reply-To: <E1FaC7e-0003Cj-00@gondolin.me.apana.org.au>
On Sun, 2006-04-30 at 23:38 +1000, Herbert Xu wrote:
> Dan Williams <dcbw@redhat.com> wrote:
> >
> > Are these done by anything else now? Did something change to make
> > SET_MODULE_OWNER useless in individual drivers? I'm asking because I
>
> SET_MODULE_OWNER has been a no-op ever since Dave made live network
> device driver modules unloadable nearly three years ago.
Ah, thanks for the clarification.
dan
^ permalink raw reply
* [PATCH] Add some new card IDs to hostap_cs
From: Marcin Juszkiewicz @ 2006-04-30 17:22 UTC (permalink / raw)
To: netdev; +Cc: hostap, Pavel Roskin, Jouni Malinen, linux-kernel
I use two Zaurus palmtops - one run 2.4.18 kernel and second run 2.6.16.
Both are running under control of OpenZaurus distribution (I'm Release
Manager of it).
When I use pcmcia-cs then my Pretec WiFi card is handled by hostap
driver and everything is working fine. Recently I switched to
pcmciautils and after card insert orinoco modules are loaded. I prefer
to use hostap modules because they work the same under 2.4 and 2.6
kernels (with orinoco I have to use 0.13e ones because never ones does
not work under 2.4/arm).
Few weeks ago I sent smaller version to LKML, got response from Pavel
Roskin (with his patch attached) and then I worked on converting our
(OpenEmbedded one) hostap_cs.conf to one patch which will add every
card which we had there during last years (definitions was collected
by users/developers of Familiar, OpenZaurus and OpenSimpad distributions).
This patch require 24_hostap_cs_id.diff [1] from Pavel Roskin.
Some hashes can be wrong but I want to get info what do you thing about
this patch.
PS I'm not subscribed to those mailinglists - please Cc: me on reply.
1. http://ewi546.ewi.utwente.nl/tmp/hrw/hostap/24-hostap_cs_id.diff
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
--- linux/drivers/net/wireless/hostap/hostap_cs.c.orig
+++ linux/drivers/net/wireless/hostap/hostap_cs.c
@@ -874,18 +874,25 @@
static struct pcmcia_device_id hostap_cs_ids[] = {
PCMCIA_DEVICE_MANF_CARD(0x000b, 0x7100),
PCMCIA_DEVICE_MANF_CARD(0x000b, 0x7300),
+ PCMCIA_DEVICE_MANF_CARD(0x0089, 0x0001), /* "Intel PRO/Wireless 2011" */
PCMCIA_DEVICE_MANF_CARD(0x0089, 0x0002),
PCMCIA_DEVICE_MANF_CARD(0x0101, 0x0777),
PCMCIA_DEVICE_MANF_CARD(0x0126, 0x8000),
PCMCIA_DEVICE_MANF_CARD(0x0138, 0x0002),
+ PCMCIA_DEVICE_MANF_CARD(0x01eb, 0x080a), /* "Nortel Networks eMobility 802.11 Wireless Adapter" */
PCMCIA_DEVICE_MANF_CARD(0x01ff, 0x0008),
PCMCIA_DEVICE_MANF_CARD(0x0250, 0x0002),
+ PCMCIA_DEVICE_MANF_CARD(0x0261, 0x0002), /* "AirWay 802.11 Adapter (PCMCIA)" */
PCMCIA_DEVICE_MANF_CARD(0x026f, 0x030b),
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1612),
PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613),
+ PCMCIA_DEVICE_MANF_CARD(0x0274, 0x3301), /* "Linksys WCF11 11Mbps 802.11b WLAN Card" */
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002),
+ PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* "Linksys Wireless CompactFlash Card WCF12" */
PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002),
+ PCMCIA_DEVICE_MANF_CARD(0x02ac, 0x0002), /* "SpeedStream SS1021 Wireless Adapter" */
PCMCIA_DEVICE_MANF_CARD(0x02d2, 0x0001),
+ PCMCIA_DEVICE_MANF_CARD(0x1668, 0x0101), /* "Actiontec 802CI2" */
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x0001),
PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300),
PCMCIA_DEVICE_MANF_CARD(0x9005, 0x0021),
@@ -893,6 +900,7 @@
PCMCIA_DEVICE_MANF_CARD(0xc00f, 0x0000),
PCMCIA_DEVICE_MANF_CARD(0xc250, 0x0002),
PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0002),
+ PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0004), /* "Sitecom WL-007 WLAN CF Card" */
PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0005),
PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0010),
PCMCIA_DEVICE_MANF_CARD_PROD_ID1(0x0156, 0x0002, "INTERSIL",
@@ -969,6 +977,151 @@
PCMCIA_DEVICE_PROD_ID12(
"ZoomAir 11Mbps High", "Rate wireless Networking",
0x273fe3db, 0x32a1eaee),
+
+ /*card "Fulbond Airbond XI-300B"*/
+ PCMCIA_DEVICE_PROD_ID12( " ", "IEEE 802.11 Wireless LAN/PC Card",
+ 0x5670ee60, 0x74e6b7c0),
+ /* manfid 0xd601, 0x0002*/
+
+ /*card "3Com AirConnect"*/
+ PCMCIA_DEVICE_PROD_ID12("3Com", "3CRWE737A AirConnect Wireless LAN PC Card",
+ 0x90952d33, 0xfa4f2ce9),
+
+ /*card "D-Link DWL-650"*/
+ PCMCIA_DEVICE_PROD_ID12( "D", "Link DWL-650 11Mbps WLAN Card",
+ 0xdfad2f93, 0xaeaf66ea),
+
+ /*card "D-Link DRC-650"*/
+ PCMCIA_DEVICE_PROD_ID12( "D", "Link DRC-650 11Mbps WLAN Card",
+ 0x124d5155, 0x62ff301f),
+
+ /*card "HyperLink Wireless PC Card 11Mbps"*/
+ PCMCIA_DEVICE_PROD_ID12( "HyperLink", "Wireless PC Card 11Mbps",
+ 0xf2ab1a6b, 0x16a66dec),
+
+ /*card "MELCO WLI-PCM-L11"*/
+ PCMCIA_DEVICE_PROD_ID12( "MELCO", "WLI-PCM-L11",
+ 0xc549cac9, 0xc2f6de9b),
+
+ /*card "MELCO WLI-PCM-L11G"*/
+ PCMCIA_DEVICE_PROD_ID12( "MELCO", "WLI-PCM-L11G",
+ 0xfebebb55, 0x6db62357),
+
+ /*card "MELCO WLI-PCM-L11G"*/
+ PCMCIA_DEVICE_PROD_ID12( "BUFFALO", "WLI-PCM-L11G",
+ 0x6cdab6ea, 0xc364d25d),
+
+ /*card "Buffalo WLI2-CF-S11"*/
+ PCMCIA_DEVICE_PROD_ID12( "BUFFALO", "WLI2-CF-S11",
+ 0x798caeca, 0xe38746ab),
+
+ /*card "NCR WaveLAN/IEEE Adapter"*/
+ PCMCIA_DEVICE_PROD_ID12( "NCR", "WaveLAN/IEEE",
+ 0x7b03a1a1, 0x1e9b31cf),
+
+ /*card "PLANEX GeoWave GW-CF110"*/
+ PCMCIA_DEVICE_PROD_ID12( "PLANEX", "GeoWave/GW-CF110",
+ 0xfc599cd7, 0xbd486a2b),
+
+ /*card "PROXIM LAN PC CARD HARMONY 80211B"*/
+ PCMCIA_DEVICE_PROD_ID12( "PROXIM", "LAN PC CARD HARMONY 80211B",
+ 0x73fc1d26, 0x87a9b674),
+
+ /*card "Proxim RangeLAN/DS"*/
+ PCMCIA_DEVICE_PROD_ID12( "PROXIM","RangeLAN-DS/LAN PC CARD",
+ 0x2aacece5, 0xf3165e33),
+ /* manfid 0x0126, 0x8000*/
+
+ /*card "SAMSUNG 11Mbps WLAN Card"*/
+ PCMCIA_DEVICE_PROD_ID12( "SAMSUNG", "11Mbps WLAN Card",
+ 0xc621522d, 0x7db4e5f0),
+
+ /*card "SanDisk ConnectPlus w/ Memory"*/
+ PCMCIA_DEVICE_PROD_ID12( "SanDisk", "ConnectPlus",
+ 0xeed76820, 0x57dcd73e),
+ /* manfid 0xd601, 0x0101*/
+
+ /*card "U.S. Robotics IEEE 802.11b PC-CARD"*/
+ PCMCIA_DEVICE_PROD_ID123( "U.S. Robotics", "IEEE 802.11b PC-CARD",
+ "Version 01.02",
+ 0xc274c253, 0x81e83306, 0x753707e3),
+
+ /*card "Longshine LCR-8531 11Mbps WLAN PCMCIA CARD"*/
+ PCMCIA_DEVICE_PROD_ID123( "OEM", "PRISM2 IEEE 802.11 PC-Card",
+ "Version 01.02",
+ 0xc1242b52, 0xe65091b7, 0xb95beace),
+
+ /*card "Level-One WPC-0100"*/
+ PCMCIA_DEVICE_PROD_ID123( "Digital Data Communications", "WPC-0100",
+ "Version 00.00",
+ 0x3c4f10c9, 0x963a48e5, 0x6b28acd),
+ /* manfid 0x0156, 0x0002*/
+
+ /*card "Belkin 802.11b WLAN PCMCIA"*/
+ PCMCIA_DEVICE_PROD_ID123( "Belkin",
+ "11Mbps Wireless Notebook Network Adapter", "Version 01.02",
+ 0x86f06bf4, 0x7f1c625, 0xe3e8328),
+ /* manfid 0x0156, 0x0002*/
+
+ /*card "Senao SL-2011CD/SL-2011CDPLUS"*/
+ PCMCIA_DEVICE_PROD_ID123( "INTERSIL", "HFA384x/IEEE", "Version 01.02",
+ 0xaa245f03, 0xfc153421, 0xc1fb16f9),
+ /* manfid 0x0156, 0x0002*/
+
+ /*card "Netgear MA401"*/
+ PCMCIA_DEVICE_PROD_ID123( "NETGEAR MA401 Wireless PC", "Card",
+ "Version 01.00",
+ 0x2d28b025, 0x6df900aa, 0x1f2b0825),
+
+ /*card "Airvast WL100"*/
+ PCMCIA_DEVICE_PROD_ID123( "AIRVAST", "IEEE 802.11b Wireless PCMCIA Card",
+ "HFA3863",
+ 0xdc579992, 0x9c73262e, 0xcc8c8afe),
+ /* manfid 0x50c2, 0x0001*/
+
+ /*card "Allied Telesyn AT-WCL452"*/
+ PCMCIA_DEVICE_PROD_ID123( "Allied Telesyn",
+ "AT-WCL452 Wireless PCMCIA Radio", "Ver. 1.00",
+ 0xc57766a0, 0xca5d9d30, 0xdce3940c),
+ /* manfid 0xc00f, 0x000*/
+
+ /*card "ASUS WL-100 8011b WLAN PC Card"*/
+ PCMCIA_DEVICE_PROD_ID123("ASUS", "802_11b_PC_CARD_25", "Version 01.00",
+ 0x45ae513c, 0x25e956b5, 0x4d4f9549),
+ /* manfid 0x02aa, 0x0002*/
+
+ /*card "Wireless LAN Adapter Version 01.02"*/
+ PCMCIA_DEVICE_PROD_ID123( "Wireless", "LAN Adapter", "Version 01.02",
+ 0x0cc3741d, 0x77846ac8, 0x280d341f),
+
+ /*card "D-Link DWL-650 Rev. P1"*/
+ PCMCIA_DEVICE_PROD_ID1234( "D-Link", "DWL-650 Wireless PC Card RevP",
+ "ISL37101P-10", "A3",
+ 0x368662a9, 0x269d73b1, 0xb0136b54, 0xfac1bb25),
+
+ /*card "SonicWALL Long Range Wireless Card"*/
+ PCMCIA_DEVICE_PROD_ID1234( "SonicWALL", "Long Range Wireless Card",
+ "ISL37100P", "1.0",
+ 0xfe59b73c, 0xdee96647, 0x2cc2096b, 0x3546bfc1),
+ /* manfid 0x000b, 0x7100*/
+
+ /*card "Senao NL-2011CD PLUS Ext2 Mercury"*/
+ PCMCIA_DEVICE_PROD_ID1234( "WLAN", "11Mbps_PC-Card_3.0", "ISL37100P",
+ "Eval-RevA",
+ 0x8d96f5be, 0xdb4801eb, 0x60ae1479, 0xb3cd1a59),
+ /* manfid 0x000b, 0x7100*/
+
+ /*card "Microsoft Wireless Notebook Adapter MN-520 1.0.3"*/
+ PCMCIA_DEVICE_PROD_ID1234( "Microsoft", "Wireless Notebook Adapter MN-520",
+ "", "1.0.3",
+ 0x51dc9ca9, 0x3684178d, 0x00000000 , 0x87ebda3b),
+ /* manfid 0x02d2, 0x0001*/
+
+ /*card "NETGEAR MA401RA"*/
+ PCMCIA_DEVICE_PROD_ID1234( "NETGEAR MA401RA Wireless PC", "Card",
+ "ISL37300P", "Eval-RevA",
+ 0x76d8b84, 0xb98efcc9, 0x6b5190fc, 0xe48c0c83),
+ /* manfid 0x000b, 0x7300*/
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Palmtop: Sharp Zaurus C760
OpenEmbedded/OpenZaurus developer
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply
* [PATCH] softmac: make non-operational after being stopped
From: Daniel Drake @ 2006-04-30 17:33 UTC (permalink / raw)
To: linville; +Cc: johannes, netdev, softmac-dev
zd1211 with softmac and wpa_supplicant revealed an issue with softmac and the
use of workqueues. Some of the work functions actually reschedule themselves,
so this meant that there could still be pending work after
flush_scheduled_work() had been called during ieee80211softmac_stop().
This patch introduces a "running" flag which is used to ensure that
rescheduling does not happen in this situation.
I also used this flag to ensure that softmac's hooks into ieee80211 are
non-operational once the stop operation has been started. This simply makes
softmac a little more robust, because I could crash it easily by receiving
frames in the short timeframe after shutting down softmac and before turning
off the ZD1211 radio. (ZD1211 is now fixed as well!)
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Index: linux/net/ieee80211/softmac/ieee80211softmac_module.c
===================================================================
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_module.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_module.c
@@ -89,6 +89,8 @@ ieee80211softmac_clear_pending_work(stru
ieee80211softmac_wait_for_scan(sm);
spin_lock_irqsave(&sm->lock, flags);
+ sm->running = 0;
+
/* Free all pending assoc work items */
cancel_delayed_work(&sm->associnfo.work);
@@ -204,6 +206,8 @@ void ieee80211softmac_start(struct net_d
assert(0);
if (mac->txrates_change)
mac->txrates_change(dev, change, &oldrates);
+
+ mac->running = 1;
}
EXPORT_SYMBOL_GPL(ieee80211softmac_start);
Index: linux/include/net/ieee80211softmac.h
===================================================================
--- linux.orig/include/net/ieee80211softmac.h
+++ linux/include/net/ieee80211softmac.h
@@ -204,7 +204,8 @@ struct ieee80211softmac_device {
/* couple of flags */
u8 scanning:1, /* protects scanning from being done multiple times at once */
- associated:1;
+ associated:1,
+ running:1;
struct ieee80211softmac_scaninfo *scaninfo;
struct ieee80211softmac_assoc_info associnfo;
Index: linux/net/ieee80211/softmac/ieee80211softmac_auth.c
===================================================================
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -86,6 +86,11 @@ ieee80211softmac_auth_queue(void *data)
/* Lock and set flags */
spin_lock_irqsave(&mac->lock, flags);
+ if (unlikely(!mac->running)) {
+ /* Prevent reschedule on workqueue flush */
+ spin_unlock_irqrestore(&mac->lock, flags);
+ return;
+ }
net->authenticated = 0;
net->authenticating = 1;
/* add a timeout call so we eventually give up waiting for an auth reply */
@@ -124,6 +129,9 @@ ieee80211softmac_auth_resp(struct net_de
unsigned long flags;
u8 * data;
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
/* Find correct auth queue item */
spin_lock_irqsave(&mac->lock, flags);
list_for_each(list_ptr, &mac->auth_queue) {
@@ -338,6 +346,9 @@ ieee80211softmac_deauth_resp(struct net_
struct ieee80211softmac_network *net = NULL;
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
if (!deauth) {
dprintk("deauth without deauth packet. eek!n");
return 0;
Index: linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
===================================================================
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -51,11 +51,12 @@ ieee80211softmac_assoc(struct ieee80211s
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.associating = 1;
mac->associated = 0; /* just to make sure */
- spin_unlock_irqrestore(&mac->lock, flags);
/* Set a timer for timeout */
/* FIXME: make timeout configurable */
- schedule_delayed_work(&mac->associnfo.timeout, 5 * HZ);
+ if (likely(mac->running))
+ schedule_delayed_work(&mac->associnfo.timeout, 5 * HZ);
+ spin_unlock_irqrestore(&mac->lock, flags);
}
void
@@ -319,6 +320,9 @@ ieee80211softmac_handle_assoc_response(s
u16 status = le16_to_cpup(&resp->status);
struct ieee80211softmac_network *network = NULL;
unsigned long flags;
+
+ if (unlikely(!mac->running))
+ return -ENODEV;
spin_lock_irqsave(&mac->lock, flags);
@@ -377,10 +381,16 @@ ieee80211softmac_handle_disassoc(struct
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
unsigned long flags;
+
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
if (memcmp(disassoc->header.addr2, mac->associnfo.bssid, ETH_ALEN))
return 0;
+
if (memcmp(disassoc->header.addr1, mac->dev->dev_addr, ETH_ALEN))
return 0;
+
dprintk(KERN_INFO PFX "got disassoc framen");
netif_carrier_off(dev);
spin_lock_irqsave(&mac->lock, flags);
@@ -400,6 +410,9 @@ ieee80211softmac_handle_reassoc_req(stru
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
struct ieee80211softmac_network *network;
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
network = ieee80211softmac_get_network_by_bssid(mac, resp->header.addr3);
if (!network) {
dprintkl(KERN_INFO PFX "reassoc request from unknown networkn");
Index: linux/net/ieee80211/softmac/ieee80211softmac_scan.c
===================================================================
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_scan.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_scan.c
@@ -115,7 +115,15 @@ void ieee80211softmac_scan(void *d)
// TODO: is this if correct, or should we do this only if scanning from assoc request?
if (sm->associnfo.req_essid.len)
ieee80211softmac_send_mgt_frame(sm, &sm->associnfo.req_essid, IEEE80211_STYPE_PROBE_REQ, 0);
+
+ spin_lock_irqsave(&sm->lock, flags);
+ if (unlikely(!sm->running)) {
+ /* Prevent reschedule on workqueue flush */
+ spin_unlock_irqrestore(&sm->lock, flags);
+ break;
+ }
schedule_delayed_work(&si->softmac_scan, IEEE80211SOFTMAC_PROBE_DELAY);
+ spin_unlock_irqrestore(&sm->lock, flags);
return;
} else {
dprintk(PFX "Not probing Channel %d (not allowed here)n", si->channels[current_channel_idx].channel);
^ permalink raw reply
* Re: [PATCH] softmac: make non-operational after being stopped
From: Johannes Berg @ 2006-04-30 18:06 UTC (permalink / raw)
To: Daniel Drake; +Cc: linville, netdev, softmac-dev
In-Reply-To: <20060430173353.16363886AB1@zog.reactivated.net>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Sun, 2006-04-30 at 18:33 +0100, Daniel Drake wrote:
> zd1211 with softmac and wpa_supplicant revealed an issue with softmac and the
> use of workqueues. Some of the work functions actually reschedule themselves,
> so this meant that there could still be pending work after
> flush_scheduled_work() had been called during ieee80211softmac_stop().
>
> This patch introduces a "running" flag which is used to ensure that
> rescheduling does not happen in this situation.
[...]
> Signed-off-by: Daniel Drake <dsd@gentoo.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Not sure what state 2.6.17 is in now, but I'm thinking it's almost a
miracle people aren't hitting this more with bcm43xx. And it kills the
kernel pretty effectively too ;)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH] softmac: don't reassociate if user asked for deauthentication
From: Daniel Drake @ 2006-04-30 18:49 UTC (permalink / raw)
To: linville; +Cc: netdev, johannes, softmac-dev
When wpa_supplicant exits, it uses SIOCSIWMLME to request deauthentication.
softmac then tries to reassociate without any user intervention, which isn't
the desired behaviour of this signal.
This change makes softmac only attempt reassociation if the remote network
itself deauthenticated us.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Index: linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_auth.c
===================================================================
--- linux-2.6.17-rc3.orig/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -301,8 +301,6 @@ ieee80211softmac_deauth_from_net(struct
/* can't transmit data right now... */
netif_carrier_off(mac->dev);
- /* let's try to re-associate */
- schedule_work(&mac->associnfo.work);
spin_unlock_irqrestore(&mac->lock, flags);
}
@@ -363,5 +361,8 @@ ieee80211softmac_deauth_resp(struct net_
}
ieee80211softmac_deauth_from_net(mac, net);
+
+ /* let's try to re-associate */
+ schedule_work(&mac->associnfo.work);
return 0;
}
^ permalink raw reply
* RtNetlink in wireless.c and netlink_broadcast(uevent_sock,...) - newbie
From: Xu Nakajima @ 2006-04-30 19:14 UTC (permalink / raw)
To: netdev
Hello,
I saw that in the wireless linux stack, there is usage
of sending messages to user space via the RtNetlink
event channel :
in net/core/wireless.c, wireless_send_event() method
calls rtmsg_iwinfo() which calls
netlink_broadcast(rtnl, skb, 0, RTNLGRP_LINK,
GFP_ATOMIC); (it fills a struct with
rtnetlink_fill_iwinfo before).
On the other hand, I see that for example, in the case
of
sending messeges to userspace udev socket, the
netlink_broadcast() call is with a different
mecahinsm;
In lib/kobject_uevent.c, there is the following call
netlink_broadcast(uevent_sock, skb, 0, 1, GFP_KERNEL);
Is there something special about RtNetlink event
channel
which makes it needed fot wireless.c (for example)?
While udev can use some other mechanism ?
What is special about RtNetlink event channel
in comaprison to non RtNetlink channels?
Regards,
Xu
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: wireless-dev: warnings while removing bcm43xx-d80211
From: Jiri Benc @ 2006-04-30 19:18 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, Broadcom Linux, Johannes Berg
In-Reply-To: <200604301449.46431.mb@bu3sch.de>
Sun, 30 Apr 2006 14:49:45 +0200, Michael Buesch pise:
> Hm, seems like I did not listen to you. :P
> How does this happen? I never saw it.
Usually when a net interface is renamed (by udev for example). The stack
then tries to remove wrong procfs directory.
Jiri
--
Jiri Benc
SUSE Labs
^ 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