* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-03 15:42 UTC (permalink / raw)
To: Carlos R. Mafra, Keith Packard, Dave Airlie
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Rafael J. Wysocki, Florian Mickler, Andrew Morton,
Kernel Testers List, Linux PM List, Maciej Rutecki
In-Reply-To: <20110203112316.GA3718@linux-yscl.site>
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:
>>
>> If you know of any other unresolved post-2.6.36 regressions, please let us know
>> either and we'll add them to the list. Also, please let us know if any
>> of the entries below are invalid.
>
> I'm sorry if I'm overlooking something, but as far as I can see the regression
> reported here:
>
> https://lkml.org/lkml/2011/1/24/457
>
> is not in the list (update on that report: reverting that commit on top of
> 2.6.37 fixes the issue).
Ok, added Keith and Dave to the cc, since they are the signers of that commit.
> After some time, I also ended up finding an earlier report in the kernel bugzilla
> which I think is the same regression (it was bisected to the same commit):
>
> https://bugzilla.kernel.org/show_bug.cgi?id=24982
>
> but I do not see it in the list either, even though it's marked as a
> regression in the bugzilla.
>
> The issue was also present in 2.6.38-rc2 last time I tested.
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.
Keithp?
Linus
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-03 15:58 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <20110203061326.GC22230@redhat.com>
On Thu, 2011-02-03 at 08:13 +0200, Michael S. Tsirkin wrote:
> > Initial TCP_STREAM performance results I got for guest to local
> host
> > 4.2Gb/s for 1K message size, (vs. 2.5Gb/s)
> > 6.2Gb/s for 2K message size, and (vs. 3.8Gb/s)
> > 9.8Gb/s for 4K message size. (vs.5.xGb/s)
>
> What is the average packet size, # bytes per ack, and the # of
> interrupts
> per packet? It could be that just slowing down trahsmission
> makes GSO work better.
There is no TX interrupts with dropping packet.
GSO/TSO is the key for small message performance, w/o GSO/TSO, the
performance is limited to about 2Gb/s no matter how big the message size
it is. I think any work we try here will increase large packet size
rate. BTW for dropping packet, TCP increased fast retrans, not slow
start.
I will collect tcpdump, netstart before and after data to compare packet
size/rate w/o w/i the patch.
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Pablo Neira Ayuso @ 2011-02-03 16:01 UTC (permalink / raw)
To: Hans Schillstrom
Cc: kaber@trash.net, jengelh@medozas.de,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
hans@schillstrom.com
In-Reply-To: <4D4ACCCB.8030902@netfilter.org>
On 03/02/11 16:42, Pablo Neira Ayuso wrote:
> On 03/02/11 15:23, Hans Schillstrom wrote:
>> On Thu, 2011-02-03 at 14:51 +0100, Pablo Neira Ayuso wrote:
>>> On 03/02/11 14:34, Hans Schillstrom wrote:
>>> this assumption is not valid in NAT handlings.
>>
>> That's true, because I want to avoid conntrack
>>
>>> If you want consistent hashing with NAT handlings you'll have to make
>>> this stateful and use the conntrack source and reply directions of the
>>> original tuples (thus making it stateful). That may be a problem because
>>> some people may want to use this without enabling connection tracking.
>>
>> What about a compilation switch or a sysctl ?
>
> or better some option for iptables.
Hm, this is actually not straight forward to implement, you'll have to
use hook functions to avoid the module dependencies with conntrack and
that's pretty annoying.
I don't come up with a good solution for this.
>>> Are you using this for (uplink) load balancing?
>>
>> Actually in both ways
>> - in front of a bunch of ipvs
to make some preliminary load-sharing between the load balancers?
>> - and in the payloads for outgoing traffic.
and then to select the uplink, right?
^ permalink raw reply
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Jan Engelhardt @ 2011-02-03 16:06 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Hans Schillstrom, kaber@trash.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
hans@schillstrom.com
In-Reply-To: <4D4AD157.50707@netfilter.org>
On Thursday 2011-02-03 17:01, Pablo Neira Ayuso wrote:
>On 03/02/11 16:42, Pablo Neira Ayuso wrote:
>> On 03/02/11 15:23, Hans Schillstrom wrote:
>>> On Thu, 2011-02-03 at 14:51 +0100, Pablo Neira Ayuso wrote:
>>>> On 03/02/11 14:34, Hans Schillstrom wrote:
>>>> this assumption is not valid in NAT handlings.
>>>
>>> That's true, because I want to avoid conntrack
>>>
>>>> If you want consistent hashing with NAT handlings you'll have to make
>>>> this stateful and use the conntrack source and reply directions of the
>>>> original tuples (thus making it stateful). That may be a problem because
>>>> some people may want to use this without enabling connection tracking.
>>>
>>> What about a compilation switch or a sysctl ?
>>
>> or better some option for iptables.
>
>Hm, this is actually not straight forward to implement, you'll have to
>use hook functions to avoid the module dependencies with conntrack and
>that's pretty annoying.
>
>I don't come up with a good solution for this.
If it loads conntrack always, there is the option to shovel it
into xt_connmark.c.
^ permalink raw reply
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Pablo Neira Ayuso @ 2011-02-03 16:08 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Hans Schillstrom, kaber@trash.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
hans@schillstrom.com
In-Reply-To: <alpine.LNX.2.01.1102031706010.28180@obet.zrqbmnf.qr>
On 03/02/11 17:06, Jan Engelhardt wrote:
> On Thursday 2011-02-03 17:01, Pablo Neira Ayuso wrote:
>
>> On 03/02/11 16:42, Pablo Neira Ayuso wrote:
>>> On 03/02/11 15:23, Hans Schillstrom wrote:
>>>> On Thu, 2011-02-03 at 14:51 +0100, Pablo Neira Ayuso wrote:
>>>>> On 03/02/11 14:34, Hans Schillstrom wrote:
>>>>> this assumption is not valid in NAT handlings.
>>>>
>>>> That's true, because I want to avoid conntrack
>>>>
>>>>> If you want consistent hashing with NAT handlings you'll have to make
>>>>> this stateful and use the conntrack source and reply directions of the
>>>>> original tuples (thus making it stateful). That may be a problem because
>>>>> some people may want to use this without enabling connection tracking.
>>>>
>>>> What about a compilation switch or a sysctl ?
>>>
>>> or better some option for iptables.
>>
>> Hm, this is actually not straight forward to implement, you'll have to
>> use hook functions to avoid the module dependencies with conntrack and
>> that's pretty annoying.
>>
>> I don't come up with a good solution for this.
>
> If it loads conntrack always, there is the option to shovel it
> into xt_connmark.c.
the problem is that Hans wants this not to depend on conntrack always.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Takashi Iwai @ 2011-02-03 16:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Carlos R. Mafra, Keith Packard, Dave Airlie, Rafael J. Wysocki,
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: <AANLkTikELiGS+fM5WguZS=Fo-sSXmej1UnKWqCFmnE0k@mail.gmail.com>
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:
> >>
> >> If you know of any other unresolved post-2.6.36 regressions, please let us know
> >> either and we'll add them to the list. Also, please let us know if any
> >> of the entries below are invalid.
> >
> > I'm sorry if I'm overlooking something, but as far as I can see the regression
> > reported here:
> >
> > https://lkml.org/lkml/2011/1/24/457
> >
> > is not in the list (update on that report: reverting that commit on top of
> > 2.6.37 fixes the issue).
>
> Ok, added Keith and Dave to the cc, since they are the signers of that commit.
>
> > After some time, I also ended up finding an earlier report in the kernel bugzilla
> > which I think is the same regression (it was bisected to the same commit):
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=24982
> >
> > but I do not see it in the list either, even though it's marked as a
> > regression in the bugzilla.
> >
> > The issue was also present in 2.6.38-rc2 last time I tested.
>
> 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.
thanks,
Takashi
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-03 16:20 UTC (permalink / raw)
To: Shirley Ma
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <1296748680.25430.169.camel@localhost.localdomain>
On Thu, Feb 03, 2011 at 07:58:00AM -0800, Shirley Ma wrote:
> On Thu, 2011-02-03 at 08:13 +0200, Michael S. Tsirkin wrote:
> > > Initial TCP_STREAM performance results I got for guest to local
> > host
> > > 4.2Gb/s for 1K message size, (vs. 2.5Gb/s)
> > > 6.2Gb/s for 2K message size, and (vs. 3.8Gb/s)
> > > 9.8Gb/s for 4K message size. (vs.5.xGb/s)
> >
> > What is the average packet size, # bytes per ack, and the # of
> > interrupts
> > per packet? It could be that just slowing down trahsmission
> > makes GSO work better.
>
> There is no TX interrupts with dropping packet.
>
> GSO/TSO is the key for small message performance, w/o GSO/TSO, the
> performance is limited to about 2Gb/s no matter how big the message size
> it is. I think any work we try here will increase large packet size
> rate. BTW for dropping packet, TCP increased fast retrans, not slow
> start.
>
> I will collect tcpdump, netstart before and after data to compare packet
> size/rate w/o w/i the patch.
>
> Thanks
> Shirley
Just a thought: does it help to make tx queue len of the
virtio device smaller?
E.g. match the vq size?
--
MST
^ permalink raw reply
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Jan Engelhardt @ 2011-02-03 16:32 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Hans Schillstrom, kaber@trash.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
hans@schillstrom.com
In-Reply-To: <4D4AD305.2060505@netfilter.org>
On Thursday 2011-02-03 17:08, Pablo Neira Ayuso wrote:
>>> Hm, this is actually not straight forward to implement, you'll have to
>>> use hook functions to avoid the module dependencies with conntrack and
>>> that's pretty annoying.
>>>
>>> I don't come up with a good solution for this.
>>
>> If it loads conntrack always, there is the option to shovel it
>> into xt_connmark.c.
>
>the problem is that Hans wants this not to depend on conntrack always.
Well you porbably won't get around the nf_conntrack module dependency,
but conntrack can still be disabled through CT --notrack
if one does not like the runtime cost.
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-03 17:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <20110203162042.GA10028@redhat.com>
On Thu, 2011-02-03 at 18:20 +0200, Michael S. Tsirkin wrote:
> Just a thought: does it help to make tx queue len of the
> virtio device smaller?
Yes, that what I did before, reducing txqueuelen will cause qdisc dropp
the packet early, But it's hard to control by using tx queuelen for
performance gain. I tried on different systems, it required different
values.
Also, I tried another patch, instead of dropping packets, I used to
timer (2 jiffies) to enable/disable queue on guest without interrupts
notification, it gets better performance than original but worse
performance than dropping packets because of netif stop/wake up too
often.
vhost is definitely needed to improve for handling small message sizes.
It's unable to handle small message packets rate for queue size 256,
even with ring size 1024. QEMU seems not allowing to increase the TX
ring size to 2K (start qemu_kvm failure with no errors), I am not able
to test it out.
Thanks
Shirley
^ permalink raw reply
* [PATCH 0/3] r8169 driver fixes
From: Francois Romieu @ 2011-02-03 17:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Ivan Vecera, Hayes Wang
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
Distance from 'master' (2ba451421b23636c45fabfa522858c5c124b3673)
-----------------------------------------------------------------
0331b3b022b9724019e4c42fded4a01eaa6946f5
407786ae1960eef585f97bfa7625a36512925de0
e4b6fa3d3d3db4fac32904ae12efe199de8efed0
Diffstat
--------
drivers/net/r8169.c | 41 ++++++++++++++++++++++++++++++++---------
1 files changed, 32 insertions(+), 9 deletions(-)
Shortlog
--------
Francois Romieu (2):
r8169: RxFIFO overflow oddities with 8168 chipsets
r8169: prevent RxFIFO induced loops in the irq handler.
Ivan Vecera (1):
r8169: use RxFIFO overflow workaround for 8168c chipset
Patch
-----
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index bde7d61..59ccf0c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -973,7 +973,8 @@ static void __rtl8169_check_link_status(struct net_device *dev,
if (pm)
pm_request_resume(&tp->pci_dev->dev);
netif_carrier_on(dev);
- netif_info(tp, ifup, dev, "link up\n");
+ if (net_ratelimit())
+ netif_info(tp, ifup, dev, "link up\n");
} else {
netif_carrier_off(dev);
netif_info(tp, ifdown, dev, "link down\n");
@@ -3757,7 +3758,8 @@ static void rtl_hw_start_8168(struct net_device *dev)
RTL_W16(IntrMitigate, 0x5151);
/* Work around for RxFIFO overflow. */
- if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_22) {
tp->intr_event |= RxFIFOOver | PCSTimeout;
tp->intr_event &= ~RxOverflow;
}
@@ -4639,12 +4641,33 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
break;
}
- /* Work around for rx fifo overflow */
- if (unlikely(status & RxFIFOOver) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_11)) {
- netif_stop_queue(dev);
- rtl8169_tx_timeout(dev);
- break;
+ if (unlikely(status & RxFIFOOver)) {
+ switch (tp->mac_version) {
+ /* Work around for rx fifo overflow */
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_22:
+ case RTL_GIGA_MAC_VER_26:
+ netif_stop_queue(dev);
+ rtl8169_tx_timeout(dev);
+ goto done;
+ /* Testers needed. */
+ case RTL_GIGA_MAC_VER_17:
+ case RTL_GIGA_MAC_VER_19:
+ case RTL_GIGA_MAC_VER_20:
+ case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_23:
+ case RTL_GIGA_MAC_VER_24:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ /* Experimental science. Pktgen proof. */
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_25:
+ if (status == RxFIFOOver)
+ goto done;
+ break;
+ default:
+ break;
+ }
}
if (unlikely(status & SYSErr)) {
@@ -4680,7 +4703,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
(status & RxFIFOOver) ? (status | RxOverflow) : status);
status = RTL_R16(IntrStatus);
}
-
+done:
return IRQ_RETVAL(handled);
}
--
Ueimor
祝你 新年快乐，兔年吉祥，心想事成，事事顺利, 万事如意，恭喜发财 !
^ permalink raw reply related
* [PATCH 1/3] r8169: use RxFIFO overflow workaround for 8168c chipset
From: Francois Romieu @ 2011-02-03 17:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Ivan Vecera, Hayes Wang
I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts
generating RxFIFO overflow errors. The result is an infinite loop in
interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11.
With the workaround everything goes fine.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index bde7d61..9ab3b43 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3757,7 +3757,8 @@ static void rtl_hw_start_8168(struct net_device *dev)
RTL_W16(IntrMitigate, 0x5151);
/* Work around for RxFIFO overflow. */
- if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_22) {
tp->intr_event |= RxFIFOOver | PCSTimeout;
tp->intr_event &= ~RxOverflow;
}
@@ -4641,7 +4642,8 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
/* Work around for rx fifo overflow */
if (unlikely(status & RxFIFOOver) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_11)) {
+ (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_22)) {
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
break;
--
1.7.3.5
^ permalink raw reply related
* [PATCH 2/3] r8169: RxFIFO overflow oddities with 8168 chipsets
From: Francois Romieu @ 2011-02-03 17:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Ivan Vecera, Hayes Wang
Some experiment-based action to prevent my 8168 chipsets locking-up hard
in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not
always mandatory (is it at all ?).
- RTL_GIGA_MAC_VER_12
- RTL_GIGA_MAC_VER_25
Missed ~55% packets. Note:
- this is an old SiS 965L motherboard
- the 8168 chipset emits (lots of) control frames towards the sender
- RTL_GIGA_MAC_VER_26
The chipset does not go into a frenzy of mac control pause when it
crashes yet but it can still be crashed. It needs more work.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Ivan Vecera <ivecera@redhat.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9ab3b43..40dabe2 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -973,7 +973,8 @@ static void __rtl8169_check_link_status(struct net_device *dev,
if (pm)
pm_request_resume(&tp->pci_dev->dev);
netif_carrier_on(dev);
- netif_info(tp, ifup, dev, "link up\n");
+ if (net_ratelimit())
+ netif_info(tp, ifup, dev, "link up\n");
} else {
netif_carrier_off(dev);
netif_info(tp, ifdown, dev, "link down\n");
@@ -4640,13 +4641,24 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
break;
}
- /* Work around for rx fifo overflow */
- if (unlikely(status & RxFIFOOver) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
- tp->mac_version == RTL_GIGA_MAC_VER_22)) {
- netif_stop_queue(dev);
- rtl8169_tx_timeout(dev);
- break;
+ if (unlikely(status & RxFIFOOver)) {
+ switch (tp->mac_version) {
+ /* Work around for rx fifo overflow */
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_22:
+ case RTL_GIGA_MAC_VER_26:
+ netif_stop_queue(dev);
+ rtl8169_tx_timeout(dev);
+ goto done;
+ /* Experimental science. Pktgen proof. */
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_25:
+ if (status == RxFIFOOver)
+ goto done;
+ break;
+ default:
+ break;
+ }
}
if (unlikely(status & SYSErr)) {
@@ -4682,7 +4694,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
(status & RxFIFOOver) ? (status | RxOverflow) : status);
status = RTL_R16(IntrStatus);
}
-
+done:
return IRQ_RETVAL(handled);
}
--
1.7.3.5
^ permalink raw reply related
* [PATCH 3/3] r8169: prevent RxFIFO induced loops in the irq handler.
From: Francois Romieu @ 2011-02-03 17:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Ivan Vecera, Hayes Wang
While the RxFIFO interruption is masked for most 8168, nothing prevents
it to appear in the irq status word. This is no excuse to crash.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Ivan Vecera <ivecera@redhat.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 40dabe2..59ccf0c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -4650,6 +4650,15 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
goto done;
+ /* Testers needed. */
+ case RTL_GIGA_MAC_VER_17:
+ case RTL_GIGA_MAC_VER_19:
+ case RTL_GIGA_MAC_VER_20:
+ case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_23:
+ case RTL_GIGA_MAC_VER_24:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
/* Experimental science. Pktgen proof. */
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_25:
--
1.7.3.5
^ permalink raw reply related
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Hans Schillstrom @ 2011-02-03 17:37 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Hans Schillstrom, kaber@trash.net, jengelh@medozas.de,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <4D4AD157.50707@netfilter.org>
On Thursday, February 03, 2011 17:01:27 Pablo Neira Ayuso wrote:
> On 03/02/11 16:42, Pablo Neira Ayuso wrote:
> > On 03/02/11 15:23, Hans Schillstrom wrote:
> >> On Thu, 2011-02-03 at 14:51 +0100, Pablo Neira Ayuso wrote:
> >>> On 03/02/11 14:34, Hans Schillstrom wrote:
> >>> this assumption is not valid in NAT handlings.
> >>
> >> That's true, because I want to avoid conntrack
> >>
> >>> If you want consistent hashing with NAT handlings you'll have to make
> >>> this stateful and use the conntrack source and reply directions of the
> >>> original tuples (thus making it stateful). That may be a problem because
> >>> some people may want to use this without enabling connection tracking.
> >>
> >> What about a compilation switch or a sysctl ?
> >
> > or better some option for iptables.
>
> Hm, this is actually not straight forward to implement, you'll have to
> use hook functions to avoid the module dependencies with conntrack and
> that's pretty annoying.
>
> I don't come up with a good solution for this.
A configuration switch might be OK.
>
> >>> Are you using this for (uplink) load balancing?
> >>
> >> Actually in both ways
> >> - in front of a bunch of ipvs
>
> to make some preliminary load-sharing between the load balancers?
Yes that's right
and in the payloads send the return traffic in the same path.
>
> >> - and in the payloads for outgoing traffic.
>
> and then to select the uplink, right?
>
Yes.
It also has the same role for cluster originated traffic to spread the load over multiple interfaces,
and catch the return traffic.
^ permalink raw reply
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Hans Schillstrom @ 2011-02-03 17:40 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Pablo Neira Ayuso, Hans Schillstrom, kaber@trash.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.01.1102031731010.30984@obet.zrqbmnf.qr>
--
Mvh
Hasse Schillstrom
070-699 7150
On Thursday, February 03, 2011 17:32:07 Jan Engelhardt wrote:
>
> On Thursday 2011-02-03 17:08, Pablo Neira Ayuso wrote:
> >>> Hm, this is actually not straight forward to implement, you'll have to
> >>> use hook functions to avoid the module dependencies with conntrack and
> >>> that's pretty annoying.
> >>>
> >>> I don't come up with a good solution for this.
> >>
> >> If it loads conntrack always, there is the option to shovel it
> >> into xt_connmark.c.
> >
> >the problem is that Hans wants this not to depend on conntrack always.
>
> Well you porbably won't get around the nf_conntrack module dependency,
> but conntrack can still be disabled through CT --notrack
> if one does not like the runtime cost.
>
If you do put this in front of a bunch of load balancers,
there is probably a lot of traffic :-)
So that's the reason why I don't want do depend upon conntrack.
^ permalink raw reply
* [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: Flavio Leitner @ 2011-02-03 18:45 UTC (permalink / raw)
To: netdev; +Cc: Flavio Leitner
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>
---
drivers/net/niu.c | 29 ++++++++++++++++++++++++++---
drivers/net/niu.h | 1 +
2 files changed, 27 insertions(+), 3 deletions(-)
Compile tested only because I don't have the hardware.
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index 2541321..bfa494e 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -4328,7 +4328,7 @@ static void niu_free_tx_ring_info(struct niu *np, struct tx_ring_info *rp)
}
}
-static void niu_free_channels(struct niu *np)
+static void __niu_free_channels(struct niu *np)
{
int i;
@@ -4355,6 +4355,13 @@ static void niu_free_channels(struct niu *np)
}
}
+static void niu_free_channels(struct niu *np)
+{
+ down_write(&np->rings_rwlock);
+ __niu_free_channels(np);
+ up_write(&np->rings_rwlock);
+}
+
static int niu_alloc_rx_ring_info(struct niu *np,
struct rx_ring_info *rp)
{
@@ -4485,7 +4492,7 @@ static void niu_size_rbr(struct niu *np, struct rx_ring_info *rp)
rp->rbr_sizes[3] = rp->rbr_block_size;
}
-static int niu_alloc_channels(struct niu *np)
+static int __niu_alloc_channels(struct niu *np)
{
struct niu_parent *parent = np->parent;
int first_rx_channel, first_tx_channel;
@@ -4558,10 +4565,21 @@ static int niu_alloc_channels(struct niu *np)
return 0;
out_err:
- niu_free_channels(np);
+ __niu_free_channels(np);
return err;
}
+static int niu_alloc_channels(struct niu *np)
+{
+ int ret;
+
+ down_write(&np->rings_rwlock);
+ ret = __niu_alloc_channels(np);
+ up_write(&np->rings_rwlock);
+
+ return ret;
+}
+
static int niu_tx_cs_sng_poll(struct niu *np, int channel)
{
int limit = 1000;
@@ -6249,6 +6267,7 @@ static void niu_get_rx_stats(struct niu *np)
int i;
pkts = dropped = errors = bytes = 0;
+ down_read(&np->rings_rwlock);
for (i = 0; i < np->num_rx_rings; i++) {
struct rx_ring_info *rp = &np->rx_rings[i];
@@ -6259,6 +6278,7 @@ static void niu_get_rx_stats(struct niu *np)
dropped += rp->rx_dropped;
errors += rp->rx_errors;
}
+ up_read(&np->rings_rwlock);
np->dev->stats.rx_packets = pkts;
np->dev->stats.rx_bytes = bytes;
np->dev->stats.rx_dropped = dropped;
@@ -6271,6 +6291,7 @@ static void niu_get_tx_stats(struct niu *np)
int i;
pkts = errors = bytes = 0;
+ down_read(&np->rings_rwlock);
for (i = 0; i < np->num_tx_rings; i++) {
struct tx_ring_info *rp = &np->tx_rings[i];
@@ -6278,6 +6299,7 @@ static void niu_get_tx_stats(struct niu *np)
bytes += rp->tx_bytes;
errors += rp->tx_errors;
}
+ up_read(&np->rings_rwlock);
np->dev->stats.tx_packets = pkts;
np->dev->stats.tx_bytes = bytes;
np->dev->stats.tx_errors = errors;
@@ -9680,6 +9702,7 @@ static struct net_device * __devinit niu_alloc_and_init(
np->msg_enable = niu_debug;
+ init_rwsem(&np->rings_rwlock);
spin_lock_init(&np->lock);
INIT_WORK(&np->reset_task, niu_reset_task);
diff --git a/drivers/net/niu.h b/drivers/net/niu.h
index a41fa8e..555bae1 100644
--- a/drivers/net/niu.h
+++ b/drivers/net/niu.h
@@ -3265,6 +3265,7 @@ struct niu {
const struct niu_ops *ops;
union niu_mac_stats mac_stats;
+ struct rw_semaphore rings_rwlock;
struct rx_ring_info *rx_rings;
struct tx_ring_info *tx_rings;
int num_rx_rings;
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH 0/3] r8169 driver fixes
From: Ivan Vecera @ 2011-02-03 19:01 UTC (permalink / raw)
To: Francois Romieu; +Cc: davem, netdev, Hayes Wang
In-Reply-To: <20110203172557.GA9024@electric-eye.fr.zoreil.com>
On Thu, 2011-02-03 at 18:26 +0100, Francois Romieu wrote:
> 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
>
> Distance from 'master' (2ba451421b23636c45fabfa522858c5c124b3673)
> -----------------------------------------------------------------
>
> 0331b3b022b9724019e4c42fded4a01eaa6946f5
> 407786ae1960eef585f97bfa7625a36512925de0
> e4b6fa3d3d3db4fac32904ae12efe199de8efed0
>
> Diffstat
> --------
>
> drivers/net/r8169.c | 41 ++++++++++++++++++++++++++++++++---------
> 1 files changed, 32 insertions(+), 9 deletions(-)
>
> Shortlog
> --------
>
> Francois Romieu (2):
> r8169: RxFIFO overflow oddities with 8168 chipsets
> r8169: prevent RxFIFO induced loops in the irq handler.
>
> Ivan Vecera (1):
> r8169: use RxFIFO overflow workaround for 8168c chipset
>
Looks good.
Ivan
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Rafael J. Wysocki @ 2011-02-03 19:09 UTC (permalink / raw)
To: Takashi Iwai
Cc: Linus Torvalds, Carlos R. Mafra, 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: <s5haaid3xos.wl%tiwai@suse.de>
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:
> > >>
> > >> If you know of any other unresolved post-2.6.36 regressions, please let us know
> > >> either and we'll add them to the list. Also, please let us know if any
> > >> of the entries below are invalid.
> > >
> > > I'm sorry if I'm overlooking something, but as far as I can see the regression
> > > reported here:
> > >
> > > https://lkml.org/lkml/2011/1/24/457
> > >
> > > is not in the list (update on that report: reverting that commit on top of
> > > 2.6.37 fixes the issue).
> >
> > Ok, added Keith and Dave to the cc, since they are the signers of that commit.
> >
> > > After some time, I also ended up finding an earlier report in the kernel bugzilla
> > > which I think is the same regression (it was bisected to the same commit):
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=24982
> > >
> > > but I do not see it in the list either, even though it's marked as a
> > > regression in the bugzilla.
> > >
> > > The issue was also present in 2.6.38-rc2 last time I tested.
> >
> > 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.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] wireless, wl1251: Fix potential NULL pointer dereference in wl1251_op_bss_info_changed()
From: Jesper Juhl @ 2011-02-03 20:14 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel, John W. Linville, Kalle Valo
In drivers/net/wireless/wl1251/main.c:wl1251_op_bss_info_changed() we make
a call to ieee80211_beacon_get() which may return NULL, but we do not
check the return value before dereferencing the pointer.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/wl1251/main.c b/drivers/net/wireless/wl1251/main.c
index 012e1a4..40372ba 100644
--- a/drivers/net/wireless/wl1251/main.c
+++ b/drivers/net/wireless/wl1251/main.c
@@ -1039,6 +1039,9 @@ static void wl1251_op_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_BEACON) {
beacon = ieee80211_beacon_get(hw, vif);
+ if (!beacon)
+ goto out_sleep;
+
ret = wl1251_cmd_template_set(wl, CMD_BEACON, beacon->data,
beacon->len);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Yuchung Cheng @ 2011-02-03 20:28 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110202.170750.229739784.davem@davemloft.net>
Thanks for doing this!
Acked-by: Yuchung Cheng <ycheng@google.com>
On Wed, Feb 2, 2011 at 5: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 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
* potential null pointer dereference in drivers/isdn/hisax/isdnl2.c
From: Jesper Juhl @ 2011-02-03 20:27 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Tejun Heo, Karsten Keil
Hi,
In drivers/isdn/hisax/isdnl2.c:l2_pull_iqueue() we have this:
...
skb = alloc_skb(oskb->len + i, GFP_ATOMIC);
memcpy(skb_put(skb, i), header, i);
...
If alloc_skb() fails and returns NULL then the second line will cause a
NULL pointer dereference - skb_put() gives the pointer to
skb_tail_pointer() which dereferences it.
I'm not quite sure how this should be dealt with, so I'll just report it
rather than submit a patch. Happy bug fixing :-)
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-02-02
From: David Miller @ 2011-02-03 21:07 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110202215322.GD2500-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 2 Feb 2011 16:53:22 -0500
> Here we have another big batch of updates destined for 2.6.39.
>
> A highlight is AP mode support for the wl12xx driver. There are
> also the usual updates to ath5k, ath9k, iwlwifi, rt2x00, and others.
> Also included are some wireless-2.6 pulls to correct for some build breakage.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
--
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] tcp: Increase the initial congestion window to 10.
From: H.K. Jerry Chu @ 2011-02-03 21:17 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: David Miller, netdev, dccp, therbert
In-Reply-To: <47859e9273bb0c1b2c32fc1adfa450ee@localhost>
On Thu, Feb 3, 2011 at 6:00 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
>
> On Wed, 02 Feb 2011 17:07:50 -0800 (PST), David Miller wrote:
>
>> +/* TCP initial congestion window */
>> +#define TCP_INIT_CWND 10
>> +
>
> Davem, there is _no_ research how this huge IW will behave in environments
> with a small BDP. Belief it or not, but there are networks out there with a
> BDP similar to ~1980. Why for heaven's sake should this work in these
> environments? There are only _two_ extensive analysis one from Cherry and
> and one from Ilpo. Both analysis focus on current mainstream BDP. I started
It's more than that. We have also conducted extensive, large scale
experiments covering
all BDP/RTT combinations and the result was documented in details in a
SIGCOMM/CCR paper that can be found from a summary page
http://code.google.com/speed/protocols/tcpm-IW10.html covering all our
IW10 work.
> 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?
Jerry
>
> HGN
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] ServerEngines, benet: Avoid potential null deref in be_cmd_get_seeprom_data()
From: Jesper Juhl @ 2011-02-03 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-drivers, linux-kernel, Ajit Khaparde, Sarveshwar Bandi,
Subbu Seetharaman, Sathya Perla
wrb_from_mccq() may return null, so we may crash on a null deref in
be_cmd_get_seeprom_data().
This avoids that potential crash.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
be_cmds.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 0c7811f..ec4a21d 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1786,6 +1786,8 @@ int be_cmd_get_seeprom_data(struct be_adapter *adapter,
spin_lock_bh(&adapter->mcc_lock);
wrb = wrb_from_mccq(adapter);
+ if (!wrb)
+ return -EBUSY;
req = nonemb_cmd->va;
sge = nonembedded_sgl(wrb);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* 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