* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Keith Packard @ 2011-02-04 1:05 UTC (permalink / raw)
To: Linus Torvalds, Dave Airlie
Cc: Linux SCSI List, Linux ACPI, Takashi Iwai, Carlos Mafra,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Rafael J. Wysocki, Florian Mickler, Network Development,
Dave Airlie, Andrew Morton, Kernel Testers List, Linux PM List,
Maciej Rutecki
In-Reply-To: <AANLkTimQPPDyBwkN0HWM2+bPcbzVd8YHZvn2iR8MVzfL@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4011 bytes --]
On Thu, 3 Feb 2011 16:30:56 -0800, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <airlied@gmail.com> wrote:
> >
> > If we are setting a mode on a connector it automatically will end up
> > in a DPMS on state,
> > so this seemed correct from what I can see.
>
> The more I look at that function, the more I disagree with you and
> with that patch.
>
> The code is just crazy.
>
> First off, it isn't even necessarily setting a mode to begin with,
> because as far as I can tell. If the mode doesn't change, neither
> mode_changed nor fb_changed will be true, afaik. There seems to be a
> fair amount of code there explicitly to avoid changing modes if not
> necessary.
>
> But even _if_ we are setting a mode, if I read the code correctly, the
> mode may be set to NULL - which seems to mean "turn it off". In which
> case it looks to me that drm_helper_disable_unused_functions() will
> actually do a
>
> (*crtc_funcs->dpms)(crtc, DRM_MODE_DPMS_OFF);
>
> call on the crtc in question. So then blindly just saying "it's mode
> DRM_MODE_DPMS_ON" afterwards looks rather bogus to me.
>
> _Maybe_ it would work if it was done before that whole
> "disable_unused" logic. Or maybe it should just be done in
> drm_crtc_helper_set_mode(), which is what actually sets the mode (but
> there's the 'fb_changed' case too)
>
> > A future mode set shouldn't ever not turn the connector on, since
> > modesetting is an implicit
> > DPMS,
> >
> > It sounds like something more subtle than that, though I'm happy to
> > revert this for now, and let Keith
> > think about it a bit more.
>
> So I haven't heard anything from Keith. Keith? Just revert it? Or do
> you have a patch for people to try?
The goal is to make it so that when you *do* set a mode, DPMS gets set
to ON (as the monitor will actually be "on" at that point). Here's a
patch which does the DPMS_ON precisely when setting a mode.
Dave thinks we should instead force dpms to match crtc->enabled, I'd
rather have dpms get set when we know the hardware has been changed.
(note, this patch compiles, but is otherwise only lightly tested).
From 38507bb3a67441425e11085d17d727f3b230f927 Mon Sep 17 00:00:00 2001
From: Keith Packard <keithp@keithp.com>
Date: Thu, 3 Feb 2011 16:57:28 -0800
Subject: [PATCH] drm: Only set DPMS ON when actually configuring a mode
In drm_crtc_helper_set_config, instead of always forcing all outputs
to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a
mode set, as any mode set will turn all outputs on.
Signed-off-by: Keith Packard <keithp@keithp.com>
---
drivers/gpu/drm/drm_crtc_helper.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 952b3d4..17459ee 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -665,6 +665,12 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
ret = -EINVAL;
goto fail;
}
+ DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
+ for (i = 0; i < set->num_connectors; i++) {
+ DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", set->connectors[i]->base.id,
+ drm_get_connector_name(set->connectors[i]));
+ set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+ }
}
drm_helper_disable_unused_functions(dev);
} else if (fb_changed) {
@@ -681,12 +687,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
goto fail;
}
}
- DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
- for (i = 0; i < set->num_connectors; i++) {
- DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", set->connectors[i]->base.id,
- drm_get_connector_name(set->connectors[i]));
- set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
- }
kfree(save_connectors);
kfree(save_encoders);
--
1.7.2.3
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Dave Airlie @ 2011-02-04 0:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carlos Mafra, Keith Packard, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTimQPPDyBwkN0HWM2+bPcbzVd8YHZvn2iR8MVzfL@mail.gmail.com>
On Fri, Feb 4, 2011 at 10:30 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <airlied@gmail.com> wrote:
>>
>> If we are setting a mode on a connector it automatically will end up
>> in a DPMS on state,
>> so this seemed correct from what I can see.
>
> The more I look at that function, the more I disagree with you and
> with that patch.
>
> The code is just crazy.
Good point, I'm just trying to get -rc3 onto a machine where I can
reproduce this now, unfortunately that looks like the machine with the
1.8" disk, so this could take a little while.
hopefully Keith will decloak and tell us more.
Dave.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-04 0:30 UTC (permalink / raw)
To: Dave Airlie
Cc: Carlos Mafra, Keith Packard, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTin7kBur95H=UBcYEcjYsUkrdG8znX-7PFZ4rrHf@mail.gmail.com>
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie <airlied@gmail.com> wrote:
>
> If we are setting a mode on a connector it automatically will end up
> in a DPMS on state,
> so this seemed correct from what I can see.
The more I look at that function, the more I disagree with you and
with that patch.
The code is just crazy.
First off, it isn't even necessarily setting a mode to begin with,
because as far as I can tell. If the mode doesn't change, neither
mode_changed nor fb_changed will be true, afaik. There seems to be a
fair amount of code there explicitly to avoid changing modes if not
necessary.
But even _if_ we are setting a mode, if I read the code correctly, the
mode may be set to NULL - which seems to mean "turn it off". In which
case it looks to me that drm_helper_disable_unused_functions() will
actually do a
(*crtc_funcs->dpms)(crtc, DRM_MODE_DPMS_OFF);
call on the crtc in question. So then blindly just saying "it's mode
DRM_MODE_DPMS_ON" afterwards looks rather bogus to me.
_Maybe_ it would work if it was done before that whole
"disable_unused" logic. Or maybe it should just be done in
drm_crtc_helper_set_mode(), which is what actually sets the mode (but
there's the 'fb_changed' case too)
> A future mode set shouldn't ever not turn the connector on, since
> modesetting is an implicit
> DPMS,
>
> It sounds like something more subtle than that, though I'm happy to
> revert this for now, and let Keith
> think about it a bit more.
So I haven't heard anything from Keith. Keith? Just revert it? Or do
you have a patch for people to try?
Linus
^ permalink raw reply
* [PATCH] niu: Fix races between up/down and get_stats.
From: David Miller @ 2011-02-04 0:25 UTC (permalink / raw)
To: netdev; +Cc: fleitner
As reported by Flavio Leitner, there is no synchronization to protect
NIU's get_stats method from seeing a NULL pointer in either
np->rx_rings or np->tx_rings. In fact, as far as ->ndo_get_stats
is concerned, these values are set completely asynchronously.
Flavio attempted to fix this using a RW semaphore, which in fact
works most of the time. However, dev_get_stats() can be invoked
from non-sleepable contexts in some cases, so this fix doesn't
work in all cases.
So instead, control the visibility of the np->{rx,tx}_ring pointers
when the device is being brough up, and use properties of the device
down sequence to our advantage.
In niu_get_stats(), return immediately if netif_running() is false.
The device shutdown sequence first marks the device as not running (by
clearing the __LINK_STATE_START bit), then it performans a
synchronize_rcu() (in dev_deactive_many()), and then finally it
invokes the driver ->ndo_stop() method.
This guarentees that all invocations of niu_get_stats() either see
netif_running() as false, or they see the channel pointers before
->ndo_stop() clears them out.
If netif_running() is true, protect against startup races by loading
the np->{rx,tx}_rings pointer into a local variable, and punting if
it is NULL. Use ACCESS_ONCE to prevent the compiler from reloading
the pointer on us.
Also, during open, control the order in which the pointers and the
ring counts become visible globally using SMP write memory barriers.
We make sure the np->num_{rx,tx}_rings value is stable and visible
before np->{rx,tx}_rings is.
Such visibility control is not necessary on the niu_free_channels()
side because of the RCU sequencing that happens during device down as
described above. We are always guarenteed that all niu_get_stats
calls are finished, or will see netif_running() false, by the time
->ndo_stop is invoked.
Reported-by: Flavio Leitner <fleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/niu.c | 61 +++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index 2541321..9fb59d3 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -4489,6 +4489,9 @@ static int niu_alloc_channels(struct niu *np)
{
struct niu_parent *parent = np->parent;
int first_rx_channel, first_tx_channel;
+ int num_rx_rings, num_tx_rings;
+ struct rx_ring_info *rx_rings;
+ struct tx_ring_info *tx_rings;
int i, port, err;
port = np->port;
@@ -4498,18 +4501,21 @@ static int niu_alloc_channels(struct niu *np)
first_tx_channel += parent->txchan_per_port[i];
}
- np->num_rx_rings = parent->rxchan_per_port[port];
- np->num_tx_rings = parent->txchan_per_port[port];
+ num_rx_rings = parent->rxchan_per_port[port];
+ num_tx_rings = parent->txchan_per_port[port];
- netif_set_real_num_rx_queues(np->dev, np->num_rx_rings);
- netif_set_real_num_tx_queues(np->dev, np->num_tx_rings);
-
- np->rx_rings = kcalloc(np->num_rx_rings, sizeof(struct rx_ring_info),
- GFP_KERNEL);
+ rx_rings = kcalloc(num_rx_rings, sizeof(struct rx_ring_info),
+ GFP_KERNEL);
err = -ENOMEM;
- if (!np->rx_rings)
+ if (!rx_rings)
goto out_err;
+ np->num_rx_rings = num_rx_rings;
+ smp_wmb();
+ np->rx_rings = rx_rings;
+
+ netif_set_real_num_rx_queues(np->dev, num_rx_rings);
+
for (i = 0; i < np->num_rx_rings; i++) {
struct rx_ring_info *rp = &np->rx_rings[i];
@@ -4538,12 +4544,18 @@ static int niu_alloc_channels(struct niu *np)
return err;
}
- np->tx_rings = kcalloc(np->num_tx_rings, sizeof(struct tx_ring_info),
- GFP_KERNEL);
+ tx_rings = kcalloc(num_tx_rings, sizeof(struct tx_ring_info),
+ GFP_KERNEL);
err = -ENOMEM;
- if (!np->tx_rings)
+ if (!tx_rings)
goto out_err;
+ np->num_tx_rings = num_tx_rings;
+ smp_wmb();
+ np->tx_rings = tx_rings;
+
+ netif_set_real_num_tx_queues(np->dev, num_tx_rings);
+
for (i = 0; i < np->num_tx_rings; i++) {
struct tx_ring_info *rp = &np->tx_rings[i];
@@ -6246,11 +6258,17 @@ static void niu_sync_mac_stats(struct niu *np)
static void niu_get_rx_stats(struct niu *np)
{
unsigned long pkts, dropped, errors, bytes;
+ struct rx_ring_info *rx_rings;
int i;
pkts = dropped = errors = bytes = 0;
+
+ rx_rings = ACCESS_ONCE(np->rx_rings);
+ if (!rx_rings)
+ goto no_rings;
+
for (i = 0; i < np->num_rx_rings; i++) {
- struct rx_ring_info *rp = &np->rx_rings[i];
+ struct rx_ring_info *rp = &rx_rings[i];
niu_sync_rx_discard_stats(np, rp, 0);
@@ -6259,6 +6277,8 @@ static void niu_get_rx_stats(struct niu *np)
dropped += rp->rx_dropped;
errors += rp->rx_errors;
}
+
+no_rings:
np->dev->stats.rx_packets = pkts;
np->dev->stats.rx_bytes = bytes;
np->dev->stats.rx_dropped = dropped;
@@ -6268,16 +6288,24 @@ static void niu_get_rx_stats(struct niu *np)
static void niu_get_tx_stats(struct niu *np)
{
unsigned long pkts, errors, bytes;
+ struct tx_ring_info *tx_rings;
int i;
pkts = errors = bytes = 0;
+
+ tx_rings = ACCESS_ONCE(np->tx_rings);
+ if (!tx_rings)
+ goto no_rings;
+
for (i = 0; i < np->num_tx_rings; i++) {
- struct tx_ring_info *rp = &np->tx_rings[i];
+ struct tx_ring_info *rp = &tx_rings[i];
pkts += rp->tx_packets;
bytes += rp->tx_bytes;
errors += rp->tx_errors;
}
+
+no_rings:
np->dev->stats.tx_packets = pkts;
np->dev->stats.tx_bytes = bytes;
np->dev->stats.tx_errors = errors;
@@ -6287,9 +6315,10 @@ static struct net_device_stats *niu_get_stats(struct net_device *dev)
{
struct niu *np = netdev_priv(dev);
- niu_get_rx_stats(np);
- niu_get_tx_stats(np);
-
+ if (netif_running(dev)) {
+ niu_get_rx_stats(np);
+ niu_get_tx_stats(np);
+ }
return &dev->stats;
}
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 0/3] r8169 driver fixes
From: David Miller @ 2011-02-04 0:11 UTC (permalink / raw)
To: romieu; +Cc: netdev, ivecera, hayeswang
In-Reply-To: <20110203235500.GA9137@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Fri, 4 Feb 2011 00:55:00 +0100
> David Miller <davem@davemloft.net> :
>> These are bug fixes, but this GIT branch is based upon net-next-2.6,
>> what is the intent here?
>
> It should have been based on $(git merge-base master net-2.6) instead
> of net-ext-2.6.
>
> I'll rebase it after some sleep.
Ok, thank you.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Dave Airlie @ 2011-02-04 0:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carlos Mafra, Keith Packard, Dave Airlie, Rafael J. Wysocki,
Takashi Iwai, Linux Kernel Mailing List, Maciej Rutecki,
Florian Mickler, Andrew Morton, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <AANLkTi=7EOih=fY5FCvhQbewSc=3a49cYVaKJRWM+-3d@mail.gmail.com>
On Fri, Feb 4, 2011 at 8:10 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra <crmafra2@gmail.com> wrote:
>>>
>>> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
>>> post-2.6.36 regressions for further tracking.
>>
>> I also tested on 2.6.38-rc3+ now and the issue is not solved,
>> just like Takashi expected.
>
> Hmm. That commit (bf9dc102e284) still reverts cleanly.
>
> Keith, Dave, should we just revert it? It's definitely a regression,
> and we do _not_ allow "fixes" to one thing that just causes a
> regression to another.
>
> Quite frankly, I think it's totally wrong to just blindly set DPMS
> status to ON like that. It's as wrong as it was to leave it off, and
> the regressions reported are basically mirror images of the exact same
> bug that that commit tried to fix.
>
> IOW, the commit message says:
>
> When setting a new crtc configuration, force the DPMS state of all
> connectors to ON. Otherwise, they'll be left at OFF and a future mode set
> that disables the specified connector will not turn the connector off.
>
> but setting it to ON doesn't actually _fix_ anything, because you just
> get the exact same issue in reverse, ie you just get
>
> .. and a future mode set that ENables the specified connector will
> not turn the connector ON.
If we are setting a mode on a connector it automatically will end up
in a DPMS on state,
so this seemed correct from what I can see.
A future mode set shouldn't ever not turn the connector on, since
modesetting is an implicit
DPMS,
It sounds like something more subtle than that, though I'm happy to
revert this for now, and let Keith
think about it a bit more.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] r8169 driver fixes
From: Francois Romieu @ 2011-02-03 23:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ivecera, hayeswang
In-Reply-To: <20110203.151802.39181951.davem@davemloft.net>
David Miller <davem@davemloft.net> :
> These are bug fixes, but this GIT branch is based upon net-next-2.6,
> what is the intent here?
It should have been based on $(git merge-base master net-2.6) instead
of net-ext-2.6.
I'll rebase it after some sleep.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Yuchung Cheng @ 2011-02-03 23:54 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, Netdev, therbert, H.K. Jerry Chu, Nandita Dukkipati
In-Reply-To: <alpine.DEB.2.00.1102040027060.25125@melkinpaasi.cs.helsinki.fi>
On Thu, Feb 3, 2011 at 2:43 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> It would perhaps be useful to change receiver advertized window to include
> some extra segs initially. It should be >= IW + peer's dupThresh-1 as
That's a very good point.
Maybe IRW should be IW + ssthresh - 1 since Linux also performs
limited-transmit during fast-recovery as described in RFC 3517. This
way sender can keep sending new data during the recovery as long as
cwnd allows.
> otherwise limited transmit won't work for the initial window because we
> won't open more receiver window with dupacks (IIRC, I suppose Jerry might
> be able to correct me right away if I'm wrong and we open window with
> dupacks too?). I think initial receiver window code used to have some
> surplus but it was broken by the rfc3390-func conversion (against my
> advice on how to do the conversion).
>
> --
> i.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: David Miller @ 2011-02-03 23:53 UTC (permalink / raw)
To: fleitner; +Cc: netdev
In-Reply-To: <20110203234748.GB3710@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Thu, 3 Feb 2011 21:47:48 -0200
> On Thu, Feb 03, 2011 at 03:22:14PM -0800, David Miller wrote:
>> One thing I'm worried about with your patch is that the statistics
>> method can be called in basically any context, therefore a sleeping
>> lock like the rw_semaphore is probably not usable.
>>
>> In fact I'm going to revert your patch for now because of this issue.
>
> Oops, I didn't see it there. I thought all calls there were process
> context. Anyway, RCU then...
Yes, one example is the dev_get_stats() call made in
drivers/net/bonding/bond_main.c, which occurs with a
rw spinlock held and BH disabled.
> thanks for reviewing it,
No problem. I think I even have a way to fix this without using RCU
(directly). Just some memory barriers during allocation of the
channels.
I'll post the patch after I'm done with it, thanks again Falvio.
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: Flavio Leitner @ 2011-02-03 23:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110203.152214.59684545.davem@davemloft.net>
On Thu, Feb 03, 2011 at 03:22:14PM -0800, David Miller wrote:
> From: Flavio Leitner <fleitner@redhat.com>
> Date: Thu, 3 Feb 2011 21:18:05 -0200
>
> > Ok, I can write a new version using RCU if you like.
>
> Don't worry, I'll take care of it, I actually have the
> hardware to test on :-)
Ok. Having the hardware around indeed helps :)
> > I've chose rwsem because I think those operations aren't
> > frequent. The RCU leaves an operation to run later during
> > a safe context, so I thought the cost doesn't worth it.
>
> One thing I'm worried about with your patch is that the statistics
> method can be called in basically any context, therefore a sleeping
> lock like the rw_semaphore is probably not usable.
>
> In fact I'm going to revert your patch for now because of this issue.
Oops, I didn't see it there. I thought all calls there were process
context. Anyway, RCU then...
thanks for reviewing it,
--
Flavio
^ permalink raw reply
* Re: [E1000-devel] [PATCH] fixing hw timestamping in igb
From: Jeff Kirsher @ 2011-02-03 23:23 UTC (permalink / raw)
To: Anders Berggren
Cc: Ronciak, John, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, Ohly, Patrick
In-Reply-To: <9D02360A-8016-4BCB-B14A-DAFE22EF558E@halon.se>
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
On Thu, 2011-02-03 at 02:39 -0800, Anders Berggren wrote:
> Hardware timestamping for Intel 82580 didn't work in either 2.6.36 or 2.6.37. Comparing it to Intel's igb-2.4.12 I found that the timecounter_init clock/counter initialization was done too early.
>
> Anders Berggren
> Halon Security
Thanks Anders, I will add this patch to my queue of igb patches.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: David Miller @ 2011-02-03 23:22 UTC (permalink / raw)
To: fleitner; +Cc: netdev
In-Reply-To: <20110203231805.GA3710@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Thu, 3 Feb 2011 21:18:05 -0200
> Ok, I can write a new version using RCU if you like.
Don't worry, I'll take care of it, I actually have the
hardware to test on :-)
> I've chose rwsem because I think those operations aren't
> frequent. The RCU leaves an operation to run later during
> a safe context, so I thought the cost doesn't worth it.
One thing I'm worried about with your patch is that the statistics
method can be called in basically any context, therefore a sleeping
lock like the rw_semaphore is probably not usable.
In fact I'm going to revert your patch for now because of this issue.
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: Flavio Leitner @ 2011-02-03 23:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110203.142145.183054407.davem@davemloft.net>
On Thu, Feb 03, 2011 at 02:21:45PM -0800, David Miller wrote:
> From: Flavio Leitner <fleitner@redhat.com>
> Date: Thu, 3 Feb 2011 16:45:17 -0200
>
> > It's possible to trigger a crash if one CPU is opening
> > the device while another CPU gets its statistics.
> >
> > It happens because niu_alloc_channels() called from
> > niu_open() sets num_tx/rx_rings before allocating the
> > ring, so the other thread crashes when accessing
> > np->tx_rings[i].tx_packets at niu_get_tx_stats().
> >
> > Signed-off-by: Flavio Leitner <fleitner@redhat.com>
> ...
> > Compile tested only because I don't have the hardware.
>
> I'll apply this and give it a quick test, thanks.
>
> Can you have the person who reported this crash to you test the patch
> out at least? That's how you learned about this problem, right,
> someone else hit the crash?
>
> In such cases I'd really appreciate it if you got positive testing
> feedback from the reporter before posting the patch.
>
> Longer term a better way to fix this is to RCU free the ring data
> structures, and use a quick NULL test at the top of the get stats
> implementation.
Ok, I can write a new version using RCU if you like.
I've chose rwsem because I think those operations aren't
frequent. The RCU leaves an operation to run later during
a safe context, so I thought the cost doesn't worth it.
I'm trying to get testing feedback as well, not sure yet
if it will be possible though. Anyway, I'll update here
when I heard something.
thanks!
--
Flavio
^ permalink raw reply
* Re: [PATCH 0/3] r8169 driver fixes
From: David Miller @ 2011-02-03 23:18 UTC (permalink / raw)
To: romieu; +Cc: netdev, ivecera, hayeswang
In-Reply-To: <20110203172557.GA9024@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 3 Feb 2011 18:26:11 +0100
> The following series includes Ivan Rx fifo overflow fix and similar
> changes I did after testing with various 8168 chipsets.
>
> The series is available as
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r8169-davem
These are bug fixes, but this GIT branch is based upon net-next-2.6,
what is the intent here?
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Hagen Paul Pfeifer @ 2011-02-03 22:55 UTC (permalink / raw)
To: H.K. Jerry Chu; +Cc: David Miller, netdev, dccp, therbert
In-Reply-To: <AANLkTimWHAz0SX_u42guHp2KNyQESsH6ysNwRoe7ZVJ=@mail.gmail.com>
* H.K. Jerry Chu | 2011-02-03 13:17:19 [-0800]:
>> to setup a ns-2 environment but due to lack of time I am a little bit
>> behind schedule. Anyway, why not make this a tunable per route knob so that
>> it is easier to fix things, e.g. set IW back to 3.
>
>You've seemed to get this backwards. Shouldn't we set the default for the normal
>cases and leave the corner cases to the initcwnd and initrwnd knobs to cover?
Yes Jerry, I phrase this a little bit abstruse. Apply David patch and use per
route options to reduce the IW if some curious behavior appear.
It seems the time is come to increase the IW. ;-)
Hagen
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Ilpo Järvinen @ 2011-02-03 22:43 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, therbert, H.K. Jerry Chu
In-Reply-To: <20110202.170750.229739784.davem@davemloft.net>
It would perhaps be useful to change receiver advertized window to include
some extra segs initially. It should be >= IW + peer's dupThresh-1 as
otherwise limited transmit won't work for the initial window because we
won't open more receiver window with dupacks (IIRC, I suppose Jerry might
be able to correct me right away if I'm wrong and we open window with
dupacks too?). I think initial receiver window code used to have some
surplus but it was broken by the rfc3390-func conversion (against my
advice on how to do the conversion).
--
i.
^ permalink raw reply
* Re: sending IP pkgs form user space on a specific interface?
From: Ben Greear @ 2011-02-03 22:41 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF72446498.F31B6A78-ONC125782C.00794F9B-C125782C.007A2D64@transmode.se>
On 02/03/2011 02:14 PM, Joakim Tjernlund wrote:
> Ben Greear<greearb@candelatech.com> wrote on 2011/02/03 23:03:53:
>> From: Ben Greear<greearb@candelatech.com>
>> To: Joakim Tjernlund<joakim.tjernlund@transmode.se>
>> Cc: netdev@vger.kernel.org
>> Date: 2011/02/03 23:03
>> Subject: Re: sending IP pkgs form user space on a specific interface?
>>
>> On 02/03/2011 01:55 PM, Joakim Tjernlund wrote:
>>>
>>> Is there a way to specify what I/F a IP pkg should be sent
>>> out on?
>>>
>>> I have multiple ppp I/Fs with the same local and remote address
>>> and I need to specify what interface to send OSPF protocol
>>> messages to.
>>
>> Check out SO_BINDTODEVICE.
>
> Thanks, can do setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, ..) for
> each I/Fs I need tx pkgs over?
> How do I unbind to any I/F?
>
> If possible, I would like to specify the I/F in the pkg overhead.
Man-pages and google should find those answers.
You could put my name in your search as well, if you want..I know I've
posted sample code in the past to some mailing list or another.
Thanks,
Ben
>
> Jocke
>
> --
> 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
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: David Miller @ 2011-02-03 22:21 UTC (permalink / raw)
To: fleitner; +Cc: netdev
In-Reply-To: <1296758717-18406-1-git-send-email-fleitner@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Thu, 3 Feb 2011 16:45:17 -0200
> It's possible to trigger a crash if one CPU is opening
> the device while another CPU gets its statistics.
>
> It happens because niu_alloc_channels() called from
> niu_open() sets num_tx/rx_rings before allocating the
> ring, so the other thread crashes when accessing
> np->tx_rings[i].tx_packets at niu_get_tx_stats().
>
> Signed-off-by: Flavio Leitner <fleitner@redhat.com>
...
> Compile tested only because I don't have the hardware.
I'll apply this and give it a quick test, thanks.
Can you have the person who reported this crash to you test the patch
out at least? That's how you learned about this problem, right,
someone else hit the crash?
In such cases I'd really appreciate it if you got positive testing
feedback from the reporter before posting the patch.
Longer term a better way to fix this is to RCU free the ring data
structures, and use a quick NULL test at the top of the get stats
implementation.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-03 22:19 UTC (permalink / raw)
To: Carlos Mafra, Keith Packard, Dave Airlie
Cc: Rafael J. Wysocki, Takashi Iwai, Linux Kernel Mailing List,
Maciej Rutecki, Florian Mickler, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <AANLkTi=7EOih=fY5FCvhQbewSc=3a49cYVaKJRWM+-3d@mail.gmail.com>
On Thu, Feb 3, 2011 at 2:10 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Maybe the right thing to do is to set it to 'unknown', something like this.
>
> TOTALLY UNTESTED!
Doing some grepping and "git blame", I found this: commit 032d2a0d068
("drm/i915: Prevent double dpms on") which took a very similar
approach, except it just uses "-1" directly instead of introducing
that DRM_MODE_DPMS_UNKNOWN concept.
So I suspect that my patch is going in the right direction, and
judging by the comments in that commit, we probably should do this
correctly at the dri level rather than have drivers see those stupid
"let's set dpms to the state that it was already in". But that very
much does require that kind of "UNKNOWN" state option.
So maybe we can get that patch tested (and acked if it works)? Carlos, Takashi?
Linus
^ permalink raw reply
* Re: sending IP pkgs form user space on a specific interface?
From: Joakim Tjernlund @ 2011-02-03 22:14 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4D4B2649.40404@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote on 2011/02/03 23:03:53:
> From: Ben Greear <greearb@candelatech.com>
> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Cc: netdev@vger.kernel.org
> Date: 2011/02/03 23:03
> Subject: Re: sending IP pkgs form user space on a specific interface?
>
> On 02/03/2011 01:55 PM, Joakim Tjernlund wrote:
> >
> > Is there a way to specify what I/F a IP pkg should be sent
> > out on?
> >
> > I have multiple ppp I/Fs with the same local and remote address
> > and I need to specify what interface to send OSPF protocol
> > messages to.
>
> Check out SO_BINDTODEVICE.
Thanks, can do setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, ..) for
each I/Fs I need tx pkgs over?
How do I unbind to any I/F?
If possible, I would like to specify the I/F in the pkg overhead.
Jocke
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-03 22:10 UTC (permalink / raw)
To: Carlos Mafra, Keith Packard, Dave Airlie
Cc: Rafael J. Wysocki, Takashi Iwai, Linux Kernel Mailing List,
Maciej Rutecki, Florian Mickler, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <AANLkTi=suS1VDL=6EtT0D2=0c1DWwxdwZBBv=-BySNX-@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra <crmafra2@gmail.com> wrote:
>>
>> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
>> post-2.6.36 regressions for further tracking.
>
> I also tested on 2.6.38-rc3+ now and the issue is not solved,
> just like Takashi expected.
Hmm. That commit (bf9dc102e284) still reverts cleanly.
Keith, Dave, should we just revert it? It's definitely a regression,
and we do _not_ allow "fixes" to one thing that just causes a
regression to another.
Quite frankly, I think it's totally wrong to just blindly set DPMS
status to ON like that. It's as wrong as it was to leave it off, and
the regressions reported are basically mirror images of the exact same
bug that that commit tried to fix.
IOW, the commit message says:
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
but setting it to ON doesn't actually _fix_ anything, because you just
get the exact same issue in reverse, ie you just get
.. and a future mode set that ENables the specified connector will
not turn the connector ON.
instead. Which is exactly what Carlos and Takashi are reporting.
Maybe the right thing to do is to set it to 'unknown', something like this.
TOTALLY UNTESTED!
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1334 bytes --]
drivers/gpu/drm/drm_crtc_helper.c | 6 +++---
include/drm/drm_mode.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 952b3d4..7f585ed 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -681,11 +681,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
goto fail;
}
}
- DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
+ DRM_DEBUG_KMS("Setting connector DPMS state to 'unknown'\n");
for (i = 0; i < set->num_connectors; i++) {
- DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", set->connectors[i]->base.id,
+ DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS 'unknown'\n", set->connectors[i]->base.id,
drm_get_connector_name(set->connectors[i]));
- set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+ set->connectors[i]->dpms = DRM_MODE_DPMS_UNKNOWN;
}
kfree(save_connectors);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 0fc7397..4b5144c 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -59,6 +59,7 @@
/* DPMS flags */
/* bit compatible with the xorg definitions. */
+#define DRM_MODE_DPMS_UNKNOWN (-1)
#define DRM_MODE_DPMS_ON 0
#define DRM_MODE_DPMS_STANDBY 1
#define DRM_MODE_DPMS_SUSPEND 2
^ permalink raw reply related
* Re: sending IP pkgs form user space on a specific interface?
From: Ben Greear @ 2011-02-03 22:03 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OFAEE2A3EA.1C3F2C8A-ONC125782C.0077F327-C125782C.007872C6@transmode.se>
On 02/03/2011 01:55 PM, Joakim Tjernlund wrote:
>
> Is there a way to specify what I/F a IP pkg should be sent
> out on?
>
> I have multiple ppp I/Fs with the same local and remote address
> and I need to specify what interface to send OSPF protocol
> messages to.
Check out SO_BINDTODEVICE.
Thanks,
Ben
>
> Jocke
>
> --
> 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
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* sending IP pkgs form user space on a specific interface?
From: Joakim Tjernlund @ 2011-02-03 21:55 UTC (permalink / raw)
To: netdev
Is there a way to specify what I/F a IP pkg should be sent
out on?
I have multiple ppp I/Fs with the same local and remote address
and I need to specify what interface to send OSPF protocol
messages to.
Jocke
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Leandro Melo de Sales @ 2011-02-03 22:00 UTC (permalink / raw)
To: netdev, dccp
In-Reply-To: <AANLkTi=z-1-=R4X6hxs738jMEdYwfMPBFq9Ss-JwKCy3@mail.gmail.com>
Just forwarding my reply to the list netdev and dccp lists, the text
was in HTML format and Majordomo rejected it...
---------- Forwarded message ----------
From: Leandro Melo de Sales <leandroal@gmail.com>
Date: Thu, Feb 3, 2011 at 2:48 PM
Subject: Re: [PATCH] tcp: Increase the initial congestion window to 10.
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, dccp@vger.kernel.org, therbert@google.com,
Angelo Perkusich <Angelo.Perkusich@gmail.com>, Hyggo Almeida
<hyggo.almeida@gmail.com>
On Wed, Feb 2, 2011 at 10:07 PM, David Miller <davem@davemloft.net> wrote:
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> I've left the DCCP code to keep using RFC3390 logic, if they
> wish to adopt this change in their code they can do so by
> simply deleting the rfc33390_bytes_to_packets() function and
> using TCP_INIT_CWND in their assignment.
>
> include/net/tcp.h | 12 +++---------
> net/dccp/ccids/ccid2.c | 9 +++++++++
> net/ipv4/tcp_input.c | 2 +-
> 3 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 9179111..7118668 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -196,6 +196,9 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
> /* TCP thin-stream limits */
> #define TCP_THIN_LINEAR_RETRIES 6 /* After 6 linear retries, do exp. backoff */
>
> +/* TCP initial congestion window */
> +#define TCP_INIT_CWND 10
> +
> extern struct inet_timewait_death_row tcp_death_row;
>
> /* sysctl variables for tcp */
> @@ -799,15 +802,6 @@ static inline __u32 tcp_current_ssthresh(const struct sock *sk)
> /* Use define here intentionally to get WARN_ON location shown at the caller */
> #define tcp_verify_left_out(tp) WARN_ON(tcp_left_out(tp) > tp->packets_out)
>
> -/*
> - * Convert RFC 3390 larger initial window into an equivalent number of packets.
> - * This is based on the numbers specified in RFC 5681, 3.1.
> - */
> -static inline u32 rfc3390_bytes_to_packets(const u32 smss)
> -{
> - return smss <= 1095 ? 4 : (smss > 2190 ? 2 : 3);
> -}
> -
> extern void tcp_enter_cwr(struct sock *sk, const int set_ssthresh);
> extern __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst);
>
> diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c
> index e96d5e8..fadecd2 100644
> --- a/net/dccp/ccids/ccid2.c
> +++ b/net/dccp/ccids/ccid2.c
> @@ -583,6 +583,15 @@ done:
> dccp_ackvec_parsed_cleanup(&hc->tx_av_chunks);
> }
>
> +/*
> + * Convert RFC 3390 larger initial window into an equivalent number of packets.
> + * This is based on the numbers specified in RFC 5681, 3.1.
> + */
> +static inline u32 rfc3390_bytes_to_packets(const u32 smss)
> +{
> + return smss <= 1095 ? 4 : (smss > 2190 ? 2 : 3);
> +}
> +
> static int ccid2_hc_tx_init(struct ccid *ccid, struct sock *sk)
> {
> struct ccid2_hc_tx_sock *hc = ccid_priv(ccid);
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index eb7f82e..2f692ce 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -817,7 +817,7 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst)
> __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0);
>
> if (!cwnd)
> - cwnd = rfc3390_bytes_to_packets(tp->mss_cache);
> + cwnd = TCP_INIT_CWND;
> return min_t(__u32, cwnd, tp->snd_cwnd_clamp);
> }
>
> --
> 1.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
David and others,
I don't think this change will make sense for DCCP, once IW10 is
for the cases of short-lived flows. DCCP is used on scenarios for
multimedia flows, which are, in general, long-lived flows. So, IMO the
way how we calculate IW for DCCP is appropriate, at least considering
a quick answer. In fact, nowadays we need better congestion control
algorithms for DCCP, and in this sense we are working on adapt TCP
Cubic for DCCP as a CCID, and also we started some work to make DCCP
support TCP pluggable mechanism , which will allow us to use TCP
congestion control algorithms in DCCP.
I've been following all the discussions about IW10 in the TCPM
discussion list and also been reading all materials in this context
(papers and ppts) provided by Tom Herbert and Nandita Dukkipati (along
with other researchers from Networking Research Lab at North Carolina
State University), but although the results is really great (at least
for scenarios they've experimented and regardless to all opinions
expressed at TCPM), DCCP should calculate its IW as specified in
RFC3390 rather than set it to IW10. For the moment, I understand that
for DCCP, we have to discuss more about this in a separated thread.
Leandro.
--
Leandro Melo de Sales
Professor at Institute of Computing at Federal University of Alagoas, Brazil
PhD candidate in Computer Science
Pervasive and Embedded Computing Laboratory, UFCG
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Carlos Mafra @ 2011-02-03 21:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Takashi Iwai, Linus Torvalds, Keith Packard, Dave Airlie,
Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <201102032009.17100.rjw@sisk.pl>
On Thu, Feb 3, 2011 at 8:09 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, February 03, 2011, Takashi Iwai wrote:
>> At Thu, 3 Feb 2011 07:42:05 -0800,
>> Linus Torvalds wrote:
>> >
>> > On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra <crmafra2@gmail.com> wrote:
>> > > On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
>> > Just to confirm, can you also check -rc3? I'm pretty sure nothing has
>> > changed, but there were a few drm patches after -rc2, so it's alsways
>> > good to double-check.
>>
>> The problem I reported in the bugzilla above is still present in
>> 2.6.38-rc3. I'm pretty sure that's the same issue as Carlos' case.
>
> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
> post-2.6.36 regressions for further tracking.
I also tested on 2.6.38-rc3+ now and the issue is not solved,
just like Takashi expected.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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
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