* [RFC PATCH] [XFRM]: Fix ordering issue in xfrm_dst_hash_transfer().
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-02-15 2:24 UTC (permalink / raw)
To: davem; +Cc: herbert, sdecugis, kazunori, yoshfuji, netdev
Keep ordering of policy entries with same selector in xfrm_dst_hash_transfer().
Issue should not appear in usual cases because multiple policy entries with
same selector are basically not allowed so far.
Bug was pointed out by Sebastien Decugis <sdecugis@hongo.wide.ad.jp>.
We could convert bydst from hlist to list and use list_add_tail() instead.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
----
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 47219f9..9fc4c31 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -331,15 +331,31 @@ static void xfrm_dst_hash_transfer(struct hlist_head *list,
struct hlist_head *ndsttable,
unsigned int nhashmask)
{
- struct hlist_node *entry, *tmp;
+ struct hlist_node *entry, *tmp, *entry0 = NULL;
struct xfrm_policy *pol;
+ unsigned int h0 = 0;
+redo:
hlist_for_each_entry_safe(pol, entry, tmp, list, bydst) {
unsigned int h;
h = __addr_hash(&pol->selector.daddr, &pol->selector.saddr,
pol->family, nhashmask);
- hlist_add_head(&pol->bydst, ndsttable+h);
+ if (!entry0) {
+ hlist_del(entry);
+ hlist_add_head(&pol->bydst, ndsttable+h);
+ h0 = h;
+ } else {
+ if (h != h0)
+ continue;
+ hlist_del(entry);
+ hlist_add_after(entry0, &pol->bydst);
+ }
+ entry0 = entry;
+ }
+ if (!hlist_empty(list)) {
+ entry0 = NULL;
+ goto redo;
}
}
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: [IPV6]: Fix IPsec datagram fragmentation
From: Herbert Xu @ 2008-02-15 1:55 UTC (permalink / raw)
To: David Miller; +Cc: yoshfuji, netdev, dlstevens, kazunori
In-Reply-To: <20080212.180828.262893392.davem@davemloft.net>
On Tue, Feb 12, 2008 at 06:08:28PM -0800, David Miller wrote:
>
> > [IPV6]: Fix IPsec datagram fragmentation
>
> Applied, and I'll queue this up to -stable as well.
Sorry, David Stevens just told me that it doesn't work as intended.
[IPV6]: Fix reversed local_df test in ip6_fragment
I managed to reverse the local_df test when forward-porting this
patch so it actually makes things worse by never fragmenting at
all.
Thanks to David Stevens for testing and reporting this bug.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 4e9a2fe..35ba693 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -621,7 +621,7 @@ static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
* or if the skb it not generated by a local socket. (This last
* check should be redundant, but it's free.)
*/
- if (skb->local_df) {
+ if (!skb->local_df) {
skb->dev = skb->dst->dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev);
IP6_INC_STATS(ip6_dst_idev(skb->dst), IPSTATS_MIB_FRAGFAILS);
^ permalink raw reply related
* tbench regression in 2.6.25-rc1
From: Zhang, Yanmin @ 2008-02-15 1:52 UTC (permalink / raw)
To: herbert; +Cc: LKML, netdev
Comparing with kernel 2.6.24, tbench result has regression with
2.6.25-rc1.
1) On 2 quad-core processor stoakley: 4%.
2) On 4 quad-core processor tigerton: more than 30%.
bisect located below patch.
b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b is first bad commit
commit b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue Nov 13 21:33:32 2007 -0800
[IPV6]: Move nfheader_len into rt6_info
The dst member nfheader_len is only used by IPv6. It's also currently
creating a rather ugly alignment hole in struct dst. Therefore this patch
moves it from there into struct rt6_info.
As tbench uses ipv4, so the patch's real impact on ipv4 is it deletes
nfheader_len in dst_entry. It might change cache line alignment.
To verify my finding, I just added nfheader_len back to dst_entry in 2.6.25-rc1
and reran tbench on the 2 machines. Performance could be recovered completely.
I started cpu_number*2 tbench processes. On my 16-core tigerton:
#./tbench_srv &
#./tbench 32 127.0.0.1
-yanmin
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Michael Chan @ 2008-02-15 0:03 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Andrew Morton, Matt Carlson, bugme-daemon, netdev,
ralf.hildebrandt
In-Reply-To: <20080214232103.GM856@gospo.usersys.redhat.com>
On Thu, 2008-02-14 at 18:21 -0500, Andy Gospodarek wrote:
> On Thu, Feb 14, 2008 at 02:48:09PM -0800, Michael Chan wrote:
> > Andy, I think you still missed my point. I don't believe this problem
> > was caused by the bridge or the chipset at all. Some corruption caused
> > us to not find the SKB in the TX ring where it was expected. So the
> > driver assumed it was the bridge re-ordering I/O and printed that
> > warning message and took recovery action. The recovery action had no
> > effect in this case since apparently it was caused by something else and
> > the corruption happened again later. This 2nd time, we hit the BUG_ON()
> > seeing that the recovery action did not work.
> >
> >
>
> Ah, I see. Due to at leat a 2 second delay between the message and the
> panic, I figured it would be good data to gather....
>
>
>
Yeah, 2 seconds for the link to come up after chip reset to recover. It
then panicked sometime later and rebooted about 90 seconds after the
initial warning message.
It was also running at the slower 100Mbps link speed. Tx packets stay
longer in the TX ring at this slower speed, increasing the window of
time that the nr_frags in the SKB can be corrupted.
Ralf, please try the debug patch that I sent out earlier. Thanks.
^ permalink raw reply
* [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: Martin Devera @ 2008-02-14 23:02 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, kaber, netdev
From: Martin Devera <devik@cdi.cz>
HTB is event driven algorithm and part of its work is to apply
scheduled events at proper times. It tried to defend itself from
livelock by processing only limited number of events per dequeue.
Because of faster computers some users already hit this hardcoded
limit.
This patch uses loops_per_jiffy variable to limit event processing
up to single jiffy interval and then delay remainder to other
jiffy.
Signed-off-by: Martin Devera <devik@cdi.cz>
---
BTW, from my measurement is seems that value 500 was good one
for my first 600MHz machine :-)
Maybe I can make something self-converging (using tasklets probably)
but I'm not sure if it is worth of the complexity.
--- a/net/sched/sch_htb.c 2008-02-14 22:56:48.000000000 +0100
+++ b/net/sched/sch_htb.c 2008-02-14 23:37:02.000000000 +0100
@@ -704,13 +704,17 @@ static void htb_charge_class(struct htb_
*
* Scans event queue for pending events and applies them. Returns time of
* next pending event (0 for no event in pq).
+ * One event costs about 1300 cycles on x86_64, let's be conservative
+ * and round it to 4096. We will allow only loops_per_jiffy/4096 events
+ * in one call to prevent us from livelock.
* Note: Applied are events whose have cl->pq_key <= q->now.
*/
+#define HTB_EVENT_COST_SHIFTS 12
static psched_time_t htb_do_events(struct htb_sched *q, int level)
{
- int i;
-
- for (i = 0; i < 500; i++) {
+ int i, max_events = loops_per_jiffy >> HTB_EVENT_COST_SHIFTS;
+ /* <= below is just for case where max_events==0 (unlikely) */
+ for (i = 0; i <= max_events; i++) {
struct htb_class *cl;
long diff;
struct rb_node *p = rb_first(&q->wait_pq[level]);
@@ -728,9 +732,8 @@ static psched_time_t htb_do_events(struc
if (cl->cmode != HTB_CAN_SEND)
htb_add_to_wait_tree(q, cl, diff);
}
- if (net_ratelimit())
- printk(KERN_WARNING "htb: too many events !\n");
- return q->now + PSCHED_TICKS_PER_SEC / 10;
+ /* too much load - let's continue on next tick */
+ return q->now + PSCHED_TICKS_PER_SEC / HZ;
}
/* Returns class->node+prio from id-tree where classe's id is >= id. NULL
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Andy Gospodarek @ 2008-02-14 23:21 UTC (permalink / raw)
To: Michael Chan
Cc: Andrew Morton, Matt Carlson, bugme-daemon, netdev,
ralf.hildebrandt
In-Reply-To: <1203029289.13495.38.camel@dell>
On Thu, Feb 14, 2008 at 02:48:09PM -0800, Michael Chan wrote:
> On Thu, 2008-02-14 at 17:12 -0500, Andy Gospodarek wrote:
> > On Thu, Feb 14, 2008 at 01:25:27PM -0800, Michael Chan wrote:
> > > On Thu, 2008-02-14 at 13:56 -0500, Andy Gospodarek wrote:
> > > > That should be a simple matter of adding the right pci-ids to
> > > > tg3_get_invariants -- hopefully Ralf will respond and we can get that
> > > > knocked out quickly.
> > > >
> > > >
> > >
> > > It doesn't look like it was re-ordered IO. If it was, it should have
> > > self-recovered without hitting the BUG().
> > >
> >
> > Good catch, Michael! I missed that it paniced since I expect to see
> > some sort of backtrace when that happens. We should try and get that
> > bridge added to the list though, to avoid repeated complaints that there
> > is a tg3 bug.
> >
> >
>
> Andy, I think you still missed my point. I don't believe this problem
> was caused by the bridge or the chipset at all. Some corruption caused
> us to not find the SKB in the TX ring where it was expected. So the
> driver assumed it was the bridge re-ordering I/O and printed that
> warning message and took recovery action. The recovery action had no
> effect in this case since apparently it was caused by something else and
> the corruption happened again later. This 2nd time, we hit the BUG_ON()
> seeing that the recovery action did not work.
>
>
Ah, I see. Due to at leat a 2 second delay between the message and the
panic, I figured it would be good data to gather....
^ permalink raw reply
* Re: [PATCH][KEY] fix bug in spdadd
From: David Miller @ 2008-02-14 22:53 UTC (permalink / raw)
To: yoshfuji; +Cc: kazunori, netdev
In-Reply-To: <20080215.015405.121725938.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Fri, 15 Feb 2008 01:54:05 +1100 (EST)
> [PATCH] [XFRM]: Avoid bogus BUG() when throwing new policy away.
>
> When we destory a new policy entry, we need to tell
> xfrm_policy_destroy() explicitly that the entry is not
> alive yet.
Applied.
Please provide a proper Signed-off-by: next time.
Thank you!
^ permalink raw reply
* Re: [PATCH][KEY] fix bug in spdadd
From: David Miller @ 2008-02-14 22:51 UTC (permalink / raw)
To: kazunori; +Cc: netdev
In-Reply-To: <47B42C3C.5090104@miyazawa.org>
From: Kazunori MIYAZAWA <kazunori@miyazawa.org>
Date: Thu, 14 Feb 2008 20:55:40 +0900
> This patch fix a BUG when adding spds which have
> same selector.
>
> Signed-off-by: Kazunori MIYAZAWA <kazunori@miyazawa.org>
Applied, thanks!
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Michael Chan @ 2008-02-14 22:48 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Andrew Morton, Matt Carlson, bugme-daemon, netdev,
ralf.hildebrandt
In-Reply-To: <20080214221234.GL856@gospo.usersys.redhat.com>
On Thu, 2008-02-14 at 17:12 -0500, Andy Gospodarek wrote:
> On Thu, Feb 14, 2008 at 01:25:27PM -0800, Michael Chan wrote:
> > On Thu, 2008-02-14 at 13:56 -0500, Andy Gospodarek wrote:
> > > That should be a simple matter of adding the right pci-ids to
> > > tg3_get_invariants -- hopefully Ralf will respond and we can get that
> > > knocked out quickly.
> > >
> > >
> >
> > It doesn't look like it was re-ordered IO. If it was, it should have
> > self-recovered without hitting the BUG().
> >
>
> Good catch, Michael! I missed that it paniced since I expect to see
> some sort of backtrace when that happens. We should try and get that
> bridge added to the list though, to avoid repeated complaints that there
> is a tg3 bug.
>
>
Andy, I think you still missed my point. I don't believe this problem
was caused by the bridge or the chipset at all. Some corruption caused
us to not find the SKB in the TX ring where it was expected. So the
driver assumed it was the bridge re-ordering I/O and printed that
warning message and took recovery action. The recovery action had no
effect in this case since apparently it was caused by something else and
the corruption happened again later. This 2nd time, we hit the BUG_ON()
seeing that the recovery action did not work.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Andy Gospodarek @ 2008-02-14 22:12 UTC (permalink / raw)
To: Michael Chan
Cc: Andy Gospodarek, Andrew Morton, Matt Carlson, bugme-daemon,
netdev, ralf.hildebrandt
In-Reply-To: <1203024327.13495.21.camel@dell>
On Thu, Feb 14, 2008 at 01:25:27PM -0800, Michael Chan wrote:
> On Thu, 2008-02-14 at 13:56 -0500, Andy Gospodarek wrote:
> > On Thu, Feb 14, 2008 at 10:24:25AM -0800, Andrew Morton wrote:
> > > On Thu, 14 Feb 2008 01:59:12 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> > >
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=9990
> > > >
> > > > Summary: tg3: eth0: The system may be re-ordering memory-mapped
> > > > I/O cycles
> > > > Product: Drivers
> > > > Version: 2.5
> > > > KernelVersion: 2.6.24-git18
> > > > Platform: All
> > > > OS/Version: Linux
> > > > Tree: Mainline
> > > > Status: NEW
> > > > Severity: normal
> > > > Priority: P1
> > > > Component: Network
> > > > AssignedTo: jgarzik@pobox.com
> > > > ReportedBy: ralf.hildebrandt@charite.de
> > > >
> > > >
> >
> > That should be a simple matter of adding the right pci-ids to
> > tg3_get_invariants -- hopefully Ralf will respond and we can get that
> > knocked out quickly.
> >
> >
>
> It doesn't look like it was re-ordered IO. If it was, it should have
> self-recovered without hitting the BUG().
>
Good catch, Michael! I missed that it paniced since I expect to see
some sort of backtrace when that happens. We should try and get that
bridge added to the list though, to avoid repeated complaints that there
is a tg3 bug.
^ permalink raw reply
* Re: [PATCH] plusb.c patched to support Belkin F5U258 USB host-to-host cable
From: tony_gibbs @ 2008-02-14 21:55 UTC (permalink / raw)
To: David Brownell; +Cc: tony_gibbs, Linux USB mailing list, NETDEV mailing list
Dear Dave,
Thanks for the reply.
I don't know why it arrived line-wrapped, and I thought I had turned DEBUG
off. So I need to try again on those.
What device name should be there? Just "PL-25A1"? or "Belkin F5U258"?
Yes I did get it to pass data back and forth, and I posted a message to
linux-usb list on Mon, 11 Feb 2008 15:34:34 -0800 showing the results.
So it is working ok, but I need to format the patch so that it will merge
in.
Thoughts?
Kind Regards,
Tony
Message text written by David Brownell
>
On Thursday 14 February 2008, tony_gibbs wrote:
> I have tried to make the changes I have been working on and testing with
> your help into a patch as attached.
>
> Please let me know what you think of it.
It arrived line wrapped, and turned on debug options that
should stay off by default ... it couldn't merge, on those
bases alone. Also, "PL-25A1hack" isn't a product name. ;)
Did you get this to pass data back and forth yet? The last
report I had from you was that it wouldn't pass data. The
Prolific hardware tends to enter that mode after a while.
(Maybe there's documentation unseen by any Linux developer,
saying how to make those chips actually work...) But you
reported that they didn't seem to work even when freshly
plugged in.
- Dave
<
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Michael Chan @ 2008-02-14 21:25 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Andrew Morton, Matt Carlson, bugme-daemon, netdev,
ralf.hildebrandt
In-Reply-To: <20080214185627.GK856@gospo.usersys.redhat.com>
On Thu, 2008-02-14 at 13:56 -0500, Andy Gospodarek wrote:
> On Thu, Feb 14, 2008 at 10:24:25AM -0800, Andrew Morton wrote:
> > On Thu, 14 Feb 2008 01:59:12 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9990
> > >
> > > Summary: tg3: eth0: The system may be re-ordering memory-mapped
> > > I/O cycles
> > > Product: Drivers
> > > Version: 2.5
> > > KernelVersion: 2.6.24-git18
> > > Platform: All
> > > OS/Version: Linux
> > > Tree: Mainline
> > > Status: NEW
> > > Severity: normal
> > > Priority: P1
> > > Component: Network
> > > AssignedTo: jgarzik@pobox.com
> > > ReportedBy: ralf.hildebrandt@charite.de
> > >
> > >
>
> That should be a simple matter of adding the right pci-ids to
> tg3_get_invariants -- hopefully Ralf will respond and we can get that
> knocked out quickly.
>
>
It doesn't look like it was re-ordered IO. If it was, it should have
self-recovered without hitting the BUG().
One possibility is that the nr_frags in the SKB got corrupted before the
TX SKB was freed. The driver relies on the nr_frags in the SKB to find
the packet boundaries in the TX ring. If it cannot find the packet
boundaries, it will exhibit the same symptom as re-ordered IO, only that
it cannot be self-recovered.
Ralf, please try this debug patch with the same traffic condition you
ran before. This patch stores the nr_frags when transmitting an SKB.
During tx completion, it will compare the stored nr_frags with the one
in the SKB and will print out something in dmesg if they don't match.
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index db606b6..73f1ddd 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3324,12 +3324,20 @@ static void tg3_tx(struct tg3 *tp)
struct tx_ring_info *ri = &tp->tx_buffers[sw_idx];
struct sk_buff *skb = ri->skb;
int i, tx_bug = 0;
+ unsigned short nr_frags = ri->nr_frags;
if (unlikely(skb == NULL)) {
tg3_tx_recover(tp);
return;
}
+ if (nr_frags != skb_shinfo(skb)->nr_frags) {
+ printk(KERN_ALERT "tg3: %s: Tx skb->nr_frags corrupted "
+ "before skb is freed. Expected nr_frags %d, "
+ "corrupted nr_frags %d\n", tp->dev->name,
+ nr_frags, skb_shinfo(skb)->nr_frags);
+ }
+
pci_unmap_single(tp->pdev,
pci_unmap_addr(ri, mapping),
skb_headlen(skb),
@@ -3339,7 +3347,7 @@ static void tg3_tx(struct tg3 *tp)
sw_idx = NEXT_TX(sw_idx);
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ for (i = 0; i < nr_frags; i++) {
ri = &tp->tx_buffers[sw_idx];
if (unlikely(ri->skb != NULL || sw_idx == hw_idx))
tx_bug = 1;
@@ -4105,6 +4113,7 @@ static int tigon3_dma_hwbug_workaround(struct tg3 *tp, struct sk_buff *skb,
len, PCI_DMA_TODEVICE);
if (i == 0) {
tp->tx_buffers[entry].skb = new_skb;
+ tp->tx_buffers[entry].nr_frags = 0;
pci_unmap_addr_set(&tp->tx_buffers[entry], mapping, new_addr);
} else {
tp->tx_buffers[entry].skb = NULL;
@@ -4211,6 +4220,7 @@ static int tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
tp->tx_buffers[entry].skb = skb;
+ tp->tx_buffers[entry].nr_frags = skb_shinfo(skb)->nr_frags;
pci_unmap_addr_set(&tp->tx_buffers[entry], mapping, mapping);
tg3_set_txd(tp, entry, mapping, len, base_flags,
@@ -4388,6 +4398,7 @@ static int tg3_start_xmit_dma_bug(struct sk_buff *skb, struct net_device *dev)
mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
tp->tx_buffers[entry].skb = skb;
+ tp->tx_buffers[entry].nr_frags = skb_shinfo(skb)->nr_frags;
pci_unmap_addr_set(&tp->tx_buffers[entry], mapping, mapping);
would_hit_hwbug = 0;
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 3938eb3..d4a3aca 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2098,6 +2098,7 @@ struct tx_ring_info {
struct sk_buff *skb;
DECLARE_PCI_UNMAP_ADDR(mapping)
u32 prev_vlan_tag;
+ unsigned short nr_frags;
};
struct tg3_config_info {
^ permalink raw reply related
* Re: [PATCH] plusb.c patched to support Belkin F5U258 USB host-to-host cable
From: David Brownell @ 2008-02-14 21:20 UTC (permalink / raw)
To: tony_gibbs; +Cc: NETDEV mailing list, Linux USB mailing list
In-Reply-To: <200802141557_MC3-1-FBB3-3DA7@compuserve.com>
On Thursday 14 February 2008, tony_gibbs wrote:
> I have tried to make the changes I have been working on and testing with
> your help into a patch as attached.
>
> Please let me know what you think of it.
It arrived line wrapped, and turned on debug options that
should stay off by default ... it couldn't merge, on those
bases alone. Also, "PL-25A1hack" isn't a product name. ;)
Did you get this to pass data back and forth yet? The last
report I had from you was that it wouldn't pass data. The
Prolific hardware tends to enter that mode after a while.
(Maybe there's documentation unseen by any Linux developer,
saying how to make those chips actually work...) But you
reported that they didn't seem to work even when freshly
plugged in.
- Dave
^ permalink raw reply
* Re: [RFC, PATCH]: Pass link level header from/to PPP interface
From: Urs Thuermann @ 2008-02-14 19:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080213.145355.57741113.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> Can tcpdump and libpcap already handle PPP properly?
Yes, with the (admittedly non-serious) limitation, that both, tcpdump
and tcpdump -e don't show the PPP header. I don't remember how
tcpdump behaved on BSD in this respect (so many years ago), but I
think libpcap will use the DLT_PPP link type on BSD, which has the PPP
header.
urs
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Andy Gospodarek @ 2008-02-14 18:56 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Carlson, Michael Chan, bugme-daemon, netdev,
ralf.hildebrandt
In-Reply-To: <20080214102425.0fc8e3c1.akpm@linux-foundation.org>
On Thu, Feb 14, 2008 at 10:24:25AM -0800, Andrew Morton wrote:
> On Thu, 14 Feb 2008 01:59:12 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=9990
> >
> > Summary: tg3: eth0: The system may be re-ordering memory-mapped
> > I/O cycles
> > Product: Drivers
> > Version: 2.5
> > KernelVersion: 2.6.24-git18
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Network
> > AssignedTo: jgarzik@pobox.com
> > ReportedBy: ralf.hildebrandt@charite.de
> >
> >
> > Latest working kernel version: 2.6.24
> > Earliest failing kernel version: 2.6.24-git18
> > Distribution: Debian/testing
> > Hardware Environment:
> > Software Environment:
> > Problem Description:
> >
> > Feb 11 13:11:52 www kernel: [ 12.015569] tg3: eth0: Link is up at 100 Mbps,
> > full duplex.
> > Feb 11 13:11:52 www kernel: [ 12.015633] tg3: eth0: Flow control is on for TX
> > and on for RX.
> > Feb 11 13:33:44 www kernel: [ 1328.538204] tg3: eth0: The system may be
> > re-ordering memory-mapped I/O cycles to the network
> > device, attempting to recover. Please report the problem to the driver
> > maintainer and include system chipset information.
> > Feb 11 13:33:44 www kernel: [ 1328.667255] tg3: eth0: Link is down.
> > Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Link is up at 100 Mbps,
> > full duplex.
> > Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Flow control is on for TX
> > and on for RX.
> >
> > After that, the machine rebooted (panic?)
> >
> > Feb 11 13:35:14 www kernel: klogd 1.5.0#1.1, log source = /proc/kmsg started.
> >
> > lspci -vvv info:
> > 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> > Ethernet (rev 10)
> > Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> > (PCI-X, 10,100,1000-T)
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> > Stepping- SERR+ FastB2B- DisINTx-
> > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> > Interrupt: pin A routed to IRQ 19
> > Region 0: Memory at fdf70000 (64-bit, non-prefetchable) [size=64K]
> > [virtual] Expansion ROM at 88140000 [disabled] [size=64K]
> > Capabilities: [40] PCI-X non-bridge device
> > Command: DPERE- ERO- RBC=2048 OST=1
> > Status: Dev=02:02.0 64bit+ 133MHz+ SCD- USC- DC=simple
> > DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> > Capabilities: [48] Power Management version 2
> > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> > PME(D0-,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 PME-Enable+ DSel=0 DScale=1 PME-
> > Capabilities: [50] Vital Product Data <?>
> > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> > Enable-
> > Address: fd7ffd6fdf7deeb8 Data: bdfd
> > Kernel driver in use: tg3
> > Kernel modules: tg3
> >
> > 02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> > Ethernet (rev 10)
> > Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> > (PCI-X, 10,100,1000-T)
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> > Stepping- SERR+ FastB2B- DisINTx-
> > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> > Interrupt: pin B routed to IRQ 20
> > Region 0: Memory at fdf60000 (64-bit, non-prefetchable) [size=64K]
> > Capabilities: [40] PCI-X non-bridge device
> > Command: DPERE- ERO+ RBC=512 OST=1
> > Status: Dev=02:02.1 64bit+ 133MHz+ SCD- USC- DC=simple
> > DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> > Capabilities: [48] Power Management version 2
> > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> > PME(D0-,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> > Capabilities: [50] Vital Product Data <?>
> > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> > Enable-
> > Address: f73feeefffffe7f8 Data: 9bcd
> > Kernel driver in use: tg3
> > Kernel modules: tg3
> >
> >
> > Steps to reproduce:
> >
> >
That should be a simple matter of adding the right pci-ids to
tg3_get_invariants -- hopefully Ralf will respond and we can get that
knocked out quickly.
^ permalink raw reply
* Re: [PATCH 2/2] add rcu_assign_index() if ever needed
From: Paul E. McKenney @ 2008-02-14 18:48 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, shemminger, davem, netdev, dipankar, ego, herbert,
akpm
In-Reply-To: <20080214092427.960d1f67.randy.dunlap@oracle.com>
On Thu, Feb 14, 2008 at 09:24:27AM -0800, Randy Dunlap wrote:
> On Wed, 13 Feb 2008 14:05:15 -0800 Paul E. McKenney wrote:
>
> > Hello again!
> >
> > This is a speculative patch that as far as I can tell is not yet required.
> > If anyone applies RCU to a data structure allocated out of an array, using
> > array indexes in place of pointers to link the array elements together,
> > then the rcu_assign_index() function in this patch will be needed to
> > assign a given element's array index to the RCU-traversed index. The
> > implementation is exactly that of the old rcu_assign_pointer(), so is
> > extremely well tested.
> >
> > The existing rcu_assign_pointer() will emit a compiler warning in cases
> > where rcu_assign_index() is required.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> >
> > rcupdate.h | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff -urpNa -X dontdiff linux-2.6.24-rap/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
> > --- linux-2.6.24-rap/include/linux/rcupdate.h 2008-02-13 13:36:47.000000000 -0800
> > +++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-13 10:55:40.000000000 -0800
> > @@ -286,6 +286,24 @@ extern struct lockdep_map rcu_lock_map;
> > })
> >
> > /**
> > + * rcu_assign_index - assign (publicize) a index of a newly
> > + * initialized array elementg that will be dereferenced by RCU
> > + * read-side critical sections. Returns the value assigned.
> > + *
> > + * Inserts memory barriers on architectures that require them
> > + * (pretty much all of them other than x86), and also prevents
> > + * the compiler from reordering the code that initializes the
> > + * structure after the index assignment. More importantly, this
> > + * call documents which indexes will be dereferenced by RCU read-side
> > + * code.
> > + */
>
> s/a index/index/
>
> Along with Gautham's typo fix, you could also make this be passable
> kernel-doc notation. :)
Guess I should do the same for rcu_assign_pointer() and probably several
others as well... Good catch!!!
Thanx, Paul
> See Documentation/kernel-doc-nano-HOWTO.txt for details.
>
> Summary:
> The function (or macro) name and short description must be on one line.
> This is followed by the parameters, then a "blank" (actually " *") line,
> then any (longer) description, notes, etc. So basically:
>
> /**
> * rcu_assign_index - assign (publicize) index of a newly initialized array element
> * @p: description of @p
> * @v: description of @v
> *
> * This function assigns (publicizes) the index of a newly
> * initialized array element that will be dereferenced by RCU
> * read-side critical sections. Returns the value assigned.
> *
> * Inserts memory barriers on architectures that require them
> * (pretty much all of them other than x86), and also prevents
> * the compiler from reordering the code that initializes the
> * structure after the index assignment. More importantly, this
> * call documents which indexes will be dereferenced by RCU read-side
> * code.
> */
>
>
> > +
> > +#define rcu_assign_index(p, v) ({ \
> > + smp_wmb(); \
> > + (p) = (v); \
> > + })
> > +
> > +/**
> > * synchronize_sched - block until all CPUs have exited any non-preemptive
> > * kernel code sequences.
> > *
>
> ---
> ~Randy
^ permalink raw reply
* Re: [Bugme-new] [Bug 9990] New: tg3: eth0: The system may be re-ordering memory-mapped I/O cycles
From: Andrew Morton @ 2008-02-14 18:24 UTC (permalink / raw)
To: Matt Carlson, Michael Chan; +Cc: bugme-daemon, netdev, ralf.hildebrandt
In-Reply-To: <bug-9990-10286@http.bugzilla.kernel.org/>
On Thu, 14 Feb 2008 01:59:12 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9990
>
> Summary: tg3: eth0: The system may be re-ordering memory-mapped
> I/O cycles
> Product: Drivers
> Version: 2.5
> KernelVersion: 2.6.24-git18
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: jgarzik@pobox.com
> ReportedBy: ralf.hildebrandt@charite.de
>
>
> Latest working kernel version: 2.6.24
> Earliest failing kernel version: 2.6.24-git18
> Distribution: Debian/testing
> Hardware Environment:
> Software Environment:
> Problem Description:
>
> Feb 11 13:11:52 www kernel: [ 12.015569] tg3: eth0: Link is up at 100 Mbps,
> full duplex.
> Feb 11 13:11:52 www kernel: [ 12.015633] tg3: eth0: Flow control is on for TX
> and on for RX.
> Feb 11 13:33:44 www kernel: [ 1328.538204] tg3: eth0: The system may be
> re-ordering memory-mapped I/O cycles to the network
> device, attempting to recover. Please report the problem to the driver
> maintainer and include system chipset information.
> Feb 11 13:33:44 www kernel: [ 1328.667255] tg3: eth0: Link is down.
> Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Link is up at 100 Mbps,
> full duplex.
> Feb 11 13:33:46 www kernel: [ 1330.560734] tg3: eth0: Flow control is on for TX
> and on for RX.
>
> After that, the machine rebooted (panic?)
>
> Feb 11 13:35:14 www kernel: klogd 1.5.0#1.1, log source = /proc/kmsg started.
>
> lspci -vvv info:
> 02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> Ethernet (rev 10)
> Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> (PCI-X, 10,100,1000-T)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 19
> Region 0: Memory at fdf70000 (64-bit, non-prefetchable) [size=64K]
> [virtual] Expansion ROM at 88140000 [disabled] [size=64K]
> Capabilities: [40] PCI-X non-bridge device
> Command: DPERE- ERO- RBC=2048 OST=1
> Status: Dev=02:02.0 64bit+ 133MHz+ SCD- USC- DC=simple
> DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> Capabilities: [48] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable+ DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data <?>
> Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> Enable-
> Address: fd7ffd6fdf7deeb8 Data: bdfd
> Kernel driver in use: tg3
> Kernel modules: tg3
>
> 02:02.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
> Ethernet (rev 10)
> Subsystem: Compaq Computer Corporation NC7782 Gigabit Server Adapter
> (PCI-X, 10,100,1000-T)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (16000ns min), Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 20
> Region 0: Memory at fdf60000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [40] PCI-X non-bridge device
> Command: DPERE- ERO+ RBC=512 OST=1
> Status: Dev=02:02.1 64bit+ 133MHz+ SCD- USC- DC=simple
> DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
> Capabilities: [48] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data <?>
> Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3
> Enable-
> Address: f73feeefffffe7f8 Data: 9bcd
> Kernel driver in use: tg3
> Kernel modules: tg3
>
>
> Steps to reproduce:
>
>
^ permalink raw reply
* [PATCH 2/2] e1000e: PCIe devices do not need to unset MANC_ARP_ENA
From: Auke Kok @ 2008-02-14 18:17 UTC (permalink / raw)
To: jeff; +Cc: netdev, e1000-devel
In-Reply-To: <20080214181712.11070.48342.stgit@localhost.localdomain>
From: David Graham <david.graham@intel.com>
Users reported that ARP's were lost with e1000e. The problem
is fixed by not enabling this manageability configuration
bit.
None of the release_manageability code is actually needed as the
normal device reset during a shutdown returns everthing to
the right condition automatically.
Signed-off-by: David Graham <david.graham@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/netdev.c | 26 --------------------------
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index ea4ecc3..3031d6d 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1055,23 +1055,6 @@ static void e1000_release_hw_control(struct e1000_adapter *adapter)
}
}
-static void e1000_release_manageability(struct e1000_adapter *adapter)
-{
- if (adapter->flags & FLAG_MNG_PT_ENABLED) {
- struct e1000_hw *hw = &adapter->hw;
-
- u32 manc = er32(MANC);
-
- /* re-enable hardware interception of ARP */
- manc |= E1000_MANC_ARP_EN;
- manc &= ~E1000_MANC_EN_MNG2HOST;
-
- /* don't explicitly have to mess with MANC2H since
- * MANC has an enable disable that gates MANC2H */
- ew32(MANC, manc);
- }
-}
-
/**
* @e1000_alloc_ring - allocate memory for a ring structure
**/
@@ -1561,9 +1544,6 @@ static void e1000_init_manageability(struct e1000_adapter *adapter)
manc = er32(MANC);
- /* disable hardware interception of ARP */
- manc &= ~(E1000_MANC_ARP_EN);
-
/* enable receiving management packets to the host. this will probably
* generate destination unreachable messages from the host OS, but
* the packets will be handled on SMBUS */
@@ -2140,8 +2120,6 @@ void e1000e_reset(struct e1000_adapter *adapter)
phy_data &= ~IGP02E1000_PM_SPD;
e1e_wphy(hw, IGP02E1000_PHY_POWER_MGMT, phy_data);
}
-
- e1000_release_manageability(adapter);
}
int e1000e_up(struct e1000_adapter *adapter)
@@ -3487,8 +3465,6 @@ static int e1000_suspend(struct pci_dev *pdev, pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- e1000_release_manageability(adapter);
-
/* make sure adapter isn't asleep if manageability is enabled */
if (adapter->flags & FLAG_MNG_PT_ENABLED) {
pci_enable_wake(pdev, PCI_D3hot, 1);
@@ -4054,8 +4030,6 @@ static void __devexit e1000_remove(struct pci_dev *pdev)
flush_scheduled_work();
- e1000_release_manageability(adapter);
-
/* Release control of h/w to f/w. If f/w is AMT enabled, this
* would have already happened in close and is redundant. */
e1000_release_hw_control(adapter);
^ permalink raw reply related
* [PATCH 1/2] igb: PCIe devices do not need to unset MANC_ARP_ENA
From: Auke Kok @ 2008-02-14 18:17 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
From: David Graham <david.graham@intel.com>
Users reported that ARP's were lost with igb. The problem
is fixed by not enabling this manageability configuration
bit.
None of the release_manageability code is actually needed as the
normal device reset during a shutdown returns everthing to
the right condition automatically.
Signed-off-by: David Graham <david.graham@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/igb/igb_main.c | 28 ----------------------------
1 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index d4eb8e2..bff280e 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -606,9 +606,6 @@ static void igb_init_manageability(struct igb_adapter *adapter)
u32 manc2h = rd32(E1000_MANC2H);
u32 manc = rd32(E1000_MANC);
- /* disable hardware interception of ARP */
- manc &= ~(E1000_MANC_ARP_EN);
-
/* enable receiving management packets to the host */
/* this will probably generate destination unreachable messages
* from the host OS, but the packets will be handled on SMBUS */
@@ -623,25 +620,6 @@ static void igb_init_manageability(struct igb_adapter *adapter)
}
}
-static void igb_release_manageability(struct igb_adapter *adapter)
-{
- struct e1000_hw *hw = &adapter->hw;
-
- if (adapter->en_mng_pt) {
- u32 manc = rd32(E1000_MANC);
-
- /* re-enable hardware interception of ARP */
- manc |= E1000_MANC_ARP_EN;
- manc &= ~E1000_MANC_EN_MNG2HOST;
-
- /* don't explicitly have to mess with MANC2H since
- * MANC has an enable disable that gates MANC2H */
-
- /* XXX stop the hardware watchdog ? */
- wr32(E1000_MANC, manc);
- }
-}
-
/**
* igb_configure - configure the hardware for RX and TX
* @adapter: private board structure
@@ -844,7 +822,6 @@ void igb_reset(struct igb_adapter *adapter)
igb_reset_adaptive(&adapter->hw);
adapter->hw.phy.ops.get_phy_info(&adapter->hw);
- igb_release_manageability(adapter);
}
/**
@@ -1178,9 +1155,6 @@ static void __devexit igb_remove(struct pci_dev *pdev)
flush_scheduled_work();
-
- igb_release_manageability(adapter);
-
/* Release control of h/w to f/w. If f/w is AMT enabled, this
* would have already happened in close and is redundant. */
igb_release_hw_control(adapter);
@@ -3955,8 +3929,6 @@ static int igb_suspend(struct pci_dev *pdev, pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- igb_release_manageability(adapter);
-
/* make sure adapter isn't asleep if manageability is enabled */
if (adapter->en_mng_pt) {
pci_enable_wake(pdev, PCI_D3hot, 1);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply related
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:38 UTC (permalink / raw)
To: Badari Pulavarty
Cc: Christoph Raisch, ossthema, apw, Greg KH, Jan-Bernd Themann,
linux-kernel, linuxppc-dev, netdev, Thomas Q Klein, tklein
In-Reply-To: <1203010575.12312.6.camel@dyn9047017100.beaverton.ibm.com>
On Thu, 2008-02-14 at 09:36 -0800, Badari Pulavarty wrote:
>
> I am not sure what you are trying to do with walk_memory_resource().
> The
> behavior is different on ppc64. Hotplug memory usage assumes that all
> the memory resources (all system memory, not just IOMEM) are
> represented
> in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
> contains ONLY iomem related. Paulus didn't want to export all the
> system
> memory into /proc/iomem on ppc64. So I had to workaround by providing
> arch-specific walk_memory_resource() function for ppc64.
OK, let's use that one.
-- Dave
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Badari Pulavarty @ 2008-02-14 17:36 UTC (permalink / raw)
To: Dave Hansen
Cc: Christoph Raisch, ossthema, apw, Greg KH, Jan-Bernd Themann,
linux-kernel, linuxppc-dev, netdev, Thomas Q Klein, tklein
In-Reply-To: <1203009163.19205.42.camel@nimitz.home.sr71.net>
On Thu, 2008-02-14 at 09:12 -0800, Dave Hansen wrote:
..
> > > > - Use currently other not exported functions in kernel/resource.c, like
> > > > walk_memory_resource (where we would still need the maximum
> > > possible number
> > > > of pages NR_MEM_SECTIONS)
> > >
> > > It isn't the act of exporting that's the problem. It's making sure that
> > > the exports won't be prone to abuse and that people are using them
> > > properly. You should assume that you can export and use
> > > walk_memory_resource().
> >
> > So this seems to come down to a basic question:
> > New hardware seems to have a tendency to get "private MMUs",
> > which need private mappings from the kernel address space into a
> > "HW defined address space with potentially unique characteristics"
> > RDMA in Openfabrics with global MR is the most prominent example heading
> > there
>
> That's not a question. ;)
>
> Please explain to me why walk_memory_resource() is insufficient for your
> needs. I've now pointed it out to you at least 3 times.
I am not sure what you are trying to do with walk_memory_resource(). The
behavior is different on ppc64. Hotplug memory usage assumes that all
the memory resources (all system memory, not just IOMEM) are represented
in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
contains ONLY iomem related. Paulus didn't want to export all the system
memory into /proc/iomem on ppc64. So I had to workaround by providing
arch-specific walk_memory_resource() function for ppc64.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 2/2] add rcu_assign_index() if ever needed
From: Randy Dunlap @ 2008-02-14 17:24 UTC (permalink / raw)
To: paulmck
Cc: linux-kernel, shemminger, davem, netdev, dipankar, ego, herbert,
akpm
In-Reply-To: <20080213220515.GA10642@linux.vnet.ibm.com>
On Wed, 13 Feb 2008 14:05:15 -0800 Paul E. McKenney wrote:
> Hello again!
>
> This is a speculative patch that as far as I can tell is not yet required.
> If anyone applies RCU to a data structure allocated out of an array, using
> array indexes in place of pointers to link the array elements together,
> then the rcu_assign_index() function in this patch will be needed to
> assign a given element's array index to the RCU-traversed index. The
> implementation is exactly that of the old rcu_assign_pointer(), so is
> extremely well tested.
>
> The existing rcu_assign_pointer() will emit a compiler warning in cases
> where rcu_assign_index() is required.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
>
> rcupdate.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff -urpNa -X dontdiff linux-2.6.24-rap/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
> --- linux-2.6.24-rap/include/linux/rcupdate.h 2008-02-13 13:36:47.000000000 -0800
> +++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-13 10:55:40.000000000 -0800
> @@ -286,6 +286,24 @@ extern struct lockdep_map rcu_lock_map;
> })
>
> /**
> + * rcu_assign_index - assign (publicize) a index of a newly
> + * initialized array elementg that will be dereferenced by RCU
> + * read-side critical sections. Returns the value assigned.
> + *
> + * Inserts memory barriers on architectures that require them
> + * (pretty much all of them other than x86), and also prevents
> + * the compiler from reordering the code that initializes the
> + * structure after the index assignment. More importantly, this
> + * call documents which indexes will be dereferenced by RCU read-side
> + * code.
> + */
s/a index/index/
Along with Gautham's typo fix, you could also make this be passable
kernel-doc notation. :)
See Documentation/kernel-doc-nano-HOWTO.txt for details.
Summary:
The function (or macro) name and short description must be on one line.
This is followed by the parameters, then a "blank" (actually " *") line,
then any (longer) description, notes, etc. So basically:
/**
* rcu_assign_index - assign (publicize) index of a newly initialized array element
* @p: description of @p
* @v: description of @v
*
* This function assigns (publicizes) the index of a newly
* initialized array element that will be dereferenced by RCU
* read-side critical sections. Returns the value assigned.
*
* Inserts memory barriers on architectures that require them
* (pretty much all of them other than x86), and also prevents
* the compiler from reordering the code that initializes the
* structure after the index assignment. More importantly, this
* call documents which indexes will be dereferenced by RCU read-side
* code.
*/
> +
> +#define rcu_assign_index(p, v) ({ \
> + smp_wmb(); \
> + (p) = (v); \
> + })
> +
> +/**
> * synchronize_sched - block until all CPUs have exited any non-preemptive
> * kernel code sequences.
> *
---
~Randy
^ permalink raw reply
* Re: [PATCH 2.6.25] igb: fix legacy mode irq issue
From: Kok, Auke @ 2008-02-14 17:24 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, Auke Kok, David S. Miller, Jeff Garzik
In-Reply-To: <20080214031920.GI856@gospo.usersys.redhat.com>
Andy Gospodarek wrote:
> I booted an igb kernel with the option pci=nomsi and instantly noticed
> that interrupts no longer worked on my igb device. I took a look at the
> interrupt initialization and quickly discovered a comment stating:
>
> "DO NOT USE EIAME or IAME in legacy mode"
>
> It seemed a bit odd that bits to enable IAM were being set in legacy
> interrupt mode, so I dropped out the following parts and interrupts
> began working fine again.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
looks valid, I'll test and see, thanks Andy
Auke
> ---
>
> igb_main.c | 3 ---
> 1 files changed, 3 deletions(-)
>
> diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
> index f3c144d..be5da09 100644
> --- a/drivers/net/igb/igb_main.c
> +++ b/drivers/net/igb/igb_main.c
> @@ -472,9 +471,6 @@ static int igb_request_irq(struct igb_adapter *adapter)
> goto request_done;
> }
>
> - /* enable IAM, auto-mask */
> - wr32(E1000_IAM, IMS_ENABLE_MASK);
> -
> request_done:
> return err;
> }
> --
> 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
* [PATCH] Make sure sockets implement splice_read
From: Rémi Denis-Courmont @ 2008-02-14 16:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Fixes a segmentation fault when trying to splice from a non-TCP socket.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>
---
net/socket.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 7651de0..b6d35cd 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -701,6 +701,9 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
{
struct socket *sock = file->private_data;
+ if (unlikely(!sock->ops->splice_read))
+ return -EINVAL;
+
return sock->ops->splice_read(sock, ppos, pipe, len, flags);
}
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:12 UTC (permalink / raw)
To: Christoph Raisch
Cc: ossthema, apw, Greg KH, Jan-Bernd Themann, linux-kernel,
linuxppc-dev, netdev, Badari Pulavarty, Thomas Q Klein, tklein
In-Reply-To: <OF64B9886B.CE795DED-ONC12573EF.002FFA8B-C12573EF.00301683@de.ibm.com>
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > > Constraints imposed by HW / FW:
> > > - eHEA has own MMU
> > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
> virtual
> > > addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> > > - The number of MRs is limited (not enough to have one MR per packet)
> >
> > Are there enough to have one per 16MB section?
>
> Unfortunately this won't work. This was one of our first ideas we tossed
> out,
> but the number of MRs will not be sufficient.
Can you give a ballpark of how many there are to work with? 10? 100?
1000?
> We understand that the add/remove area is not as
> settled in the kernel like for example f_ops ;-)
> Are there already base working assumptions which are very unlikely to
> change?
If you use good interfaces, and someone changes them, they'll likely
also fix your driver.
If you use bad interfaces, people may not even notice when they break.
As I showed you with those compile failures, you're using bad interfaces
that don't even compile on some .configs.
> I'm a little confused here....
> ...the existing add/remove code depends on sparse mem.
> Other pieces on the POWER6 version of the architecture do as well.
> So we could either chose to disable add/remove if sparsemem is not there,
> or disable the driver by Kconfig in this case.
Technically, you can do this. But, it's not a sign of a professionally
written driver that is going to get its patches accepted into mainline.
Technically, you can also use lots of magic numbers and not obey
CodingStyle. But, you'll probably get review comments asking you to
change it.
> > > - a way to iterate over all kernel pages and a way to detect holes in
> the
> > > kernel memory layout in order to build up our own ehea_bmap.
> >
> > Look at kernel/resource.c
> >
> > But, I'm really not convinced that you can actually keep this map
> > yourselves. It's not as simple as you think. What happens if you get
> > on an LPAR with two sections, one 256MB@0x0 and another
> > 16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
> > array will eat all of memory.
> I'm glad you mention this part. There are many algorithms out there to
> handle this problem,
> hashes/trees/... all of these trade speed for smaller memory footprint.
> We based the table decission on the existing implementations of the
> architecture.
> Do you see such a case coming along for the next generation POWER systems?
Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of
memory to it. Then, remove all of the sections of memory in the middle.
You'll be left with a very sparse memory configuration that we *DO*
handle today in the core VM. We handle it quite well, actually.
The hypervisor does not shrink memory from the top down. It pulls
things out of the middle and shuffles things around. In fact, a NUMA
node's memory isn't even contiguous.
Your code will OOM the machine in this case. I consider the ehea driver
buggy in this regard.
> I would guess these drastic changes would also require changes in base
> kernel.
No, we actually solved those a couple years ago.
> Will you provide a generic mapping system with a contiguous virtual address
> space
> like the ehea_bmap we can query? This would need to be a "stable" part of
> the implementation,
> including translation functions from kernel to nextgen_ehea_generic_bmap
> like virt_to_abs.
Yes, that's a real possibility, especially if some other users for it
come forward. We could definitely add something like that to the
generic code. But, you'll have to be convincing that what we have now
is insufficient.
Does this requirement:
"- MRs cover a contiguous virtual memory block (no holes)"
come from the hardware?
Is that *EACH* MR? OR all MRs?
Where does EHEA_BUSMAP_START come from? Is that defined in the
hardware? Have you checked to ensure that no other users might want a
chunk of memory in that area?
Can you query the existing MRs? Not change them in place, but can you
query their contents?
> > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
> > in the core, so that we can deal with these kinds of problems, once and
> > *NOT* in every single little driver out there.
> >
> > > Functions to use while building ehea_bmap + MRs:
> > > - Use either the functions that are used by the memory hotplug system
> as
> > > well, that means using the section defines + functions
> (section_nr_to_pfn,
> > > pfn_valid)
> >
> > Basically, you can't use anything related to sections outside of the
> > core code. You can use things like pfn_valid(), or you can create new
> > interfaces that are properly abstracted.
>
> We picked sections instead of PFNs because this keeps the ehea_bmap in a
> reasonable range
> on the existing systems.
> But if you provide a abstract method handling exactly the problem we
> mention
> we'll be happy to use that and dump our private implementation.
One thing you can guarantee today is that things are contiguous up to
MAX_ORDER_NR_PAGES. That's a symbol that is unlikely to change and is
much more appropriate than using sparsemem. We could also give you a
nice new #define like MINIMUM_CONTIGUOUS_PAGES or something. I think
that's what you really want.
> > > - Use currently other not exported functions in kernel/resource.c, like
> > > walk_memory_resource (where we would still need the maximum
> > possible number
> > > of pages NR_MEM_SECTIONS)
> >
> > It isn't the act of exporting that's the problem. It's making sure that
> > the exports won't be prone to abuse and that people are using them
> > properly. You should assume that you can export and use
> > walk_memory_resource().
>
> So this seems to come down to a basic question:
> New hardware seems to have a tendency to get "private MMUs",
> which need private mappings from the kernel address space into a
> "HW defined address space with potentially unique characteristics"
> RDMA in Openfabrics with global MR is the most prominent example heading
> there
That's not a question. ;)
Please explain to me why walk_memory_resource() is insufficient for your
needs. I've now pointed it out to you at least 3 times.
> > Do you know what other operating systems do with this hardware?
>
> We're not aware of another open source Operating system trying to address
> this topic.
What about AIX? Do you know who wrote its driver? Perhaps you should
go ask them.
-- Dave
^ 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