* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: David Dillow @ 2009-08-22 20:43 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <m18whcf3w2.fsf@fess.ebiederm.org>
On Sat, 2009-08-22 at 05:07 -0700, Eric W. Biederman wrote:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > David Dillow <dave@thedillows.org> writes:
> >
> >>
> >> Re-looking at the code, I'd guess that some IRQ status line is getting
> >> stuck high, but I don't see why -- we should acknowledge all outstanding
> >> interrupts each time through the loop, whether we care about them or
> >> not.
> >>
> >> Could reproduce a problem with the following patch applied, and send the
> >> full dmesg, please?
> >
> > Here is what I get.
> >
> > r8169 screaming irq status 00000085 mask 0000ffff event 0000803f napi 0000001d
>
> And now that the machine has come out of it, that was followed by:
> Looks like the soft lockup did not manage to trigger in this case.
I need some more context, please. What is the network load through this
NIC when you have the issues? Light, heavy? Can you give me more details
about the machine? A full dmesg from boot until this happens would help
quite a bit. At a minimum it would help answer which version of the chip
we're dealing with and what the machine it is in looks like.
Can you reproduce this with pci=nomsi? I'm assuming it the chip running
in MSI mode.
Also, can you reproduce it when booting UP (or maxcpus=1)? I'm thinking
about a race between rtl8169_interrupt() and rtl8169_poll(), but it
isn't jumping out at me.
Also, I'm having connectivity troubles this weekend, so my response may
be spotty. :(
^ permalink raw reply
* Re: Strange network timeouts w/ 2.6.30.5
From: Krzysztof Halasa @ 2009-08-22 20:26 UTC (permalink / raw)
To: Walt Holman; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <987943678.21250869504786.JavaMail.root@mail.holmansrus.com>
Walt Holman <walt@holmansrus.com> writes:
> Just got a chance to test this for confirmation. When limiting the
> RAM to 2GB, the patched driver appears to work OK.
Thanks for confirming this.
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH 1/1] NET: llc, zero sockaddr_llc struct
From: Jiri Slaby @ 2009-08-22 18:58 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Jiri Slaby, Arnaldo Carvalho de Melo
sllc_arphrd member of sockaddr_llc might not be set. Zero sllc
before copying it to the above layers.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
---
net/llc/af_llc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index 9208cf5..22629fc 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -909,7 +909,7 @@ release:
static int llc_ui_getname(struct socket *sock, struct sockaddr *uaddr,
int *uaddrlen, int peer)
{
- struct sockaddr_llc sllc;
+ struct sockaddr_llc sllc = {};
struct sock *sk = sock->sk;
struct llc_sock *llc = llc_sk(sk);
int rc = 0;
--
1.6.3.3
^ permalink raw reply related
* Re: [Bridge] VLANs and bridge
From: Simon Barber @ 2009-08-22 17:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: bridge, netdev
In-Reply-To: <OF9BD07CB5.A2197AEA-ONC125761A.005AE004-C125761A.005B662E@transmode.se>
Looking through B.1.3 it looks like the patch would need some
enhancement. It provides a good basis - handling tagging/untagging and
filtering, but would need a way to specify the untagged vlan separately
for in and out.
Simon
Joakim Tjernlund wrote:
> Joakim Tjernlund/Transmode wrote on 22/08/2009 17:36:54:
>
>> Simon Barber <simon@superduper.net> wrote on 22/08/2009 16:34:11:
>>
>>> Hi Joakim,
>>>
>>> Look back a month or so in the archives - you'll find an email from me
>>> referencing a patch to make the bridge VLAN aware. It's a little old,
>>> and needs updating for 2.6 (it was written for 2.4) - but should not be
>>> much work to get it done. There is a matching patch for the brctl utility.
>>>
>>> Simon
>>>
>>>
>> Thanks Simon
>>
>> Do you mean the "bridge vlan integration" patch?
>> It is not clear to me if this would support the case
>> described in B.1.3(802.1Q-2005), does it?
>>
>> Seems like there is little interest to post this to 2.6 and
>> I am not sure how welcome this would be either, perhaps
>> the bridge maintainer could comment?
>>
>> Jocke
>>
>
> Thinking a bit more about this I could envision some changes to the
> vlan code too. I image one could create one vlan interface which will listen
> to several VLANs. One VLAN is the primary VLAN and is used in the tx path
> by default. The bridge would be able to filter on individual VLANs received
> from such interface and be able to chose outgoing VLAN too.
>
> Jocke
>
>
^ permalink raw reply
* Re: [Bridge] VLANs and bridge
From: Joakim Tjernlund @ 2009-08-22 16:38 UTC (permalink / raw)
Cc: bridge, netdev, Simon Barber
In-Reply-To: <OF2C06F138.1BC279AE-ONC125761A.0054117B-C125761A.0055C6F1@LocalDomain>
Joakim Tjernlund/Transmode wrote on 22/08/2009 17:36:54:
>
> Simon Barber <simon@superduper.net> wrote on 22/08/2009 16:34:11:
> >
> > Hi Joakim,
> >
> > Look back a month or so in the archives - you'll find an email from me
> > referencing a patch to make the bridge VLAN aware. It's a little old,
> > and needs updating for 2.6 (it was written for 2.4) - but should not be
> > much work to get it done. There is a matching patch for the brctl utility.
> >
> > Simon
> >
>
> Thanks Simon
>
> Do you mean the "bridge vlan integration" patch?
> It is not clear to me if this would support the case
> described in B.1.3(802.1Q-2005), does it?
>
> Seems like there is little interest to post this to 2.6 and
> I am not sure how welcome this would be either, perhaps
> the bridge maintainer could comment?
>
> Jocke
Thinking a bit more about this I could envision some changes to the
vlan code too. I image one could create one vlan interface which will listen
to several VLANs. One VLAN is the primary VLAN and is used in the tx path
by default. The bridge would be able to filter on individual VLANs received
from such interface and be able to chose outgoing VLAN too.
Jocke
^ permalink raw reply
* Re: [Bridge] VLANs and bridge
From: Joakim Tjernlund @ 2009-08-22 15:36 UTC (permalink / raw)
To: Simon Barber; +Cc: bridge, netdev
In-Reply-To: <4A9001E3.6060506@superduper.net>
Simon Barber <simon@superduper.net> wrote on 22/08/2009 16:34:11:
>
> Hi Joakim,
>
> Look back a month or so in the archives - you'll find an email from me
> referencing a patch to make the bridge VLAN aware. It's a little old,
> and needs updating for 2.6 (it was written for 2.4) - but should not be
> much work to get it done. There is a matching patch for the brctl utility.
>
> Simon
>
Thanks Simon
Do you mean the "bridge vlan integration" patch?
It is not clear to me if this would support the case
described in B.1.3(802.1Q-2005), does it?
Seems like there is little interest to post this to 2.6 and
I am not sure how welcome this would be either, perhaps
the bridge maintainer could comment?
Jocke
>
> Joakim Tjernlund wrote:
> > This is probably no news to experienced bridge and VLAN users but I just learned the
> > hard way that Shared VLAN learning(SVL) isn't supported
> > by the linux bridge making it impossible to support configurations described in B.1.3
> > Basically the bride needs to be made VLAN aware and the VLAN code needs to be adopted
> > to allow this.
> >
> > I figured I should mention it in case it is just an oversight. It does not
> look like a simple
> > job though.
> >
> > Jocke
> >
> > _______________________________________________
> > Bridge mailing list
> > Bridge@lists.linux-foundation.org
> > https://lists.linux-foundation.org/mailman/listinfo/bridge
> >
>
>
>
^ permalink raw reply
* Re: E100 RX ring buffers continued...
From: Krzysztof Halasa @ 2009-08-22 15:32 UTC (permalink / raw)
To: netdev
Cc: David Miller, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
PJ Waskiewicz, John Ronciak
In-Reply-To: <m38whchrer.fsf@intrepid.localdomain>
Krzysztof Halasa <khc@pm.waw.pl> writes:
> There is also apparently unsupported and mostly undocumented "flexible
> mode". The question to Intel's experts: can the flexible mode be used
> anyway? I can write the code, but need info about eg. the data
> structures (RFD, how does it work in flexible mode) and a confirmation
> the silicon (or maybe which silicon) will work with it.
I can see there is some "erratum" in 82559 related to flexible RX mode.
It seems we're not affected, though - it requires more than 1 RBD (per
RFD I hope) for the problem to happen.
Do I get it right?
--
Krzysztof Halasa
^ permalink raw reply
* ''''congratulations you won''''''
From: prnmedia @ 2009-08-22 15:17 UTC (permalink / raw)
To: unl
800,000.00 GBP and new peugeot 407 car your personal datails for claim
^ permalink raw reply
* Re: VLANs and bridge
From: Simon Barber @ 2009-08-22 14:34 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev, bridge
In-Reply-To: <OFC5BA9A4A.DCCE8D0D-ONC125761A.004A7620-C125761A.004BEA17@transmode.se>
Hi Joakim,
Look back a month or so in the archives - you'll find an email from me
referencing a patch to make the bridge VLAN aware. It's a little old,
and needs updating for 2.6 (it was written for 2.4) - but should not be
much work to get it done. There is a matching patch for the brctl utility.
Simon
Joakim Tjernlund wrote:
> This is probably no news to experienced bridge and VLAN users but I just learned the
> hard way that Shared VLAN learning(SVL) isn't supported
> by the linux bridge making it impossible to support configurations described in B.1.3
> Basically the bride needs to be made VLAN aware and the VLAN code needs to be adopted
> to allow this.
>
> I figured I should mention it in case it is just an oversight. It does not look like a simple
> job though.
>
> Jocke
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>
^ permalink raw reply
* E100 RX ring buffers continued...
From: Krzysztof Halasa @ 2009-08-22 14:09 UTC (permalink / raw)
To: netdev
Cc: David Miller, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
PJ Waskiewicz, John Ronciak
Hi,
E100 RX buffers seem more problematic than I though.
The descriptor doesn't contain the address of the data buffer. Instead,
the descriptor is to be followed by the data buffer immediately. It's
not only the driver invention :-(
The manual mentions it's the only mode supported, aka "simplified mode".
There is also apparently unsupported and mostly undocumented "flexible
mode". The question to Intel's experts: can the flexible mode be used
anyway? I can write the code, but need info about eg. the data
structures (RFD, how does it work in flexible mode) and a confirmation
the silicon (or maybe which silicon) will work with it.
TIA.
--
Krzysztof Halasa
^ permalink raw reply
* VLANs and bridge
From: Joakim Tjernlund @ 2009-08-22 13:49 UTC (permalink / raw)
To: netdev, bridge
This is probably no news to experienced bridge and VLAN users but I just learned the
hard way that Shared VLAN learning(SVL) isn't supported
by the linux bridge making it impossible to support configurations described in B.1.3
Basically the bride needs to be made VLAN aware and the VLAN code needs to be adopted
to allow this.
I figured I should mention it in case it is just an oversight. It does not look like a simple
job though.
Jocke
^ permalink raw reply
* [PATCH] Fix useless test: int > INT_MAX
From: Nicolas de Pesloüan @ 2009-08-22 12:17 UTC (permalink / raw)
To: netdev, bonding-devel; +Cc: Cyril Chaboisseau
max_bonds is of type int and cannot be greater than INT_MAX.
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
drivers/net/bonding/bond_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 4798d30..edd71a1 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4755,7 +4755,7 @@ static int bond_check_params(struct bond_params *params)
params->ad_select = BOND_AD_STABLE;
}
- if (max_bonds < 0 || max_bonds > INT_MAX) {
+ if (max_bonds < 0) {
pr_warning(DRV_NAME
": Warning: max_bonds (%d) not in range %d-%d, so it "
"was reset to BOND_DEFAULT_MAX_BONDS (%d)\n",
^ permalink raw reply related
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: Eric W. Biederman @ 2009-08-22 12:07 UTC (permalink / raw)
To: David Dillow
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <m1iqggf4rf.fsf@fess.ebiederm.org>
ebiederm@xmission.com (Eric W. Biederman) writes:
> David Dillow <dave@thedillows.org> writes:
>
>>
>> Re-looking at the code, I'd guess that some IRQ status line is getting
>> stuck high, but I don't see why -- we should acknowledge all outstanding
>> interrupts each time through the loop, whether we care about them or
>> not.
>>
>> Could reproduce a problem with the following patch applied, and send the
>> full dmesg, please?
>
> Here is what I get.
>
> r8169 screaming irq status 00000085 mask 0000ffff event 0000803f napi 0000001d
And now that the machine has come out of it, that was followed by:
Looks like the soft lockup did not manage to trigger in this case.
------------[ cut here ]------------
WARNING: at /home/ebiederm/projects/linux/linux-2.6.30-Arora/net/sched/sch_generic.c:226 dev_watchdog+0xd9/0x14a()
Hardware name: G33M-S2
NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Modules linked in: tulip xt_tcpudp iptable_filter nfsd lockd nfs_acl auth_rpcgss bridge stp exportfs bnep sco l2cap bluetooth sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table ext4 jbd2 crc16 dm_mirror dm_region_hash dm_log dm_multipath dm_mod uinput kvm_intel kvm fuse xt_multiport iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 tun 8021q snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ppdev ata_generic snd_timer firewire_ohci pata_acpi parport_pc snd firewire_core parport r8169 i2c_i801 pata_jmicron mii pcspkr soundcore sg iTCO_wdt floppy iTCO_vendor_support snd_page_alloc crc_itu_t ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd i915 drm i2c_algo_bit video output i2c_core [last unloaded: microcode]
Pid: 0, comm: swapper Not tainted 2.6.30eric-rtl8169-debug #36
Call Trace:
<IRQ> [<ffffffff8104583b>] warn_slowpath_common+0x88/0xb6
[<ffffffff812ee53c>] ? dev_watchdog+0x0/0x14a
[<ffffffff810458ec>] warn_slowpath_fmt+0x4b/0x61
[<ffffffff812d607e>] ? netdev_drivername+0x52/0x70
[<ffffffff812ee615>] dev_watchdog+0xd9/0x14a
[<ffffffff810596de>] ? __queue_work+0x44/0x61
[<ffffffff81050922>] run_timer_softirq+0x169/0x1f5
[<ffffffff81020306>] ? apic_write+0x24/0x3a
[<ffffffff81069ce2>] ? clockevents_program_event+0x88/0xa5
[<ffffffff8104ba7b>] __do_softirq+0xc3/0x1b0
[<ffffffff8100cfcc>] call_softirq+0x1c/0x28
[<ffffffff8100e721>] do_softirq+0x51/0xae
[<ffffffff8104b6d2>] irq_exit+0x52/0xa3
[<ffffffff81020f11>] smp_apic_timer_interrupt+0x94/0xb8
[<ffffffff8100c9d3>] apic_timer_interrupt+0x13/0x20
<EOI> [<ffffffff81014096>] ? mwait_idle+0x9b/0xcc
[<ffffffff81014038>] ? mwait_idle+0x3d/0xcc
[<ffffffff8100ae08>] ? enter_idle+0x33/0x49
[<ffffffff8100aece>] ? cpu_idle+0xb0/0xf3
[<ffffffff8136f25c>] ? start_secondary+0x19c/0x1b7
---[ end trace 595b23907a063360 ]---
^ permalink raw reply
* Re: [PATCH 1/2]: pkt_sched: Convert qdisc_watchdog to tasklet_hrtimer
From: Jarek Poplawski @ 2009-08-22 12:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, tglx
In-Reply-To: <20090821.170330.217935645.davem@davemloft.net>
David Miller wrote, On 08/22/2009 02:03 AM:
> None of this stuff should execute in hw IRQ context, therefore
> use a tasklet_hrtimer so that it runs in softirq context.
Do you mean __netif_schedule()? Could you explain it more?
Thanks,
Jarek P.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> include/net/pkt_sched.h | 4 ++--
> net/sched/sch_api.c | 8 ++++----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
> index 82a3191..7eafb8d 100644
> --- a/include/net/pkt_sched.h
> +++ b/include/net/pkt_sched.h
> @@ -61,8 +61,8 @@ psched_tdiff_bounded(psched_time_t tv1, psched_time_t tv2, psched_time_t bound)
> }
>
> struct qdisc_watchdog {
> - struct hrtimer timer;
> - struct Qdisc *qdisc;
> + struct tasklet_hrtimer timer;
> + struct Qdisc *qdisc;
> };
>
> extern void qdisc_watchdog_init(struct qdisc_watchdog *wd, struct Qdisc *qdisc);
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index 24d17ce..e1c2bf7 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -468,8 +468,8 @@ static enum hrtimer_restart qdisc_watchdog(struct hrtimer *timer)
>
> void qdisc_watchdog_init(struct qdisc_watchdog *wd, struct Qdisc *qdisc)
> {
> - hrtimer_init(&wd->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> - wd->timer.function = qdisc_watchdog;
> + tasklet_hrtimer_init(&wd->timer, qdisc_watchdog,
> + CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> wd->qdisc = qdisc;
> }
> EXPORT_SYMBOL(qdisc_watchdog_init);
> @@ -485,13 +485,13 @@ void qdisc_watchdog_schedule(struct qdisc_watchdog *wd, psched_time_t expires)
> wd->qdisc->flags |= TCQ_F_THROTTLED;
> time = ktime_set(0, 0);
> time = ktime_add_ns(time, PSCHED_TICKS2NS(expires));
> - hrtimer_start(&wd->timer, time, HRTIMER_MODE_ABS);
> + tasklet_hrtimer_start(&wd->timer, time, HRTIMER_MODE_ABS);
> }
> EXPORT_SYMBOL(qdisc_watchdog_schedule);
>
> void qdisc_watchdog_cancel(struct qdisc_watchdog *wd)
> {
> - hrtimer_cancel(&wd->timer);
> + tasklet_hrtimer_cancel(&wd->timer);
> wd->qdisc->flags &= ~TCQ_F_THROTTLED;
> }
> EXPORT_SYMBOL(qdisc_watchdog_cancel);
^ permalink raw reply
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: Eric W. Biederman @ 2009-08-22 11:48 UTC (permalink / raw)
To: David Dillow
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <1250897657.23419.5.camel@obelisk.thedillows.org>
David Dillow <dave@thedillows.org> writes:
>
> Re-looking at the code, I'd guess that some IRQ status line is getting
> stuck high, but I don't see why -- we should acknowledge all outstanding
> interrupts each time through the loop, whether we care about them or
> not.
>
> Could reproduce a problem with the following patch applied, and send the
> full dmesg, please?
Here is what I get.
r8169 screaming irq status 00000085 mask 0000ffff event 0000803f napi 0000001d
Eric
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index b82780d..46cb05a 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -3556,6 +3556,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
> void __iomem *ioaddr = tp->mmio_addr;
> int handled = 0;
> int status;
> + int count = 0;
>
> /* loop handling interrupts until we have no new ones or
> * we hit a invalid/hotplug case.
> @@ -3564,6 +3565,15 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
> while (status && status != 0xffff) {
> handled = 1;
>
> + if (count++ > 100) {
> + printk_once("r8169 screaming irq status %08x "
> + "mask %08x event %08x napi %08x\n",
> + status, tp->intr_mask, tp->intr_event,
> + tp->napi_event);
> + break;
> + }
> +
> +
> /* Handle all of the error cases first. These will reset
> * the chip, so just exit the loop.
> */
^ permalink raw reply
* [PATCH] sit: 6to4: honour routing table
From: Sascha Hlusiak @ 2009-08-22 10:47 UTC (permalink / raw)
To: netdev; +Cc: Sascha Hlusiak
Using only the actual destination address to determine the IPv4 target in
try_6to4(&iph6->daddr) seems wrong to me and breaks, if a 6to4 address is
the next-hop, like ::192.88.99.1 written as 6to4:
default via 2002:c058:6301:: dev 6to4
A package to 2001:: would fall through the try_6to4 check to the
IPv4-compat check and die there.
This patch makes try_6to4 use the address of the Next-Hop instead, respecting
the routing table. Users are encouraged to have a route 2002::/16 to the
tunnel device anyway, making all other 6to4 hosts direct neighbours.
Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de>
---
net/ipv6/sit.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 98b7327..8ae3028 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -656,8 +656,17 @@ static int ipip6_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
goto tx_error;
}
- if (!dst)
- dst = try_6to4(&iph6->daddr);
+ if (!dst) {
+ struct neighbour *neigh = NULL;
+
+ if (skb_dst(skb))
+ neigh = skb_dst(skb)->neighbour;
+
+ if (neigh) {
+ addr6 = (struct in6_addr *)&neigh->primary_key;
+ dst = try_6to4(addr6);
+ }
+ }
if (!dst) {
struct neighbour *neigh = NULL;
--
1.6.4
^ permalink raw reply related
* Re: [PATCH 2/2]: pkt_sched: Convert CBQ to tasklet_hrtimer.
From: Thomas Gleixner @ 2009-08-22 9:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090821.170333.153413841.davem@davemloft.net>
On Fri, 21 Aug 2009, David Miller wrote:
> This code expects to run in softirq context, and bare hrtimers
> run in hw IRQ context.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> @@ -510,12 +512,12 @@ static void cbq_ovl_delay(struct cbq_class *cl)
>
> expires = ktime_set(0, 0);
> expires = ktime_add_ns(expires, PSCHED_TICKS2NS(sched));
> - if (hrtimer_try_to_cancel(&q->delay_timer) &&
> - ktime_to_ns(ktime_sub(
> - hrtimer_get_expires(&q->delay_timer),
> - expires)) > 0)
> - hrtimer_set_expires(&q->delay_timer, expires);
> - hrtimer_restart(&q->delay_timer);
> + ht = &q->delay_timer.timer;
> + if (hrtimer_try_to_cancel(ht) &&
> + ktime_to_ns(ktime_sub(hrtimer_get_expires(ht),
> + expires)) > 0)
> + hrtimer_set_expires(ht, expires);
> + hrtimer_restart(ht);
This code looks still wrong. The new expiry time is only set when the
timer is already active. If the timer is not active then you restart
it with the last stale expiry time which is probably in the past, but
might be somewhere in the future as well. I doubt that this is the
intention.
So what you really want is:
cl->cpriority = TC_CBQ_MAXPRIO;
q->pmask |= (1<<TC_CBQ_MAXPRIO);
- expires = ktime_set(0, 0);
- expires = ktime_add_ns(expires, PSCHED_TICKS2NS(sched));
- if (hrtimer_try_to_cancel(&q->delay_timer) &&
- ktime_to_ns(ktime_sub(
- hrtimer_get_expires(&q->delay_timer),
- expires)) > 0)
- hrtimer_set_expires(&q->delay_timer, expires);
- hrtimer_restart(&q->delay_timer);
+ ht = &q->delay_timer.timer;
+ expires = ns_to_ktime(PSCHED_TICKS2NS(sched));
+ if (!hrtimer_active(ht) ||
+ expires.tv64 < hrtimer_get_expires(ht).tv64)
+ hrtimer_start(ht, expires, HRTIMER_MODE_ABS);
cl->delayed = 1;
cl->xstats.overactions++;
return;
This starts the timer when
1) the timer is not active
2) the timer is active and the new expiry time is before the
current one. (hrtimer_start takes care of stopping the active
timer)
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 1/2]: pkt_sched: Convert qdisc_watchdog to tasklet_hrtimer
From: Thomas Gleixner @ 2009-08-22 8:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090821.170330.217935645.davem@davemloft.net>
On Fri, 21 Aug 2009, David Miller wrote:
>
> None of this stuff should execute in hw IRQ context, therefore
> use a tasklet_hrtimer so that it runs in softirq context.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-22 5:11 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev
In-Reply-To: <1250860381.2876.19.camel@localhost.localdomain>
Thanks very much, I'll post this to linux-wireless mailing list.
2009/8/21 Dan Williams <dcbw@redhat.com>:
> On Fri, 2009-08-21 at 14:22 +0800, feng tian wrote:
>> Dear All,
>>
>> We are working on a project which supports the BCM4325 linux wireless
>> driver. The interface between the BCM chip and SOC(pxa310) is SDIO.
>> I did some searches online and found that there is no available driver
>> for this chip. Do I have to implement this myself? Is there anyone can
>> provide us some related materials? Thanks very much.
>
> You'll probably want to ask on the linux-wireless list where the
> wireless people hang out. Partial answer: there is already a driver
> (b43) for many of broadcom 802.11 devices, including some of the
> "LP-PHY" devices. This driver may or may not be suitable for the 4325
> depending on the 4325's firmware interface. The b43 driver is not yet
> capable of using SDIO to communicate with the wifi chip, but that
> appears to be what you are working on. So I'd suggest posting to the
> linux-wireless mailing list and seeing what the b43 driver people say.
>
> http://linuxwireless.org/en/developers/MailingLists
>
> Dan
>
>
>
^ permalink raw reply
* [PATCH -next 7/8] bnx2: Use const on flash_table structure.
From: Michael Chan @ 2009-08-22 2:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1250907650-24672-1-git-send-email-mchan@broadcom.com>
The structure, once initialized, never changes.
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 6 +++---
drivers/net/bnx2.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index ea6e6b7..58ab3f4 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -145,7 +145,7 @@ static DEFINE_PCI_DEVICE_TABLE(bnx2_pci_tbl) = {
{ 0, }
};
-static struct flash_spec flash_table[] =
+static const struct flash_spec flash_table[] =
{
#define BUFFERED_FLAGS (BNX2_NV_BUFFERED | BNX2_NV_TRANSLATE)
#define NONBUFFERED_FLAGS (BNX2_NV_WREN)
@@ -234,7 +234,7 @@ static struct flash_spec flash_table[] =
"Buffered flash (256kB)"},
};
-static struct flash_spec flash_5709 = {
+static const struct flash_spec flash_5709 = {
.flags = BNX2_NV_BUFFERED,
.page_bits = BCM5709_FLASH_PAGE_BITS,
.page_size = BCM5709_FLASH_PAGE_SIZE,
@@ -4227,7 +4227,7 @@ bnx2_init_nvram(struct bnx2 *bp)
{
u32 val;
int j, entry_count, rc = 0;
- struct flash_spec *flash;
+ const struct flash_spec *flash;
if (CHIP_NUM(bp) == CHIP_NUM_5709) {
bp->flash_info = &flash_5709;
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 3c004b4..7544188 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6889,7 +6889,7 @@ struct bnx2 {
int pm_cap;
int pcix_cap;
- struct flash_spec *flash_info;
+ const struct flash_spec *flash_info;
u32 flash_size;
int status_stats_size;
--
1.5.6.GIT
^ permalink raw reply related
* [PATCH -next 8/8] bnx2: Update version to 2.0.2.
From: Michael Chan @ 2009-08-22 2:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1250907650-24672-1-git-send-email-mchan@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 58ab3f4..4450177 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -59,8 +59,8 @@
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "2.0.1"
-#define DRV_MODULE_RELDATE "May 6, 2009"
+#define DRV_MODULE_VERSION "2.0.2"
+#define DRV_MODULE_RELDATE "Aug 21, 2009"
#define FW_MIPS_FILE_06 "bnx2/bnx2-mips-06-4.6.16.fw"
#define FW_RV2P_FILE_06 "bnx2/bnx2-rv2p-06-4.6.16.fw"
#define FW_MIPS_FILE_09 "bnx2/bnx2-mips-09-4.6.17.fw"
--
1.5.6.GIT
^ permalink raw reply related
* [PATCH -next 6/8] bnx2: Refine coalescing parameters.
From: Michael Chan @ 2009-08-22 2:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1250907650-24672-1-git-send-email-mchan@broadcom.com>
- Set the USE_INT_PARAM bit so the rx-frames-irq and tx-frames-irq will take
effect on 5709.
- Increase the default rx-frames to reduce interrupt count.
- Decrease the default rx-frames-irq and tx-frames-irq to catch more events
during NAPI poll.
All these will reduce interrupts without affecting latency.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index e025833..ea6e6b7 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4921,7 +4921,7 @@ bnx2_init_chip(struct bnx2 *bp)
}
if (bp->flags & BNX2_FLAG_ONE_SHOT_MSI)
- val |= BNX2_HC_CONFIG_ONE_SHOT;
+ val |= BNX2_HC_CONFIG_ONE_SHOT | BNX2_HC_CONFIG_USE_INT_PARAM;
REG_WR(bp, BNX2_HC_CONFIG, val);
@@ -7858,13 +7858,13 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
bp->rx_csum = 1;
- bp->tx_quick_cons_trip_int = 20;
+ bp->tx_quick_cons_trip_int = 2;
bp->tx_quick_cons_trip = 20;
- bp->tx_ticks_int = 80;
+ bp->tx_ticks_int = 18;
bp->tx_ticks = 80;
- bp->rx_quick_cons_trip_int = 6;
- bp->rx_quick_cons_trip = 6;
+ bp->rx_quick_cons_trip_int = 2;
+ bp->rx_quick_cons_trip = 12;
bp->rx_ticks_int = 18;
bp->rx_ticks = 18;
--
1.5.6.GIT
^ permalink raw reply related
* [PATCH -next 2/8] bnx2: Check if_running() before touching chip registers.
From: Michael Chan @ 2009-08-22 2:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1250907650-24672-1-git-send-email-mchan@broadcom.com>
Add this check to bnx2_netif_stop() and bnx2_vlan_rx_register() to
prevent bus lockups on some systems when the chip is in low power state.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index e75b6e9..9cfd460 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -619,6 +619,9 @@ bnx2_disable_int_sync(struct bnx2 *bp)
int i;
atomic_inc(&bp->intr_sem);
+ if (!netif_running(bp->dev))
+ return;
+
bnx2_disable_int(bp);
for (i = 0; i < bp->irq_nvecs; i++)
synchronize_irq(bp->irq_tbl[i].vector);
@@ -6254,9 +6257,14 @@ bnx2_vlan_rx_register(struct net_device *dev, struct vlan_group *vlgrp)
{
struct bnx2 *bp = netdev_priv(dev);
- bnx2_netif_stop(bp);
+ if (netif_running(dev))
+ bnx2_netif_stop(bp);
bp->vlgrp = vlgrp;
+
+ if (!netif_running(dev))
+ return;
+
bnx2_set_rx_mode(dev);
if (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN)
bnx2_fw_sync(bp, BNX2_DRV_MSG_CODE_KEEP_VLAN_UPDATE, 0, 1);
--
1.5.6.GIT
^ permalink raw reply related
* [PATCH -next 1/8] bnx2: Zero out status block before chip reset.
From: Michael Chan @ 2009-08-22 2:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In case IRQs are shared, we will not mistakenly start processing
the ring based on old status block indices.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 756d4b4..e75b6e9 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4858,6 +4858,7 @@ bnx2_init_chip(struct bnx2 *bp)
bnx2_reg_wr_ind(bp, BNX2_RBUF_CONFIG2, BNX2_RBUF_CONFIG2_VAL(mtu));
bnx2_reg_wr_ind(bp, BNX2_RBUF_CONFIG3, BNX2_RBUF_CONFIG3_VAL(mtu));
+ memset(bp->bnx2_napi[0].status_blk.msi, 0, bp->status_stats_size);
for (i = 0; i < BNX2_MAX_MSIX_VEC; i++)
bp->bnx2_napi[i].last_status_idx = 0;
--
1.5.6.GIT
^ permalink raw reply related
* [PATCH -next 5/8] bnx2: Report FTQ discard counter.
From: Michael Chan @ 2009-08-22 2:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1250907650-24672-1-git-send-email-mchan@broadcom.com>
Report this counter to ethtool -S and include it in netstat.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 085c2dd..e025833 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6485,7 +6485,8 @@ bnx2_get_stats(struct net_device *dev)
stats_blk->stat_EtherStatsOverrsizePkts);
net_stats->rx_over_errors =
- (unsigned long) stats_blk->stat_IfInMBUFDiscards;
+ (unsigned long) (stats_blk->stat_IfInFTQDiscards +
+ stats_blk->stat_IfInMBUFDiscards);
net_stats->rx_frame_errors =
(unsigned long) stats_blk->stat_Dot3StatsAlignmentErrors;
@@ -6518,8 +6519,8 @@ bnx2_get_stats(struct net_device *dev)
net_stats->tx_carrier_errors;
net_stats->rx_missed_errors =
- (unsigned long) (stats_blk->stat_IfInMBUFDiscards +
- stats_blk->stat_FwRxDrop);
+ (unsigned long) (stats_blk->stat_IfInFTQDiscards +
+ stats_blk->stat_IfInMBUFDiscards + stats_blk->stat_FwRxDrop);
return net_stats;
}
@@ -7090,11 +7091,9 @@ bnx2_set_tso(struct net_device *dev, u32 data)
return 0;
}
-#define BNX2_NUM_STATS 46
-
static struct {
char string[ETH_GSTRING_LEN];
-} bnx2_stats_str_arr[BNX2_NUM_STATS] = {
+} bnx2_stats_str_arr[] = {
{ "rx_bytes" },
{ "rx_error_bytes" },
{ "tx_bytes" },
@@ -7139,10 +7138,14 @@ static struct {
{ "tx_xoff_frames" },
{ "rx_mac_ctrl_frames" },
{ "rx_filtered_packets" },
+ { "rx_ftq_discards" },
{ "rx_discards" },
{ "rx_fw_discards" },
};
+#define BNX2_NUM_STATS (sizeof(bnx2_stats_str_arr)/\
+ sizeof(bnx2_stats_str_arr[0]))
+
#define STATS_OFFSET32(offset_name) (offsetof(struct statistics_block, offset_name) / 4)
static const unsigned long bnx2_stats_offset_arr[BNX2_NUM_STATS] = {
@@ -7190,6 +7193,7 @@ static const unsigned long bnx2_stats_offset_arr[BNX2_NUM_STATS] = {
STATS_OFFSET32(stat_OutXoffSent),
STATS_OFFSET32(stat_MacControlFramesReceived),
STATS_OFFSET32(stat_IfInFramesL2FilterDiscards),
+ STATS_OFFSET32(stat_IfInFTQDiscards),
STATS_OFFSET32(stat_IfInMBUFDiscards),
STATS_OFFSET32(stat_FwRxDrop),
};
@@ -7202,7 +7206,7 @@ static u8 bnx2_5706_stats_len_arr[BNX2_NUM_STATS] = {
4,0,4,4,4,4,4,4,4,4,
4,4,4,4,4,4,4,4,4,4,
4,4,4,4,4,4,4,4,4,4,
- 4,4,4,4,4,4,
+ 4,4,4,4,4,4,4,
};
static u8 bnx2_5708_stats_len_arr[BNX2_NUM_STATS] = {
@@ -7210,7 +7214,7 @@ static u8 bnx2_5708_stats_len_arr[BNX2_NUM_STATS] = {
4,4,4,4,4,4,4,4,4,4,
4,4,4,4,4,4,4,4,4,4,
4,4,4,4,4,4,4,4,4,4,
- 4,4,4,4,4,4,
+ 4,4,4,4,4,4,4,
};
#define BNX2_NUM_TESTS 6
--
1.5.6.GIT
^ permalink raw reply related
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