* RE: Splice status
From: Ofer Heifetz @ 2010-07-06 2:36 UTC (permalink / raw)
To: Changli Gao, Eric Dumazet; +Cc: Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <AANLkTim_eBmT-6HmkqG5d7k0jjrGKAFBjzqVCricTpgK@mail.gmail.com>
Regarding your remark of replacing sendfile with recvfile, I have two questions:
1) what will be used if both are enabled in smb.conf
2) from your experience, which is faster for reading files?
________________________________________
From: Changli Gao [xiaosuo@gmail.com]
Sent: Tuesday, July 06, 2010 5:01 AM
To: Eric Dumazet
Cc: Jens Axboe; Ofer Heifetz; netdev@vger.kernel.org
Subject: Re: Splice status
On Mon, Jul 5, 2010 at 8:50 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 05 juillet 2010 à 13:52 +0300, Ofer Heifetz a écrit :
>> I am using Samba, so from my understanding of the source code, it
> loops and performs splice(sock, pipe) and splice(pipe, fd). There is no
> flush of any sort in between.
>>
>> When you say drain you mean to flush all data to pipe?
>>
>
> Draining pipe before splice() call would only trigger the bug less
> often.
If we don't drain the pipe before calling splice(2), the data spliced
from pipe maybe not be what we expect. Then data corruption occurs.
>
> splice(sock, pipe) can block if caller dont use appropriate "non
> blocking pipe' splice() mode, even if pipe is empty before a splice()
> call.
I don't think it is expected. The code of sys_recvfile is much like
the sendfile(2) implementation in kernel. If sys_recvfile may block
without non_block flag, sendfile(2) may block too.
BTW: Samba can use sendfile(2) instead in sys_recvfile.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: bridge br_multicast: BUG: unable to handle kernel NULL pointer dereference
From: David Miller @ 2010-07-06 3:07 UTC (permalink / raw)
To: herbert; +Cc: frank.arnold, shemminger, yoshfuji, netdev
In-Reply-To: <20100706005008.GA11699@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 6 Jul 2010 08:50:08 +0800
> On Tue, Jul 06, 2010 at 08:48:35AM +0800, Herbert Xu wrote:
>>
>> bridge: Restore NULL check in br_mdb_ip_get
>
> Resend with proper attribution.
>
> bridge: Restore NULL check in br_mdb_ip_get
>
> Somewhere along the line the NULL check in br_mdb_ip_get went
> AWOL, causing crashes when we receive an IGMP packet with no
> multicast table allocated.
It got removed by:
--------------------
commit 8ef2a9a59854994bace13b5c4f7edc2c8d4d124e
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun Apr 18 12:42:07 2010 +0900
bridge br_multicast: Make functions less ipv4 dependent.
Introduce struct br_ip{} to store ip address and protocol
and make functions more generic so that we can support
both IPv4 and IPv6 with less pain.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--------------------
> This patch restores it and ensures all br_mdb_*_get functions
> use it.
>
> Reported-by: Frank Arnold <frank.arnold@amd.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/ne: fix memory leak in ne_drv_probe()
From: David Miller @ 2010-07-06 3:08 UTC (permalink / raw)
To: segooon; +Cc: kernel-janitors, joe, anemo, netdev, linux-kernel
In-Reply-To: <1278170444-8170-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Sat, 3 Jul 2010 19:20:42 +0400
> net_device allocated with alloc_eip_netdev() must be freed.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: Philip Prindeville @ 2010-07-06 3:08 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Alexander Clouter, netdev
In-Reply-To: <20100706020734.GA2972@nuttenaction>
On 7/5/10 8:07 PM, Hagen Paul Pfeifer wrote:
> * Philip Prindeville | 2010-07-05 12:04:31 [-0600]:
>
>
>> I understand that. That's part of the reason that I've submitted
>> patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>> etc. There is pressure within certain technical groups to get ISP's
>> to voluntarily implement RFC-4594... that's the carrot. The stick
>> being FCC heavy-handed regulation of the ISP's if they don't.
>>
> Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
> operation? At the end the user/service is still required to set his service
> class, but this time with CAP_NET_ADMIN. Do you think that Service
> Providers/Transit Providers trust (and this is the critical aspect) customers
> based on some IP flags - this is extreme unlikely. 99% of users have
> effective CAP_NET_ADMIN capabilities - and you cannot stop using them.
>
QoS is expensive to implement, since it requires a lot more inspection
of the packet, multiple queues, bandwidth reservation, etc.
ISP's are going to look for an excuse not to implement it.
Having it be exploited by users is another arrow in their quill to not
implement it.
Yes, most users have admin/privileged rights on their machines, but
don't know enough to exploit that.
Whatever makes it harder to abusively exploit QoS seems like a good
idea. Harder. Not impossible.
"Stopping them" was never the objective.
> Service Providers/Transit Providers will trust customers who pays more and
> then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
> other customers will be treated normal, with zeroed DSCP. It makes no sense
> for ISP's to shift the trust aspect to the customer side.
>
> HGN
>
>
>
Alas there's more to it than that: the movement is to make QoS be
ubiquitous for all SLA's of broadband.
I'd argue that it makes no sense for them not to trust it: SDP/RTP
packets are hard to identify as such without peaking into the
accompanying SIP conversation... which drives up the cost of their
required infrastructure to handle QoS even more.
Besides, if I deploy a new protocol that uses RTP or leverages QoS, I'd
have to wait for the ISP to update their network with knowledge of that
protocol in order to handle it properly... given the glacial pace that
at which ISP's certify and deploy software updates, configuration
changes, etc. I don't want to have to wait months or years for them to
play catch-up.
What's more, if I'm running SIP over TLS over TCP, they can't peek into
the stream anyway to figure out what UDP ports I'm using for SDP.
So I can sacrifice control, privacy, or timeliness... or they can simply
trust my QoS markings.
But what's the downside of their trusting my markings, anyway?
Let's say that I have 7mb/s DSL, and with that standard base profile
comes 240kb/s EF policing, 512kb/s AF4x, etc. Further let's suppose
that I exceed my SLA: they could either downgrade the excess to the next
lowest bin, or discard it... Hence I'm highly incentivized to remain
within my agreed SLA envelope.
^ permalink raw reply
* Re: [PATCH net-2.6] net: Fix definition of netif_vdbg() when VERBOSE_DEBUG is defined
From: David Miller @ 2010-07-06 3:08 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers, joe
In-Reply-To: <1278090524.2095.41.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 02 Jul 2010 18:08:44 +0100
> netif_vdbg() was originally defined as entirely equivalent to
> netdev_vdbg(), but I assume that it was intended to take the same
> parameters as netif_dbg() etc. (Currently it is only used by the
> sfc driver, in which I worked on that assumption.)
>
> In commit a4ed89c I changed the definition used when VERBOSE_DEBUG is
> not defined, but I failed to notice that the definition used when
> VERBOSE_DEBUG is defined was also not as I expected. Change that to
> match netif_dbg() as well.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: David Miller @ 2010-07-06 3:13 UTC (permalink / raw)
To: philipp_subx; +Cc: hagen, alex, netdev
In-Reply-To: <4C329E15.2000601@redfish-solutions.com>
From: Philip Prindeville <philipp_subx@redfish-solutions.com>
Date: Mon, 05 Jul 2010 21:08:05 -0600
> Yes, most users have admin/privileged rights on their machines, but
> don't know enough to exploit that.
Even "stupid" users are a very slim, marginal, step away from making
use of it once they get shown with a HOWTO on some web site what is
possible with this if QoS is being abided by on their network.
Look, this discussion seems completely pointless. The behavior is
never changing, setting the TOS will always be non-privileged.
We cannot change the current behavior no matter what political or
other motivation we might have for doing so. It's been non-privileged
for more than 15 years, and we'd knowingly break applications with the
change.
And I don't even agree with the arguments being proposed for doing
this. Users can control their packets however they wish. The only
thing the ISP can do to prevent toying with the TOS bits is putting
logic into your little black box that hooks up to your cable/dsl line.
So this TOS being privileged proposal it's a "no go" from any angle as
far as I'm concerned.
^ permalink raw reply
* Re: Splice status
From: Eric Dumazet @ 2010-07-06 3:56 UTC (permalink / raw)
To: Changli Gao; +Cc: Jens Axboe, Ofer Heifetz, netdev@vger.kernel.org
In-Reply-To: <AANLkTim_eBmT-6HmkqG5d7k0jjrGKAFBjzqVCricTpgK@mail.gmail.com>
Le mardi 06 juillet 2010 à 10:01 +0800, Changli Gao a écrit :
> On Mon, Jul 5, 2010 at 8:50 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le lundi 05 juillet 2010 à 13:52 +0300, Ofer Heifetz a écrit :
> >> I am using Samba, so from my understanding of the source code, it
> > loops and performs splice(sock, pipe) and splice(pipe, fd). There is no
> > flush of any sort in between.
> >>
> >> When you say drain you mean to flush all data to pipe?
> >>
> >
> > Draining pipe before splice() call would only trigger the bug less
> > often.
>
> If we don't drain the pipe before calling splice(2), the data spliced
> from pipe maybe not be what we expect. Then data corruption occurs.
>
This is not true. A pipe is a pipe is a buffer. You dont need it to be
empty when using it. Nowhere in documentation its stated.
However, a single skb can fill a pipe, even if "its empty"
> >
> > splice(sock, pipe) can block if caller dont use appropriate "non
> > blocking pipe' splice() mode, even if pipe is empty before a splice()
> > call.
>
> I don't think it is expected. The code of sys_recvfile is much like
> the sendfile(2) implementation in kernel. If sys_recvfile may block
> without non_block flag, sendfile(2) may block too.
Then it would be a bug. You might fix it easily.
Using splice() correctly (ie, not blocking on sock->pipe) should work
too.
Again, you can block on splice(sock, pipe), iff you have a second thread
doing the opposite (pipe->file) in parallel to unblock you. But samba
recvfile algo is using a single thread.
>
> BTW: Samba can use sendfile(2) instead in sys_recvfile.
>
^ permalink raw reply
* linux-next: build warning after merge of the net tree
From: Stephen Rothwell @ 2010-07-06 4:25 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Joe Perches, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
Hi Dave,
After merging the net tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/scsi/sym53c8xx_2/sym_hipd.c: In function 'sym_print_msg':
drivers/scsi/sym53c8xx_2/sym_hipd.c:78: warning: zero-length gnu_printf format string
drivers/scsi/constants.c: In function 'scsi_print_sense':
drivers/scsi/constants.c:1407: warning: zero-length gnu_printf format string
drivers/scsi/constants.c:1413: warning: zero-length gnu_printf format string
drivers/scsi/constants.c: In function 'scsi_print_result':
drivers/scsi/constants.c:1456: warning: zero-length gnu_printf format string
drivers/scsi/sd.c: In function 'sd_print_sense_hdr':
drivers/scsi/sd.c:2599: warning: zero-length gnu_printf format string
drivers/scsi/sd.c:2601: warning: zero-length gnu_printf format string
drivers/scsi/sd.c: In function 'sd_print_result':
drivers/scsi/sd.c:2607: warning: zero-length gnu_printf format string
(There may be more ...)
Introduced by commit 99bcf217183e02ebae46373896fba7f12d588001 ("device.h
drivers/base/core.c Convert dev_<level> logging macros to functions").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] net: sh_eth: add support for SH7757's ETHER
From: Yoshihiro Shimoda @ 2010-07-06 4:32 UTC (permalink / raw)
To: netdev; +Cc: SH-Linux
The SH7757 has 2 Fast Ethernet controller (ETHER) and 2 Gigabit Ethernet
Controller (GETHER). This patch supports 2 ETHER only.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/net/Kconfig | 5 ++-
drivers/net/sh_eth.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ce2fcdd..663f863 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -530,14 +530,15 @@ config SH_ETH
depends on SUPERH && \
(CPU_SUBTYPE_SH7710 || CPU_SUBTYPE_SH7712 || \
CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7619 || \
- CPU_SUBTYPE_SH7724)
+ CPU_SUBTYPE_SH7724 || CPU_SUBTYPE_SH7757)
select CRC32
select MII
select MDIO_BITBANG
select PHYLIB
help
Renesas SuperH Ethernet device driver.
- This driver support SH7710, SH7712, SH7763, SH7619, and SH7724.
+ This driver supporting CPUs are:
+ - SH7710, SH7712, SH7763, SH7619, SH7724, and SH7757.
config SUNLANCE
tristate "Sun LANCE support"
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 501a55f..7ac814d 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -88,6 +88,55 @@ static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
.rpadir = 1,
.rpadir_value = 0x00020000, /* NET_IP_ALIGN assumed to be 2 */
};
+#elif defined(CONFIG_CPU_SUBTYPE_SH7757)
+#define SH_ETH_RESET_DEFAULT 1
+static void sh_eth_set_duplex(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ u32 ioaddr = ndev->base_addr;
+
+ if (mdp->duplex) /* Full */
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) | ECMR_DM, ioaddr + ECMR);
+ else /* Half */
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) & ~ECMR_DM, ioaddr + ECMR);
+}
+
+static void sh_eth_set_rate(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ u32 ioaddr = ndev->base_addr;
+
+ switch (mdp->speed) {
+ case 10: /* 10BASE */
+ ctrl_outl(0, ioaddr + RTRATE);
+ break;
+ case 100:/* 100BASE */
+ ctrl_outl(1, ioaddr + RTRATE);
+ break;
+ default:
+ break;
+ }
+}
+
+/* SH7757 */
+static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
+ .set_duplex = sh_eth_set_duplex,
+ .set_rate = sh_eth_set_rate,
+
+ .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
+ .rmcr_value = 0x00000001,
+
+ .tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
+ .eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RDE |
+ EESR_RFRMER | EESR_TFE | EESR_TDE | EESR_ECI,
+ .tx_error_check = EESR_TWB | EESR_TABT | EESR_TDE | EESR_TFE,
+
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .hw_swap = 1,
+ .no_ade = 1,
+};
#elif defined(CONFIG_CPU_SUBTYPE_SH7763)
#define SH_ETH_HAS_TSU 1
@@ -1023,7 +1072,9 @@ static int sh_eth_open(struct net_device *ndev)
pm_runtime_get_sync(&mdp->pdev->dev);
ret = request_irq(ndev->irq, sh_eth_interrupt,
-#if defined(CONFIG_CPU_SUBTYPE_SH7763) || defined(CONFIG_CPU_SUBTYPE_SH7764)
+#if defined(CONFIG_CPU_SUBTYPE_SH7763) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7764) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7757)
IRQF_SHARED,
#else
0,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] drivers/net: correct valid flag
From: Julia Lawall @ 2010-07-06 5:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20100705.180349.112607097.davem@davemloft.net>
On Mon, 5 Jul 2010, David Miller wrote:
> From: Julia Lawall <julia@diku.dk>
> Date: Mon, 5 Jul 2010 17:07:15 +0200 (CEST)
>
> > From: Julia Lawall <julia@diku.dk>
> >
> > Elsewhere in the "optimized" functions, the "2" constants are used.
> > NV_TX_VALID and NV_TX2_VALID have the same value.
> >
> > Signed-off-by: Julia Lawall <julia@diku.dk>
> >
> > ---
> > diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> > index 268ea4d..870c18b 100644
> > --- a/drivers/net/forcedeth.c
> > +++ b/drivers/net/forcedeth.c
> > @@ -2468,7 +2468,8 @@ static int nv_tx_done_optimized(struct net_device *dev, int limit)
> > struct ring_desc_ex* orig_get_tx = np->get_tx.ex;
> >
> > while ((np->get_tx.ex != np->put_tx.ex) &&
> > - !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX_VALID) &&
> > + !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX2_VALID)
> > + &&
> > (tx_work < limit)) {
>
> Please don't put that "&&" on a line by itself. I don't care if leaving it
> on the previous line makes it exceed 80 columns, what you're doing here is
> infinitely less pleasant to read.
OK, I'll put it back.
julia
^ permalink raw reply
* Re: [PATCH] drivers/net: correct valid flag
From: Julia Lawall @ 2010-07-06 5:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20100705.180349.112607097.davem@davemloft.net>
From: Julia Lawall <julia@diku.dk>
Elsewhere in the "optimized" functions, the "2" constants are used.
NV_TX_VALID and NV_TX2_VALID have the same value.
Signed-off-by: Julia Lawall <julia@diku.dk>
---
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 268ea4d..9ef6a9d 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2468,7 +2468,7 @@ static int nv_tx_done_optimized(struct net_device *dev, int limit)
struct ring_desc_ex* orig_get_tx = np->get_tx.ex;
while ((np->get_tx.ex != np->put_tx.ex) &&
- !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX_VALID) &&
+ !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX2_VALID) &&
(tx_work < limit)) {
dprintk(KERN_DEBUG "%s: nv_tx_done_optimized: flags 0x%x.\n",
^ permalink raw reply related
* Re: [PATCH] drivers/net: correct valid flag
From: David Miller @ 2010-07-06 5:16 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.1007060711320.30668@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Tue, 6 Jul 2010 07:11:45 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> Elsewhere in the "optimized" functions, the "2" constants are used.
> NV_TX_VALID and NV_TX2_VALID have the same value.
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Since the two values are identical this doesn't fix a bug, so I've
applied this to net-next-2.6
Thanks!
^ permalink raw reply
* RE: [PATCH] bnx2x: add support for receive hashing
From: Vladislav Zolotarov @ 2010-07-06 7:16 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev@vger.kernel.org
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDE646FBFB@SJEXCHCCR02.corp.ad.broadcom.com>
Let me rephrase: the part of your patch below enables RSS flow in our FW even if there is only one HW queue and I wonder why?
To refresh:
1) FW won't provide Toeplitz hash on CQE if RSS is not enabled.
2) There can be one HW queue in only 2 cases:
- There is only one CPU in the system. In that case I wonder if u have anything to do with Toeplitz hash on the skb at all.
- User has explicitly requested 1 HW queue with module parameter (num_queues=1). In that case if u r going to use the RSS hash on the skb means that u r actually going to do SW RSS instead of HW RSS, which sounds strange to me.
So, Herbert, could u, pls., explain, what was your original idea about these code lines?
Thanks,
vlad
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Vladislav Zolotarov
> Sent: Sunday, July 04, 2010 7:36 PM
> To: Tom Herbert
> Cc: netdev@vger.kernel.org
> Subject: RE: [PATCH] bnx2x: add support for receive hashing
>
> Tom, could u, pls., explain what did u mean by taking the (RSS) flags
> configuration out of RSS "if"? To recall "if(is_multi(bp))" is true iff RSS
> is enabled.
>
> Thanks,
> vlad
>
> > @@ -5750,10 +5757,10 @@ static void bnx2x_init_internal_func(struct bnx2x
> > *bp)
> > u32 offset;
> > u16 max_agg_size;
> >
> > - if (is_multi(bp)) {
> > - tstorm_config.config_flags = MULTI_FLAGS(bp);
> > + tstorm_config.config_flags = RSS_FLAGS(bp);
> > +
> > + if (is_multi(bp))
> > tstorm_config.rss_result_mask = MULTI_MASK;
> > - }
> >
> > /* Enable TPA if needed */
> > if (bp->flags & TPA_ENABLE_FLAG)
>
>
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> > Behalf Of Tom Herbert
> > Sent: Friday, April 23, 2010 8:54 AM
> > To: davem@davemloft.net; netdev@vger.kernel.org
> > Subject: [PATCH] bnx2x: add support for receive hashing
> >
> > Add support to bnx2x to extract Toeplitz hash out of the receive descriptor
> > for use in skb->rxhash.
> >
> > Signed-off-by: Tom Herbert <therbert@google.com>
> > ---
> > diff --git a/drivers/net/bnx2x.h b/drivers/net/bnx2x.h
> > index 0819530..8bd2368 100644
> > --- a/drivers/net/bnx2x.h
> > +++ b/drivers/net/bnx2x.h
> > @@ -1330,7 +1330,7 @@ static inline u32 reg_poll(struct bnx2x *bp, u32 reg,
> > u32 expected, int ms,
> > AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY | \
> > AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY)
> >
> > -#define MULTI_FLAGS(bp) \
> > +#define RSS_FLAGS(bp) \
> > (TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_IPV4_CAPABILITY | \
> > TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_IPV4_TCP_CAPABILITY | \
> > TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_IPV6_CAPABILITY | \
> > diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
> > index 0c6dba2..613f727 100644
> > --- a/drivers/net/bnx2x_main.c
> > +++ b/drivers/net/bnx2x_main.c
> > @@ -1582,7 +1582,7 @@ static int bnx2x_rx_int(struct bnx2x_fastpath *fp,
> int
> > budget)
> > struct sw_rx_bd *rx_buf = NULL;
> > struct sk_buff *skb;
> > union eth_rx_cqe *cqe;
> > - u8 cqe_fp_flags;
> > + u8 cqe_fp_flags, cqe_fp_status_flags;
> > u16 len, pad;
> >
> > comp_ring_cons = RCQ_BD(sw_comp_cons);
> > @@ -1598,6 +1598,7 @@ static int bnx2x_rx_int(struct bnx2x_fastpath *fp,
> int
> > budget)
> >
> > cqe = &fp->rx_comp_ring[comp_ring_cons];
> > cqe_fp_flags = cqe->fast_path_cqe.type_error_flags;
> > + cqe_fp_status_flags = cqe->fast_path_cqe.status_flags;
> >
> > DP(NETIF_MSG_RX_STATUS, "CQE type %x err %x status %x"
> > " queue %x vlan %x len %u\n", CQE_TYPE(cqe_fp_flags),
> > @@ -1727,6 +1728,12 @@ reuse_rx:
> >
> > skb->protocol = eth_type_trans(skb, bp->dev);
> >
> > + if ((bp->dev->features & ETH_FLAG_RXHASH) &&
> > + (cqe_fp_status_flags &
> > + ETH_FAST_PATH_RX_CQE_RSS_HASH_FLG))
> > + skb->rxhash = le32_to_cpu(
> > + cqe->fast_path_cqe.rss_hash_result);
> > +
> > skb->ip_summed = CHECKSUM_NONE;
> > if (bp->rx_csum) {
> > if (likely(BNX2X_RX_CSUM_OK(cqe)))
> > @@ -5750,10 +5757,10 @@ static void bnx2x_init_internal_func(struct bnx2x
> > *bp)
> > u32 offset;
> > u16 max_agg_size;
> >
> > - if (is_multi(bp)) {
> > - tstorm_config.config_flags = MULTI_FLAGS(bp);
> > + tstorm_config.config_flags = RSS_FLAGS(bp);
> > +
> > + if (is_multi(bp))
> > tstorm_config.rss_result_mask = MULTI_MASK;
> > - }
> >
> > /* Enable TPA if needed */
> > if (bp->flags & TPA_ENABLE_FLAG)
> > @@ -6629,10 +6636,8 @@ static int bnx2x_init_common(struct bnx2x *bp)
> > bnx2x_init_block(bp, PBF_BLOCK, COMMON_STAGE);
> >
> > REG_WR(bp, SRC_REG_SOFT_RST, 1);
> > - for (i = SRC_REG_KEYRSS0_0; i <= SRC_REG_KEYRSS1_9; i += 4) {
> > - REG_WR(bp, i, 0xc0cac01a);
> > - /* TODO: replace with something meaningful */
> > - }
> > + for (i = SRC_REG_KEYRSS0_0; i <= SRC_REG_KEYRSS1_9; i += 4)
> > + REG_WR(bp, i, random32());
> > bnx2x_init_block(bp, SRCH_BLOCK, COMMON_STAGE);
> > #ifdef BCM_CNIC
> > REG_WR(bp, SRC_REG_KEYSEARCH_0, 0x63285672);
> > @@ -11001,6 +11006,11 @@ static int bnx2x_set_flags(struct net_device *dev,
> > u32 data)
> > changed = 1;
> > }
> >
> > + if (data & ETH_FLAG_RXHASH)
> > + dev->features |= NETIF_F_RXHASH;
> > + else
> > + dev->features &= ~NETIF_F_RXHASH;
> > +
> > if (changed && netif_running(dev)) {
> > bnx2x_nic_unload(bp, UNLOAD_NORMAL);
> > rc = bnx2x_nic_load(bp, LOAD_NORMAL);
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Possible bug in net/ipv4/route.c?
From: Herbert Xu @ 2010-07-06 7:29 UTC (permalink / raw)
To: Guojun Jin
Cc: Stephen Hemminger, Sol Kavy, linux-kernel, Greg Ren, Murat Sezgin,
Sener Ilgen, David S. Miller, netdev
In-Reply-To: <CB2DD11991B27C4F99935E6229450D3203950BE5@STORK.scenix.com>
On Mon, Jul 05, 2010 at 11:06:30PM -0700, Guojun Jin wrote:
>
> Would you please point to where is the best place that CB should be cleared for this case?
>
> I also wonder why IP packet is routed through ARP queue for ICMP delievry.
I was hoping that you guys would figure this out :)
Anyway, this patch should fix the crash.
bridge: Clear IPCB before possible entry into IP stack
The bridge protocol lives dangerously by having incestuous relations
with the IP stack. In this instance an abomination has been created
where a bogus IPCB area from a bridged packet leads to a crash in
the IP stack because it's interpreted as IP options.
This patch papers over the problem by clearing the IPCB area in that
particular spot. To fix this properly we'd also need to parse any
IP options if present but I'm way too lazy for that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 4442099..8fb75f8 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -591,6 +591,9 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
pskb_trim_rcsum(skb, len);
+ /* BUG: Should really parse the IP options here. */
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+
nf_bridge_put(skb->nf_bridge);
if (!nf_bridge_alloc(skb))
return NF_DROP;
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH -net-2.6] ll_temac: Fix missing iounmaps
From: Denis Kirjanov @ 2010-07-06 7:44 UTC (permalink / raw)
To: davem; +Cc: john.linn, brian.hill, netdev
Fix missing iounmaps.
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
drivers/net/ll_temac_main.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 52dcc84..6474c49 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -964,7 +964,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
np = of_parse_phandle(op->dev.of_node, "llink-connected", 0);
if (!np) {
dev_err(&op->dev, "could not find DMA node\n");
- goto nodev;
+ goto err_iounmap;
}
/* Setup the DMA register accesses, could be DCR or memory mapped */
@@ -978,7 +978,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
dev_dbg(&op->dev, "MEM base: %p\n", lp->sdma_regs);
} else {
dev_err(&op->dev, "unable to map DMA registers\n");
- goto nodev;
+ goto err_iounmap;
}
}
@@ -987,7 +987,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
if ((lp->rx_irq == NO_IRQ) || (lp->tx_irq == NO_IRQ)) {
dev_err(&op->dev, "could not determine irqs\n");
rc = -ENOMEM;
- goto nodev;
+ goto err_iounmap_2;
}
of_node_put(np); /* Finished with the DMA node; drop the reference */
@@ -997,7 +997,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
if ((!addr) || (size != 6)) {
dev_err(&op->dev, "could not find MAC address\n");
rc = -ENODEV;
- goto nodev;
+ goto err_iounmap_2;
}
temac_set_mac_address(ndev, (void *)addr);
@@ -1013,7 +1013,7 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
rc = sysfs_create_group(&lp->dev->kobj, &temac_attr_group);
if (rc) {
dev_err(lp->dev, "Error creating sysfs files\n");
- goto nodev;
+ goto err_iounmap_2;
}
rc = register_netdev(lp->ndev);
@@ -1026,6 +1026,11 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
err_register_ndev:
sysfs_remove_group(&lp->dev->kobj, &temac_attr_group);
+ err_iounmap_2:
+ if (lp->sdma_regs)
+ iounmap(lp->sdma_regs);
+ err_iounmap:
+ iounmap(lp->regs);
nodev:
free_netdev(ndev);
ndev = NULL;
@@ -1044,6 +1049,9 @@ static int __devexit temac_of_remove(struct of_device *op)
of_node_put(lp->phy_node);
lp->phy_node = NULL;
dev_set_drvdata(&op->dev, NULL);
+ iounmap(lp->regs);
+ if (lp->sdma_regs)
+ iounmap(lp->sdma_regs);
free_netdev(ndev);
return 0;
}
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 00/11] ISDN patches for 2.6.36
From: Tilman Schmidt @ 2010-07-06 7:47 UTC (permalink / raw)
To: David Miller; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705.185352.39176355.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Am 2010-07-06 03:53 schrieb David Miller:
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Tue, 6 Jul 2010 02:18:32 +0200 (CEST)
>
>> Karsten, David,
>>
>> following are a series of patches to the Gigaset driver I'd like
>> to see included in kernel release 2.6.36.
>
> Do they have any dependencies on the two patch set of fixes
> you just sent out for net-2.6?
None. They are completely independent.
I guess your question arose because I gave both series the same
title by mistake. The second one should have been called:
"*Gigaset* patches for 2.6.36".
Thanks,
Tilman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCH 05/11] isdn/gigaset: improve CAPI message debugging
From: Tilman Schmidt @ 2010-07-06 8:14 UTC (permalink / raw)
To: David Miller; +Cc: isdn, hjlipp, keil, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100705.192356.52184135.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Am 2010-07-06 04:23 schrieb David Miller:
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Tue, 6 Jul 2010 02:18:59 +0200 (CEST)
>
>> @@ -384,7 +388,7 @@ void gigaset_skb_sent(struct bc_state *bcs, struct sk_buff *dskb)
>>
>> /* don't send further B3 messages if disconnected */
>> if (bcs->apconnstate < APCONN_ACTIVE) {
>> - gig_dbg(DEBUG_LLDATA, "disconnected, discarding ack");
>> + gig_dbg(DEBUG_MCMD, "disconnected, discarding ack");
>> return;
>> }
>
> This is against something other than net-next-2.6 even with your
> other two ISDN patches applied, because all of these lines read
> "if (ap->connected ..."
>
> Please tell me what exactly these patches are against so that I
> can apply them to net-next-2.6 cleanly.
They are against mainline and apply cleanly to v2.6.35-rc3.
IOW, they go on top of the series you applied to net-2.6 on
Fri, 25 Jun 2010 21:31:28 -0700 (PDT).
Specifically, the last patch of that series,
> Subject: [PATCH 5/5] isdn/gigaset: correct CAPI connection state storage
makes the switch from ap->connected to bcs->apconnstate.
So if you'll postpone applying last night's series until
after your next merge of net-2.6 into net-next-2.6, it
should then apply cleanly.
Thanks,
Tilman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: Rémi Denis-Courmont @ 2010-07-06 8:17 UTC (permalink / raw)
To: Philip Prindeville; +Cc: netdev
In-Reply-To: <4C2F7A55.5090700@redfish-solutions.com>
On Sat, 03 Jul 2010 11:58:45 -0600, Philip Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> Does anyone else think that setsockopt(IP_TOS) should be a privileged
> operation, perhaps using CAP_NET_ADMIN, or maybe even adding separate
> granularity as CAP_NET_TOS?
That's a terribly idea.
Some applications do rely on this to set their TOS "correctly". If you
don't want unprivileged applications to be able to affect the queuing
policy, then don't use the TOS bits in your queuing policy - as simple as
that.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Dear friend,
From: mamudadiallo @ 2010-07-06 10:17 UTC (permalink / raw)
Dear friend,
I want to transfer ($2,500.000.00) Two million Five hundred thousand United States Dollars to overseas account.
Your assistance as a foreigner is necessary because the management of the bank will welcome any foreigner who has correct information to this account which I will give to you immediately, if you are interested to do this business with me please reply with the assurance, include your private telephone and fax numbers as it is necessary to facilitate an easy communication in this transaction.
As soon as you reply, I will let you know the next step to follow in order to finalize this transaction immediately. I expect your urgent communication.
Upon your response and strong assurance that you will not let me down once the fund goes into your account.
I will let you know the origin of the fund and the transfer procedures without delay.
Yours sincerely.
MAMUDA DIALLO
^ permalink raw reply
* Re: setsockopt(IP_TOS) being privileged or distinct capability?
From: Benny Amorsen @ 2010-07-06 10:56 UTC (permalink / raw)
To: Philip Prindeville; +Cc: Alexander Clouter, netdev
In-Reply-To: <4C321EAF.9000508@redfish-solutions.com>
Philip Prindeville <philipp_subx@redfish-solutions.com> writes:
> Once QoS markings actually *are* implemented in carrier networks, the
> potential for abuse is non-insignificant. Hence the suggestion to
> make it privileged.
I think you are overestimating the potential for abuse. ISP's who
oversubscribe enough to suffer from heavy congestion internally should
stop doing that and most likely have fancy congestion control equipment
installed. That equipment can apply all sorts of limits to prioritized
traffic.
For a more typical ISP, marking TCP packets with EF means you get
marginally lower and more stable latency but risk increased packet loss.
TCP does not mind a little extra latency and suffers badly from packet
loss, so that behaviour should be self-limiting.
/Benny
^ permalink raw reply
* [PATCH kernel 2.6.35-rc3-git7] axnet_cs: local_irq_save before calling ei_irq_wrapper
From: Ken Kawasaki @ 2010-07-06 11:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100620102427.77d2c7d3.ken_kawasaki@spring.nifty.jp>
axnet_cs:
local_irq_save before calling ei_irq_wrapper.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.35-git7/drivers/net/pcmcia/axnet_cs.c.orig 2010-07-04 08:28:15.000000000 +0900
+++ linux-2.6.35-git7/drivers/net/pcmcia/axnet_cs.c 2010-07-04 08:40:23.000000000 +0900
@@ -606,6 +606,7 @@ static void ei_watchdog(u_long arg)
unsigned int nic_base = dev->base_addr;
unsigned int mii_addr = nic_base + AXNET_MII_EEP;
u_short link;
+ unsigned long flags;
if (!netif_device_present(dev)) goto reschedule;
@@ -614,7 +615,10 @@ static void ei_watchdog(u_long arg)
if (info->stale++ && (inb_p(nic_base + EN0_ISR) & ENISR_ALL)) {
if (!info->fast_poll)
printk(KERN_INFO "%s: interrupt(s) dropped!\n", dev->name);
+ local_irq_save(flags);
ei_irq_wrapper(dev->irq, dev);
+ local_irq_restore(flags);
+
info->fast_poll = HZ;
}
if (info->fast_poll) {
^ permalink raw reply
* Re: [patch v2.3 1/4] netfilter: xt_ipvs (netfilter matcher for IPVS)
From: Patrick McHardy @ 2010-07-06 11:32 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, linux-kernel, netfilter, netfilter-devel,
Malcolm Turnbull, Wensong Zhang, Julius Volz, David S. Miller,
Hannes Eder
In-Reply-To: <20100704114808.459045895@vergenet.net>
Simon Horman wrote:
> From: Hannes Eder <heder@google.com>
>
> This implements the kernel-space side of the netfilter matcher xt_ipvs.
>
> @@ -0,0 +1,25 @@
> +#ifndef _XT_IPVS_H
> +#define _XT_IPVS_H
> +
> +#define XT_IPVS_IPVS_PROPERTY (1 << 0) /* all other options imply this one */
> +#define XT_IPVS_PROTO (1 << 1)
> +#define XT_IPVS_VADDR (1 << 2)
> +#define XT_IPVS_VPORT (1 << 3)
> +#define XT_IPVS_DIR (1 << 4)
> +#define XT_IPVS_METHOD (1 << 5)
> +#define XT_IPVS_VPORTCTL (1 << 6)
> +#define XT_IPVS_MASK ((1 << 7) - 1)
> +#define XT_IPVS_ONCE_MASK (XT_IPVS_MASK & ~XT_IPVS_IPVS_PROPERTY)
> +
> +struct xt_ipvs_mtinfo {
> + union nf_inet_addr vaddr, vmask;
> + __be16 vport;
> + __u16 l4proto;
> + __u16 fwd_method;
>
It seems you could use __u8 for both l4proto and fwd_method
and reduce the match size by 2 bytes.
> + __be16 vportctl;
> +
> + __u8 invert;
> + __u8 bitmask;
> +};
> +static bool
> +ipvs_mt(const struct sk_buff *skb, struct xt_action_param *par)
> +...
>
> + if (data->bitmask & XT_IPVS_DIR) {
> + enum ip_conntrack_info ctinfo;
> + struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
> +
> + if (ct == NULL || ct == &nf_conntrack_untracked) {
>
We're using per-cpu structures for nf_conntrack_untracked in the
current net-next/nf-next tree, so this doesn't work anymore. You
need to use nf_ct_is_untracked() instead.
> + match = false;
> + goto out_put_cp;
> + }
^ permalink raw reply
* Re: [patch v2.3 2/4] IPVS: make friends with nf_conntrack
From: Patrick McHardy @ 2010-07-06 11:36 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, linux-kernel, netfilter, netfilter-devel,
Malcolm Turnbull, Wensong Zhang, Julius Volz, David S. Miller,
Hannes Eder
In-Reply-To: <20100704114808.668473084@vergenet.net>
Simon Horman wrote:
> +static void
> +ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp)
> +{
> + struct nf_conn *ct = (struct nf_conn *)skb->nfct;
> + struct nf_conntrack_tuple new_tuple;
> +
> + if (ct == NULL || ct == &nf_conntrack_untracked ||
> + nf_ct_is_confirmed(ct))
>
Similar to the last patch, this needs to use nf_ct_is_untracked().
> + return;
> +
^ permalink raw reply
* Re: [patch v2.3 3/4] IPVS: make FTP work with full NAT support
From: Patrick McHardy @ 2010-07-06 11:43 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, linux-kernel, netfilter, netfilter-devel,
Malcolm Turnbull, Wensong Zhang, Julius Volz, David S. Miller,
Hannes Eder
In-Reply-To: <20100704114808.932594876@vergenet.net>
Simon Horman wrote:
> @@ -219,19 +358,23 @@ static int ip_vs_ftp_out(struct ip_vs_ap
>
> buf_len = strlen(buf);
>
> + ct = nf_ct_get(skb, &ctinfo);
> + ret = nf_nat_mangle_tcp_packet(skb,
> + ct,
> + ctinfo,
> + start-data,
> + end-start,
> + buf,
> + buf_len);
> +
> + if (ct && ct != &nf_conntrack_untracked)
>
This does not make sense, you're already using the conntrack above
in the call to nf_nat_mangle_tcp_packet(), so the check should
probably happen before that. You also should be checking the
return value of nf_nat_mangle_tcp_packet() before setting up the
expectation.
> + ip_vs_expect_related(skb, ct, n_cp,
> + IPPROTO_TCP, NULL, 0);
^ permalink raw reply
* Re: iwl3945: HARDWARE GONE??
From: Priit Laes @ 2010-07-06 12:48 UTC (permalink / raw)
To: Robert Hancock; +Cc: netdev, linux-kernel
In-Reply-To: <4C32766C.4080305@gmail.com>
Ühel kenal päeval, E, 2010-07-05 kell 18:18, kirjutas Robert Hancock:
> On 07/02/2010 10:02 AM, Priit Laes wrote:
> > Heya!
> >
> > Bumped my kernel to version 2.6.35-rc3-00391-g97e0214 and ran into
> > HARDWARE GONE error message..
> >
> > Hardware is Lenovo x60s and wireless card is intel 3945:
> >
> > 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
> > Subsystem: Intel Corporation ThinkPad R60e/X60s
> > Flags: bus master, fast devsel, latency 0, IRQ 47
> > Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
> > Capabilities: [c8] Power Management version 2
> > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Capabilities: [e0] Express Legacy Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [140] Device Serial Number 00-xx-xx-xx-xx-xx-xx-xx
> > Kernel driver in use: iwl3945
> > Kernel modules: iwl3945
>
> Wonder if somehow an ACPI power resource powering the wireless card got
> switched off? What previous kernel version was working, can you try
> bisecting?
Bisecting is a bit hard, because I haven't seen this issue anymore :(
^ 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