* Re: [PATCH 05/05] ipv6: RFC4214 Support (3)
From: Stephen Hemminger @ 2007-11-13 20:53 UTC (permalink / raw)
To: osprey67; +Cc: osprey67, netdev
In-Reply-To: <4734FCEF.3080301@yahoo.com>
On Fri, 09 Nov 2007 16:35:59 -0800
osprey67 <osprey67@yahoo.com> wrote:
> From: Fred L. Templin <fred.l.templin@boeing.com>
>
> This message attaches the combined diffs from
> messages 01/05 through 04/05. This file should be
> suitable for use with the patch utility.
>
> Signed-off-by: Fred L. Templin <fred.l.templin@boeing.com>
>
Isn't increasing the size of struct ip_tunnel_parm
going to cause kernel ABI changes?
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [Resend(2)] [PATCH 01/05] ipv6: RFC4214 Support (4)
From: Stephen Hemminger @ 2007-11-13 21:10 UTC (permalink / raw)
To: Templin, Fred L
Cc: netdev, YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC1A@XCH-NW-7V2.nw.nos.boeing.com>
> +#if defined(CONFIG_IPV6_ISATAP)
> +/* only for IFF_ISATAP interfaces */
> +static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
> +{
> + return ((addr->s6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE));
> +}
> +#endif
> +
No need to make this conditional, unless you want to define an equivalent
inline for !ISATAP that always returns 0.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Alan Cox @ 2007-11-13 21:12 UTC (permalink / raw)
To: Adrian Bunk
Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb,
linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia,
linux-input, bugme-daemon
In-Reply-To: <20071113200028.GJ4250@stusta.de>
> Bug fixing is not about finding someone to blame, it's about getting the
> bug fixed.
Partly - its also about understanding why the bug occurred and making it
not happen again.
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Adrian Bunk @ 2007-11-13 21:20 UTC (permalink / raw)
To: Mark Lord
Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel,
netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input,
bugme-daemon
In-Reply-To: <473A057A.90802@rtr.ca>
On Tue, Nov 13, 2007 at 03:13:46PM -0500, Mark Lord wrote:
> Adrian Bunk wrote:
>> On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote:
> ..
>>> If you've been making significant updates to a driver/subsystem,
>>> and people are reporting that it is now broken for them,
>>
>> What are "significant updates"?
>>
>> Sometimes one person makes one small patch and this patch contains
>> a typo.
> ..
>
> Then that person should double check their changes against
> the problems reported, and re-convince themselves that the
> breakage wasn't from those. Simple.
Simple?
Everything you have in mind with "should double check their changes" is
simply not realistic with dozens of known unfixed regressions within
more than half a million changed or new lines of code written by more
than 800 people - all numbers only counted since 2.6.23.
>...
>>> The reporters can help,
>>> and many may even git-bisect or send patches. But you cannot *expect* or
>>> *insist* upon them doing your job.
>>
>> Bullshit.
>>
>> Bug fixing is not about finding someone to blame, it's about getting the
>> bug fixed.
> ..
>
> It's not about blame, it's about paying attention to breakages in code that a
> person claims to be supporting, and then doing their best to resolve the issues.
Maintainers are just humans with limited time.
You were the one who suggested to "distribute code maintainership",
so you should explain how to find the additional maintainers.
> Again, if one has the time to actively write/modify code such that something breaks,
> then that person should also make time to fix the breakages.
code writer != subsystem maintainer
And git-bisect is the tool that tells you who broke it.
>> The bug reporter is the person who can reproduce the problem, and if it's
>> a regression then bisecting is the natural way of getting nearer at
>> getting it fixed.
> ..
> For the third time, no disagreement here. git-bsect can help in many cases,
> but not in all cases. And it requires a great time commitment from somebody
> who's system used to work and now doesn't work. The person who broke it has
> a fair bit of responsibility there, too.
git-bisect can help only for regressions, and it can help for most
regressions.
And you shouldn't try to make a problem out of something that isn't a
problem:
Bug submitters are either volunteers who test -rc or even -git or -mm
kernels for finding bugs or people who want a problem they experience
fixed.
In both cases the submitters are usually willing to invest some time for
helping to get the bug fixed.
> cheers
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [ofa-general] Re: [PATCH 10/10 REV5] [E1000] Implement batching
From: Kok, Auke @ 2007-11-13 21:28 UTC (permalink / raw)
To: Krishna Kumar
Cc: randy.dunlap, Robert.Olsson, gaagaan, kumarkr,
peter.p.waskiewicz.jr, shemminger, johnpol, herbert, jeff,
rdreier, mcarlson, general, sri, jagana, hadi, mchan, netdev,
davem, tgraf, kaber
In-Reply-To: <20070914090442.17589.23005.sendpatchset@K50wks273871wss.in.ibm.com>
Krishna Kumar wrote:
> E1000: Implement batching capability (ported thanks to changes taken from
> Jamal).
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
this doesn't apply anymore and it would help if you could re-spin this for e1000e.
I don't know what the status for merging of the batched xmit patches is right now
but it would help if you could rewrite them against e1000e, which I assume is what
most people want to test with. There are also significant changes upstream right
now in jgarzik/netdev-2.6 #upstream...
I'm still very interested in these patches BTW.
Auke
> ---
> e1000_main.c | 104 ++++++++++++++++++++++++++++++++++++++++++-----------------
> 1 files changed, 75 insertions(+), 29 deletions(-)
>
> diff -ruNp org/drivers/net/e1000/e1000_main.c new/drivers/net/e1000/e1000_main.c
> --- org/drivers/net/e1000/e1000_main.c 2007-09-14 10:30:57.000000000 +0530
> +++ new/drivers/net/e1000/e1000_main.c 2007-09-14 10:31:02.000000000 +0530
> @@ -990,7 +990,7 @@ e1000_probe(struct pci_dev *pdev,
> if (pci_using_dac)
> netdev->features |= NETIF_F_HIGHDMA;
>
> - netdev->features |= NETIF_F_LLTX;
> + netdev->features |= NETIF_F_LLTX | NETIF_F_BATCH_SKBS;
>
> adapter->en_mng_pt = e1000_enable_mng_pass_thru(&adapter->hw);
>
> @@ -3092,6 +3092,17 @@ e1000_tx_map(struct e1000_adapter *adapt
> return count;
> }
>
> +static void e1000_kick_DMA(struct e1000_adapter *adapter,
> + struct e1000_tx_ring *tx_ring, int i)
> +{
> + wmb();
> +
> + writel(i, adapter->hw.hw_addr + tx_ring->tdt);
> + /* we need this if more than one processor can write to our tail
> + * at a time, it syncronizes IO on IA64/Altix systems */
> + mmiowb();
> +}
> +
> static void
> e1000_tx_queue(struct e1000_adapter *adapter, struct e1000_tx_ring *tx_ring,
> int tx_flags, int count)
> @@ -3138,13 +3149,7 @@ e1000_tx_queue(struct e1000_adapter *ada
> * know there are new descriptors to fetch. (Only
> * applicable for weak-ordered memory model archs,
> * such as IA-64). */
> - wmb();
> -
> tx_ring->next_to_use = i;
> - writel(i, adapter->hw.hw_addr + tx_ring->tdt);
> - /* we need this if more than one processor can write to our tail
> - * at a time, it syncronizes IO on IA64/Altix systems */
> - mmiowb();
> }
>
> /**
> @@ -3251,22 +3256,23 @@ static int e1000_maybe_stop_tx(struct ne
> }
>
> #define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1 )
> +
> +#define NETDEV_TX_DROPPED -5
> +
> static int
> -e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> +e1000_prep_queue_frame(struct sk_buff *skb, struct net_device *netdev)
> {
> struct e1000_adapter *adapter = netdev_priv(netdev);
> struct e1000_tx_ring *tx_ring;
> unsigned int first, max_per_txd = E1000_MAX_DATA_PER_TXD;
> unsigned int max_txd_pwr = E1000_MAX_TXD_PWR;
> unsigned int tx_flags = 0;
> - unsigned int len = skb->len;
> - unsigned long flags;
> - unsigned int nr_frags = 0;
> - unsigned int mss = 0;
> + unsigned int len = skb->len - skb->data_len;
> + unsigned int nr_frags;
> + unsigned int mss;
> int count = 0;
> int tso;
> unsigned int f;
> - len -= skb->data_len;
>
> /* This goes back to the question of how to logically map a tx queue
> * to a flow. Right now, performance is impacted slightly negatively
> @@ -3276,7 +3282,7 @@ e1000_xmit_frame(struct sk_buff *skb, st
>
> if (unlikely(skb->len <= 0)) {
> dev_kfree_skb_any(skb);
> - return NETDEV_TX_OK;
> + return NETDEV_TX_DROPPED;
> }
>
> /* 82571 and newer doesn't need the workaround that limited descriptor
> @@ -3322,7 +3328,7 @@ e1000_xmit_frame(struct sk_buff *skb, st
> DPRINTK(DRV, ERR,
> "__pskb_pull_tail failed.\n");
> dev_kfree_skb_any(skb);
> - return NETDEV_TX_OK;
> + return NETDEV_TX_DROPPED;
> }
> len = skb->len - skb->data_len;
> break;
> @@ -3366,22 +3372,15 @@ e1000_xmit_frame(struct sk_buff *skb, st
> (adapter->hw.mac_type == e1000_82573))
> e1000_transfer_dhcp_info(adapter, skb);
>
> - if (!spin_trylock_irqsave(&tx_ring->tx_lock, flags))
> - /* Collision - tell upper layer to requeue */
> - return NETDEV_TX_LOCKED;
> -
> /* need: count + 2 desc gap to keep tail from touching
> * head, otherwise try next time */
> - if (unlikely(e1000_maybe_stop_tx(netdev, tx_ring, count + 2))) {
> - spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
> + if (unlikely(e1000_maybe_stop_tx(netdev, tx_ring, count + 2)))
> return NETDEV_TX_BUSY;
> - }
>
> if (unlikely(adapter->hw.mac_type == e1000_82547)) {
> if (unlikely(e1000_82547_fifo_workaround(adapter, skb))) {
> netif_stop_queue(netdev);
> mod_timer(&adapter->tx_fifo_stall_timer, jiffies + 1);
> - spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
> return NETDEV_TX_BUSY;
> }
> }
> @@ -3396,8 +3395,7 @@ e1000_xmit_frame(struct sk_buff *skb, st
> tso = e1000_tso(adapter, tx_ring, skb);
> if (tso < 0) {
> dev_kfree_skb_any(skb);
> - spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
> - return NETDEV_TX_OK;
> + return NETDEV_TX_DROPPED;
> }
>
> if (likely(tso)) {
> @@ -3416,13 +3414,61 @@ e1000_xmit_frame(struct sk_buff *skb, st
> e1000_tx_map(adapter, tx_ring, skb, first,
> max_per_txd, nr_frags, mss));
>
> - netdev->trans_start = jiffies;
> + return NETDEV_TX_OK;
> +}
> +
> +static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> +{
> + struct e1000_adapter *adapter = netdev_priv(netdev);
> + struct e1000_tx_ring *tx_ring = adapter->tx_ring;
> + struct sk_buff_head *blist;
> + int ret, skbs_done = 0;
> + unsigned long flags;
> +
> + if (!spin_trylock_irqsave(&tx_ring->tx_lock, flags)) {
> + /* Collision - tell upper layer to requeue */
> + return NETDEV_TX_LOCKED;
> + }
>
> - /* Make sure there is space in the ring for the next send. */
> - e1000_maybe_stop_tx(netdev, tx_ring, MAX_SKB_FRAGS + 2);
> + blist = netdev->skb_blist;
> +
> + if (!skb || (blist && skb_queue_len(blist))) {
> + /*
> + * Either batching xmit call, or single skb case but there are
> + * skbs already in the batch list from previous failure to
> + * xmit - send the earlier skbs first to avoid out of order.
> + */
> + if (skb)
> + __skb_queue_tail(blist, skb);
> + skb = __skb_dequeue(blist);
> + } else {
> + blist = NULL;
> + }
> +
> + do {
> + ret = e1000_prep_queue_frame(skb, netdev);
> + if (likely(ret == NETDEV_TX_OK))
> + skbs_done++;
> + else {
> + if (ret == NETDEV_TX_BUSY) {
> + if (blist)
> + __skb_queue_head(blist, skb);
> + break;
> + }
> + /* skb dropped, not a TX error */
> + ret = NETDEV_TX_OK;
> + }
> + } while (blist && (skb = __skb_dequeue(blist)) != NULL);
> +
> + if (skbs_done) {
> + e1000_kick_DMA(adapter, tx_ring, adapter->tx_ring->next_to_use);
> + netdev->trans_start = jiffies;
> + /* Make sure there is space in the ring for the next send. */
> + e1000_maybe_stop_tx(netdev, tx_ring, MAX_SKB_FRAGS + 2);
> + }
>
> spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
> - return NETDEV_TX_OK;
> + return ret;
> }
>
> /**
> -
> 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: [BUG] New Kernel Bugs
From: Jörn Engel @ 2007-11-13 21:33 UTC (permalink / raw)
To: Mark Lord
Cc: Ingo Molnar, alsa-devel, netdev, linux-pcmcia, linux-kernel,
protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton,
David Miller
In-Reply-To: <473A067F.3090007@rtr.ca>
On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote:
>
> I just find it weird that something can be known broken for several -rc*
> kernels before I happen to install it, discover it's broken on my own
> machine,
> and then I track it down, fix it, and submit the patch, generally all
> within a
> couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL.
>
> And when I receive hostility from the "maintainers" of said code for fixing
> their bugs, well.. that really motivates me to continue reporting new ones..
Given a decent bug report, I agree that having the bug not looked at is
shameful. But what can a developer do if a bug report effectively reads
"there is some bug somewhere in recent kernels"? How can I know that in
this particular case it is my bug that I introduced? It could just as
easily be 50 other people and none of them are eager to debug it unless
they suspect it to be their bug.
This is a common problem and fairly unrelated to linux in general or the
kernel in particular. Who is going to be the sucker that figures out
which developer the bug belongs to? And I have yet to find a project,
commercial or opensource, where volunteers flock to become such a
sucker.
One option is to push this role to the bug reporter. Another is to
strong-arm some developers into this role, by whatever means. A third
would be for $LARGE_COMPANY to hire some people. If you have a better
idea or would volunteer your time, I'd be grateful. Simply blaming one
side, whether bug reporter or a random developer, for not being the
sucker doesn't help anyone.
Jörn
--
Joern's library part 2:
http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html
^ permalink raw reply
* Re: Re : Oops preceded by WARNING: at net/ipv4/tcp_input.c:1571 tcp_remove_reno_sacks()
From: Ilpo Järvinen @ 2007-11-13 21:35 UTC (permalink / raw)
To: Chazarain Guillaume, David Miller; +Cc: Netdev
In-Reply-To: <Pine.LNX.4.64.0711111216170.12719@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1908 bytes --]
On Mon, 12 Nov 2007, Ilpo Järvinen wrote:
> Yeah, it's more likely a miscount somewhere rather than corruption but
> that wasn't obvious from the first mail...
>
> ...but alas, I haven't yet been able to come up with any theory on how
> a miscount could occur....
Cancel that, first idea is presented in this patch (not sure if it's one
that fixes your symptoms, but at least it seems a potential place where
such thing could happen, no idea what events can cause that to occur
though :-():
--
[PATCH] [TCP] FRTO: Plug potential LOST-bit leak
It might be possible that, in some extreme scenario that
I just cannot now construct in my mind, end_seq <=
frto_highmark check does not match causing the lost_out
and LOST bits become out-of-sync due to clearing and
recounting in the loop.
This may fix LOST-bit leak reported by Chazarain Guillaume
<guichaz@yahoo.fr>.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 23a0092..cc358d4 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1706,6 +1706,8 @@ static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
tcp_for_write_queue(skb, sk) {
if (skb == tcp_send_head(sk))
break;
+
+ TCP_SKB_CB(skb)->sacked &= ~TCPCB_LOST;
/*
* Count the retransmission made on RTO correctly (only when
* waiting for the first ACK and did not get it)...
@@ -1719,7 +1721,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
} else {
if (TCP_SKB_CB(skb)->sacked & TCPCB_RETRANS)
tp->undo_marker = 0;
- TCP_SKB_CB(skb)->sacked &= ~(TCPCB_LOST|TCPCB_SACKED_RETRANS);
+ TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS;
}
/* Don't lost mark skbs that were fwd transmitted after RTO */
--
1.5.0.6
^ permalink raw reply related
* Re: [BUG] New Kernel Bugs
From: Andrew Morton @ 2007-11-13 21:56 UTC (permalink / raw)
To: Jörn Engel
Cc: Mark Lord, Ingo Molnar, alsa-devel, netdev, linux-pcmcia,
linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input,
David Miller
In-Reply-To: <20071113213358.GC20167@lazybastard.org>
On Tue, 13 Nov 2007 22:33:58 +0100 Jörn Engel <joern@logfs.org> wrote:
> On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote:
> >
> > I just find it weird that something can be known broken for several -rc*
> > kernels before I happen to install it, discover it's broken on my own
> > machine,
> > and then I track it down, fix it, and submit the patch, generally all
> > within a
> > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL.
> >
> > And when I receive hostility from the "maintainers" of said code for fixing
> > their bugs, well.. that really motivates me to continue reporting new ones..
>
> Given a decent bug report, I agree that having the bug not looked at is
> shameful. But what can a developer do if a bug report effectively reads
> "there is some bug somewhere in recent kernels"? How can I know that in
> this particular case it is my bug that I introduced? It could just as
> easily be 50 other people and none of them are eager to debug it unless
> they suspect it to be their bug.
It's relatively common that a regression in subsystem A will manifest as a
failure in subsystem B, and the report initially lands on the desk of the
subsystem B developers.
But that's OK. The subsystem B people are the ones with the expertise to
be able to work out where the bug resides and to help the subsystem A
people understand what went wrong.
Alas, sometimes the B people will just roll eyes and do nothing because
they know the problem wasn't in their code. Sometimes.
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Frans Pop @ 2007-11-13 22:03 UTC (permalink / raw)
To: Romano Giannetti
Cc: akpm, alsa-devel, bugme-daemon, bunk, cate, davem, liml,
linux-ide, linux-input, linux-kernel, linux-pcmcia, mingo, netdev,
protasnb, ray-lk
In-Reply-To: <1194976238.15745.17.camel@rukbat>
Romano Giannetti wrote:
> This was what I did in my (in the end almost successful) bisecting when
> trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my
> SD card"). This is true in theory, but it has some problem. The "this
> commit does not compile is the easiest and in man git-bisect it's
> explained how to solve it. The changes in .config options, added or
> removed, are another problem when jumping back and forth from version.
>
> The main problem I had, and that stopped me to arrive to a definite is
> this situation:
[...]
> (d was the series to change drivers to use sg helpers, and g was a "fix
> fallout from sg helpers" patch). Now I have a series of kernels (d, e,
> f) that did not work at all and so I cannot mark them good or bad. With
> the number of patches added in the free-for-all week, this is a very
> probable scenario. There is a way out from this using bisect?
I think there are three strategies you can use in this case:
- create a kernel config that is as simple as possible, but still supports
your hardware and reproduces your problem; a simpler config will often
avoid compilation issues in parts of the kernel that you're not using
anyway and has the benefit of speeding up the compiles too
- if you know/suspect in what part of the tree the bug is, first limit the
bisection to that; you will have to verify that you did indeed find the
correct (broken) change by doing a compile for the "last good commit + 1"
- if you find a broken commit, use 'git-reset --hard' to try to jump past
the bad set of commits, but of course that does not help in the case:
g version-bad
f unrelated bug corrected
e
d the broken commit that caused your problem
c
b unrelated bug that breaks compilation or system introduced
a version-good
in that case the best you can reasonably be expected to do is report that
you narrowed it down to "between a and g" and leave the rest to the
developers
Cheers,
FJP
^ permalink raw reply
* [PATCH] [TCP] FRTO: Limit snd_cwnd if TCP was application limited
From: Ilpo Järvinen @ 2007-11-13 22:08 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1313 bytes --]
Otherwise TCP might violate packet ordering principles that FRTO
is based on. If conventional recovery path is chosen, this won't
be significant at all. In practice, any small enough value will
be sufficient to provide proper operation for FRTO, yet other
users of snd_cwnd might benefit from a "close enough" value.
FRTO's formula is now equal to what tcp_enter_cwr() uses.
FRTO used to check application limitedness a bit differently but
I changed that in commit 575ee7140dabe9b9c4f66f4f867039b97e548867
and as a result checking for application limitedness became
completely non-existing.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
Noticed this unrelated problem while thinking LOST bits and stuff...
net/ipv4/tcp_input.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index cc358d4..3f126ec 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1674,6 +1674,9 @@ void tcp_enter_frto(struct sock *sk)
}
tcp_verify_left_out(tp);
+ /* Too bad if TCP was application limited */
+ tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp) + 1);
+
/* Earlier loss recovery underway (see RFC4138; Appendix B).
* The last condition is necessary at least in tp->frto_counter case.
*/
--
1.5.0.6
^ permalink raw reply related
* Re: [BUG] New Kernel Bugs
From: Rafael J. Wysocki @ 2007-11-13 22:09 UTC (permalink / raw)
To: Mark Lord
Cc: Matthew Wilcox, Ingo Molnar, alsa-devel, netdev, linux-pcmcia,
linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input,
Andrew Morton, David Miller
In-Reply-To: <4739F2DD.5050802@rtr.ca>
On Tuesday, 13 of November 2007, Mark Lord wrote:
> Matthew Wilcox wrote:
> > On Tue, Nov 13, 2007 at 01:43:53PM -0500, Mark Lord wrote:
> >
> >> mkdir t
> >> cd t
> >> git clone
> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >> (wait half an hour)
> >> /usr/bin/du -s linux-2.6
> >> 522732 linux-2.6
> >
> > You're assuming that everything in linux-2.6 was downloaded; that's
> > not true. Everything in linux-2.6/.git was downloaded; but then you do a
> > checkout which happens to approximately double the size of the linux-2.6
> > directory.
> ..
>
> Ah, I wondered why it took only half an hour to download.
>
> ..
> > When you compare it to the 60MB tarballs that are published, it's really
> > not that bad.
> ..
>
> The tarballs I download are only 45MB.
You clone the git repo once. Afterwards, you only update it and that usually
doesn't take that much time and a little effort.
Greetings,
Rafael
^ permalink raw reply
* Re: BUG: sky2: hw csum failure with dual-port copper NIC on SMP
From: Stephen Hemminger @ 2007-11-13 22:14 UTC (permalink / raw)
To: Tony Battersby; +Cc: netdev
In-Reply-To: <4739E425.20408@cybernetics.com>
On Tue, 13 Nov 2007 12:51:33 -0500
Tony Battersby <tonyb@cybernetics.com> wrote:
> I am getting "hw csum failure" messages with sky2. I have seen this
> problem reported elsewhere with a fibre NIC, but I am using a copper
> NIC. It seems to be triggered by SMP. It is easy to reproduce in
> 2.6.23. 2.6.24-rc2-git3 still has the problem, but it happens less
> frequently.
>
> To reproduce the problem, I am using a simple network benchmark program
> that I wrote that basically does send()/recv() as fast as possible using
> a memory buffer (null data, no disk I/O, no data integrity checking).
> The computer with the SysKonnect NIC acts as the server. I have two
> other computers with Intel PRO/1000 NICs that are directly cabled to the
> two ports on the SysKonnect NIC. Each of them runs the client program,
> which connects to the server, send()s 10 GB, and then recv()s 10 GB.
> Essentially, both ports on the Syskonnect NIC are receiving at the
> maximum rate for a few minutes, and then transmitting at the maximum
> rate for a few minutes. Sustained throughput is about 117 MB/s on both
> ports simultaneously.
>
> The "hw csum failure" does not seem to affect the test. send()/recv()
> continue to work normally. Nothing locks up.
>
> I get several "hw csum failure" messages per minute on 2.6.23-SMP. The
> error does not happen with 2.6.23 if I boot with "max_cpus=1". The
> message seems less frequent with 2.6.24-SMP, but it still happens once
> every minute or so.
>
> The "hw csum failure" message does not happen when only one port is in
> use. You have to stress both ports simultaneously to reproduce the
> problem.
>
> Another cosmetic issue is that "ifconfig" shows eth2 at IRQ 16 and eth3
> at IRQ 218, when in fact both are at IRQ 218. IRQ 16 is the regular
> interrupt line and IRQ 218 is the MSI interrupt. I imagine that the
> driver is just reporting the IRQ incorrectly in this case. It is just a
> minor cosmetic issue which doesn't break anything.
ifconfig reports value from dev->irq, which is a a legacy thing.
When using MSI it gets it wrong.
I can reproduce the problem under load with only a single port on 2.6.23.
I haven't been able to reproduce it on 2.6.24-rc2 (latest) but that maybe
because of either insufficient stress or another bug fix correcting the
problem. There is an issue with Yukon XL updating the receive status index
before updating the receive status structure, that is now fixed in 2.6.24.
The fix is:
commit ab5adecb2d02f3688719dfb5936a82833fcc3955
Author: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon Nov 5 15:52:09 2007 -0800
sky2: status ring race fix
The D-Link PCI-X board (and maybe others) can lie about status
ring entries. It seems it will update the register for last status
index before completing the DMA for the ring entry. To avoid reading
stale data, zap the old entry and check.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Russell King @ 2007-11-13 22:18 UTC (permalink / raw)
To: Andrew Morton
Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel,
protasnb, linux-ide, bugme-daemon, linux-input
In-Reply-To: <20071113125222.9eb53ac8.akpm@linux-foundation.org>
On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote:
> On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > There's another issue I want to raise concerning bugzilla. We have the
> > classic case of "not enough people reading bugzilla bugs" - which is one
> > of the biggest problems with bugzilla. Virtually no one in the ARM
> > community looks for ARM bugs in bugzilla.
>
> Nor should they.
So what you're saying is...
> > Let's not forget that it would be a waste of time for people to manually
> > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs
> > into bugzilla that a weekly manual check by every maintainer would just
> > return the same old boring results for months and months at a time.
>
> I screen all bugzilla reports. 100% of them.
>
> - I'll try to establish whether it is a regression
>
> - I'll solicit any extra information which I believe the reveloper will need
>
> - I'll ensure that an appropriate developer has seen the report
>
> And yes, the number of arm-specific reports in there is very small.
that just because you do this everyone in a select clique, who you include
me in, should be doing this as well.
No. Thank. You.
> > It would be far more productive if the ARM category was deleted from
> > bugzilla and the few people who use bugzilla reported their bugs on the
> > mailing list. We've a couple of thousand people on the ARM kernel
> > mailing list at the moment - that's 3 orders of magnitude more of eyes
> > than look at bugzilla.
>
> Is that linux-arm-kernel@lists.arm.linux.org.uk?
Yes.
> If so, MANITAINERS claims that it is subscribers-only. That would cause
> some bug reporters to give up and go away.
Find some other mailing list; I'm not hosting *nor* am I willing to run a
non-subscribers only mailing list. Period. Not negotiable, so don't even
try to change my mind.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Mark Lord @ 2007-11-13 22:29 UTC (permalink / raw)
To: Jörn Engel
Cc: Mark Lord, Ingo Molnar, netdev, linux-pcmcia, linux-kernel,
protasnb, linux-ide, bugme-daemon, linux-input, Andrew Morton,
David Miller
In-Reply-To: <20071113213358.GC20167@lazybastard.org>
Jörn Engel wrote:
> On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote:
>> I just find it weird that something can be known broken for several -rc*
>> kernels before I happen to install it, discover it's broken on my own machine,
>> and then I track it down, fix it, and submit the patch, generally all within a
>> couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL.
>>
>> And when I receive hostility from the "maintainers" of said code for fixing
>> their bugs, well.. that really motivates me to continue reporting new ones..
>
> Given a decent bug report, I agree that having the bug not looked at is
> shameful. But what can a developer do if a bug report effectively reads
> "there is some bug somewhere in recent kernels"? How can I know that in
> this particular case it is my bug that I introduced? It could just as
> easily be 50 other people and none of them are eager to debug it unless
> they suspect it to be their bug.
..
Most of the regressions we have are easily identifiable and not of the type
where there could "50 other people" touching the relevant code. As a developer
(and former subsystem maintainer) I look hard at my own code when there's a
bug reported that could have come from recent updates there. Usually there are
not that many updates to consider, and tracking it down is just a matter of
being willing to do so.
Of late, I've given up on other developers fixing the stuff they break on my
own machines, and I generally just dive into totally unfamiliar code, and find
and fix it myself. Quite quickly, usually. And the bugs are often very apparent
just from looking at the source code diffs (patches) from recent history in
the code that's not working. This is not rocket science, and it doesn't require
a log2 download/rebuild/reboot process.
But yes, there are more difficult ones, like when my machine crashed yesterday
with some form of corruption showing up during JBD filesystem I/O. That's one
where the problem isn't going to be obvious to anyone, and I don't actually
expect anyone to go looking for it right away. If more such events happen,
then it will get more attention.
But things like broken drivers, in almost every case those are trivial
to track down and fix, even for people not familar with that specific code.
> This is a common problem and fairly unrelated to linux in general or the
> kernel in particular. Who is going to be the sucker that figures out
> which developer the bug belongs to? And I have yet to find a project,
> commercial or opensource, where volunteers flock to become such a
> sucker.
>
> One option is to push this role to the bug reporter. Another is to
> strong-arm some developers into this role, by whatever means. A third
> would be for $LARGE_COMPANY to hire some people. If you have a better
> idea or would volunteer your time, I'd be grateful. Simply blaming one
> side, whether bug reporter or a random developer, for not being the
> sucker doesn't help anyone.
..
Nobody's blaming anyone here. I'm just asking that developers here do more
like our Top Penguin does, and actually look at problems and try to understand
them and suggest fixes to try. And not rely solely on the git-bisect crutch.
It's a good crutch, provided the reporter is a kernel developer, or has a lot
of time on their hands. But we debugged Linux here for a long time without it.
And I already volunteer my time here, thanks, BIG TIME, since 1992 or so.
Cheers
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Jörn Engel @ 2007-11-13 22:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Jörn Engel, Mark Lord, Ingo Molnar, alsa-devel, netdev,
linux-pcmcia, linux-kernel, protasnb, linux-ide, bugme-daemon,
linux-input, David Miller
In-Reply-To: <20071113135658.5c9ac7ba.akpm@linux-foundation.org>
On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote:
>
> It's relatively common that a regression in subsystem A will manifest as a
> failure in subsystem B, and the report initially lands on the desk of the
> subsystem B developers.
>
> But that's OK. The subsystem B people are the ones with the expertise to
> be able to work out where the bug resides and to help the subsystem A
> people understand what went wrong.
>
> Alas, sometimes the B people will just roll eyes and do nothing because
> they know the problem wasn't in their code. Sometimes.
And sometimes the A people will ignore the B people after the root cause
has been worked out. Do you have a good idea how to shame A into
action? Should I put you on Cc:? Right now I'm in the eye-rolling
phase.
Jörn
--
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Andrew Morton @ 2007-11-13 22:32 UTC (permalink / raw)
To: Russell King
Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel,
protasnb, linux-ide, bugme-daemon, linux-input
In-Reply-To: <20071113221801.GF1356@flint.arm.linux.org.uk>
On Tue, 13 Nov 2007 22:18:01 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote:
> > On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > There's another issue I want to raise concerning bugzilla. We have the
> > > classic case of "not enough people reading bugzilla bugs" - which is one
> > > of the biggest problems with bugzilla. Virtually no one in the ARM
> > > community looks for ARM bugs in bugzilla.
> >
> > Nor should they.
>
> So what you're saying is...
>
> > > Let's not forget that it would be a waste of time for people to manually
> > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs
> > > into bugzilla that a weekly manual check by every maintainer would just
> > > return the same old boring results for months and months at a time.
> >
> > I screen all bugzilla reports. 100% of them.
> >
> > - I'll try to establish whether it is a regression
> >
> > - I'll solicit any extra information which I believe the reveloper will need
> >
> > - I'll ensure that an appropriate developer has seen the report
> >
> > And yes, the number of arm-specific reports in there is very small.
>
> that just because you do this everyone in a select clique, who you include
> me in, should be doing this as well.
>
> No. Thank. You.
No, I don't mean that at all and this was very plainly obviously from my very
clearly written email. Let me try again.
No, no subsystem developer needs to monitor new bugzilla reports. This is
because *I do it for them*. I will actively make them aware of new reports
which I believe are legitimate and which contain sufficient information for
them to be able to take further action.
> > > It would be far more productive if the ARM category was deleted from
> > > bugzilla and the few people who use bugzilla reported their bugs on the
> > > mailing list. We've a couple of thousand people on the ARM kernel
> > > mailing list at the moment - that's 3 orders of magnitude more of eyes
> > > than look at bugzilla.
> >
> > Is that linux-arm-kernel@lists.arm.linux.org.uk?
>
> Yes.
>
> > If so, MANITAINERS claims that it is subscribers-only. That would cause
> > some bug reporters to give up and go away.
>
> Find some other mailing list; I'm not hosting *nor* am I willing to run a
> non-subscribers only mailing list. Period. Not negotiable, so don't even
> try to change my mind.
Making a list subscribers-only will cause some bug reports to be lost.
Tradeoffs are involved, against which decisions must be made. You have
made yours.
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Russell King @ 2007-11-13 22:34 UTC (permalink / raw)
To: Alan Cox
Cc: Thomas Gleixner, Mark Lord, alsa-devel, netdev, linux-pcmcia,
linux-kernel, Natalie Protasevich, linux-ide, bugme-daemon,
linux-input, Andrew Morton
In-Reply-To: <20071113182516.250de873@the-village.bc.nu>
On Tue, Nov 13, 2007 at 06:25:16PM +0000, Alan Cox wrote:
> > Given the wide range of ARM platforms today, it is utterly idiotic to
> > expect a single person to be able to provide responses for all ARM bugs.
> > I for one wish I'd never *VOLUNTEERED* to be a part of the kernel
> > bugzilla, and really *WISH* I could pull out of that function.
>
> You can. Perhaps that bugzilla needs to point to some kind of
> arm-maintainers@vger.kernel.org list for the various ARM platform
> maintainers ?
That might work - though it would be hard to get all the platform
maintainers to be signed up to yet another mailing list, I'm sure
sufficient would do.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Andrew Morton @ 2007-11-13 22:43 UTC (permalink / raw)
To: Jörn Engel
Cc: Mark Lord, Ingo Molnar, alsa-devel, netdev, linux-pcmcia,
linux-kernel, protasnb, linux-ide, bugme-daemon, linux-input,
David Miller
In-Reply-To: <20071113222414.GD20167@lazybastard.org>
On Tue, 13 Nov 2007 23:24:14 +0100 Jörn Engel <joern@logfs.org> wrote:
> On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote:
> >
> > It's relatively common that a regression in subsystem A will manifest as a
> > failure in subsystem B, and the report initially lands on the desk of the
> > subsystem B developers.
> >
> > But that's OK. The subsystem B people are the ones with the expertise to
> > be able to work out where the bug resides and to help the subsystem A
> > people understand what went wrong.
> >
> > Alas, sometimes the B people will just roll eyes and do nothing because
> > they know the problem wasn't in their code. Sometimes.
>
> And sometimes the A people will ignore the B people after the root cause
> has been worked out. Do you have a good idea how to shame A into
> action? Should I put you on Cc:? Right now I'm in the eye-rolling
> phase.
>
Well, that's the problem, isn't it?
The best I can come up with is to suggest that all the info be captured in
a bugzilla report so that at least it doesn't get forgotten about.
I suppose that other options are
a) try to fix it yourself. I'll take the patch and as long as we make a
big enough mess of it, someone who knows what they're doing might fix it
for real.
b) If it was a regression, identify the offending commit and we'll just
revert it.
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Thomas Gleixner @ 2007-11-13 22:46 UTC (permalink / raw)
To: Mark Lord
Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <4739E4E5.2010602@rtr.ca>
On Tue, 13 Nov 2007, Mark Lord wrote:
> Thomas Gleixner wrote:
> > On Tue, 13 Nov 2007, Mark Lord wrote:
> >
> > > > Andrew Morton wrote:
> > > > > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich"
> > > > > > <protasnb@gmail.com> wrote:
> > > > ..
> > > > > > > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23
> > > > > doesn't
> > > > > > > > boot (ARM, Timer)
> > > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9229
> > > > > > > > Kernel: 2.6.23
> > > > > > > > No response from developers
> > > > ..
> >
> > The bug report is bogus. ARM has no CONFIG_HPET_TIMER.
> > > > Note: that same bug exists/existed on i386 back when NO_HZ was
> > > > introduced (2.6.21?). I still see it from time to time on my Quad core
> > > > system (very rare), but not any more on my Duo notebook where it used
> > > > to happen about 1 in n boots (n < 10).
> > > > > AFAICT no fix was ever released for it.
> >
> > Hmm, at which point does the boot stop ?
> ..
>
> Just as it prints out these messages, sometimes one of them,
> sometimes both (or all four on the quad core):
>
> kernel: switched to high resolution mode on cpu 1
> kernel: switched to high resolution mode on cpu 0
It's completely dead afterwards ?
tglx
^ permalink raw reply
* Re: Problems with ULI 526x driver
From: Francois Romieu @ 2007-11-13 22:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: peerchen, netdev
In-Reply-To: <4738A7A4.1030004@freescale.com>
Timur Tabi <timur@freescale.com> :
[...]
> Update: I can ping anything on my subnet, but nothing else. Also, it looks
> like my MAC address is hosed:
[...]
> It turns out that the driver is getting the MAC address from the ID table:
>
> if(((u16 *) db->srom)[0] == 0xffff || ((u16 *) db->srom)[0] == 0) /*
> SROM absent, so read MAC address from ID Table */
> {
>
>
> In my case, the address that is returned is all zeros. I don't know
> anything about the ULI 526x hardware. Is it possible that there's a
> missing EEPROM on my board that's supposed to hold the MAC address? Are
> these registers user-writable?
You previously said that the tulip driver + reverted change works with
your card (TULIP_MMIO was not set, right ?). I guess it did correctly set
the HW address, did it not ?
--
Ueimor
^ permalink raw reply
* Re: BUG: sky2: hw csum failure with dual-port copper NIC on SMP
From: Tony Battersby @ 2007-11-13 22:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071113141414.0959735a@freepuppy.rosehill>
Stephen Hemminger wrote:
> I can reproduce the problem under load with only a single port on 2.6.23.
> I haven't been able to reproduce it on 2.6.24-rc2 (latest) but that maybe
> because of either insufficient stress or another bug fix correcting the
> problem. There is an issue with Yukon XL updating the receive status index
> before updating the receive status structure, that is now fixed in 2.6.24.
> The fix is:
>
> commit ab5adecb2d02f3688719dfb5936a82833fcc3955
> Author: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Mon Nov 5 15:52:09 2007 -0800
>
> sky2: status ring race fix
>
> The D-Link PCI-X board (and maybe others) can lie about status
> ring entries. It seems it will update the register for last status
> index before completing the DMA for the ring entry. To avoid reading
> stale data, zap the old entry and check.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
The kernel I tested (2.6.24-rc2-git3) has this patch in it already.
Perhaps that is why the problem happens less frequently with that
kernel, but it didn't fix it entirely.
Do you want the test program I am using? It is a pretty basic
send()/recv() program, ~650 lines of C.
Tony
^ permalink raw reply
* [PATCH] netdev: create an "is_napi_enabled()" call
From: Linas Vepstas @ 2007-11-13 23:06 UTC (permalink / raw)
To: Jeff Garzik, Andrew Morton; +Cc: NetDev, e1000-devel
In certain rare cases, it can be nice to be able to check
if napi is enabled or not. Create an is_napi_enabled() call.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
-------
Actually, I'm confused about whether I'd mailed this previously.
It might be a duplicate submission.
include/linux/netdevice.h | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: linux-2.6.23-rc8-mm1/include/linux/netdevice.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/include/linux/netdevice.h 2007-11-09 17:36:51.000000000 -0600
+++ linux-2.6.23-rc8-mm1/include/linux/netdevice.h 2007-11-09 17:40:19.000000000 -0600
@@ -384,6 +384,17 @@ static inline void napi_enable(struct na
clear_bit(NAPI_STATE_SCHED, &n->state);
}
+/**
+ * is_napi_enabled - return non-zero if napi enabled
+ * @n: napi context
+ *
+ * Return true if napi is enabled.
+ */
+static inline bool is_napi_enabled(struct napi_struct *n)
+{
+ return !test_bit(NAPI_STATE_SCHED, &n->state);
+}
+
/*
* The DEVICE structure.
* Actually, this whole structure is a big mistake. It mixes I/O
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Russell King @ 2007-11-13 23:09 UTC (permalink / raw)
To: Andrew Morton
Cc: David Miller, alsa-devel, netdev, linux-pcmcia, linux-kernel,
protasnb, linux-ide, bugme-daemon, linux-input
In-Reply-To: <20071113143201.9441c940.akpm@linux-foundation.org>
On Tue, Nov 13, 2007 at 02:32:01PM -0800, Andrew Morton wrote:
> On Tue, 13 Nov 2007 22:18:01 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote:
> > > On Tue, 13 Nov 2007 19:32:19 +0000 Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > > There's another issue I want to raise concerning bugzilla. We have the
> > > > classic case of "not enough people reading bugzilla bugs" - which is one
> > > > of the biggest problems with bugzilla. Virtually no one in the ARM
> > > > community looks for ARM bugs in bugzilla.
> > >
> > > Nor should they.
> >
> > So what you're saying is...
> >
> > > > Let's not forget that it would be a waste of time for people to manually
> > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs
> > > > into bugzilla that a weekly manual check by every maintainer would just
> > > > return the same old boring results for months and months at a time.
> > >
> > > I screen all bugzilla reports. 100% of them.
> > >
> > > - I'll try to establish whether it is a regression
> > >
> > > - I'll solicit any extra information which I believe the reveloper will need
> > >
> > > - I'll ensure that an appropriate developer has seen the report
> > >
> > > And yes, the number of arm-specific reports in there is very small.
> >
> > that just because you do this everyone in a select clique, who you include
> > me in, should be doing this as well.
> >
> > No. Thank. You.
>
> No, I don't mean that at all and this was very plainly obviously from my very
> clearly written email. Let me try again.
If you screen all bugzilla reports then you'll know that bug #9356 arrived
at about 1400 GMT yesterday. It's hardly surprising then that your utterly
crappy responses to Natalie's message (which, incidentally, wasn't copied
to me) sent within 24 hours of that report cause *great* annoyance.
> No, no subsystem developer needs to monitor new bugzilla reports. This is
> because *I do it for them*. I will actively make them aware of new reports
> which I believe are legitimate and which contain sufficient information for
> them to be able to take further action.
On the whole you do an excellent job with feeding the bug reports to
people, and while I recognise that you're only human, things do
occasionally go wrong. For instance, sending clearly marked Samsung
S3C bugs to me rather than Ben Dooks (who's in MAINTAINERS for those
platforms.)
> > > > It would be far more productive if the ARM category was deleted from
> > > > bugzilla and the few people who use bugzilla reported their bugs on the
> > > > mailing list. We've a couple of thousand people on the ARM kernel
> > > > mailing list at the moment - that's 3 orders of magnitude more of eyes
> > > > than look at bugzilla.
> > >
> > > Is that linux-arm-kernel@lists.arm.linux.org.uk?
> >
> > Yes.
> >
> > > If so, MANITAINERS claims that it is subscribers-only. That would cause
> > > some bug reporters to give up and go away.
> >
> > Find some other mailing list; I'm not hosting *nor* am I willing to run a
> > non-subscribers only mailing list. Period. Not negotiable, so don't even
> > try to change my mind.
>
> Making a list subscribers-only will cause some bug reports to be lost.
>
> Tradeoffs are involved, against which decisions must be made. You have
> made yours.
So how are they lost when they're held in a moderation queue and are
either accepted, a useful response given to the original poster, or
are forwarded to someone who can deal with the issue.
I don't think "subscribers only" describes my lists - we don't devnull
stuff just because the poster is not a subscriber.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* [PATCH 2/6] e1000: update netstats traffic counters realtime
From: Auke Kok @ 2007-11-13 23:11 UTC (permalink / raw)
To: davem, jeff; +Cc: netdev, jesse.brandeburg, auke-jan.h.kok
In-Reply-To: <20071113231110.13177.27339.stgit@localhost.localdomain>
formerly e1000/e1000e only updated traffic counters once every
2 seconds with the register values of bytes/packets. With newer
code however in the interrupt and polling code we can real-time
fill in these values in the netstats struct for users to see.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_main.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index d1b88e4..e1ba705 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3652,10 +3652,6 @@ e1000_update_stats(struct e1000_adapter *adapter)
}
/* Fill out the OS statistics structure */
- adapter->net_stats.rx_packets = adapter->stats.gprc;
- adapter->net_stats.tx_packets = adapter->stats.gptc;
- adapter->net_stats.rx_bytes = adapter->stats.gorcl;
- adapter->net_stats.tx_bytes = adapter->stats.gotcl;
adapter->net_stats.multicast = adapter->stats.mprc;
adapter->net_stats.collisions = adapter->stats.colc;
@@ -4034,6 +4030,8 @@ e1000_clean_tx_irq(struct e1000_adapter *adapter,
}
adapter->total_tx_bytes += total_tx_bytes;
adapter->total_tx_packets += total_tx_packets;
+ adapter->net_stats.tx_bytes += total_tx_bytes;
+ adapter->net_stats.tx_packets += total_tx_packets;
return cleaned;
}
@@ -4256,6 +4254,8 @@ next_desc:
adapter->total_rx_packets += total_rx_packets;
adapter->total_rx_bytes += total_rx_bytes;
+ adapter->net_stats.rx_bytes += total_rx_bytes;
+ adapter->net_stats.rx_packets += total_rx_packets;
return cleaned;
}
@@ -4443,6 +4443,8 @@ next_desc:
adapter->total_rx_packets += total_rx_packets;
adapter->total_rx_bytes += total_rx_bytes;
+ adapter->net_stats.rx_bytes += total_rx_bytes;
+ adapter->net_stats.rx_packets += total_rx_packets;
return cleaned;
}
^ permalink raw reply related
* [PATCH 5/6] e1000: Secondary unicast address support
From: Auke Kok @ 2007-11-13 23:11 UTC (permalink / raw)
To: davem, jeff; +Cc: netdev, jesse.brandeburg, auke-jan.h.kok
In-Reply-To: <20071113231110.13177.27339.stgit@localhost.localdomain>
From: Patrick McHardy <kaber@trash.net>
Add support for configuring secondary unicast addresses. Unicast
addresses take precendece over multicast addresses when filling
the exact address filters to avoid going to promiscous mode.
When more unicast addresses are present than filter slots,
unicast filtering is disabled and all slots can be used for
multicast addresses.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_main.c | 47 ++++++++++++++++++++++++++--------------
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index e1ba705..dc4934d 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -126,7 +126,7 @@ static void e1000_clean_tx_ring(struct e1000_adapter *adapter,
struct e1000_tx_ring *tx_ring);
static void e1000_clean_rx_ring(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring);
-static void e1000_set_multi(struct net_device *netdev);
+static void e1000_set_rx_mode(struct net_device *netdev);
static void e1000_update_phy_info(unsigned long data);
static void e1000_watchdog(unsigned long data);
static void e1000_82547_tx_fifo_stall(unsigned long data);
@@ -487,7 +487,7 @@ static void e1000_configure(struct e1000_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int i;
- e1000_set_multi(netdev);
+ e1000_set_rx_mode(netdev);
e1000_restore_vlan(adapter);
e1000_init_manageability(adapter);
@@ -899,7 +899,7 @@ e1000_probe(struct pci_dev *pdev,
netdev->stop = &e1000_close;
netdev->hard_start_xmit = &e1000_xmit_frame;
netdev->get_stats = &e1000_get_stats;
- netdev->set_multicast_list = &e1000_set_multi;
+ netdev->set_rx_mode = &e1000_set_rx_mode;
netdev->set_mac_address = &e1000_set_mac;
netdev->change_mtu = &e1000_change_mtu;
netdev->do_ioctl = &e1000_ioctl;
@@ -2382,21 +2382,22 @@ e1000_set_mac(struct net_device *netdev, void *p)
}
/**
- * e1000_set_multi - Multicast and Promiscuous mode set
+ * e1000_set_rx_mode - Secondary Unicast, Multicast and Promiscuous mode set
* @netdev: network interface device structure
*
- * The set_multi entry point is called whenever the multicast address
- * list or the network interface flags are updated. This routine is
- * responsible for configuring the hardware for proper multicast,
+ * The set_rx_mode entry point is called whenever the unicast or multicast
+ * address lists or the network interface flags are updated. This routine is
+ * responsible for configuring the hardware for proper unicast, multicast,
* promiscuous mode, and all-multi behavior.
**/
static void
-e1000_set_multi(struct net_device *netdev)
+e1000_set_rx_mode(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
- struct dev_mc_list *mc_ptr;
+ struct dev_addr_list *uc_ptr;
+ struct dev_addr_list *mc_ptr;
uint32_t rctl;
uint32_t hash_value;
int i, rar_entries = E1000_RAR_ENTRIES;
@@ -2419,9 +2420,16 @@ e1000_set_multi(struct net_device *netdev)
rctl |= (E1000_RCTL_UPE | E1000_RCTL_MPE);
} else if (netdev->flags & IFF_ALLMULTI) {
rctl |= E1000_RCTL_MPE;
- rctl &= ~E1000_RCTL_UPE;
} else {
- rctl &= ~(E1000_RCTL_UPE | E1000_RCTL_MPE);
+ rctl &= ~E1000_RCTL_MPE;
+ }
+
+ uc_ptr = NULL;
+ if (netdev->uc_count > rar_entries - 1) {
+ rctl |= E1000_RCTL_UPE;
+ } else if (!(netdev->flags & IFF_PROMISC)) {
+ rctl &= ~E1000_RCTL_UPE;
+ uc_ptr = netdev->uc_list;
}
E1000_WRITE_REG(hw, RCTL, rctl);
@@ -2431,7 +2439,10 @@ e1000_set_multi(struct net_device *netdev)
if (hw->mac_type == e1000_82542_rev2_0)
e1000_enter_82542_rst(adapter);
- /* load the first 14 multicast address into the exact filters 1-14
+ /* load the first 14 addresses into the exact filters 1-14. Unicast
+ * addresses take precedence to avoid disabling unicast filtering
+ * when possible.
+ *
* RAR 0 is used for the station MAC adddress
* if there are not 14 addresses, go ahead and clear the filters
* -- with 82571 controllers only 0-13 entries are filled here
@@ -2439,8 +2450,11 @@ e1000_set_multi(struct net_device *netdev)
mc_ptr = netdev->mc_list;
for (i = 1; i < rar_entries; i++) {
- if (mc_ptr) {
- e1000_rar_set(hw, mc_ptr->dmi_addr, i);
+ if (uc_ptr) {
+ e1000_rar_set(hw, uc_ptr->da_addr, i);
+ uc_ptr = uc_ptr->next;
+ } else if (mc_ptr) {
+ e1000_rar_set(hw, mc_ptr->da_addr, i);
mc_ptr = mc_ptr->next;
} else {
E1000_WRITE_REG_ARRAY(hw, RA, i << 1, 0);
@@ -2449,6 +2463,7 @@ e1000_set_multi(struct net_device *netdev)
E1000_WRITE_FLUSH(hw);
}
}
+ WARN_ON(uc_ptr != NULL);
/* clear the old settings from the multicast hash table */
@@ -2460,7 +2475,7 @@ e1000_set_multi(struct net_device *netdev)
/* load any remaining addresses into the hash table */
for (; mc_ptr; mc_ptr = mc_ptr->next) {
- hash_value = e1000_hash_mc_addr(hw, mc_ptr->dmi_addr);
+ hash_value = e1000_hash_mc_addr(hw, mc_ptr->da_addr);
e1000_mta_set(hw, hash_value);
}
@@ -5079,7 +5094,7 @@ e1000_suspend(struct pci_dev *pdev, pm_message_t state)
if (wufc) {
e1000_setup_rctl(adapter);
- e1000_set_multi(netdev);
+ e1000_set_rx_mode(netdev);
/* turn on all-multi mode if wake on multicast is enabled */
if (wufc & E1000_WUFC_MC) {
^ 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