* Re: e1000 driver and samba
From: Francois Romieu @ 2007-09-21 22:41 UTC (permalink / raw)
To: Bruce Cole; +Cc: netdev
In-Reply-To: <46F43F4B.7090903@gmail.com>
Bruce Cole <bacole@gmail.com> :
> Francois Romieu wrote:
[...]
> >Can you be more specific ?
> >
> Yes per the reference I gave:
> http://www.spinics.net/lists/netdev/msg40384.html
[...]
Ok, I wondered if you had found something between the start_xmit and the
Tx completion code.
[...]
> I could probably help fix the underlying problem but I didn't
> receive any response to my post quoted above.
I have submitted the smallest workaround to Jeff. It is not necessarily
the best wrt performance but this part is not trivial to arbitrate.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko @ 2007-09-21 22:43 UTC (permalink / raw)
To: Krzysztof Oledzki
Cc: Valdis.Kletnieks, David Miller, jeff, mchan, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.64.0709212130490.11228@bizon.gios.gov.pl>
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote:
>
> On Fri, 21 Sep 2007, Denys Vlasenko wrote:
>
> > On Friday 21 September 2007 19:36, Valdis.Kletnieks@vt.edu wrote:
> >> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
> >>
> >>> I plan to use gzip compression on following drivers' firmware,
> >>> if patches will be accepted:
> >>>
> >>> text data bss dec hex filename
> >>> 17653 109968 240 127861 1f375 drivers/net/acenic.o
> >>> 6628 120448 4 127080 1f068 drivers/net/dgrs.o
> >>> ^^^^^^
> >>
> >> Should this be redone to use the existing firmware loading framework to
> >> load the firmware instead?
> >
> > Not in every case.
> >
> > For example, bnx2 maintainer says that driver and
> > firmware are closely tied for his driver. IOW: you upgrade kernel
> > and your NIC is not working anymore.
>
> Firmware may come with a kernel. We have a "install modules", we can also
> add "install firmware".
Install where? I boot my machine over NFS, and it has no hard drive.
> > Another argument is to make kernel be able to bring up NICs
> > without needing firmware images in initramfs/initrd/hard drive.
>
> It is not possible to bring up things like FC or WiFi without firmware,
> what special is in classic NICs?
Nothing.
It is just not (yet?) decreed from The Very Top that all and every
firmware image should be loaded using request_firmware().
Also people may want to gzip something else than firmware.
--
vda
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Jeff Garzik @ 2007-09-21 22:57 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Krzysztof Oledzki, Valdis.Kletnieks, David Miller, mchan,
linux-kernel, netdev
In-Reply-To: <200709212343.41160.vda.linux@googlemail.com>
Denys Vlasenko wrote:
> On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote:
>> On Fri, 21 Sep 2007, Denys Vlasenko wrote:
>>
>>> On Friday 21 September 2007 19:36, Valdis.Kletnieks@vt.edu wrote:
>>>> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said:
>>>>
>>>>> I plan to use gzip compression on following drivers' firmware,
>>>>> if patches will be accepted:
>>>>>
>>>>> text data bss dec hex filename
>>>>> 17653 109968 240 127861 1f375 drivers/net/acenic.o
>>>>> 6628 120448 4 127080 1f068 drivers/net/dgrs.o
>>>>> ^^^^^^
>>>> Should this be redone to use the existing firmware loading framework to
>>>> load the firmware instead?
>>> Not in every case.
>>>
>>> For example, bnx2 maintainer says that driver and
>>> firmware are closely tied for his driver. IOW: you upgrade kernel
>>> and your NIC is not working anymore.
>> Firmware may come with a kernel. We have a "install modules", we can also
>> add "install firmware".
>
> Install where? I boot my machine over NFS, and it has no hard drive.
Special cases already fail when using distro-linked targets like "make
install."
Jeff
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: maximilian attems @ 2007-09-22 0:02 UTC (permalink / raw)
To: Alan Cox
Cc: Jeff Garzik, Denys Vlasenko, Valdis.Kletnieks, David Miller,
mchan, linux-kernel, netdev
In-Reply-To: <20070921234805.478efe15@the-village.bc.nu>
On Fri, Sep 21, 2007 at 11:48:05PM +0100, Alan Cox wrote:
> > According to an earlier thread, dgrs was never really maintained,
> > written for hardware that was never really distributed widely, and very
> > likely hasn't had users in years... if ever.
> >
> > If that picture is accurate (it's a story I was told), then I am
> > definitely queueing up a deletion patch.
>
> I think thats sensible. If someone whines it can be put back but I really
> don't think anyone will
nobody did yet, please yell if you need a rebased patch.
--
maks
^ permalink raw reply
* Re: [PATCH] note that NETIF_F_LLTX is deprecated (was: [kvm-devel][PATCH 3/6] virtio net driver)
From: Herbert Xu @ 2007-09-22 0:57 UTC (permalink / raw)
To: Christian Borntraeger; +Cc: Jeff Garzik, netdev, David Miller
In-Reply-To: <200709211659.54935.borntraeger@de.ibm.com>
On Fri, Sep 21, 2007 at 04:59:54PM +0200, Christian Borntraeger wrote:
>
> I suggest to document that LLTX is deprecated.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
This looks good to me.
Thanks,
--
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: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Michael Chan @ 2007-09-22 2:47 UTC (permalink / raw)
To: David Miller; +Cc: vda.linux, jeff, linux-kernel, netdev
In-Reply-To: <20070921.104912.41646795.davem@davemloft.net>
On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote:
> From: Denys Vlasenko <vda.linux@googlemail.com>
> Date: Fri, 21 Sep 2007 18:03:55 +0100
>
> > Do patches look ok to you?
>
> I'm travelling so I haven't looked closely yet :-)
>
> Michael can take a look and I'll try to do so as well
> tonight.
>
I've already reviewed the earlier versions of the patch and have made
some suggestions. This latest one looks ok to me and tested ok.
I'll follow up later with another patch to remove all the zeros in other
firmware sections, and to remove the gzip headers completely.
Acked-by: Michael Chan <mchan@broadcom.com>
^ permalink raw reply
* Re: Distributed storage. Security attributes and ducumentation update.
From: Pavel Machek @ 2007-09-17 18:22 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, linux-kernel, linux-fsdevel
In-Reply-To: <20070831160611.GA21660@2ka.mipt.ru>
Hi!
> I'm pleased to announce third release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
How is this different from raid0/1 over nbd? Or raid0/1 over
ata-over-ethernet?
> +|---------------- DST storate -------------------|
storage?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Satyam Sharma @ 2007-09-22 6:54 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Linux Kernel Mailing List, linuxppc-dev,
Linux Netdev Mailing List, jeff
In-Reply-To: <alpine.LFD.0.999.0709201903180.17093@enigma.security.iitk.ac.in>
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c: In function 'spider_net_release_tx_chain':
drivers/net/spider_net.c:818: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c:818: error: (Each undeclared identifier is reported only once
drivers/net/spider_net.c:818: error: for each function it appears in.)
drivers/net/spider_net.c: In function 'spider_net_xmit':
drivers/net/spider_net.c:922: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c: In function 'spider_net_pass_skb_up':
drivers/net/spider_net.c:1018: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c: In function 'spider_net_decode_one_descr':
drivers/net/spider_net.c:1215: error: 'dev' undeclared (first use in this function)
make[2]: *** [drivers/net/spider_net.o] Error 1
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/spider_net.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff -ruNp a/drivers/net/spider_net.c b/drivers/net/spider_net.c
--- a/drivers/net/spider_net.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/spider_net.c 2007-09-22 12:12:23.000000000 +0530
@@ -795,6 +795,7 @@ spider_net_set_low_watermark(struct spid
static int
spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
{
+ struct net_device *dev = card->netdev;
struct spider_net_descr_chain *chain = &card->tx_chain;
struct spider_net_descr *descr;
struct spider_net_hw_descr *hwdescr;
@@ -919,7 +920,7 @@ spider_net_xmit(struct sk_buff *skb, str
spider_net_release_tx_chain(card, 0);
if (spider_net_prepare_tx_descr(card, skb) != 0) {
- dev->stats.tx_dropped++;
+ netdev->stats.tx_dropped++;
netif_stop_queue(netdev);
return NETDEV_TX_BUSY;
}
@@ -979,16 +980,12 @@ static void
spider_net_pass_skb_up(struct spider_net_descr *descr,
struct spider_net_card *card)
{
- struct spider_net_hw_descr *hwdescr= descr->hwdescr;
- struct sk_buff *skb;
- struct net_device *netdev;
- u32 data_status, data_error;
-
- data_status = hwdescr->data_status;
- data_error = hwdescr->data_error;
- netdev = card->netdev;
+ struct spider_net_hw_descr *hwdescr = descr->hwdescr;
+ struct sk_buff *skb = descr->skb;
+ struct net_device *netdev = card->netdev;
+ u32 data_status = hwdescr->data_status;
+ u32 data_error = hwdescr->data_error;
- skb = descr->skb;
skb_put(skb, hwdescr->valid_size);
/* the card seems to add 2 bytes of junk in front
@@ -1015,8 +1012,8 @@ spider_net_pass_skb_up(struct spider_net
}
/* update netdevice statistics */
- dev->stats.rx_packets++;
- dev->stats.rx_bytes += skb->len;
+ netdev->stats.rx_packets++;
+ netdev->stats.rx_bytes += skb->len;
/* pass skb up to stack */
netif_receive_skb(skb);
@@ -1184,6 +1181,7 @@ static int spider_net_resync_tail_ptr(st
static int
spider_net_decode_one_descr(struct spider_net_card *card)
{
+ struct net_device *dev = card->netdev;
struct spider_net_descr_chain *chain = &card->rx_chain;
struct spider_net_descr *descr = chain->tail;
struct spider_net_hw_descr *hwdescr = descr->hwdescr;
@@ -1210,7 +1208,7 @@ spider_net_decode_one_descr(struct spide
(status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
(status == SPIDER_NET_DESCR_FORCE_END) ) {
if (netif_msg_rx_err(card))
- dev_err(&card->netdev->dev,
+ dev_err(&dev->dev,
"dropping RX descriptor with state %d\n", status);
dev->stats.rx_dropped++;
goto bad_desc;
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Satyam Sharma @ 2007-09-22 7:25 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Linux Kernel Mailing List, linuxppc-dev,
Jeff Garzik, Linux Netdev Mailing List
In-Reply-To: <alpine.LFD.0.999.0709201903180.17093@enigma.security.iitk.ac.in>
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_ethtool.c)
[PATCH -mm] spider_net_ethtool: Keep up with recent netdev stats changes
Unbreak the following:
drivers/net/spider_net_ethtool.c: In function 'spider_net_get_ethtool_stats':
drivers/net/spider_net_ethtool.c:160: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:161: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:162: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:163: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:164: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:165: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:166: error: structure has no member named 'netdev_stats'
make[2]: *** [drivers/net/spider_net_ethtool.o] Error 1
Also do another ARRAY_SIZE() cleanup while at it.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/spider_net_ethtool.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff -ruNp a/drivers/net/spider_net_ethtool.c b/drivers/net/spider_net_ethtool.c
--- a/drivers/net/spider_net_ethtool.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/spider_net_ethtool.c 2007-09-22 12:43:51.000000000 +0530
@@ -28,8 +28,6 @@
#include "spider_net.h"
-#define SPIDER_NET_NUM_STATS 13
-
static struct {
const char str[ETH_GSTRING_LEN];
} ethtool_stats_keys[] = {
@@ -149,7 +147,7 @@ spider_net_ethtool_get_ringparam(struct
static int spider_net_get_stats_count(struct net_device *netdev)
{
- return SPIDER_NET_NUM_STATS;
+ return ARRAY_SIZE(ethtool_stats_keys);
}
static void spider_net_get_ethtool_stats(struct net_device *netdev,
@@ -157,13 +155,13 @@ static void spider_net_get_ethtool_stats
{
struct spider_net_card *card = netdev->priv;
- data[0] = card->netdev_stats.tx_packets;
- data[1] = card->netdev_stats.tx_bytes;
- data[2] = card->netdev_stats.rx_packets;
- data[3] = card->netdev_stats.rx_bytes;
- data[4] = card->netdev_stats.tx_errors;
- data[5] = card->netdev_stats.tx_dropped;
- data[6] = card->netdev_stats.rx_dropped;
+ data[0] = netdev->stats.tx_packets;
+ data[1] = netdev->stats.tx_bytes;
+ data[2] = netdev->stats.rx_packets;
+ data[3] = netdev->stats.rx_bytes;
+ data[4] = netdev->stats.tx_errors;
+ data[5] = netdev->stats.tx_dropped;
+ data[6] = netdev->stats.rx_dropped;
data[7] = card->spider_stats.rx_desc_error;
data[8] = card->spider_stats.tx_timeouts;
data[9] = card->spider_stats.alloc_rx_skb_error;
^ permalink raw reply
* [PATCH -mm] pasemi_mac: Build fix after recent netdev stats changes
From: Satyam Sharma @ 2007-09-22 7:40 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Linux Kernel Mailing List,
Linux Netdev Mailing List, Jeff Garzik, David Miller
In-Reply-To: <alpine.LFD.0.999.0709201903180.17093@enigma.security.iitk.ac.in>
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/pasemi_mac.c
[PATCH -mm] pasemi_mac: Build fix after recent netdev stats changes
Unbreak the following:
drivers/net/pasemi_mac.c: In function 'pasemi_mac_clean_rx':
drivers/net/pasemi_mac.c:533: error: 'dev' undeclared (first use in this function)
drivers/net/pasemi_mac.c:533: error: (Each undeclared identifier is reported only once
drivers/net/pasemi_mac.c:533: error: for each function it appears in.)
And remove an unused static function:
drivers/net/pasemi_mac.c: At top level:
drivers/net/pasemi_mac.c:89: warning: 'read_iob_reg' defined but not used
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/pasemi_mac.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff -ruNp a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
--- a/drivers/net/pasemi_mac.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/pasemi_mac.c 2007-09-22 13:03:04.000000000 +0530
@@ -85,11 +85,6 @@ MODULE_PARM_DESC(debug, "PA Semi MAC bit
static struct pasdma_status *dma_status;
-static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
-{
- return in_le32(mac->iob_regs+reg);
-}
-
static void write_iob_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
@@ -530,8 +525,8 @@ static int pasemi_mac_clean_rx(struct pa
} else
skb->ip_summed = CHECKSUM_NONE;
- dev->stats.rx_bytes += len;
- dev->stats.rx_packets++;
+ mac->netdev->stats.rx_bytes += len;
+ mac->netdev->stats.rx_packets++;
skb->protocol = eth_type_trans(skb, mac->netdev);
netif_receive_skb(skb);
^ permalink raw reply
* [PATCH -mm] mv643xx_eth: Remove redundant multiple initialization
From: Satyam Sharma @ 2007-09-22 7:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Jeff Garzik, Linux Netdev Mailing List
In-Reply-To: <20070918011841.2381bd93.akpm@linux-foundation.org>
Of ethtool_ops->get_stats_count and ethtool_ops->get_ethtool_stats.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/mv643xx_eth.c | 2 --
1 file changed, 2 deletions(-)
diff -ruNp a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
--- a/drivers/net/mv643xx_eth.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/mv643xx_eth.c 2007-09-22 13:15:41.000000000 +0530
@@ -2740,8 +2740,6 @@ static const struct ethtool_ops mv643xx_
.get_stats_count = mv643xx_get_stats_count,
.get_ethtool_stats = mv643xx_get_ethtool_stats,
.get_strings = mv643xx_get_strings,
- .get_stats_count = mv643xx_get_stats_count,
- .get_ethtool_stats = mv643xx_get_ethtool_stats,
.nway_reset = mv643xx_eth_nway_restart,
};
^ permalink raw reply
* [PATCH -mm] iseries_veth: Kill unused variable
From: Satyam Sharma @ 2007-09-22 7:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Jeff Garzik, Linux Netdev Mailing List
In-Reply-To: <20070918011841.2381bd93.akpm@linux-foundation.org>
drivers/net/iseries_veth.c: In function 'veth_transmit_to_many':
drivers/net/iseries_veth.c:1174: warning: unused variable 'port'
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/iseries_veth.c | 1 -
1 file changed, 1 deletion(-)
diff -ruNp a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
--- a/drivers/net/iseries_veth.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/iseries_veth.c 2007-09-22 11:17:29.000000000 +0530
@@ -1171,7 +1171,6 @@ static void veth_transmit_to_many(struct
HvLpIndexMap lpmask,
struct net_device *dev)
{
- struct veth_port *port = (struct veth_port *) dev->priv;
int i, success, error;
success = error = 0;
^ permalink raw reply
* Re: Please pull 'z1211' branch of wireless-2.6
From: Ulrich Kunitz @ 2007-09-22 9:48 UTC (permalink / raw)
To: John W. Linville
Cc: Daniel Drake, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070920134730.GC6748-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Sorry for joining the discussion so late, but I have a day job
requires sometimes all of my time.
John W. Linville wrote:
> On Wed, Sep 19, 2007 at 11:08:16PM +0100, Daniel Drake wrote:
>
> > I would like to this until 2.6.25 until I have had time to clear up some
> > final issues and do more testing myself of zd1211rw-mac80211. I also
> > think we need to discuss the rename...
>
> Renames being what they are, I was hoping to avoid a "bikeshed"
> discussion about the choice of names. My main point was to get it
> into the tree with a unique and manageable name. I'm sure we could
> still rename it again before 2.6.24 ships or even later.
I would remark here that names are important. John you are
suggesting here the fourth rename of the mac80211 zd1211rw driver.
In my professional life I would clearly identify this as a
problem. I agree that zd1211rw-mac80211 is awkward, but this name
hasn't been introduced by Daniel or me. z1211 has never been used
to refer to the device. If a new name for zd1211rw-mac80211 has to
be found, we should use zd1211mac. This is a different name than
the for the softmac driver, which is zd1211rw. This should also
clarify my personal position, which is that different things
should be named differently. We cannot use zd1211, because this is
used by the out-of-tree vendor driver, which is still used by some
people.
> Well, obviously I would like to get it out now. The longer we are
> without a mac80211-based driver for zd1211 hardware then the longer
> we must maintain the softmac component (or at least take bug reports
> for it).
The problem from my perspective is, that mac80211 and our driver
is not there where it should be. Actually the softmac driver still
works better than the mac80211 driver. There are sometimes stops
with mac80211 for several seconds, which is pretty painful while
remotely editing text, which I do right now. Yes, I eat my own dog
food. The reason is that mac80211 has assumptions about the
features a device supports that we emulate quite badly, because
the device interface doesn't support the required semantics. (TX
confirmations is my major concern right now.) Multiple interfaces
don't work and I have been able to cause kernel crashes while
playing around with this. The driver doesn't support the setting
of certain configuration parameters while the device is down.
(Personally I think that should be handled by the stack, but it
doesn't right now.) We are receiving complains about kismet
compatibility once in a while.
You could ask, why we have not fixed those things. The problem is
that mac80211 right now is a moving target. I spent two weekends
simply to identify the patch, that caused a complete crash of the
kernel with the driver. At the same time the wireless-dev tree
reorg has been done, which destroyed the whole history. I wrote my
own git patch tool to be able to bisect. I found the patch, it had
around 2000 changed lines, it mixed code moves and some quick
fixes. Shortly afterwards a patch by Johannes fixed the problem. I
had not changed a line of the driver, but had spend around 50
hours on the problem. I apologize for the ranting. But I sometimes
feel, that Linux development is done under the assumption that
everybody has tons of midnight oil to burn.
Daniel and I are testing and reviewing every patch we are
forwarding to the wireless mailing list. It's not nice to spend
one to two hours again to adapt and test the pending patches,
because somebody has renamed the driver directory again.
> If you are determined not to have it in 2.6.24 then I will relent.
> I will also suggest that Larry start sending any softmac bugs to
> you... :-)
I think I have ranted enough. :-)
>
> If we will be having a port rather than a new driver, how soon after
> 2.6.24-rc1 closes can we queue the port for 2.6.25? I think it
> should be almost immediately, to ensure maximum test exposure and to
> "seal the deal". What do you think?
My minimum criteria for mainline inclusion are:
1) The driver doesn't crash anymore while playing around with
multiple interfaces. (I have to check this.)
2) A reasonable name has been chosen. My suggestion is zd1211mac.
A real high-quality driver will require Johannes' proposed
mac80211 driver interface changes to be merged and TX
confirmations handled in a way, that the semantics can really be
supported by the driver. (Michael Buesh's patch is taping over the
issue.)
Thanks,
Uli
--
Uli Kunitz
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Patrick McHardy @ 2007-09-22 10:53 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Thomas Gleixner, Oliver Hartkopp,
Oliver Hartkopp
In-Reply-To: <ygfzlzfuccs.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
>
>
>>You drop the module reference again when leaving this function.
>>So sock->ops might contain a stale pointer if the module is
>>unloaded after this. You need to either keep the module reference
>>while the socket is alive or remove stale references when
>>unregistering the protocol.
>
>
> I don't think that can happen. Before we drop the module reference we
> call sk_alloc() which gets another module reference via its cp->prot
> argument. If sk_alloc() fails we return with error from can_create()
> I assume sock->ops won't be used after that.
You're right, that should be enough.
^ permalink raw reply
* Re: [PATCH 3/7] CAN: Add raw protocol
From: Patrick McHardy @ 2007-09-22 11:02 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Thomas Gleixner, Oliver Hartkopp,
Oliver Hartkopp
In-Reply-To: <ygfvea3u3u2.fsf@janus.isnogud.escape.de>
Urs Thuermann wrote:
> Patrick McHardy <kaber@trash.net> writes:
>>
>>>+config CAN_RAW_USER
>>>+ bool "Allow non-root users to access Raw CAN Protocol sockets"
>>
>>
>>If you plan to remove this option, it should happen before merging
>>since it affects userspace visible behaviour.
>
>
> We have discussed this and have come to the conclusion that we should
> remove permission checks completely, i.e. any user can open any CAN
> socket (raw, bcm, or whatever will be implemented in the future).
> This is because CAN is a pure broadcast network with no addresses.
> CAN frames can't be directed to only one machine or a group or to only
> one process (say one port). There is no communication between only
> two (or some number) of stations which must be protected from other
> stations.
>
> On the other hand, requiring a process to have CAP_NET_RAW to open a
> CAN socket would mean that such process would also be able to sniff on
> your ethernet or WLAN interfaces, which one probably wouldn't want.
>
> We have added that check when we still allowed the CAN raw socket to
> bind to any interface and we didn't want an unprivileged process to be
> able to read all e.g. TCP/IP traffic. Now binding is restricted to
> ARPHRD_CAN interfaces. But even without this restriction the check is
> not necessary, since all CAN sockets can only receive and send
> ETH_P_CAN packets. So even if there would be an encapsulation of CAN
> frames over ethernet or some other type of network, a normal user
> process opening a CAN socket would only be able to read/write CAN
> traffic, which should be OK without any special capability.
>
> So what do you think about this?
I believe that should be fine.
^ permalink raw reply
* Re: Distributed storage. Security attributes and ducumentation update.
From: Evgeniy Polyakov @ 2007-09-22 11:31 UTC (permalink / raw)
To: Pavel Machek; +Cc: netdev, linux-kernel, linux-fsdevel
In-Reply-To: <20070917182229.GA5966@ucw.cz>
Hi Pavel.
On Mon, Sep 17, 2007 at 06:22:30PM +0000, Pavel Machek (pavel@ucw.cz) wrote:
> > I'm pleased to announce third release of the distributed storage
> > subsystem, which allows to form a storage on top of remote and local
> > nodes, which in turn can be exported to another storage as a node to
> > form tree-like storages.
>
> How is this different from raid0/1 over nbd? Or raid0/1 over
> ata-over-ethernet?
I will repeate a quote I made for previous release:
It has number of advantages, outlined in the first release and on the
project homepage, namely:
* non-blocking processing without busy loops (compared to iSCSI and NBD)
* small, plugable architecture
* failover recovery (reconnect to remote target)
* autoconfiguration
* no additional allocatins (not including network part) - at least two
in device mapper for fast path
* very simple - try to compare with iSCSI
* works with different network protocols
* storage can be formed on top of remote nodes and be exported
simultaneously (iSCSI is peer-to-peer only, NBD
requires device mapper, is synchronous and wants
special userspace thread)
DST allows to remove any nodes and then turn it
back into the storage without
breaking the dataflow, dst core will
reconnect automatically to the
failed remote nodes, it allows to work
with detouched devices just like
with usual filesystems (in case it was
not formed as a part of linear
storage, since in that case meta
information is spreaded between nodes).
It does not require special processes on
behalf of network connection,
everything will be performed
automatically on behalf of DST core
workers, it allows to export new device,
created on top of mirror or
linear combination of the others, which
in turn can be formed on top of
another and so on...
This was designed to allow to create a
distributed storage with
completely transparent failover
recovery, with ability to detouch remote
nodes from mirror array to became
standalone realtime backups (or
snapshots) and turn it back into the
storage without stopping main
device node.
> > +|---------------- DST storate -------------------|
>
> storage?
Yep, thanks.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Please pull 'z1211' branch of wireless-2.6
From: Michael Buesch @ 2007-09-22 12:11 UTC (permalink / raw)
To: Ulrich Kunitz
Cc: John W. Linville, Daniel Drake, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070922094800.GB12327-hUSrv6EASfkEnNRfnnE9gw@public.gmane.org>
On Saturday 22 September 2007 11:48:00 Ulrich Kunitz wrote:
> A real high-quality driver will require Johannes' proposed
> mac80211 driver interface changes to be merged and TX
> confirmations handled in a way, that the semantics can really be
> supported by the driver. (Michael Buesh's patch is taping over the
> issue.)
No it is not. It is fixing the issue. It fixes the following issues:
* You must ignore the Txstat-requested bit in the driver.
* You must report bad frames with the excessive_retries set.
The issue you are (most likely) talking about is that we can not
reliably tell whether a frame was good in the driver. That is a different
issue completely seperate from the two points above, which my patch fixes.
With my patch rate-controlling correctly works. Without it does not.
If you find a way to fix the reliable-detection-of-good-TX issue, that's
another good fix. But I think it's not release critical, because the
device works with the current "guessing-around" code. But without the two
points above fixed, it does not correctly work at all (unless you manually
tune to the best rate each time you move the machine).
--
Greetings Michael.
^ permalink raw reply
* Re: Please pull 'z1211' branch of wireless-2.6
From: Ulrich Kunitz @ 2007-09-22 14:42 UTC (permalink / raw)
To: Michael Buesch
Cc: John W. Linville, Daniel Drake, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200709221411.12128.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
Michael Buesch wrote:
> On Saturday 22 September 2007 11:48:00 Ulrich Kunitz wrote:
> > A real high-quality driver will require Johannes' proposed
> > mac80211 driver interface changes to be merged and TX
> > confirmations handled in a way, that the semantics can really be
> > supported by the driver. (Michael Buesh's patch is taping over the
> > issue.)
>
> No it is not. It is fixing the issue. It fixes the following issues:
> * You must ignore the Txstat-requested bit in the driver.
If that is really the case the flag should be removed from
mac80211. There is no way for somebody looking at the code to know
this.
> * You must report bad frames with the excessive_retries set.
All bad frames or only those with actual excessive retries? Your patch
set the excessive_retries flag for packets that couldn't be
transmitted to the device because of an USB error. If the flag
should be set for all kinds of errors it should be renamed.
> The issue you are (most likely) talking about is that we can not
> reliably tell whether a frame was good in the driver. That is a different
> issue completely seperate from the two points above, which my patch fixes.
This has been the reason, why I stated "taped over".
The issues are:
* The driver cannot reliably tell, whether the transmission of
particular packet to the same address failed but is forced by
mac80211 to pretend this.
* Currently the device reports ACKs over the USB interface, which
increases the interrupt load. The ACKs can also not reliably
paired with the transmitted packet. Sending only one packet in parallel
per destination address to the device and wait for a timeout
would slow things down.
I would like to see that the driver would only be required to
report the status for single packets in critical phases like
associations. In other situations the driver should only be
requested to support statistics.
> With my patch rate-controlling correctly works. Without it does not.
> If you find a way to fix the reliable-detection-of-good-TX issue, that's
> another good fix. But I think it's not release critical, because the
> device works with the current "guessing-around" code. But without the two
> points above fixed, it does not correctly work at all (unless you manually
> tune to the best rate each time you move the machine).
Your patch clearly fixed the problem of the missing excessive
retries flag. But it should be accomponied by patches of
mac80211. One could fix the request-tx-status flag situation.
Another could rename the excessive_retries flag to tx_error.
--
Uli Kunitz
^ permalink raw reply
* Re: Please pull 'z1211' branch of wireless-2.6
From: Michael Buesch @ 2007-09-22 14:47 UTC (permalink / raw)
To: Ulrich Kunitz
Cc: John W. Linville, Daniel Drake, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070922144254.GB12907-hUSrv6EASfkEnNRfnnE9gw@public.gmane.org>
On Saturday 22 September 2007, Ulrich Kunitz wrote:
> Michael Buesch wrote:
>
> > On Saturday 22 September 2007 11:48:00 Ulrich Kunitz wrote:
> > > A real high-quality driver will require Johannes' proposed
> > > mac80211 driver interface changes to be merged and TX
> > > confirmations handled in a way, that the semantics can really be
> > > supported by the driver. (Michael Buesh's patch is taping over the
> > > issue.)
> >
> > No it is not. It is fixing the issue. It fixes the following issues:
>
> > * You must ignore the Txstat-requested bit in the driver.
>
> If that is really the case the flag should be removed from
> mac80211. There is no way for somebody looking at the code to know
> this.
It is used internally in mac80211.
> > * You must report bad frames with the excessive_retries set.
>
> All bad frames or only those with actual excessive retries? Your patch
> set the excessive_retries flag for packets that couldn't be
> transmitted to the device because of an USB error. If the flag
> should be set for all kinds of errors it should be renamed.
Well, there is no better flag to set, currently.
^ permalink raw reply
* Re: ?^?H?G Re: ?^?H?G Re: [linux-usb-devel] Please pull 'ssb-drivers' branch of wireless-2.6 -- aln.
From: Greg KH @ 2007-09-22 15:13 UTC (permalink / raw)
To: Alninuo_Li-mw3RyXb2L4OHSoWHlOhhYg
Cc: John W. Linville, David Brownell,
linux-usb-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-usb-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
mb-fseUSCV1ubazQB+pC5nmwQ, zambrano-dY08KVG/lbpWk0Htik3J/w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <OF2983FA30.A28D686E-ON4825735E.004F310B-4825735E.004F7C82-mw3RyXb2L4OHSoWHlOhhYg@public.gmane.org>
On Sat, Sep 22, 2007 at 10:28:23PM +0800, Alninuo_Li-mw3RyXb2L4OHSoWHlOhhYg@public.gmane.org wrote:
> Hi Greg,
> It should be the right name now, apologize for the typo., anyway,
> glad to get the response from u.
> I think the usbserial crash, or the printk crash is a small bug,
> likely interrupt handling, but since I have no much idea for the driver,
> so I need some helpful advice to debug on,
> And also for now, we have no much time to move from 2.4 to 2.6,
> since the time to market is no room for us, which means the full
> integration for other feature points.
Again, no one supports 2.4 anymore, so you are on your own. Remember,
the 2.4.20 kernel was released almost 5 _years_ ago. There are numerous
security holes in that kernel, as well as bugs that have been fixed in
newer releases. If you insist on using that release, you are on your
own.
good luck,
greg k-h
^ permalink raw reply
* Please pull 'fixes-davem' branch of wireless-2.6 (for 2.6.23)
From: John W. Linville @ 2007-09-22 15:41 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Dave,
These are a few more minor fixes that I would like to have in 2.6.23 if
at all possible.
Thanks!
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem/
---
The following changes since commit 81cfe79b9c577139a873483654640eb3f6e78c39:
Linus Torvalds (1):
Linux 2.6.23-rc7
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
Johannes Berg (3):
cfg80211: fix initialisation if built-in
net/mac80211/wme.c: fix sparse warning
mac80211: fix initialisation when built-in
Satyam Sharma (1):
net/wireless/sysfs.c: Shut up build warning
net/mac80211/ieee80211.c | 2 +-
net/mac80211/rc80211_simple.c | 2 +-
net/mac80211/wme.c | 2 +-
net/wireless/core.c | 2 +-
net/wireless/sysfs.c | 2 ++
5 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 7286c38..ff2172f 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -5259,7 +5259,7 @@ static void __exit ieee80211_exit(void)
}
-module_init(ieee80211_init);
+subsys_initcall(ieee80211_init);
module_exit(ieee80211_exit);
MODULE_DESCRIPTION("IEEE 802.11 subsystem");
diff --git a/net/mac80211/rc80211_simple.c b/net/mac80211/rc80211_simple.c
index f6780d6..17b9f46 100644
--- a/net/mac80211/rc80211_simple.c
+++ b/net/mac80211/rc80211_simple.c
@@ -431,7 +431,7 @@ static void __exit rate_control_simple_exit(void)
}
-module_init(rate_control_simple_init);
+subsys_initcall(rate_control_simple_init);
module_exit(rate_control_simple_exit);
MODULE_DESCRIPTION("Simple rate control algorithm for ieee80211");
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index 89ce815..7ab82b3 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -424,7 +424,7 @@ static int wme_qdiscop_init(struct Qdisc *qd, struct rtattr *opt)
skb_queue_head_init(&q->requeued[i]);
q->queues[i] = qdisc_create_dflt(qd->dev, &pfifo_qdisc_ops,
qd->handle);
- if (q->queues[i] == 0) {
+ if (!q->queues[i]) {
q->queues[i] = &noop_qdisc;
printk(KERN_ERR "%s child qdisc %i creation failed", dev->name, i);
}
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7eabd55..9771451 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -213,7 +213,7 @@ out_fail_notifier:
out_fail_sysfs:
return err;
}
-module_init(cfg80211_init);
+subsys_initcall(cfg80211_init);
static void cfg80211_exit(void)
{
diff --git a/net/wireless/sysfs.c b/net/wireless/sysfs.c
index 88aaacd..2d5d225 100644
--- a/net/wireless/sysfs.c
+++ b/net/wireless/sysfs.c
@@ -52,12 +52,14 @@ static void wiphy_dev_release(struct device *dev)
cfg80211_dev_free(rdev);
}
+#ifdef CONFIG_HOTPLUG
static int wiphy_uevent(struct device *dev, char **envp,
int num_envp, char *buf, int size)
{
/* TODO, we probably need stuff here */
return 0;
}
+#endif
struct class ieee80211_class = {
.name = "ieee80211",
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Re: bind and O_NONBLOCK
From: Evgeniy Polyakov @ 2007-09-22 16:14 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: netdev, Alan Cox
In-Reply-To: <46F35DD9.4000909@redhat.com>
Hi Ulrich.
On Thu, Sep 20, 2007 at 10:59:53PM -0700, Ulrich Drepper (drepper@redhat.com) wrote:
> Some time back Alan asked about adding O_NONBLOCK support to bind in the
> POSIX spec. I brought this up and the following text will be in the
> next revision of the POSIX spec:
>
> =======================
> If the socket address cannot be assigned immediately and O_NONBLOCK is
> set for the file descriptor for the socket, bind( ) shall fail and set
> errno to [EINPROGRESS], but the assignment request shall not be aborted,
> and the assignment shall be completed asynchronously. Subsequent calls
> to bind() for the same socket, before the assignment is completed, shall
> fail and set errno to [EALREADY].
>
> When the assignment has been performed asynchronously, pselect(),
> select(), and poll() shall indicate that the file descriptor for the
> socket is ready for reading and writing.
> =======================
>
> It would be ideal if we'd have such an implementation in the next few
> months so that we, in theory, can check whether the text in the
> specification makes sense.
On behalf of which process this is supposed to be done?
Network does not have any async processing units to perform this kind
of operations. There are four ways where bind can fail:
1. unsufficient rights - nothing can help here
2. there is no memory - async binding can not help here too, since it
some memory just has to be allocated to save async request
somewhere.
3. socket is locked.
4. addres is being bound is in use.
We can wait until it is released and perform binding on behalf of some
other process in both situations, although I think we do not want 4'th
variant in some cases.
So, did I understand you correctly, that you want to introduce network
AIO here? (for example on behalf of work queue or something else?)
--
Evgeniy Polyakov
^ permalink raw reply
* Re: bind and O_NONBLOCK
From: Ulrich Drepper @ 2007-09-22 16:21 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, Alan Cox
In-Reply-To: <20070922161414.GA29637@2ka.mipt.ru>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Evgeniy Polyakov wrote:
> So, did I understand you correctly, that you want to introduce network
> AIO here? (for example on behalf of work queue or something else?)
See Alan's mail. All this was his proposal, I just got it accepted
upstream.
The problem to solve is if you have a distributed network port set.
Apparently NetBIOS has it but I could also imagine this to be useful in
cluster implementations which have to appear as one machine. In this
case, before binding to a given port, you have to make sure no other
machine already handles this port.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG9UDy2ijCOnn/RHQRAvntAKC6F6Pz6zHd/iZLFECOZ0MxlhdPBQCgjrLC
V9cazPF5jjf2eUSr7ZKDSas=
=0v1W
-----END PGP SIGNATURE-----
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6 (for 2.6.23)
From: John W. Linville @ 2007-09-22 16:08 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
Jeff,
One of these is a fairly obvious one-liner (COMPATIBLE_IOCTL). The other is
a bit more complicated, but fixes a problem created by a patch already
in 2.6.23 (reported this week by Yoshifuji). Please pull this for
2.6.23 if at all possible.
Thanks!
John
---
Individual patches are here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit 81cfe79b9c577139a873483654640eb3f6e78c39:
Linus Torvalds (1):
Linux 2.6.23-rc7
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Jean Tourrilhes (1):
WE : Add missing auth compat-ioctl
Larry Finger (1):
softmac: Fix inability to associate with WEP networks
fs/compat_ioctl.c | 2 +
net/ieee80211/softmac/ieee80211softmac_assoc.c | 2 -
net/ieee80211/softmac/ieee80211softmac_wx.c | 54 +++++++++---------------
3 files changed, 22 insertions(+), 36 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 5a5b711..37310b0 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -3190,6 +3190,8 @@ COMPATIBLE_IOCTL(SIOCSIWRETRY)
COMPATIBLE_IOCTL(SIOCGIWRETRY)
COMPATIBLE_IOCTL(SIOCSIWPOWER)
COMPATIBLE_IOCTL(SIOCGIWPOWER)
+COMPATIBLE_IOCTL(SIOCSIWAUTH)
+COMPATIBLE_IOCTL(SIOCGIWAUTH)
/* hiddev */
COMPATIBLE_IOCTL(HIDIOCGVERSION)
COMPATIBLE_IOCTL(HIDIOCAPPLICATION)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index afb6c66..e475f2e 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -273,8 +273,6 @@ ieee80211softmac_assoc_work(struct work_struct *work)
ieee80211softmac_notify(mac->dev, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify_scan, NULL);
if (ieee80211softmac_start_scan(mac)) {
dprintk(KERN_INFO PFX "Associate: failed to initiate scan. Is device up?\n");
- mac->associnfo.associating = 0;
- mac->associnfo.associated = 0;
}
goto out;
} else {
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index d054e92..442b987 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -70,44 +70,30 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,
char *extra)
{
struct ieee80211softmac_device *sm = ieee80211_priv(net_dev);
- struct ieee80211softmac_network *n;
struct ieee80211softmac_auth_queue_item *authptr;
int length = 0;
check_assoc_again:
mutex_lock(&sm->associnfo.mutex);
- /* Check if we're already associating to this or another network
- * If it's another network, cancel and start over with our new network
- * If it's our network, ignore the change, we're already doing it!
- */
if((sm->associnfo.associating || sm->associnfo.associated) &&
(data->essid.flags && data->essid.length)) {
- /* Get the associating network */
- n = ieee80211softmac_get_network_by_bssid(sm, sm->associnfo.bssid);
- if(n && n->essid.len == data->essid.length &&
- !memcmp(n->essid.data, extra, n->essid.len)) {
- dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
- MAC_ARG(sm->associnfo.bssid));
- goto out;
- } else {
- dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
- /* Cancel assoc work */
- cancel_delayed_work(&sm->associnfo.work);
- /* We don't have to do this, but it's a little cleaner */
- list_for_each_entry(authptr, &sm->auth_queue, list)
- cancel_delayed_work(&authptr->work);
- sm->associnfo.bssvalid = 0;
- sm->associnfo.bssfixed = 0;
- sm->associnfo.associating = 0;
- sm->associnfo.associated = 0;
- /* We must unlock to avoid deadlocks with the assoc workqueue
- * on the associnfo.mutex */
- mutex_unlock(&sm->associnfo.mutex);
- flush_scheduled_work();
- /* Avoid race! Check assoc status again. Maybe someone started an
- * association while we flushed. */
- goto check_assoc_again;
- }
+ dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
+ /* Cancel assoc work */
+ cancel_delayed_work(&sm->associnfo.work);
+ /* We don't have to do this, but it's a little cleaner */
+ list_for_each_entry(authptr, &sm->auth_queue, list)
+ cancel_delayed_work(&authptr->work);
+ sm->associnfo.bssvalid = 0;
+ sm->associnfo.bssfixed = 0;
+ sm->associnfo.associating = 0;
+ sm->associnfo.associated = 0;
+ /* We must unlock to avoid deadlocks with the assoc workqueue
+ * on the associnfo.mutex */
+ mutex_unlock(&sm->associnfo.mutex);
+ flush_scheduled_work();
+ /* Avoid race! Check assoc status again. Maybe someone started an
+ * association while we flushed. */
+ goto check_assoc_again;
}
sm->associnfo.static_essid = 0;
@@ -153,13 +139,13 @@ ieee80211softmac_wx_get_essid(struct net_device *net_dev,
data->essid.length = sm->associnfo.req_essid.len;
data->essid.flags = 1; /* active */
memcpy(extra, sm->associnfo.req_essid.data, sm->associnfo.req_essid.len);
- }
-
+ dprintk(KERN_INFO PFX "Getting essid from req_essid\n");
+ } else if (sm->associnfo.associated || sm->associnfo.associating) {
/* If we're associating/associated, return that */
- if (sm->associnfo.associated || sm->associnfo.associating) {
data->essid.length = sm->associnfo.associate_essid.len;
data->essid.flags = 1; /* active */
memcpy(extra, sm->associnfo.associate_essid.data, sm->associnfo.associate_essid.len);
+ dprintk(KERN_INFO PFX "Getting essid from associate_essid\n");
}
mutex_unlock(&sm->associnfo.mutex);
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Re: bind and O_NONBLOCK
From: Evgeniy Polyakov @ 2007-09-22 16:59 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: netdev, Alan Cox
In-Reply-To: <46F540F2.1090109@redhat.com>
On Sat, Sep 22, 2007 at 09:21:06AM -0700, Ulrich Drepper (drepper@redhat.com) wrote:
> Evgeniy Polyakov wrote:
> > So, did I understand you correctly, that you want to introduce network
> > AIO here? (for example on behalf of work queue or something else?)
>
> See Alan's mail. All this was his proposal, I just got it accepted
> upstream.
>
> The problem to solve is if you have a distributed network port set.
> Apparently NetBIOS has it but I could also imagine this to be useful in
> cluster implementations which have to appear as one machine. In this
> case, before binding to a given port, you have to make sure no other
> machine already handles this port.
Yes, to handle bind conflict in some or another way.
Could you point to the original Alan's proposal, I only found short note
(as in you original mail) at opengroup.org and failed to correctly
googlify it in the web.
--
Evgeniy Polyakov
^ 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