Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check

[Ian Kumlien]

On Thu, Dec 17, 2020 at 12:21 AM Bjorn Helgaas  wrote:
>
> On Wed, Dec 16, 2020 at 12:20:53PM +0100, Ian Kumlien wrote:
> > On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas  wrote:
> > > On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > > > On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas  
> > > > wrote:
> > > > > On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > > > > > On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas  
> > > > > > wrote:
> > > > >
> > > > > > > If you're interested, you could probably unload the Realtek 
> > > > > > > drivers,
> > > > > > > remove the devices, and set the PCI_EXP_LNKCTL_LD (Link Disable) 
> > > > > > > bit
> > > > > > > in 02:04.0, e.g.,
> > > > > > >
> > > > > > >   # 
> > > > > > > RT=/sys/devices/pci:00/:00:01.2/:01:00.0/:02:04.0
> > > > > > >   # echo 1 > $RT/:04:00.0/remove
> > > > > > >   # echo 1 > $RT/:04:00.1/remove
> > > > > > >   # echo 1 > $RT/:04:00.2/remove
> > > > > > >   # echo 1 > $RT/:04:00.4/remove
> > > > > > >   # echo 1 > $RT/:04:00.7/remove
> > > > > > >   # setpci -s02:04.0 CAP_EXP+0x10.w=0x0010
> > > > > > >
> > > > > > > That should take 04:00.x out of the picture.
> > > > > >
> > > > > > Didn't actually change the behaviour, I'm suspecting an errata for 
> > > > > > AMD pcie...
> > > > > >
> > > > > > So did this, with unpatched kernel:
> > > > > > [ ID] Interval   Transfer Bitrate Retr  Cwnd
> > > > > > [  5]   0.00-1.00   sec  4.56 MBytes  38.2 Mbits/sec0   67.9 
> > > > > > KBytes
> > > > > > [  5]   1.00-2.00   sec  4.47 MBytes  37.5 Mbits/sec0   96.2 
> > > > > > KBytes
> > > > > > [  5]   2.00-3.00   sec  4.85 MBytes  40.7 Mbits/sec0   50.9 
> > > > > > KBytes
> > > > > > [  5]   3.00-4.00   sec  4.23 MBytes  35.4 Mbits/sec0   70.7 
> > > > > > KBytes
> > > > > > [  5]   4.00-5.00   sec  4.23 MBytes  35.4 Mbits/sec0   48.1 
> > > > > > KBytes
> > > > > > [  5]   5.00-6.00   sec  4.23 MBytes  35.4 Mbits/sec0   45.2 
> > > > > > KBytes
> > > > > > [  5]   6.00-7.00   sec  4.23 MBytes  35.4 Mbits/sec0   36.8 
> > > > > > KBytes
> > > > > > [  5]   7.00-8.00   sec  3.98 MBytes  33.4 Mbits/sec0   36.8 
> > > > > > KBytes
> > > > > > [  5]   8.00-9.00   sec  4.23 MBytes  35.4 Mbits/sec0   36.8 
> > > > > > KBytes
> > > > > > [  5]   9.00-10.00  sec  4.23 MBytes  35.4 Mbits/sec0   48.1 
> > > > > > KBytes
> > > > > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > > > [ ID] Interval   Transfer Bitrate Retr
> > > > > > [  5]   0.00-10.00  sec  43.2 MBytes  36.2 Mbits/sec0   
> > > > > >   sender
> > > > > > [  5]   0.00-10.00  sec  42.7 MBytes  35.8 Mbits/sec
> > > > > >   receiver
> > > > > >
> > > > > > and:
> > > > > > echo 0 > 
> > > > > > /sys/devices/pci:00/:00:01.2/:01:00.0/link/l1_aspm
> > > > >
> > > > > BTW, thanks a lot for testing out the "l1_aspm" sysfs file.  I'm very
> > > > > pleased that it seems to be working as intended.
> > > >
> > > > It was nice to find it for easy disabling :)
> > > >
> > > > > > and:
> > > > > > [ ID] Interval   Transfer Bitrate Retr  Cwnd
> > > > > > [  5]   0.00-1.00   sec   113 MBytes   951 Mbits/sec  153772 
> > > > > > KBytes
> > > > > > [  5]   1.00-2.00   sec   109 MBytes   912 Mbits/sec  276550 
> > > > > > KBytes
> > > > > > [  5]   2.00-3.00   sec   111 MBytes   933 Mbits/sec  123625 
> > > > > > KBytes
> > > > > > [  5]   3.00-4.00   sec   111 MBytes   933 Mbits/sec   31687 
> > > > > > KBytes
> > &g

Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check

[Ian Kumlien]

On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas  wrote:
>
> On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas  wrote:
> > >
> > > On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > > > On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas  
> > > > wrote:
> > >
> > > > > If you're interested, you could probably unload the Realtek drivers,
> > > > > remove the devices, and set the PCI_EXP_LNKCTL_LD (Link Disable) bit
> > > > > in 02:04.0, e.g.,
> > > > >
> > > > >   # RT=/sys/devices/pci:00/:00:01.2/:01:00.0/:02:04.0
> > > > >   # echo 1 > $RT/:04:00.0/remove
> > > > >   # echo 1 > $RT/:04:00.1/remove
> > > > >   # echo 1 > $RT/:04:00.2/remove
> > > > >   # echo 1 > $RT/:04:00.4/remove
> > > > >   # echo 1 > $RT/:04:00.7/remove
> > > > >   # setpci -s02:04.0 CAP_EXP+0x10.w=0x0010
> > > > >
> > > > > That should take 04:00.x out of the picture.
> > > >
> > > > Didn't actually change the behaviour, I'm suspecting an errata for AMD 
> > > > pcie...
> > > >
> > > > So did this, with unpatched kernel:
> > > > [ ID] Interval   Transfer Bitrate Retr  Cwnd
> > > > [  5]   0.00-1.00   sec  4.56 MBytes  38.2 Mbits/sec0   67.9 KBytes
> > > > [  5]   1.00-2.00   sec  4.47 MBytes  37.5 Mbits/sec0   96.2 KBytes
> > > > [  5]   2.00-3.00   sec  4.85 MBytes  40.7 Mbits/sec0   50.9 KBytes
> > > > [  5]   3.00-4.00   sec  4.23 MBytes  35.4 Mbits/sec0   70.7 KBytes
> > > > [  5]   4.00-5.00   sec  4.23 MBytes  35.4 Mbits/sec0   48.1 KBytes
> > > > [  5]   5.00-6.00   sec  4.23 MBytes  35.4 Mbits/sec0   45.2 KBytes
> > > > [  5]   6.00-7.00   sec  4.23 MBytes  35.4 Mbits/sec0   36.8 KBytes
> > > > [  5]   7.00-8.00   sec  3.98 MBytes  33.4 Mbits/sec0   36.8 KBytes
> > > > [  5]   8.00-9.00   sec  4.23 MBytes  35.4 Mbits/sec0   36.8 KBytes
> > > > [  5]   9.00-10.00  sec  4.23 MBytes  35.4 Mbits/sec0   48.1 KBytes
> > > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > [ ID] Interval   Transfer Bitrate Retr
> > > > [  5]   0.00-10.00  sec  43.2 MBytes  36.2 Mbits/sec0 
> > > > sender
> > > > [  5]   0.00-10.00  sec  42.7 MBytes  35.8 Mbits/sec  
> > > > receiver
> > > >
> > > > and:
> > > > echo 0 > /sys/devices/pci:00/:00:01.2/:01:00.0/link/l1_aspm
> > >
> > > BTW, thanks a lot for testing out the "l1_aspm" sysfs file.  I'm very
> > > pleased that it seems to be working as intended.
> >
> > It was nice to find it for easy disabling :)
> >
> > > > and:
> > > > [ ID] Interval   Transfer Bitrate Retr  Cwnd
> > > > [  5]   0.00-1.00   sec   113 MBytes   951 Mbits/sec  153772 KBytes
> > > > [  5]   1.00-2.00   sec   109 MBytes   912 Mbits/sec  276550 KBytes
> > > > [  5]   2.00-3.00   sec   111 MBytes   933 Mbits/sec  123625 KBytes
> > > > [  5]   3.00-4.00   sec   111 MBytes   933 Mbits/sec   31687 KBytes
> > > > [  5]   4.00-5.00   sec   110 MBytes   923 Mbits/sec0679 KBytes
> > > > [  5]   5.00-6.00   sec   110 MBytes   923 Mbits/sec  136577 KBytes
> > > > [  5]   6.00-7.00   sec   110 MBytes   923 Mbits/sec  214645 KBytes
> > > > [  5]   7.00-8.00   sec   110 MBytes   923 Mbits/sec   32628 KBytes
> > > > [  5]   8.00-9.00   sec   110 MBytes   923 Mbits/sec   81537 KBytes
> > > > [  5]   9.00-10.00  sec   110 MBytes   923 Mbits/sec   10577 KBytes
> > > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > [ ID] Interval   Transfer Bitrate Retr
> > > > [  5]   0.00-10.00  sec  1.08 GBytes   927 Mbits/sec  1056 
> > > > sender
> > > > [  5]   0.00-10.00  sec  1.07 GBytes   923 Mbits/sec  
> > > > receiver
> > > >
> > > > But this only confirms that the fix i experience is a side effect.
> > > >
> > > > The original code is still wrong :)
> > >
> > > What exactly is this machine?  Brand, model, config?  Maybe you could
> > > add this and a dmesg log to the buzilla?  It seems li

Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check

[Ian Kumlien]

On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas  wrote:
>
> On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas  wrote:
>
> > > If you're interested, you could probably unload the Realtek drivers,
> > > remove the devices, and set the PCI_EXP_LNKCTL_LD (Link Disable) bit
> > > in 02:04.0, e.g.,
> > >
> > >   # RT=/sys/devices/pci:00/:00:01.2/:01:00.0/:02:04.0
> > >   # echo 1 > $RT/:04:00.0/remove
> > >   # echo 1 > $RT/:04:00.1/remove
> > >   # echo 1 > $RT/:04:00.2/remove
> > >   # echo 1 > $RT/:04:00.4/remove
> > >   # echo 1 > $RT/:04:00.7/remove
> > >   # setpci -s02:04.0 CAP_EXP+0x10.w=0x0010
> > >
> > > That should take 04:00.x out of the picture.
> >
> > Didn't actually change the behaviour, I'm suspecting an errata for AMD 
> > pcie...
> >
> > So did this, with unpatched kernel:
> > [ ID] Interval   Transfer Bitrate Retr  Cwnd
> > [  5]   0.00-1.00   sec  4.56 MBytes  38.2 Mbits/sec0   67.9 KBytes
> > [  5]   1.00-2.00   sec  4.47 MBytes  37.5 Mbits/sec0   96.2 KBytes
> > [  5]   2.00-3.00   sec  4.85 MBytes  40.7 Mbits/sec0   50.9 KBytes
> > [  5]   3.00-4.00   sec  4.23 MBytes  35.4 Mbits/sec0   70.7 KBytes
> > [  5]   4.00-5.00   sec  4.23 MBytes  35.4 Mbits/sec0   48.1 KBytes
> > [  5]   5.00-6.00   sec  4.23 MBytes  35.4 Mbits/sec0   45.2 KBytes
> > [  5]   6.00-7.00   sec  4.23 MBytes  35.4 Mbits/sec0   36.8 KBytes
> > [  5]   7.00-8.00   sec  3.98 MBytes  33.4 Mbits/sec0   36.8 KBytes
> > [  5]   8.00-9.00   sec  4.23 MBytes  35.4 Mbits/sec0   36.8 KBytes
> > [  5]   9.00-10.00  sec  4.23 MBytes  35.4 Mbits/sec0   48.1 KBytes
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > [ ID] Interval   Transfer Bitrate Retr
> > [  5]   0.00-10.00  sec  43.2 MBytes  36.2 Mbits/sec0 sender
> > [  5]   0.00-10.00  sec  42.7 MBytes  35.8 Mbits/sec  
> > receiver
> >
> > and:
> > echo 0 > /sys/devices/pci:00/:00:01.2/:01:00.0/link/l1_aspm
>
> BTW, thanks a lot for testing out the "l1_aspm" sysfs file.  I'm very
> pleased that it seems to be working as intended.

It was nice to find it for easy disabling :)

> > and:
> > [ ID] Interval   Transfer Bitrate Retr  Cwnd
> > [  5]   0.00-1.00   sec   113 MBytes   951 Mbits/sec  153772 KBytes
> > [  5]   1.00-2.00   sec   109 MBytes   912 Mbits/sec  276550 KBytes
> > [  5]   2.00-3.00   sec   111 MBytes   933 Mbits/sec  123625 KBytes
> > [  5]   3.00-4.00   sec   111 MBytes   933 Mbits/sec   31687 KBytes
> > [  5]   4.00-5.00   sec   110 MBytes   923 Mbits/sec0679 KBytes
> > [  5]   5.00-6.00   sec   110 MBytes   923 Mbits/sec  136577 KBytes
> > [  5]   6.00-7.00   sec   110 MBytes   923 Mbits/sec  214645 KBytes
> > [  5]   7.00-8.00   sec   110 MBytes   923 Mbits/sec   32628 KBytes
> > [  5]   8.00-9.00   sec   110 MBytes   923 Mbits/sec   81537 KBytes
> > [  5]   9.00-10.00  sec   110 MBytes   923 Mbits/sec   10577 KBytes
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > [ ID] Interval   Transfer Bitrate Retr
> > [  5]   0.00-10.00  sec  1.08 GBytes   927 Mbits/sec  1056 
> > sender
> > [  5]   0.00-10.00  sec  1.07 GBytes   923 Mbits/sec  
> > receiver
> >
> > But this only confirms that the fix i experience is a side effect.
> >
> > The original code is still wrong :)
>
> What exactly is this machine?  Brand, model, config?  Maybe you could
> add this and a dmesg log to the buzilla?  It seems like other people
> should be seeing the same problem, so I'm hoping to grub around on the
> web to see if there are similar reports involving these devices.

ASUS Pro WS X570-ACE with AMD Ryzen 9 3900X

> https://bugzilla.kernel.org/show_bug.cgi?id=209725
>
> Here's one that is superficially similar:
> https://linux-hardware.org/index.php?probe=e5f24075e5=lspci_all
> in that it has a RP -- switch -- I211 path.  Interestingly, the switch
> here advertises <64us L1 exit latency instead of the <32us latency
> your switch advertises.  Of course, I can't tell if it's exactly the
> same switch.

Same chipset it seems

I'm running bios version:
Version: 2206
Release Date: 08/13/2020

ANd latest is:
Version 3003
2020/12/07

Will test upgrading that as well, but it could be that they report the
incorrect latency of the switch - I don't know how many things AGESA
changes but... It's been updated twice since my upgrade.

> Bjorn

Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check

[Ian Kumlien]

On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas  wrote:
>
> On Mon, Dec 14, 2020 at 04:47:32PM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 3:02 PM Bjorn Helgaas  wrote:
> > > On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> > > > On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas  
> > > > wrote:
> > > > >
> > > > > [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
> > > > > issue with I211 or Realtek NICs.  Beginning of thread:
> > > > > https://lore.kernel.org/r/20201024205548.1837770-1-ian.kuml...@gmail.com
> > > > >
> > > > > Short story: Ian has:
> > > > >
> > > > >   Root Port --- Switch --- I211 NIC
> > > > >\-- multifunction Realtek NIC, etc
> > > > >
> > > > > and the I211 performance is poor with ASPM L1 enabled on both links
> > > > > in the path to it.  The patch here disables ASPM on the upstream link
> > > > > and fixes the performance, but AFAICT the devices in that path give us
> > > > > no reason to disable L1.  If I understand the spec correctly, the
> > > > > Realtek device should not be relevant to the I211 path.]
> > > > >
> > > > > On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
> > > > > > On Sun, Dec 13, 2020 at 12:47 AM Bjorn Helgaas  
> > > > > > wrote:
> > > > > > > On Sat, Oct 24, 2020 at 10:55:46PM +0200, Ian Kumlien wrote:
> > > > > > > > Make pcie_aspm_check_latency comply with the PCIe spec, 
> > > > > > > > specifically:
> > > > > > > > "5.4.1.2.2. Exit from the L1 State"
> > > > > > > >
> > > > > > > > Which makes it clear that each switch is required to
> > > > > > > > initiate a transition within 1μs from receiving it,
> > > > > > > > accumulating this latency and then we have to wait for the
> > > > > > > > slowest link along the path before entering L0 state from
> > > > > > > > L1.
> > > > > > > > ...
> > > > > > >
> > > > > > > > On my specific system:
> > > > > > > > 03:00.0 Ethernet controller: Intel Corporation I211 Gigabit 
> > > > > > > > Network Connection (rev 03)
> > > > > > > > 04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., 
> > > > > > > > Ltd. Device 816e (rev 1a)
> > > > > > > >
> > > > > > > > Exit latency   Acceptable latency
> > > > > > > > Tree:   L1   L0s   L1   L0s
> > > > > > > > --  ---  - ---  --
> > > > > > > > 00:01.2 <32 us   -
> > > > > > > > | 01:00.0   <32 us   -
> > > > > > > > |- 02:03.0  <32 us   -
> > > > > > > > | \03:00.0  <16 us   <2us  <64 us   <512ns
> > > > > > > > |
> > > > > > > > \- 02:04.0  <32 us   -
> > > > > > > >   \04:00.0  <64 us   unlimited <64 us   <512ns
> > > > > > > >
> > > > > > > > 04:00.0's latency is the same as the maximum it allows so as
> > > > > > > > we walk the path the first switchs startup latency will pass
> > > > > > > > the acceptable latency limit for the link, and as a
> > > > > > > > side-effect it fixes my issues with 03:00.0.
> > > > > > > >
> > > > > > > > Without this patch, 03:00.0 misbehaves and only gives me ~40
> > > > > > > > mbit/s over links with 6 or more hops. With this patch I'm
> > > > > > > > back to a maximum of ~933 mbit/s.
> > > > > > >
> > > > > > > There are two paths here that share a Link:
> > > > > > >
> > > > > > >   00:01.2 --- 01:00.0 -- 02:03.0 --- 03:00.0 I211 NIC
> > > > > > >   00:01.2 --- 01:00.0 -- 02:04.0 --- 04:00.x multifunction Realtek
> > > > > > >
> > > > > > > 1) The path to the I211 NIC includes four Ports and two Links (the
> > > > > > >connection between 01:00.0 and 02:03.0 is internal Switch 
>

Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check

[Ian Kumlien]

On Mon, Dec 14, 2020 at 3:02 PM Bjorn Helgaas  wrote:
>
> On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas  wrote:
> > >
> > > [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
> > > issue with I211 or Realtek NICs.  Beginning of thread:
> > > https://lore.kernel.org/r/20201024205548.1837770-1-ian.kuml...@gmail.com
> > >
> > > Short story: Ian has:
> > >
> > >   Root Port --- Switch --- I211 NIC
> > >\-- multifunction Realtek NIC, etc
> > >
> > > and the I211 performance is poor with ASPM L1 enabled on both links
> > > in the path to it.  The patch here disables ASPM on the upstream link
> > > and fixes the performance, but AFAICT the devices in that path give us
> > > no reason to disable L1.  If I understand the spec correctly, the
> > > Realtek device should not be relevant to the I211 path.]
> > >
> > > On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
> > > > On Sun, Dec 13, 2020 at 12:47 AM Bjorn Helgaas  
> > > > wrote:
> > > > > On Sat, Oct 24, 2020 at 10:55:46PM +0200, Ian Kumlien wrote:
> > > > > > Make pcie_aspm_check_latency comply with the PCIe spec, 
> > > > > > specifically:
> > > > > > "5.4.1.2.2. Exit from the L1 State"
> > > > > >
> > > > > > Which makes it clear that each switch is required to
> > > > > > initiate a transition within 1μs from receiving it,
> > > > > > accumulating this latency and then we have to wait for the
> > > > > > slowest link along the path before entering L0 state from
> > > > > > L1.
> > > > > > ...
> > > > >
> > > > > > On my specific system:
> > > > > > 03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network 
> > > > > > Connection (rev 03)
> > > > > > 04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. 
> > > > > > Device 816e (rev 1a)
> > > > > >
> > > > > > Exit latency   Acceptable latency
> > > > > > Tree:   L1   L0s   L1   L0s
> > > > > > --  ---  - ---  --
> > > > > > 00:01.2 <32 us   -
> > > > > > | 01:00.0   <32 us   -
> > > > > > |- 02:03.0  <32 us   -
> > > > > > | \03:00.0  <16 us   <2us  <64 us   <512ns
> > > > > > |
> > > > > > \- 02:04.0  <32 us   -
> > > > > >   \04:00.0  <64 us   unlimited <64 us   <512ns
> > > > > >
> > > > > > 04:00.0's latency is the same as the maximum it allows so as
> > > > > > we walk the path the first switchs startup latency will pass
> > > > > > the acceptable latency limit for the link, and as a
> > > > > > side-effect it fixes my issues with 03:00.0.
> > > > > >
> > > > > > Without this patch, 03:00.0 misbehaves and only gives me ~40
> > > > > > mbit/s over links with 6 or more hops. With this patch I'm
> > > > > > back to a maximum of ~933 mbit/s.
> > > > >
> > > > > There are two paths here that share a Link:
> > > > >
> > > > >   00:01.2 --- 01:00.0 -- 02:03.0 --- 03:00.0 I211 NIC
> > > > >   00:01.2 --- 01:00.0 -- 02:04.0 --- 04:00.x multifunction Realtek
> > > > >
> > > > > 1) The path to the I211 NIC includes four Ports and two Links (the
> > > > >connection between 01:00.0 and 02:03.0 is internal Switch routing,
> > > > >not a Link).
> > > >
> > > > >The Ports advertise L1 exit latencies of <32us, <32us, <32us,
> > > > ><16us.  If both Links are in L1 and 03:00.0 initiates L1 exit at T,
> > > > >01:00.0 initiates L1 exit at T + 1.  A TLP from 03:00.0 may see up
> > > > >to 1 + 32 = 33us of L1 exit latency.
> > > > >
> > > > >The NIC can tolerate up to 64us of L1 exit latency, so it is safe
> > > > >to enable L1 for both Links.
> > > > >
> > > > > 2) The path to the Realtek device is similar except that the Realtek
> > > > >L1 exit latency is <64us.  If both Links are in L1 a

Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check

[Ian Kumlien]

On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas  wrote:
>
> [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
> issue with I211 or Realtek NICs.  Beginning of thread:
> https://lore.kernel.org/r/20201024205548.1837770-1-ian.kuml...@gmail.com
>
> Short story: Ian has:
>
>   Root Port --- Switch --- I211 NIC
>\-- multifunction Realtek NIC, etc
>
> and the I211 performance is poor with ASPM L1 enabled on both links
> in the path to it.  The patch here disables ASPM on the upstream link
> and fixes the performance, but AFAICT the devices in that path give us
> no reason to disable L1.  If I understand the spec correctly, the
> Realtek device should not be relevant to the I211 path.]
>
> On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
> > On Sun, Dec 13, 2020 at 12:47 AM Bjorn Helgaas  wrote:
> > > On Sat, Oct 24, 2020 at 10:55:46PM +0200, Ian Kumlien wrote:
> > > > Make pcie_aspm_check_latency comply with the PCIe spec, specifically:
> > > > "5.4.1.2.2. Exit from the L1 State"
> > > >
> > > > Which makes it clear that each switch is required to initiate a
> > > > transition within 1μs from receiving it, accumulating this latency and
> > > > then we have to wait for the slowest link along the path before
> > > > entering L0 state from L1.
> > > > ...
> > >
> > > > On my specific system:
> > > > 03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network 
> > > > Connection (rev 03)
> > > > 04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 
> > > > 816e (rev 1a)
> > > >
> > > > Exit latency   Acceptable latency
> > > > Tree:   L1   L0s   L1   L0s
> > > > --  ---  - ---  --
> > > > 00:01.2 <32 us   -
> > > > | 01:00.0   <32 us   -
> > > > |- 02:03.0  <32 us   -
> > > > | \03:00.0  <16 us   <2us  <64 us   <512ns
> > > > |
> > > > \- 02:04.0  <32 us   -
> > > >   \04:00.0  <64 us   unlimited <64 us   <512ns
> > > >
> > > > 04:00.0's latency is the same as the maximum it allows so as we walk 
> > > > the path
> > > > the first switchs startup latency will pass the acceptable latency limit
> > > > for the link, and as a side-effect it fixes my issues with 03:00.0.
> > > >
> > > > Without this patch, 03:00.0 misbehaves and only gives me ~40 mbit/s over
> > > > links with 6 or more hops. With this patch I'm back to a maximum of ~933
> > > > mbit/s.
> > >
> > > There are two paths here that share a Link:
> > >
> > >   00:01.2 --- 01:00.0 -- 02:03.0 --- 03:00.0 I211 NIC
> > >   00:01.2 --- 01:00.0 -- 02:04.0 --- 04:00.x multifunction Realtek
> > >
> > > 1) The path to the I211 NIC includes four Ports and two Links (the
> > >connection between 01:00.0 and 02:03.0 is internal Switch routing,
> > >not a Link).
> >
> > >The Ports advertise L1 exit latencies of <32us, <32us, <32us,
> > ><16us.  If both Links are in L1 and 03:00.0 initiates L1 exit at T,
> > >01:00.0 initiates L1 exit at T + 1.  A TLP from 03:00.0 may see up
> > >to 1 + 32 = 33us of L1 exit latency.
> > >
> > >The NIC can tolerate up to 64us of L1 exit latency, so it is safe
> > >to enable L1 for both Links.
> > >
> > > 2) The path to the Realtek device is similar except that the Realtek
> > >L1 exit latency is <64us.  If both Links are in L1 and 04:00.x
> > >initiates L1 exit at T, 01:00.0 again initiates L1 exit at T + 1,
> > >but a TLP from 04:00.x may see up to 1 + 64 = 65us of L1 exit
> > >latency.
> > >
> > >The Realtek device can only tolerate 64us of latency, so it is not
> > >safe to enable L1 for both Links.  It should be safe to enable L1
> > >on the shared link because the exit latency for that link would be
> > ><32us.
> >
> > 04:00.0:
> > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
> > LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
> > unlimited, L1 <64us
> >
> > So maximum latency for the entire link has to be <64 us
> > For the device to leave L1 ASPM takes <64us
> >
> > So the device itself is the slowest entry along the link, which
>

Re: [PATCH 2/2] PCI: vmd: Enable ASPM for mobile platforms

[Ian Kumlien]

On Thu, Oct 8, 2020 at 6:19 AM Kai-Heng Feng
 wrote:
>
>
>
> > On Oct 7, 2020, at 21:30, Bjorn Helgaas  wrote:
> >
> > On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
> >>> On Oct 6, 2020, at 03:19, Bjorn Helgaas  wrote:
> >>> On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> > On Oct 3, 2020, at 06:18, Bjorn Helgaas  wrote:
> > On Wed, Sep 30, 2020 at 04:24:54PM +0800, Kai-Heng Feng wrote:
> >
> > ...
>  I wonder whether other devices that add PCIe domain have the same
>  behavior?  Maybe it's not a special case at all...
> >>>
> >>> What other devices are these?
> >>
> >> Controllers which add PCIe domain.
> >
> > I was looking for specific examples, not just a restatement of what
> > you said before.  I'm just curious because there are a lot of
> > controllers I'm not familiar with, and I can't think of an example.
> >
>  I understand the end goal is to keep consistency for the entire ASPM
>  logic. However I can't think of any possible solution right now.
> 
> > - If we built with CONFIG_PCIEASPM_POWERSAVE=y, would that solve the
> >  SoC power state problem?
> 
>  Yes.
> 
> > - What issues would CONFIG_PCIEASPM_POWERSAVE=y introduce?
> 
>  This will break many systems, at least for the 1st Gen Ryzen
>  desktops and laptops.
> 
>  All PCIe ASPM are not enabled by BIOS, and those systems immediately
>  freeze once ASPM is enabled.
> >>>
> >>> That indicates a defect in the Linux ASPM code.  We should fix that.
> >>> It should be safe to use CONFIG_PCIEASPM_POWERSAVE=y on every system.
> >>
> >> On those systems ASPM are also not enabled on Windows. So I think
> >> ASPM are disabled for a reason.
> >
> > If the platform knows ASPM needs to be disabled, it should be using
> > ACPI_FADT_NO_ASPM or _OSC to prevent the OS from using it.  And if
> > CONFIG_PCIEASPM_POWERSAVE=y means Linux enables ASPM when it
> > shouldn't, that's a Linux bug that we need to fix.
>
> Yes that's a bug which fixed by Ian's new patch.
>
> >
> >>> Are there bug reports for these? The info we would need to start with
> >>> includes "lspci -vv" and dmesg log (with CONFIG_PCIEASPM_DEFAULT=y).
> >>> If a console log with CONFIG_PCIEASPM_POWERSAVE=y is available, that
> >>> might be interesting, too.  We'll likely need to add some
> >>> instrumentation and do some experimentation, but in principle, this
> >>> should be fixable.
> >>
> >> Doing this is asking users to use hardware settings that ODM/OEM
> >> never tested, and I think the risk is really high.
> >
> > What?  That's not what I said at all.  I'm asking for information
> > about these hangs so we can fix them.  I'm not suggesting that you
> > should switch to CONFIG_PCIEASPM_POWERSAVE=y for the distro.
>
> Ah, I thought your suggestion is switching to CONFIG_PCIEASPM_POWERSAVE=y, 
> because I sense you want to use that to cover the VMD ASPM this patch tries 
> to solve.
>
> Do we have a conclusion how to enable VMD ASPM with CONFIG_PCIEASPM_DEFAULT=y?
>
> >
> > Let's back up.  You said:
> >
> >  CONFIG_PCIEASPM_POWERSAVE=y ... will break many systems, at least
> >  for the 1st Gen Ryzen desktops and laptops.
> >
> >  All PCIe ASPM are not enabled by BIOS, and those systems immediately
> >  freeze once ASPM is enabled.
> >
> > These system hangs might be caused by (1) some hardware issue that
> > causes a hang when ASPM is enabled even if it is configured correctly
> > or (2) Linux configuring ASPM incorrectly.
>
> It's (2) here.
>
> >
> > For case (1), the platform should be using ACPI_FADT_NO_ASPM or _OSC
> > to prevent the OS from enabling ASPM.  Linux should pay attention to
> > that even when CONFIG_PCIEASPM_POWERSAVE=y.
> >
> > If the platform *should* use these mechanisms but doesn't, the
> > solution is a quirk, not the folklore that "we can't use
> > CONFIG_PCIEASPM_POWERSAVE=y because it breaks some systems."
>
> The platform in question doesn't prevent OS from enabling ASPM.
>
> >
> > For case (2), we should fix Linux so it configures ASPM correctly.
> >
> > We cannot use the build-time CONFIG_PCIEASPM settings to avoid these
> > hangs.  We need to fix the Linux run-time code so the system operates
> > correctly no matter what CONFIG_PCIEASPM setting is used.
> >
> > We have sysfs knobs to control ASPM (see 72ea91afbfb0 ("PCI/ASPM: Add
> > sysfs attributes for controlling ASPM link states")).  They can do the
> > same thing at run-time as CONFIG_PCIEASPM_POWERSAVE=y does at
> > build-time.  If those knobs cause hangs on 1st Gen Ryzen systems, we
> > need to fix that.
>
> Ian's patch solves the issue, at least for the systems I have.

Could you add:
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 15d64832a988..cd9f2101f9a2 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -482,7 +482,12 @@ static void pcie_aspm_check_latency(struct
pci_dev *endpoint)
latency = max_t(u32, link->latency_up.l1,

Re: [PATCH 2/2] PCI: vmd: Enable ASPM for mobile platforms

[Ian Kumlien]

On Wed, Oct 7, 2020 at 3:30 PM Bjorn Helgaas  wrote:
>
> On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
> > > On Oct 6, 2020, at 03:19, Bjorn Helgaas  wrote:
> > > On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> > >>> On Oct 3, 2020, at 06:18, Bjorn Helgaas  wrote:
> > >>> On Wed, Sep 30, 2020 at 04:24:54PM +0800, Kai-Heng Feng wrote:
>
> ...
> > >> I wonder whether other devices that add PCIe domain have the same
> > >> behavior?  Maybe it's not a special case at all...
> > >
> > > What other devices are these?
> >
> > Controllers which add PCIe domain.
>
> I was looking for specific examples, not just a restatement of what
> you said before.  I'm just curious because there are a lot of
> controllers I'm not familiar with, and I can't think of an example.
>
> > >> I understand the end goal is to keep consistency for the entire ASPM
> > >> logic. However I can't think of any possible solution right now.
> > >>
> > >>> - If we built with CONFIG_PCIEASPM_POWERSAVE=y, would that solve the
> > >>>   SoC power state problem?
> > >>
> > >> Yes.
> > >>
> > >>> - What issues would CONFIG_PCIEASPM_POWERSAVE=y introduce?
> > >>
> > >> This will break many systems, at least for the 1st Gen Ryzen
> > >> desktops and laptops.
> > >>
> > >> All PCIe ASPM are not enabled by BIOS, and those systems immediately
> > >> freeze once ASPM is enabled.
> > >
> > > That indicates a defect in the Linux ASPM code.  We should fix that.
> > > It should be safe to use CONFIG_PCIEASPM_POWERSAVE=y on every system.
> >
> > On those systems ASPM are also not enabled on Windows. So I think
> > ASPM are disabled for a reason.
>
> If the platform knows ASPM needs to be disabled, it should be using
> ACPI_FADT_NO_ASPM or _OSC to prevent the OS from using it.  And if
> CONFIG_PCIEASPM_POWERSAVE=y means Linux enables ASPM when it
> shouldn't, that's a Linux bug that we need to fix.
>
> > > Are there bug reports for these? The info we would need to start with
> > > includes "lspci -vv" and dmesg log (with CONFIG_PCIEASPM_DEFAULT=y).
> > > If a console log with CONFIG_PCIEASPM_POWERSAVE=y is available, that
> > > might be interesting, too.  We'll likely need to add some
> > > instrumentation and do some experimentation, but in principle, this
> > > should be fixable.
> >
> > Doing this is asking users to use hardware settings that ODM/OEM
> > never tested, and I think the risk is really high.
>
> What?  That's not what I said at all.  I'm asking for information
> about these hangs so we can fix them.  I'm not suggesting that you
> should switch to CONFIG_PCIEASPM_POWERSAVE=y for the distro.
>
> Let's back up.  You said:
>
>   CONFIG_PCIEASPM_POWERSAVE=y ... will break many systems, at least
>   for the 1st Gen Ryzen desktops and laptops.
>
>   All PCIe ASPM are not enabled by BIOS, and those systems immediately
>   freeze once ASPM is enabled.
>
> These system hangs might be caused by (1) some hardware issue that
> causes a hang when ASPM is enabled even if it is configured correctly
> or (2) Linux configuring ASPM incorrectly.

Could this be:
1044 PCIe ® Controller May Hang on Entry Into Either L1.1 or
L1.2 Power Management Substate

Description
Under a highly specific and detailed set of internal timing
conditions, the PCIe ® controller may hang on entry
into either L1.1 or L1.2 power management substate.
This failure occurs when L1 power management substate exit is
triggered by a link partner asserting CLKREQ#
prior to the completion of the L1 power management stubstates entry protocol.

Potential Effect on System
The system may hang or reset.

Suggested Workaround
Disable L1.1 and L1.2 power management substates. System software may
contain the workaround for this
erratum.

Fix Planned
Yes

Link: 
https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf

> For case (1), the platform should be using ACPI_FADT_NO_ASPM or _OSC
> to prevent the OS from enabling ASPM.  Linux should pay attention to
> that even when CONFIG_PCIEASPM_POWERSAVE=y.
>
> If the platform *should* use these mechanisms but doesn't, the
> solution is a quirk, not the folklore that "we can't use
> CONFIG_PCIEASPM_POWERSAVE=y because it breaks some systems."
>
> For case (2), we should fix Linux so it configures ASPM correctly.
>
> We cannot use the build-time CONFIG_PCIEASPM settings to avoid these
> hangs.  We need to fix the Linux run-time code so the system operates
> correctly no matter what CONFIG_PCIEASPM setting is used.
>
> We have sysfs knobs to control ASPM (see 72ea91afbfb0 ("PCI/ASPM: Add
> sysfs attributes for controlling ASPM link states")).  They can do the
> same thing at run-time as CONFIG_PCIEASPM_POWERSAVE=y does at
> build-time.  If those knobs cause hangs on 1st Gen Ryzen systems, we
> need to fix that.
>
> Bjorn

Re: [PATCH 2/2] PCI: vmd: Enable ASPM for mobile platforms

[Ian Kumlien]

On Wed, Oct 7, 2020 at 6:26 AM Kai-Heng Feng
 wrote:
>
>
>
> > On Oct 6, 2020, at 03:19, Bjorn Helgaas  wrote:
> >
> > [+cc Ian, who's also working on an ASPM issue]
> >
> > On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> >>> On Oct 3, 2020, at 06:18, Bjorn Helgaas  wrote:
> >>> On Wed, Sep 30, 2020 at 04:24:54PM +0800, Kai-Heng Feng wrote:
>  BIOS may not be able to program ASPM for links behind VMD, prevent Intel
>  SoC from entering deeper power saving state.
> >>>
> >>> It's not a question of BIOS not being *able* to configure ASPM.  I
> >>> think BIOS could do it, at least in principle, if it had a driver for
> >>> VMD.  Actually, it probably *does* include some sort of VMD code
> >>> because it sounds like BIOS can assign some Root Ports to appear
> >>> either as regular Root Ports or behind the VMD.
> >>>
> >>> Since this issue is directly related to the unusual VMD topology, I
> >>> think it would be worth a quick recap here.  Maybe something like:
> >>>
> >>> VMD is a Root Complex Integrated Endpoint that acts as a host bridge
> >>> to a secondary PCIe domain.  BIOS can reassign one or more Root
> >>> Ports to appear within a VMD domain instead of the primary domain.
> >>>
> >>> However, BIOS may not enable ASPM for the hierarchies behind a VMD,
> >>> ...
> >>>
> >>> (This is based on the commit log from 185a383ada2e ("x86/PCI: Add
> >>> driver for Intel Volume Management Device (VMD)")).
> >>
> >> Ok, will just copy the portion as-is if there's patch v2 :)
> >>
> >>> But we still have the problem that CONFIG_PCIEASPM_DEFAULT=y means
> >>> "use the BIOS defaults", and this patch would make it so we use the
> >>> BIOS defaults *except* for things behind VMD.
> >>>
> >>> - Why should VMD be a special case?
> >>
> >> Because BIOS doesn't handle ASPM for it so it's up to software to do
> >> the job.  In the meantime we want other devices still use the BIOS
> >> defaults to not introduce any regression.
> >>
> >>> - How would we document such a special case?
> >>
> >> I wonder whether other devices that add PCIe domain have the same
> >> behavior?  Maybe it's not a special case at all...
> >
> > What other devices are these?
>
> Controllers which add PCIe domain.
>
> >
> >> I understand the end goal is to keep consistency for the entire ASPM
> >> logic. However I can't think of any possible solution right now.
> >>
> >>> - If we built with CONFIG_PCIEASPM_POWERSAVE=y, would that solve the
> >>>   SoC power state problem?
> >>
> >> Yes.
> >>
> >>> - What issues would CONFIG_PCIEASPM_POWERSAVE=y introduce?
> >>
> >> This will break many systems, at least for the 1st Gen Ryzen
> >> desktops and laptops.
> >>
> >> All PCIe ASPM are not enabled by BIOS, and those systems immediately
> >> freeze once ASPM is enabled.
> >
> > That indicates a defect in the Linux ASPM code.  We should fix that.
> > It should be safe to use CONFIG_PCIEASPM_POWERSAVE=y on every system.
>
> On those systems ASPM are also not enabled on Windows. So I think ASPM are 
> disabled for a reason.
>
> >
> > Are there bug reports for these? The info we would need to start with
> > includes "lspci -vv" and dmesg log (with CONFIG_PCIEASPM_DEFAULT=y).
> > If a console log with CONFIG_PCIEASPM_POWERSAVE=y is available, that
> > might be interesting, too.  We'll likely need to add some
> > instrumentation and do some experimentation, but in principle, this
> > should be fixable.
>
> Doing this is asking users to use hardware settings that ODM/OEM never 
> tested, and I think the risk is really high.

They have to test it to comply with pcie specs? and what we're
currently doing is wrong...

This fixes the L1 behaviour in the kernel, could you test it?

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 253c30cc1967..893b37669087 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -434,7 +434,7 @@ static void pcie_get_aspm_reg(struct pci_dev *pdev,

 static void pcie_aspm_check_latency(struct pci_dev *endpoint)
 {
-   u32 latency, l1_switch_latency = 0;
+   u32 latency, l1_max_latency = 0, l1_switch_latency = 0;
struct aspm_latency *acceptable;
struct pcie_link_state *link;

@@ -456,10 +456,14 @@ static void pcie_aspm_check_latency(struct
pci_dev *endpoint)
if ((link->aspm_capable & ASPM_STATE_L0S_DW) &&
(link->latency_dw.l0s > acceptable->l0s))
link->aspm_capable &= ~ASPM_STATE_L0S_DW;
+
/*
 * Check L1 latency.
-* Every switch on the path to root complex need 1
-* more microsecond for L1. Spec doesn't mention L0s.
+*
+* PCIe r5.0, sec 5.4.1.2.2 states:
+* A Switch is required to initiate an L1 exit transition on its
+* Upstream Port Link after no more than 1 μs from the
beginning of an
+* L1 exit transition on any of its Downstream Port Links.

Re: [PATCH v4 01/12] IB/hfi1: Check if pcie_capability_read_*() reads ~0

[Ian Kumlien]

ownstream direction L0s latency */
-   if ((link->aspm_capable & ASPM_STATE_L0S_DW) &&
-   (link->latency_dw.l0s > acceptable->l0s))
-   link->aspm_capable &= ~ASPM_STATE_L0S_DW;
+   if (link->aspm_capable & ASPM_STATE_L0S) {
+   u32 l0s_up = 0, l0s_dw = 0;
+
+   /* Check upstream direction L0s latency */
+   if (link->aspm_capable & ASPM_STATE_L0S_UP)
+   l0s_up = link->latency_up.l0s;
+
+   /* Check downstream direction L0s latency */
+   if (link->aspm_capable & ASPM_STATE_L0S_DW)
+   l0s_dw = link->latency_dw.l0s;
+
+   l0s_max_latency += max_t(u32, l0s_up, l0s_dw);
+
+   /* If the latency exceeds, disable both */
+   if (l0s_max_latency > acceptable->l0s)
+   link->aspm_capable &= ~ASPM_STATE_L0S;
+   }
+
/*
 * Check L1 latency.
 * Every switch on the path to root complex need 1
@@ -469,11 +479,13 @@ static void pcie_aspm_check_latency(struct
pci_dev *endpoint)
 * L1 exit latencies advertised by a device include L1
 * substate latencies (and hence do not do any check).
 */
-   latency = max_t(u32, link->latency_up.l1, link->latency_dw.l1);
-   if ((link->aspm_capable & ASPM_STATE_L1) &&
-   (latency + l1_switch_latency > acceptable->l1))
-   link->aspm_capable &= ~ASPM_STATE_L1;
-   l1_switch_latency += 1000;
+       if (link->aspm_capable & ASPM_STATE_L1) {
+   latency = max_t(u32, link->latency_up.l1,
link->latency_dw.l1);
+   l1_max_latency = max_t(u32, latency, l1_max_latency);
+   if (l1_max_latency + l1_switch_latency > acceptable->l1)
+   link->aspm_capable &= ~ASPM_STATE_L1;
+   l1_switch_latency += 1000;
+   }

link = link->parent;
}
From 971735bd32d7a8cb7cd1a8d4316fc2a2e192f8e2 Mon Sep 17 00:00:00 2001
From: Ian Kumlien 
Date: Sun, 26 Jul 2020 16:01:15 +0200
Subject: [PATCH] Use maximum latency when determining L1/L0s ASPM

Currently we check the maximum latency of upstream and downstream
per link, not the maximum for the path

This would work if all links have the same latency, but:
endpoint -> c -> b -> a -> root  (in the order we walk the path)

If c or b has the higest latency, it will not register

Fix this by maintaining the maximum latency value for the path

Also, L0s seems to be a cumulative maximum over the path, fix this as
well

This change fixes a regression introduced (but not caused) by:
66ff14e59e8a (PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges)

Signed-off-by: Ian Kumlien 
---
 drivers/pci/pcie/aspm.c | 42 ++---
 1 file changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index b17e5ffd31b1..0d93ae065f73 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -434,7 +434,8 @@ static void pcie_get_aspm_reg(struct pci_dev *pdev,
 
 static void pcie_aspm_check_latency(struct pci_dev *endpoint)
 {
-	u32 latency, l1_switch_latency = 0;
+	u32 latency, l1_max_latency = 0, l1_switch_latency = 0,
+		l0s_max_latency = 0;
 	struct aspm_latency *acceptable;
 	struct pcie_link_state *link;
 
@@ -447,15 +448,24 @@ static void pcie_aspm_check_latency(struct pci_dev *endpoint)
 	acceptable = >acceptable[PCI_FUNC(endpoint->devfn)];
 
 	while (link) {
-		/* Check upstream direction L0s latency */
-		if ((link->aspm_capable & ASPM_STATE_L0S_UP) &&
-		(link->latency_up.l0s > acceptable->l0s))
-			link->aspm_capable &= ~ASPM_STATE_L0S_UP;
-
-		/* Check downstream direction L0s latency */
-		if ((link->aspm_capable & ASPM_STATE_L0S_DW) &&
-		(link->latency_dw.l0s > acceptable->l0s))
-			link->aspm_capable &= ~ASPM_STATE_L0S_DW;
+		if (link->aspm_capable & ASPM_STATE_L0S) {
+			u32 l0s_up = 0, l0s_dw = 0;
+
+			/* Check upstream direction L0s latency */
+			if (link->aspm_capable & ASPM_STATE_L0S_UP)
+l0s_up = link->latency_up.l0s;
+
+			/* Check downstream direction L0s latency */
+			if (link->aspm_capable & ASPM_STATE_L0S_DW)
+l0s_dw = link->latency_dw.l0s;
+
+			l0s_max_latency += max_t(u32, l0s_up, l0s_dw);
+
+			/* If the latency exceeds, disable both */
+			if (l0s_max_latency > acceptable->l0s)
+link->aspm_capable &= ~ASPM_STATE_L0S;
+		}
+
 		/*
 		 * Check L1 latency.
 		 * Every switch on the

Re: [PATCH 4.20 000/111] 4.20.4-stable review

[Ian Kumlien]

On Mon, Jan 21, 2019 at 7:48 PM David Miller  wrote:
>
> From: Ian Kumlien 
> Date: Mon, 21 Jan 2019 16:38:11 +0100
>
> > Hi David,
> >
> > could we have your blessing to add the following patch to -stable for 
> > 4.20.4:
> > commit 41d1c8839e5f8cb781cc635f12791decee8271b7
> > Author: Paolo Abeni 
> > Date:   Tue Jan 8 18:45:05 2019 +0100
> >
> > net: clear skb->tstamp in bridge forwarding path
>
> It is already in my -stable queue:
>
> https://patchwork.ozlabs.org/bundle/davem/stable/?series===*==
>
> I honestly don't know why I bother putting forth such an effort to publish
> what is in my -stable queue if people don't bother checking it. :-(

Sorry, I will check it in the future, the patch from Greg would
highlight it as well!

I was really hoping that this was pushed to -stable already,  which is
why I sent
my initial mail.

I haven't really followed kernel policies that closely since 2.5 or something =/

Re: [PATCH 4.20 000/111] 4.20.4-stable review

[Ian Kumlien]

Hi David,

could we have your blessing to add the following patch to -stable for 4.20.4:
commit 41d1c8839e5f8cb781cc635f12791decee8271b7
Author: Paolo Abeni 
Date:   Tue Jan 8 18:45:05 2019 +0100

net: clear skb->tstamp in bridge forwarding path

Matteo reported forwarding issues inside the linux bridge,
if the enslaved interfaces use the fq qdisc.

Similar to commit 8203e2d844d3 ("net: clear skb->tstamp in
forwarding paths"), we need to clear the tstamp field in
the bridge forwarding path.

Fixes: 80b14dee2bea ("net: Add a new socket option for a future
transmit time.")
Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC")
Reported-and-tested-by: Matteo Croce 
Signed-off-by: Paolo Abeni 
Acked-by: Nikolay Aleksandrov 
Acked-by: Roopa Prabhu 
Reviewed-by: Eric Dumazet 
Signed-off-by: David S. Miller 
---

Also, do you keep your -stable queue somewhere where I can see it?
It feels like I'm stepping on toes, adding overhead and such, which is
not what i want...

On Mon, Jan 21, 2019 at 4:10 PM Greg KH  wrote:
> On Mon, Jan 21, 2019 at 03:56:24PM +0100, Ian Kumlien wrote:
> > On Mon, Jan 21, 2019 at 3:47 PM Greg KH  wrote:
> > > On Mon, Jan 21, 2019 at 03:44:24PM +0100, Ian Kumlien wrote:
> > > > Hi,
> > > >
> > > > IMHO you are missing: 41d1c8839e5f8cb781cc635f12791decee8271b7
> > > >
> > > > Which should be marked for stable, it fixes:
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=202235
> > >
> > > The networking maintainer handles sending those patches to me.  It
> > > wasn't part of the last set of patches, so perhaps it will be in the
> > > next one?
> >
> > I thought it would be in the next one after it's in the rc but perhaps 
> > not...
> >
> > I suspected that it could have been a slip up, since:
> > https://marc.info/?l=linux-netdev=154726015506044=2
> >
> > And i know that there are people waiting for it ;)
>
> Well, ask David and if he says I can queue it up now, I'll be glad to do
> so.
>
> thanks,
>
> greg k-h

Re: [PATCH 4.20 000/111] 4.20.4-stable review

[Ian Kumlien]

On Mon, Jan 21, 2019 at 3:47 PM Greg KH  wrote:
>
> On Mon, Jan 21, 2019 at 03:44:24PM +0100, Ian Kumlien wrote:
> > Hi,
> >
> > IMHO you are missing: 41d1c8839e5f8cb781cc635f12791decee8271b7
> >
> > Which should be marked for stable, it fixes:
> > https://bugzilla.kernel.org/show_bug.cgi?id=202235
>
> The networking maintainer handles sending those patches to me.  It
> wasn't part of the last set of patches, so perhaps it will be in the
> next one?

I thought it would be in the next one after it's in the rc but perhaps not...

I suspected that it could have been a slip up, since:
https://marc.info/?l=linux-netdev=154726015506044=2

And i know that there are people waiting for it ;)

> Please see:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
> thanks,
>
> greg k-h

Re: [PATCH 4.20 000/111] 4.20.4-stable review

[Ian Kumlien]

Hi,

IMHO you are missing: 41d1c8839e5f8cb781cc635f12791decee8271b7

Which should be marked for stable, it fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=202235

Re: [BUG] moving fq back to clock monotonic breaks my setup

[Ian Kumlien]

On Fri, Jan 11, 2019 at 10:35 AM Eric Dumazet  wrote:
> On Thu, Jan 10, 2019 at 12:55 AM Paolo Abeni  wrote:
> > On Thu, 2019-01-10 at 09:25 +0100, Ian Kumlien wrote:
>
>
> > > This works, and so does: 
> > > https://marc.info/?l=linux-netdev=154696956604748=2
> > >
> > > Pointed out by Paolo (tested both separately)
> >
> > Note: I cleared the tstamp in br_forward_finish() instead of
> > br_dev_queue_push_xmit() because I think the latter could be called
> > also in the local xmit path, via br_nf_post_routing.
> >
> > We must preserve the tstamp in output path, right?
> >
>
>  I was not aware of your patch, SGTM, thanks.

And you can add Tested-by: ian.kuml...@gmail.com

Re: [BUG] moving fq back to clock monotonic breaks my setup

[Ian Kumlien]

On Thu, Jan 10, 2019 at 6:53 AM Eric Dumazet  wrote:
> On Wed, Jan 9, 2019 at 4:48 PM Ian Kumlien  wrote:
> >
> > Hi,
> >
> > Just been trough ~5+ hours of bisecting and eventually actually found
> > the culprit =)
> >
> > commit fb420d5d91c1274d5966917725e71f27ed092a85 (refs/bisect/bad)
> > Author: Eric Dumazet 
> > Date:   Fri Sep 28 10:28:44 2018 -0700
> >
> > tcp/fq: move back to CLOCK_MONOTONIC
> >
> > [--8<--]
> >
> > So this might be because my setup might be "odd".
> >
> > Basically I have a firewall with four nics that uses two of those nics
> > to handle my normal
> > internet connection (firewall/MASQ/NAT) and the other two are assigned
> > to one bridge each.
> >
> > The firewall is also my local caching DNS server and DHCP server,
> > which is also used by the VM:s...
> > But with 4.20 DHCP replies disappeared before entering the bridge - i
> > couldn't even see them in
> > tcpdump! (all nics are ixgbe on a atom soc)
> >
> > I'm currently running a kernel with that patch reversed but I'm also
> > wondering about possible ways
> > forward since I'm reverting a fix from someone else...
>
> I suggest you use netdev@ mailing list instead of lkml
>
> Then, we probably need to clear skb->tstamp in more paths (you are
> mentioning bridge ...)
>
> See commit 8203e2d844d34af247a151d8ebd68553a6e91785 for reference.
>
> Can you try :
>
> diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
> index 
> 5372e2042adfe20d3cd039c29057535b2413be61..bd4fa141420c92a44716bd93fcd8aa3d3310203a
> 100644
> --- a/net/bridge/br_forward.c
> +++ b/net/bridge/br_forward.c
> @@ -53,6 +53,7 @@ int br_dev_queue_push_xmit(struct net *net, struct
> sock *sk, struct sk_buff *skb
> skb_set_network_header(skb, depth);
> }
>
> +   skb->tstamp = 0;
> dev_queue_xmit(skb);
>
> return 0;

This works, and so does: https://marc.info/?l=linux-netdev=154696956604748=2

Pointed out by Paolo (tested both separately)

[BUG] moving fq back to clock monotonic breaks my setup

[Ian Kumlien]

Hi,

Just been trough ~5+ hours of bisecting and eventually actually found
the culprit =)

commit fb420d5d91c1274d5966917725e71f27ed092a85 (refs/bisect/bad)
Author: Eric Dumazet 
Date:   Fri Sep 28 10:28:44 2018 -0700

tcp/fq: move back to CLOCK_MONOTONIC

[--8<--]

So this might be because my setup might be "odd".

Basically I have a firewall with four nics that uses two of those nics
to handle my normal
internet connection (firewall/MASQ/NAT) and the other two are assigned
to one bridge each.

The firewall is also my local caching DNS server and DHCP server,
which is also used by the VM:s...
But with 4.20 DHCP replies disappeared before entering the bridge - i
couldn't even see them in
tcpdump! (all nics are ixgbe on a atom soc)

I'm currently running a kernel with that patch reversed but I'm also
wondering about possible ways
forward since I'm reverting a fix from someone else...

Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

[Ian Kumlien]

Confirmed, sending a new mail with summary etc

On Thu, Jan 10, 2019 at 1:16 AM Ian Kumlien  wrote:
>
> On Wed, Jan 9, 2019 at 12:17 AM Ian Kumlien  wrote:
> > On Wed, Jan 9, 2019, 00:09 Florian Fainelli 
>  [--8<---]
>
> >> > when looking at "git log v4.19...v4.20
> >> > drivers/net/ethernet/intel/ixgbe/" nothing else really stands out...
> >> > The machine is also running NAT for my home network and all of that
> >> > works just fine...
> >> >
> >> > I started with tcpdump, prooving that packets reached all the way
> >> > outside but replies never made it, reboorting
> >> > with 4.19.13 resulted in replies appearing in the tcpdump.
> >> >
> >> > I don't quite know where to look - and what can i do to test - i tried
> >> > disabling all offloading (due to the UDP
> >> > offloading changes) but nothing helped...
> >> >
> >> > Ideas? Patches? ;)
> >>
> >> Running a bisection would certainly help find the offending commit if
> >> that is something that you can do?
> >
> > I was hoping for a likely suspect but this was on my "Todo" for Friday 
> > night anyway... (And I already started testing with some patches reversed)
>
> So after lengthy git bisect sections, both from the latest stable i
> was using (not the best of ideas)
> and from 4.19.
>
> The latest stable yielded 72b0094f918294e6cb8cf5c3b4520d928fbb1a57 -
> which is incorrect...
>
> However, the proper bisect gave me this:
> fb420d5d91c1274d5966917725e71f27ed092a85 is the first bad commit
> commit fb420d5d91c1274d5966917725e71f27ed092a85
> Author: Eric Dumazet 
> Date:   Fri Sep 28 10:28:44 2018 -0700
>
> tcp/fq: move back to CLOCK_MONOTONIC
>
> In the recent TCP/EDT patch series, I switched TCP and sch_fq
> clocks from MONOTONIC to TAI, in order to meet the choice done
> earlier for sch_etf packet scheduler.
>
> But sure enough, this broke some setups were the TAI clock
> jumps forward (by almost 50 year...), as reported
> by Leonard Crestez.
>
> If we want to converge later, we'll probably need to add
> an skb field to differentiate the clock bases, or a socket option.
>
> In the meantime, an UDP application will need to use CLOCK_MONOTONIC
> base for its SCM_TXTIME timestamps if using fq packet scheduler.
>
> Fixes: 72b0094f9182 ("tcp: switch tcp_clock_ns() to CLOCK_TAI base")
> Fixes: 142537e41923 ("net_sched: sch_fq: switch to CLOCK_TAI")
> Fixes: fd2bca2aa789 ("tcp: switch internal pacing timer to CLOCK_TAI")
> Signed-off-by: Eric Dumazet 
> Reported-by: Leonard Crestez 
> Tested-by: Leonard Crestez 
> Signed-off-by: David S. Miller 
>
> :04 04 06615f5ed4486fd0af77a8fb59775a9f2346aebc
> 7f883c7753cb3d5d881e0edbef2989f4e6db6a1f M include
> :04 04 767c5e93fe5cfd609f90834d93978511c284ea01
> cc47bd361516622c0b21602e188181fdfc6b2995 M net
> 
>
> Which could actually be the culprit - I'm having problems *with* UDP
> traffic (DHCP) and I am using fq
>
> Lets hope it's so, since this was kinda boring:
> ls /lib/modules |grep 4.19.0 |wc -l
> 27
>
> Testing 4.20.1 and then 4.20.1 with the suspected patch reverted, will
> report shortly!

Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

[Ian Kumlien]

On Wed, Jan 9, 2019 at 12:17 AM Ian Kumlien  wrote:
> On Wed, Jan 9, 2019, 00:09 Florian Fainelli > > when looking at "git log v4.19...v4.20
>> > drivers/net/ethernet/intel/ixgbe/" nothing else really stands out...
>> > The machine is also running NAT for my home network and all of that
>> > works just fine...
>> >
>> > I started with tcpdump, prooving that packets reached all the way
>> > outside but replies never made it, reboorting
>> > with 4.19.13 resulted in replies appearing in the tcpdump.
>> >
>> > I don't quite know where to look - and what can i do to test - i tried
>> > disabling all offloading (due to the UDP
>> > offloading changes) but nothing helped...
>> >
>> > Ideas? Patches? ;)
>>
>> Running a bisection would certainly help find the offending commit if
>> that is something that you can do?
>
> I was hoping for a likely suspect but this was on my "Todo" for Friday night 
> anyway... (And I already started testing with some patches reversed)

So after lengthy git bisect sections, both from the latest stable i
was using (not the best of ideas)
and from 4.19.

The latest stable yielded 72b0094f918294e6cb8cf5c3b4520d928fbb1a57 -
which is incorrect...

However, the proper bisect gave me this:
fb420d5d91c1274d5966917725e71f27ed092a85 is the first bad commit
commit fb420d5d91c1274d5966917725e71f27ed092a85
Author: Eric Dumazet 
Date:   Fri Sep 28 10:28:44 2018 -0700

tcp/fq: move back to CLOCK_MONOTONIC

In the recent TCP/EDT patch series, I switched TCP and sch_fq
clocks from MONOTONIC to TAI, in order to meet the choice done
earlier for sch_etf packet scheduler.

But sure enough, this broke some setups were the TAI clock
jumps forward (by almost 50 year...), as reported
by Leonard Crestez.

If we want to converge later, we'll probably need to add
an skb field to differentiate the clock bases, or a socket option.

In the meantime, an UDP application will need to use CLOCK_MONOTONIC
base for its SCM_TXTIME timestamps if using fq packet scheduler.

Fixes: 72b0094f9182 ("tcp: switch tcp_clock_ns() to CLOCK_TAI base")
Fixes: 142537e41923 ("net_sched: sch_fq: switch to CLOCK_TAI")
Fixes: fd2bca2aa789 ("tcp: switch internal pacing timer to CLOCK_TAI")
Signed-off-by: Eric Dumazet 
Reported-by: Leonard Crestez 
Tested-by: Leonard Crestez 
Signed-off-by: David S. Miller 

:04 04 06615f5ed4486fd0af77a8fb59775a9f2346aebc
7f883c7753cb3d5d881e0edbef2989f4e6db6a1f M include
:04 04 767c5e93fe5cfd609f90834d93978511c284ea01
cc47bd361516622c0b21602e188181fdfc6b2995 M net


Which could actually be the culprit - I'm having problems *with* UDP
traffic (DHCP) and I am using fq

Lets hope it's so, since this was kinda boring:
ls /lib/modules |grep 4.19.0 |wc -l
27

Testing 4.20.1 and then 4.20.1 with the suspected patch reverted, will
report shortly!

Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

[Ian Kumlien]

On Tue, Jan 8, 2019 at 11:51 PM Stephen Hemminger
 wrote:
> On Tue, 8 Jan 2019 23:10:04 +0100
> Ian Kumlien  wrote:
> > On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien  wrote:
> > >
> > > [Sorry for the repost, screwed up the netdev address...]
> > >
> > > Hi,
> > >
> > > Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
> > >
> > > My firewall (which also runs the dhcpd) runs VM:s and it does this by
> > > having physical
> > > interfaces attached to bridges - which the VM:s in turn attach to.
> > >
> > > Since 4.20 the VM:s can't use DHCP, it's odd since the requests are
> > > seen - a response is sent but
> > > it never enters the interface attached to the bridge.
> > >
> > > Basically:
> > > VM vnet2: -> br0 -> eno2 -> switch -> eno1 (dhcpd)
> > > dhcpd eno1 -> siwtch and... gone.
> > >
> > > Any clues?
> > >
> > > All the nics are handled by ixgbe
> >
> > So, doing similar tests at work with other drivers works - could it be
> > related to the mac address filter that was added?
> > I don't *really* use VF:s though... (can't really find anything else atm)
> >
> > Will try to test, but the VM:s on this machine is in use.
>
> The default MAC address of the bridge device is the first device assigned
> to the bridge.  Remember most VF interfaces will only allow single MAC address
> and no promiscious mode.

Yeah, I'm not running any VF:s and it just seems like the responses
are dropped somewhere

when looking at "git log v4.19...v4.20
drivers/net/ethernet/intel/ixgbe/" nothing else really stands out...
The machine is also running NAT for my home network and all of that
works just fine...

I started with tcpdump, prooving that packets reached all the way
outside but replies never made it, reboorting
with 4.19.13 resulted in replies appearing in the tcpdump.

I don't quite know where to look - and what can i do to test - i tried
disabling all offloading (due to the UDP
offloading changes) but nothing helped...

Ideas? Patches? ;)

Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

[Ian Kumlien]

On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien  wrote:
>
> [Sorry for the repost, screwed up the netdev address...]
>
> Hi,
>
> Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
>
> My firewall (which also runs the dhcpd) runs VM:s and it does this by
> having physical
> interfaces attached to bridges - which the VM:s in turn attach to.
>
> Since 4.20 the VM:s can't use DHCP, it's odd since the requests are
> seen - a response is sent but
> it never enters the interface attached to the bridge.
>
> Basically:
> VM vnet2: -> br0 -> eno2 -> switch -> eno1 (dhcpd)
> dhcpd eno1 -> siwtch and... gone.
>
> Any clues?
>
> All the nics are handled by ixgbe

So, doing similar tests at work with other drivers works - could it be
related to the mac address filter that was added?
I don't *really* use VF:s though... (can't really find anything else atm)

Will try to test, but the VM:s on this machine is in use.

Fwd: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

[Ian Kumlien]

[Sorry for the repost, screwed up the netdev address...]

Hi,

Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.

My firewall (which also runs the dhcpd) runs VM:s and it does this by
having physical
interfaces attached to bridges - which the VM:s in turn attach to.

Since 4.20 the VM:s can't use DHCP, it's odd since the requests are
seen - a response is sent but
it never enters the interface attached to the bridge.

Basically:
VM vnet2: -> br0 -> eno2 -> switch -> eno1 (dhcpd)
dhcpd eno1 -> siwtch and... gone.

Any clues?

All the nics are handled by ixgbe

[BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

[Ian Kumlien]

Hi,

Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.

My firewall (which also runs the dhcpd) runs VM:s and it does this by
having physical
interfaces attached to bridges - which the VM:s in turn attach to.

Since 4.20 the VM:s can't use DHCP, it's odd since the requests are
seen - a response is sent but
it never enters the interface attached to the bridge.

Basically:
VM vnet2: -> br0 -> eno2 -> switch -> eno1 (dhcpd)
dhcpd eno1 -> siwtch and... gone.

Any clues?

All the nics are handled by ixgbe

Re: pcc_cpufreq: high LA

[Ian Kumlien]

No response? Should pcc_cpufreq be assumed as broken since it actually
kills machines?

Should I submit a patch that removes it?

On Tue, Nov 20, 2018 at 3:05 PM Ian Kumlien  wrote:
>
> Hi,
>
> We've had this happen a few times now, pcc_cpufreq is loaded and the
> machine has a LA of 33 with kworkers consuming *all CPU*
>
> We have had this happen before, looking at it has been pushed to the
> leaky-stack^tm in my mind and...
>
> 32 cores:
> processor : 31
> vendor_id : GenuineIntel
> cpu family : 6
> model : 62
> model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
> stepping : 4
> microcode : 0x42d
> cpu MHz : 2053.444
> cache size : 20480 KB
> 
>
> System Information:
> Manufacturer: HP
> Product Name: ProLiant SL210t Gen8
> ---
>
> The only warning I can see, which seems unrelated is:
> [6928231.623398] WARNING: CPU: 11 PID: 0 at kernel/irq/matrix.c:371
> irq_matrix_free+0x35/0xe0
> [6928231.623402] Modules linked in: 8021q garp mrp ipt_MASQUERADE
> nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat
> nf_conntrack dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio
> libcrc32c loop bonding sb_edac x86_pkg_temp_thermal intel_powerclamp
> coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
> ghash_clmulni_intel pcbc aesni_intel crypto_simd cryptd glue_helper
> intel_cstate intel_rapl_perf iTCO_wdt iTCO_vendor_support joydev
> input_leds acpi_power_meter pcspkr hpilo sg ipmi_si ipmi_devintf
> ipmi_msghandler hpwdt ioatdma lpc_ich shpchp pcc_cpufreq mfd_core
> ip_tables ext4 mbcache jbd2 raid1 sd_mod crc32c_intel serio_raw
> drm_kms_helper ahci syscopyarea sysfillrect libahci sysimgblt
> fb_sys_fops ttm libata drm igb
> [6928231.623490]  i2c_algo_bit ixgbe mdio ptp pps_core dca dm_mirror
> dm_region_hash dm_log dm_mod
> [6928231.623507] CPU: 11 PID: 0 Comm: swapper/11 Not tainted
> 4.17.0-1.el7.elrepo.x86_64 #1
> [6928231.623509] Hardware name: HP ProLiant SL210t Gen8/, BIOS P83 05/21/2018
> [6928231.623514] RIP: 0010:irq_matrix_free+0x35/0xe0
> [6928231.623516] RSP: 0018:88203f4c3f58 EFLAGS: 00010002
> [6928231.623519] RAX: 00026d00 RBX: 880ffaf64340 RCX:
> 
> [6928231.623521] RDX: 000b RSI: 000b RDI:
> 880fff038800
> [6928231.623523] RBP: 88203f4c3f80 R08: 0101 R09:
> 
> [6928231.623525] R10:  R11:  R12:
> 88203f4c
> [6928231.623527] R13:  R14: 000b R15:
> 880fff038800
> [6928231.623530] FS:  () GS:88203f4c()
> knlGS:
> [6928231.623532] CS:  0010 DS:  ES:  CR0: 80050033
> [6928231.623534] CR2: 7fc429b73d20 CR3: 0220a006 CR4:
> 001606e0
> [6928231.623537] Call Trace:
> [6928231.623541]  
> [6928231.623554]  free_moved_vector+0x58/0x110
> [6928231.623563]  smp_irq_move_cleanup_interrupt+0xa2/0xc1
> [6928231.623572]  irq_move_cleanup_interrupt+0xc/0x20
> [6928231.623574]  
> [6928231.623582] RIP: 0010:cpuidle_enter_state+0xdd/0x270
> [6928231.623583] RSP: 0018:c9000631fe48 EFLAGS: 0246 ORIG_RAX:
> ffdf
> [6928231.623586] RAX: 88203f4e2c00 RBX: e86da700 RCX:
> 001f
> [6928231.623588] RDX:  RSI: fff0a6fbff885c1c RDI:
> 
> [6928231.623590] RBP: c9000631fe80 R08: 2036 R09:
> 43d0
> [6928231.623592] R10: 133e R11: 0018 R12:
> 0004
> [6928231.623594] R13: 000b R14: 82364b60 R15:
> 00189d309ada9b44
> [6928231.623599]  ? cpuidle_enter_state+0xcc/0x270
> [6928231.623603]  cpuidle_enter+0x17/0x20
> [6928231.623611]  call_cpuidle+0x23/0x40
> [6928231.623614]  do_idle+0x1d2/0x270
> [6928231.623619]  cpu_startup_entry+0x73/0x80
> [6928231.623624]  start_secondary+0x1ae/0x200
> [6928231.623632]  secondary_startup_64+0xa5/0xb0
> [6928231.623634] Code: 57 49 89 ff 41 56 41 89 f6 41 55 41 89 d5 89 f2
> 41 54 4c 8b 24 d5 60 c7 12 82 53 48 8b 47 28 44 39 6f 04 77 06 44 3b
> 6f 08 72 0d <0f> 0b 5b 41 5c 41 5d 41 5e 41 5f 5d c3 49 01 c4 44 89 e8
> f0 49
> [6928231.623693] ---[ end trace 6436d0c28a5009d4 ]---

Re: pcc_cpufreq: high LA

[Ian Kumlien]

No response? Should pcc_cpufreq be assumed as broken since it actually
kills machines?

Should I submit a patch that removes it?

On Tue, Nov 20, 2018 at 3:05 PM Ian Kumlien  wrote:
>
> Hi,
>
> We've had this happen a few times now, pcc_cpufreq is loaded and the
> machine has a LA of 33 with kworkers consuming *all CPU*
>
> We have had this happen before, looking at it has been pushed to the
> leaky-stack^tm in my mind and...
>
> 32 cores:
> processor : 31
> vendor_id : GenuineIntel
> cpu family : 6
> model : 62
> model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
> stepping : 4
> microcode : 0x42d
> cpu MHz : 2053.444
> cache size : 20480 KB
> 
>
> System Information:
> Manufacturer: HP
> Product Name: ProLiant SL210t Gen8
> ---
>
> The only warning I can see, which seems unrelated is:
> [6928231.623398] WARNING: CPU: 11 PID: 0 at kernel/irq/matrix.c:371
> irq_matrix_free+0x35/0xe0
> [6928231.623402] Modules linked in: 8021q garp mrp ipt_MASQUERADE
> nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat
> nf_conntrack dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio
> libcrc32c loop bonding sb_edac x86_pkg_temp_thermal intel_powerclamp
> coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
> ghash_clmulni_intel pcbc aesni_intel crypto_simd cryptd glue_helper
> intel_cstate intel_rapl_perf iTCO_wdt iTCO_vendor_support joydev
> input_leds acpi_power_meter pcspkr hpilo sg ipmi_si ipmi_devintf
> ipmi_msghandler hpwdt ioatdma lpc_ich shpchp pcc_cpufreq mfd_core
> ip_tables ext4 mbcache jbd2 raid1 sd_mod crc32c_intel serio_raw
> drm_kms_helper ahci syscopyarea sysfillrect libahci sysimgblt
> fb_sys_fops ttm libata drm igb
> [6928231.623490]  i2c_algo_bit ixgbe mdio ptp pps_core dca dm_mirror
> dm_region_hash dm_log dm_mod
> [6928231.623507] CPU: 11 PID: 0 Comm: swapper/11 Not tainted
> 4.17.0-1.el7.elrepo.x86_64 #1
> [6928231.623509] Hardware name: HP ProLiant SL210t Gen8/, BIOS P83 05/21/2018
> [6928231.623514] RIP: 0010:irq_matrix_free+0x35/0xe0
> [6928231.623516] RSP: 0018:88203f4c3f58 EFLAGS: 00010002
> [6928231.623519] RAX: 00026d00 RBX: 880ffaf64340 RCX:
> 
> [6928231.623521] RDX: 000b RSI: 000b RDI:
> 880fff038800
> [6928231.623523] RBP: 88203f4c3f80 R08: 0101 R09:
> 
> [6928231.623525] R10:  R11:  R12:
> 88203f4c
> [6928231.623527] R13:  R14: 000b R15:
> 880fff038800
> [6928231.623530] FS:  () GS:88203f4c()
> knlGS:
> [6928231.623532] CS:  0010 DS:  ES:  CR0: 80050033
> [6928231.623534] CR2: 7fc429b73d20 CR3: 0220a006 CR4:
> 001606e0
> [6928231.623537] Call Trace:
> [6928231.623541]  
> [6928231.623554]  free_moved_vector+0x58/0x110
> [6928231.623563]  smp_irq_move_cleanup_interrupt+0xa2/0xc1
> [6928231.623572]  irq_move_cleanup_interrupt+0xc/0x20
> [6928231.623574]  
> [6928231.623582] RIP: 0010:cpuidle_enter_state+0xdd/0x270
> [6928231.623583] RSP: 0018:c9000631fe48 EFLAGS: 0246 ORIG_RAX:
> ffdf
> [6928231.623586] RAX: 88203f4e2c00 RBX: e86da700 RCX:
> 001f
> [6928231.623588] RDX:  RSI: fff0a6fbff885c1c RDI:
> 
> [6928231.623590] RBP: c9000631fe80 R08: 2036 R09:
> 43d0
> [6928231.623592] R10: 133e R11: 0018 R12:
> 0004
> [6928231.623594] R13: 000b R14: 82364b60 R15:
> 00189d309ada9b44
> [6928231.623599]  ? cpuidle_enter_state+0xcc/0x270
> [6928231.623603]  cpuidle_enter+0x17/0x20
> [6928231.623611]  call_cpuidle+0x23/0x40
> [6928231.623614]  do_idle+0x1d2/0x270
> [6928231.623619]  cpu_startup_entry+0x73/0x80
> [6928231.623624]  start_secondary+0x1ae/0x200
> [6928231.623632]  secondary_startup_64+0xa5/0xb0
> [6928231.623634] Code: 57 49 89 ff 41 56 41 89 f6 41 55 41 89 d5 89 f2
> 41 54 4c 8b 24 d5 60 c7 12 82 53 48 8b 47 28 44 39 6f 04 77 06 44 3b
> 6f 08 72 0d <0f> 0b 5b 41 5c 41 5d 41 5e 41 5f 5d c3 49 01 c4 44 89 e8
> f0 49
> [6928231.623693] ---[ end trace 6436d0c28a5009d4 ]---

pcc_cpufreq: high LA

[Ian Kumlien]

Hi,

We've had this happen a few times now, pcc_cpufreq is loaded and the
machine has a LA of 33 with kworkers consuming *all CPU*

We have had this happen before, looking at it has been pushed to the
leaky-stack^tm in my mind and...

32 cores:
processor : 31
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping : 4
microcode : 0x42d
cpu MHz : 2053.444
cache size : 20480 KB


System Information:
Manufacturer: HP
Product Name: ProLiant SL210t Gen8
---

The only warning I can see, which seems unrelated is:
[6928231.623398] WARNING: CPU: 11 PID: 0 at kernel/irq/matrix.c:371
irq_matrix_free+0x35/0xe0
[6928231.623402] Modules linked in: 8021q garp mrp ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat
nf_conntrack dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio
libcrc32c loop bonding sb_edac x86_pkg_temp_thermal intel_powerclamp
coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel pcbc aesni_intel crypto_simd cryptd glue_helper
intel_cstate intel_rapl_perf iTCO_wdt iTCO_vendor_support joydev
input_leds acpi_power_meter pcspkr hpilo sg ipmi_si ipmi_devintf
ipmi_msghandler hpwdt ioatdma lpc_ich shpchp pcc_cpufreq mfd_core
ip_tables ext4 mbcache jbd2 raid1 sd_mod crc32c_intel serio_raw
drm_kms_helper ahci syscopyarea sysfillrect libahci sysimgblt
fb_sys_fops ttm libata drm igb
[6928231.623490]  i2c_algo_bit ixgbe mdio ptp pps_core dca dm_mirror
dm_region_hash dm_log dm_mod
[6928231.623507] CPU: 11 PID: 0 Comm: swapper/11 Not tainted
4.17.0-1.el7.elrepo.x86_64 #1
[6928231.623509] Hardware name: HP ProLiant SL210t Gen8/, BIOS P83 05/21/2018
[6928231.623514] RIP: 0010:irq_matrix_free+0x35/0xe0
[6928231.623516] RSP: 0018:88203f4c3f58 EFLAGS: 00010002
[6928231.623519] RAX: 00026d00 RBX: 880ffaf64340 RCX:

[6928231.623521] RDX: 000b RSI: 000b RDI:
880fff038800
[6928231.623523] RBP: 88203f4c3f80 R08: 0101 R09:

[6928231.623525] R10:  R11:  R12:
88203f4c
[6928231.623527] R13:  R14: 000b R15:
880fff038800
[6928231.623530] FS:  () GS:88203f4c()
knlGS:
[6928231.623532] CS:  0010 DS:  ES:  CR0: 80050033
[6928231.623534] CR2: 7fc429b73d20 CR3: 0220a006 CR4:
001606e0
[6928231.623537] Call Trace:
[6928231.623541]  
[6928231.623554]  free_moved_vector+0x58/0x110
[6928231.623563]  smp_irq_move_cleanup_interrupt+0xa2/0xc1
[6928231.623572]  irq_move_cleanup_interrupt+0xc/0x20
[6928231.623574]  
[6928231.623582] RIP: 0010:cpuidle_enter_state+0xdd/0x270
[6928231.623583] RSP: 0018:c9000631fe48 EFLAGS: 0246 ORIG_RAX:
ffdf
[6928231.623586] RAX: 88203f4e2c00 RBX: e86da700 RCX:
001f
[6928231.623588] RDX:  RSI: fff0a6fbff885c1c RDI:

[6928231.623590] RBP: c9000631fe80 R08: 2036 R09:
43d0
[6928231.623592] R10: 133e R11: 0018 R12:
0004
[6928231.623594] R13: 000b R14: 82364b60 R15:
00189d309ada9b44
[6928231.623599]  ? cpuidle_enter_state+0xcc/0x270
[6928231.623603]  cpuidle_enter+0x17/0x20
[6928231.623611]  call_cpuidle+0x23/0x40
[6928231.623614]  do_idle+0x1d2/0x270
[6928231.623619]  cpu_startup_entry+0x73/0x80
[6928231.623624]  start_secondary+0x1ae/0x200
[6928231.623632]  secondary_startup_64+0xa5/0xb0
[6928231.623634] Code: 57 49 89 ff 41 56 41 89 f6 41 55 41 89 d5 89 f2
41 54 4c 8b 24 d5 60 c7 12 82 53 48 8b 47 28 44 39 6f 04 77 06 44 3b
6f 08 72 0d <0f> 0b 5b 41 5c 41 5d 41 5e 41 5f 5d c3 49 01 c4 44 89 e8
f0 49
[6928231.623693] ---[ end trace 6436d0c28a5009d4 ]---

pcc_cpufreq: high LA

[Ian Kumlien]

Hi,

We've had this happen a few times now, pcc_cpufreq is loaded and the
machine has a LA of 33 with kworkers consuming *all CPU*

We have had this happen before, looking at it has been pushed to the
leaky-stack^tm in my mind and...

32 cores:
processor : 31
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping : 4
microcode : 0x42d
cpu MHz : 2053.444
cache size : 20480 KB


System Information:
Manufacturer: HP
Product Name: ProLiant SL210t Gen8
---

The only warning I can see, which seems unrelated is:
[6928231.623398] WARNING: CPU: 11 PID: 0 at kernel/irq/matrix.c:371
irq_matrix_free+0x35/0xe0
[6928231.623402] Modules linked in: 8021q garp mrp ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 xt_addrtype iptable_filter xt_conntrack nf_nat
nf_conntrack dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio
libcrc32c loop bonding sb_edac x86_pkg_temp_thermal intel_powerclamp
coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel pcbc aesni_intel crypto_simd cryptd glue_helper
intel_cstate intel_rapl_perf iTCO_wdt iTCO_vendor_support joydev
input_leds acpi_power_meter pcspkr hpilo sg ipmi_si ipmi_devintf
ipmi_msghandler hpwdt ioatdma lpc_ich shpchp pcc_cpufreq mfd_core
ip_tables ext4 mbcache jbd2 raid1 sd_mod crc32c_intel serio_raw
drm_kms_helper ahci syscopyarea sysfillrect libahci sysimgblt
fb_sys_fops ttm libata drm igb
[6928231.623490]  i2c_algo_bit ixgbe mdio ptp pps_core dca dm_mirror
dm_region_hash dm_log dm_mod
[6928231.623507] CPU: 11 PID: 0 Comm: swapper/11 Not tainted
4.17.0-1.el7.elrepo.x86_64 #1
[6928231.623509] Hardware name: HP ProLiant SL210t Gen8/, BIOS P83 05/21/2018
[6928231.623514] RIP: 0010:irq_matrix_free+0x35/0xe0
[6928231.623516] RSP: 0018:88203f4c3f58 EFLAGS: 00010002
[6928231.623519] RAX: 00026d00 RBX: 880ffaf64340 RCX:

[6928231.623521] RDX: 000b RSI: 000b RDI:
880fff038800
[6928231.623523] RBP: 88203f4c3f80 R08: 0101 R09:

[6928231.623525] R10:  R11:  R12:
88203f4c
[6928231.623527] R13:  R14: 000b R15:
880fff038800
[6928231.623530] FS:  () GS:88203f4c()
knlGS:
[6928231.623532] CS:  0010 DS:  ES:  CR0: 80050033
[6928231.623534] CR2: 7fc429b73d20 CR3: 0220a006 CR4:
001606e0
[6928231.623537] Call Trace:
[6928231.623541]  
[6928231.623554]  free_moved_vector+0x58/0x110
[6928231.623563]  smp_irq_move_cleanup_interrupt+0xa2/0xc1
[6928231.623572]  irq_move_cleanup_interrupt+0xc/0x20
[6928231.623574]  
[6928231.623582] RIP: 0010:cpuidle_enter_state+0xdd/0x270
[6928231.623583] RSP: 0018:c9000631fe48 EFLAGS: 0246 ORIG_RAX:
ffdf
[6928231.623586] RAX: 88203f4e2c00 RBX: e86da700 RCX:
001f
[6928231.623588] RDX:  RSI: fff0a6fbff885c1c RDI:

[6928231.623590] RBP: c9000631fe80 R08: 2036 R09:
43d0
[6928231.623592] R10: 133e R11: 0018 R12:
0004
[6928231.623594] R13: 000b R14: 82364b60 R15:
00189d309ada9b44
[6928231.623599]  ? cpuidle_enter_state+0xcc/0x270
[6928231.623603]  cpuidle_enter+0x17/0x20
[6928231.623611]  call_cpuidle+0x23/0x40
[6928231.623614]  do_idle+0x1d2/0x270
[6928231.623619]  cpu_startup_entry+0x73/0x80
[6928231.623624]  start_secondary+0x1ae/0x200
[6928231.623632]  secondary_startup_64+0xa5/0xb0
[6928231.623634] Code: 57 49 89 ff 41 56 41 89 f6 41 55 41 89 d5 89 f2
41 54 4c 8b 24 d5 60 c7 12 82 53 48 8b 47 28 44 39 6f 04 77 06 44 3b
6f 08 72 0d <0f> 0b 5b 41 5c 41 5d 41 5e 41 5f 5d c3 49 01 c4 44 89 e8
f0 49
[6928231.623693] ---[ end trace 6436d0c28a5009d4 ]---

[nfsd] page allocation failure -> kernel oops, even local fs hangs.

[Ian Kumlien]

Hi,

I just had this happen a little while ago, got different weird
deadlocks but this one actually generated a oops..

This is basic operation, a machine with 16 gb memory mainly doing NFS traffic.

I'm currently playing with RDMA for this, which is why mlx4 is included.

When the crash occurs, the local filesystem is just as inaccessible as
trying to use it remotely - i couldn't find any change that looked
related to it in v4.18-rc3 so here goes:

(the same report is attached as well)
[1609167.131537] nfsd: page allocation failure: order:8,
mode:0x14000c0(GFP_KERNEL), nodemask=(null)
[1609167.131548] nfsd cpuset=/ mems_allowed=0
[1609167.131554] CPU: 5 PID: 1310 Comm: nfsd Not tainted 4.17.1 #196
[1609167.131557] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./X370 Taichi, BIOS P4.70 04/17/2018
[1609167.131561] Call Trace:
[1609167.131567]  dump_stack+0x46/0x5b
[1609167.131571]  warn_alloc+0xf8/0x180
[1609167.131575]  ? __alloc_pages_direct_compact+0x8b/0x110
[1609167.131578]  __alloc_pages_slowpath+0xb86/0xbc0
[1609167.131583]  ? set_next_entity+0x47b/0x680
[1609167.131586]  __alloc_pages_nodemask+0x1f9/0x230
[1609167.131589]  dma_direct_alloc+0xbd/0x120
[1609167.131593]  alloc_coherent+0x60/0x160
[1609167.131599]  mlx4_buf_direct_alloc.isra.9+0xc1/0x170 [mlx4_core]
[1609167.131604]  mlx4_buf_alloc+0x158/0x1d0 [mlx4_core]
[1609167.131608]  ? _raw_spin_lock_irqsave+0x1d/0x50
[1609167.131612]  create_qp_common.isra.48+0x4bc/0x10d0 [mlx4_ib]
[1609167.131616]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[1609167.131620]  ? mlx4_free_cmd_mailbox.part.20+0x17/0x20 [mlx4_core]
[1609167.131624]  mlx4_ib_create_qp+0x128/0x880 [mlx4_ib]
[1609167.131627]  ? mlx4_ib_create_cq+0x25f/0x420 [mlx4_ib]
[1609167.131633]  ib_create_qp+0x9c/0x310 [ib_core]
[1609167.131636]  rdma_create_qp+0x39/0xb0 [rdma_cm]
[1609167.131641]  svc_rdma_accept+0x325/0x4d0 [rpcrdma]
[1609167.131644]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[1609167.131648]  ? try_to_del_timer_sync+0x47/0x70
[1609167.131651]  ? svc_rdma_detach+0x10/0x10 [rpcrdma]
[1609167.131655]  svc_recv+0x2cc/0x7d0
[1609167.131659]  ? nfsd_destroy+0x80/0x80
[1609167.131661]  nfsd+0xd5/0x150
[1609167.131665]  kthread+0x109/0x120
[1609167.131668]  ? kthread_create_worker_on_cpu+0x70/0x70
[1609167.131671]  ret_from_fork+0x22/0x40
[1609167.131674] Mem-Info:
[1609167.131678] active_anon:16522 inactive_anon:21289 isolated_anon:0
  active_file:736374 inactive_file:2641993 isolated_file:23
  unevictable:0 dirty:2 writeback:123602 unstable:0
  slab_reclaimable:103077 slab_unreclaimable:76545
  mapped:10454 shmem:318 pagetables:2054 bounce:0
  free:42337 free_pcp:12 free_cma:0
[1609167.136395] Node 0 active_anon:66088kB inactive_anon:85156kB
active_file:2945496kB inactive_file:10567972kB unevictable:0kB
isolated(anon):0kB isolated
(file):92kB mapped:41816kB dirty:8kB writeback:494408kB shmem:1272kB
shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 98304kB
writeback_tmp:0kB unstable:0kB al
l_unreclaimable? no
[1609167.138299] Node 0 DMA free:15900kB min:64kB low:80kB high:96kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB wri
tepending:0kB present:15984kB managed:15900kB mlocked:0kB
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[1609167.140313] lowmem_reserve[]: 0 3449 15946 15946
[1609167.141305] Node 0 DMA32 free:75596kB min:14604kB low:18252kB
high:21900kB active_anon:7208kB inactive_anon:10828kB
active_file:651676kB inactive_file:
2600688kB unevictable:0kB writepending:151540kB present:3597884kB
managed:3597884kB mlocked:0kB kernel_stack:288kB pagetables:20kB
bounce:0kB free_pcp:0kB l
ocal_pcp:0kB free_cma:0kB
[1609167.143453] lowmem_reserve[]: 0 0 12497 12497
[1609167.144600] Node 0 Normal free:77852kB min:52912kB low:66140kB
high:79368kB active_anon:58880kB inactive_anon:74328kB
active_file:2293820kB inactive_fi
le:7967284kB unevictable:0kB writepending:342876kB present:13094400kB
managed:12802572kB mlocked:0kB kernel_stack:5760kB pagetables:8196kB
bounce:0kB free_p
cp:48kB local_pcp:48kB free_cma:0kB
[1609167.146913] lowmem_reserve[]: 0 0 0 0
[1609167.148033] Node 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 0*32kB
2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M)
3*4096kB (M) = 15900
kB
[1609167.149199] Node 0 DMA32: 564*4kB (UME) 640*8kB (UME) 465*16kB
(UME) 358*32kB (UME) 275*64kB (UME) 119*128kB (UME) 45*256kB (UM)
10*512kB (M) 0*1024kB
0*2048kB 0*4096kB = 75744kB
[1609167.150389] Node 0 Normal: 1517*4kB (UMEH) 1231*8kB (UMEH)
840*16kB (UMEH) 545*32kB (UM) 304*64kB (UM) 62*128kB (UM) 14*256kB (M)
1*512kB (M) 0*1024kB
0*2048kB 0*4096kB = 78284kB
[1609167.151592] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=1048576kB
[1609167.152783] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[1609167.153980] 3379126 total pagecache pages
[1609167.155155] 368 

[nfsd] page allocation failure -> kernel oops, even local fs hangs.

[Ian Kumlien]

Hi,

I just had this happen a little while ago, got different weird
deadlocks but this one actually generated a oops..

This is basic operation, a machine with 16 gb memory mainly doing NFS traffic.

I'm currently playing with RDMA for this, which is why mlx4 is included.

When the crash occurs, the local filesystem is just as inaccessible as
trying to use it remotely - i couldn't find any change that looked
related to it in v4.18-rc3 so here goes:

(the same report is attached as well)
[1609167.131537] nfsd: page allocation failure: order:8,
mode:0x14000c0(GFP_KERNEL), nodemask=(null)
[1609167.131548] nfsd cpuset=/ mems_allowed=0
[1609167.131554] CPU: 5 PID: 1310 Comm: nfsd Not tainted 4.17.1 #196
[1609167.131557] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./X370 Taichi, BIOS P4.70 04/17/2018
[1609167.131561] Call Trace:
[1609167.131567]  dump_stack+0x46/0x5b
[1609167.131571]  warn_alloc+0xf8/0x180
[1609167.131575]  ? __alloc_pages_direct_compact+0x8b/0x110
[1609167.131578]  __alloc_pages_slowpath+0xb86/0xbc0
[1609167.131583]  ? set_next_entity+0x47b/0x680
[1609167.131586]  __alloc_pages_nodemask+0x1f9/0x230
[1609167.131589]  dma_direct_alloc+0xbd/0x120
[1609167.131593]  alloc_coherent+0x60/0x160
[1609167.131599]  mlx4_buf_direct_alloc.isra.9+0xc1/0x170 [mlx4_core]
[1609167.131604]  mlx4_buf_alloc+0x158/0x1d0 [mlx4_core]
[1609167.131608]  ? _raw_spin_lock_irqsave+0x1d/0x50
[1609167.131612]  create_qp_common.isra.48+0x4bc/0x10d0 [mlx4_ib]
[1609167.131616]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[1609167.131620]  ? mlx4_free_cmd_mailbox.part.20+0x17/0x20 [mlx4_core]
[1609167.131624]  mlx4_ib_create_qp+0x128/0x880 [mlx4_ib]
[1609167.131627]  ? mlx4_ib_create_cq+0x25f/0x420 [mlx4_ib]
[1609167.131633]  ib_create_qp+0x9c/0x310 [ib_core]
[1609167.131636]  rdma_create_qp+0x39/0xb0 [rdma_cm]
[1609167.131641]  svc_rdma_accept+0x325/0x4d0 [rpcrdma]
[1609167.131644]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[1609167.131648]  ? try_to_del_timer_sync+0x47/0x70
[1609167.131651]  ? svc_rdma_detach+0x10/0x10 [rpcrdma]
[1609167.131655]  svc_recv+0x2cc/0x7d0
[1609167.131659]  ? nfsd_destroy+0x80/0x80
[1609167.131661]  nfsd+0xd5/0x150
[1609167.131665]  kthread+0x109/0x120
[1609167.131668]  ? kthread_create_worker_on_cpu+0x70/0x70
[1609167.131671]  ret_from_fork+0x22/0x40
[1609167.131674] Mem-Info:
[1609167.131678] active_anon:16522 inactive_anon:21289 isolated_anon:0
  active_file:736374 inactive_file:2641993 isolated_file:23
  unevictable:0 dirty:2 writeback:123602 unstable:0
  slab_reclaimable:103077 slab_unreclaimable:76545
  mapped:10454 shmem:318 pagetables:2054 bounce:0
  free:42337 free_pcp:12 free_cma:0
[1609167.136395] Node 0 active_anon:66088kB inactive_anon:85156kB
active_file:2945496kB inactive_file:10567972kB unevictable:0kB
isolated(anon):0kB isolated
(file):92kB mapped:41816kB dirty:8kB writeback:494408kB shmem:1272kB
shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 98304kB
writeback_tmp:0kB unstable:0kB al
l_unreclaimable? no
[1609167.138299] Node 0 DMA free:15900kB min:64kB low:80kB high:96kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB wri
tepending:0kB present:15984kB managed:15900kB mlocked:0kB
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[1609167.140313] lowmem_reserve[]: 0 3449 15946 15946
[1609167.141305] Node 0 DMA32 free:75596kB min:14604kB low:18252kB
high:21900kB active_anon:7208kB inactive_anon:10828kB
active_file:651676kB inactive_file:
2600688kB unevictable:0kB writepending:151540kB present:3597884kB
managed:3597884kB mlocked:0kB kernel_stack:288kB pagetables:20kB
bounce:0kB free_pcp:0kB l
ocal_pcp:0kB free_cma:0kB
[1609167.143453] lowmem_reserve[]: 0 0 12497 12497
[1609167.144600] Node 0 Normal free:77852kB min:52912kB low:66140kB
high:79368kB active_anon:58880kB inactive_anon:74328kB
active_file:2293820kB inactive_fi
le:7967284kB unevictable:0kB writepending:342876kB present:13094400kB
managed:12802572kB mlocked:0kB kernel_stack:5760kB pagetables:8196kB
bounce:0kB free_p
cp:48kB local_pcp:48kB free_cma:0kB
[1609167.146913] lowmem_reserve[]: 0 0 0 0
[1609167.148033] Node 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 0*32kB
2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M)
3*4096kB (M) = 15900
kB
[1609167.149199] Node 0 DMA32: 564*4kB (UME) 640*8kB (UME) 465*16kB
(UME) 358*32kB (UME) 275*64kB (UME) 119*128kB (UME) 45*256kB (UM)
10*512kB (M) 0*1024kB
0*2048kB 0*4096kB = 75744kB
[1609167.150389] Node 0 Normal: 1517*4kB (UMEH) 1231*8kB (UMEH)
840*16kB (UMEH) 545*32kB (UM) 304*64kB (UM) 62*128kB (UM) 14*256kB (M)
1*512kB (M) 0*1024kB
0*2048kB 0*4096kB = 78284kB
[1609167.151592] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=1048576kB
[1609167.152783] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[1609167.153980] 3379126 total pagecache pages
[1609167.155155] 368 

[4.11.0 Kernel oops] propagate_one+0xa1/0x200

[Ian Kumlien]

Hi,

While restarting a docker container today we had four machines
deadlock with the following oops

If this is related to propagate_one, then nothing has changed in the
later kernels and this could still be a issue

I'm still trying to investigate what happened

This is the OCR-corrected version:
[4492428.611565]  do_syscall_64+0x67/0x180
[4492428.611713]  entry_SYSCALL64_slow_path+0x25/0x25
[4492428.611860] RIP: 0033:0x6ba79a
[4492428.612005] RSP: 002b:00c421cc0ac0 EFLAGS: 0206 ORIG_RAX:
00a5
[4492428.612292] RAX: ffda RBX: 00c42001550c RCX:
006ba79a
[4492428.612576] RDX: 00c4214e6a40 RSI: 00c4216a67e0 RDI:
00c4214e6a38
[4492428.612862] RBP: 00c421cc0b70 R08: 00c4226597c0 RB9:

[4492428.613146] R10: 000e R11: 0206 R12:
0a40
[4492428.613435] R13: 00af R14: 001f R15:
0004
[4492428.613723] Code: ee cb f4 00 48 8b 3d ef cb f4 00 48 39 fa 48 8b
72 10 0f 84 69 01 00 00 48 3b 86 d8 00 00 00 74 24 48 8b 92 d8 00 00
00 48 39 d7 <48> 8b 72 10 0f 84 40 01 00 00 48 3b 86 d8 00 00 00 75 e3
48 B9
[4492428.614213] RIP: propagate_one+0xa1/0x200 RSP: c9002eac3d78
[4492428.614363] CR2: 0010
[4492428.614881] ---[ end trace ce6357ccc7c57710 I---
[4492428.615067] Kernel panic - not syncing: Fatal exception
[4492428.615286] Kernel 0ffset: disabled
[4492428.615478] ---[ end Kernel panic - not syncing: Fatal exception

Original screenshot:
https://goo.gl/photos/3aFVPE17FwAqqhsr8

OCR-corrected version attached, as well ;)
[4492428.611565]  do_syscall_64+0x67/0x180
[4492428.611713]  entry_SYSCALL64_slow_path+0x25/0x25
[4492428.611860] RIP: 0033:0x6ba79a
[4492428.612005] RSP: 002b:00c421cc0ac0 EFLAGS: 0206 ORIG_RAX: 
00a5
[4492428.612292] RAX: ffda RBX: 00c42001550c RCX: 
006ba79a
[4492428.612576] RDX: 00c4214e6a40 RSI: 00c4216a67e0 RDI: 
00c4214e6a38
[4492428.612862] RBP: 00c421cc0b70 R08: 00c4226597c0 RB9: 

[4492428.613146] R10: 000e R11: 0206 R12: 
0a40
[4492428.613435] R13: 00af R14: 001f R15: 
0004
[4492428.613723] Code: ee cb f4 00 48 8b 3d ef cb f4 00 48 39 fa 48 8b 72 10 0f 
84 69 01 00 00 48 3b 86 d8 00 00 00 74 24 48 8b 92 d8 00 00 00 48 39 d7 <48> 8b 
72 10 0f 84 40 01 00 00 48 3b 86 d8 00 00 00 75 e3 48 B9
[4492428.614213] RIP: propagate_one+0xa1/0x200 RSP: c9002eac3d78
[4492428.614363] CR2: 0010
[4492428.614881] ---[ end trace ce6357ccc7c57710 I---
[4492428.615067] Kernel panic - not syncing: Fatal exception
[4492428.615286] Kernel 0ffset: disabled
[4492428.615478] ---[ end Kernel panic - not syncing: Fatal exception

[4.11.0 Kernel oops] propagate_one+0xa1/0x200

[Ian Kumlien]

Hi,

While restarting a docker container today we had four machines
deadlock with the following oops

If this is related to propagate_one, then nothing has changed in the
later kernels and this could still be a issue

I'm still trying to investigate what happened

This is the OCR-corrected version:
[4492428.611565]  do_syscall_64+0x67/0x180
[4492428.611713]  entry_SYSCALL64_slow_path+0x25/0x25
[4492428.611860] RIP: 0033:0x6ba79a
[4492428.612005] RSP: 002b:00c421cc0ac0 EFLAGS: 0206 ORIG_RAX:
00a5
[4492428.612292] RAX: ffda RBX: 00c42001550c RCX:
006ba79a
[4492428.612576] RDX: 00c4214e6a40 RSI: 00c4216a67e0 RDI:
00c4214e6a38
[4492428.612862] RBP: 00c421cc0b70 R08: 00c4226597c0 RB9:

[4492428.613146] R10: 000e R11: 0206 R12:
0a40
[4492428.613435] R13: 00af R14: 001f R15:
0004
[4492428.613723] Code: ee cb f4 00 48 8b 3d ef cb f4 00 48 39 fa 48 8b
72 10 0f 84 69 01 00 00 48 3b 86 d8 00 00 00 74 24 48 8b 92 d8 00 00
00 48 39 d7 <48> 8b 72 10 0f 84 40 01 00 00 48 3b 86 d8 00 00 00 75 e3
48 B9
[4492428.614213] RIP: propagate_one+0xa1/0x200 RSP: c9002eac3d78
[4492428.614363] CR2: 0010
[4492428.614881] ---[ end trace ce6357ccc7c57710 I---
[4492428.615067] Kernel panic - not syncing: Fatal exception
[4492428.615286] Kernel 0ffset: disabled
[4492428.615478] ---[ end Kernel panic - not syncing: Fatal exception

Original screenshot:
https://goo.gl/photos/3aFVPE17FwAqqhsr8

OCR-corrected version attached, as well ;)
[4492428.611565]  do_syscall_64+0x67/0x180
[4492428.611713]  entry_SYSCALL64_slow_path+0x25/0x25
[4492428.611860] RIP: 0033:0x6ba79a
[4492428.612005] RSP: 002b:00c421cc0ac0 EFLAGS: 0206 ORIG_RAX: 
00a5
[4492428.612292] RAX: ffda RBX: 00c42001550c RCX: 
006ba79a
[4492428.612576] RDX: 00c4214e6a40 RSI: 00c4216a67e0 RDI: 
00c4214e6a38
[4492428.612862] RBP: 00c421cc0b70 R08: 00c4226597c0 RB9: 

[4492428.613146] R10: 000e R11: 0206 R12: 
0a40
[4492428.613435] R13: 00af R14: 001f R15: 
0004
[4492428.613723] Code: ee cb f4 00 48 8b 3d ef cb f4 00 48 39 fa 48 8b 72 10 0f 
84 69 01 00 00 48 3b 86 d8 00 00 00 74 24 48 8b 92 d8 00 00 00 48 39 d7 <48> 8b 
72 10 0f 84 40 01 00 00 48 3b 86 d8 00 00 00 75 e3 48 B9
[4492428.614213] RIP: propagate_one+0xa1/0x200 RSP: c9002eac3d78
[4492428.614363] CR2: 0010
[4492428.614881] ---[ end trace ce6357ccc7c57710 I---
[4492428.615067] Kernel panic - not syncing: Fatal exception
[4492428.615286] Kernel 0ffset: disabled
[4492428.615478] ---[ end Kernel panic - not syncing: Fatal exception

[PATCH] Update pptp handling to avoid null pointer deref. v2

[Ian Kumlien]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 
0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 
1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  [] 
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8() 
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001 
94085c2b5fc0
[  109.560578]  0001 2000  

[  109.561200]     

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080

Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct pptp_gre_header 
*)0)->ack);
 
-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr), 
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
 
-- 
2.11.0

[PATCH] Update pptp handling to avoid null pointer deref. v2

[Ian Kumlien]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 
0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 
1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  [] 
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8() 
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001 
94085c2b5fc0
[  109.560578]  0001 2000  

[  109.561200]     

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080

Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien 
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct pptp_gre_header 
*)0)->ack);
 
-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr), 
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
 
-- 
2.11.0

[PATCH] Update pptp handling to avoid null pointer deref. v2

[Ian Kumlien]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 
0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 
1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  [] 
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8() 
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001 
94085c2b5fc0
[  109.560578]  0001 2000  

[  109.561200]     

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080

Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct pptp_gre_header 
*)0)->ack);
 
-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr), 
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
 
-- 
2.11.0

[PATCH] Update pptp handling to avoid null pointer deref. v2

[Ian Kumlien]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 
0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 
1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  [] 
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8() 
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001 
94085c2b5fc0
[  109.560578]  0001 2000  

[  109.561200]     

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080

Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien 
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct pptp_gre_header 
*)0)->ack);
 
-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr), 
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
 
-- 
2.11.0

Re: [PATCH] Update pptp handling to avoid null pointer deref.

[Ian Kumlien]

On Mon, Jan 2, 2017 at 5:07 AM, David Miller <da...@davemloft.net> wrote:
> From: Ian Kumlien <ian.kuml...@gmail.com>
> Date: Mon,  2 Jan 2017 00:19:36 +0100
>
>> __skb_flow_dissect can be called with a skb or a data packet, either
>> can be NULL. All calls seems to have been moved to __skb_header_pointer
>> except the pptp handling which is still calling skb_header_pointer.
>>
>> skb_header_pointer will use skb->data and thus:
>  ...
>> ---
>>
>> Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
>
> You need to fix some parts of your submission.
>
> Do not put the signoff after the "---", git will remove all text
> after that "---" from the commit message.

Sorry, I tend to do that automatically

> You must include a proper "Fixes: " tag which indicates which change
> introduced this regression.  This is critical for analyzing your fix
> and also for figuring out which -stable releases your fix should be
> backported to.

I it's supposed to be added after 4.7 but i can't find it in 4.8, will
send it as a stable patch for 4.9

> In this case the guilty commit is ab10dccb1160 ("rps: Inspect PPTP
> encapsulated by GRE to get flow hash")

Thanks, =)

Now patch is incomming

Re: [PATCH] Update pptp handling to avoid null pointer deref.

[Ian Kumlien]

On Mon, Jan 2, 2017 at 5:07 AM, David Miller  wrote:
> From: Ian Kumlien 
> Date: Mon,  2 Jan 2017 00:19:36 +0100
>
>> __skb_flow_dissect can be called with a skb or a data packet, either
>> can be NULL. All calls seems to have been moved to __skb_header_pointer
>> except the pptp handling which is still calling skb_header_pointer.
>>
>> skb_header_pointer will use skb->data and thus:
>  ...
>> ---
>>
>> Signed-off-by: Ian Kumlien 
>
> You need to fix some parts of your submission.
>
> Do not put the signoff after the "---", git will remove all text
> after that "---" from the commit message.

Sorry, I tend to do that automatically

> You must include a proper "Fixes: " tag which indicates which change
> introduced this regression.  This is critical for analyzing your fix
> and also for figuring out which -stable releases your fix should be
> backported to.

I it's supposed to be added after 4.7 but i can't find it in 4.8, will
send it as a stable patch for 4.9

> In this case the guilty commit is ab10dccb1160 ("rps: Inspect PPTP
> encapsulated by GRE to get flow hash")

Thanks, =)

Now patch is incomming

[PATCH] Update pptp handling to avoid null pointer deref.

[Ian Kumlien]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 
0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 
1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  [] 
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8() 
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001 
94085c2b5fc0
[  109.560578]  0001 2000  

[  109.561200]     

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080
---

Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct pptp_gre_header 
*)0)->ack);
 
-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr), 
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
 
-- 
2.11.0

[PATCH] Update pptp handling to avoid null pointer deref.

[Ian Kumlien]

__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.

skb_header_pointer will use skb->data and thus:
[  109.556866] BUG: unable to handle kernel NULL pointer dereference at 
0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 
1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  [] 
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8() 
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001 
94085c2b5fc0
[  109.560578]  0001 2000  

[  109.561200]     

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080
---

Signed-off-by: Ian Kumlien 
---
 net/core/flow_dissector.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct pptp_gre_header 
*)0)->ack);
 
-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr), 
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
 
-- 
2.11.0

Re: [BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

Sorry, after further inspection, it seems like the choice of
skb_header_pointer is wrong and skb isn't always populated. It seems
like the code has suffered from bitrot since all the surrounding code
is actually fixed.

This fixes it as well:
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct
pptp_gre_header *)0)->ack);

-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr),
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;

Will send a patch with signed off by n' all.

On Sun, Jan 1, 2017 at 6:31 PM, Ian Kumlien <ian.kuml...@gmail.com> wrote:
> On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien <ian.kuml...@gmail.com> wrote:
>> Hi,
>>
>> Been fighting with "crash" to get it to help me to analyze my crash
>> dumps... This is the output from vmcore-dmesg.
>>
>> This is 100% reproducible...
>>
>> Config that lets the connection trough but crashes the kernel:
>> # CONFIG_NF_CONNTRACK_PPTP is not set
>> # CONFIG_NF_NAT_PPTP is not set
>> CONFIG_PPTP=y
>>
>> If I enable the *_NF_* options, it doesn't crash but it also blocks
>> the PPTP packets.
>>
>> The crash is after the negotiation bit...
>
> So, some of the dumps pointed me, after some coaxing, to
> net/core/flow_dissector.c:448
> ---
> ppp_hdr = skb_header_pointer(skb, nhoff + offset,
>  sizeof(_ppp_hdr),
> _ppp_hdr);
> if (!ppp_hdr)
> goto out_bad;
> --
>
> Ie, copy or get the information from the skb to get more information
> on the pptp connection.
>
> However include/linux/skbuff.h:3109, with my test and debug code added
> static inline void * __must_check
> __skb_header_pointer(const struct sk_buff *skb, int offset,
>  int len, void *data, int hlen, void *buffer)
> {
> if (hlen - offset >= len)
> {
> if (skb == NULL || data == NULL)
> {
> printk("WARNING: something is null skb:%p
> data:%p - offset: %i hlen: %i len: %i\n", skb, data, offset, hlen,
> len);
> return NULL;
> }
> else
> return data + offset;
> }
>
> if (!skb ||
> skb_copy_bits(skb, offset, buffer, len) < 0)
> return NULL;
>
> return buffer;
> }
>
> static inline void * __must_check
> skb_header_pointer(const struct sk_buff *skb, int offset, int len, void 
> *buffer)
> {
> return __skb_header_pointer(skb, offset, len, skb->data,
> skb_headlen(skb), buffer);
> }
> ---
>
> so skb_header_pointer sends skb->data as data, but we never check if
> skb is *NULL*
>
> This does happen when we do a pptp connection:
> [   89.606712] WARNING: something is null skb:  (null)
> data:88bccc0d4000 - offset: 14 hlen: 256 len: 20
> [   89.613264] WARNING: something is null skb:  (null)
> data:88bccc00f800 - offset: 14 hlen: 256 len: 20
> [   89.621005] WARNING: something is null skb:  (null)
> data:88bccc010800 - offset: 14 hlen: 256 len: 20
> [   89.650479] WARNING: something is null skb:  (null)
> data:88bccc2cb000 - offset: 14 hlen: 256 len: 20
>
> So, the question is if the skb should always be there and always be
> valid? In that case something like this should fix it:
> static inline void * __must_check
> __skb_header_pointer(const struct sk_buff *skb, int offset,
>  int len, void *data, int hlen, void *buffer)
> {
> if (!skb)
> return NULL;
>
> if (hlen - offset >= len)
> return data + offset;
>
> if (skb_copy_bits(skb, offset, buffer, len) < 0)
> return NULL;
>
> return buffer;
> }
> ---
>
> Else the actual check would have to be moved to skb_header_pointer in
> this case - comments?
>
>> [  109.556866] BUG: unabl

Re: [BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

Sorry, after further inspection, it seems like the choice of
skb_header_pointer is wrong and skb isn't always populated. It seems
like the code has suffered from bitrot since all the surrounding code
is actually fixed.

This fixes it as well:
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -445,8 +445,9 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
if (hdr->flags & GRE_ACK)
offset += sizeof(((struct
pptp_gre_header *)0)->ack);

-   ppp_hdr = skb_header_pointer(skb, nhoff + offset,
-sizeof(_ppp_hdr),
_ppp_hdr);
+   ppp_hdr = __skb_header_pointer(skb, nhoff + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;

Will send a patch with signed off by n' all.

On Sun, Jan 1, 2017 at 6:31 PM, Ian Kumlien  wrote:
> On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien  wrote:
>> Hi,
>>
>> Been fighting with "crash" to get it to help me to analyze my crash
>> dumps... This is the output from vmcore-dmesg.
>>
>> This is 100% reproducible...
>>
>> Config that lets the connection trough but crashes the kernel:
>> # CONFIG_NF_CONNTRACK_PPTP is not set
>> # CONFIG_NF_NAT_PPTP is not set
>> CONFIG_PPTP=y
>>
>> If I enable the *_NF_* options, it doesn't crash but it also blocks
>> the PPTP packets.
>>
>> The crash is after the negotiation bit...
>
> So, some of the dumps pointed me, after some coaxing, to
> net/core/flow_dissector.c:448
> ---
> ppp_hdr = skb_header_pointer(skb, nhoff + offset,
>  sizeof(_ppp_hdr),
> _ppp_hdr);
> if (!ppp_hdr)
> goto out_bad;
> --
>
> Ie, copy or get the information from the skb to get more information
> on the pptp connection.
>
> However include/linux/skbuff.h:3109, with my test and debug code added
> static inline void * __must_check
> __skb_header_pointer(const struct sk_buff *skb, int offset,
>  int len, void *data, int hlen, void *buffer)
> {
> if (hlen - offset >= len)
> {
> if (skb == NULL || data == NULL)
> {
> printk("WARNING: something is null skb:%p
> data:%p - offset: %i hlen: %i len: %i\n", skb, data, offset, hlen,
> len);
> return NULL;
> }
> else
> return data + offset;
> }
>
> if (!skb ||
> skb_copy_bits(skb, offset, buffer, len) < 0)
> return NULL;
>
> return buffer;
> }
>
> static inline void * __must_check
> skb_header_pointer(const struct sk_buff *skb, int offset, int len, void 
> *buffer)
> {
> return __skb_header_pointer(skb, offset, len, skb->data,
> skb_headlen(skb), buffer);
> }
> ---
>
> so skb_header_pointer sends skb->data as data, but we never check if
> skb is *NULL*
>
> This does happen when we do a pptp connection:
> [   89.606712] WARNING: something is null skb:  (null)
> data:88bccc0d4000 - offset: 14 hlen: 256 len: 20
> [   89.613264] WARNING: something is null skb:  (null)
> data:88bccc00f800 - offset: 14 hlen: 256 len: 20
> [   89.621005] WARNING: something is null skb:  (null)
> data:88bccc010800 - offset: 14 hlen: 256 len: 20
> [   89.650479] WARNING: something is null skb:  (null)
> data:88bccc2cb000 - offset: 14 hlen: 256 len: 20
>
> So, the question is if the skb should always be there and always be
> valid? In that case something like this should fix it:
> static inline void * __must_check
> __skb_header_pointer(const struct sk_buff *skb, int offset,
>  int len, void *data, int hlen, void *buffer)
> {
> if (!skb)
> return NULL;
>
> if (hlen - offset >= len)
> return data + offset;
>
> if (skb_copy_bits(skb, offset, buffer, len) < 0)
> return NULL;
>
> return buffer;
> }
> ---
>
> Else the actual check would have to be moved to skb_header_pointer in
> this case - comments?
>
>> [  109.556866] BUG: unable to handle kernel NULL pointer dereference
>> at 00

Re: [BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien <ian.kuml...@gmail.com> wrote:
> Hi,
>
> Been fighting with "crash" to get it to help me to analyze my crash
> dumps... This is the output from vmcore-dmesg.
>
> This is 100% reproducible...
>
> Config that lets the connection trough but crashes the kernel:
> # CONFIG_NF_CONNTRACK_PPTP is not set
> # CONFIG_NF_NAT_PPTP is not set
> CONFIG_PPTP=y
>
> If I enable the *_NF_* options, it doesn't crash but it also blocks
> the PPTP packets.
>
> The crash is after the negotiation bit...

So, some of the dumps pointed me, after some coaxing, to
net/core/flow_dissector.c:448
---
ppp_hdr = skb_header_pointer(skb, nhoff + offset,
 sizeof(_ppp_hdr),
_ppp_hdr);
if (!ppp_hdr)
goto out_bad;
--

Ie, copy or get the information from the skb to get more information
on the pptp connection.

However include/linux/skbuff.h:3109, with my test and debug code added
static inline void * __must_check
__skb_header_pointer(const struct sk_buff *skb, int offset,
 int len, void *data, int hlen, void *buffer)
{
if (hlen - offset >= len)
{
if (skb == NULL || data == NULL)
{
printk("WARNING: something is null skb:%p
data:%p - offset: %i hlen: %i len: %i\n", skb, data, offset, hlen,
len);
return NULL;
}
else
return data + offset;
}

if (!skb ||
skb_copy_bits(skb, offset, buffer, len) < 0)
return NULL;

return buffer;
}

static inline void * __must_check
skb_header_pointer(const struct sk_buff *skb, int offset, int len, void *buffer)
{
return __skb_header_pointer(skb, offset, len, skb->data,
skb_headlen(skb), buffer);
}
---

so skb_header_pointer sends skb->data as data, but we never check if
skb is *NULL*

This does happen when we do a pptp connection:
[   89.606712] WARNING: something is null skb:  (null)
data:88bccc0d4000 - offset: 14 hlen: 256 len: 20
[   89.613264] WARNING: something is null skb:  (null)
data:88bccc00f800 - offset: 14 hlen: 256 len: 20
[   89.621005] WARNING: something is null skb:  (null)
data:88bccc010800 - offset: 14 hlen: 256 len: 20
[   89.650479] WARNING: something is null skb:  (null)
data:88bccc2cb000 - offset: 14 hlen: 256 len: 20

So, the question is if the skb should always be there and always be
valid? In that case something like this should fix it:
static inline void * __must_check
__skb_header_pointer(const struct sk_buff *skb, int offset,
 int len, void *data, int hlen, void *buffer)
{
if (!skb)
return NULL;

if (hlen - offset >= len)
return data + offset;

if (skb_copy_bits(skb, offset, buffer, len) < 0)
return NULL;

return buffer;
}
---

Else the actual check would have to be moved to skb_header_pointer in
this case - comments?

> [  109.556866] BUG: unable to handle kernel NULL pointer dereference
> at 0080
> [  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
> [  109.557263] PGD 0
> [  109.557338]
> [  109.557484] Oops:  [#1] SMP
> [  109.557562] Modules linked in: chaoskey
> [  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
> [  109.557867] Hardware name: Supermicro
> A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
> [  109.557957] task: 94085c27bc00 task.stack: b745c0068000
> [  109.558041] RIP: 0010:[]  []
> __skb_flow_dissect+0xa88/0xce0
> [  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
> [  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 
> 94084fab6800
> [  109.558373] RDX: 0010 RSI: 000c RDI: 
> 
> [  109.558460] RBP: 0b88 R08:  R09: 
> 0022
> [  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
> 
> [  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 
> 002f
> [  109.558979] FS:  () GS:94087fc8()
> knlGS:
> [  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
> [  109.559539] CR2: 0080 CR3: 000281809000 CR4: 
> 001026e0
> [  109.559753] Stack:
> [  109.559957]  000c 94084fab6822 0001
> 94085c2b5fc0
> [  109.560578]  0001 2000 
> 
> [  109.561200]    
> 
> 

Re: [BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien  wrote:
> Hi,
>
> Been fighting with "crash" to get it to help me to analyze my crash
> dumps... This is the output from vmcore-dmesg.
>
> This is 100% reproducible...
>
> Config that lets the connection trough but crashes the kernel:
> # CONFIG_NF_CONNTRACK_PPTP is not set
> # CONFIG_NF_NAT_PPTP is not set
> CONFIG_PPTP=y
>
> If I enable the *_NF_* options, it doesn't crash but it also blocks
> the PPTP packets.
>
> The crash is after the negotiation bit...

So, some of the dumps pointed me, after some coaxing, to
net/core/flow_dissector.c:448
---
ppp_hdr = skb_header_pointer(skb, nhoff + offset,
 sizeof(_ppp_hdr),
_ppp_hdr);
if (!ppp_hdr)
goto out_bad;
--

Ie, copy or get the information from the skb to get more information
on the pptp connection.

However include/linux/skbuff.h:3109, with my test and debug code added
static inline void * __must_check
__skb_header_pointer(const struct sk_buff *skb, int offset,
 int len, void *data, int hlen, void *buffer)
{
if (hlen - offset >= len)
{
if (skb == NULL || data == NULL)
{
printk("WARNING: something is null skb:%p
data:%p - offset: %i hlen: %i len: %i\n", skb, data, offset, hlen,
len);
return NULL;
}
else
return data + offset;
}

if (!skb ||
skb_copy_bits(skb, offset, buffer, len) < 0)
return NULL;

return buffer;
}

static inline void * __must_check
skb_header_pointer(const struct sk_buff *skb, int offset, int len, void *buffer)
{
return __skb_header_pointer(skb, offset, len, skb->data,
skb_headlen(skb), buffer);
}
---

so skb_header_pointer sends skb->data as data, but we never check if
skb is *NULL*

This does happen when we do a pptp connection:
[   89.606712] WARNING: something is null skb:  (null)
data:88bccc0d4000 - offset: 14 hlen: 256 len: 20
[   89.613264] WARNING: something is null skb:  (null)
data:88bccc00f800 - offset: 14 hlen: 256 len: 20
[   89.621005] WARNING: something is null skb:  (null)
data:88bccc010800 - offset: 14 hlen: 256 len: 20
[   89.650479] WARNING: something is null skb:  (null)
data:88bccc2cb000 - offset: 14 hlen: 256 len: 20

So, the question is if the skb should always be there and always be
valid? In that case something like this should fix it:
static inline void * __must_check
__skb_header_pointer(const struct sk_buff *skb, int offset,
 int len, void *data, int hlen, void *buffer)
{
if (!skb)
return NULL;

if (hlen - offset >= len)
return data + offset;

if (skb_copy_bits(skb, offset, buffer, len) < 0)
return NULL;

return buffer;
}
---

Else the actual check would have to be moved to skb_header_pointer in
this case - comments?

> [  109.556866] BUG: unable to handle kernel NULL pointer dereference
> at 0080
> [  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
> [  109.557263] PGD 0
> [  109.557338]
> [  109.557484] Oops:  [#1] SMP
> [  109.557562] Modules linked in: chaoskey
> [  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
> [  109.557867] Hardware name: Supermicro
> A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
> [  109.557957] task: 94085c27bc00 task.stack: b745c0068000
> [  109.558041] RIP: 0010:[]  []
> __skb_flow_dissect+0xa88/0xce0
> [  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
> [  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 
> 94084fab6800
> [  109.558373] RDX: 0010 RSI: 000c RDI: 
> 
> [  109.558460] RBP: 0b88 R08:  R09: 
> 0022
> [  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
> 
> [  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 
> 002f
> [  109.558979] FS:  () GS:94087fc8()
> knlGS:
> [  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
> [  109.559539] CR2: 0080 CR3: 000281809000 CR4: 
> 001026e0
> [  109.559753] Stack:
> [  109.559957]  000c 94084fab6822 0001
> 94085c2b5fc0
> [  109.560578]  0001 2000 
> 
> [  109.561200]    
> 
> [  109.561820] Call Trace:
> [  10

[BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

Hi,

Been fighting with "crash" to get it to help me to analyze my crash
dumps... This is the output from vmcore-dmesg.

This is 100% reproducible...

Config that lets the connection trough but crashes the kernel:
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_NAT_PPTP is not set
CONFIG_PPTP=y

If I enable the *_NF_* options, it doesn't crash but it also blocks
the PPTP packets.

The crash is after the negotiation bit...


[  109.556866] BUG: unable to handle kernel NULL pointer dereference
at 0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro
A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  []
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8()
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001
94085c2b5fc0
[  109.560578]  0001 2000 

[  109.561200]    

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080

[BUG] 4.9 - kernel oops when pptp connection is established and the kernel doesn't have pptp modules compiled

[Ian Kumlien]

Hi,

Been fighting with "crash" to get it to help me to analyze my crash
dumps... This is the output from vmcore-dmesg.

This is 100% reproducible...

Config that lets the connection trough but crashes the kernel:
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_NAT_PPTP is not set
CONFIG_PPTP=y

If I enable the *_NF_* options, it doesn't crash but it also blocks
the PPTP packets.

The crash is after the negotiation bit...


[  109.556866] BUG: unable to handle kernel NULL pointer dereference
at 0080
[  109.557102] IP: [] __skb_flow_dissect+0xa88/0xce0
[  109.557263] PGD 0
[  109.557338]
[  109.557484] Oops:  [#1] SMP
[  109.557562] Modules linked in: chaoskey
[  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
[  109.557867] Hardware name: Supermicro
A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
[  109.557957] task: 94085c27bc00 task.stack: b745c0068000
[  109.558041] RIP: 0010:[]  []
__skb_flow_dissect+0xa88/0xce0
[  109.558203] RSP: 0018:94087fc83d40  EFLAGS: 00010206
[  109.558286] RAX: 0130 RBX: 8975bf80 RCX: 94084fab6800
[  109.558373] RDX: 0010 RSI: 000c RDI: 
[  109.558460] RBP: 0b88 R08:  R09: 0022
[  109.558547] R10: 0008 R11: 94087fc83e04 R12: 
[  109.558763] R13: 94084fab6800 R14: 94087fc83e04 R15: 002f
[  109.558979] FS:  () GS:94087fc8()
knlGS:
[  109.559326] CS:  0010 DS:  ES:  CR0: 80050033
[  109.559539] CR2: 0080 CR3: 000281809000 CR4: 001026e0
[  109.559753] Stack:
[  109.559957]  000c 94084fab6822 0001
94085c2b5fc0
[  109.560578]  0001 2000 

[  109.561200]    

[  109.561820] Call Trace:
[  109.562027]  
[  109.562108]  [] ? eth_get_headlen+0x7a/0xf0
[  109.562522]  [] ? igb_poll+0x96a/0xe80
[  109.562737]  [] ? net_rx_action+0x20b/0x350
[  109.562953]  [] ? __do_softirq+0xe8/0x280
[  109.563169]  [] ? irq_exit+0xaa/0xb0
[  109.563382]  [] ? do_IRQ+0x4b/0xc0
[  109.563597]  [] ? common_interrupt+0x7f/0x7f
[  109.563810]  
[  109.563890]  [] ? cpuidle_enter_state+0x130/0x2c0
[  109.564304]  [] ? cpuidle_enter_state+0x120/0x2c0
[  109.564520]  [] ? cpu_startup_entry+0x19f/0x1f0
[  109.564737]  [] ? start_secondary+0x12a/0x140
[  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
24 84
[  109.569959] RIP  [] __skb_flow_dissect+0xa88/0xce0
[  109.570245]  RSP 
[  109.570453] CR2: 0080

Re: [BUG][4.5-rc5] rcu_shed self-detected stall on CPU - directly after network goes online.

[Ian Kumlien]

On 22 February 2016 at 01:38, Ian Kumlien <ian.kuml...@gmail.com> wrote:
> Hi,
>
> When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
> testing - it deadlocked almost instantly.

After bisect, the offending patch seems to be:
b16c29191dc89bd877af99a7b04ce4866728a3e0

It looks like some basic sanity checking went missing...

The original patch does:
diff --git a/net/netfilter/nfnetlink_cttimeout.c
b/net/netfilter/nfnetlink_cttimeout.c
index 5d010f2..94837d2 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -307,12 +307,12 @@ static void ctnl_untimeout(struct net *net,
struct ctnl_timeout *timeout)

local_bh_disable();
for (i = 0; i < net->ct.htable_size; i++) {
-   spin_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+   nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
if (i < net->ct.htable_size) {
hlist_nulls_for_each_entry(h, nn,
>ct.hash[i], hnnode)
untimeout(h, timeout);
}
-   spin_unlock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+   nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
}
local_bh_enable();
 }
---

Which looks like a mistake - the fix should be:
diff --git a/net/netfilter/nfnetlink_cttimeout.c
b/net/netfilter/nfnetlink_cttimeout.c
index 94837d2..2671b9d 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -312,7 +312,7 @@ static void ctnl_untimeout(struct net *net, struct
ctnl_timeout *timeout)
hlist_nulls_for_each_entry(h, nn,
>ct.hash[i], hnnode)
untimeout(h, timeout);
}
-   nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+   spin_unlock(_conntrack_locks[i % CONNTRACK_LOCKS]);
}
local_bh_enable();
 }
---

And it fixes my issue! ;)

> In the photo, i started writing "root" and it keeps repeating it, like
> it's in a while loop.
>
> https://goo.gl/photos/yGhNSogJjeb2VJyu5
>
> Trying to get better information - as in any - i enabled quite a few
> debugging options that could have any bearing on it and ended up with:
> https://goo.gl/photos/NnQER2WXXJ5ZWPR67
>
> The interesting part is that in this case the machine was booted in to
> single user mode and did not crash.
>
> It seems like it gets in to trouble when the bridges and the network
> interfaces are enabled, as in just about a second or two after boot.

[--8<--]
From caff3fec1641ba3e207ff705b68eba62dec3bef9 Mon Sep 17 00:00:00 2001
From: Ian Kumlien <ian.kuml...@gmail.com>
Date: Wed, 24 Feb 2016 23:40:57 +0100
Subject: [PATCH] netfilter: nf_conntrack: lock error

A lock error was introduced during the lock cleanup
lets undo that, =)

Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
---
 net/netfilter/nfnetlink_cttimeout.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
index 94837d2..2671b9d 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -312,7 +312,7 @@ static void ctnl_untimeout(struct net *net, struct ctnl_timeout *timeout)
 			hlist_nulls_for_each_entry(h, nn, >ct.hash[i], hnnode)
 untimeout(h, timeout);
 		}
-		nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+		spin_unlock(_conntrack_locks[i % CONNTRACK_LOCKS]);
 	}
 	local_bh_enable();
 }
-- 
2.7.2

Re: [BUG][4.5-rc5] rcu_shed self-detected stall on CPU - directly after network goes online.

[Ian Kumlien]

On 22 February 2016 at 01:38, Ian Kumlien  wrote:
> Hi,
>
> When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
> testing - it deadlocked almost instantly.

After bisect, the offending patch seems to be:
b16c29191dc89bd877af99a7b04ce4866728a3e0

It looks like some basic sanity checking went missing...

The original patch does:
diff --git a/net/netfilter/nfnetlink_cttimeout.c
b/net/netfilter/nfnetlink_cttimeout.c
index 5d010f2..94837d2 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -307,12 +307,12 @@ static void ctnl_untimeout(struct net *net,
struct ctnl_timeout *timeout)

local_bh_disable();
for (i = 0; i < net->ct.htable_size; i++) {
-   spin_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+   nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
if (i < net->ct.htable_size) {
hlist_nulls_for_each_entry(h, nn,
>ct.hash[i], hnnode)
untimeout(h, timeout);
}
-   spin_unlock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+   nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
}
local_bh_enable();
 }
---

Which looks like a mistake - the fix should be:
diff --git a/net/netfilter/nfnetlink_cttimeout.c
b/net/netfilter/nfnetlink_cttimeout.c
index 94837d2..2671b9d 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -312,7 +312,7 @@ static void ctnl_untimeout(struct net *net, struct
ctnl_timeout *timeout)
hlist_nulls_for_each_entry(h, nn,
>ct.hash[i], hnnode)
untimeout(h, timeout);
}
-   nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+   spin_unlock(_conntrack_locks[i % CONNTRACK_LOCKS]);
}
local_bh_enable();
 }
---

And it fixes my issue! ;)

> In the photo, i started writing "root" and it keeps repeating it, like
> it's in a while loop.
>
> https://goo.gl/photos/yGhNSogJjeb2VJyu5
>
> Trying to get better information - as in any - i enabled quite a few
> debugging options that could have any bearing on it and ended up with:
> https://goo.gl/photos/NnQER2WXXJ5ZWPR67
>
> The interesting part is that in this case the machine was booted in to
> single user mode and did not crash.
>
> It seems like it gets in to trouble when the bridges and the network
> interfaces are enabled, as in just about a second or two after boot.

[--8<--]
From caff3fec1641ba3e207ff705b68eba62dec3bef9 Mon Sep 17 00:00:00 2001
From: Ian Kumlien 
Date: Wed, 24 Feb 2016 23:40:57 +0100
Subject: [PATCH] netfilter: nf_conntrack: lock error

A lock error was introduced during the lock cleanup
lets undo that, =)

Signed-off-by: Ian Kumlien 
---
 net/netfilter/nfnetlink_cttimeout.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
index 94837d2..2671b9d 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -312,7 +312,7 @@ static void ctnl_untimeout(struct net *net, struct ctnl_timeout *timeout)
 			hlist_nulls_for_each_entry(h, nn, >ct.hash[i], hnnode)
 untimeout(h, timeout);
 		}
-		nf_conntrack_lock(_conntrack_locks[i % CONNTRACK_LOCKS]);
+		spin_unlock(_conntrack_locks[i % CONNTRACK_LOCKS]);
 	}
 	local_bh_enable();
 }
-- 
2.7.2

[BUG][4.5-rc5] rcu_shed self-detected stall on CPU - directly after network goes online.

[Ian Kumlien]

Hi,

When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
testing - it deadlocked almost instantly.

In the photo, i started writing "root" and it keeps repeating it, like
it's in a while loop.

https://goo.gl/photos/yGhNSogJjeb2VJyu5

Trying to get better information - as in any - i enabled quite a few
debugging options that could have any bearing on it and ended up with:
https://goo.gl/photos/NnQER2WXXJ5ZWPR67

The interesting part is that in this case the machine was booted in to
single user mode and did not crash.

It seems like it gets in to trouble when the bridges and the network
interfaces are enabled, as in just about a second or two after boot.

Anyone that has a clue of what i should be looking at/for?

lspci output:
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 1 (rev 02)
00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 2 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 3 (rev 02)
00:04.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 4 (rev 02)
00:0b.0 Co-processor: Intel Corporation Atom processor C2000 QAT (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000
SMBus 2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.3 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
Enhanced Host Controller (rev 02)
00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA2 Controller (rev 02)
00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA3 Controller (rev 02)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
02:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 03)
03:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
Graphics Family (rev 30)
04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)
05:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network
Connection (rev 01)
05:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network
Connection (rev 01)

[BUG][4.5-rc5] rcu_shed self-detected stall on CPU - directly after network goes online.

[Ian Kumlien]

Hi,

When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
testing - it deadlocked almost instantly.

In the photo, i started writing "root" and it keeps repeating it, like
it's in a while loop.

https://goo.gl/photos/yGhNSogJjeb2VJyu5

Trying to get better information - as in any - i enabled quite a few
debugging options that could have any bearing on it and ended up with:
https://goo.gl/photos/NnQER2WXXJ5ZWPR67

The interesting part is that in this case the machine was booted in to
single user mode and did not crash.

It seems like it gets in to trouble when the bridges and the network
interfaces are enabled, as in just about a second or two after boot.

Anyone that has a clue of what i should be looking at/for?

lspci output:
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 1 (rev 02)
00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 2 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 3 (rev 02)
00:04.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 4 (rev 02)
00:0b.0 Co-processor: Intel Corporation Atom processor C2000 QAT (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000
SMBus 2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.3 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
Enhanced Host Controller (rev 02)
00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA2 Controller (rev 02)
00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA3 Controller (rev 02)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
02:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 03)
03:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
Graphics Family (rev 30)
04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)
05:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network
Connection (rev 01)
05:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network
Connection (rev 01)

Re: [BUG] linux 4.3 - intel graphics card driver keeps oopsing

[Ian Kumlien]

After a few hours the machine started to spontaneously reboot.

It's back to running 4.2.5 - which works fine.

(I don't know if these messages are actually reaching lkml since it's
not showing up in the index on marc.info)

On 4 November 2015 at 10:24, Ian Kumlien  wrote:
> Hi,
>
> This happened when i booted linux 4.3 on a old intel machine.
>
> Please note, it's named before "twilight" was known and it's name is
> inspired by "twilight zone" since it's actually a firewall ;)
>
>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
>  1666 root  20   0   0  0  0 R  16,5  0,0  28:19.19 
> kworker/0:2
>  5297 root  20   0   28168   6200   4236 S   6,6  0,3  10:45.31 syslog-ng
> 7 root  20   0   0  0  0 S   0,7  0,0   0:36.32
> rcu_sched
>
> All this cpu usage seems to be required to constantly log OOPSes, like
> the ones listed below, is this known?
>
> ---
> Nov  4 10:18:55 twilight kernel: [ cut here ]
> Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
> drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x457/0x570()
> Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
> Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
> Tainted: GW   4.3.0 #86
> Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
> INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
> Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
> Nov  4 10:18:55 twilight kernel:  c13b856d  c10788b1
> c14aa787 01eb f6250800 
> Nov  4 10:18:55 twilight kernel: f549e948 f549e938 c107894d 0009
>  c14aa787 0002 f6315400
> Nov  4 10:18:55 twilight kernel: e0ebe600 f6315400 e0ebe600 f6315400
>  e0ebe600 c14aa8ab f6250800
> Nov  4 10:18:55 twilight kernel: Call Trace:
> Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_atomic_check_only+0x457/0x570
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_null+0xd/0x10
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_atomic_check_only+0x457/0x570
> Nov  4 10:18:55 twilight kernel: [] ? drm_atomic_commit+0xb/0x50
> Nov  4 10:18:55 twilight kernel: [] ?
> intel_get_load_detect_pipe+0x37d/0x530
> Nov  4 10:18:55 twilight kernel: [] ? intel_tv_detect+0xfb/0x540
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_helper_probe_single_connector_modes_merge_bits+0x293/0x490
> Nov  4 10:18:55 twilight kernel: [] ? kobject_uevent_env+0xd7/0x470
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_helper_probe_single_connector_modes+0x7/0x10
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_fb_helper_probe_connector_modes.isra.5+0x3c/0x60
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_fb_helper_hotplug_event+0x44/0xc0
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_kms_helper_hotplug_event+0x19/0x20
> Nov  4 10:18:55 twilight kernel: [] ? 
> output_poll_execute+0x161/0x1a0
> Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0xef/0x2b0
> Nov  4 10:18:55 twilight kernel: [] ? worker_thread+0x18a/0x400
> Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0x2b0/0x2b0
> Nov  4 10:18:55 twilight kernel: [] ? kthread+0x98/0xb0
> Nov  4 10:18:55 twilight kernel: [] ? 
> ret_from_kernel_thread+0x21/0x30
> Nov  4 10:18:55 twilight kernel: [] ?
> kthread_create_on_node+0x100/0x100
> Nov  4 10:18:55 twilight kernel: ---[ end trace 2c368f52bd242123 ]---
> Nov  4 10:18:55 twilight kernel: [ cut here ]
> Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
> drivers/gpu/drm/i915/intel_display.c:1389
> assert_planes_disabled+0xdf/0x120()
> Nov  4 10:18:55 twilight kernel: plane A assertion failure, should be
> off on pipe A but is still active
> Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
> Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
> Tainted: GW   4.3.0 #86
> Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
> INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
> Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
> Nov  4 10:18:55 twilight kernel:  c13b856d f5bcfd90 c10788b1
> c14f165f 056d f590 0041
> Nov  4 10:18:55 twilight kernel:  0041 c1078906 0009
> f5bcfd90 c1ba0294 f5bcfda8 c14f165f
> Nov  4 10:18:55 twilight kernel: c1ba0010 056d c1ba0294 0041
> 0041 f590  
> Nov  4 10:18:55 twilight kernel: Call Trace:
> Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
> Nov  4 10:18:55 twilight kernel: [] ? 

[BUG] linux 4.3 - intel graphics card driver keeps oopsing

[Ian Kumlien]

Hi,

This happened when i booted linux 4.3 on a old intel machine.

Please note, it's named before "twilight" was known and it's name is
inspired by "twilight zone" since it's actually a firewall ;)

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 1666 root  20   0   0  0  0 R  16,5  0,0  28:19.19 kworker/0:2
 5297 root  20   0   28168   6200   4236 S   6,6  0,3  10:45.31 syslog-ng
7 root  20   0   0  0  0 S   0,7  0,0   0:36.32
rcu_sched

All this cpu usage seems to be required to constantly log OOPSes, like
the ones listed below, is this known?

---
Nov  4 10:18:55 twilight kernel: [ cut here ]
Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x457/0x570()
Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
Tainted: GW   4.3.0 #86
Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
Nov  4 10:18:55 twilight kernel:  c13b856d  c10788b1
c14aa787 01eb f6250800 
Nov  4 10:18:55 twilight kernel: f549e948 f549e938 c107894d 0009
 c14aa787 0002 f6315400
Nov  4 10:18:55 twilight kernel: e0ebe600 f6315400 e0ebe600 f6315400
 e0ebe600 c14aa8ab f6250800
Nov  4 10:18:55 twilight kernel: Call Trace:
Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_check_only+0x457/0x570
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_null+0xd/0x10
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_check_only+0x457/0x570
Nov  4 10:18:55 twilight kernel: [] ? drm_atomic_commit+0xb/0x50
Nov  4 10:18:55 twilight kernel: [] ?
intel_get_load_detect_pipe+0x37d/0x530
Nov  4 10:18:55 twilight kernel: [] ? intel_tv_detect+0xfb/0x540
Nov  4 10:18:55 twilight kernel: [] ?
drm_helper_probe_single_connector_modes_merge_bits+0x293/0x490
Nov  4 10:18:55 twilight kernel: [] ? kobject_uevent_env+0xd7/0x470
Nov  4 10:18:55 twilight kernel: [] ?
drm_helper_probe_single_connector_modes+0x7/0x10
Nov  4 10:18:55 twilight kernel: [] ?
drm_fb_helper_probe_connector_modes.isra.5+0x3c/0x60
Nov  4 10:18:55 twilight kernel: [] ?
drm_fb_helper_hotplug_event+0x44/0xc0
Nov  4 10:18:55 twilight kernel: [] ?
drm_kms_helper_hotplug_event+0x19/0x20
Nov  4 10:18:55 twilight kernel: [] ? output_poll_execute+0x161/0x1a0
Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0xef/0x2b0
Nov  4 10:18:55 twilight kernel: [] ? worker_thread+0x18a/0x400
Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0x2b0/0x2b0
Nov  4 10:18:55 twilight kernel: [] ? kthread+0x98/0xb0
Nov  4 10:18:55 twilight kernel: [] ? ret_from_kernel_thread+0x21/0x30
Nov  4 10:18:55 twilight kernel: [] ?
kthread_create_on_node+0x100/0x100
Nov  4 10:18:55 twilight kernel: ---[ end trace 2c368f52bd242123 ]---
Nov  4 10:18:55 twilight kernel: [ cut here ]
Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
drivers/gpu/drm/i915/intel_display.c:1389
assert_planes_disabled+0xdf/0x120()
Nov  4 10:18:55 twilight kernel: plane A assertion failure, should be
off on pipe A but is still active
Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
Tainted: GW   4.3.0 #86
Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
Nov  4 10:18:55 twilight kernel:  c13b856d f5bcfd90 c10788b1
c14f165f 056d f590 0041
Nov  4 10:18:55 twilight kernel:  0041 c1078906 0009
f5bcfd90 c1ba0294 f5bcfda8 c14f165f
Nov  4 10:18:55 twilight kernel: c1ba0010 056d c1ba0294 0041
0041 f590  
Nov  4 10:18:55 twilight kernel: Call Trace:
Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
Nov  4 10:18:55 twilight kernel: [] ?
assert_planes_disabled+0xdf/0x120
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_fmt+0x26/0x30
Nov  4 10:18:55 twilight kernel: [] ?
assert_planes_disabled+0xdf/0x120
Nov  4 10:18:55 twilight kernel: [] ? intel_enable_pipe+0x3a/0x200
Nov  4 10:18:55 twilight kernel: [] ? i9xx_crtc_enable+0x282/0x400
Nov  4 10:18:55 twilight kernel: [] ? intel_atomic_commit+0x31d/0x10b0
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_helper_check_planes+0xf5/0x1b0
Nov  4 10:18:55 twilight kernel: [] ? intel_link_compute_m_n+0x50/0x50
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_check_only+0x1c9/0x570
Nov  4 10:18:55 twilight kernel: [] ? drm_atomic_commit+0x27/0x50
Nov  4 

Re: [BUG] linux 4.3 - intel graphics card driver keeps oopsing

[Ian Kumlien]

After a few hours the machine started to spontaneously reboot.

It's back to running 4.2.5 - which works fine.

(I don't know if these messages are actually reaching lkml since it's
not showing up in the index on marc.info)

On 4 November 2015 at 10:24, Ian Kumlien <ian.kuml...@gmail.com> wrote:
> Hi,
>
> This happened when i booted linux 4.3 on a old intel machine.
>
> Please note, it's named before "twilight" was known and it's name is
> inspired by "twilight zone" since it's actually a firewall ;)
>
>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
>  1666 root  20   0   0  0  0 R  16,5  0,0  28:19.19 
> kworker/0:2
>  5297 root  20   0   28168   6200   4236 S   6,6  0,3  10:45.31 syslog-ng
> 7 root  20   0   0  0  0 S   0,7  0,0   0:36.32
> rcu_sched
>
> All this cpu usage seems to be required to constantly log OOPSes, like
> the ones listed below, is this known?
>
> ---
> Nov  4 10:18:55 twilight kernel: [ cut here ]
> Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
> drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x457/0x570()
> Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
> Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
> Tainted: GW   4.3.0 #86
> Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
> INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
> Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
> Nov  4 10:18:55 twilight kernel:  c13b856d  c10788b1
> c14aa787 01eb f6250800 
> Nov  4 10:18:55 twilight kernel: f549e948 f549e938 c107894d 0009
>  c14aa787 0002 f6315400
> Nov  4 10:18:55 twilight kernel: e0ebe600 f6315400 e0ebe600 f6315400
>  e0ebe600 c14aa8ab f6250800
> Nov  4 10:18:55 twilight kernel: Call Trace:
> Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_atomic_check_only+0x457/0x570
> Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_null+0xd/0x10
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_atomic_check_only+0x457/0x570
> Nov  4 10:18:55 twilight kernel: [] ? drm_atomic_commit+0xb/0x50
> Nov  4 10:18:55 twilight kernel: [] ?
> intel_get_load_detect_pipe+0x37d/0x530
> Nov  4 10:18:55 twilight kernel: [] ? intel_tv_detect+0xfb/0x540
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_helper_probe_single_connector_modes_merge_bits+0x293/0x490
> Nov  4 10:18:55 twilight kernel: [] ? kobject_uevent_env+0xd7/0x470
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_helper_probe_single_connector_modes+0x7/0x10
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_fb_helper_probe_connector_modes.isra.5+0x3c/0x60
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_fb_helper_hotplug_event+0x44/0xc0
> Nov  4 10:18:55 twilight kernel: [] ?
> drm_kms_helper_hotplug_event+0x19/0x20
> Nov  4 10:18:55 twilight kernel: [] ? 
> output_poll_execute+0x161/0x1a0
> Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0xef/0x2b0
> Nov  4 10:18:55 twilight kernel: [] ? worker_thread+0x18a/0x400
> Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0x2b0/0x2b0
> Nov  4 10:18:55 twilight kernel: [] ? kthread+0x98/0xb0
> Nov  4 10:18:55 twilight kernel: [] ? 
> ret_from_kernel_thread+0x21/0x30
> Nov  4 10:18:55 twilight kernel: [] ?
> kthread_create_on_node+0x100/0x100
> Nov  4 10:18:55 twilight kernel: ---[ end trace 2c368f52bd242123 ]---
> Nov  4 10:18:55 twilight kernel: [ cut here ]
> Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
> drivers/gpu/drm/i915/intel_display.c:1389
> assert_planes_disabled+0xdf/0x120()
> Nov  4 10:18:55 twilight kernel: plane A assertion failure, should be
> off on pipe A but is still active
> Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
> Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
> Tainted: GW   4.3.0 #86
> Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
> INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
> Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
> Nov  4 10:18:55 twilight kernel:  c13b856d f5bcfd90 c10788b1
> c14f165f 056d f590 0041
> Nov  4 10:18:55 twilight kernel:  0041 c1078906 0009
> f5bcfd90 c1ba0294 f5bcfda8 c14f165f
> Nov  4 10:18:55 twilight kernel: c1ba0010 056d c1ba0294 0041
> 0041 f590  
> Nov  4 10:18:55 twilight kernel: Call Trace:
> Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
> Nov  4 10:18:55 

[BUG] linux 4.3 - intel graphics card driver keeps oopsing

[Ian Kumlien]

Hi,

This happened when i booted linux 4.3 on a old intel machine.

Please note, it's named before "twilight" was known and it's name is
inspired by "twilight zone" since it's actually a firewall ;)

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 1666 root  20   0   0  0  0 R  16,5  0,0  28:19.19 kworker/0:2
 5297 root  20   0   28168   6200   4236 S   6,6  0,3  10:45.31 syslog-ng
7 root  20   0   0  0  0 S   0,7  0,0   0:36.32
rcu_sched

All this cpu usage seems to be required to constantly log OOPSes, like
the ones listed below, is this known?

---
Nov  4 10:18:55 twilight kernel: [ cut here ]
Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x457/0x570()
Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
Tainted: GW   4.3.0 #86
Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
Nov  4 10:18:55 twilight kernel:  c13b856d  c10788b1
c14aa787 01eb f6250800 
Nov  4 10:18:55 twilight kernel: f549e948 f549e938 c107894d 0009
 c14aa787 0002 f6315400
Nov  4 10:18:55 twilight kernel: e0ebe600 f6315400 e0ebe600 f6315400
 e0ebe600 c14aa8ab f6250800
Nov  4 10:18:55 twilight kernel: Call Trace:
Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_check_only+0x457/0x570
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_null+0xd/0x10
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_check_only+0x457/0x570
Nov  4 10:18:55 twilight kernel: [] ? drm_atomic_commit+0xb/0x50
Nov  4 10:18:55 twilight kernel: [] ?
intel_get_load_detect_pipe+0x37d/0x530
Nov  4 10:18:55 twilight kernel: [] ? intel_tv_detect+0xfb/0x540
Nov  4 10:18:55 twilight kernel: [] ?
drm_helper_probe_single_connector_modes_merge_bits+0x293/0x490
Nov  4 10:18:55 twilight kernel: [] ? kobject_uevent_env+0xd7/0x470
Nov  4 10:18:55 twilight kernel: [] ?
drm_helper_probe_single_connector_modes+0x7/0x10
Nov  4 10:18:55 twilight kernel: [] ?
drm_fb_helper_probe_connector_modes.isra.5+0x3c/0x60
Nov  4 10:18:55 twilight kernel: [] ?
drm_fb_helper_hotplug_event+0x44/0xc0
Nov  4 10:18:55 twilight kernel: [] ?
drm_kms_helper_hotplug_event+0x19/0x20
Nov  4 10:18:55 twilight kernel: [] ? output_poll_execute+0x161/0x1a0
Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0xef/0x2b0
Nov  4 10:18:55 twilight kernel: [] ? worker_thread+0x18a/0x400
Nov  4 10:18:55 twilight kernel: [] ? process_one_work+0x2b0/0x2b0
Nov  4 10:18:55 twilight kernel: [] ? kthread+0x98/0xb0
Nov  4 10:18:55 twilight kernel: [] ? ret_from_kernel_thread+0x21/0x30
Nov  4 10:18:55 twilight kernel: [] ?
kthread_create_on_node+0x100/0x100
Nov  4 10:18:55 twilight kernel: ---[ end trace 2c368f52bd242123 ]---
Nov  4 10:18:55 twilight kernel: [ cut here ]
Nov  4 10:18:55 twilight kernel: WARNING: CPU: 0 PID: 1666 at
drivers/gpu/drm/i915/intel_display.c:1389
assert_planes_disabled+0xdf/0x120()
Nov  4 10:18:55 twilight kernel: plane A assertion failure, should be
off on pipe A but is still active
Nov  4 10:18:55 twilight kernel: Modules linked in: tun uas
Nov  4 10:18:55 twilight kernel: CPU: 0 PID: 1666 Comm: kworker/0:2
Tainted: GW   4.3.0 #86
Nov  4 10:18:55 twilight kernel: Hardware name: MICRO-STAR
INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 05/16/2007
Nov  4 10:18:55 twilight kernel: Workqueue: events output_poll_execute
Nov  4 10:18:55 twilight kernel:  c13b856d f5bcfd90 c10788b1
c14f165f 056d f590 0041
Nov  4 10:18:55 twilight kernel:  0041 c1078906 0009
f5bcfd90 c1ba0294 f5bcfda8 c14f165f
Nov  4 10:18:55 twilight kernel: c1ba0010 056d c1ba0294 0041
0041 f590  
Nov  4 10:18:55 twilight kernel: Call Trace:
Nov  4 10:18:55 twilight kernel: [] ? dump_stack+0x3e/0x51
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_common+0x71/0xa0
Nov  4 10:18:55 twilight kernel: [] ?
assert_planes_disabled+0xdf/0x120
Nov  4 10:18:55 twilight kernel: [] ? warn_slowpath_fmt+0x26/0x30
Nov  4 10:18:55 twilight kernel: [] ?
assert_planes_disabled+0xdf/0x120
Nov  4 10:18:55 twilight kernel: [] ? intel_enable_pipe+0x3a/0x200
Nov  4 10:18:55 twilight kernel: [] ? i9xx_crtc_enable+0x282/0x400
Nov  4 10:18:55 twilight kernel: [] ? intel_atomic_commit+0x31d/0x10b0
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_helper_check_planes+0xf5/0x1b0
Nov  4 10:18:55 twilight kernel: [] ? intel_link_compute_m_n+0x50/0x50
Nov  4 10:18:55 twilight kernel: [] ?
drm_atomic_check_only+0x1c9/0x570
Nov  4 10:18:55 twilight kernel: [] ? drm_atomic_commit+0x27/0x50
Nov  4 

[igb] AER timeout - resend.

[Ian Kumlien]

Sending this to both netdev and kernel since i don't know if it's the
driver or the pcie AER that does something odd - the machine was
stable before 3.19 and PCIE AER.

Everything started out like i first sent to linux nics () intel:
--

And today i had some issues and wondered why things was broken, i was met with:

[950016.366477] pcieport :00:04.0: AER: Uncorrected (Non-Fatal)
error received: id=0500
[950016.366495] igb :05:00.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, id=0500(Requester ID)
[950016.366502] igb :05:00.0:   device [8086:1521] error
status/mask=4000/
[950016.366509] igb :05:00.0:[14] Completion Timeout
[950016.366519] igb :05:00.0: broadcast error_detected message
[950016.379742] br0: port 1(enp5s0f0) entered disabled state
[950016.488213] igb :05:00.0: broadcast slot_reset message
[950016.588014] igb :05:00.0: broadcast resume message
[950016.752654] igb :05:00.0: AER: Device recovery successful
[950019.817249] igb :05:00.1 enp5s0f1: igb: enp5s0f1 NIC Link is
Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[950020.699773] igb :05:00.0 enp5s0f0: igb: enp5s0f0 NIC Link is
Up 1000 Mbps Full Duplex, Flow Control: RX
[950020.701485] br0: port 1(enp5s0f0) entered forwarding state
[950020.701504] br0: port 1(enp5s0f0) entered forwarding state
[976152.448092] ata5: exception Emask 0x50 SAct 0x0 SErr 0x4090800
action 0xe frozen
[976152.448100] ata5: irq_stat 0x00400040, connection status changed
[976152.448107] ata5: SError: { HostInt PHYRdyChg 10B8B DevExch }
[976152.448117] ata5: hard resetting link
[976152.448134] ata6: exception Emask 0x50 SAct 0x0 SErr 0x4090800
action 0xe frozen
[976152.448140] ata6: irq_stat 0x00400040, connection status changed
[976152.448147] ata6: SError: { HostInt PHYRdyChg 10B8B DevExch }
[976152.448155] ata6: hard resetting link
[976153.171195] ata6: SATA link down (SStatus 0 SControl 300)
[976158.174058] ata6: hard resetting link
[976158.174110] ata5: SATA link down (SStatus 0 SControl 300)
[976163.176997] ata5: hard resetting link
[976163.480133] ata6: SATA link down (SStatus 0 SControl 300)
[976163.480147] ata6: limiting SATA link speed to 1.5 Gbps
[976168.483028] ata6: hard resetting link
[976168.483095] ata5: SATA link down (SStatus 0 SControl 300)
[976168.483108] ata5: limiting SATA link speed to 1.5 Gbps
[976173.485907] ata5: hard resetting link
[976173.789066] ata6: SATA link down (SStatus 0 SControl 310)
[976173.789080] ata6.00: disabled
[976173.791066] ata6: EH complete
[976173.791078] ata5: SATA link down (SStatus 0 SControl 310)
[976173.791085] ata6.00: detaching (SCSI 5:0:0:0)
[976173.791090] ata5.00: disabled
[976173.794073] ata5: EH complete
[976173.794100] ata5.00: detaching (SCSI 4:0:0:0)
[976173.794968] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
[976173.795073] sd 5:0:0:0: [sdb] Synchronize Cache(10) failed:
Result: hostbyte=0x04 driverbyte=0x00
[976173.795080] sd 5:0:0:0: [sdb] Stopping disk
[976173.795108] sd 5:0:0:0: [sdb] Start/Stop Unit failed: Result:
hostbyte=0x04 driverbyte=0x00
[976173.797180] sd 4:0:0:0: [sda] Synchronizing SCSI cache
[976173.797254] sd 4:0:0:0: [sda] Synchronize Cache(10) failed:
Result: hostbyte=0x04 driverbyte=0x00
[976173.797261] sd 4:0:0:0: [sda] Stopping disk
[976173.797285] sd 4:0:0:0: [sda] Start/Stop Unit failed: Result:
hostbyte=0x04 driverbyte=0x00

So two out of two disks just failed and isn't replying anymore?

Seven hours after a AER this machine who's intel ssd:s are idle just
fail to respond? ;)

Anyway, will reboot it when i get home - any idea/suggestion is more
than welcome.
--
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/

[igb] AER timeout - resend.

[Ian Kumlien]

Sending this to both netdev and kernel since i don't know if it's the
driver or the pcie AER that does something odd - the machine was
stable before 3.19 and PCIE AER.

Everything started out like i first sent to linux nics () intel:
--

And today i had some issues and wondered why things was broken, i was met with:

[950016.366477] pcieport :00:04.0: AER: Uncorrected (Non-Fatal)
error received: id=0500
[950016.366495] igb :05:00.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, id=0500(Requester ID)
[950016.366502] igb :05:00.0:   device [8086:1521] error
status/mask=4000/
[950016.366509] igb :05:00.0:[14] Completion Timeout
[950016.366519] igb :05:00.0: broadcast error_detected message
[950016.379742] br0: port 1(enp5s0f0) entered disabled state
[950016.488213] igb :05:00.0: broadcast slot_reset message
[950016.588014] igb :05:00.0: broadcast resume message
[950016.752654] igb :05:00.0: AER: Device recovery successful
[950019.817249] igb :05:00.1 enp5s0f1: igb: enp5s0f1 NIC Link is
Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[950020.699773] igb :05:00.0 enp5s0f0: igb: enp5s0f0 NIC Link is
Up 1000 Mbps Full Duplex, Flow Control: RX
[950020.701485] br0: port 1(enp5s0f0) entered forwarding state
[950020.701504] br0: port 1(enp5s0f0) entered forwarding state
[976152.448092] ata5: exception Emask 0x50 SAct 0x0 SErr 0x4090800
action 0xe frozen
[976152.448100] ata5: irq_stat 0x00400040, connection status changed
[976152.448107] ata5: SError: { HostInt PHYRdyChg 10B8B DevExch }
[976152.448117] ata5: hard resetting link
[976152.448134] ata6: exception Emask 0x50 SAct 0x0 SErr 0x4090800
action 0xe frozen
[976152.448140] ata6: irq_stat 0x00400040, connection status changed
[976152.448147] ata6: SError: { HostInt PHYRdyChg 10B8B DevExch }
[976152.448155] ata6: hard resetting link
[976153.171195] ata6: SATA link down (SStatus 0 SControl 300)
[976158.174058] ata6: hard resetting link
[976158.174110] ata5: SATA link down (SStatus 0 SControl 300)
[976163.176997] ata5: hard resetting link
[976163.480133] ata6: SATA link down (SStatus 0 SControl 300)
[976163.480147] ata6: limiting SATA link speed to 1.5 Gbps
[976168.483028] ata6: hard resetting link
[976168.483095] ata5: SATA link down (SStatus 0 SControl 300)
[976168.483108] ata5: limiting SATA link speed to 1.5 Gbps
[976173.485907] ata5: hard resetting link
[976173.789066] ata6: SATA link down (SStatus 0 SControl 310)
[976173.789080] ata6.00: disabled
[976173.791066] ata6: EH complete
[976173.791078] ata5: SATA link down (SStatus 0 SControl 310)
[976173.791085] ata6.00: detaching (SCSI 5:0:0:0)
[976173.791090] ata5.00: disabled
[976173.794073] ata5: EH complete
[976173.794100] ata5.00: detaching (SCSI 4:0:0:0)
[976173.794968] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
[976173.795073] sd 5:0:0:0: [sdb] Synchronize Cache(10) failed:
Result: hostbyte=0x04 driverbyte=0x00
[976173.795080] sd 5:0:0:0: [sdb] Stopping disk
[976173.795108] sd 5:0:0:0: [sdb] Start/Stop Unit failed: Result:
hostbyte=0x04 driverbyte=0x00
[976173.797180] sd 4:0:0:0: [sda] Synchronizing SCSI cache
[976173.797254] sd 4:0:0:0: [sda] Synchronize Cache(10) failed:
Result: hostbyte=0x04 driverbyte=0x00
[976173.797261] sd 4:0:0:0: [sda] Stopping disk
[976173.797285] sd 4:0:0:0: [sda] Start/Stop Unit failed: Result:
hostbyte=0x04 driverbyte=0x00

So two out of two disks just failed and isn't replying anymore?

Seven hours after a AER this machine who's intel ssd:s are idle just
fail to respond? ;)

Anyway, will reboot it when i get home - any idea/suggestion is more
than welcome.
--
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: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Ian Kumlien]

Hi,

Sorry to but in like this but I'm suffering from the same kind of
deadlocks with nouveau...

The really odd thing is that i could boot some -rc6+ kernel without
problems but it hung
while playing video and then it refused to start properly again.


Anyway, to quote Maarten:
Ok that most likely means the interrupt based wait is borked somehow,
so lets find \
out why..

I fear that this happens because of a race in the interface, so my
first attempt will \
rule out abuse of the nvif api by nouveau_fence.c

Can you test below patch with the default wait function?
---

I tried the patch, straight on Linus' master and it didn't change
anything for me :(
--
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: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Ian Kumlien]

Hi,

Sorry to but in like this but I'm suffering from the same kind of
deadlocks with nouveau...

The really odd thing is that i could boot some -rc6+ kernel without
problems but it hung
while playing video and then it refused to start properly again.


Anyway, to quote Maarten:
Ok that most likely means the interrupt based wait is borked somehow,
so lets find \
out why..

I fear that this happens because of a race in the interface, so my
first attempt will \
rule out abuse of the nvif api by nouveau_fence.c

Can you test below patch with the default wait function?
---

I tried the patch, straight on Linus' master and it didn't change
anything for me :(
--
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/

[Q] threading and scope_process

[Ian Kumlien]

Hi,

I have to admit that this is perhaps not the best time to write this,
late in the evening after work but... =)

A friend of mine recently started to develop things on Linux and got a
bit confused since Linux lacks PTHREAD_SCOPE_PROCESS which just about
all other OS:es seems to implement.

(Ok, so I have only googled a bit but it seems like all BSD:s has it
since quite some time and the
same goes for OS X and Windows)

At first i thought that this should be somewhat simple to simulate
using cgroups but there seems to be
quite a overhead and a learning curve, while implementing this should
be simpler because cgroups exist =)

Using this, and thus only compete with your own processes, should make
some multimedia applications
easier to do and could be usable for other things as well, I did talk
to some realtime people a while back
and they were quite surprised that it was lacking...

So, in conclusion is there a reason for this being missing or is it
just a question of "show me the code"?
--
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/

[Q] threading and scope_process

[Ian Kumlien]

Hi,

I have to admit that this is perhaps not the best time to write this,
late in the evening after work but... =)

A friend of mine recently started to develop things on Linux and got a
bit confused since Linux lacks PTHREAD_SCOPE_PROCESS which just about
all other OS:es seems to implement.

(Ok, so I have only googled a bit but it seems like all BSD:s has it
since quite some time and the
same goes for OS X and Windows)

At first i thought that this should be somewhat simple to simulate
using cgroups but there seems to be
quite a overhead and a learning curve, while implementing this should
be simpler because cgroups exist =)

Using this, and thus only compete with your own processes, should make
some multimedia applications
easier to do and could be usable for other things as well, I did talk
to some realtime people a while back
and they were quite surprised that it was lacking...

So, in conclusion is there a reason for this being missing or is it
just a question of show me the code?
--
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: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

On Fri, Aug 1, 2014 at 3:16 PM, Imre Deak  wrote:

[--8<--]

> Ok, I see the trace of suspend/resume now, but the bug has vanished.. I
> can't see the WARN backtrace in your original report, nor the debug
> message from the above fix, that would indicate that it had fixed
> anything ("VDD left on by BIOS, adjusting state tracking"). So I'm a bit
> lost, I would need a full dmesg with either the WARN or this debug
> message.

Well the bug seemed to be a unbalanced _put _get thing.

At least that's the impression i got when reading the code, so what i
did, which is part of the original patch, is to make sure that the
_put happens so that the "mode" isn't '0' and thus triggers a warn_on.

What we can say is that due to the patch you sent these are now
balanced in that code...

Actually reading the patches again i can't see how that happened, esp
without the debug message... I think I'll have to play some more with
this and get back to you when $clue has increased by at least one
=)
--
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: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

On Fri, Aug 1, 2014 at 3:16 PM, Imre Deak imre.d...@intel.com wrote:

[--8--]

 Ok, I see the trace of suspend/resume now, but the bug has vanished.. I
 can't see the WARN backtrace in your original report, nor the debug
 message from the above fix, that would indicate that it had fixed
 anything (VDD left on by BIOS, adjusting state tracking). So I'm a bit
 lost, I would need a full dmesg with either the WARN or this debug
 message.

Well the bug seemed to be a unbalanced _put _get thing.

At least that's the impression i got when reading the code, so what i
did, which is part of the original patch, is to make sure that the
_put happens so that the mode isn't '0' and thus triggers a warn_on.

What we can say is that due to the patch you sent these are now
balanced in that code...

Actually reading the patches again i can't see how that happened, esp
without the debug message... I think I'll have to play some more with
this and get back to you when $clue has increased by at least one
=)
--
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: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote:
> On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote:
> > Try four, now including CC lists for the intel driver...
> 
> Could you give a try to the 2 patches at:
> https://patchwork.kernel.org/patch/4437061/
> 
> If these don't fix the issue, could you send a full dmesg log with the
> drm.debug=14 kernel option set?

I will, but the tests will be a bit delayed (earliest tomorrow evening)

> Thanks,
> Imre
> 
> > 
> > ---
> > 
> > Hi again,
> > 
> > 
> > Playing some more with the new kernel release i noticed this:
> > [ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
> > drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
> > [ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
> > snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
> > uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
> > videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep 
> > snd_pcm snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
> > [ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
> > 3.16.0-rc6 #23
> > [ 9064.008840] Hardware name: Apple Inc. 
> > MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133 
> > 11/16/2012
> > [ 9064.008843] Workqueue: events edp_panel_vdd_work
> > [ 9064.008844]  0009 88015ba77d28 8198ea2d 
> > 
> > [ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
> > 000c7204
> > [ 9064.008848]  0001 8802610b80f0 8802610b 
> > 88015ba77d70
> > [ 9064.008850] Call Trace:
> > [ 9064.008854]  [] dump_stack+0x4e/0x7a
> > [ 9064.008857]  [] warn_slowpath_common+0x78/0xa0
> > [ 9064.008858]  [] warn_slowpath_null+0x15/0x20
> > [ 9064.008860]  [] intel_display_power_put+0x12d/0x160
> > [ 9064.008862]  [] edp_panel_vdd_off_sync+0xf4/0x1c0
> > [ 9064.008863]  [] edp_panel_vdd_work+0x2f/0x40
> > [ 9064.008866]  [] process_one_work+0x16e/0x480
> > [ 9064.008868]  [] worker_thread+0x11b/0x520
> > [ 9064.008870]  [] ? create_and_start_worker+0x50/0x50
> > [ 9064.008872]  [] kthread+0xc4/0xe0
> > [ 9064.008874]  [] ? kthread_create_on_node+0x170/0x170
> > [ 9064.008877]  [] ret_from_fork+0x7c/0xb0
> > [ 9064.008878]  [] ? kthread_create_on_node+0x170/0x170
> > [ 9064.008880] ---[ end trace 17f9738f20aec288 ]---
> > 
> > 
> > 
> > I had multiples of them in my dmesg, however, this seems to fix it:
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 8a1a4fb..4c3249d 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
> > *intel_dp)
> > intel_dp->last_power_cycle = jiffies;
> >  
> > power_domain = 
> > intel_display_port_power_domain(intel_encoder);
> > +   intel_display_power_get(dev_priv, power_domain);
> > intel_display_power_put(dev_priv, power_domain);
> > }
> >  }
> > @@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
> >  
> > /* We got a reference when we enabled the VDD. */
> > power_domain = intel_display_port_power_domain(intel_encoder);
> > +   intel_display_power_get(dev_priv, power_domain);
> > intel_display_power_put(dev_priv, power_domain);
> >  }
> > ---
> > 
> > 
> > The question however is: Is this the correct approach? Should it be done
> > differently?
> > (This handles the "close and open lid" usecase, i don't know if there
> > are others, a grep indicated that there might be two more missing...)
> > 
> > 
> > 
> > 
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 


--
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: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote:
 On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote:
  Try four, now including CC lists for the intel driver...
 
 Could you give a try to the 2 patches at:
 https://patchwork.kernel.org/patch/4437061/
 
 If these don't fix the issue, could you send a full dmesg log with the
 drm.debug=14 kernel option set?

I will, but the tests will be a bit delayed (earliest tomorrow evening)

 Thanks,
 Imre
 
  
  ---
  
  Hi again,
  
  
  Playing some more with the new kernel release i noticed this:
  [ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
  drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
  [ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
  snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
  uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
  videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep 
  snd_pcm snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
  [ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
  3.16.0-rc6 #23
  [ 9064.008840] Hardware name: Apple Inc. 
  MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133 
  11/16/2012
  [ 9064.008843] Workqueue: events edp_panel_vdd_work
  [ 9064.008844]  0009 88015ba77d28 8198ea2d 
  
  [ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
  000c7204
  [ 9064.008848]  0001 8802610b80f0 8802610b 
  88015ba77d70
  [ 9064.008850] Call Trace:
  [ 9064.008854]  [8198ea2d] dump_stack+0x4e/0x7a
  [ 9064.008857]  [810cbac8] warn_slowpath_common+0x78/0xa0
  [ 9064.008858]  [810cbba5] warn_slowpath_null+0x15/0x20
  [ 9064.008860]  [815bdb3d] intel_display_power_put+0x12d/0x160
  [ 9064.008862]  [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0
  [ 9064.008863]  [8161e17f] edp_panel_vdd_work+0x2f/0x40
  [ 9064.008866]  [810e63be] process_one_work+0x16e/0x480
  [ 9064.008868]  [810e6cbb] worker_thread+0x11b/0x520
  [ 9064.008870]  [810e6ba0] ? create_and_start_worker+0x50/0x50
  [ 9064.008872]  [810ecb24] kthread+0xc4/0xe0
  [ 9064.008874]  [810eca60] ? kthread_create_on_node+0x170/0x170
  [ 9064.008877]  [81997e6c] ret_from_fork+0x7c/0xb0
  [ 9064.008878]  [810eca60] ? kthread_create_on_node+0x170/0x170
  [ 9064.008880] ---[ end trace 17f9738f20aec288 ]---
  
  
  
  I had multiples of them in my dmesg, however, this seems to fix it:
  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
  b/drivers/gpu/drm/i915/intel_dp.c
  index 8a1a4fb..4c3249d 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
  *intel_dp)
  intel_dp-last_power_cycle = jiffies;
   
  power_domain = 
  intel_display_port_power_domain(intel_encoder);
  +   intel_display_power_get(dev_priv, power_domain);
  intel_display_power_put(dev_priv, power_domain);
  }
   }
  @@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
   
  /* We got a reference when we enabled the VDD. */
  power_domain = intel_display_port_power_domain(intel_encoder);
  +   intel_display_power_get(dev_priv, power_domain);
  intel_display_power_put(dev_priv, power_domain);
   }
  ---
  
  
  The question however is: Is this the correct approach? Should it be done
  differently?
  (This handles the close and open lid usecase, i don't know if there
  are others, a grep indicated that there might be two more missing...)
  
  
  
  
  ___
  Intel-gfx mailing list
  intel-...@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 


--
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/

[BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

Try four, now including CC lists for the intel driver...

---

Hi again,


Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm 
snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d 

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b 
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [] dump_stack+0x4e/0x7a
[ 9064.008857]  [] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [] process_one_work+0x16e/0x480
[ 9064.008868]  [] worker_thread+0x11b/0x520
[ 9064.008870]  [] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [] kthread+0xc4/0xe0
[ 9064.008874]  [] ? kthread_create_on_node+0x170/0x170
[ 9064.008877]  [] ret_from_fork+0x7c/0xb0
[ 9064.008878]  [] ? kthread_create_on_node+0x170/0x170
[ 9064.008880] ---[ end trace 17f9738f20aec288 ]---



I had multiples of them in my dmesg, however, this seems to fix it:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a1a4fb..4c3249d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
intel_dp->last_power_cycle = jiffies;
 
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
}
 }
@@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
 
/* We got a reference when we enabled the VDD. */
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
 }
---


The question however is: Is this the correct approach? Should it be done
differently?
(This handles the "close and open lid" usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)




commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien 
Date:   Tue Jul 22 21:10:50 2014 +0200

Add intel_display_power_get before _put

When closing the lid when using 3.16-rc6 on my laptop i got
three "WARN_ON" back traces.

Example:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at
drivers/gpu/drm/i915/intel_pm.c:5997
intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill
snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc
videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller
snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore
mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133
11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [] dump_stack+0x4e/0x7a
[ 9064.008857]  [] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [] process_one_work+0x16e/0x480
[ 9064.008868]  [] worker_thread+0x11b/0x520
[ 9064.008870]  [] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [] kthread+0xc4/0xe0
[ 9064.008874]  [] ?
kthread_create_on_node+0x170/

[BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

Try four, now including CC lists for the intel driver...

---

Hi again,


Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm 
snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d 

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b 
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [8198ea2d] dump_stack+0x4e/0x7a
[ 9064.008857]  [810cbac8] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [810cbba5] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [815bdb3d] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [8161e17f] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [810e63be] process_one_work+0x16e/0x480
[ 9064.008868]  [810e6cbb] worker_thread+0x11b/0x520
[ 9064.008870]  [810e6ba0] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [810ecb24] kthread+0xc4/0xe0
[ 9064.008874]  [810eca60] ? kthread_create_on_node+0x170/0x170
[ 9064.008877]  [81997e6c] ret_from_fork+0x7c/0xb0
[ 9064.008878]  [810eca60] ? kthread_create_on_node+0x170/0x170
[ 9064.008880] ---[ end trace 17f9738f20aec288 ]---



I had multiples of them in my dmesg, however, this seems to fix it:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a1a4fb..4c3249d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
intel_dp-last_power_cycle = jiffies;
 
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
}
 }
@@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
 
/* We got a reference when we enabled the VDD. */
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
 }
---


The question however is: Is this the correct approach? Should it be done
differently?
(This handles the close and open lid usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)




commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien ian.kuml...@gmail.com
Date:   Tue Jul 22 21:10:50 2014 +0200

Add intel_display_power_get before _put

When closing the lid when using 3.16-rc6 on my laptop i got
three WARN_ON back traces.

Example:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at
drivers/gpu/drm/i915/intel_pm.c:5997
intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill
snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc
videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller
snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore
mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133
11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [8198ea2d] dump_stack+0x4e/0x7a
[ 9064.008857]  [810cbac8] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [810cbba5] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [815bdb3d] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863

[BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

Try three... 

---

Hi again,


Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm 
snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d 

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b 
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [] dump_stack+0x4e/0x7a
[ 9064.008857]  [] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [] process_one_work+0x16e/0x480
[ 9064.008868]  [] worker_thread+0x11b/0x520
[ 9064.008870]  [] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [] kthread+0xc4/0xe0
[ 9064.008874]  [] ? kthread_create_on_node+0x170/0x170
[ 9064.008877]  [] ret_from_fork+0x7c/0xb0
[ 9064.008878]  [] ? kthread_create_on_node+0x170/0x170
[ 9064.008880] ---[ end trace 17f9738f20aec288 ]---



I had multiples of them in my dmesg, however, this seems to fix it:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a1a4fb..4c3249d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
intel_dp->last_power_cycle = jiffies;
 
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
}
 }
@@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
 
/* We got a reference when we enabled the VDD. */
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
 }
---


The question however is: Is this the correct approach? Should it be done
differently?
(This handles the "close and open lid" usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)



commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien 
Date:   Tue Jul 22 21:10:50 2014 +0200

Add intel_display_power_get before _put

When closing the lid when using 3.16-rc6 on my laptop i got
three "WARN_ON" back traces.

Example:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at
drivers/gpu/drm/i915/intel_pm.c:5997
intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill
snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc
videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller
snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore
mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133
11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [] dump_stack+0x4e/0x7a
[ 9064.008857]  [] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [] process_one_work+0x16e/0x480
[ 9064.008868]  [] worker_thread+0x11b/0x520
[ 9064.008870]  [] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [] kthread+0xc4/0xe0
[ 9064.008874]  [] ?
kthread_create_on_node+0x170/0x170
[ 9064.008877]  [] ret_from_fork+0x7c

[BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

Hi again,


Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm 
snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d 

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b 
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [] dump_stack+0x4e/0x7a
[ 9064.008857]  [] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [] process_one_work+0x16e/0x480
[ 9064.008868]  [] worker_thread+0x11b/0x520
[ 9064.008870]  [] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [] kthread+0xc4/0xe0
[ 9064.008874]  [] ? kthread_create_on_node+0x170/0x170
[ 9064.008877]  [] ret_from_fork+0x7c/0xb0
[ 9064.008878]  [] ? kthread_create_on_node+0x170/0x170
[ 9064.008880] ---[ end trace 17f9738f20aec288 ]---



I had multiples of them in my dmesg, however, this seems to fix it:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a1a4fb..4c3249d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
intel_dp->last_power_cycle = jiffies;
 
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
}
 }
@@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
 
/* We got a reference when we enabled the VDD. */
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
 }
---


The question however is: Is this the correct approach? Should it be done
differently?
(This handles the "close and open lid" usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)


commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien 
Date:   Tue Jul 22 21:10:50 2014 +0200

Add intel_display_power_get before _put

When closing the lid when using 3.16-rc6 on my laptop i got
three "WARN_ON" back traces.

Example:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at
drivers/gpu/drm/i915/intel_pm.c:5997
intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill
snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc
videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller
snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore
mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133
11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [] dump_stack+0x4e/0x7a
[ 9064.008857]  [] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [] process_one_work+0x16e/0x480
[ 9064.008868]  [] worker_thread+0x11b/0x520
[ 9064.008870]  [] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [] kthread+0xc4/0xe0
[ 9064.008874]  [] ?
kthread_create_on_node+0x170/0x170
[ 9064.008877]  [] ret_from_fork+0x7c

Re: [RFC] 3.16-rc6 -- fs/direct-io.c:1011 from and to uninitialized.

[Ian Kumlien]

On tis, 2014-07-22 at 12:20 -0700, Randy Dunlap wrote:
> On 07/22/2014 12:03 PM, Ian Kumlien wrote:
> > This is a resend, try two... 
> > 
> > And while the fix is simple, something along the lines of:
> > diff --git a/fs/direct-io.c b/fs/direct-io.c
> > index 98040ba..64a8286 100644
> > --- a/fs/direct-io.c
> > +++ b/fs/direct-io.c
> > @@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct
> > dio_submit *sdi
> >  
> > while (sdio->block_in_file < sdio->final_block_in_request) {
> > struct page *page;
> > -   size_t from, to;
> > +   size_t from, to = {0};
> > page = dio_get_page(dio, sdio, , );
> > if (IS_ERR(page)) {
> > ret = PTR_ERR(page);
> > ---
> > 
> > I however don't know if it's in the correct C standard, it compiles fine
> > though... (or if this is more gcc speific)
> 
> so... do you know C or not?

I know C but i don't know if this got added in C99 or C11 or how they
denote it.

> Why the braces around the 0?

Because it's special

> Why do you initialize 'to' but not 'from'?

The magic of {0} is that it will initialize all your values.

--
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: [RFC] 3.16-rc6 -- fs/direct-io.c:1011 from and to uninitialized.

[Ian Kumlien]

On tis, 2014-07-22 at 21:12 +0200, Richard Weinberger wrote:
> On Tue, Jul 22, 2014 at 9:03 PM, Ian Kumlien  wrote:
> > This is a resend, try two...
> 
> Please see "[PATCH v3] direct-io: fix uninitialized warning in 
> do_direct_IO()".

That looks like a better approach, couldn't find it before i started
sending this and my emails are autofiltered if you send via the web
ui.. ;)

> > ---
> > Hi,
> >
> > While playing around compiling the kernel i noticed the following:
> > fs/direct-io.c: In function ‘do_blockdev_direct_IO’:
> > fs/direct-io.c:1022:29: warning: ‘from’ may be used uninitialized in
> > this function [-Wmaybe-uninitialized]
> > ret = submit_page_section(dio, sdio, page,
> >  ^
> > fs/direct-io.c:913:10: note: ‘from’ was declared here
> >size_t from, to;
> >   ^
> > fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
> > function [-Wmaybe-uninitialized]
> > u = (to - from) >> blkbits;
> > ^
> > fs/direct-io.c:913:16: note: ‘to’ was declared here
> >size_t from, to;
> > ^
> > ---
> >
> >
> > And while the fix is simple, something along the lines of:
> > diff --git a/fs/direct-io.c b/fs/direct-io.c
> > index 98040ba..64a8286 100644
> > --- a/fs/direct-io.c
> > +++ b/fs/direct-io.c
> > @@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct
> > dio_submit *sdi
> >
> > while (sdio->block_in_file < sdio->final_block_in_request) {
> > struct page *page;
> > -   size_t from, to;
> > +   size_t from, to = {0};
> > page = dio_get_page(dio, sdio, , );
> > if (IS_ERR(page)) {
> > ret = PTR_ERR(page);
> > ---
> >
> > I however don't know if it's in the correct C standard, it compiles fine
> > though... (or if this is more gcc speific)
> >
> >
> >
> 
> 
> 


--
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/

[RFC] 3.16-rc6 -- fs/direct-io.c:1011 from and to uninitialized.

[Ian Kumlien]

This is a resend, try two... 

---
Hi,

While playing around compiling the kernel i noticed the following:
fs/direct-io.c: In function ‘do_blockdev_direct_IO’:
fs/direct-io.c:1022:29: warning: ‘from’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
ret = submit_page_section(dio, sdio, page,
 ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
  ^
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
u = (to - from) >> blkbits;
^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
^
---


And while the fix is simple, something along the lines of:
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 98040ba..64a8286 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct
dio_submit *sdi
 
while (sdio->block_in_file < sdio->final_block_in_request) {
struct page *page;
-   size_t from, to;
+   size_t from, to = {0};
page = dio_get_page(dio, sdio, , );
if (IS_ERR(page)) {
ret = PTR_ERR(page);
---

I however don't know if it's in the correct C standard, it compiles fine
though... (or if this is more gcc speific)



commit f94d05ce10d869c418d3271bd028fc33bfd25e6f
Author: Ian Kumlien 
Date:   Tue Jul 22 20:57:50 2014 +0200

Initialize the to and from fields

While compliling the 3.16-rc6 kernel I saw this:
fs/direct-io.c: In function ‘do_blockdev_direct_IO’:
fs/direct-io.c:1022:29: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ret = submit_page_section(dio, sdio, page,
 ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
  ^
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
u = (to - from) >> blkbits;
^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
^
---

This small changes makes sure that the values are initialized.
    
    Signed-off-by: Ian Kumlien 

diff --git a/fs/direct-io.c b/fs/direct-io.c
index 98040ba..64a8286 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct dio_submit *sdio,
 
while (sdio->block_in_file < sdio->final_block_in_request) {
struct page *page;
-   size_t from, to;
+   size_t from, to = {0};
page = dio_get_page(dio, sdio, , );
if (IS_ERR(page)) {
ret = PTR_ERR(page);

[RFC] 3.16-rc6 -- fs/direct-io.c:1011 from and to uninitialized.

[Ian Kumlien]

This is a resend, try two... 

---
Hi,

While playing around compiling the kernel i noticed the following:
fs/direct-io.c: In function ‘do_blockdev_direct_IO’:
fs/direct-io.c:1022:29: warning: ‘from’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
ret = submit_page_section(dio, sdio, page,
 ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
  ^
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
u = (to - from)  blkbits;
^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
^
---


And while the fix is simple, something along the lines of:
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 98040ba..64a8286 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct
dio_submit *sdi
 
while (sdio-block_in_file  sdio-final_block_in_request) {
struct page *page;
-   size_t from, to;
+   size_t from, to = {0};
page = dio_get_page(dio, sdio, from, to);
if (IS_ERR(page)) {
ret = PTR_ERR(page);
---

I however don't know if it's in the correct C standard, it compiles fine
though... (or if this is more gcc speific)



commit f94d05ce10d869c418d3271bd028fc33bfd25e6f
Author: Ian Kumlien ian.kuml...@gmail.com
Date:   Tue Jul 22 20:57:50 2014 +0200

Initialize the to and from fields

While compliling the 3.16-rc6 kernel I saw this:
fs/direct-io.c: In function ‘do_blockdev_direct_IO’:
fs/direct-io.c:1022:29: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ret = submit_page_section(dio, sdio, page,
 ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
  ^
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
u = (to - from)  blkbits;
^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
^
---

This small changes makes sure that the values are initialized.

Signed-off-by: Ian Kumlien ian.kuml...@gmail.com

diff --git a/fs/direct-io.c b/fs/direct-io.c
index 98040ba..64a8286 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct dio_submit *sdio,
 
while (sdio-block_in_file  sdio-final_block_in_request) {
struct page *page;
-   size_t from, to;
+   size_t from, to = {0};
page = dio_get_page(dio, sdio, from, to);
if (IS_ERR(page)) {
ret = PTR_ERR(page);

Re: [RFC] 3.16-rc6 -- fs/direct-io.c:1011 from and to uninitialized.

[Ian Kumlien]

On tis, 2014-07-22 at 21:12 +0200, Richard Weinberger wrote:
 On Tue, Jul 22, 2014 at 9:03 PM, Ian Kumlien ian.kuml...@gmail.com wrote:
  This is a resend, try two...
 
 Please see [PATCH v3] direct-io: fix uninitialized warning in 
 do_direct_IO().

That looks like a better approach, couldn't find it before i started
sending this and my emails are autofiltered if you send via the web
ui.. ;)

  ---
  Hi,
 
  While playing around compiling the kernel i noticed the following:
  fs/direct-io.c: In function ‘do_blockdev_direct_IO’:
  fs/direct-io.c:1022:29: warning: ‘from’ may be used uninitialized in
  this function [-Wmaybe-uninitialized]
  ret = submit_page_section(dio, sdio, page,
   ^
  fs/direct-io.c:913:10: note: ‘from’ was declared here
 size_t from, to;
^
  fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
  function [-Wmaybe-uninitialized]
  u = (to - from)  blkbits;
  ^
  fs/direct-io.c:913:16: note: ‘to’ was declared here
 size_t from, to;
  ^
  ---
 
 
  And while the fix is simple, something along the lines of:
  diff --git a/fs/direct-io.c b/fs/direct-io.c
  index 98040ba..64a8286 100644
  --- a/fs/direct-io.c
  +++ b/fs/direct-io.c
  @@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct
  dio_submit *sdi
 
  while (sdio-block_in_file  sdio-final_block_in_request) {
  struct page *page;
  -   size_t from, to;
  +   size_t from, to = {0};
  page = dio_get_page(dio, sdio, from, to);
  if (IS_ERR(page)) {
  ret = PTR_ERR(page);
  ---
 
  I however don't know if it's in the correct C standard, it compiles fine
  though... (or if this is more gcc speific)
 
 
 
 
 
 


--
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: [RFC] 3.16-rc6 -- fs/direct-io.c:1011 from and to uninitialized.

[Ian Kumlien]

On tis, 2014-07-22 at 12:20 -0700, Randy Dunlap wrote:
 On 07/22/2014 12:03 PM, Ian Kumlien wrote:
  This is a resend, try two... 
  
  And while the fix is simple, something along the lines of:
  diff --git a/fs/direct-io.c b/fs/direct-io.c
  index 98040ba..64a8286 100644
  --- a/fs/direct-io.c
  +++ b/fs/direct-io.c
  @@ -910,7 +910,7 @@ static int do_direct_IO(struct dio *dio, struct
  dio_submit *sdi
   
  while (sdio-block_in_file  sdio-final_block_in_request) {
  struct page *page;
  -   size_t from, to;
  +   size_t from, to = {0};
  page = dio_get_page(dio, sdio, from, to);
  if (IS_ERR(page)) {
  ret = PTR_ERR(page);
  ---
  
  I however don't know if it's in the correct C standard, it compiles fine
  though... (or if this is more gcc speific)
 
 so... do you know C or not?

I know C but i don't know if this got added in C99 or C11 or how they
denote it.

 Why the braces around the 0?

Because it's special

 Why do you initialize 'to' but not 'from'?

The magic of {0} is that it will initialize all your values.

--
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/

[BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

Hi again,


Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm 
snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d 

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b 
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [8198ea2d] dump_stack+0x4e/0x7a
[ 9064.008857]  [810cbac8] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [810cbba5] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [815bdb3d] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [8161e17f] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [810e63be] process_one_work+0x16e/0x480
[ 9064.008868]  [810e6cbb] worker_thread+0x11b/0x520
[ 9064.008870]  [810e6ba0] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [810ecb24] kthread+0xc4/0xe0
[ 9064.008874]  [810eca60] ? kthread_create_on_node+0x170/0x170
[ 9064.008877]  [81997e6c] ret_from_fork+0x7c/0xb0
[ 9064.008878]  [810eca60] ? kthread_create_on_node+0x170/0x170
[ 9064.008880] ---[ end trace 17f9738f20aec288 ]---



I had multiples of them in my dmesg, however, this seems to fix it:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a1a4fb..4c3249d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
intel_dp-last_power_cycle = jiffies;
 
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
}
 }
@@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
 
/* We got a reference when we enabled the VDD. */
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
 }
---


The question however is: Is this the correct approach? Should it be done
differently?
(This handles the close and open lid usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)


commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien ian.kuml...@gmail.com
Date:   Tue Jul 22 21:10:50 2014 +0200

Add intel_display_power_get before _put

When closing the lid when using 3.16-rc6 on my laptop i got
three WARN_ON back traces.

Example:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at
drivers/gpu/drm/i915/intel_pm.c:5997
intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill
snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc
videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller
snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore
mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133
11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [8198ea2d] dump_stack+0x4e/0x7a
[ 9064.008857]  [810cbac8] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [810cbba5] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [815bdb3d] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [8161e17f] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866

[BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()

[Ian Kumlien]

Try three... 

---

Hi again,


Playing some more with the new kernel release i noticed this:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at 
drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus 
uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops 
videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm 
snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d 

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c 
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b 
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [8198ea2d] dump_stack+0x4e/0x7a
[ 9064.008857]  [810cbac8] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [810cbba5] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [815bdb3d] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [8161e17f] edp_panel_vdd_work+0x2f/0x40
[ 9064.008866]  [810e63be] process_one_work+0x16e/0x480
[ 9064.008868]  [810e6cbb] worker_thread+0x11b/0x520
[ 9064.008870]  [810e6ba0] ? create_and_start_worker+0x50/0x50
[ 9064.008872]  [810ecb24] kthread+0xc4/0xe0
[ 9064.008874]  [810eca60] ? kthread_create_on_node+0x170/0x170
[ 9064.008877]  [81997e6c] ret_from_fork+0x7c/0xb0
[ 9064.008878]  [810eca60] ? kthread_create_on_node+0x170/0x170
[ 9064.008880] ---[ end trace 17f9738f20aec288 ]---



I had multiples of them in my dmesg, however, this seems to fix it:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a1a4fb..4c3249d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
intel_dp-last_power_cycle = jiffies;
 
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
}
 }
@@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
 
/* We got a reference when we enabled the VDD. */
power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
intel_display_power_put(dev_priv, power_domain);
 }
---


The question however is: Is this the correct approach? Should it be done
differently?
(This handles the close and open lid usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)



commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien ian.kuml...@gmail.com
Date:   Tue Jul 22 21:10:50 2014 +0200

Add intel_display_power_get before _put

When closing the lid when using 3.16-rc6 on my laptop i got
three WARN_ON back traces.

Example:
[ 9064.008821] WARNING: CPU: 3 PID: 22929 at
drivers/gpu/drm/i915/intel_pm.c:5997
intel_display_power_put+0x12d/0x160()
[ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211
snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill
snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc
videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller
snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore
mmc_core bcma
[ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW
3.16.0-rc6 #23
[ 9064.008840] Hardware name: Apple Inc.
MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133
11/16/2012
[ 9064.008843] Workqueue: events edp_panel_vdd_work
[ 9064.008844]  0009 88015ba77d28 8198ea2d

[ 9064.008846]  88015ba77d60 810cbac8 8802610b002c
000c7204
[ 9064.008848]  0001 8802610b80f0 8802610b
88015ba77d70
[ 9064.008850] Call Trace:
[ 9064.008854]  [8198ea2d] dump_stack+0x4e/0x7a
[ 9064.008857]  [810cbac8] warn_slowpath_common+0x78/0xa0
[ 9064.008858]  [810cbba5] warn_slowpath_null+0x15/0x20
[ 9064.008860]  [815bdb3d] intel_display_power_put+0x12d/0x160
[ 9064.008862]  [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0
[ 9064.008863]  [8161e17f] edp_panel_vdd_work+0x2f/0x40

Re: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On ons, 2014-01-22 at 11:52 +1100, NeilBrown wrote:
> On Mon, 20 Jan 2014 19:27:18 +0100 Ian Kumlien  wrote:
> > I have been unable to trip this up, so this was it!
> > 
> > Tested-by: Ian Kumlien 
> > 
> > I hope this hits stable ASAP ;)
> 
> I've push it out into my for-next branch.
> I'll probably send a pull request to Linus tomorrow.
> It has some chance of getting into a -stable branch next week (though I'm not
> really sure of the schedule).

Good, I bet I'm not the only one that will hit this...

> Thanks again for testing and reporting!

No problem, and thank you! ;)

> NeilBrown


--
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: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On ons, 2014-01-22 at 11:52 +1100, NeilBrown wrote:
 On Mon, 20 Jan 2014 19:27:18 +0100 Ian Kumlien ian.kuml...@gmail.com wrote:
  I have been unable to trip this up, so this was it!
  
  Tested-by: Ian Kumlien ian.kuml...@gmail.com
  
  I hope this hits stable ASAP ;)
 
 I've push it out into my for-next branch.
 I'll probably send a pull request to Linus tomorrow.
 It has some chance of getting into a -stable branch next week (though I'm not
 really sure of the schedule).

Good, I bet I'm not the only one that will hit this...

 Thanks again for testing and reporting!

No problem, and thank you! ;)

 NeilBrown


--
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: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On mån, 2014-01-20 at 14:37 +1100, NeilBrown wrote:
> 
> Thanks - that extra info is quite useful.  Knowing that nothing else unusual
> is happening can be quite valuable (and I don't like to assume).
> 
> I haven't found anything that would clearly cause your crash, but I have
> found something that looks wrong and conceivably could.
> 
> Could you please try this patch on top of what you are currently using?  By
> the look of it you get a crash at least every day, often more often.  So if
> this produces a day with no crashes, that would be promising.
> 
> The important aspect of the patch is that it moves the "atomic_inc" of
> "sh->count" back under the protection of ->device_lock in the case when some
> other thread might be using the same 'sh'.

I have been unable to trip this up, so this was it!

Tested-by: Ian Kumlien 

I hope this hits stable ASAP ;)

> Thanks,
> NeilBrown
> 
> 
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 3088d3af5a89..03f82ab87d9e 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -675,8 +675,10 @@ get_active_stripe(struct r5conf *conf, sector_t sector,
>|| !conf->inactive_blocked),
>   *(conf->hash_locks + hash));
>   conf->inactive_blocked = 0;
> - } else
> + } else {
>   init_stripe(sh, sector, previous);
> + atomic_inc(>count);
> + }
>   } else {
>   spin_lock(>device_lock);
>   if (atomic_read(>count)) {
> @@ -695,13 +697,11 @@ get_active_stripe(struct r5conf *conf, sector_t sector,
>   sh->group = NULL;
>   }
>   }
> + atomic_inc(>count);
>   spin_unlock(>device_lock);
>   }
>   } while (sh == NULL);
>  
> - if (sh)
> - atomic_inc(>count);
> -
>   spin_unlock_irq(conf->hash_locks + hash);
>   return sh;
>  }


--
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: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On mån, 2014-01-20 at 14:37 +1100, NeilBrown wrote:
> On Mon, 20 Jan 2014 01:49:17 +0100 Ian Kumlien  wrote:
> 
> > On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
> > > On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien  
> > > wrote:
> > > 
> > > > Ok, so third try to actually email this... 
> > > > ---
> > > > 
> > > > Hi,
> > > > 
> > > > I started testing 3.13-rc8 on another machine since the first one seemed
> > > > to be working fine...
> > > > 
> > > > One spontaneous reboot later i'm not so sure ;)
> > > > 
> > > > Right now i captured a kernel oops in the raid code it seems...
> > > > 
> > > > (Also attached to avoid mangling)
> > > > 
> > > > [33411.934672] [ cut here ]
> > > > [33411.934685] kernel BUG at drivers/md/raid5.c:291!
> > > > [33411.934690] invalid opcode:  [#1] PREEMPT SMP 
> > > > [33411.934696] Modules linked in: bonding btrfs microcode
> > > > [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 
> > > > #83
> > > > [33411.934709] Hardware name: System manufacturer System Product 
> > > > Name/Crosshair IV Formula, BIOS 302910/09/2012
> > > > [33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
> > > > 880320472000
> > > > [33411.934720] RIP: 0010:[]  [] 
> > > > do_release_stripe+0x18e/0x1a0
> > > > [33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
> > > > [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 
> > > > 8800b0d816b0
> > > > [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 
> > > > 880324eeec00
> > > > [33411.934743] RBP: 8802f0875a50 R08:  R09: 
> > > > 0001
> > > > [33411.934747] R10:  R11:  R12: 
> > > > 880324eeec00
> > > > [33411.934752] R13: 88032458 R14: 880320473e88 R15: 
> > > > 
> > > > [33411.934756] FS:  7fc38654d700() GS:880337d0() 
> > > > knlGS:
> > > > [33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
> > > > [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 
> > > > 000407e0
> > > > [33411.934769] Stack:
> > > > [33411.934771]  8800bba09690 8800b4f16588 880303005a40 
> > > > 0001
> > > > [33411.934779]  8800b33e43d0 81a3a62d 88032458 
> > > > 
> > > > [33411.934786]  88032458 880326660670 880326265880 
> > > > 81a41692
> > > > [33411.934794] Call Trace:
> > > > [33411.934798]  [] ? release_stripe_list+0x4d/0x70
> > > > [33411.934803]  [] ? raid5d+0xa2/0x4d0
> > > > [33411.934808]  [] ? md_thread+0xe6/0x120
> > > > [33411.934814]  [] ? finish_wait+0x90/0x90
> > > > [33411.934818]  [] ? md_rdev_init+0x100/0x100
> > > > [33411.934823]  [] ? kthread+0xbc/0xe0
> > > > [33411.934828]  [] ? smpboot_park_threads+0x70/0x70Hi,
> > > 
> > > Thanks for the report.
> > > Can you provide any more context about the details of the array in 
> > > question?
> > > I see it was RAID6.  Was it degraded?  Was it resyncing?  Was it being
> > > reshaped?
> > > Was there any way that it was different from the array one the machine 
> > > where
> > > it seemed to work?
> > 
> > Yes, it's a raid6 and no, there is no reshaping or syncing going on... 
> > 
> > Basically everything worked fine before:
> > reboot   system boot  3.13.0-rc8   Sun Jan 19 21:47 - 01:42  (03:55)
> > reboot   system boot  3.13.0-rc8   Sun Jan 19 21:38 - 01:42  (04:04)
> > reboot   system boot  3.13.0-rc8   Sun Jan 19 12:13 - 01:42  (13:29)
> > reboot   system boot  3.13.0-rc8   Sat Jan 18 21:23 - 01:42 (1+04:19)   
> > reboot   system boot  3.12.6   Mon Dec 30 16:27 - 22:21 (19+05:53)  
> > 
> > As in, no problems before the 3.13.0-rc8 upgrade...
> > 
> > cat /proc/mdstat:
> > Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
> > [multipath] 
> > md2 : active raid6 sdf1[2] sdd1[9] sdj1[8] sdg1[4] sde1[5] sdi1[11] sdc1[0] 
> > sdh1[10]
> >   11721074304 blocks super 1.2 level 6, 6

Re: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On mån, 2014-01-20 at 14:37 +1100, NeilBrown wrote:
 
 Thanks - that extra info is quite useful.  Knowing that nothing else unusual
 is happening can be quite valuable (and I don't like to assume).
 
 I haven't found anything that would clearly cause your crash, but I have
 found something that looks wrong and conceivably could.
 
 Could you please try this patch on top of what you are currently using?  By
 the look of it you get a crash at least every day, often more often.  So if
 this produces a day with no crashes, that would be promising.
 
 The important aspect of the patch is that it moves the atomic_inc of
 sh-count back under the protection of -device_lock in the case when some
 other thread might be using the same 'sh'.

I have been unable to trip this up, so this was it!

Tested-by: Ian Kumlien ian.kuml...@gmail.com

I hope this hits stable ASAP ;)

 Thanks,
 NeilBrown
 
 
 diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
 index 3088d3af5a89..03f82ab87d9e 100644
 --- a/drivers/md/raid5.c
 +++ b/drivers/md/raid5.c
 @@ -675,8 +675,10 @@ get_active_stripe(struct r5conf *conf, sector_t sector,
|| !conf-inactive_blocked),
   *(conf-hash_locks + hash));
   conf-inactive_blocked = 0;
 - } else
 + } else {
   init_stripe(sh, sector, previous);
 + atomic_inc(sh-count);
 + }
   } else {
   spin_lock(conf-device_lock);
   if (atomic_read(sh-count)) {
 @@ -695,13 +697,11 @@ get_active_stripe(struct r5conf *conf, sector_t sector,
   sh-group = NULL;
   }
   }
 + atomic_inc(sh-count);
   spin_unlock(conf-device_lock);
   }
   } while (sh == NULL);
  
 - if (sh)
 - atomic_inc(sh-count);
 -
   spin_unlock_irq(conf-hash_locks + hash);
   return sh;
  }


--
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: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On mån, 2014-01-20 at 14:37 +1100, NeilBrown wrote:
 On Mon, 20 Jan 2014 01:49:17 +0100 Ian Kumlien ian.kuml...@gmail.com wrote:
 
  On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
   On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien ian.kuml...@gmail.com 
   wrote:
   
Ok, so third try to actually email this... 
---

Hi,

I started testing 3.13-rc8 on another machine since the first one seemed
to be working fine...

One spontaneous reboot later i'm not so sure ;)

Right now i captured a kernel oops in the raid code it seems...

(Also attached to avoid mangling)

[33411.934672] [ cut here ]
[33411.934685] kernel BUG at drivers/md/raid5.c:291!
[33411.934690] invalid opcode:  [#1] PREEMPT SMP 
[33411.934696] Modules linked in: bonding btrfs microcode
[33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 
#83
[33411.934709] Hardware name: System manufacturer System Product 
Name/Crosshair IV Formula, BIOS 302910/09/2012
[33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
880320472000
[33411.934720] RIP: 0010:[81a3a5be]  [81a3a5be] 
do_release_stripe+0x18e/0x1a0
[33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
[33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 
8800b0d816b0
[33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 
880324eeec00
[33411.934743] RBP: 8802f0875a50 R08:  R09: 
0001
[33411.934747] R10:  R11:  R12: 
880324eeec00
[33411.934752] R13: 88032458 R14: 880320473e88 R15: 

[33411.934756] FS:  7fc38654d700() GS:880337d0() 
knlGS:
[33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
[33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 
000407e0
[33411.934769] Stack:
[33411.934771]  8800bba09690 8800b4f16588 880303005a40 
0001
[33411.934779]  8800b33e43d0 81a3a62d 88032458 

[33411.934786]  88032458 880326660670 880326265880 
81a41692
[33411.934794] Call Trace:
[33411.934798]  [81a3a62d] ? release_stripe_list+0x4d/0x70
[33411.934803]  [81a41692] ? raid5d+0xa2/0x4d0
[33411.934808]  [81a65ed6] ? md_thread+0xe6/0x120
[33411.934814]  [81122060] ? finish_wait+0x90/0x90
[33411.934818]  [81a65df0] ? md_rdev_init+0x100/0x100
[33411.934823]  [8110958c] ? kthread+0xbc/0xe0
[33411.934828]  [8111] ? smpboot_park_threads+0x70/0x70Hi,
   
   Thanks for the report.
   Can you provide any more context about the details of the array in 
   question?
   I see it was RAID6.  Was it degraded?  Was it resyncing?  Was it being
   reshaped?
   Was there any way that it was different from the array one the machine 
   where
   it seemed to work?
  
  Yes, it's a raid6 and no, there is no reshaping or syncing going on... 
  
  Basically everything worked fine before:
  reboot   system boot  3.13.0-rc8   Sun Jan 19 21:47 - 01:42  (03:55)
  reboot   system boot  3.13.0-rc8   Sun Jan 19 21:38 - 01:42  (04:04)
  reboot   system boot  3.13.0-rc8   Sun Jan 19 12:13 - 01:42  (13:29)
  reboot   system boot  3.13.0-rc8   Sat Jan 18 21:23 - 01:42 (1+04:19)   
  reboot   system boot  3.12.6   Mon Dec 30 16:27 - 22:21 (19+05:53)  
  
  As in, no problems before the 3.13.0-rc8 upgrade...
  
  cat /proc/mdstat:
  Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
  [multipath] 
  md2 : active raid6 sdf1[2] sdd1[9] sdj1[8] sdg1[4] sde1[5] sdi1[11] sdc1[0] 
  sdh1[10]
11721074304 blocks super 1.2 level 6, 64k chunk, algorithm 2 [8/8] 
  []
bitmap: 0/15 pages [0KB], 65536KB chunk
  
  What i do do is:
  echo 32768  /sys/block/*/md/stripe_cache_size
  
  Which has caused no problems during intense write operations before... 
  
  I find it quite surprising since it only requires ~3 gigabytes of writes
  to die and almost assume that it's related to the stripe_cache_size.
  (Since all memory is ECC and i doubt it would break, quite literally,
  over night i haven't run extensive memory tests)
  
  I don't quite know what other information you might need...
 
 Thanks - that extra info is quite useful.  Knowing that nothing else unusual
 is happening can be quite valuable (and I don't like to assume).

Yeah, i know, it can be hard to know which information to provide though
=)

 I haven't found anything that would clearly cause your crash, but I have
 found something that looks wrong and conceivably could.
 
 Could you please try this patch on top of what you are currently using?  By
 the look of it you get

Re: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
> On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien  wrote:
> 
> > Ok, so third try to actually email this... 
> > ---
> > 
> > Hi,
> > 
> > I started testing 3.13-rc8 on another machine since the first one seemed
> > to be working fine...
> > 
> > One spontaneous reboot later i'm not so sure ;)
> > 
> > Right now i captured a kernel oops in the raid code it seems...
> > 
> > (Also attached to avoid mangling)
> > 
> > [33411.934672] [ cut here ]
> > [33411.934685] kernel BUG at drivers/md/raid5.c:291!
> > [33411.934690] invalid opcode:  [#1] PREEMPT SMP 
> > [33411.934696] Modules linked in: bonding btrfs microcode
> > [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83
> > [33411.934709] Hardware name: System manufacturer System Product 
> > Name/Crosshair IV Formula, BIOS 302910/09/2012
> > [33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
> > 880320472000
> > [33411.934720] RIP: 0010:[]  [] 
> > do_release_stripe+0x18e/0x1a0
> > [33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
> > [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 
> > 8800b0d816b0
> > [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 
> > 880324eeec00
> > [33411.934743] RBP: 8802f0875a50 R08:  R09: 
> > 0001
> > [33411.934747] R10:  R11:  R12: 
> > 880324eeec00
> > [33411.934752] R13: 88032458 R14: 880320473e88 R15: 
> > 
> > [33411.934756] FS:  7fc38654d700() GS:880337d0() 
> > knlGS:
> > [33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
> > [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 
> > 000407e0
> > [33411.934769] Stack:
> > [33411.934771]  8800bba09690 8800b4f16588 880303005a40 
> > 0001
> > [33411.934779]  8800b33e43d0 81a3a62d 88032458 
> > 
> > [33411.934786]  88032458 880326660670 880326265880 
> > 81a41692
> > [33411.934794] Call Trace:
> > [33411.934798]  [] ? release_stripe_list+0x4d/0x70
> > [33411.934803]  [] ? raid5d+0xa2/0x4d0
> > [33411.934808]  [] ? md_thread+0xe6/0x120
> > [33411.934814]  [] ? finish_wait+0x90/0x90
> > [33411.934818]  [] ? md_rdev_init+0x100/0x100
> > [33411.934823]  [] ? kthread+0xbc/0xe0
> > [33411.934828]  [] ? smpboot_park_threads+0x70/0x70Hi,
> 
> Thanks for the report.
> Can you provide any more context about the details of the array in question?
> I see it was RAID6.  Was it degraded?  Was it resyncing?  Was it being
> reshaped?
> Was there any way that it was different from the array one the machine where
> it seemed to work?

Yes, it's a raid6 and no, there is no reshaping or syncing going on... 

Basically everything worked fine before:
reboot   system boot  3.13.0-rc8   Sun Jan 19 21:47 - 01:42  (03:55)
reboot   system boot  3.13.0-rc8   Sun Jan 19 21:38 - 01:42  (04:04)
reboot   system boot  3.13.0-rc8   Sun Jan 19 12:13 - 01:42  (13:29)
reboot   system boot  3.13.0-rc8   Sat Jan 18 21:23 - 01:42 (1+04:19)   
reboot   system boot  3.12.6   Mon Dec 30 16:27 - 22:21 (19+05:53)  

As in, no problems before the 3.13.0-rc8 upgrade...

cat /proc/mdstat:
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
[multipath] 
md2 : active raid6 sdf1[2] sdd1[9] sdj1[8] sdg1[4] sde1[5] sdi1[11] sdc1[0] 
sdh1[10]
  11721074304 blocks super 1.2 level 6, 64k chunk, algorithm 2 [8/8] 
[]
  bitmap: 0/15 pages [0KB], 65536KB chunk

What i do do is:
echo 32768 > /sys/block/*/md/stripe_cache_size

Which has caused no problems during intense write operations before... 

I find it quite surprising since it only requires ~3 gigabytes of writes
to die and almost assume that it's related to the stripe_cache_size.
(Since all memory is ECC and i doubt it would break, quite literally,
over night i haven't run extensive memory tests)

I don't quite know what other information you might need...

> Thanks,
> NeilBrown


--
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/

[BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

Ok, so third try to actually email this... 
---

Hi,

I started testing 3.13-rc8 on another machine since the first one seemed
to be working fine...

One spontaneous reboot later i'm not so sure ;)

Right now i captured a kernel oops in the raid code it seems...

(Also attached to avoid mangling)

[33411.934672] [ cut here ]
[33411.934685] kernel BUG at drivers/md/raid5.c:291!
[33411.934690] invalid opcode:  [#1] PREEMPT SMP 
[33411.934696] Modules linked in: bonding btrfs microcode
[33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83
[33411.934709] Hardware name: System manufacturer System Product Name/Crosshair 
IV Formula, BIOS 302910/09/2012
[33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
880320472000
[33411.934720] RIP: 0010:[]  [] 
do_release_stripe+0x18e/0x1a0
[33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
[33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 8800b0d816b0
[33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 880324eeec00
[33411.934743] RBP: 8802f0875a50 R08:  R09: 0001
[33411.934747] R10:  R11:  R12: 880324eeec00
[33411.934752] R13: 88032458 R14: 880320473e88 R15: 
[33411.934756] FS:  7fc38654d700() GS:880337d0() 
knlGS:
[33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
[33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 000407e0
[33411.934769] Stack:
[33411.934771]  8800bba09690 8800b4f16588 880303005a40 
0001
[33411.934779]  8800b33e43d0 81a3a62d 88032458 

[33411.934786]  88032458 880326660670 880326265880 
81a41692
[33411.934794] Call Trace:
[33411.934798]  [] ? release_stripe_list+0x4d/0x70
[33411.934803]  [] ? raid5d+0xa2/0x4d0
[33411.934808]  [] ? md_thread+0xe6/0x120
[33411.934814]  [] ? finish_wait+0x90/0x90
[33411.934818]  [] ? md_rdev_init+0x100/0x100
[33411.934823]  [] ? kthread+0xbc/0xe0
[33411.934828]  [] ? smpboot_park_threads+0x70/0x70Hi,

I started testing 3.13-rc8 on another machine since the first one seemed to be 
working fine...

One spontaneous reboot later i'm not so sure ;)

Right now i captured a kernel oops in the raid code it seems...

(Also attached to avoid mangling)

[33411.934672] [ cut here ]
[33411.934685] kernel BUG at drivers/md/raid5.c:291!
[33411.934690] invalid opcode:  [#1] PREEMPT SMP 
[33411.934696] Modules linked in: bonding btrfs microcode
[33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83
[33411.934709] Hardware name: System manufacturer System Product Name/Crosshair 
IV Formula, BIOS 302910/09/2012
[33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
880320472000
[33411.934720] RIP: 0010:[]  [] 
do_release_stripe+0x18e/0x1a0
[33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
[33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 8800b0d816b0
[33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 880324eeec00
[33411.934743] RBP: 8802f0875a50 R08:  R09: 0001
[33411.934747] R10:  R11:  R12: 880324eeec00
[33411.934752] R13: 88032458 R14: 880320473e88 R15: 
[33411.934756] FS:  7fc38654d700() GS:880337d0() 
knlGS:
[33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
[33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 000407e0
[33411.934769] Stack:
[33411.934771]  8800bba09690 8800b4f16588 880303005a40 
0001
[33411.934779]  8800b33e43d0 81a3a62d 88032458 

[33411.934786]  88032458 880326660670 880326265880 
81a41692
[33411.934794] Call Trace:
[33411.934798]  [] ? release_stripe_list+0x4d/0x70
[33411.934803]  [] ? raid5d+0xa2/0x4d0
[33411.934808]  [] ? md_thread+0xe6/0x120
[33411.934814]  [] ? finish_wait+0x90/0x90
[33411.934818]  [] ? md_rdev_init+0x100/0x100
[33411.934823]  [] ? kthread+0xbc/0xe0
[33411.934828]  [] ? smpboot_park_threads+0x70/0x70
[33411.934833]  [] ? flush_kthread_worker+0x80/0x80
[33411.934839]  [] ? ret_from_fork+0x7c/0xb0
[33411.934843]  [] ? flush_kthread_worker+0x80/0x80
[33411.934847] Code: f7 ff ff 66 90 48 8b 43 18 48 8b b8 48 01 00 00 48 89 14 
24 48 89 74 24 08 e8 af 9a 02 00 48 8b 74 24 08 48 8b 14 24 eb 9f 0f 0b <0f> 0b 
0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 f0 ff 4e 
[33411.934912] RIP  [] do_release_stripe+0x18e/0x1a0
[33411.934918]  RSP 
[33411.941326] ---[ end trace 42d97d618cc5bfe2 ]---
[33411.941331] [ cut here ]
[33411.941337] WARNING: CPU: 4 PID: 2319 at kernel/exit.c:703 
do_exit+0x45/0xa40()
[33411.941351] Modules linked in: bonding btrfs microcode

[BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

Ok, so third try to actually email this... 
---

Hi,

I started testing 3.13-rc8 on another machine since the first one seemed
to be working fine...

One spontaneous reboot later i'm not so sure ;)

Right now i captured a kernel oops in the raid code it seems...

(Also attached to avoid mangling)

[33411.934672] [ cut here ]
[33411.934685] kernel BUG at drivers/md/raid5.c:291!
[33411.934690] invalid opcode:  [#1] PREEMPT SMP 
[33411.934696] Modules linked in: bonding btrfs microcode
[33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83
[33411.934709] Hardware name: System manufacturer System Product Name/Crosshair 
IV Formula, BIOS 302910/09/2012
[33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
880320472000
[33411.934720] RIP: 0010:[81a3a5be]  [81a3a5be] 
do_release_stripe+0x18e/0x1a0
[33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
[33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 8800b0d816b0
[33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 880324eeec00
[33411.934743] RBP: 8802f0875a50 R08:  R09: 0001
[33411.934747] R10:  R11:  R12: 880324eeec00
[33411.934752] R13: 88032458 R14: 880320473e88 R15: 
[33411.934756] FS:  7fc38654d700() GS:880337d0() 
knlGS:
[33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
[33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 000407e0
[33411.934769] Stack:
[33411.934771]  8800bba09690 8800b4f16588 880303005a40 
0001
[33411.934779]  8800b33e43d0 81a3a62d 88032458 

[33411.934786]  88032458 880326660670 880326265880 
81a41692
[33411.934794] Call Trace:
[33411.934798]  [81a3a62d] ? release_stripe_list+0x4d/0x70
[33411.934803]  [81a41692] ? raid5d+0xa2/0x4d0
[33411.934808]  [81a65ed6] ? md_thread+0xe6/0x120
[33411.934814]  [81122060] ? finish_wait+0x90/0x90
[33411.934818]  [81a65df0] ? md_rdev_init+0x100/0x100
[33411.934823]  [8110958c] ? kthread+0xbc/0xe0
[33411.934828]  [8111] ? smpboot_park_threads+0x70/0x70Hi,

I started testing 3.13-rc8 on another machine since the first one seemed to be 
working fine...

One spontaneous reboot later i'm not so sure ;)

Right now i captured a kernel oops in the raid code it seems...

(Also attached to avoid mangling)

[33411.934672] [ cut here ]
[33411.934685] kernel BUG at drivers/md/raid5.c:291!
[33411.934690] invalid opcode:  [#1] PREEMPT SMP 
[33411.934696] Modules linked in: bonding btrfs microcode
[33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83
[33411.934709] Hardware name: System manufacturer System Product Name/Crosshair 
IV Formula, BIOS 302910/09/2012
[33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
880320472000
[33411.934720] RIP: 0010:[81a3a5be]  [81a3a5be] 
do_release_stripe+0x18e/0x1a0
[33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
[33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 8800b0d816b0
[33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 880324eeec00
[33411.934743] RBP: 8802f0875a50 R08:  R09: 0001
[33411.934747] R10:  R11:  R12: 880324eeec00
[33411.934752] R13: 88032458 R14: 880320473e88 R15: 
[33411.934756] FS:  7fc38654d700() GS:880337d0() 
knlGS:
[33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
[33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 000407e0
[33411.934769] Stack:
[33411.934771]  8800bba09690 8800b4f16588 880303005a40 
0001
[33411.934779]  8800b33e43d0 81a3a62d 88032458 

[33411.934786]  88032458 880326660670 880326265880 
81a41692
[33411.934794] Call Trace:
[33411.934798]  [81a3a62d] ? release_stripe_list+0x4d/0x70
[33411.934803]  [81a41692] ? raid5d+0xa2/0x4d0
[33411.934808]  [81a65ed6] ? md_thread+0xe6/0x120
[33411.934814]  [81122060] ? finish_wait+0x90/0x90
[33411.934818]  [81a65df0] ? md_rdev_init+0x100/0x100
[33411.934823]  [8110958c] ? kthread+0xbc/0xe0
[33411.934828]  [8111] ? smpboot_park_threads+0x70/0x70
[33411.934833]  [811094d0] ? flush_kthread_worker+0x80/0x80
[33411.934839]  [81d5857c] ? ret_from_fork+0x7c/0xb0
[33411.934843]  [811094d0] ? flush_kthread_worker+0x80/0x80
[33411.934847] Code: f7 ff ff 66 90 48 8b 43 18 48 8b b8 48 01 00 00 48 89 14 
24 48 89 74 24 08 e8 af 9a 02 00 48 8b 74 24 08 48 8b 14 24 eb 9f 0f 0b 0f 0b 
0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 f0 

Re: [BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8

[Ian Kumlien]

On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
 On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien ian.kuml...@gmail.com wrote:
 
  Ok, so third try to actually email this... 
  ---
  
  Hi,
  
  I started testing 3.13-rc8 on another machine since the first one seemed
  to be working fine...
  
  One spontaneous reboot later i'm not so sure ;)
  
  Right now i captured a kernel oops in the raid code it seems...
  
  (Also attached to avoid mangling)
  
  [33411.934672] [ cut here ]
  [33411.934685] kernel BUG at drivers/md/raid5.c:291!
  [33411.934690] invalid opcode:  [#1] PREEMPT SMP 
  [33411.934696] Modules linked in: bonding btrfs microcode
  [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83
  [33411.934709] Hardware name: System manufacturer System Product 
  Name/Crosshair IV Formula, BIOS 302910/09/2012
  [33411.934716] task: 880326265880 ti: 880320472000 task.ti: 
  880320472000
  [33411.934720] RIP: 0010:[81a3a5be]  [81a3a5be] 
  do_release_stripe+0x18e/0x1a0
  [33411.934731] RSP: 0018:880320473d28  EFLAGS: 00010087
  [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 
  8800b0d816b0
  [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 
  880324eeec00
  [33411.934743] RBP: 8802f0875a50 R08:  R09: 
  0001
  [33411.934747] R10:  R11:  R12: 
  880324eeec00
  [33411.934752] R13: 88032458 R14: 880320473e88 R15: 
  
  [33411.934756] FS:  7fc38654d700() GS:880337d0() 
  knlGS:
  [33411.934761] CS:  0010 DS:  ES:  CR0: 8005003b
  [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 
  000407e0
  [33411.934769] Stack:
  [33411.934771]  8800bba09690 8800b4f16588 880303005a40 
  0001
  [33411.934779]  8800b33e43d0 81a3a62d 88032458 
  
  [33411.934786]  88032458 880326660670 880326265880 
  81a41692
  [33411.934794] Call Trace:
  [33411.934798]  [81a3a62d] ? release_stripe_list+0x4d/0x70
  [33411.934803]  [81a41692] ? raid5d+0xa2/0x4d0
  [33411.934808]  [81a65ed6] ? md_thread+0xe6/0x120
  [33411.934814]  [81122060] ? finish_wait+0x90/0x90
  [33411.934818]  [81a65df0] ? md_rdev_init+0x100/0x100
  [33411.934823]  [8110958c] ? kthread+0xbc/0xe0
  [33411.934828]  [8111] ? smpboot_park_threads+0x70/0x70Hi,
 
 Thanks for the report.
 Can you provide any more context about the details of the array in question?
 I see it was RAID6.  Was it degraded?  Was it resyncing?  Was it being
 reshaped?
 Was there any way that it was different from the array one the machine where
 it seemed to work?

Yes, it's a raid6 and no, there is no reshaping or syncing going on... 

Basically everything worked fine before:
reboot   system boot  3.13.0-rc8   Sun Jan 19 21:47 - 01:42  (03:55)
reboot   system boot  3.13.0-rc8   Sun Jan 19 21:38 - 01:42  (04:04)
reboot   system boot  3.13.0-rc8   Sun Jan 19 12:13 - 01:42  (13:29)
reboot   system boot  3.13.0-rc8   Sat Jan 18 21:23 - 01:42 (1+04:19)   
reboot   system boot  3.12.6   Mon Dec 30 16:27 - 22:21 (19+05:53)  

As in, no problems before the 3.13.0-rc8 upgrade...

cat /proc/mdstat:
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
[multipath] 
md2 : active raid6 sdf1[2] sdd1[9] sdj1[8] sdg1[4] sde1[5] sdi1[11] sdc1[0] 
sdh1[10]
  11721074304 blocks super 1.2 level 6, 64k chunk, algorithm 2 [8/8] 
[]
  bitmap: 0/15 pages [0KB], 65536KB chunk

What i do do is:
echo 32768  /sys/block/*/md/stripe_cache_size

Which has caused no problems during intense write operations before... 

I find it quite surprising since it only requires ~3 gigabytes of writes
to die and almost assume that it's related to the stripe_cache_size.
(Since all memory is ECC and i doubt it would break, quite literally,
over night i haven't run extensive memory tests)

I don't quite know what other information you might need...

 Thanks,
 NeilBrown


--
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: [OOPS][3.12] BUG: unable to handle kernel NULL pointer dereference at 0000000c

[Ian Kumlien]

On Fri, Nov 15, 2013 at 05:44:26PM -0500, David Miller wrote:
> From: Bjorn Helgaas 
> Date: Fri, 15 Nov 2013 15:29:53 -0700
> 
> > [+cc David, Eric, Alex, netdev]
> > 
> > Alex reported a similar issue at
> > http://marc.info/?l=linux-netdev=138355719901790=4
> 
> Fixed by:
> 
> commit 84502b5ef9849a9694673b15c31bd3ac693010ae
> Author: Steffen Klassert 
> Date:   Wed Oct 30 11:16:28 2013 +0100

Cherry-picked, compiled and preparing for reboot - thanks!

Shouldn't this be queued up in stable sometime soonish?

(Sorry for the change of email address, i had forgot to switch the
configurations in mutt)

--
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/

[OOPS][3.12] BUG: unable to handle kernel NULL pointer dereference at 0000000c

[Ian Kumlien]

Hi, 

After a lot of wondering i finally tracked down the bug that was hitting
me since 3.12-rc7. Since this is a firewall I haven't actually noticed
it all the time. But when i saw that it rebooted too often, i enabled
netconsole and this is the output:

BUG: unable to handle kernel NULL pointer dereference at 000c
IP: [] _decode_session6+0x8b/0x370
*pde = 
Oops:  [#1] SMP
Modules linked in: netconsole tun
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0 #55
Hardware name: MICRO-STAR INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 
05/16/2007
task: c1b64880 ti: f600a000 task.ti: c1b5a000
EIP: 0060:[] EFLAGS: 00210202 CPU: 0
EIP is at _decode_session6+0x8b/0x370
EAX:  EBX: f2c42c00 ECX: 0001 EDX: e351a0a2
ESI:  EDI: f600be70 EBP: f600be34 ESP: f600bdfc
 DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 8005003b CR2: 000c CR3: 235e8000 CR4: 07d0
Stack:
 f600be30 00282c00 0001 c1bb24e0 f63f8000 c1baa780 f2c42c00 c17d653f
 f2c42c00 c1807178 0001  e3791f00 e3791f00  
        
Call Trace:
 [] ? __xfrm_decode_session+0x1f/0x30
 [] ? icmpv6_route_lookup+0xa8/0x170
 [] ? icmp6_send+0x453/0x6e0
 [] ? ip_local_deliver_finish+0x7c/0x1f0
 [] ? ip_rcv_finish+0x310/0x310
 [] ? ip_rcv_finish+0x113/0x310
 [] ? icmpv6_route_lookup+0x170/0x170
 [] ? icmpv6_send+0x24/0x30
 [] ? ip6_expire_frag_queue+0x16f/0x180
 [] ? nf_ct_net_init+0x60/0x60
 [] ? call_timer_fn.isra.27+0x1c/0x80
 [] ? e1000e_poll+0x13b/0x2e0
 [] ? nf_ct_net_init+0x60/0x60
 [] ? run_timer_softirq+0x134/0x1d0
 [] ? __do_softirq+0xa5/0x160
 [] ? remote_softirq_cpu_notify+0xa0/0xa0
 
 [] ? irq_exit+0x66/0x90
 [] ? smp_apic_timer_interrupt+0x35/0x50
 [] ? apic_timer_interrupt+0x2d/0x34
 [] ? default_idle+0x2/0x10
 [] ? arch_cpu_idle+0x16/0x20
 [] ? cpu_startup_entry+0x49/0x130
 [] ? start_kernel+0x29e/0x2a3
 [] ? repair_env_string+0x4d/0x4d
Code: 00 00 f3 ab 74 08 66 c7 07 00 00 83 c7 02 83 e6 01 74 03 c6 07 00 8b 83 
90 00 00 00 8b 4c 24 08 89 45 08 8b 43 48 83 e0 fe 85 c9 <8b> 40 0c 8b 80 88 00 
00 00 89 45 00 0f 84 1b 01 00 00 8b 42 08
EIP: [] _decode_session6+0x8b/0x370 SS:ESP 0068:f600bdfc
CR2: 000c
---[ end trace 0cbf7fb6e6aa1f45 ]---
Kernel panic - not syncing: Fatal exception in interrupt
---

Any clue besides just disabling ipv6? ;)

--
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/

[OOPS][3.12] BUG: unable to handle kernel NULL pointer dereference at 0000000c

[Ian Kumlien]

Hi, 

After a lot of wondering i finally tracked down the bug that was hitting
me since 3.12-rc7. Since this is a firewall I haven't actually noticed
it all the time. But when i saw that it rebooted too often, i enabled
netconsole and this is the output:

BUG: unable to handle kernel NULL pointer dereference at 000c
IP: [c18196db] _decode_session6+0x8b/0x370
*pde = 
Oops:  [#1] SMP
Modules linked in: netconsole tun
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0 #55
Hardware name: MICRO-STAR INTERNATIONAL CO., LTD MS-9632/MS-9632, BIOS 6.00 PG 
05/16/2007
task: c1b64880 ti: f600a000 task.ti: c1b5a000
EIP: 0060:[c18196db] EFLAGS: 00210202 CPU: 0
EIP is at _decode_session6+0x8b/0x370
EAX:  EBX: f2c42c00 ECX: 0001 EDX: e351a0a2
ESI:  EDI: f600be70 EBP: f600be34 ESP: f600bdfc
 DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 8005003b CR2: 000c CR3: 235e8000 CR4: 07d0
Stack:
 f600be30 00282c00 0001 c1bb24e0 f63f8000 c1baa780 f2c42c00 c17d653f
 f2c42c00 c1807178 0001  e3791f00 e3791f00  
        
Call Trace:
 [c17d653f] ? __xfrm_decode_session+0x1f/0x30
 [c1807178] ? icmpv6_route_lookup+0xa8/0x170
 [c1807693] ? icmp6_send+0x453/0x6e0
 [c177dd7c] ? ip_local_deliver_finish+0x7c/0x1f0
 [c177dd00] ? ip_rcv_finish+0x310/0x310
 [c177db03] ? ip_rcv_finish+0x113/0x310
 [c1807240] ? icmpv6_route_lookup+0x170/0x170
 [c182dc64] ? icmpv6_send+0x24/0x30
 [c180df2f] ? ip6_expire_frag_queue+0x16f/0x180
 [c1823390] ? nf_ct_net_init+0x60/0x60
 [c1075efc] ? call_timer_fn.isra.27+0x1c/0x80
 [c155ff1b] ? e1000e_poll+0x13b/0x2e0
 [c1823390] ? nf_ct_net_init+0x60/0x60
 [c1076094] ? run_timer_softirq+0x134/0x1d0
 [c1071255] ? __do_softirq+0xa5/0x160
 [c10711b0] ? remote_softirq_cpu_notify+0xa0/0xa0
 IRQ
 [c1071416] ? irq_exit+0x66/0x90
 [c105dff5] ? smp_apic_timer_interrupt+0x35/0x50
 [c187196d] ? apic_timer_interrupt+0x2d/0x34
 [c103d8d2] ? default_idle+0x2/0x10
 [c103df26] ? arch_cpu_idle+0x16/0x20
 [c10a1ed9] ? cpu_startup_entry+0x49/0x130
 [c1bc4948] ? start_kernel+0x29e/0x2a3
 [c1bc44ef] ? repair_env_string+0x4d/0x4d
Code: 00 00 f3 ab 74 08 66 c7 07 00 00 83 c7 02 83 e6 01 74 03 c6 07 00 8b 83 
90 00 00 00 8b 4c 24 08 89 45 08 8b 43 48 83 e0 fe 85 c9 8b 40 0c 8b 80 88 00 
00 00 89 45 00 0f 84 1b 01 00 00 8b 42 08
EIP: [c18196db] _decode_session6+0x8b/0x370 SS:ESP 0068:f600bdfc
CR2: 000c
---[ end trace 0cbf7fb6e6aa1f45 ]---
Kernel panic - not syncing: Fatal exception in interrupt
---

Any clue besides just disabling ipv6? ;)

--
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: [OOPS][3.12] BUG: unable to handle kernel NULL pointer dereference at 0000000c

[Ian Kumlien]

On Fri, Nov 15, 2013 at 05:44:26PM -0500, David Miller wrote:
 From: Bjorn Helgaas bhelg...@google.com
 Date: Fri, 15 Nov 2013 15:29:53 -0700
 
  [+cc David, Eric, Alex, netdev]
  
  Alex reported a similar issue at
  http://marc.info/?l=linux-netdevm=138355719901790w=4
 
 Fixed by:
 
 commit 84502b5ef9849a9694673b15c31bd3ac693010ae
 Author: Steffen Klassert steffen.klass...@secunet.com
 Date:   Wed Oct 30 11:16:28 2013 +0100

Cherry-picked, compiled and preparing for reboot - thanks!

Shouldn't this be queued up in stable sometime soonish?

(Sorry for the change of email address, i had forgot to switch the
configurations in mutt)

--
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/

atl1c: networking bug - increasing counters with no data.

[Ian Kumlien]

Hi all, 

I have a atl1c networking card in my laptop - it's not connected since i
use wifi instead.

After a while of uptime it seems like it goes haywire, tools are
currently reporting data transfers of ~9GB/s

ifconfig eth0
eth0: flags=4099  mtu 1500
ether 48:5b:39:5e:b0:4b  txqueuelen 1000  (Ethernet)
RX packets 324218491164960  bytes 324218491164960 (294.8 TiB)
RX errors 1945310946989760  dropped 648436982329920  overruns 
324218491164960  frame 1621092455824800
TX packets 324218491164960  bytes 324218491164960 (294.8 TiB)
TX errors 1296878259627135  dropped 0 overruns 324218491164960  carrier 
648436982329920  collisions 1621092455824800

ethtool -i eth0
driver: atl1c
version: 1.0.1.0-NAPI
firmware-version: 
bus-info: :04:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

uptime
 19:45:20 up 1 day, 17:45,  8 users,  load average: 0.74, 1.79, 1.41

The only changes i have been able to spot was the __dev* cleanups... 

git log HEAD...v3.7.3 --format=oneline -- drivers/net/ethernet/atheros/atl1c/
1dd06ae8db716e17ec7e06244b858606edf378c0 drivers/net: fix up function 
prototypes after __dev* removals
093d369d4e8e8b6361317edd83935bdf8a0c83de net/atheros: remove __dev* attributes

And I'm currently running: v3.8-rc4-139-g1d85490

(It takes a while to recreate... )
--
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/

atl1c: networking bug - increasing counters with no data.

[Ian Kumlien]

Hi all, 

I have a atl1c networking card in my laptop - it's not connected since i
use wifi instead.

After a while of uptime it seems like it goes haywire, tools are
currently reporting data transfers of ~9GB/s

ifconfig eth0
eth0: flags=4099UP,BROADCAST,MULTICAST  mtu 1500
ether 48:5b:39:5e:b0:4b  txqueuelen 1000  (Ethernet)
RX packets 324218491164960  bytes 324218491164960 (294.8 TiB)
RX errors 1945310946989760  dropped 648436982329920  overruns 
324218491164960  frame 1621092455824800
TX packets 324218491164960  bytes 324218491164960 (294.8 TiB)
TX errors 1296878259627135  dropped 0 overruns 324218491164960  carrier 
648436982329920  collisions 1621092455824800

ethtool -i eth0
driver: atl1c
version: 1.0.1.0-NAPI
firmware-version: 
bus-info: :04:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

uptime
 19:45:20 up 1 day, 17:45,  8 users,  load average: 0.74, 1.79, 1.41

The only changes i have been able to spot was the __dev* cleanups... 

git log HEAD...v3.7.3 --format=oneline -- drivers/net/ethernet/atheros/atl1c/
1dd06ae8db716e17ec7e06244b858606edf378c0 drivers/net: fix up function 
prototypes after __dev* removals
093d369d4e8e8b6361317edd83935bdf8a0c83de net/atheros: remove __dev* attributes

And I'm currently running: v3.8-rc4-139-g1d85490

(It takes a while to recreate... )
--
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: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

On tor, 2012-11-29 at 20:25 +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
> > > Can you do:
> > > 
> > > make arch/x86/kernel/ptrace.lst
> > > 
> > > and send me that file, privately is fine too.
> > 
> > Done, =)
> 
> Ok, thanks. Here it is:
> 
> 8100b627:   83 3f 00cmpl   $0x0,(%rdi)
> 8100b62a:   75 24   jne8100b650 
> 
> 8100b62c:   eb 37   jmp8100b665 
> 
> 8100b62e:   65 48 8b 0c 25 00 00mov%gs:0x0,%rcx
> 8100b635:   00 00 
> 8100b633: R_X86_64_32S  current_task
> extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> extern void __audit_ptrace(struct task_struct *t);
> 
> static inline int audit_dummy_context(void)
> {
> void *p = current->audit_context;
> 8100b637:   48 8b 89 c0 04 00 00mov0x4c0(%rcx),%rcx
> regs->orig_ax,
> regs->bx, regs->cx,
> regs->dx, regs->si);
> #ifdef CONFIG_X86_64
> else
> audit_syscall_entry(AUDIT_ARCH_X86_64,
> 8100b63e:   4c 8b 4b 38 mov0x38(%rbx),%r9
> 8100b642:   48 8b 53 70 mov0x70(%rbx),%rdx
> return !p || *(int *)p;
> 8100b646:   48 85 c9test   %rcx,%rcx
> 8100b649:   74 05   je 8100b650 
> 
> 8100b64b:   83 39 00cmpl   $0x0,(%rcx)
> 8100b64e:   74 1f   je 8100b66f 
> 
> regs->di, regs->si,
> regs->dx, regs->r10);
> #endif
> 
> out:
> return ret ?: regs->orig_ax;
> 8100b650:   48 83 ca ff or 
> $0x,%rdx
> 8100b654:   48 85 edtest   %rbp,%rbp
> 8100b657:   75 04   jne8100b65d 
> 
> 8100b659:   48 8b 53 78 mov0x78(%rbx),%rdx
> }
> 8100b65d:   5b  pop%rbx
> 8100b65e:   5d  pop%rbp
> 8100b65f:   48 89 d0mov%rdx,%rax
> 8100b662:   41 5c   pop%r12
> 8100b664:   c3  retq
> 
> We're calling audit_syscall_entry() for a 64-bit task (chrome) and we
> check whether the audit context of the task is not a dummy one.
> 
> We fail at the second check in
> 
> return !p || *(int *)p;
> 
> when we're trying to deref the ->audit_context pointer of current and
> then check it for being 0 in audit_syscall_entry. It turns out it is
> some random crap, as we saw already: RCX=0063.

Yep, actually gathered that from the disassembly =)

> From looking at the code, task audit contexts get normally allocated
> at fork time and dealloc'd at task exit time so your process should
> actually have a valid task context.

Weird, and this should be allocated automatically?

> The only explanation I have is that it could be some random corruption
> which f*cked up the ->audit_context pointer but I might be wrong. Btw,
> do you have CONFIG_AUDITSYSCALL enabled in your kernel?

grep CONFIG_AUDITSYSCALL .config
CONFIG_AUDITSYSCALL=y

> I'd say right now we could watch this and if it is reproducible, then
> we can involve some more brain power and skills into it. If it has been
> only a single occurrence, then we'll write it on the random corruption's
> tab.

Uhmmm oki

> Thanks.
> 

-- 
Ian Kumlien  -- http://demius.net || http://pomac.netswarm.net


signature.asc
Description: This is a digitally signed message part

Re: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

On Thu, Nov 29, 2012 at 03:22:20PM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
> > I think that chrome does traceing all the time as a part of it's
> > sandbox - this is most likely chrome monitoring flash...
> 
> Ah, ok.

[ --8<--8<-- ]

> Right, so I can get the code now where it happens, but it is pretty
> unreliable to map it to what my compiler generates here (of course,
> different compilers and hardware):

Yeah i know... =)

> Code: 53 28 48 85 ff 74 29 83 3f 00 75 24 eb 37 65 48 8b 0c 25 80 b8 00 00 48 
> 8b 89 c0 04 00 00 4c 8b 4b 38 48 8b 53 70 48 85 c9 74 08 <83> 39 00 74 1f 48 
> 83 ca ff 48 85 ed 75 04 48 8b 53 78 5b 5d 48
> All code
> 
>0:   53  push   %rbx
>1:   28 48 85sub%cl,-0x7b(%rax)
>4:   ff 74 29 83 pushq  -0x7d(%rcx,%rbp,1)
>8:   3f  (bad)  
>9:   00 75 24add%dh,0x24(%rbp)
>c:   eb 37   jmp0x45
>e:   65 48 8b 0c 25 80 b8mov%gs:0xb880,%rcx
>   15:   00 00 
>   17:   48 8b 89 c0 04 00 00mov0x4c0(%rcx),%rcx
>   1e:   4c 8b 4b 38 mov0x38(%rbx),%r9
>   22:   48 8b 53 70 mov0x70(%rbx),%rdx
>   26:   48 85 c9test   %rcx,%rcx
>   29:   74 08   je 0x33
>   2b:*  83 39 00cmpl   $0x0,(%rcx) <-- trapping 
> instruction
>   2e:   74 1f   je 0x4f
>   30:   48 83 ca ff or $0x,%rdx
>   34:   48 85 edtest   %rbp,%rbp
>   37:   75 04   jne0x3d
>   39:   48 8b 53 78 mov0x78(%rbx),%rdx
>   3d:   5b  pop%rbx
>   3e:   5d  pop%rbp
>   3f:   48  rex.W
> 
> So we oops when we try to deref 0x63 which is, of course, not a valid
> pointer. The question is, what exactly is that thing in rcx. It looks
> like a percpu variable to me but I'm not sure.
>
> Can you do:
> 
> make arch/x86/kernel/ptrace.lst
> 
> and send me that file, privately is fine too.

Done, =)

> Thanks.
> 
> -- 
> Regards/Gruss,
> Boris.
--
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: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

On Thu, Nov 29, 2012 at 10:26:21AM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 12:20:02AM +0100, Ian Kumlien wrote:
> > Hi, 
> > 
> > Due to unexplained dns problems, I'll be using google plus to post the
> > photo of the bug output.
> > 
> > https://plus.google.com/photos/110698868656495230656/albums/5816005854482735041
> > 
> > I'm sorry but my knowledge is limited and current caffeine level is low,
> > so I'm offloading to someone who has these things handled ;)
> 
> Hmm, this looks strange, were you doing any system tracing or similar?

I think that chrome does traceing all the time as a part of it's sandbox
- this is most likely chrome monitoring flash... 

> How reproducible is this? If you can reliably reproduce it, can you
> make a much more readable screen photo of it so that one can read all
> register values and the "Code:" section in the backtrace is complete and
> also readable?

I can't say, it's the first kernel bug i have in quite a while - I guess
time will tell.

It seems like google plus worsened the image quality and i had another
picture to go by as well, so i peiced them together in to the following
information - Now if i just had the energy to disable the wraparound in
vim 

---

BUG: unable to handle kernel NULL pointer dereference at
0063
IP: [] syscall_trace_enter+0x15e/0x191
PGD 0
Oops:  [#1] PREEMPT SMP
Modules linked in: snd_usb_audio snd_usbmidi_lib nouveau mxm_wmi wmi
i2x_algo_bit ttm drm_kms_helper drm
CPU 0
Pid: 24590, comm: chrome Not tainted 3.7.0-rc7 #50 System manufacturer
System Product Name/A8N32-SLI-Deluxe
RIP: 0010:[] []
syscall_trace_enter+0x15e/0x191
RSP: 0018:8800058e3f38 EFLAGS: 00010206
RAX: 0081 RBX: 8800058e3f58 RCX: 0063
RDX: 7fe1f2fbde18 RSI: 00ca RDI: 7fe1f2fbde18
RBP:  R08: 0001 R09: 7fe23f9fcb10
R10: 7fe23f9fcb10 R11: 0206 R12: 0032
R13: 7fe23f9fd9c0 R14: 7fe25d743710 R15: 0007
FS:  7fe23f9fd700() GS:88013fc0()
knlGS:f5c88740
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0063 CR3: 83a84000 CR4: 07f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process chrome (pid: 24590, threadinfo 8800058e2000, task
88003dacd3b0)
Stack:
 7fe1f2fbde10 0001 0032 8160646c
 0007 7fe25d743710 7fe23f9fd9c0 0032
 0001 7fe1f2fbde10 0206 7fe23f9fcb10
Call Trace:
 [] ? tracesys+0x7e/0xe2
Code: 53 28 48 85 ff 74 29 83 3f 00 75 24 eb 37 65 48 8b 0c 25 80 b8 00
00 48 8b 89 c0 04 00 00 4c 8b 4b 38 48 8b 53 70 48 85 c9 74 08 <83> 39
00 74 1f 48 83 ca ff 48 85 ed 75 04 48 8b 53 78 5b 5d 48
RIP  [] syscall_trace_eneter+0x15e/0x191
 RSP 
CR2: 0063

---

> Thanks.
> 
> -- 
> Regards/Gruss,
> Boris.
--
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: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

On Thu, Nov 29, 2012 at 10:26:21AM +0100, Borislav Petkov wrote:
 On Thu, Nov 29, 2012 at 12:20:02AM +0100, Ian Kumlien wrote:
  Hi, 
  
  Due to unexplained dns problems, I'll be using google plus to post the
  photo of the bug output.
  
  https://plus.google.com/photos/110698868656495230656/albums/5816005854482735041
  
  I'm sorry but my knowledge is limited and current caffeine level is low,
  so I'm offloading to someone who has these things handled ;)
 
 Hmm, this looks strange, were you doing any system tracing or similar?

I think that chrome does traceing all the time as a part of it's sandbox
- this is most likely chrome monitoring flash... 

 How reproducible is this? If you can reliably reproduce it, can you
 make a much more readable screen photo of it so that one can read all
 register values and the Code: section in the backtrace is complete and
 also readable?

I can't say, it's the first kernel bug i have in quite a while - I guess
time will tell.

It seems like google plus worsened the image quality and i had another
picture to go by as well, so i peiced them together in to the following
information - Now if i just had the energy to disable the wraparound in
vim 

---

BUG: unable to handle kernel NULL pointer dereference at
0063
IP: [8100b64b] syscall_trace_enter+0x15e/0x191
PGD 0
Oops:  [#1] PREEMPT SMP
Modules linked in: snd_usb_audio snd_usbmidi_lib nouveau mxm_wmi wmi
i2x_algo_bit ttm drm_kms_helper drm
CPU 0
Pid: 24590, comm: chrome Not tainted 3.7.0-rc7 #50 System manufacturer
System Product Name/A8N32-SLI-Deluxe
RIP: 0010:[8100b64b] [8100b64b]
syscall_trace_enter+0x15e/0x191
RSP: 0018:8800058e3f38 EFLAGS: 00010206
RAX: 0081 RBX: 8800058e3f58 RCX: 0063
RDX: 7fe1f2fbde18 RSI: 00ca RDI: 7fe1f2fbde18
RBP:  R08: 0001 R09: 7fe23f9fcb10
R10: 7fe23f9fcb10 R11: 0206 R12: 0032
R13: 7fe23f9fd9c0 R14: 7fe25d743710 R15: 0007
FS:  7fe23f9fd700() GS:88013fc0()
knlGS:f5c88740
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0063 CR3: 83a84000 CR4: 07f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process chrome (pid: 24590, threadinfo 8800058e2000, task
88003dacd3b0)
Stack:
 7fe1f2fbde10 0001 0032 8160646c
 0007 7fe25d743710 7fe23f9fd9c0 0032
 0001 7fe1f2fbde10 0206 7fe23f9fcb10
Call Trace:
 [8160646c] ? tracesys+0x7e/0xe2
Code: 53 28 48 85 ff 74 29 83 3f 00 75 24 eb 37 65 48 8b 0c 25 80 b8 00
00 48 8b 89 c0 04 00 00 4c 8b 4b 38 48 8b 53 70 48 85 c9 74 08 83 39
00 74 1f 48 83 ca ff 48 85 ed 75 04 48 8b 53 78 5b 5d 48
RIP  [8100b64b] syscall_trace_eneter+0x15e/0x191
 RSP 8800058e3f38
CR2: 0063

---

 Thanks.
 
 -- 
 Regards/Gruss,
 Boris.
--
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: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

On Thu, Nov 29, 2012 at 03:22:20PM +0100, Borislav Petkov wrote:
 On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
  I think that chrome does traceing all the time as a part of it's
  sandbox - this is most likely chrome monitoring flash...
 
 Ah, ok.

[ --8--8-- ]

 Right, so I can get the code now where it happens, but it is pretty
 unreliable to map it to what my compiler generates here (of course,
 different compilers and hardware):

Yeah i know... =)

 Code: 53 28 48 85 ff 74 29 83 3f 00 75 24 eb 37 65 48 8b 0c 25 80 b8 00 00 48 
 8b 89 c0 04 00 00 4c 8b 4b 38 48 8b 53 70 48 85 c9 74 08 83 39 00 74 1f 48 
 83 ca ff 48 85 ed 75 04 48 8b 53 78 5b 5d 48
 All code
 
0:   53  push   %rbx
1:   28 48 85sub%cl,-0x7b(%rax)
4:   ff 74 29 83 pushq  -0x7d(%rcx,%rbp,1)
8:   3f  (bad)  
9:   00 75 24add%dh,0x24(%rbp)
c:   eb 37   jmp0x45
e:   65 48 8b 0c 25 80 b8mov%gs:0xb880,%rcx
   15:   00 00 
   17:   48 8b 89 c0 04 00 00mov0x4c0(%rcx),%rcx
   1e:   4c 8b 4b 38 mov0x38(%rbx),%r9
   22:   48 8b 53 70 mov0x70(%rbx),%rdx
   26:   48 85 c9test   %rcx,%rcx
   29:   74 08   je 0x33
   2b:*  83 39 00cmpl   $0x0,(%rcx) -- trapping 
 instruction
   2e:   74 1f   je 0x4f
   30:   48 83 ca ff or $0x,%rdx
   34:   48 85 edtest   %rbp,%rbp
   37:   75 04   jne0x3d
   39:   48 8b 53 78 mov0x78(%rbx),%rdx
   3d:   5b  pop%rbx
   3e:   5d  pop%rbp
   3f:   48  rex.W
 
 So we oops when we try to deref 0x63 which is, of course, not a valid
 pointer. The question is, what exactly is that thing in rcx. It looks
 like a percpu variable to me but I'm not sure.

 Can you do:
 
 make arch/x86/kernel/ptrace.lst
 
 and send me that file, privately is fine too.

Done, =)

 Thanks.
 
 -- 
 Regards/Gruss,
 Boris.
--
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: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

On tor, 2012-11-29 at 20:25 +0100, Borislav Petkov wrote:
 On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
   Can you do:
   
   make arch/x86/kernel/ptrace.lst
   
   and send me that file, privately is fine too.
  
  Done, =)
 
 Ok, thanks. Here it is:
 
 8100b627:   83 3f 00cmpl   $0x0,(%rdi)
 8100b62a:   75 24   jne8100b650 
 syscall_trace_enter+0x163
 8100b62c:   eb 37   jmp8100b665 
 syscall_trace_enter+0x178
 8100b62e:   65 48 8b 0c 25 00 00mov%gs:0x0,%rcx
 8100b635:   00 00 
 8100b633: R_X86_64_32S  current_task
 extern void __audit_seccomp(unsigned long syscall, long signr, int code);
 extern void __audit_ptrace(struct task_struct *t);
 
 static inline int audit_dummy_context(void)
 {
 void *p = current-audit_context;
 8100b637:   48 8b 89 c0 04 00 00mov0x4c0(%rcx),%rcx
 regs-orig_ax,
 regs-bx, regs-cx,
 regs-dx, regs-si);
 #ifdef CONFIG_X86_64
 else
 audit_syscall_entry(AUDIT_ARCH_X86_64,
 8100b63e:   4c 8b 4b 38 mov0x38(%rbx),%r9
 8100b642:   48 8b 53 70 mov0x70(%rbx),%rdx
 return !p || *(int *)p;
 8100b646:   48 85 c9test   %rcx,%rcx
 8100b649:   74 05   je 8100b650 
 syscall_trace_enter+0x163
 8100b64b:   83 39 00cmpl   $0x0,(%rcx)
 8100b64e:   74 1f   je 8100b66f 
 syscall_trace_enter+0x182
 regs-di, regs-si,
 regs-dx, regs-r10);
 #endif
 
 out:
 return ret ?: regs-orig_ax;
 8100b650:   48 83 ca ff or 
 $0x,%rdx
 8100b654:   48 85 edtest   %rbp,%rbp
 8100b657:   75 04   jne8100b65d 
 syscall_trace_enter+0x170
 8100b659:   48 8b 53 78 mov0x78(%rbx),%rdx
 }
 8100b65d:   5b  pop%rbx
 8100b65e:   5d  pop%rbp
 8100b65f:   48 89 d0mov%rdx,%rax
 8100b662:   41 5c   pop%r12
 8100b664:   c3  retq
 
 We're calling audit_syscall_entry() for a 64-bit task (chrome) and we
 check whether the audit context of the task is not a dummy one.
 
 We fail at the second check in
 
 return !p || *(int *)p;
 
 when we're trying to deref the -audit_context pointer of current and
 then check it for being 0 in audit_syscall_entry. It turns out it is
 some random crap, as we saw already: RCX=0063.

Yep, actually gathered that from the disassembly =)

 From looking at the code, task audit contexts get normally allocated
 at fork time and dealloc'd at task exit time so your process should
 actually have a valid task context.

Weird, and this should be allocated automatically?

 The only explanation I have is that it could be some random corruption
 which f*cked up the -audit_context pointer but I might be wrong. Btw,
 do you have CONFIG_AUDITSYSCALL enabled in your kernel?

grep CONFIG_AUDITSYSCALL .config
CONFIG_AUDITSYSCALL=y

 I'd say right now we could watch this and if it is reproducible, then
 we can involve some more brain power and skills into it. If it has been
 only a single occurrence, then we'll write it on the random corruption's
 tab.

Uhmmm oki

 Thanks.
 

-- 
Ian Kumlien  -- http://demius.net || http://pomac.netswarm.net


signature.asc
Description: This is a digitally signed message part

[BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

Hi, 

Due to unexplained dns problems, I'll be using google plus to post the
photo of the bug output.

https://plus.google.com/photos/110698868656495230656/albums/5816005854482735041

I'm sorry but my knowledge is limited and current caffeine level is low,
so I'm offloading to someone who has these things handled ;)

-- 
Ian Kumlien  -- http://demius.net || http://pomac.netswarm.net


signature.asc
Description: This is a digitally signed message part

[BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

[Ian Kumlien]

Hi, 

Due to unexplained dns problems, I'll be using google plus to post the
photo of the bug output.

https://plus.google.com/photos/110698868656495230656/albums/5816005854482735041

I'm sorry but my knowledge is limited and current caffeine level is low,
so I'm offloading to someone who has these things handled ;)

-- 
Ian Kumlien  -- http://demius.net || http://pomac.netswarm.net


signature.asc
Description: This is a digitally signed message part

[SKY2] Problems (2.6.24-rc3-git1)

[Ian Kumlien]

From lkml:
On Tue, 27 Nov 2007 23:40:22 +0100
Ian Kumlien <[EMAIL PROTECTED]> wrote:

> [Repost, no reply has been recived]
> 
> Hi,
> 
> A little while ago, something went horribly wrong.
> 
> I could still use my mouse and the desktop was still alive more or
> less... everything using networking was dead AND the keyboard was
> dead... So i composed commands using existing text on the screen.
> 
> The device:
> sky2 :02:00.0: v1.20 addr 0xdbffc000 irq 17 Yukon-EC (0xb6) rev 2
> sky2 :02:00.0: PCI Express Advanced Error Reporting not configured or 
> MMCONFIG problem?
> sky2 :02:00.0: No interrupt generated using MSI, switching to INTx mode.
> sky2 eth0: addr 00:15:f2:aa:8b:3e

The recovery logic for hung FIFO no longer works in 2.6.24-rc1+, I'm looking
into it.
---

Ahh, ok thanks, i dunno if your reply is caught in greylisting... 
Else please CC always =)
(did you get the email on netdev as well? in that case, i'm very sorry
for reposting... I only follow linux-kernel on a regular basis)

When you have something ready for testing, mail me a patch =)

-- 
Ian Kumlien  -- http://pomac.netswarm.net


signature.asc
Description: This is a digitally signed message part