Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread David Miller
From: David Miller 
Date: Wed, 15 May 2013 13:39:13 -0700 (PDT)

> From: Francois Romieu 
> Date: Wed, 15 May 2013 08:14:01 +0200
> 
>> Ken Moffat  :
>> [...]
>>>  Cc'ing to netdev because I don't think this has had a response, and
>> 
>> A patch has been sent to netdev a few hours ago. It needs more work,
>> especially testing (hint, hint) as I don't have a proven test case yet.
>> 
>> Please note:
>> - if you don't use a 8168evl (check your dmesg for the XID line emitted
>>   by the r8169 driver), you are not the experiencing the same bug.
>> - if you don't enable Tx checksum offload (distro/vendor dependent though
>>   disabled by default in the vanilla driver, see ethtool -k eth0,
>>   ethtool -K eth0 tx on sg on)), you are not the experiencing the same
>>   bug.
>> - if you are experiencing the same bug, 3.10-rc1 should work again
>>   after reverting e5195c1f31f399289347e043d6abf3ffa80f0005
>> 
>> If someone comes with a failing network capture and a working one, it will
>> save time. A 64 bytes (max) packet is not correctly transmitted.
> 
> FWIW, I was about to submit the regression causing commit to -stable
> but now I'm going to hold off until we get the fix for it to Linus.

Oh, I see, someone merged it behind my back.

Well, guys, now do you see why I let patches cook in Linus's tree for a
week or two before I submit them to Linus?

It's so that bugs like this are less likely to propagate, and we find
them such problems and fix them before a change hits -stable and
therefore has an effect on an even larger number of users.

Please, use the networking -stable submission process.  If you want a
patch merged, tell me, and I'll queue it up in patchwork.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread David Miller
From: Francois Romieu 
Date: Wed, 15 May 2013 08:14:01 +0200

> Ken Moffat  :
> [...]
>>  Cc'ing to netdev because I don't think this has had a response, and
> 
> A patch has been sent to netdev a few hours ago. It needs more work,
> especially testing (hint, hint) as I don't have a proven test case yet.
> 
> Please note:
> - if you don't use a 8168evl (check your dmesg for the XID line emitted
>   by the r8169 driver), you are not the experiencing the same bug.
> - if you don't enable Tx checksum offload (distro/vendor dependent though
>   disabled by default in the vanilla driver, see ethtool -k eth0,
>   ethtool -K eth0 tx on sg on)), you are not the experiencing the same
>   bug.
> - if you are experiencing the same bug, 3.10-rc1 should work again
>   after reverting e5195c1f31f399289347e043d6abf3ffa80f0005
> 
> If someone comes with a failing network capture and a working one, it will
> save time. A 64 bytes (max) packet is not correctly transmitted.

FWIW, I was about to submit the regression causing commit to -stable
but now I'm going to hold off until we get the fix for it to Linus.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread Ken Moffat
On Wed, May 15, 2013 at 08:14:01AM +0200, Francois Romieu wrote:
> Ken Moffat  :
> [...]
> >  Cc'ing to netdev because I don't think this has had a response, and
> 
> A patch has been sent to netdev a few hours ago. It needs more work,
> especially testing (hint, hint) as I don't have a proven test case yet.
> 
> Please note:
> - if you don't use a 8168evl (check your dmesg for the XID line emitted
>   by the r8169 driver), you are not the experiencing the same bug.
[3.174180] r8169 :02:00.0 eth0: RTL8168evl/8111evl at
0xc9008000, c8:60:00:97:07:35, XID 0c900800 IRQ 41

> - if you don't enable Tx checksum offload (distro/vendor dependent though
>   disabled by default in the vanilla driver, see ethtool -k eth0,
>   ethtool -K eth0 tx on sg on)), you are not the experiencing the same
>   bug.

 If it is disabled by default then my problem is different (I don't
have an ethtool program)

> - if you are experiencing the same bug, 3.10-rc1 should work again
>   after reverting e5195c1f31f399289347e043d6abf3ffa80f0005
> 
> If someone comes with a failing network capture and a working one, it will
> save time. A 64 bytes (max) packet is not correctly transmitted.
> 
> -- 
> Ueimor

 Thanks for the detailed comments, looks as if my intermittent
problem is something else.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread Francois Romieu
Ken Moffat  :
[...]
>  Cc'ing to netdev because I don't think this has had a response, and

A patch has been sent to netdev a few hours ago. It needs more work,
especially testing (hint, hint) as I don't have a proven test case yet.

Please note:
- if you don't use a 8168evl (check your dmesg for the XID line emitted
  by the r8169 driver), you are not the experiencing the same bug.
- if you don't enable Tx checksum offload (distro/vendor dependent though
  disabled by default in the vanilla driver, see ethtool -k eth0,
  ethtool -K eth0 tx on sg on)), you are not the experiencing the same
  bug.
- if you are experiencing the same bug, 3.10-rc1 should work again
  after reverting e5195c1f31f399289347e043d6abf3ffa80f0005

If someone comes with a failing network capture and a working one, it will
save time. A 64 bytes (max) packet is not correctly transmitted.

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread Francois Romieu
Ken Moffat zarniwh...@ntlworld.com :
[...]
  Cc'ing to netdev because I don't think this has had a response, and

A patch has been sent to netdev a few hours ago. It needs more work,
especially testing (hint, hint) as I don't have a proven test case yet.

Please note:
- if you don't use a 8168evl (check your dmesg for the XID line emitted
  by the r8169 driver), you are not the experiencing the same bug.
- if you don't enable Tx checksum offload (distro/vendor dependent though
  disabled by default in the vanilla driver, see ethtool -k eth0,
  ethtool -K eth0 tx on sg on)), you are not the experiencing the same
  bug.
- if you are experiencing the same bug, 3.10-rc1 should work again
  after reverting e5195c1f31f399289347e043d6abf3ffa80f0005

If someone comes with a failing network capture and a working one, it will
save time. A 64 bytes (max) packet is not correctly transmitted.

-- 
Ueimor
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread Ken Moffat
On Wed, May 15, 2013 at 08:14:01AM +0200, Francois Romieu wrote:
 Ken Moffat zarniwh...@ntlworld.com :
 [...]
   Cc'ing to netdev because I don't think this has had a response, and
 
 A patch has been sent to netdev a few hours ago. It needs more work,
 especially testing (hint, hint) as I don't have a proven test case yet.
 
 Please note:
 - if you don't use a 8168evl (check your dmesg for the XID line emitted
   by the r8169 driver), you are not the experiencing the same bug.
[3.174180] r8169 :02:00.0 eth0: RTL8168evl/8111evl at
0xc9008000, c8:60:00:97:07:35, XID 0c900800 IRQ 41

 - if you don't enable Tx checksum offload (distro/vendor dependent though
   disabled by default in the vanilla driver, see ethtool -k eth0,
   ethtool -K eth0 tx on sg on)), you are not the experiencing the same
   bug.

 If it is disabled by default then my problem is different (I don't
have an ethtool program)

 - if you are experiencing the same bug, 3.10-rc1 should work again
   after reverting e5195c1f31f399289347e043d6abf3ffa80f0005
 
 If someone comes with a failing network capture and a working one, it will
 save time. A 64 bytes (max) packet is not correctly transmitted.
 
 -- 
 Ueimor

 Thanks for the detailed comments, looks as if my intermittent
problem is something else.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread David Miller
From: Francois Romieu rom...@fr.zoreil.com
Date: Wed, 15 May 2013 08:14:01 +0200

 Ken Moffat zarniwh...@ntlworld.com :
 [...]
  Cc'ing to netdev because I don't think this has had a response, and
 
 A patch has been sent to netdev a few hours ago. It needs more work,
 especially testing (hint, hint) as I don't have a proven test case yet.
 
 Please note:
 - if you don't use a 8168evl (check your dmesg for the XID line emitted
   by the r8169 driver), you are not the experiencing the same bug.
 - if you don't enable Tx checksum offload (distro/vendor dependent though
   disabled by default in the vanilla driver, see ethtool -k eth0,
   ethtool -K eth0 tx on sg on)), you are not the experiencing the same
   bug.
 - if you are experiencing the same bug, 3.10-rc1 should work again
   after reverting e5195c1f31f399289347e043d6abf3ffa80f0005
 
 If someone comes with a failing network capture and a working one, it will
 save time. A 64 bytes (max) packet is not correctly transmitted.

FWIW, I was about to submit the regression causing commit to -stable
but now I'm going to hold off until we get the fix for it to Linus.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-15 Thread David Miller
From: David Miller da...@davemloft.net
Date: Wed, 15 May 2013 13:39:13 -0700 (PDT)

 From: Francois Romieu rom...@fr.zoreil.com
 Date: Wed, 15 May 2013 08:14:01 +0200
 
 Ken Moffat zarniwh...@ntlworld.com :
 [...]
  Cc'ing to netdev because I don't think this has had a response, and
 
 A patch has been sent to netdev a few hours ago. It needs more work,
 especially testing (hint, hint) as I don't have a proven test case yet.
 
 Please note:
 - if you don't use a 8168evl (check your dmesg for the XID line emitted
   by the r8169 driver), you are not the experiencing the same bug.
 - if you don't enable Tx checksum offload (distro/vendor dependent though
   disabled by default in the vanilla driver, see ethtool -k eth0,
   ethtool -K eth0 tx on sg on)), you are not the experiencing the same
   bug.
 - if you are experiencing the same bug, 3.10-rc1 should work again
   after reverting e5195c1f31f399289347e043d6abf3ffa80f0005
 
 If someone comes with a failing network capture and a working one, it will
 save time. A 64 bytes (max) packet is not correctly transmitted.
 
 FWIW, I was about to submit the regression causing commit to -stable
 but now I'm going to hold off until we get the fix for it to Linus.

Oh, I see, someone merged it behind my back.

Well, guys, now do you see why I let patches cook in Linus's tree for a
week or two before I submit them to Linus?

It's so that bugs like this are less likely to propagate, and we find
them such problems and fix them before a change hits -stable and
therefore has an effect on an even larger number of users.

Please, use the networking -stable submission process.  If you want a
patch merged, tell me, and I'll queue it up in patchwork.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-14 Thread Ken Moffat
On Fri, May 10, 2013 at 12:54:27PM +0200, Holger Hoffstaette wrote:

 Cc'ing to netdev because I don't think this has had a response, and
I care because I *might* be seeing the same problem on both 3.9.2
and 3.10-rc1, but my take on the problem is slightly different [
details after Holger's posting ]

> On Thu, 09 May 2013 15:31:23 -0700, Greg Kroah-Hartman wrote:
> 
> > This is the start of the stable review cycle for the 3.8.13 release. There
> 
> This patchset broke my internet, with all sorts of weird effects like
> Samba clients having problems to talk to the server and only partially
> working DNS resolution (CDNs broken, Amazon unreachable).
> 
> After two reboots to/from .12/.13 (to rule out temporary internet
> brokenness) the problem has been identified as:
> 
> > Stefan Bader 
> > r8169: fix 8168evl frame padding.
> 
> After reverting only this patch (turning r8169 back to 3.8.12) things
> again behave as expected with the rest of .13. So far no other regressions
> detected.
> 
> This patch should probably be removed from 3.9.2-rc as well.
> 
> -h
> 
 For me, I'm seeing what might be a similar problem in about 2/5 of
my boots of 3.9.2 and 3.10-rc1 : in my case, r8169 is a module [ most
things are built in ], I use dhclient to get an ip address, and I
have separate nfs shares for /sources [ in /etc/mtab ] and my user's
~/notes [ mounted from ~/.bashrc ].

 On a good boot, everything mounts.  On a bad boot, /sources is NOT
mounted because eth0 is not up, but by the time anyone logs in it
_is_ up so mounting ~/notes [and manually mounting /sources as root]
works.  What seems to be happening is that eth0 is coming up
slightly later on some occasions (about 11 seconds from booting,
instead of 10.5 seconds) and somehow the dhclient script seems to
have ended *before* that.

 For me, this isn't bisectable (so far, 10 boots of 3.9.2 and
3.10-rc1 on this box, and 4 were problematic).  On this box, 3.9.0
itself was perfect.

Holger : apologies if I've hijacked this thread with what turns out
to be a different problem.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

2013-05-14 Thread Ken Moffat
On Fri, May 10, 2013 at 12:54:27PM +0200, Holger Hoffstaette wrote:

 Cc'ing to netdev because I don't think this has had a response, and
I care because I *might* be seeing the same problem on both 3.9.2
and 3.10-rc1, but my take on the problem is slightly different [
details after Holger's posting ]

 On Thu, 09 May 2013 15:31:23 -0700, Greg Kroah-Hartman wrote:
 
  This is the start of the stable review cycle for the 3.8.13 release. There
 
 This patchset broke my internet, with all sorts of weird effects like
 Samba clients having problems to talk to the server and only partially
 working DNS resolution (CDNs broken, Amazon unreachable).
 
 After two reboots to/from .12/.13 (to rule out temporary internet
 brokenness) the problem has been identified as:
 
  Stefan Bader stefan.ba...@canonical.com
  r8169: fix 8168evl frame padding.
 
 After reverting only this patch (turning r8169 back to 3.8.12) things
 again behave as expected with the rest of .13. So far no other regressions
 detected.
 
 This patch should probably be removed from 3.9.2-rc as well.
 
 -h
 
 For me, I'm seeing what might be a similar problem in about 2/5 of
my boots of 3.9.2 and 3.10-rc1 : in my case, r8169 is a module [ most
things are built in ], I use dhclient to get an ip address, and I
have separate nfs shares for /sources [ in /etc/mtab ] and my user's
~/notes [ mounted from ~/.bashrc ].

 On a good boot, everything mounts.  On a bad boot, /sources is NOT
mounted because eth0 is not up, but by the time anyone logs in it
_is_ up so mounting ~/notes [and manually mounting /sources as root]
works.  What seems to be happening is that eth0 is coming up
slightly later on some occasions (about 11 seconds from booting,
instead of 10.5 seconds) and somehow the dhclient script seems to
have ended *before* that.

 For me, this isn't bisectable (so far, 10 boots of 3.9.2 and
3.10-rc1 on this box, and 4 were problematic).  On this box, 3.9.0
itself was perfect.

Holger : apologies if I've hijacked this thread with what turns out
to be a different problem.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ 00/73] 3.8.13-stable review

2013-05-11 Thread Satoru Takeuchi
At Thu,  9 May 2013 15:31:23 -0700,
Greg Kroah-Hartman wrote:
> 
> 
> NOTE:  This is the LAST 3.8.y kernel release to be done by me.  After
> this one, it is end-of-life.  You should have moved on to the 3.9.y
> kernel series by now.
> 
> 
> This is the start of the stable review cycle for the 3.8.13 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat May 11 22:26:18 UTC 2013.
> Anything received after that time might be too late.

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

 - Build Machine: debian wheezy x86_64
   CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   memory: 8GB

 - Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
   vCPU: x2
   memory: 2GB

I reviewed the following patches and it looks good to me.

> Chen Gang 
> kernel/audit_tree.c: tree will leak memory when failure occurs in 
> audit_trim_trees()
...
> Joerg Roedel 
> iommu/amd: Properly initialize irq-table lock

Thanks,
Satoru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ 00/73] 3.8.13-stable review

2013-05-11 Thread Satoru Takeuchi
At Thu,  9 May 2013 15:31:23 -0700,
Greg Kroah-Hartman wrote:
 
 
 NOTE:  This is the LAST 3.8.y kernel release to be done by me.  After
 this one, it is end-of-life.  You should have moved on to the 3.9.y
 kernel series by now.
 
 
 This is the start of the stable review cycle for the 3.8.13 release.
 There are 73 patches in this series, all will be posted as a response
 to this one.  If anyone has any issues with these being applied, please
 let me know.
 
 Responses should be made by Sat May 11 22:26:18 UTC 2013.
 Anything received after that time might be too late.

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

 - Build Machine: debian wheezy x86_64
   CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   memory: 8GB

 - Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
   vCPU: x2
   memory: 2GB

I reviewed the following patches and it looks good to me.

 Chen Gang gang.c...@asianux.com
 kernel/audit_tree.c: tree will leak memory when failure occurs in 
 audit_trim_trees()
...
 Joerg Roedel j...@8bytes.org
 iommu/amd: Properly initialize irq-table lock

Thanks,
Satoru
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ 00/73] 3.8.13-stable review

2013-05-10 Thread Shuah Khan
On Thu, 2013-05-09 at 15:31 -0700, Greg Kroah-Hartman wrote:
> 
> NOTE:  This is the LAST 3.8.y kernel release to be done by me.  After
> this one, it is end-of-life.  You should have moved on to the 3.9.y
> kernel series by now.
> 
> 
> This is the start of the stable review cycle for the 3.8.13 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat May 11 22:26:18 UTC 2013.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.13-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Patches applied cleanly to 3.0.77, 3.4.44, 3.8.12, and 3.9.1 

Compiled and booted on the following systems:

Samsung Series 9 900X4C Intel Corei5:
(3.4.45-rc1, 3.8.13-rc1, and 3.9.2-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.78-rc1, 3.4.45-rc1, 3.8.13-rc1, and 3.9.2-rc1)

dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.

Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.78-rc1, 3.4.45-rc1, 3.8.13-rc1, and 3.9.2-rc1)

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y, and 3.9.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, 3.8.y, and 3.9.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all 
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

thanks,
-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group 
Samsung Research America (Silicon Valley)
shuah...@samsung.com | (970) 672-0658

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [ 00/73] 3.8.13-stable review

2013-05-10 Thread Holger Hoffstaette
On Thu, 09 May 2013 15:31:23 -0700, Greg Kroah-Hartman wrote:

> This is the start of the stable review cycle for the 3.8.13 release. There

This patchset broke my internet, with all sorts of weird effects like
Samba clients having problems to talk to the server and only partially
working DNS resolution (CDNs broken, Amazon unreachable).

After two reboots to/from .12/.13 (to rule out temporary internet
brokenness) the problem has been identified as:

> Stefan Bader 
> r8169: fix 8168evl frame padding.

After reverting only this patch (turning r8169 back to 3.8.12) things
again behave as expected with the rest of .13. So far no other regressions
detected.

This patch should probably be removed from 3.9.2-rc as well.

-h


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ 00/73] 3.8.13-stable review

2013-05-10 Thread Holger Hoffstaette
On Thu, 09 May 2013 15:31:23 -0700, Greg Kroah-Hartman wrote:

 This is the start of the stable review cycle for the 3.8.13 release. There

This patchset broke my internet, with all sorts of weird effects like
Samba clients having problems to talk to the server and only partially
working DNS resolution (CDNs broken, Amazon unreachable).

After two reboots to/from .12/.13 (to rule out temporary internet
brokenness) the problem has been identified as:

 Stefan Bader stefan.ba...@canonical.com
 r8169: fix 8168evl frame padding.

After reverting only this patch (turning r8169 back to 3.8.12) things
again behave as expected with the rest of .13. So far no other regressions
detected.

This patch should probably be removed from 3.9.2-rc as well.

-h


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ 00/73] 3.8.13-stable review

2013-05-10 Thread Shuah Khan
On Thu, 2013-05-09 at 15:31 -0700, Greg Kroah-Hartman wrote:
 
 NOTE:  This is the LAST 3.8.y kernel release to be done by me.  After
 this one, it is end-of-life.  You should have moved on to the 3.9.y
 kernel series by now.
 
 
 This is the start of the stable review cycle for the 3.8.13 release.
 There are 73 patches in this series, all will be posted as a response
 to this one.  If anyone has any issues with these being applied, please
 let me know.
 
 Responses should be made by Sat May 11 22:26:18 UTC 2013.
 Anything received after that time might be too late.
 
 The whole patch series can be found in one patch at:
   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.13-rc1.gz
 and the diffstat can be found below.
 
 thanks,
 
 greg k-h

Patches applied cleanly to 3.0.77, 3.4.44, 3.8.12, and 3.9.1 

Compiled and booted on the following systems:

Samsung Series 9 900X4C Intel Corei5:
(3.4.45-rc1, 3.8.13-rc1, and 3.9.2-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.78-rc1, 3.4.45-rc1, 3.8.13-rc1, and 3.9.2-rc1)

dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.

Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.78-rc1, 3.4.45-rc1, 3.8.13-rc1, and 3.9.2-rc1)

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y, and 3.9.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, 3.8.y, and 3.9.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all 
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

thanks,
-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group 
Samsung Research America (Silicon Valley)
shuah...@samsung.com | (970) 672-0658

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

[ 00/73] 3.8.13-stable review

2013-05-09 Thread Greg Kroah-Hartman

NOTE:  This is the LAST 3.8.y kernel release to be done by me.  After
this one, it is end-of-life.  You should have moved on to the 3.9.y
kernel series by now.


This is the start of the stable review cycle for the 3.8.13 release.
There are 73 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat May 11 22:26:18 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.13-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.8.13-rc1

Jerry Hoemann 
x86/mm: account for PGDIR_SIZE alignment

Chen Gang 
kernel/audit_tree.c: tree will leak memory when failure occurs in 
audit_trim_trees()

Trond Myklebust 
NFSv4.x: Fix handling of partially delegated locks

Srivatsa S. Bhat 
EDAC: Don't give write permission to read-only files

Josef Bacik 
Btrfs: fix extent logging with O_DIRECT into prealloc

Josef Bacik 
Btrfs: compare relevant parts of delayed tree refs

Steven Rostedt (Red Hat) 
tracing: Fix ftrace_dump()

Alex Deucher 
drm/radeon: fix handling of v6 power tables

Alex Deucher 
drm/radeon: add new richland pci ids

Alex Deucher 
drm/radeon: fix possible segfault when parsing pm tables

Alex Deucher 
drm/radeon: fix endian bugs in atom_allocate_fb_scratch()

Alex Deucher 
drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)

Jerome Glisse 
drm/radeon: Always flush the VM

Alex Deucher 
drm/radeon: fix typo in si_select_se_sh()

Alex Deucher 
drm/radeon: fix hdmi mode enable on RS600/RS690/RS740

Alex Deucher 
drm/radeon: cleanup properly if mmio mapping fails

Alex Deucher 
drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS

Alex Deucher 
drm/radeon: add some new SI PCI ids

Alex Deucher 
drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)

Alex Deucher 
drm/radeon: update wait_for_vblank for r1xx-r4xx

Alex Deucher 
drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx

Alex Deucher 
drm/radeon: properly lock disp in mc_stop/resume for evergreen+

Alex Deucher 
drm/radeon: update wait_for_vblank for evergreen+

Alex Deucher 
drm/radeon: update wait_for_vblank for r5xx-r7xx

Alex Deucher 
drm/radeon/dce6: add missing display reg for tiling setup

Alex Deucher 
drm/radeon: fix typo in rv515_mc_resume()

Alex Deucher 
drm/radeon: use frac fb div on RS780/RS880

Alex Deucher 
drm/radeon: don't use get_engine_clock() on APUs

David Müller 
drm/i915: Fall back to bit banging mode for DVO transmitter detection

Daniel Vetter 
drm/i915: Fixup Oops in the pipe config computation

Jani Nikula 
drm/i915: ensure single initialization and cleanup of backlight device

Paulo Zanoni 
drm/i915: set CPT FDI RX polarity bits based on VBT

Chris Wilson 
drm/i915: Use MLC (l3$) for context objects

Chris Wilson 
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

Egbert Eich 
drm/i915: Fix SDVO connector and encoder get_hw_state functions

Christian Lamparter 
drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

Daniel Vetter 
drm/i915: Fix sdvo connector get_hw_state function

Chris Wilson 
drm/i915: Fix detection of base of stolen memory

Dave Airlie 
drm/ast: deal with bo reserve fail in dirty update path

Dave Airlie 
drm/prime: keep a reference from the handle to exported dma-buf (v6)

Anisse Astier 
drm/gma500: fix backlight hotkeys behaviour on netbooks

Dave Airlie 
drm/mgag200: deal with bo reserve fail in dirty update path

Dave Airlie 
drm/cirrus: deal with bo reserve fail in dirty update path

James Bottomley 
block: fix max discard sectors limit

Catalin Marinas 
arm64: Ignore the 'write' ESR flag on cache maintenance faults

Thadeu Lima de Souza Cascardo 
RDMA/cxgb4: Fix SQ allocation when on-chip SQ is disabled

Stefan Bader 
r8169: fix 8168evl frame padding.

Theodore Ts'o 
ext4: add check for inodes_count overflow in new resize ioctl

Matthias Schiffer 
netfilter: ip6t_NPT: Fix translation for non-multiple of 32 prefix lengths

Florian Westphal 
netfilter: xt_rpfilter: skip locally generated broadcast/multicast, too

Florian Westphal 
netfilter: ctnetlink: don't permit ct creation with random tuple

Florian Westphal 
netfilter: nf_ct_helper: don't discard helper if it is actually the same

Jozsef Kadlecsik 
netfilter: ipset: "Directory not empty" error message

Patrick McHardy 
netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the 
packet

Jozsef Kadlecsik 
netfilter: ipset: list:set: fix reference counter update

Florian Westphal 
netfilter: 

[ 00/73] 3.8.13-stable review

2013-05-09 Thread Greg Kroah-Hartman

NOTE:  This is the LAST 3.8.y kernel release to be done by me.  After
this one, it is end-of-life.  You should have moved on to the 3.9.y
kernel series by now.


This is the start of the stable review cycle for the 3.8.13 release.
There are 73 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat May 11 22:26:18 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.13-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman gre...@linuxfoundation.org
Linux 3.8.13-rc1

Jerry Hoemann jerry.hoem...@hp.com
x86/mm: account for PGDIR_SIZE alignment

Chen Gang gang.c...@asianux.com
kernel/audit_tree.c: tree will leak memory when failure occurs in 
audit_trim_trees()

Trond Myklebust trond.mykleb...@netapp.com
NFSv4.x: Fix handling of partially delegated locks

Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
EDAC: Don't give write permission to read-only files

Josef Bacik jba...@fusionio.com
Btrfs: fix extent logging with O_DIRECT into prealloc

Josef Bacik jba...@fusionio.com
Btrfs: compare relevant parts of delayed tree refs

Steven Rostedt (Red Hat) rost...@goodmis.org
tracing: Fix ftrace_dump()

Alex Deucher alexander.deuc...@amd.com
drm/radeon: fix handling of v6 power tables

Alex Deucher alexander.deuc...@amd.com
drm/radeon: add new richland pci ids

Alex Deucher alexander.deuc...@amd.com
drm/radeon: fix possible segfault when parsing pm tables

Alex Deucher alexander.deuc...@amd.com
drm/radeon: fix endian bugs in atom_allocate_fb_scratch()

Alex Deucher alexander.deuc...@amd.com
drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2)

Jerome Glisse jgli...@redhat.com
drm/radeon: Always flush the VM

Alex Deucher alexander.deuc...@amd.com
drm/radeon: fix typo in si_select_se_sh()

Alex Deucher alexander.deuc...@amd.com
drm/radeon: fix hdmi mode enable on RS600/RS690/RS740

Alex Deucher alexander.deuc...@amd.com
drm/radeon: cleanup properly if mmio mapping fails

Alex Deucher alexander.deuc...@amd.com
drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS

Alex Deucher alexander.deuc...@amd.com
drm/radeon: add some new SI PCI ids

Alex Deucher alexander.deuc...@amd.com
drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2)

Alex Deucher alexander.deuc...@amd.com
drm/radeon: update wait_for_vblank for r1xx-r4xx

Alex Deucher alexander.deuc...@amd.com
drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx

Alex Deucher alexander.deuc...@amd.com
drm/radeon: properly lock disp in mc_stop/resume for evergreen+

Alex Deucher alexander.deuc...@amd.com
drm/radeon: update wait_for_vblank for evergreen+

Alex Deucher alexander.deuc...@amd.com
drm/radeon: update wait_for_vblank for r5xx-r7xx

Alex Deucher alexander.deuc...@amd.com
drm/radeon/dce6: add missing display reg for tiling setup

Alex Deucher alexander.deuc...@amd.com
drm/radeon: fix typo in rv515_mc_resume()

Alex Deucher alexander.deuc...@amd.com
drm/radeon: use frac fb div on RS780/RS880

Alex Deucher alexander.deuc...@amd.com
drm/radeon: don't use get_engine_clock() on APUs

David Müller d.muel...@elsoft.ch
drm/i915: Fall back to bit banging mode for DVO transmitter detection

Daniel Vetter daniel.vet...@ffwll.ch
drm/i915: Fixup Oops in the pipe config computation

Jani Nikula jani.nik...@intel.com
drm/i915: ensure single initialization and cleanup of backlight device

Paulo Zanoni paulo.r.zan...@intel.com
drm/i915: set CPT FDI RX polarity bits based on VBT

Chris Wilson ch...@chris-wilson.co.uk
drm/i915: Use MLC (l3$) for context objects

Chris Wilson ch...@chris-wilson.co.uk
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

Egbert Eich e...@suse.de
drm/i915: Fix SDVO connector and encoder get_hw_state functions

Christian Lamparter chunk...@googlemail.com
drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

Daniel Vetter daniel.vet...@ffwll.ch
drm/i915: Fix sdvo connector get_hw_state function

Chris Wilson ch...@chris-wilson.co.uk
drm/i915: Fix detection of base of stolen memory

Dave Airlie airl...@redhat.com
drm/ast: deal with bo reserve fail in dirty update path

Dave Airlie airl...@gmail.com
drm/prime: keep a reference from the handle to exported dma-buf (v6)

Anisse Astier ani...@astier.eu
drm/gma500: fix backlight hotkeys behaviour on netbooks

Dave Airlie airl...@redhat.com
drm/mgag200: deal with bo reserve fail in dirty update path

Dave Airlie airl...@redhat.com
drm/cirrus: deal with bo reserve fail in dirty update path

James Bottomley jbottom...@parallels.com