* Re: [Bugme-new] [Bug 14450] New: [2.6.31] Network interfaces are dead with 2.6.31 (iwlagn and sky2)
From: Andrew Morton @ 2009-11-03 23:21 UTC (permalink / raw)
To: orion.linbug
Cc: bugzilla-daemon, bugme-daemon, netdev, linux-acpi,
Rafael J. Wysocki, linux-wireless
In-Reply-To: <bug-14450-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 21 Oct 2009 07:30:12 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14450
>
> Summary: [2.6.31] Network interfaces are dead with 2.6.31
> (iwlagn and sky2)
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.31
Rafael, this is a 2.6.30->2.6.31 regression.
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: orion.linbug@gmail.com
> Regression: Yes
>
>
> My wireless and ethernet networks are dead with the kernel 2.6.31. All work
> very fine with the 2.6.30 and older. I have a Toshiba laptop wich uses the
> iwlagn module for wireless and the sky2 for ethernet. I have tested with
> acpi=off in the grub kernel line but it freezes the system on boot...
> ifconfig gets only the lo interface. ifconfig eth0 or wlan0 up gets something
> like "the interface doesn't exist".
>
> lspci shows:
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
> Controller Hub (rev 07)
> 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express
> Graphics Port (rev 07)
> 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #4 (rev 03)
> 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #5 (rev 03)
> 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #6 (rev 03)
> 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #2 (rev 03)
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
> Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1
> (rev 03)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2
> (rev 03)
> 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4
> (rev 03)
> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #3 (rev 03)
> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #1 (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
> 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev
> 03)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
> 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD
> 4500 Series]
> 01:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000
> Series]
> 02:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
> 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040T PCI-E Fast
> Ethernet Controller (rev 12)
> 0a:01.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
> 0a:01.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev
> 02)
> 0a:01.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller
> (rev 01)
>
> Dmesg shows errors on sky2 and iwlagn driver:
> iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks2009-10-13
> 17:57:36
> iwlagn: Copyright(c) 2003-2009 Intel Corporation2009-10-13 17:57:36
> iwlagn 0000:02:00.0: enabling device (0000 -> 0002)2009-10-13 17:57:36
> iwlagn 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 162009-10-13
> 17:57:36
> iwlagn 0000:02:00.0: Detected Intel Wireless WiFi Link 5100AGN
> REV=0xFFFFFFFF2009-10-13 17:57:36
> Clocksource tsc unstable (delta = -212055894 ns)2009-10-13 17:57:36
> iwlagn 0000:02:00.0: Failed, HW not ready2009-10-13 17:57:36
> iwlagn 0000:02:00.0: PCI INT A disabled2009-10-13 17:57:36
>
> sky2 driver version 1.232009-10-13 17:50:48
> sky2 0000:03:00.0: enabling device (0000 -> 0003)2009-10-13 17:50:48
> sky2 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 172009-10-13
> 17:50:48
> sky2 0000:03:00.0: PCI INT A disabled2009-10-13 17:50:48
> sky2: probe of 0000:03:00.0 failed with error -952009-10-13 17:50:48
Given that both the wired and wireless interfaces failed, I'd assume
that something went wrong at the bus level. Perhaps due to an ACPI
change.
Could the sky2, iwlagn and ACPI developers please take a look, offer an
opinion as to where we should be looking?
Thanks.
^ permalink raw reply
* Re: [Bugme-new] [Bug 14451] New: b44 BCM4401 immediate disconnect and power down after ip assignment
From: Andrew Morton @ 2009-11-03 23:23 UTC (permalink / raw)
To: Gary Zambrano; +Cc: bugzilla-daemon, bugme-daemon, netdev, andreas
In-Reply-To: <bug-14451-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 21 Oct 2009 07:38:13 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14451
>
> Summary: b44 BCM4401 immediate disconnect and power down after
> ip assignment
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.31.4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: andreas@schipplock.de
> Regression: No
>
>
> Hi,
> I compiled the linux kernel 2.6.31.4 and after "dhcpcd" wanted to assign an ip,
> it worked for 500ms and I then got the following message being repeated a _lot_
> in dmesg:
>
> b44: eth0: powering down PHY
> b44: eth0: Link is down.
> b44: eth0: Link is up at 100 Mbps, full duplex.
> b44: eth0: Flow control is off for TX and off for RX.
> b44: eth0: powering down PHY
> b44: eth0: Link is down.
> b44: eth0: Link is up at 100 Mbps, full duplex.
> b44: eth0: Flow control is off for TX and off for RX.
>
> These messages repeat endlessly and I can't establish a connection.
>
> The exact name of the ethernet controller is: "08:00.0 Ethernet controller:
> Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)" regarding lspci output.
>
> When I execute "ifconfig" every 500ms I can see that the device "eth0" gets a
> valid ip but the next time I execute ifconfig the ip is already "gone" and I
> again get the the messages posted above in dmesg.
>
> I first thought was that I have a media problem so I replaced all my wires but
> the problem still exists and the problem doesn't appear on the 2.6.28.x kernel
> which I ran before. I even installed linux mint in a hurry to see if it's
> really not a hardware issue and it worked there without a problem (using kernel
> 2.6.28-11, that's how they call it).
>
> I've got no further idea. I created three different config files from scratch
> using menuconfig. In the end I even thought other modules are conflicting and I
> adapted the config so it only fits for my specific hardware which gave me some
> good boot time but no success regarding the bcm4401 issue.
>
> Any help is appreciated.
>
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 23:46 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <14add3d10911031509l328e7674kb625b70250ff30fb@mail.gmail.com>
On Wednesday 04 November 2009 00:09:02 Gertjan van Wingerde wrote:
> On Tue, Nov 3, 2009 at 11:34 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> > On Tuesday 03 November 2009 23:01:32 Ivo van Doorn wrote:
> >> > > > The following patch series (against wireless-next) addresses issues raised
> >> > > > during code review and subsequently rejected by rt2x00/wireless/networking
> >> > > > maintainers.
> >> > >
> >> > > Really stop reading only the half of emails, try reading it entirely (or at least don't
> >> > > stop at the second word in a sentence). It really starts the bug me to repeat
> >> > > myself over and over again because you refuse to read.
> >> > >
> >> > > Your comments during code review were ACCEPTED with the only remark that
> >> > > it shouldn't be done right here and now.
> >> >
> >> > Please stop this bullshit. We have some standards for the upstream code
> >> > and by being maintainer you have to live up to this standards and make sure
> >> > that they are respected instead of watering them down yourself..
> >> >
> >> > You were not interested even in fixing the headers duplication (it turned
> >> > out debugging scripts needed only 25 lines of code to be able to work with
> >> > fixed headers -- 25 LOC in bash scripts used only for debugging instead
> >> > of 1800 LOC of kernel code).
> >>
> >> Yeah I know that. But like I said, I still needed to get around to do that,
> >> and I am very happy you were interested in fixing it.
> >
> > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> >
> > I'm not in slightest interested in wasting my time on such
> > things and educating some maintainers about basics.
> >
> > [ Code duplication is bad, mmm'okay? Just say no, mmm'okay? ]
> >
>
> Bart,
>
> Are you really interested in working with us (the rt2x00 project) in
> getting the rt2800{pci,usb}
> drivers in a better shape, or do you just want to continue your
> ramblings on how bad you
> think the rt2x00 maintainers, wireless maintainer, and networking
> maintainer are in your view?
>
> Just continuing these discussions doesn't help a bit as Ivo, John, and
> David said they disagreed
> with you on this topic.
I tried explain many times that it is not about what is in MAINTAINERS
file or what somebody says.
> If you just want to continue with a hostile take-over of the rt2800
> maintainership, then please
> let us know that, so that we stop spending time on useless
I fail to see why you see it as a hostile takeover.
I just did what should have been done in the first place (+ I'm going
to push drivers further in this direction in my tree) and I was always
pretty clear that once staging drivers become sufficiently cleaned up
I would start re-basing my efforts on in kernel drivers.
I will be glad to cooperate with you or anyone else from rt2x00 project.
However I will not spin in some stupid bureaucracy when I see that things
can be done more effectively.
> discussions, and let John Linville
> decide how he wants to handle this situation. It would be a shame of
> the good patches and work
> you did, but if that's the case, than that's it.
John can just pull my tree in right now since it is based on his tree
and it would be an immediate improvement over what its in his tree.
It is up to him, or Ivo can also pull my patches into his tree.
You can also decide to throw up my patches completely or re-do them
for some silly reasons. I won't be making much noise about it since
I'll be already on some next patches..
> Otherwise, please focus on the technical contents of the patches and
> work with us to get
> these drivers in a better shape.
This is what I'm focused on, if you have any technical arguments w.r.t.
my patches I'm willing to listen and address them in sensible time
(if they are valid). I would also be happy to work with people with any
patches that they are working on currently.
Thanks.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Alan Cox @ 2009-11-03 23:48 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911032334.40547.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Yeah I know that. But like I said, I still needed to get around to do that,
> > and I am very happy you were interested in fixing it.
>
> Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
Really - you have a service and support contract with Ivo.. no i thought
not.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 23:52 UTC (permalink / raw)
To: Alan Cox
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <20091103234835.3042f7b5@lxorguk.ukuu.org.uk>
On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > and I am very happy you were interested in fixing it.
> >
> > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
>
> Really - you have a service and support contract with Ivo.. no i thought
> not.
Just today I got PM from somebody complaining to me about non-working
pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
I fixed some bug there some time ago....
Problems are publicly know -- do you want bz# from Debian, SuSE or Red Hat?
Wait.. unfortunately I also don't have support contract with you..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* [net-next PATCH 0/3] qlge: Clean up and firmware subcommands.
From: Ron Mercer @ 2009-11-03 23:49 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
Hello Dave,
Patch #1 is a respin per your request from yesterday.
Patch #2 adds handling for more firmware events.
Patch #3 cleans up netdev statistics handling.
Regards,
Ron Mercer
^ permalink raw reply
* [net-next PATCH 1/3] qlge: Fix indentations.
From: Ron Mercer @ 2009-11-03 23:49 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
In-Reply-To: <1257292171-11683-1-git-send-email-ron.mercer@qlogic.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index fa53009..4a07548 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -2102,12 +2102,12 @@ static irqreturn_t qlge_isr(int irq, void *dev_id)
*/
var = ql_read32(qdev, ISR1);
if (var & intr_context->irq_mask) {
- QPRINTK(qdev, INTR, INFO,
+ QPRINTK(qdev, INTR, INFO,
"Waking handler for rx_ring[0].\n");
ql_disable_completion_interrupt(qdev, intr_context->intr);
- napi_schedule(&rx_ring->napi);
- work_done++;
- }
+ napi_schedule(&rx_ring->napi);
+ work_done++;
+ }
ql_enable_completion_interrupt(qdev, intr_context->intr);
return work_done ? IRQ_HANDLED : IRQ_NONE;
}
--
1.6.0.2
^ permalink raw reply related
* [net-next PATCH 3/3] qlge: Clean up netdev->stats usage.
From: Ron Mercer @ 2009-11-03 23:49 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
In-Reply-To: <1257292171-11683-1-git-send-email-ron.mercer@qlogic.com>
Don't access netdev->stats in IO path. Save them in tx_ring/rx_rings
and add them up when get_stats API is called.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge.h | 8 +++++++
drivers/net/qlge/qlge_main.c | 46 +++++++++++++++++++++++++++++++++++++----
2 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/drivers/net/qlge/qlge.h b/drivers/net/qlge/qlge.h
index 5e4d343..1f59f05 100644
--- a/drivers/net/qlge/qlge.h
+++ b/drivers/net/qlge/qlge.h
@@ -1263,6 +1263,9 @@ struct tx_ring {
atomic_t queue_stopped; /* Turns queue off when full. */
struct delayed_work tx_work;
struct ql_adapter *qdev;
+ u64 tx_packets;
+ u64 tx_bytes;
+ u64 tx_errors;
};
/*
@@ -1329,6 +1332,11 @@ struct rx_ring {
struct napi_struct napi;
u8 reserved;
struct ql_adapter *qdev;
+ u64 rx_packets;
+ u64 rx_multicast;
+ u64 rx_bytes;
+ u64 rx_dropped;
+ u64 rx_errors;
};
/*
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index 4a07548..0de596a 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -1661,6 +1661,7 @@ static void ql_process_mac_rx_intr(struct ql_adapter *qdev,
if (unlikely(!skb)) {
QPRINTK(qdev, RX_STATUS, DEBUG,
"No skb available, drop packet.\n");
+ rx_ring->rx_dropped++;
return;
}
@@ -1669,6 +1670,7 @@ static void ql_process_mac_rx_intr(struct ql_adapter *qdev,
QPRINTK(qdev, DRV, ERR, "Receive error, flags2 = 0x%x\n",
ib_mac_rsp->flags2);
dev_kfree_skb_any(skb);
+ rx_ring->rx_errors++;
return;
}
@@ -1677,6 +1679,7 @@ static void ql_process_mac_rx_intr(struct ql_adapter *qdev,
*/
if (skb->len > ndev->mtu + ETH_HLEN) {
dev_kfree_skb_any(skb);
+ rx_ring->rx_dropped++;
return;
}
@@ -1697,6 +1700,7 @@ static void ql_process_mac_rx_intr(struct ql_adapter *qdev,
IB_MAC_IOCB_RSP_M_REG ? "Registered" : "",
(ib_mac_rsp->flags1 & IB_MAC_IOCB_RSP_M_MASK) ==
IB_MAC_IOCB_RSP_M_PROM ? "Promiscuous" : "");
+ rx_ring->rx_multicast++;
}
if (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_P) {
QPRINTK(qdev, RX_STATUS, DEBUG, "Promiscuous Packet.\n");
@@ -1728,8 +1732,8 @@ static void ql_process_mac_rx_intr(struct ql_adapter *qdev,
}
}
- ndev->stats.rx_packets++;
- ndev->stats.rx_bytes += skb->len;
+ rx_ring->rx_packets++;
+ rx_ring->rx_bytes += skb->len;
skb_record_rx_queue(skb, rx_ring->cq_id);
if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
if (qdev->vlgrp &&
@@ -1753,7 +1757,6 @@ static void ql_process_mac_rx_intr(struct ql_adapter *qdev,
static void ql_process_mac_tx_intr(struct ql_adapter *qdev,
struct ob_mac_iocb_rsp *mac_rsp)
{
- struct net_device *ndev = qdev->ndev;
struct tx_ring *tx_ring;
struct tx_ring_desc *tx_ring_desc;
@@ -1761,8 +1764,8 @@ static void ql_process_mac_tx_intr(struct ql_adapter *qdev,
tx_ring = &qdev->tx_ring[mac_rsp->txq_idx];
tx_ring_desc = &tx_ring->q[mac_rsp->tid];
ql_unmap_send(qdev, tx_ring_desc, tx_ring_desc->map_cnt);
- ndev->stats.tx_bytes += (tx_ring_desc->skb)->len;
- ndev->stats.tx_packets++;
+ tx_ring->tx_bytes += (tx_ring_desc->skb)->len;
+ tx_ring->tx_packets++;
dev_kfree_skb(tx_ring_desc->skb);
tx_ring_desc->skb = NULL;
@@ -2205,6 +2208,7 @@ static netdev_tx_t qlge_send(struct sk_buff *skb, struct net_device *ndev)
__func__, tx_ring_idx);
netif_stop_subqueue(ndev, tx_ring->wq_id);
atomic_inc(&tx_ring->queue_stopped);
+ tx_ring->tx_errors++;
return NETDEV_TX_BUSY;
}
tx_ring_desc = &tx_ring->q[tx_ring->prod_idx];
@@ -2239,6 +2243,7 @@ static netdev_tx_t qlge_send(struct sk_buff *skb, struct net_device *ndev)
NETDEV_TX_OK) {
QPRINTK(qdev, TX_QUEUED, ERR,
"Could not map the segments.\n");
+ tx_ring->tx_errors++;
return NETDEV_TX_BUSY;
}
QL_DUMP_OB_MAC_IOCB(mac_iocb_ptr);
@@ -3817,6 +3822,37 @@ static int qlge_change_mtu(struct net_device *ndev, int new_mtu)
static struct net_device_stats *qlge_get_stats(struct net_device
*ndev)
{
+ struct ql_adapter *qdev = netdev_priv(ndev);
+ struct rx_ring *rx_ring = &qdev->rx_ring[0];
+ struct tx_ring *tx_ring = &qdev->tx_ring[0];
+ unsigned long pkts, mcast, dropped, errors, bytes;
+ int i;
+
+ /* Get RX stats. */
+ pkts = mcast = dropped = errors = bytes = 0;
+ for (i = 0; i < qdev->rss_ring_count; i++, rx_ring++) {
+ pkts += rx_ring->rx_packets;
+ bytes += rx_ring->rx_bytes;
+ dropped += rx_ring->rx_dropped;
+ errors += rx_ring->rx_errors;
+ mcast += rx_ring->rx_multicast;
+ }
+ ndev->stats.rx_packets = pkts;
+ ndev->stats.rx_bytes = bytes;
+ ndev->stats.rx_dropped = dropped;
+ ndev->stats.rx_errors = errors;
+ ndev->stats.multicast = mcast;
+
+ /* Get TX stats. */
+ pkts = errors = bytes = 0;
+ for (i = 0; i < qdev->tx_ring_count; i++, tx_ring++) {
+ pkts += tx_ring->tx_packets;
+ bytes += tx_ring->tx_bytes;
+ errors += tx_ring->tx_errors;
+ }
+ ndev->stats.tx_packets = pkts;
+ ndev->stats.tx_bytes = bytes;
+ ndev->stats.tx_errors = errors;
return &ndev->stats;
}
--
1.6.0.2
^ permalink raw reply related
* [net-next PATCH 2/3] qlge: Add firmware/driver sub-command support.
From: Ron Mercer @ 2009-11-03 23:49 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
In-Reply-To: <1257292171-11683-1-git-send-email-ron.mercer@qlogic.com>
These sub-commands are issued by another (FCoE) function requesting
an operation on a shared resource.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge.h | 12 +++++++++
drivers/net/qlge/qlge_mpi.c | 56 +++++++++++++++++++++++++++++++++++++-----
2 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/drivers/net/qlge/qlge.h b/drivers/net/qlge/qlge.h
index 872e95e..5e4d343 100644
--- a/drivers/net/qlge/qlge.h
+++ b/drivers/net/qlge/qlge.h
@@ -816,6 +816,18 @@ enum {
MB_CMD_GET_MGMNT_TFK_CTL = 0x00000161, /* Get Mgmnt Traffic Control */
MB_GET_MPI_TFK_STOPPED = (1 << 0),
MB_GET_MPI_TFK_FIFO_EMPTY = (1 << 1),
+ /* Sub-commands for IDC request.
+ * This describes the reason for the
+ * IDC request.
+ */
+ MB_CMD_IOP_NONE = 0x0000,
+ MB_CMD_IOP_PREP_UPDATE_MPI = 0x0001,
+ MB_CMD_IOP_COMP_UPDATE_MPI = 0x0002,
+ MB_CMD_IOP_PREP_LINK_DOWN = 0x0010,
+ MB_CMD_IOP_DVR_START = 0x0100,
+ MB_CMD_IOP_FLASH_ACC = 0x0101,
+ MB_CMD_IOP_RESTART_MPI = 0x0102,
+ MB_CMD_IOP_CORE_DUMP_MPI = 0x0103,
/* Mailbox Command Status. */
MB_CMD_STS_GOOD = 0x00004000, /* Success. */
diff --git a/drivers/net/qlge/qlge_mpi.c b/drivers/net/qlge/qlge_mpi.c
index bac7b86..f5619fe 100644
--- a/drivers/net/qlge/qlge_mpi.c
+++ b/drivers/net/qlge/qlge_mpi.c
@@ -1038,8 +1038,11 @@ void ql_mpi_idc_work(struct work_struct *work)
int status;
struct mbox_params *mbcp = &qdev->idc_mbc;
u32 aen;
+ int timeout;
+ rtnl_lock();
aen = mbcp->mbox_out[1] >> 16;
+ timeout = (mbcp->mbox_out[1] >> 8) & 0xf;
switch (aen) {
default:
@@ -1047,22 +1050,61 @@ void ql_mpi_idc_work(struct work_struct *work)
"Bug: Unhandled IDC action.\n");
break;
case MB_CMD_PORT_RESET:
- case MB_CMD_SET_PORT_CFG:
case MB_CMD_STOP_FW:
ql_link_off(qdev);
+ case MB_CMD_SET_PORT_CFG:
/* Signal the resulting link up AEN
* that the frame routing and mac addr
* needs to be set.
* */
set_bit(QL_CAM_RT_SET, &qdev->flags);
- rtnl_lock();
- status = ql_mb_idc_ack(qdev);
- rtnl_unlock();
- if (status) {
- QPRINTK(qdev, DRV, ERR,
- "Bug: No pending IDC!\n");
+ /* Do ACK if required */
+ if (timeout) {
+ status = ql_mb_idc_ack(qdev);
+ if (status)
+ QPRINTK(qdev, DRV, ERR,
+ "Bug: No pending IDC!\n");
+ } else {
+ QPRINTK(qdev, DRV, DEBUG,
+ "IDC ACK not required\n");
+ status = 0; /* success */
+ }
+ break;
+
+ /* These sub-commands issued by another (FCoE)
+ * function are requesting to do an operation
+ * on the shared resource (MPI environment).
+ * We currently don't issue these so we just
+ * ACK the request.
+ */
+ case MB_CMD_IOP_RESTART_MPI:
+ case MB_CMD_IOP_PREP_LINK_DOWN:
+ /* Drop the link, reload the routing
+ * table when link comes up.
+ */
+ ql_link_off(qdev);
+ set_bit(QL_CAM_RT_SET, &qdev->flags);
+ /* Fall through. */
+ case MB_CMD_IOP_DVR_START:
+ case MB_CMD_IOP_FLASH_ACC:
+ case MB_CMD_IOP_CORE_DUMP_MPI:
+ case MB_CMD_IOP_PREP_UPDATE_MPI:
+ case MB_CMD_IOP_COMP_UPDATE_MPI:
+ case MB_CMD_IOP_NONE: /* an IDC without params */
+ /* Do ACK if required */
+ if (timeout) {
+ status = ql_mb_idc_ack(qdev);
+ if (status)
+ QPRINTK(qdev, DRV, ERR,
+ "Bug: No pending IDC!\n");
+ } else {
+ QPRINTK(qdev, DRV, DEBUG,
+ "IDC ACK not required\n");
+ status = 0; /* success */
}
+ break;
}
+ rtnl_unlock();
}
void ql_mpi_work(struct work_struct *work)
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Paul E. McKenney @ 2009-11-03 23:57 UTC (permalink / raw)
To: Gregory Haskins
Cc: Eric Dumazet, Michael S. Tsirkin, netdev, virtualization, kvm,
linux-kernel, mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze
In-Reply-To: <4AF072EE.9020202@gmail.com>
On Tue, Nov 03, 2009 at 01:14:06PM -0500, Gregory Haskins wrote:
> Gregory Haskins wrote:
> > Eric Dumazet wrote:
> >> Michael S. Tsirkin a écrit :
> >>> +static void handle_tx(struct vhost_net *net)
> >>> +{
> >>> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
> >>> + unsigned head, out, in, s;
> >>> + struct msghdr msg = {
> >>> + .msg_name = NULL,
> >>> + .msg_namelen = 0,
> >>> + .msg_control = NULL,
> >>> + .msg_controllen = 0,
> >>> + .msg_iov = vq->iov,
> >>> + .msg_flags = MSG_DONTWAIT,
> >>> + };
> >>> + size_t len, total_len = 0;
> >>> + int err, wmem;
> >>> + size_t hdr_size;
> >>> + struct socket *sock = rcu_dereference(vq->private_data);
> >>> + if (!sock)
> >>> + return;
> >>> +
> >>> + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
> >>> + if (wmem >= sock->sk->sk_sndbuf)
> >>> + return;
> >>> +
> >>> + use_mm(net->dev.mm);
> >>> + mutex_lock(&vq->mutex);
> >>> + vhost_no_notify(vq);
> >>> +
> >> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
> >> that your use of RCU is not correct.
> >>
> >> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
> >> we are not allowed to sleep in such a section.
> >> (Quoting Documentation/RCU/whatisRCU.txt :
> >> It is illegal to block while in an RCU read-side critical section, )
> >>
> >> 2) mutex_lock() can sleep (ie block)
> >>
> >
> >
> > Michael,
> > I warned you that this needed better documentation ;)
> >
> > Eric,
> > I think I flagged this once before, but Michael convinced me that it
> > was indeed "ok", if but perhaps a bit unconventional. I will try to
> > find the thread.
> >
> > Kind Regards,
> > -Greg
> >
>
> Here it is:
>
> http://lkml.org/lkml/2009/8/12/173
What was happening in that case was that the rcu_dereference()
was being used in a workqueue item. The role of rcu_read_lock()
was taken on be the start of execution of the workqueue item, of
rcu_read_unlock() by the end of execution of the workqueue item, and
of synchronize_rcu() by flush_workqueue(). This does work, at least
assuming that flush_workqueue() operates as advertised, which it appears
to at first glance.
The above code looks somewhat different, however -- I don't see
handle_tx() being executed in the context of a work queue. Instead
it appears to be in an interrupt handler.
So what is the story? Using synchronize_irq() or some such?
Thanx, Paul
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [atl1-devel] [Bugme-new] [Bug 14431] New: atl1 eth0 link continuously down up
From: J. K. Cliburn @ 2009-11-04 0:19 UTC (permalink / raw)
To: Andrew Morton
Cc: atl1-devel, netdev, johan_vdp, bugzilla-daemon, bugme-daemon
In-Reply-To: <20091102224018.e306b12f.akpm@linux-foundation.org>
On Nov 3, 2009, at 12:40 AM, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not
> via the
> bugzilla web interface).
>
> On Sat, 17 Oct 2009 19:17:38 GMT bugzilla-
> daemon@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=14431
>>
>> Summary: atl1 eth0 link continuously down up
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.30.8-64.fc11.x86_64
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Network
>> AssignedTo: drivers_network@kernel-bugs.osdl.org
>> ReportedBy: johan_vdp@hotmail.com
>> Regression: No
>>
>>
>> /var/log/messages shows
>> ..
>> Oct 17 21:06:01 blauw kernel: atl1 0000:01:00.0: eth0 link is down
>> Oct 17 21:06:01 blauw kernel: atl1 0000:01:00.0: eth0 link is up
>> 100 Mbps full
>> duplex
Strange. This driver hasn't been changed in quite some time and it's
very stable. I'm running Fedora 11 and I don't see the problem at all.
I note that your NIC is autonegotiating to only 100 Mbps instead of
1000 Mbps; is your switch a 100 Mbps device?
Out of curiosity, are you running with or without NetworkManager active?
Increase the verbosity of driver messages and see if any additional
light is shed on the subject.
ethtool -s eth0 msglvl 0xffff
Jay Cliburn
^ permalink raw reply
* RE: Subject: [PATCH 1/6] bna: Brocade 10Gb Ethernet device driver
From: Joe Perches @ 2009-11-04 0:31 UTC (permalink / raw)
To: Rasesh Mody
Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team,
Greg Kroah-Hartman
In-Reply-To: <CBE1CC7A31453F4CA63C13EFCE6A0F6C05BAC64093@HQ-EXCH-7.corp.brocade.com>
On Tue, 2009-11-03 at 10:24 -0800, Rasesh Mody wrote:
> Joe,
> Thanks for your input. We are in the process addressing the comments that we are getting.
Hi Rasesh.
Thanks for bringing this out to netdev.
I think that with a few hours of cleanup, the code
would be more linux style conforming. But right now,
it looks a bit odd with too many indirections.
> Can you please give examples or elaborate your comment? It would be really helpful.
OS dependent includes? Most of them are senseless.
All of bfa_os_inc.h should go elsewhere or be dropped.
All of bna_os should go elsewhere or be dropped.
drop all bna_os_ prefixes
drop all bfa_os_ntohs, etc:
sed -r -i -e 's/\bbfa_os_(nh)to(nh)(sl)\b/\1to\2\3/g' *
Redefine true/false? why?
sed -r -i -e 's/\bbfa_boolean_t\b/bool/g' *
sed -r -i -e 's/\bBFA_TRUE\b/true/g' *
sed -r -i -e 's/\bBFA_FALSE\b/false/g' *
Don't suffix struct names with _s
sed -r -i -e 's/\bstruct\b\s+(\w+)\s+(\w+)_s/struct \1 \2/g' *
bfa_panic -> bfa_os_panic -> nothing
a laundry list like that...
I think it should go into staging for a few weeks, and then
it would be ready to be integrated into a mainline release.
cheers, Joe
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Alan Cox @ 2009-11-04 0:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911040052.28323.bzolnier@gmail.com>
On Wed, 4 Nov 2009 00:52:28 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > and I am very happy you were interested in fixing it.
> > >
> > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> >
> > Really - you have a service and support contract with Ivo.. no i thought
> > not.
>
> Just today I got PM from somebody complaining to me about non-working
> pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> I fixed some bug there some time ago....
And didn't bother committing a patch to both sets of code bec
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-04 0:48 UTC (permalink / raw)
To: Alan Cox
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <20091104004015.23c4c1a3@lxorguk.ukuu.org.uk>
On Wednesday 04 November 2009 01:40:15 Alan Cox wrote:
> On Wed, 4 Nov 2009 00:52:28 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> > On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > > and I am very happy you were interested in fixing it.
> > > >
> > > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> > >
> > > Really - you have a service and support contract with Ivo.. no i thought
> > > not.
> >
> > Just today I got PM from somebody complaining to me about non-working
> > pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> > I fixed some bug there some time ago....
>
> And didn't bother committing a patch to both sets of code bec
You misread my mail.
Because I also fixed bug in the PATA code though I was IDE Maintainer.
Also:
Did you have a service & support contract with me when you were complaining
about IDE to me? [ and I would strongly suggest you not to go there.. ]
Or reversing the initial question:
Does Ivo have a contract with me to contribute to rt2x00 project?
So please stop idiotic arguments.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Julian Calaby @ 2009-11-04 1:33 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Gertjan van Wingerde, Ivo van Doorn,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911040046.54247.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> If you just want to continue with a hostile take-over of the rt2800
>> maintainership, then please
>> let us know that, so that we stop spending time on useless
>
> I fail to see why you see it as a hostile takeover.
Updating MAINTAINERS to replace the current developers with yourself
can be considered to be a hostile act.
If you want this for your own personal tree, then keep the patch
private - don't include it in pull requests, patch listings etc.
And if you genuinely want the maintainership of the rt28xx drivers,
then updating MAINTAINERS should be done as an afterthought after
clearly proving that you are capable of maintaining the driver and
working with the maintainers of the rt2x00 and wireless subsystems.
> I will be glad to cooperate with you or anyone else from rt2x00 project.
> However I will not spin in some stupid bureaucracy when I see that things
> can be done more effectively.
It's not "stupid bureaucracy" it's *how* *it's* *done*.
If I was going to submit a patch to the Marvell TOPDOG driver to add
support for another related chipset, I'd be going out of my way to
make sure that *everyone* involved was 100% happy so that the patch
can get out to the people who matter: the users.
Everyone has to do this, from big corporations like Intel, to you and
me. For example, I recall the Intel IWL developers being smacked down
a few months ago by John and David over exactly what constitutes a
post-merge window "bugfix".
The rules apply to everyone, just because you don't like them doesn't
mean you can ignore them.
Thanks,
--
Julian Calaby
Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] trivial: remove duplicated MIN macro from tehuti.
From: Yang Hongyang @ 2009-11-04 1:36 UTC (permalink / raw)
To: Thiago Farina
Cc: trivial, baum, andy, davem, shemminger, apkm, ben, netdev,
linux-kernel
In-Reply-To: <1257194714-5218-1-git-send-email-tfransosi@gmail.com>
Thiago Farina wrote:
> Since the kernel api already has the macro "min",
> just use it instead of declaring another one.
>
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
> ---
> drivers/net/tehuti.c | 4 ++--
> drivers/net/tehuti.h | 2 --
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c
> index ec9dfb2..8d116a9 100644
> --- a/drivers/net/tehuti.c
> +++ b/drivers/net/tehuti.c
> @@ -1878,7 +1878,7 @@ static void bdx_tx_push_desc_safe(struct bdx_priv *priv, void *data, int size)
> udelay(50); /* give hw a chance to clean fifo */
> continue;
> }
> - avail = MIN(avail, size);
> + avail = min(avail, size);
> DBG("about to push %d bytes starting %p size %d\n", avail,
> data, size);
> bdx_tx_push_desc(priv, data, avail);
> @@ -1889,7 +1889,7 @@ static void bdx_tx_push_desc_safe(struct bdx_priv *priv, void *data, int size)
> }
>
> static const struct net_device_ops bdx_netdev_ops = {
> - .ndo_open = bdx_open,
> + .ndo_open = bdx_open,
Why are you change TAB to SPACES here?
> .ndo_stop = bdx_close,
> .ndo_start_xmit = bdx_tx_transmit,
> .ndo_validate_addr = eth_validate_addr,
> diff --git a/drivers/net/tehuti.h b/drivers/net/tehuti.h
> index 4fc875e..1241419 100644
> --- a/drivers/net/tehuti.h
> +++ b/drivers/net/tehuti.h
> @@ -76,8 +76,6 @@
> #define FIFO_SIZE 4096
> #define FIFO_EXTRA_SPACE 1024
>
> -#define MIN(x, y) ((x) < (y) ? (x) : (y))
> -
> #if BITS_PER_LONG == 64
> # define H32_64(x) (u32) ((u64)(x) >> 32)
> # define L32_64(x) (u32) ((u64)(x) & 0xffffffff)
--
Regards
Yang Hongyang
^ permalink raw reply
* kernel WARNING/BUG with IOMMU + skb_dma_map/unmap + pktgen
From: Alexander Duyck @ 2009-11-04 1:44 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Tantilov, Emil S, davem@davemloft.net, dwmw2
It looks like skb_dma_map/unmap plus trying to transmit multiple copies
of the same skb via pktgen doesn't work when a hardware IOMMU is enabled.
We first saw this on igb doing a loopback test partially due to the fact
that I had copied the approach used by pktgen of just incrementing the
user count and sending the same skb into the transmit path multiple
times. However we did some testing to verify that this is reproducible
on other NICs using skb_dma_map/unmap and pktgen and generated the
traces below on a tg3 w/ pktgen configured to clone_skb several times.
The issue seems to be due to the fact that skb_dma_map assumes that
dma_map_single/page should return the same value every time it is
called, however in the case of having a hardware iommu enabled this is
not so and as a result we end up leaking dma mappings and then attempt
multiple unmaps on the last dma mapping we received.
I'm wondering if this is a valid issue since I am not sure how many
different situations will result in a skb being cloned and sent either
to the same device multiple times or to multiple devices. Also I am
looking for suggestions on how best to address this without negatively
impacting TX performance.
Thanks,
Alex
DRHD: handling fault status reg 2
DMAR:[DMA Read] Request device [05:00.0] fault addr ffb9c000
DMAR:[fault reason 06] PTE Read access is not set
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:798 check_unmap+0x158/0x5bf()
Hardware name: S5520HC
tg3 0000:05:00.0: DMA-API: device driver tries to free DMA memory it has
not allocated [device address=0x00000000ffb9c822] [size=1200 bytes]
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Not tainted
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
<IRQ> [<ffffffff811c2500>] ? check_unmap+0x158/0x5bf
[<ffffffff81046006>] warn_slowpath_common+0x77/0x8f
[<ffffffff810460ce>] warn_slowpath_fmt+0x9f/0xa1
[<ffffffff8137fca5>] ? _spin_lock_irqsave+0x44/0x50
[<ffffffff811c182f>] ? get_hash_bucket+0x28/0x33
[<ffffffff8106c648>] ? register_lock_class+0x20/0x29f
[<ffffffff811c2500>] check_unmap+0x158/0x5bf
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffff8100e020>] ? do_IRQ+0x97/0xae
[<ffffffff811c2b11>] debug_dma_unmap_page+0x80/0x92
[<ffffffff811dcea8>] ? intel_unmap_page+0xf6/0x103
[<ffffffff812e1dd9>] dma_unmap_single_attrs+0x5c/0x68
[<ffffffff812e2043>] skb_dma_unmap+0x3f/0x78
[<ffffffffa01a8890>] tg3_poll+0x172/0x77d [tg3]
[<ffffffff812e2f84>] ? rcu_read_lock+0x0/0x3a
[<ffffffff812e7ff1>] net_rx_action+0xbc/0x19f
[<ffffffff8104bcf1>] __do_softirq+0xd5/0x19d
[<ffffffff8100cc9c>] call_softirq+0x1c/0x34
<EOI> [<ffffffff8100e2d8>] do_softirq+0x33/0x6b
[<ffffffff8104b541>] _local_bh_enable_ip+0x78/0xa7
[<ffffffff8104b579>] local_bh_enable_ip+0x9/0xb
[<ffffffff8137f9a2>] _spin_unlock_bh+0x39/0x3d
[<ffffffffa004a2c3>] pktgen_xmit+0xf5f/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
---[ end trace 39dadbc5c44cf3fd ]---
------------[ cut here ]------------
WARNING: at drivers/pci/intel-iommu.c:2719 intel_unmap_page+0x8e/0x103()
Hardware name: S5520HC
Driver unmaps unmatched page at PFN ffb9c822
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Tainted: G W
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
<IRQ> [<ffffffff811dce40>] ? intel_unmap_page+0x8e/0x103
[<ffffffff81046006>] warn_slowpath_common+0x77/0x8f
[<ffffffff810460ce>] warn_slowpath_fmt+0x9f/0xa1
[<ffffffff811dac28>] ? find_iova+0x18/0x66
[<ffffffff8137fa55>] ? _spin_unlock_irqrestore+0x57/0x5c
[<ffffffff811dac6b>] ? find_iova+0x5b/0x66
[<ffffffff811dce40>] intel_unmap_page+0x8e/0x103
[<ffffffff812e1dc3>] dma_unmap_single_attrs+0x46/0x68
[<ffffffff812e2043>] skb_dma_unmap+0x3f/0x78
[<ffffffffa01a8890>] tg3_poll+0x172/0x77d [tg3]
[<ffffffff812e2f84>] ? rcu_read_lock+0x0/0x3a
[<ffffffff812e7ff1>] net_rx_action+0xbc/0x19f
[<ffffffff8104bcf1>] __do_softirq+0xd5/0x19d
[<ffffffff8100cc9c>] call_softirq+0x1c/0x34
<EOI> [<ffffffff8100e2d8>] do_softirq+0x33/0x6b
[<ffffffff8104b541>] _local_bh_enable_ip+0x78/0xa7
[<ffffffff8104b579>] local_bh_enable_ip+0x9/0xb
[<ffffffff8137f9a2>] _spin_unlock_bh+0x39/0x3d
[<ffffffffa004a2c3>] pktgen_xmit+0xf5f/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
---[ end trace 39dadbc5c44cf3fe ]---
------------[ cut here ]------------
kernel BUG at drivers/pci/iova.c:155!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file:
/sys/devices/pci0000:00/0000:00:1e.0/0000:0a:00.0/local_cpus
CPU 0
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Tainted: G W
2.6.32-rc3-net-next-igb-tag110309 #12 S5520HC
RIP: 0010:[<ffffffff811db065>] [<ffffffff811db065>] alloc_iova+0x174/0x1d7
RSP: 0018:ffff88036570fac0 EFLAGS: 00010046
RAX: 00000000000ffb9b RBX: ffff8801e78d4180 RCX: 0000000000000000
RDX: ffff8801e73ba710 RSI: ffff8801e73ba700 RDI: 0000000000000001
RBP: ffff88036570fb20 R08: 0000000000000000 R09: ffff880100000000
R10: ffffffff811daf48 R11: 0000fffffffff000 R12: 00000000000ffb9b
R13: 0000000000000001 R14: ffff8801e5cad520 R15: ffff8801e73ba700
FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00007fef515530a0 CR3: 0000000001001000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kpktgend_0 (pid: 8701, threadinfo ffff88036570e000, task
ffff8803661d3fc0)
Stack:
ffffffff81e5a328 ffffffff81e5a310 00000000000fffff 0000000000000286
<0> 01ff8801e88de890 ffffffff81e5a310 ffff8801e78d4180 ffff8801e88de890
<0> 0000fffffffff000 ffff8801e5cad500 0000000000000001 ffff8801e88de890
Call Trace:
[<ffffffff811dd992>] intel_alloc_iova+0x68/0xb4
[<ffffffff811ddc3a>] __intel_map_single+0x7d/0x152
[<ffffffff811ddd0f>] ? intel_map_page+0x0/0x3e
[<ffffffff811ddd4b>] intel_map_page+0x3c/0x3e
[<ffffffff812e1e77>] skb_dma_map+0x92/0x21f
[<ffffffff81039012>] ? finish_task_switch+0x7c/0x9e
[<ffffffffa01a6976>] tg3_start_xmit_dma_bug+0x37f/0x7cd [tg3]
[<ffffffffa004a1ef>] ? pktgen_xmit+0xe8b/0xfe3 [pktgen]
[<ffffffffa004a230>] pktgen_xmit+0xecc/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
Code: 05 ff 49 89 47 18 48 83 7d d0 00 75 04 49 8d 56 30 31 c0 eb 1d 48
8b 46 20 48 8d 56 10 49 39 47 20 72 0c 76 06 48 8d 56 08 eb 04 <0f> 0b
eb fe 48 89 f0 48 8b 32 48 85 f6 75 db 48 89 c6 4c 89 ff
RIP [<ffffffff811db065>] alloc_iova+0x174/0x1d7
RSP <ffff88036570fac0>
---[ end trace 39dadbc5c44cf3ff ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 8701, comm: kpktgend_0 Tainted: G D W
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
[<ffffffff810461c4>] panic+0xe5/0x195
[<ffffffff8137fa4c>] ? _spin_unlock_irqrestore+0x4e/0x5c
[<ffffffff81046860>] ? release_console_sem+0x19e/0x1ab
[<ffffffff81046a8b>] ? console_unblank+0x65/0x69
[<ffffffff81045e36>] ? print_oops_end_marker+0x1e/0x20
[<ffffffff81380d8f>] oops_end+0xaa/0xba
[<ffffffff8100f41d>] die+0x55/0x5e
[<ffffffff813806b2>] do_trap+0x110/0x11f
[<ffffffff8100d4bb>] do_invalid_op+0x91/0x9a
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff8137faa4>] ? _spin_unlock+0x4a/0x57
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffff8100c935>] invalid_op+0x15/0x20
[<ffffffff811daf48>] ? alloc_iova+0x57/0x1d7
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff811dd992>] intel_alloc_iova+0x68/0xb4
[<ffffffff811ddc3a>] __intel_map_single+0x7d/0x152
[<ffffffff811ddd0f>] ? intel_map_page+0x0/0x3e
[<ffffffff811ddd4b>] intel_map_page+0x3c/0x3e
[<ffffffff812e1e77>] skb_dma_map+0x92/0x21f
[<ffffffff81039012>] ? finish_task_switch+0x7c/0x9e
[<ffffffffa01a6976>] tg3_start_xmit_dma_bug+0x37f/0x7cd [tg3]
[<ffffffffa004a1ef>] ? pktgen_xmit+0xe8b/0xfe3 [pktgen]
[<ffffffffa004a230>] pktgen_xmit+0xecc/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
------------[ cut here ]------------
WARNING: at arch/x86/kernel/smp.c:117 native_smp_send_reschedule+0x25/0x43()
Hardware name: S5520HC
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Tainted: G D W
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
<IRQ> [<ffffffff81034a05>] ? __enqueue_entity+0x74/0x76
[<ffffffff8101eefc>] ? native_smp_send_reschedule+0x25/0x43
[<ffffffff81046006>] warn_slowpath_common+0x77/0x8f
[<ffffffff8104602d>] warn_slowpath_null+0xf/0x11
[<ffffffff8101eefc>] native_smp_send_reschedule+0x25/0x43
[<ffffffff8102ff5d>] smp_send_reschedule+0xa/0xc
[<ffffffff810324ea>] resched_task+0x67/0x6c
[<ffffffff81032585>] check_preempt_curr_idle+0x10/0x12
[<ffffffff81030056>] check_preempt_curr+0x12/0x14
[<ffffffff8103dfbf>] try_to_wake_up+0x249/0x2b2
[<ffffffff8103e035>] default_wake_function+0xd/0xf
[<ffffffff8105e6a4>] autoremove_wake_function+0x11/0x38
[<ffffffff81030bad>] __wake_up_common+0x41/0x74
[<ffffffff810341d8>] __wake_up+0x38/0x4f
[<ffffffff810468c0>] printk_tick+0x53/0x58
[<ffffffff81051f13>] update_process_times+0x3e/0x54
[<ffffffff8106b278>] tick_sched_timer+0x70/0x99
[<ffffffff8106b208>] ? tick_sched_timer+0x0/0x99
[<ffffffff81061101>] __run_hrtimer+0xba/0x121
[<ffffffff8106125e>] hrtimer_interrupt+0xf6/0x152
[<ffffffff81096d71>] ? rcu_irq_enter+0x15/0x63
[<ffffffff81020124>] smp_apic_timer_interrupt+0x73/0x87
[<ffffffff8100c673>] apic_timer_interrupt+0x13/0x20
<EOI> [<ffffffff81382434>] ? __atomic_notifier_call_chain+0x0/0xb2
[<ffffffff81382434>] ? __atomic_notifier_call_chain+0x0/0xb2
[<ffffffff81046252>] ? panic+0x173/0x195
[<ffffffff810461e6>] ? panic+0x107/0x195
[<ffffffff8137fa4c>] ? _spin_unlock_irqrestore+0x4e/0x5c
[<ffffffff81046860>] ? release_console_sem+0x19e/0x1ab
[<ffffffff81046a8b>] ? console_unblank+0x65/0x69
[<ffffffff81045e36>] ? print_oops_end_marker+0x1e/0x20
[<ffffffff81380d8f>] ? oops_end+0xaa/0xba
[<ffffffff8100f41d>] ? die+0x55/0x5e
[<ffffffff813806b2>] ? do_trap+0x110/0x11f
[<ffffffff8100d4bb>] ? do_invalid_op+0x91/0x9a
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff8137faa4>] ? _spin_unlock+0x4a/0x57
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffff8100c935>] ? invalid_op+0x15/0x20
[<ffffffff811daf48>] ? alloc_iova+0x57/0x1d7
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff811dd992>] ? intel_alloc_iova+0x68/0xb4
[<ffffffff811ddc3a>] ? __intel_map_single+0x7d/0x152
[<ffffffff811ddd0f>] ? intel_map_page+0x0/0x3e
[<ffffffff811ddd4b>] ? intel_map_page+0x3c/0x3e
[<ffffffff812e1e77>] ? skb_dma_map+0x92/0x21f
[<ffffffff81039012>] ? finish_task_switch+0x7c/0x9e
[<ffffffffa01a6976>] ? tg3_start_xmit_dma_bug+0x37f/0x7cd [tg3]
[<ffffffffa004a1ef>] ? pktgen_xmit+0xe8b/0xfe3 [pktgen]
[<ffffffffa004a230>] ? pktgen_xmit+0xecc/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] ? pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] ? kthread+0x69/0x71
[<ffffffff8100cb9a>] ? child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
---[ end trace 39dadbc5c44cf400 ]---
^ permalink raw reply
* Re: [PATCH] sch_htb.c consume the classes's tokens bellow the HTB_CAN_SEND level
From: Changli Gao @ 2009-11-04 1:53 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Jamal Hadi Salim, devik, netdev
In-Reply-To: <20091103230035.GA2352@ami.dom.local>
On Wed, Nov 4, 2009 at 7:00 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On Tue, Nov 03, 2009 at 09:18:49PM +0800, Changli Gao wrote:
>> On Tue, Nov 3, 2009 at 6:05 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
>> >
>> > The ceil specification is controlled only by ctokens, which are always
>> > updated, so no such risk.
>> >
>> Nevertheless, updating tokens is necessary too.
>
> If it's really necessary you should present some test case fixed by
> your patch, I guess.
>
> In the meantime let's consider what could be broken:
> class 1:1 (parent) rate 10 packets/sec
> class 1:2 rate 5 packets/sec ceil 10 packets/sec
> class 1:3 rate 5 packets/sec ceil 10 packets/sec
>
> class 1:2 doesn't use all its rate, and sends every other second
> (in even seconds)
> class 1:3 sends 10 packets during the first second, so with your
> patch it will use its tokens for 2 seconds
> class 1:2 uses its rate in the second second..., so class 1:1
> can't lend anything
> class 1:3 can only borrow, so it won't be able to send during
> this second anything
>
> So, the effect would be class 1:3 sending every odd second 10 packets
> while every even second - nothing...
class 1:3 can send, as its parent rate is 10, but class 1:2 only uses
half of it, and class 1:1 is still in HTB_CAN_SEND mode.
The result is, hasn't any difference with or without my patch :
class 1:1 sends 10 packets in odd seconds, and 5 packets in even seconds.
class 1:2 sends 5 packets in even seconds.
class 1:1 (parent) sends 10 packets in every second.
Let's think this case in another way: which class sends packets in
even seconds first, class 1:2 or class 1:3.
With my patch, as 1:3 in HTB_MAY_BORROW mode, and 1:2 in HTB_CAN_SEND
mode, so 1:2 sends all its 5 packets first.
Without my patch, as 1:2 and 1:3 are both in HTB_CAN_SEND mode, the
sequence is undetermined. In other word, 1:2 and 1:3 are treated
fairly, and it isn't fair for 1:2, because 1:2 sends nothing in odd
seconds, and has no deficit in rate as 1:3.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: Valdis.Kletnieks @ 2009-11-04 2:01 UTC (permalink / raw)
To: Ilpo JÀrvinen
Cc: Gilad Ben-Yossef, Eric Dumazet, Andrew Morton, linux-kernel,
netdev, Ori Finkelman
In-Reply-To: <Pine.LNX.4.64.0911032330090.3488@melkinkari.cs.Helsinki.FI>
[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]
On Tue, 03 Nov 2009 23:34:19 +0200, Ilpo JÀrvinen said:
> On Tue, 3 Nov 2009, Gilad Ben-Yossef wrote:
>
> > Eric Dumazet wrote:
> >
> > > Valdis.Kletnieks@vt.edu a écrit :
> > >
> > > > Seen right after I started 'fetchmail'. Reproducible - 3 out of 3.
> > > > I'll bisect this tonight if nobody jumps up and yells they know what it
> > > > is...
> > > >
> > Bah... this is most probably my fault. Sorry about that.
> >
> > Can you please try the patch in the next email?
Tried while at home, machine panic'ed. No netconsole here at the moment, sorry.
> > But also, can you please send me the route table in effect when this happened
> > and the fetchmail command line/config (removing any passwords or account
> > details of course)? I want to understand better when this happens.
% route -n -A inet
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
128.173.12.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 128.173.12.1 0.0.0.0 UG 0 0 0 eth0
% route -n -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 687 1 lo
2001:468:c80:2103:215:c5ff:fec8:334e/128 :: U 0 53533 1 lo
2001:468:c80:2103::/64 :: UA 256 316 0 eth0
fe80::215:c5ff:fec8:334e/128 :: U 0 176 1 lo
fe80::218:deff:fe9c:24e0/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 wlan0
ff02::1/128 ff02::1 UC 0 451 0 eth0
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 wlan0
::/0 fe80::20f:35ff:fe3e:d41a UGDA 1024 2082 1 eth0
Command line was just 'fetchmail'. Relevant .fetchmailrc:
set postmaster "valdis"
set bouncemail
set no spambounce
set properties ""
set daemon 240
poll imap.vt.edu with proto IMAP and options
user 'valdis' there with password 'redacted' is 'valdis' here ssl fetchsizelimit 0 smtpaddress turing-police.cc.vt.edu
(imap.vt.edu is 198.82.183.77 - so off the local subnet)
> According to the stacktrace, it came from ipv6 side which doesn't have any
> null checking what so ever atm (you only handled ipv4 correctly). ...You
> should be a bit more careful next time when adding any BUG_ONs...
Why was this blowing chunks in the IPv6 when I was making an IPv4 connection
then? I just noticed that. My fetchmail can't make an IPv6 TCP connection to
our IMAP server because the server isn't v6-enabled yet. And although I
contact our DNS over IPv6, but that's UDP not TCP.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Karol Lewandowski @ 2009-11-04 2:03 UTC (permalink / raw)
To: Mel Gorman
Cc: Karol Lewandowski, Frans Pop, Jiri Kosina, Sven Geggus,
Tobias Oetiker, Rafael J. Wysocki, David Miller, Reinette Chatre,
Kalle Valo, David Rientjes, KOSAKI Motohiro, Mohamed Abbas,
Jens Axboe, John W. Linville, Pekka Enberg,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
In-Reply-To: <20091102203034.GC22046-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
On Mon, Nov 02, 2009 at 08:30:34PM +0000, Mel Gorman wrote:
> Does applying the following on top make any difference?
>
> ==== CUT HERE ====
> PM: Shrink memory before suspend
No, this patch didn't change anything either.
IIRC I get failures while free(1) shows as much as 20MB free RAM
(ie. without buffers/caches). Additionaly nr_free_pages (from
/proc/vmstat) stays at about 800-1000 under heavy memory pressure
(gitk on full linux repository).
--- babbling follows ---
Hmm, I wonder if it's really timing issue then wouldn't be the case
that lowering swappiness sysctl would make problem more visible?
I've vm.swappiness=15, would testing with higher value make any sense?
Thanks.
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-04 2:28 UTC (permalink / raw)
To: Julian Calaby
Cc: Gertjan van Wingerde, Ivo van Doorn, linux-wireless, linux-kernel,
netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <646765f40911031733u1641c0dr5d4eec30031e7cea@mail.gmail.com>
On Wednesday 04 November 2009 02:33:52 Julian Calaby wrote:
> On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> If you just want to continue with a hostile take-over of the rt2800
> >> maintainership, then please
> >> let us know that, so that we stop spending time on useless
> >
> > I fail to see why you see it as a hostile takeover.
>
> Updating MAINTAINERS to replace the current developers with yourself
> can be considered to be a hostile act.
>
> If you want this for your own personal tree, then keep the patch
> private - don't include it in pull requests, patch listings etc.
This is not pull request etc. but since the change in question has been
stirring needless controversies and distracting people from reading patches
it has been dropped for now.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: kernel WARNING/BUG with IOMMU + skb_dma_map/unmap + pktgen
From: David Miller @ 2009-11-04 2:32 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, emil.s.tantilov, dwmw2
In-Reply-To: <4AF0DC81.10305@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 03 Nov 2009 17:44:33 -0800
> It looks like skb_dma_map/unmap plus trying to transmit multiple
> copies of the same skb via pktgen doesn't work when a hardware IOMMU
> is enabled.
This is just the tip of the iceburg as to why pktgen's scheme
to send the same SKB over and over again doesn't really work.
If it's referenced by a transmit, you really can't reuse it
again in the transmit path, even TCP has code that copies
when a SKB has a device reference on the transmit path.
I think we've just been lucky until now about this, as pktgen
doesn't usually attach other forms of shared state such as
netfilter conntrack info, and it doesn't care about the header
being mangled by the driver (since it emits pure UDP frames
this isn't likely to happen anyways).
But not with the SKB DMA map/unmap this becomes a real visible bug and
must be fixed.
^ permalink raw reply
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: David Miller @ 2009-11-04 2:34 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: ilpo.jarvinen, gilad, eric.dumazet, akpm, linux-kernel, netdev,
ori
In-Reply-To: <7916.1257300093@turing-police.cc.vt.edu>
From: Valdis.Kletnieks@vt.edu
Date: Tue, 03 Nov 2009 21:01:33 -0500
> Why was this blowing chunks in the IPv6 when I was making an IPv4 connection
> then? I just noticed that. My fetchmail can't make an IPv6 TCP connection to
> our IMAP server because the server isn't v6-enabled yet. And although I
> contact our DNS over IPv6, but that's UDP not TCP.
Many things IPV6 capable will go through the IPV4 compat
path of the IPV6 stack, depending upon how listening sockets
configure themselves etc.
^ permalink raw reply
* Re: HTB accuracy on 10GbE
From: Ryousei Takano @ 2009-11-04 3:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Patrick McHardy, Linux Netdev List, takano-ryousei
In-Reply-To: <20091102125345.3c39c42e@nehalam>
Hi Patrick and Stephen,
Thanks for your comments.
I retried on the newer kernel and iproute2, and added the experimental result
on my page. Please see 'Experimental result 2':
http://code.google.com/p/pspacer/wiki/HTBon10GbE
The accuracy improves compared with the previous experiment.
The difference reduces from +810 Mbps to +430 Mbps.
It is because the timer resolution improves from 1 usec to 1/64 usec.
But it is not perfect.
Best regards,
Ryousei Takano
On Tue, Nov 3, 2009 at 5:53 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Mon, 02 Nov 2009 16:43:42 +0100
> Patrick McHardy <kaber@trash.net> wrote:
>
>> Ryousei Takano wrote:
>> > Hi Stephen and all,
>> >
>> > I have observed a HTB accuracy problem on the Linux kernel 2.6.30 and
>> > the Myri-10G 10 GbE NIC.
>> > HTB can control the transmission rate at Gigabit speed, however it can
>> > not work well at 10 Gigabit speed.
>> >
>> > I asked Stephen this problem at Japan Linux Symposium. He mentioned a
>> > HTB bug related to the timer granularity.
>> > I want to know what is happen, and what should be do for fixing it.
>> >
>> > Any comments and suggestions will be welcome.
>> >
>> > For more detail, please see the following page:
>> > http://code.google.com/p/pspacer/wiki/HTBon10GbE
>>
>> This is not an easy problem to fix. Userspace, the kernel and the
>> netlink API use 32 bit for timing related values, which is too small
>> to use more than microsecond resolution. All of them need to be
>> converted to use bigger types, additionally some kind of compatibility
>> handling to deal with old iproute versions still using microsecond
>> resolution is required.
>
> The existing API is a legacy mish-mash. The field is limited to 32 bits,
> but it might be possible to use a finer scale.
>
> Maybe if kernel advertised finer resolution through /proc/net/psched
> then table could be finer grained. This would maintain compatibility
> between kernel and user space. You would need to have new kernel and
> new iproute to get nanosecond resolution but older combinations would
> still work.
>
> The downside is that by using nanosecond resolution the rates are upper
> bounded at 4.2seconds / packet.
>
>
^ permalink raw reply
* Re: [PATCH] usbnet: Do not implement ethtool get_link() if link state is unknown
From: Ben Hutchings @ 2009-11-04 3:20 UTC (permalink / raw)
To: David Miller; +Cc: david-b, greg, jacmet, steve.glendinning, netdev
In-Reply-To: <20091103.020444.120631587.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Tue, 2009-11-03 at 02:04 -0800, David Miller wrote:
> From: David Brownell <david-b@pacbell.net>
> Date: Tue, 3 Nov 2009 02:41:27 -0700
>
> > On Tuesday 03 November 2009, David Miller wrote:
> >> All kidding aside, I think the alternative is for the USB network
> >> driver to call ethtool_op_get_link() if it cannot determine the
> >> link state in hardware.
> >
> > There's usbnet_get_link() which does just that. But
> > there may be some ancient debris confusing things.
>
> It's perfect, and Ben's patch is completely unnecessary.
I don't see how it's 'perfect' since it reports the link as up where it
is really unknown. Still, this is a fairly minor bug.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ 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