* Re: [patch 2/5] s2io driver updates
From: Stephen Hemminger @ 2006-04-24 17:22 UTC (permalink / raw)
To: Francois Romieu
Cc: Ananda Raju, jgarzik, netdev, leonid.grossman, ravinandan.arakali,
rapuru.sriram, alicia.pena
In-Reply-To: <20060422092802.GD26666@electric-eye.fr.zoreil.com>
On Sat, 22 Apr 2006 11:28:02 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Ananda Raju <Ananda.Raju@neterion.com> :
> [...]
> > Signed-off-by: Ananda Raju <ananda.raju@neterion.com>
> > ---
> > diff -upNr perf_fixes/drivers/net/s2io.c dmesg_param_fixes/drivers/net/s2io.c
> > --- perf_fixes/drivers/net/s2io.c 2006-04-13 08:02:56.000000000 -0700
> > +++ dmesg_param_fixes/drivers/net/s2io.c 2006-04-13 09:08:22.000000000 -0700
> [...]
> > @@ -4626,6 +4633,45 @@ static int write_eeprom(nic_t * sp, int
> > return ret;
> > }
> >
> > +static void s2io_vpd_read(nic_t *nic)
> > +{
> > + u8 vpd_data[256],data;
>
> You may consider removing vpd_data from the stack and kmallocing it.
>
Since there lsvpd tool doesn't in user space, why add more kernel code
to do it? Adding more code to just print prettier console log's is bogus.
^ permalink raw reply
* Re: [PATCH 02/11] ixgb: Fix the use of dprintk rather than printk
From: Stephen Hemminger @ 2006-04-24 17:24 UTC (permalink / raw)
To: Francois Romieu
Cc: Jeff Kirsher, Jeff Garzik, netdev, David Miller, John Rociak,
Jesse Brandeburg
In-Reply-To: <20060422090301.GB26666@electric-eye.fr.zoreil.com>
On Sat, 22 Apr 2006 11:03:01 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> :
> [...]
> > diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
> > index c83271b..a696c33 100644
> > --- a/drivers/net/ixgb/ixgb.h
> > +++ b/drivers/net/ixgb/ixgb.h
> [...]
> > @@ -192,6 +197,7 @@ struct ixgb_adapter {
> >
> > /* structs defined in ixgb_hw.h */
> > struct ixgb_hw hw;
> > + u16 msg_enable;
> > struct ixgb_hw_stats stats;
> > #ifdef CONFIG_PCI_MSI
> > boolean_t have_msi;
> > diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
> > index d38ade5..e8d83de 100644
> > --- a/drivers/net/ixgb/ixgb_ethtool.c
> > +++ b/drivers/net/ixgb/ixgb_ethtool.c
> > @@ -251,6 +251,20 @@ ixgb_set_tso(struct net_device *netdev,
> > }
> > #endif /* NETIF_F_TSO */
> >
> > +static uint32_t
> > +ixgb_get_msglevel(struct net_device *netdev)
> > +{
> > + struct ixgb_adapter *adapter = netdev->priv;
> > + return adapter->msg_enable;
> > +}
> > +
> > +static void
> > +ixgb_set_msglevel(struct net_device *netdev, uint32_t data)
> > +{
> > + struct ixgb_adapter *adapter = netdev->priv;
> > + adapter->msg_enable = data;
> > +}
> > +
>
> Minor nits:
> - you may consider removing the u{8/16/32} in drivers/net/ixgb
> for consistency sake in a different patch (there is a strong
> majority of uint_something in the driver).
All the uint32_t should be removed. Kernel style is u32.
^ permalink raw reply
* RE: Van Jacobson's net channels and real-time
From: Caitlin Bestler @ 2006-04-24 17:28 UTC (permalink / raw)
To: netdev
netdev-owner@vger.kernel.org wrote:
> Subject: Re: Van Jacobson's net channels and real-time
>
>
> On Mon, 24 Apr 2006, Auke Kok wrote:
>
>> Ingo Oeser wrote:
>>> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
>>>> That was another main point, yes. And the endpoints should be as
>>>> little burden on the bottlenecks as possible. One bottleneck is
>>>> the receive interrupt, which shouldn't wait for cachelines from
>>>> other cpus too much.
>>>
>>> Thats right. This will be made a non issue with early demuxing on
>>> the NIC and MSI (or was it MSI-X?) which will select the right CPU
>>> based on hardware channels.
>>
>> MSI-X. with MSI you still have only one cpu handling all MSI
>> interrupts and that doesn't look any different than ordinary
>> interrupts. MSI-X will allow much better interrupt handling across
>> several cpu's.
>>
>> Auke
>> -
>
> Message signaled interrupts are just a kudge to save a trace
> on a PC board (read make junk cheaper still). They are not
> faster and may even be slower. They will not be the salvation
> of any interrupt latency problems. The solutions for
> increasing networking speed, where the bit-rate on the wire
> gets close to the bit-rate on the bus, is to put more and
> more of the networking code inside the network board. The CPU
> get interrupted after most things (like network handshakes)
> are complete.
>
The number of hardware interrupts supported is a bit out of scope.
Whatever the capacity is, the key is to have as few meaningless
interrupts as possible.
In the context of netchannels this would mean that an interrupt
should only be fired when there is a sufficient number of packets
for the user-mode code to process. Fully offloading the protocol
to the hardware is certainly one option, that I also thinks make
sense, but the goal of netchannels is to try to optimize performance
while keeping TCP processing on host.
More hardware offload is distinctly possible and relevant in this
context. Statefull offload, such as TSO, are fully relevant.
Going directly from the NIC to the channel is also possible (after
the channel is set up by the kernel, of course). If the NIC is
aware of the channels directly then interrupts can be limited to
packets that cross per-channel thresholds configured directly
by the ring consumer.
^ permalink raw reply
* Re: Congestion Avoidance Monitoring Tools
From: Stephen Hemminger @ 2006-04-24 17:39 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: piet, netdev, linux-net
In-Reply-To: <20060423225235.GA23714@c3po.0xdef.net>
On Mon, 24 Apr 2006 00:52:35 +0200
Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> * Stephen Hemminger | 2006-04-21 08:19:17 [-0700]:
>
> >2.6.13 still had lots of problems, things didn't really get working
> >right till 2.6.15 or later. Especially with TSO.
>
> --verbose?
>
> >I have a tool using kprobe's see http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz
> >I try to keep it up to date with current kernel and build process, last used it
> >on 2.6.16.
>
> wget http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz
>
> Ended with following error code: ;-)
>
> 00:32:48 ERROR 403: Forbidden.
>
> HGN
>
Fixed
^ permalink raw reply
* RE: [patch 2/5] s2io driver updates
From: Ananda Raju @ 2006-04-24 17:39 UTC (permalink / raw)
To: 'Stephen Hemminger', 'Francois Romieu'
Cc: jgarzik, netdev, leonid.grossman, ravinandan.arakali,
rapuru.sriram, alicia.pena
In-Reply-To: <20060424102203.3cb5e29b@localhost.localdomain>
Hi,
Currently the only way we can differentiate between copper CX4 transponder
adapters from optical transponder adapters is by reading the product name
string in vpd.
Actually we added the VPD read function for identifying CX4 adapter. While
submitting the patch the CX4 changes went in patch 3 and reading of vpd went
in patch 2.
Also we have one more product Xframe-E which is a PCIe adapter. This also
has same device ID of Xframe-II PCI-X adapter. As we have multiple product
with same Device_ID and only way to differentiate between them is through
VPD string we are reading VPD string in driver.
Thanks
Ananda.
-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@osdl.org]
Sent: Monday, April 24, 2006 10:22 AM
To: Francois Romieu
Cc: Ananda Raju; jgarzik@pobox.com; netdev@vger.kernel.org;
leonid.grossman@neterion.com; ravinandan.arakali@neterion.com;
rapuru.sriram@neterion.com; alicia.pena@neterion.com
Subject: Re: [patch 2/5] s2io driver updates
On Sat, 22 Apr 2006 11:28:02 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Ananda Raju <Ananda.Raju@neterion.com> :
> [...]
> > Signed-off-by: Ananda Raju <ananda.raju@neterion.com>
> > ---
> > diff -upNr perf_fixes/drivers/net/s2io.c
dmesg_param_fixes/drivers/net/s2io.c
> > --- perf_fixes/drivers/net/s2io.c 2006-04-13 08:02:56.000000000 -0700
> > +++ dmesg_param_fixes/drivers/net/s2io.c 2006-04-13
09:08:22.000000000 -0700
> [...]
> > @@ -4626,6 +4633,45 @@ static int write_eeprom(nic_t * sp, int
> > return ret;
> > }
> >
> > +static void s2io_vpd_read(nic_t *nic)
> > +{
> > + u8 vpd_data[256],data;
>
> You may consider removing vpd_data from the stack and kmallocing it.
>
Since there lsvpd tool doesn't in user space, why add more kernel code
to do it? Adding more code to just print prettier console log's is bogus.
^ permalink raw reply
* Re: [patch 2/5] s2io driver updates
From: Stephen Hemminger @ 2006-04-24 17:57 UTC (permalink / raw)
To: Ananda Raju
Cc: 'Francois Romieu', jgarzik, netdev, leonid.grossman,
ravinandan.arakali, rapuru.sriram, alicia.pena
In-Reply-To: <200604241740.k3OHepDr023452@guinness.s2io.com>
On Mon, 24 Apr 2006 10:39:52 -0700
"Ananda Raju" <ananda.raju@neterion.com> wrote:
> Hi,
>
> Currently the only way we can differentiate between copper CX4 transponder
> adapters from optical transponder adapters is by reading the product name
> string in vpd.
That makes sense. Though often the VPD can be messed up by OEM's. Probably
not a big issue with this driver.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: linux-os (Dick Johnson) @ 2006-04-24 18:12 UTC (permalink / raw)
To: Rick Jones
Cc: Auke Kok, Ingo Oeser, Jörn Engel, Ingo Oeser,
David S. Miller, simlo, linux-kernel, mingo, netdev
In-Reply-To: <444D08A8.3060908@hp.com>
On Mon, 24 Apr 2006, Rick Jones wrote:
>>>> Thats right. This will be made a non issue with early demuxing
>>>> on the NIC and MSI (or was it MSI-X?) which will select
>>>> the right CPU based on hardware channels.
>>>
>>> MSI-X. with MSI you still have only one cpu handling all MSI interrupts and
>>> that doesn't look any different than ordinary interrupts. MSI-X will allow
>>> much better interrupt handling across several cpu's.
>>>
>>> Auke
>>> -
>>
>>
>> Message signaled interrupts are just a kudge to save a trace on a
>> PC board (read make junk cheaper still). They are not faster and
>> may even be slower. They will not be the salvation of any interrupt
>> latency problems. The solutions for increasing networking speed,
>> where the bit-rate on the wire gets close to the bit-rate on the
>> bus, is to put more and more of the networking code inside the
>> network board. The CPU get interrupted after most things (like
>> network handshakes) are complete.
>
> if the issue is bus vs network bitrates would offloading really buy that
> much? i suppose that for minimum sized packets not DMA'ing the headers
> across the bus would be a decent win, but down at small packet sizes
> where headers would be 1/3 to 1/2 the stuff DMA'd around, I would think
> one is talking more about CPU path lengths than bus bitrates.
>
> and up and "full size" segments, since everyone is so fond of bulk
> transfer tests, the transfer saved by not shovig headers across the bus
> is what 54/1448 or ~3.75%
>
> spreading interrupts via MSI-X seems nice and all, but i keep wondering
> if the header field-based distribution that is (will be) done by the
> NICs is putting the cart before the horse - should the NIC essentially
> be telling the system the CPU on which to run the application, or should
> the CPU on which the application runs be telling "networking" where it
> should be happening?
>
> rick jones
>
Ideally, TCP/IP is so mature that one should be able to tell some
hardware state-machine "Connect with 123.555.44.333, port 23" and
it signals via interrupt when that happens. Then one should be
able to say "send these data to that address" or "fill this buffer
with data from that address". All the networking could be done
on the board, perhaps with a dedicated CPU (as is now done) or
all in silicon.
So, the driver end of the networking software just handles
buffers. There are interrupts that show status such as
completions or time-outs, trivial stuff.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* RE: [patch 2/5] s2io driver updates
From: Ananda Raju @ 2006-04-24 18:20 UTC (permalink / raw)
To: 'Francois Romieu'
Cc: jgarzik, netdev, leonid.grossman, ravinandan.arakali,
rapuru.sriram, alicia.pena
In-Reply-To: <20060422092802.GD26666@electric-eye.fr.zoreil.com>
Hi
We will consider moving vpd_data out of stack. We will wait for few more
time for other review comment, and submit one more patch on top of 5th patch
addressing all review comments.
If there are no further comments please apply the patches 1 to 5 and notify
us. We will submit one more patch which addressing all review comments.
Thanks
Ananda
-----Original Message-----
From: Francois Romieu [mailto:romieu@fr.zoreil.com]
Sent: Saturday, April 22, 2006 2:28 AM
To: Ananda Raju
Cc: jgarzik@pobox.com; netdev@vger.kernel.org; leonid.grossman@neterion.com;
ravinandan.arakali@neterion.com; rapuru.sriram@neterion.com;
alicia.pena@neterion.com
Subject: Re: [patch 2/5] s2io driver updates
Ananda Raju <Ananda.Raju@neterion.com> :
[...]
> Signed-off-by: Ananda Raju <ananda.raju@neterion.com>
> ---
> diff -upNr perf_fixes/drivers/net/s2io.c
dmesg_param_fixes/drivers/net/s2io.c
> --- perf_fixes/drivers/net/s2io.c 2006-04-13 08:02:56.000000000 -0700
> +++ dmesg_param_fixes/drivers/net/s2io.c 2006-04-13
09:08:22.000000000 -0700
[...]
> @@ -4626,6 +4633,45 @@ static int write_eeprom(nic_t * sp, int
> return ret;
> }
>
> +static void s2io_vpd_read(nic_t *nic)
> +{
> + u8 vpd_data[256],data;
You may consider removing vpd_data from the stack and kmallocing it.
--
Ueimor
^ permalink raw reply
* Please pull 'upstream-fixes' branch of wireless-2.6
From: John W. Linville @ 2006-04-24 19:40 UTC (permalink / raw)
To: jeff; +Cc: netdev
The following changes since commit 6b426e785cb81e53dc2fc4dcf997661472b470ef:
Linus Torvalds:
Merge git://git.kernel.org/.../kyle/parisc-2.6
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes
Johannes Berg:
softmac: fix SIOCSIWAP
Michael Buesch:
bcm43xx: add to MAINTAINERS
bcm43xx: make PIO mode usable
Pavel Roskin:
Fix crash on big-endian systems during scan
MAINTAINERS | 8 ++
drivers/net/wireless/bcm43xx/bcm43xx_dma.h | 8 ++
drivers/net/wireless/bcm43xx/bcm43xx_pio.c | 92 ++++++++++++++++-------
drivers/net/wireless/bcm43xx/bcm43xx_pio.h | 16 ++++
drivers/net/wireless/hostap/hostap_ioctl.c | 4 +
include/net/ieee80211softmac.h | 5 +
net/ieee80211/softmac/ieee80211softmac_assoc.c | 20 ++++-
net/ieee80211/softmac/ieee80211softmac_module.c | 2 +
net/ieee80211/softmac/ieee80211softmac_wx.c | 27 ++++---
9 files changed, 133 insertions(+), 49 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e1e817..d6a8e5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -421,6 +421,14 @@ L: linux-hams@vger.kernel.org
W: http://www.baycom.org/~tom/ham/ham.html
S: Maintained
+BCM43XX WIRELESS DRIVER
+P: Michael Buesch
+M: mb@bu3sch.de
+P: Stefano Brivio
+M: st3@riseup.net
+W: http://bcm43xx.berlios.de/
+S: Maintained
+
BEFS FILE SYSTEM
P: Sergey S. Kostyliov
M: rathamahata@php4.ru
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.h b/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
index 2d520e4..b7d7763 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
@@ -213,6 +213,14 @@ static inline
void bcm43xx_dma_rx(struct bcm43xx_dmaring *ring)
{
}
+static inline
+void bcm43xx_dma_tx_suspend(struct bcm43xx_dmaring *ring)
+{
+}
+static inline
+void bcm43xx_dma_tx_resume(struct bcm43xx_dmaring *ring)
+{
+}
#endif /* CONFIG_BCM43XX_DMA */
#endif /* BCM43xx_DMA_H_ */
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_pio.c b/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
index c59ddd4..0aa1bd2 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
@@ -27,6 +27,7 @@
#include "bcm43xx_pio.h"
#include "bcm43xx_main.h"
#include "bcm43xx_xmit.h"
+#include "bcm43xx_power.h"
#include <linux/delay.h>
@@ -44,10 +45,10 @@ static void tx_octet(struct bcm43xx_pioq
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
}
@@ -103,7 +104,7 @@ static void tx_complete(struct bcm43xx_p
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
skb->data[skb->len - 1]);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI |
+ BCM43xx_PIO_TXCTL_WRITELO |
BCM43xx_PIO_TXCTL_COMPLETE);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
@@ -112,9 +113,10 @@ static void tx_complete(struct bcm43xx_p
}
static u16 generate_cookie(struct bcm43xx_pioqueue *queue,
- int packetindex)
+ struct bcm43xx_pio_txpacket *packet)
{
u16 cookie = 0x0000;
+ int packetindex;
/* We use the upper 4 bits for the PIO
* controller ID and the lower 12 bits
@@ -135,6 +137,7 @@ static u16 generate_cookie(struct bcm43x
default:
assert(0);
}
+ packetindex = pio_txpacket_getindex(packet);
assert(((u16)packetindex & 0xF000) == 0x0000);
cookie |= (u16)packetindex;
@@ -184,7 +187,7 @@ static void pio_tx_write_fragment(struct
bcm43xx_generate_txhdr(queue->bcm,
&txhdr, skb->data, skb->len,
(packet->xmitted_frags == 0),
- generate_cookie(queue, pio_txpacket_getindex(packet)));
+ generate_cookie(queue, packet));
tx_start(queue);
octets = skb->len + sizeof(txhdr);
@@ -241,7 +244,7 @@ static int pio_tx_packet(struct bcm43xx_
queue->tx_devq_packets++;
queue->tx_devq_used += octets;
- assert(packet->xmitted_frags <= packet->txb->nr_frags);
+ assert(packet->xmitted_frags < packet->txb->nr_frags);
packet->xmitted_frags++;
packet->xmitted_octets += octets;
}
@@ -257,8 +260,14 @@ static void tx_tasklet(unsigned long d)
unsigned long flags;
struct bcm43xx_pio_txpacket *packet, *tmp_packet;
int err;
+ u16 txctl;
bcm43xx_lock_mmio(bcm, flags);
+
+ txctl = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
+ if (txctl & BCM43xx_PIO_TXCTL_SUSPEND)
+ goto out_unlock;
+
list_for_each_entry_safe(packet, tmp_packet, &queue->txqueue, list) {
assert(packet->xmitted_frags < packet->txb->nr_frags);
if (packet->xmitted_frags == 0) {
@@ -288,6 +297,7 @@ static void tx_tasklet(unsigned long d)
next_packet:
continue;
}
+out_unlock:
bcm43xx_unlock_mmio(bcm, flags);
}
@@ -330,12 +340,19 @@ struct bcm43xx_pioqueue * bcm43xx_setup_
(unsigned long)queue);
value = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- value |= BCM43xx_SBF_XFER_REG_BYTESWAP;
+ value &= ~BCM43xx_SBF_XFER_REG_BYTESWAP;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, value);
qsize = bcm43xx_read16(bcm, queue->mmio_base + BCM43xx_PIO_TXQBUFSIZE);
+ if (qsize == 0) {
+ printk(KERN_ERR PFX "ERROR: This card does not support PIO "
+ "operation mode. Please use DMA mode "
+ "(module parameter pio=0).\n");
+ goto err_freequeue;
+ }
if (qsize <= BCM43xx_PIO_TXQADJUST) {
- printk(KERN_ERR PFX "PIO tx device-queue too small (%u)\n", qsize);
+ printk(KERN_ERR PFX "PIO tx device-queue too small (%u)\n",
+ qsize);
goto err_freequeue;
}
qsize -= BCM43xx_PIO_TXQADJUST;
@@ -444,15 +461,10 @@ int bcm43xx_pio_tx(struct bcm43xx_privat
{
struct bcm43xx_pioqueue *queue = bcm43xx_current_pio(bcm)->queue1;
struct bcm43xx_pio_txpacket *packet;
- u16 tmp;
assert(!queue->tx_suspended);
assert(!list_empty(&queue->txfree));
- tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL);
- if (tmp & BCM43xx_PIO_TXCTL_SUSPEND)
- return -EBUSY;
-
packet = list_entry(queue->txfree.next, struct bcm43xx_pio_txpacket, list);
packet->txb = txb;
packet->xmitted_frags = 0;
@@ -462,7 +474,7 @@ int bcm43xx_pio_tx(struct bcm43xx_privat
assert(queue->nr_txfree < BCM43xx_PIO_MAXTXPACKETS);
/* Suspend TX, if we are out of packets in the "free" queue. */
- if (unlikely(list_empty(&queue->txfree))) {
+ if (list_empty(&queue->txfree)) {
netif_stop_queue(queue->bcm->net_dev);
queue->tx_suspended = 1;
}
@@ -480,15 +492,15 @@ void bcm43xx_pio_handle_xmitstatus(struc
queue = parse_cookie(bcm, status->cookie, &packet);
assert(queue);
-//TODO
-if (!queue)
-return;
+
free_txpacket(packet, 1);
- if (unlikely(queue->tx_suspended)) {
+ if (queue->tx_suspended) {
queue->tx_suspended = 0;
netif_wake_queue(queue->bcm->net_dev);
}
- /* If there are packets on the txqueue, poke the tasklet. */
+ /* If there are packets on the txqueue, poke the tasklet
+ * to transmit them.
+ */
if (!list_empty(&queue->txqueue))
tasklet_schedule(&queue->txtask);
}
@@ -519,12 +531,9 @@ void bcm43xx_pio_rx(struct bcm43xx_pioqu
int i, preamble_readwords;
struct sk_buff *skb;
-return;
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXCTL);
- if (!(tmp & BCM43xx_PIO_RXCTL_DATAAVAILABLE)) {
- dprintkl(KERN_ERR PFX "PIO RX: No data available\n");//TODO: remove this printk.
+ if (!(tmp & BCM43xx_PIO_RXCTL_DATAAVAILABLE))
return;
- }
bcm43xx_pio_write(queue, BCM43xx_PIO_RXCTL,
BCM43xx_PIO_RXCTL_DATAAVAILABLE);
@@ -538,8 +547,7 @@ return;
return;
data_ready:
-//FIXME: endianess in this function.
- len = le16_to_cpu(bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA));
+ len = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
if (unlikely(len > 0x700)) {
pio_rx_error(queue, 0, "len > 0x700");
return;
@@ -555,7 +563,7 @@ data_ready:
preamble_readwords = 18 / sizeof(u16);
for (i = 0; i < preamble_readwords; i++) {
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
- preamble[i + 1] = cpu_to_be16(tmp);//FIXME?
+ preamble[i + 1] = cpu_to_le16(tmp);
}
rxhdr = (struct bcm43xx_rxhdr *)preamble;
rxflags2 = le16_to_cpu(rxhdr->flags2);
@@ -591,16 +599,40 @@ data_ready:
}
skb_put(skb, len);
for (i = 0; i < len - 1; i += 2) {
- tmp = cpu_to_be16(bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA));
- *((u16 *)(skb->data + i)) = tmp;
+ tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
+ *((u16 *)(skb->data + i)) = cpu_to_le16(tmp);
}
if (len % 2) {
tmp = bcm43xx_pio_read(queue, BCM43xx_PIO_RXDATA);
skb->data[len - 1] = (tmp & 0x00FF);
+/* The specs say the following is required, but
+ * it is wrong and corrupts the PLCP. If we don't do
+ * this, the PLCP seems to be correct. So ifdef it out for now.
+ */
+#if 0
if (rxflags2 & BCM43xx_RXHDR_FLAGS2_TYPE2FRAME)
- skb->data[0x20] = (tmp & 0xFF00) >> 8;
+ skb->data[2] = (tmp & 0xFF00) >> 8;
else
- skb->data[0x1E] = (tmp & 0xFF00) >> 8;
+ skb->data[0] = (tmp & 0xFF00) >> 8;
+#endif
}
+ skb_trim(skb, len - IEEE80211_FCS_LEN);
bcm43xx_rx(queue->bcm, skb, rxhdr);
}
+
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue)
+{
+ bcm43xx_power_saving_ctl_bits(queue->bcm, -1, 1);
+ bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
+ bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL)
+ | BCM43xx_PIO_TXCTL_SUSPEND);
+}
+
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue)
+{
+ bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
+ bcm43xx_pio_read(queue, BCM43xx_PIO_TXCTL)
+ & ~BCM43xx_PIO_TXCTL_SUSPEND);
+ bcm43xx_power_saving_ctl_bits(queue->bcm, -1, -1);
+ tasklet_schedule(&queue->txtask);
+}
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_pio.h b/drivers/net/wireless/bcm43xx/bcm43xx_pio.h
index 970627b..dfc7820 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_pio.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_pio.h
@@ -14,8 +14,8 @@
#define BCM43xx_PIO_RXCTL 0x08
#define BCM43xx_PIO_RXDATA 0x0A
-#define BCM43xx_PIO_TXCTL_WRITEHI (1 << 0)
-#define BCM43xx_PIO_TXCTL_WRITELO (1 << 1)
+#define BCM43xx_PIO_TXCTL_WRITELO (1 << 0)
+#define BCM43xx_PIO_TXCTL_WRITEHI (1 << 1)
#define BCM43xx_PIO_TXCTL_COMPLETE (1 << 2)
#define BCM43xx_PIO_TXCTL_INIT (1 << 3)
#define BCM43xx_PIO_TXCTL_SUSPEND (1 << 7)
@@ -95,6 +95,7 @@ void bcm43xx_pio_write(struct bcm43xx_pi
u16 offset, u16 value)
{
bcm43xx_write16(queue->bcm, queue->mmio_base + offset, value);
+ mmiowb();
}
@@ -107,6 +108,9 @@ void bcm43xx_pio_handle_xmitstatus(struc
struct bcm43xx_xmitstatus *status);
void bcm43xx_pio_rx(struct bcm43xx_pioqueue *queue);
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue);
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue);
+
#else /* CONFIG_BCM43XX_PIO */
static inline
@@ -133,6 +137,14 @@ static inline
void bcm43xx_pio_rx(struct bcm43xx_pioqueue *queue)
{
}
+static inline
+void bcm43xx_pio_tx_suspend(struct bcm43xx_pioqueue *queue)
+{
+}
+static inline
+void bcm43xx_pio_tx_resume(struct bcm43xx_pioqueue *queue)
+{
+}
#endif /* CONFIG_BCM43XX_PIO */
#endif /* BCM43xx_PIO_H_ */
diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
index 8b37e82..8399de5 100644
--- a/drivers/net/wireless/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -1860,7 +1860,7 @@ static char * __prism2_translate_scan(lo
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
if (scan) {
- chan = scan->chid;
+ chan = le16_to_cpu(scan->chid);
} else if (bss) {
chan = bss->chan;
} else {
@@ -1868,7 +1868,7 @@ static char * __prism2_translate_scan(lo
}
if (chan > 0) {
- iwe.u.freq.m = freq_list[le16_to_cpu(chan - 1)] * 100000;
+ iwe.u.freq.m = freq_list[chan - 1] * 100000;
iwe.u.freq.e = 1;
current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);
diff --git a/include/net/ieee80211softmac.h b/include/net/ieee80211softmac.h
index 6b3693f..b1ebfba 100644
--- a/include/net/ieee80211softmac.h
+++ b/include/net/ieee80211softmac.h
@@ -96,10 +96,13 @@ struct ieee80211softmac_assoc_info {
*
* bssvalid is true if we found a matching network
* and saved it's BSSID into the bssid above.
+ *
+ * bssfixed is used for SIOCSIWAP.
*/
u8 static_essid:1,
associating:1,
- bssvalid:1;
+ bssvalid:1,
+ bssfixed:1;
/* Scan retries remaining */
int scan_retry;
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index 4498023..fb79ce7 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -144,6 +144,12 @@ network_matches_request(struct ieee80211
if (!we_support_all_basic_rates(mac, net->rates_ex, net->rates_ex_len))
return 0;
+ /* assume that users know what they're doing ...
+ * (note we don't let them select a net we're incompatible with) */
+ if (mac->associnfo.bssfixed) {
+ return !memcmp(mac->associnfo.bssid, net->bssid, ETH_ALEN);
+ }
+
/* if 'ANY' network requested, take any that doesn't have privacy enabled */
if (mac->associnfo.req_essid.len == 0
&& !(net->capability & WLAN_CAPABILITY_PRIVACY))
@@ -176,7 +182,7 @@ ieee80211softmac_assoc_work(void *d)
ieee80211softmac_disassoc(mac, WLAN_REASON_DISASSOC_STA_HAS_LEFT);
/* try to find the requested network in our list, if we found one already */
- if (mac->associnfo.bssvalid)
+ if (mac->associnfo.bssvalid || mac->associnfo.bssfixed)
found = ieee80211softmac_get_network_by_bssid(mac, mac->associnfo.bssid);
/* Search the ieee80211 networks for this network if we didn't find it by bssid,
@@ -241,19 +247,25 @@ ieee80211softmac_assoc_work(void *d)
if (ieee80211softmac_start_scan(mac))
dprintk(KERN_INFO PFX "Associate: failed to initiate scan. Is device up?\n");
return;
- }
- else {
+ } else {
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.associating = 0;
mac->associated = 0;
spin_unlock_irqrestore(&mac->lock, flags);
dprintk(KERN_INFO PFX "Unable to find matching network after scan!\n");
+ /* reset the retry counter for the next user request since we
+ * break out and don't reschedule ourselves after this point. */
+ mac->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_NET_NOT_FOUND, NULL);
return;
}
}
-
+
+ /* reset the retry counter for the next user request since we
+ * now found a net and will try to associate to it, but not
+ * schedule this function again. */
+ mac->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
mac->associnfo.bssvalid = 1;
memcpy(mac->associnfo.bssid, found->bssid, ETH_ALEN);
/* copy the ESSID for displaying it */
diff --git a/net/ieee80211/softmac/ieee80211softmac_module.c b/net/ieee80211/softmac/ieee80211softmac_module.c
index 60f06a3..be83bdc 100644
--- a/net/ieee80211/softmac/ieee80211softmac_module.c
+++ b/net/ieee80211/softmac/ieee80211softmac_module.c
@@ -45,6 +45,8 @@ struct net_device *alloc_ieee80211softma
softmac->ieee->handle_disassoc = ieee80211softmac_handle_disassoc;
softmac->scaninfo = NULL;
+ softmac->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
+
/* TODO: initialise all the other callbacks in the ieee struct
* (once they're written)
*/
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 00f0d4f..27edb2b 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -27,7 +27,8 @@
#include "ieee80211softmac_priv.h"
#include <net/iw_handler.h>
-
+/* for is_broadcast_ether_addr and is_zero_ether_addr */
+#include <linux/etherdevice.h>
int
ieee80211softmac_wx_trigger_scan(struct net_device *net_dev,
@@ -83,7 +84,6 @@ ieee80211softmac_wx_set_essid(struct net
sm->associnfo.static_essid = 1;
}
}
- sm->associnfo.scan_retry = IEEE80211SOFTMAC_ASSOC_SCAN_RETRY_LIMIT;
/* set our requested ESSID length.
* If applicable, we have already copied the data in */
@@ -310,8 +310,6 @@ ieee80211softmac_wx_set_wap(struct net_d
char *extra)
{
struct ieee80211softmac_device *mac = ieee80211_priv(net_dev);
- static const unsigned char any[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
- static const unsigned char off[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
unsigned long flags;
/* sanity check */
@@ -320,10 +318,17 @@ ieee80211softmac_wx_set_wap(struct net_d
}
spin_lock_irqsave(&mac->lock, flags);
- if (!memcmp(any, data->ap_addr.sa_data, ETH_ALEN) ||
- !memcmp(off, data->ap_addr.sa_data, ETH_ALEN)) {
- schedule_work(&mac->associnfo.work);
- goto out;
+ if (is_broadcast_ether_addr(data->ap_addr.sa_data)) {
+ /* the bssid we have is not to be fixed any longer,
+ * and we should reassociate to the best AP. */
+ mac->associnfo.bssfixed = 0;
+ /* force reassociation */
+ mac->associnfo.bssvalid = 0;
+ if (mac->associated)
+ schedule_work(&mac->associnfo.work);
+ } else if (is_zero_ether_addr(data->ap_addr.sa_data)) {
+ /* the bssid we have is no longer fixed */
+ mac->associnfo.bssfixed = 0;
} else {
if (!memcmp(mac->associnfo.bssid, data->ap_addr.sa_data, ETH_ALEN)) {
if (mac->associnfo.associating || mac->associated) {
@@ -333,12 +338,14 @@ ieee80211softmac_wx_set_wap(struct net_d
} else {
/* copy new value in data->ap_addr.sa_data to bssid */
memcpy(mac->associnfo.bssid, data->ap_addr.sa_data, ETH_ALEN);
- }
+ }
+ /* tell the other code that this bssid should be used no matter what */
+ mac->associnfo.bssfixed = 1;
/* queue associate if new bssid or (old one again and not associated) */
schedule_work(&mac->associnfo.work);
}
-out:
+ out:
spin_unlock_irqrestore(&mac->lock, flags);
return 0;
}
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Please pull 'upstream' branch of wireless-2.6
From: John W. Linville @ 2006-04-24 20:40 UTC (permalink / raw)
To: jeff; +Cc: netdev
In-Reply-To: <20060424194006.GB21761@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 5062 bytes --]
The following changes since commit 7c241d37fe0e6442c5cf3b5d73f7f58f2dc66352:
Michael Buesch:
bcm43xx: make PIO mode usable
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream
Dan Williams:
wireless/airo: minimal WPA awareness
Jiri Benc:
orinoco: fix BAP0 offset error after several days of operation
Johannes Berg:
softmac: add SIOCSIWMLME
softmac: clean up event handling code
Michael Buesch:
bcm43xx: use pci_iomap() for convenience.
Pavel Roskin:
orinoco: Remove useless CIS validation
orinoco: remove PCMCIA audio support, it's useless for wireless cards
orinoco: remove underscores from little-endian field names
orinoco: remove tracing code, it's unused
orinoco: remove debug buffer code and userspace include support
orinoco: Symbol card supported by spectrum_cs is LA4137, not LA4100
orinoco: optimize Tx exception handling in orinoco
orinoco: orinoco_xmit() should only return valid symbolic constants
orinoco replace hermes_write_words() with hermes_write_bytes()
orinoco: don't use any padding for Tx frames
orinoco: refactor and clean up Tx error handling
orinoco: simplify 802.3 encapsulation code
orinoco: delay FID allocation after firmware initialization
orinoco_pci: disable device and free IRQ when suspending
orinoco_pci: use pci_iomap() for resources
orinoco: support PCI suspend/resume for Nortel, PLX and TMD adaptors
orinoco: reduce differences between PCI drivers, create orinoco_pci.h
orinoco: further comment cleanup in the PCI drivers
orinoco: bump version to 0.15
Zhu Yi:
ieee80211: Fix TKIP MIC calculation for QoS frames
ieee80211: Fix TX code doesn't enable QoS when using WPA + QoS
ieee80211: export list of bit rates with standard WEXT procddures
ieee80211: remove unnecessary CONFIG_WIRELESS_EXT checking
ieee80211: replace debug IEEE80211_WARNING with each own debug macro
ieee80211: update version stamp to 1.1.13
ipw2200: Exponential averaging for signal and noise Level
ipw2200: Fix TX QoS enabled frames problem
ipw2200: generates a scan event after a scan has completed
ipw2200: add module_param support for antenna selection
ipw2200: fix compile warning when !CONFIG_IPW2200_DEBUG
ipw2200: Do not continue loading the firmware if kmalloc fails
ipw2200: turn off signal debug log
ipw2200: Set the 'fixed' flags in wext get_rate
ipw2200: Fix endian issues with v3.0 fw image format
README.ipw2200: rename CONFIG_IPW_DEBUG to CONFIG_IPW2200_DEBUG
ipw2200: Enable rtap interface for RF promiscuous mode while associated
ipw2200: version string rework
ipw2200: update version stamp to 1.1.2
ipw2200: rename CONFIG_IPW_QOS to CONFIG_IPW2200_QOS
wireless Kconfig add IPW2200_RADIOTAP
ipw2200: rename CONFIG_IEEE80211_RADIOTAP to CONFIG_IPW2200_RADIOTAP
ipw2200: remove priv->last_noise reference
ipw2200: Fix wpa_supplicant association problem
Documentation/networking/README.ipw2200 | 10
drivers/net/wireless/Kconfig | 30 +
drivers/net/wireless/airo.c | 271 +++++---
drivers/net/wireless/bcm43xx/bcm43xx.h | 1
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 2
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 27 -
drivers/net/wireless/hermes.c | 66 --
drivers/net/wireless/hermes.h | 43 -
drivers/net/wireless/ipw2200.c | 849 +++++++++++++++++++++---
drivers/net/wireless/ipw2200.h | 83 ++
drivers/net/wireless/orinoco.c | 251 ++-----
drivers/net/wireless/orinoco.h | 19 -
drivers/net/wireless/orinoco_cs.c | 9
drivers/net/wireless/orinoco_nortel.c | 168 +++--
drivers/net/wireless/orinoco_pci.c | 207 +-----
drivers/net/wireless/orinoco_pci.h | 125 ++++
drivers/net/wireless/orinoco_plx.c | 222 +++---
drivers/net/wireless/orinoco_tmd.c | 96 +--
drivers/net/wireless/spectrum_cs.c | 48 +
include/net/ieee80211.h | 6
include/net/ieee80211softmac_wx.h | 5
net/ieee80211/ieee80211_crypt_tkip.c | 11
net/ieee80211/ieee80211_rx.c | 18 -
net/ieee80211/ieee80211_tx.c | 63 +-
net/ieee80211/ieee80211_wx.c | 44 +
net/ieee80211/softmac/ieee80211softmac_assoc.c | 2
net/ieee80211/softmac/ieee80211softmac_event.c | 25 -
net/ieee80211/softmac/ieee80211softmac_priv.h | 1
net/ieee80211/softmac/ieee80211softmac_wx.c | 32 +
29 files changed, 1673 insertions(+), 1061 deletions(-)
create mode 100644 drivers/net/wireless/orinoco_pci.h
Patch included as attachment due to size concerns.
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: upstream.patch.gz --]
[-- Type: application/x-gzip, Size: 41864 bytes --]
^ permalink raw reply
* Re: patch prism54usb: add set_bssid_filter
From: John W. Linville @ 2006-04-24 20:57 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: jean-baptiste.note, netdev
In-Reply-To: <20060331233159.a8893328.zaitcev@redhat.com>
On Fri, Mar 31, 2006 at 11:31:59PM -0800, Pete Zaitcev wrote:
> Implement proper set_bssid_filter. If filters are not set, firmware receives
> management frames only (instead of everything), so this is necessary.
Merged to master branch of wireless-2.6 tree.
Thanks!
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH wireless-2.6] add adm8211 wireless driver
From: John W. Linville @ 2006-04-24 21:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: netdev, Michael Wu, Jouni Malinen, Jean Tourrilhes
In-Reply-To: <444026BF.2080801@gmail.com>
On Fri, Apr 14, 2006 at 06:48:31PM -0400, Luis R. Rodriguez wrote:
>
> John, (Jean please update your docs)
>
> as promised here's a new 802.11b driver for wireless-2.6. It is based on
> Jouni Malinen's original work and maintained by Michael Wu.
> This driver is for ADM8211A, ADM8211B, and ADM8211C based cards which
> are PCI/mini-PCI/Cardbus 802.11b cards. This driver has been tested and
> known to work with the following wireless cards:
Applied to master branch of wireless-2.6. Let's get this one properly
reviewed and whipped into shape in time for 2.6.18!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* [PATCH] netdev: hotplug napi race cleanup
From: Stephen Hemminger @ 2006-04-24 22:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: patrakov, netdev, davem, akpm
In-Reply-To: <E1FX5zQ-000177-00@gondolin.me.apana.org.au>
This follows after the earlier two patches.
Change the initialization of the class device portion of the net device
to be done earlier, so that any races before registration completes are
harmless. Add a mutex to avoid changes to netdevice during the
class device registration.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- linux-2.6.orig/net/core/dev.c 2006-04-24 10:31:15.000000000 -0700
+++ linux-2.6/net/core/dev.c 2006-04-24 10:31:16.000000000 -0700
@@ -203,10 +203,12 @@
#ifdef CONFIG_SYSFS
extern int netdev_sysfs_init(void);
-extern int netdev_register_sysfs(struct net_device *);
-extern void netdev_unregister_sysfs(struct net_device *);
+extern void netdev_init_classdev(struct net_device *);
+#define netdev_register_sysfs(dev) class_device_add(&(dev->class_dev))
+#define netdev_unregister_sysfs(dev) class_device_del(&(dev->class_dev))
#else
#define netdev_sysfs_init() (0)
+#define netdev_init_classdev(dev) do { } while(0)
#define netdev_register_sysfs(dev) (0)
#define netdev_unregister_sysfs(dev) do { } while(0)
#endif
@@ -2870,6 +2872,8 @@
set_bit(__LINK_STATE_PRESENT, &dev->state);
+ netdev_init_classdev(dev);
+
dev->next = NULL;
dev_init_scheduler(dev);
write_lock_bh(&dev_base_lock);
@@ -3047,7 +3051,10 @@
* this is a delayed call after register_netdevice
* so no way to tell device driver what is wrong.
*/
+ rtnl_lock();
err = netdev_register_sysfs(dev);
+ __rtnl_unlock();
+
if (err) {
printk(KERN_ERR "%s: failed sysfs registration (%d)\n",
dev->name, err);
--- sky2-2.6.17.orig/net/core/net-sysfs.c 2006-04-24 10:31:14.000000000 -0700
+++ sky2-2.6.17/net/core/net-sysfs.c 2006-04-24 10:31:16.000000000 -0700
@@ -443,13 +443,8 @@
#endif
};
-void netdev_unregister_sysfs(struct net_device * net)
-{
- class_device_del(&(net->class_dev));
-}
-
-/* Create sysfs entries for network device. */
-int netdev_register_sysfs(struct net_device *net)
+/* Setup class device */
+void netdev_init_classdev(struct net_device *net)
{
struct class_device *class_dev = &(net->class_dev);
struct attribute_group **groups = net->sysfs_groups;
@@ -470,8 +465,6 @@
|| (net->wireless_handlers && net->wireless_handlers->get_wireless_stats))
*groups++ = &wireless_group;
#endif
-
- return class_device_add(class_dev);
}
int netdev_sysfs_init(void)
^ permalink raw reply
* [PATCH]: suspicious unlikely usage in tcp_transmit_skb()
From: Hua Zhong @ 2006-04-24 23:25 UTC (permalink / raw)
To: davem, netdev
Hi,
I am developing a profiling tool to check if likely/unlikely usages are wise. I find that the following one is always a miss:
# Hit # miss Function:Filename@Line
! 0 50505 tcp_transmit_skb():net/ipv4/tcp_output.c@468
There is a chance that my tool is buggy, but I just want to confirm with you whether this does look suspicious and what your opinion is.
Signed-off-by: Hua Zhong <hzhong@gmail.com>
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a28ae59..743016b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -465,7 +465,7 @@ #define SYSCTL_FLAG_SACK 0x4
TCP_INC_STATS(TCP_MIB_OUTSEGS);
err = icsk->icsk_af_ops->queue_xmit(skb, 0);
- if (unlikely(err <= 0))
+ if (likely(err <= 0))
return err;
tcp_enter_cwr(sk);
^ permalink raw reply related
* is it a backwards compatability catch-22?
From: Rick Jones @ 2006-04-24 23:47 UTC (permalink / raw)
To: Linux Network Development list
I might be out to lunch, certainly it happens often enough :) I've
spent the afternoon trying to stop my NIC names from being "random" on
each boot. To that end, I've been doing udev rules based on an example
I found at http://www.debianhelp.co.uk/udev.htm In this case I'm
running a Debian 2.6.15-1 kernel.
It seems that the SYSTEM{address} looks for a case senstive match on the
address (MAC) of the interface in rules like these:
lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0"
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d3", NAME="eth3"
KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"
it seems to want lower-case hex because that is what comes out of SYSFS. (?)
Of course, ifconfig -a gives HW addresses in "uppercase" hex:
lumber:~# ifconfig -a | grep HW
eth0 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3C
eth1 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3D
eth2 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D2
eth3 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D3
eth4 Link encap:Ethernet HWaddr 00:0C:FC:00:08:71
and some of the dmesg stuff - notably e100:
lumber:~# dmesg | grep eth
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
eth1: Tigon3 [partno(BCM95700A6) rev 0105 PHY(5701)] (PCI:66MHz:64-bit)
10/100/1000BaseT Ethernet 00:30:6e:4c:27:3d
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1]
TSOcap[0]
eth1: dma_rwctrl[76ff2d0f]
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
e100: eth3: e100_probe: addr 0x80020000, irq 57, MAC addr 00:30:6E:4C:27:3C
eth4: Neterion Xframe I 10GbE adapter (rev 4), Version Version 2.0.9.3,
Intr type INTA
e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex
While it isn't a "showstopper" it does become a bit inconvenient to have
to "downshift" the MAC when taking it from ifconfig to use in the udev
rules. Any chance the two can agree on one or the other? Or is each
locked in a backwards compatability embrace?
rick jones
and of course, arp matches ifconfig:
lumber:~# arp -an
? (15.4.89.87) at 00:12:79:94:F8:24 [ether] on eth0
? (15.4.88.1) at 00:00:0C:07:AC:00 [ether] on eth0
not that arp in and of itself matters in this situation.
^ permalink raw reply
* Re: is it a backwards compatability catch-22?
From: Stephen Hemminger @ 2006-04-24 23:54 UTC (permalink / raw)
To: Rick Jones; +Cc: Linux Network Development list
In-Reply-To: <444D6396.4010004@hp.com>
On Mon, 24 Apr 2006 16:47:34 -0700
Rick Jones <rick.jones2@hp.com> wrote:
> I might be out to lunch, certainly it happens often enough :) I've
> spent the afternoon trying to stop my NIC names from being "random" on
> each boot. To that end, I've been doing udev rules based on an example
> I found at http://www.debianhelp.co.uk/udev.htm In this case I'm
> running a Debian 2.6.15-1 kernel.
>
> It seems that the SYSTEM{address} looks for a case senstive match on the
> address (MAC) of the interface in rules like these:
>
> lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules
> KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0"
> KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1"
> KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2"
> KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d3", NAME="eth3"
> KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"
>
> it seems to want lower-case hex because that is what comes out of SYSFS. (?)
>
> Of course, ifconfig -a gives HW addresses in "uppercase" hex:
>
> lumber:~# ifconfig -a | grep HW
> eth0 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3C
> eth1 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3D
> eth2 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D2
> eth3 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D3
> eth4 Link encap:Ethernet HWaddr 00:0C:FC:00:08:71
>
> and some of the dmesg stuff - notably e100:
>
> lumber:~# dmesg | grep eth
> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> eth1: Tigon3 [partno(BCM95700A6) rev 0105 PHY(5701)] (PCI:66MHz:64-bit)
> 10/100/1000BaseT Ethernet 00:30:6e:4c:27:3d
> eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1]
> TSOcap[0]
> eth1: dma_rwctrl[76ff2d0f]
> e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
> e100: eth3: e100_probe: addr 0x80020000, irq 57, MAC addr 00:30:6E:4C:27:3C
> eth4: Neterion Xframe I 10GbE adapter (rev 4), Version Version 2.0.9.3,
> Intr type INTA
> e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex
>
> While it isn't a "showstopper" it does become a bit inconvenient to have
> to "downshift" the MAC when taking it from ifconfig to use in the udev
> rules. Any chance the two can agree on one or the other? Or is each
> locked in a backwards compatability embrace?
>
> rick jones
>
> and of course, arp matches ifconfig:
>
> lumber:~# arp -an
> ? (15.4.89.87) at 00:12:79:94:F8:24 [ether] on eth0
> ? (15.4.88.1) at 00:00:0C:07:AC:00 [ether] on eth0
>
> not that arp in and of itself matters in this situation.
Don't use the auto assigned format "eth0, eth1, eth2"?
The udev stuff runs after the device has already chosen it's default name.
It has to, it's part of the hotplug infrastructure, and we don't want
to depend on usermode to define the name. Just choose some other
convention "eth_0" or something like that.
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* Re: Please pull 'upstream' branch of wireless-2.6
From: Dan Williams @ 2006-04-25 0:33 UTC (permalink / raw)
To: John W. Linville; +Cc: jeff, netdev
In-Reply-To: <20060424204044.GC21761@tuxdriver.com>
On Mon, 2006-04-24 at 16:40 -0400, John W. Linville wrote:
> The following changes since commit 7c241d37fe0e6442c5cf3b5d73f7f58f2dc66352:
> Michael Buesch:
> bcm43xx: make PIO mode usable
>
> are found in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream
>
> Dan Williams:
> wireless/airo: minimal WPA awareness
>
> Jiri Benc:
> orinoco: fix BAP0 offset error after several days of operation
>
> Johannes Berg:
> softmac: add SIOCSIWMLME
> softmac: clean up event handling code
Any way to get the event handling cleanup patch into 2.6.17? It's
pretty much a bugfix and bcm43xx is useless with wpa_supplicant and NM
without the patch...
Dan
> Michael Buesch:
> bcm43xx: use pci_iomap() for convenience.
>
> Pavel Roskin:
> orinoco: Remove useless CIS validation
> orinoco: remove PCMCIA audio support, it's useless for wireless cards
> orinoco: remove underscores from little-endian field names
> orinoco: remove tracing code, it's unused
> orinoco: remove debug buffer code and userspace include support
> orinoco: Symbol card supported by spectrum_cs is LA4137, not LA4100
> orinoco: optimize Tx exception handling in orinoco
> orinoco: orinoco_xmit() should only return valid symbolic constants
> orinoco replace hermes_write_words() with hermes_write_bytes()
> orinoco: don't use any padding for Tx frames
> orinoco: refactor and clean up Tx error handling
> orinoco: simplify 802.3 encapsulation code
> orinoco: delay FID allocation after firmware initialization
> orinoco_pci: disable device and free IRQ when suspending
> orinoco_pci: use pci_iomap() for resources
> orinoco: support PCI suspend/resume for Nortel, PLX and TMD adaptors
> orinoco: reduce differences between PCI drivers, create orinoco_pci.h
> orinoco: further comment cleanup in the PCI drivers
> orinoco: bump version to 0.15
>
> Zhu Yi:
> ieee80211: Fix TKIP MIC calculation for QoS frames
> ieee80211: Fix TX code doesn't enable QoS when using WPA + QoS
> ieee80211: export list of bit rates with standard WEXT procddures
> ieee80211: remove unnecessary CONFIG_WIRELESS_EXT checking
> ieee80211: replace debug IEEE80211_WARNING with each own debug macro
> ieee80211: update version stamp to 1.1.13
> ipw2200: Exponential averaging for signal and noise Level
> ipw2200: Fix TX QoS enabled frames problem
> ipw2200: generates a scan event after a scan has completed
> ipw2200: add module_param support for antenna selection
> ipw2200: fix compile warning when !CONFIG_IPW2200_DEBUG
> ipw2200: Do not continue loading the firmware if kmalloc fails
> ipw2200: turn off signal debug log
> ipw2200: Set the 'fixed' flags in wext get_rate
> ipw2200: Fix endian issues with v3.0 fw image format
> README.ipw2200: rename CONFIG_IPW_DEBUG to CONFIG_IPW2200_DEBUG
> ipw2200: Enable rtap interface for RF promiscuous mode while associated
> ipw2200: version string rework
> ipw2200: update version stamp to 1.1.2
> ipw2200: rename CONFIG_IPW_QOS to CONFIG_IPW2200_QOS
> wireless Kconfig add IPW2200_RADIOTAP
> ipw2200: rename CONFIG_IEEE80211_RADIOTAP to CONFIG_IPW2200_RADIOTAP
> ipw2200: remove priv->last_noise reference
> ipw2200: Fix wpa_supplicant association problem
>
> Documentation/networking/README.ipw2200 | 10
> drivers/net/wireless/Kconfig | 30 +
> drivers/net/wireless/airo.c | 271 +++++---
> drivers/net/wireless/bcm43xx/bcm43xx.h | 1
> drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 2
> drivers/net/wireless/bcm43xx/bcm43xx_main.c | 27 -
> drivers/net/wireless/hermes.c | 66 --
> drivers/net/wireless/hermes.h | 43 -
> drivers/net/wireless/ipw2200.c | 849 +++++++++++++++++++++---
> drivers/net/wireless/ipw2200.h | 83 ++
> drivers/net/wireless/orinoco.c | 251 ++-----
> drivers/net/wireless/orinoco.h | 19 -
> drivers/net/wireless/orinoco_cs.c | 9
> drivers/net/wireless/orinoco_nortel.c | 168 +++--
> drivers/net/wireless/orinoco_pci.c | 207 +-----
> drivers/net/wireless/orinoco_pci.h | 125 ++++
> drivers/net/wireless/orinoco_plx.c | 222 +++---
> drivers/net/wireless/orinoco_tmd.c | 96 +--
> drivers/net/wireless/spectrum_cs.c | 48 +
> include/net/ieee80211.h | 6
> include/net/ieee80211softmac_wx.h | 5
> net/ieee80211/ieee80211_crypt_tkip.c | 11
> net/ieee80211/ieee80211_rx.c | 18 -
> net/ieee80211/ieee80211_tx.c | 63 +-
> net/ieee80211/ieee80211_wx.c | 44 +
> net/ieee80211/softmac/ieee80211softmac_assoc.c | 2
> net/ieee80211/softmac/ieee80211softmac_event.c | 25 -
> net/ieee80211/softmac/ieee80211softmac_priv.h | 1
> net/ieee80211/softmac/ieee80211softmac_wx.c | 32 +
> 29 files changed, 1673 insertions(+), 1061 deletions(-)
> create mode 100644 drivers/net/wireless/orinoco_pci.h
>
> Patch included as attachment due to size concerns.
^ permalink raw reply
* Re: is it a backwards compatability catch-22?
From: Rick Jones @ 2006-04-25 0:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Network Development list
In-Reply-To: <20060424165407.202a86f4@dxpl.pdx.osdl.net>
> The udev stuff runs after the device has already chosen it's default name.
> It has to, it's part of the hotplug infrastructure, and we don't want
> to depend on usermode to define the name. Just choose some other
> convention "eth_0" or something like that.
Is that because adding another NIC at a later time might cause it to
grab ethN out from under what I'm trying to do with udev?
rick jones
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Michael Chan @ 2006-04-24 23:17 UTC (permalink / raw)
To: linux-os (Dick Johnson)
Cc: Auke Kok, Ingo Oeser, Jörn Engel, Ingo Oeser,
David S. Miller, simlo, linux-kernel, mingo, netdev
In-Reply-To: <Pine.LNX.4.61.0604241254180.24099@chaos.analogic.com>
On Mon, 2006-04-24 at 12:59 -0400, linux-os (Dick Johnson) wrote:
> Message signaled interrupts are just a kudge to save a trace on a
> PC board (read make junk cheaper still). They are not faster and
> may even be slower. They will not be the salvation of any interrupt
> latency problems.
MSI has 2 very nice properties: MSI is never shared and MSI guarantees
that all DMA activities before the MSI have completed. When you take
advantage of these guarantees in your MSI handler, there can be
noticeable improvements compared to using INTA.
^ permalink raw reply
* Re: [PATCH] netdev: hotplug napi race cleanup
From: Andrew Morton @ 2006-04-25 1:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: herbert, patrakov, netdev, davem
In-Reply-To: <20060424152341.094b72d8@localhost.localdomain>
Stephen Hemminger <shemminger@osdl.org> wrote:
>
> This follows after the earlier two patches.
>
> Change the initialization of the class device portion of the net device
> to be done earlier, so that any races before registration completes are
> harmless. Add a mutex to avoid changes to netdevice during the
> class device registration.
>
I had to fix up a reject in here.
> @@ -3047,7 +3051,10 @@
> * this is a delayed call after register_netdevice
> * so no way to tell device driver what is wrong.
> */
> + rtnl_lock();
> err = netdev_register_sysfs(dev);
> + __rtnl_unlock();
> +
> if (err) {
> printk(KERN_ERR "%s: failed sysfs registration (%d)\n",
> dev->name, err);
bix:/usr/src/25> grep 'this is a delayed call after' net/core/*.c patches/*.patch
bix:/usr/src/25>
I cannot find that comment anywhere.
^ permalink raw reply
* Re: Van Jacobson's net channels and real-time
From: Auke Kok @ 2006-04-25 1:49 UTC (permalink / raw)
To: linux-os (Dick Johnson)
Cc: Auke Kok, Ingo Oeser, Jörn Engel, Ingo Oeser,
David S. Miller, simlo, linux-kernel, mingo, netdev
In-Reply-To: <Pine.LNX.4.61.0604241254180.24099@chaos.analogic.com>
linux-os (Dick Johnson) wrote:
> On Mon, 24 Apr 2006, Auke Kok wrote:
>
>> Ingo Oeser wrote:
>>> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
>>>> That was another main point, yes. And the endpoints should be as
>>>> little burden on the bottlenecks as possible. One bottleneck is the
>>>> receive interrupt, which shouldn't wait for cachelines from other cpus
>>>> too much.
>>> Thats right. This will be made a non issue with early demuxing
>>> on the NIC and MSI (or was it MSI-X?) which will select
>>> the right CPU based on hardware channels.
>> MSI-X. with MSI you still have only one cpu handling all MSI interrupts and
>> that doesn't look any different than ordinary interrupts. MSI-X will allow
>> much better interrupt handling across several cpu's.
>>
>> Auke
>> -
>
> Message signaled interrupts are just a kudge to save a trace on a
> PC board (read make junk cheaper still).
yes. Also in PCI-Express there is no physical interrupt line anymore due to
the architecture, so even classical interrupts are sent as "message" over the bus.
> They are not faster and may even be slower.
thus in the case of PCI-Express, MSI interrupts are just as fast as the
ordinary ones. I have no numbers on whether MSI is faster or not then e.g.
interrupts on PCI-X, but generally speaking, the PCI-Express bus is not
designed to be "low latency" at all, at best it gives you X latency, where X
is something like microseconds. The MSI message itself only takes 10-20
nanoseconds though, but all the handling probably adds a large factor to that
(1000 or so). No clue on classical interrupt line latency - anyone?
> They will not be the salvation of any interrupt latency problems.
This is also not the problem - we really don't care that our 100.000 packets
arrive 20usec slower per packet, just as long as the bus is not idle for those
intervals. We would care a lot if 25.000 of those arrive directly at the
proper CPU, without the need for one of the cpu's to arbitrate on every
interrupt. That's the idea anyway.
Nowadays with irq throttling we introduce a lot of designed latency anyway,
especially with network devices.
> The solutions for increasing networking speed,
> where the bit-rate on the wire gets close to the bit-rate on the
> bus, is to put more and more of the networking code inside the
> network board. The CPU get interrupted after most things (like
> network handshakes) are complete.
That is a limited vision of the situation. You could argue that the current
CPU's have so much power that they can easily do a lot of the processing
instead of the hardware, and thus warm caches for userspace, setup sockets
etc. This is the whole idea of Van Jacobsen's net channels. Putting more
offloading into the hardware just brings so much problems with itself, that
are just far easier solved in the OS.
Cheers,
Auke
^ permalink raw reply
* Re: TCP not retransmitting supposedly lost segment
From: Herbert Xu @ 2006-04-25 2:42 UTC (permalink / raw)
To: Florian Zumbiehl; +Cc: netdev
In-Reply-To: <20060423235609.GB17254@florz.florz.dyndns.org>
On Mon, Apr 24, 2006 at 01:56:09AM +0200, Florian Zumbiehl wrote:
>
> Well, at least the tcp part of it, it seems, yep. The debugging I've
> done so far also seems to confirm that the problem is somewhere beyond
> the tcp code, but I don't have any real clue yet ...
One way to proceed is to add printk's to the error paths in the output
path through TCP, IPv6, netfilter, ...
These should be rare so the it shouldn't flood your syslog. Based on
which error path is taken or not taken you should be able to work out
where you need to focus your search on.
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: [PATCH]: suspicious unlikely usage in tcp_transmit_skb()
From: Herbert Xu @ 2006-04-25 5:34 UTC (permalink / raw)
To: Hua Zhong; +Cc: davem, netdev
In-Reply-To: <444D5E73.7020803@gmail.com>
Hua Zhong <hzhong@gmail.com> wrote:
>
> I am developing a profiling tool to check if likely/unlikely usages are wise. I find that the following one is always a miss:
>
> # Hit # miss Function:Filename@Line
> ! 0 50505 tcp_transmit_skb():net/ipv4/tcp_output.c@468
>
> There is a chance that my tool is buggy, but I just want to confirm with you whether this does look suspicious and what your opinion is.
Your tool is correct. The only way for it to fall through is if
we encounter local congestion.
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
* determine outgoing interface (eth0,eth1) for a packet according to the dest IP
From: John Que @ 2006-04-25 7:31 UTC (permalink / raw)
To: netdev
Hello,
What is the right way to determine on which interface card
(eth0 or eth1) will a packet be sent (according to the dest IP)?
I have a machine with two NICS (eth0 and eth1).
I have 2 different gateways.
I need to know on which interface (eth0 or eth1) will the
packet be send according to the dest IP.
I want to do in in a User Space function.
I think of one way to do this is:
Parse the routing table (/proc/net/route) as is done in
net-tools. (to be more specific rprint_fib() in lib/inet_gr.c
of net-tools.
Than according to the IP address and the netmask check if the
dest IP is for one gatway or the second.
If not - than it is the default gateway.
Is there another way ? Is it the correct way ?
Regards,
John
^ permalink raw reply
* Re: determine outgoing interface (eth0,eth1) for a packet according to the dest IP
From: Andi Kleen @ 2006-04-25 7:43 UTC (permalink / raw)
To: John Que; +Cc: netdev
In-Reply-To: <ada605fb0604250031r2e4a74e7id0b5079fabde9517@mail.gmail.com>
On Tuesday 25 April 2006 09:31, John Que wrote:
> Hello,
> What is the right way to determine on which interface card
> (eth0 or eth1) will a packet be sent (according to the dest IP)?
You can send a rtnetlink RTM_GETROUTE message to ask the kernel.
Result is the interface index in RTA_OIF, which can be converted
into a name.
-Andi
^ 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