[PATCH] builddeb: Consolidate consecutive chmod calls into one

[Sven Joachim]

No need to call chmod three times when it can do everything at once.

Signed-off-by: Sven Joachim 
---
 scripts/package/builddeb | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 91a502bb97e8..6a100c449579 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -42,11 +42,9 @@ create_package() {
else
chown -R root:root "$pdir"
fi
-   chmod -R go-w "$pdir"
-   # in case we are in a restrictive umask environment like 0077
-   chmod -R a+rX "$pdir"
-   # in case we build in a setuid/setgid directory
-   chmod -R ug-s "$pdir"
+   # a+rX in case we are in a restrictive umask environment like 0077
+   # ug-s in case we build in a setuid/setgid directory
+   chmod -R go-w,a+rX,ug-s "$pdir"

# Create the package
dpkg-gencontrol -p$pname -P"$pdir"
--
2.29.1

Re: [PATCH 1/2] builddeb: Fix rootless build in setuid/setgid directory

[Sven Joachim]

On 2020-10-28 15:00 +0900, Masahiro Yamada wrote:

> On Tue, Oct 27, 2020 at 4:32 AM Sven Joachim  wrote:
>>
>> Building 5.10-rc1 in a setgid directory failed with the following
>> error:
>>
>> dpkg-deb: error: control directory has bad permissions 2755 (must be
>> >=0755 and <=0775)
>>
>> When building with fakeroot, the earlier chown call would have removed
>> the setgid bits, but in a rootless build they remain.
>>
>
>
> Applied to linux-kbuild. Thanks.

I don't see it there, have you pushed it out yet?

> I agreed with "g-s" but was not sure about "u-s"
> because nothing is explained about setuid,
> and the setuid bit against directories seems to have no effect.
>
>
>
>
>
> It was interesting to read this article:
> https://superuser.com/questions/471844/why-is-setuid-ignored-on-directories
>
>
>
> Also, it is summarized in the wikipedia
> https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
>
> "The setuid permission set on a directory is ignored on most UNIX and
> Linux systems.[citation needed] However FreeBSD can be configured to
> interpret setuid in a manner similar to setgid, in which case it
> forces all files and sub-directories created in a directory to be
> owned by that directory's owner - a simple form of inheritance.[5]
> This is generally not needed on most systems derived from BSD, since
> by default directories are treated as if their setgid bit is always
> set, regardless of the actual value. As is stated in open(2), "When a
> new file is created it is given the group of the directory which
> contains it.""
>
>
> After all, I am convinced that it would not hurt to do "u-s"
> although I have never tested kernel builds on FreeBSD.

Agreed, setuid directories should not end up in the .deb files even if
that bit does currently nothing.

Cheers,
   Sven

[PATCH 2/2] builddeb: Consolidate consecutive chmod calls into one

[Sven Joachim]

No need to call chmod three times when it can do everything at once.

Signed-off-by: Sven Joachim 
---
 scripts/package/builddeb | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 91a502bb97e8..81ec6414726c 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -42,11 +42,7 @@ create_package() {
else
chown -R root:root "$pdir"
fi
-   chmod -R go-w "$pdir"
-   # in case we are in a restrictive umask environment like 0077
-   chmod -R a+rX "$pdir"
-   # in case we build in a setuid/setgid directory
-   chmod -R ug-s "$pdir"
+   chmod -R go-w,a+rX,ug-s "$pdir"

# Create the package
dpkg-gencontrol -p$pname -P"$pdir"
--
2.28.0

[PATCH 1/2] builddeb: Fix rootless build in setuid/setgid directory

[Sven Joachim]

Building 5.10-rc1 in a setgid directory failed with the following
error:

dpkg-deb: error: control directory has bad permissions 2755 (must be
>=0755 and <=0775)

When building with fakeroot, the earlier chown call would have removed
the setgid bits, but in a rootless build they remain.

Fixes: 3e8541803624 ("builddeb: Enable rootless builds")
Cc: Guillem Jover 
Signed-off-by: Sven Joachim 
---
 scripts/package/builddeb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 1b11f8993629..91a502bb97e8 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -45,6 +45,8 @@ create_package() {
chmod -R go-w "$pdir"
# in case we are in a restrictive umask environment like 0077
chmod -R a+rX "$pdir"
+   # in case we build in a setuid/setgid directory
+   chmod -R ug-s "$pdir"

# Create the package
dpkg-gencontrol -p$pname -P"$pdir"
--
2.28.0

Re: [RFC][PATCH 4/4] acpi: Take over RCU-idle for C3-BM idle

[Sven Joachim]

On 2020-09-15 12:32 +0200, Peter Zijlstra wrote:

> The C3 BusMaster idle code takes lock in a number of places, some deep
> inside the ACPI code. Instead of wrapping it all in RCU_NONIDLE, have
> the driver take over RCU-idle duty and avoid flipping RCU state back
> and forth a lot.
>
> ( by marking 'C3 && bm_check' as RCU_IDLE, we _must_ call enter_bm() for
>   that combination, otherwise we'll loose RCU-idle, this requires
>   shuffling some code around )
>
> Signed-off-by: Peter Zijlstra (Intel) 

I got modpost errors in 5.9-rc6 after this patch:

ERROR: modpost: "rcu_idle_enter" [drivers/acpi/processor.ko] undefined!
ERROR: modpost: "rcu_idle_exit" [drivers/acpi/processor.ko] undefined!

Reverting commit 1fecfdbb7acc made them go away.  Notably my
configuration had CONFIG_ACPI_PROCESSOR=m,  changing that
to CONFIG_ACPI_PROCESSOR=y let the build succeed as well.

Cheers,
   Sven

> ---
>  drivers/acpi/processor_idle.c |   69 
> +-
>  1 file changed, 49 insertions(+), 20 deletions(-)
>
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -558,22 +558,43 @@ static DEFINE_RAW_SPINLOCK(c3_lock);
>
>  /**
>   * acpi_idle_enter_bm - enters C3 with proper BM handling
> + * @drv: cpuidle driver
>   * @pr: Target processor
>   * @cx: Target state context
> + * @index: index of target state
>   */
> -static void acpi_idle_enter_bm(struct acpi_processor *pr,
> -struct acpi_processor_cx *cx)
> +static int acpi_idle_enter_bm(struct cpuidle_driver *drv,
> +struct acpi_processor *pr,
> +struct acpi_processor_cx *cx,
> +int index)
>  {
> + static struct acpi_processor_cx safe_cx = {
> + .entry_method = ACPI_CSTATE_HALT,
> + };
> +
>   /*
>* disable bus master
>* bm_check implies we need ARB_DIS
>* bm_control implies whether we can do ARB_DIS
>*
> -  * That leaves a case where bm_check is set and bm_control is
> -  * not set. In that case we cannot do much, we enter C3
> -  * without doing anything.
> +  * That leaves a case where bm_check is set and bm_control is not set.
> +  * In that case we cannot do much, we enter C3 without doing anything.
>*/
> - if (pr->flags.bm_control) {
> + bool dis_bm = pr->flags.bm_control;
> +
> + /* If we can skip BM, demote to a safe state. */
> + if (!cx->bm_sts_skip && acpi_idle_bm_check()) {
> + dis_bm = false;
> + index = drv->safe_state_index;
> + if (index >= 0) {
> + cx = this_cpu_read(acpi_cstate[index]);
> + } else {
> + cx = _cx;
> + index = -EBUSY;
> + }
> + }
> +
> + if (dis_bm) {
>   raw_spin_lock(_lock);
>   c3_cpu_count++;
>   /* Disable bus master arbitration when all CPUs are in C3 */
> @@ -582,15 +603,21 @@ static void acpi_idle_enter_bm(struct ac
>   raw_spin_unlock(_lock);
>   }
>
> + rcu_idle_enter();
> +
>   acpi_idle_do_entry(cx);
>
> + rcu_idle_exit();
> +
>   /* Re-enable bus master arbitration */
> - if (pr->flags.bm_control) {
> + if (dis_bm) {
>   raw_spin_lock(_lock);
>   acpi_write_bit_register(ACPI_BITREG_ARB_DISABLE, 0);
>   c3_cpu_count--;
>   raw_spin_unlock(_lock);
>   }
> +
> + return index;
>  }
>
>  static int acpi_idle_enter(struct cpuidle_device *dev,
> @@ -604,20 +631,13 @@ static int acpi_idle_enter(struct cpuidl
>   return -EINVAL;
>
>   if (cx->type != ACPI_STATE_C1) {
> + if (cx->type == ACPI_STATE_C3 && pr->flags.bm_check)
> + return acpi_idle_enter_bm(drv, pr, cx, index);
> +
> + /* C2 to C1 demotion. */
>   if (acpi_idle_fallback_to_c1(pr) && num_online_cpus() > 1) {
>   index = ACPI_IDLE_STATE_START;
>   cx = per_cpu(acpi_cstate[index], dev->cpu);
> - } else if (cx->type == ACPI_STATE_C3 && pr->flags.bm_check) {
> - if (cx->bm_sts_skip || !acpi_idle_bm_check()) {
> - acpi_idle_enter_bm(pr, cx);
> - return index;
> - } else if (drv->safe_state_index >= 0) {
> - index = drv->safe_state_index;
> - cx = per_cpu(acpi_cstate[index], dev->cpu);
> - } else {
> - acpi_safe_halt();
> - return -EBUSY;
> - }
>   }
>   }
>
> @@ -641,7 +661,13 @@ static int acpi_idle_enter_s2idle(struct
>   return 0;
>
>   if (pr->flags.bm_check) {
> - acpi_idle_enter_bm(pr, cx);
> +

Re: linux-next: build failure after merge of the net-next tree

[Sven Joachim]

On 2020-08-28 16:42 -0700, Randy Dunlap wrote:

> On 8/28/20 4:16 PM, Brian Vazquez wrote:
>> On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap  wrote:
>>>
>>> On 8/28/20 8:09 AM, Sven Joachim wrote:
>>>> On 2020-08-27 11:12 -0700, Brian Vazquez wrote:
>>>>
>>>>> I've been trying to reproduce it with your config but I didn't
>>>>> succeed. I also looked at the file after the preprocessor and it
>>>>> looked good:
>>>>>
>>>>> ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ?
>>>>> fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); })
>>>>
>>>> However, in my configuration I have CONFIG_IPV6=m, and so
>>>> fib6_rule_match is not available as a builtin.  I think that's why ld is
>>>> complaining about the undefined reference.
>>>
>>> Same here FWIW. CONFIG_IPV6=m.
>>
>> Oh I see,
>> I tried this and it seems to work fine for me, does this also fix your
>> problem? if so, I'll prepare the patch, and thanks for helping!
>> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
>> index 51678a528f85..40dfd1f55899 100644
>> --- a/net/core/fib_rules.c
>> +++ b/net/core/fib_rules.c
>> @@ -16,7 +16,7 @@
>>  #include 
>>  #include 
>>
>> -#ifdef CONFIG_IPV6_MULTIPLE_TABLES
>> +#if defined(CONFIG_IPV6_MULTIPLE_TABLES) && defined(CONFIG_IPV6)
>
>
> Yes, that works for me.
> You can add this to your patch:
>
> Acked-by: Randy Dunlap  # build-tested

Works for me as well.

Cheers,
   Sven

Re: linux-next: build failure after merge of the net-next tree

[Sven Joachim]

On 2020-08-27 11:12 -0700, Brian Vazquez wrote:

> I've been trying to reproduce it with your config but I didn't
> succeed. I also looked at the file after the preprocessor and it
> looked good:
>
> ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ?
> fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); })

However, in my configuration I have CONFIG_IPV6=m, and so
fib6_rule_match is not available as a builtin.  I think that's why ld is
complaining about the undefined reference.

Changing the configuration to CONFIG_IPV6=y helps, FWIW.

> Note that fib4_rule_match doesn't appear as the
> CONFIG_IP_MULTIPLE_TABLES is not there.
>
> Could you share more details on how you're compiling it and what
> compiler you're using??

Tried with both gcc 9 and gcc 10 under Debian unstable, binutils 2.35.
I usually use "make bindebpkg", but just running "make" is sufficient to
reproduce the problem, as it happens when linking vmlinux.

Cheers,
   Sven


> On Mon, Aug 24, 2020 at 1:08 AM Sven Joachim  wrote:
>>
>> On 2020-08-22 08:16 +0200, Sven Joachim wrote:
>>
>> > On 2020-08-21 09:23 -0700, Brian Vazquez wrote:
>> >
>> >> Hi Sven,
>> >>
>> >> Sorry for the late reply, did you still see this after:
>> >> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaib...@huawei.com/
>> >> ??
>> >
>> > That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so
>> > yes I'm still seeing it.
>>
>> Still present in 5.9-rc2 as of today, I have attached my .config for
>> reference.  Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but
>> CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there.
>>
>> To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES.  Not
>> sure why this was enabled in my .config which has grown organically over
>> many years.
>>
>> Cheers,
>>Sven
>>
>>
>> >> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim  wrote:
>> >>
>> >>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote:
>> >>>
>> >>> > Hi all,
>> >>> >
>> >>> > After merging the net-next tree, today's linux-next build (i386
>> >>> defconfig)
>> >>> > failed like this:
>> >>> >
>> >>> > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function
>> >>> `fib_rules_lookup':
>> >>> > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
>> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to
>> >>> `fib6_rule_match'
>> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to
>> >>> `fib6_rule_action'
>> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to
>> >>> `fib6_rule_action'
>> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to
>> >>> `fib6_rule_suppress'
>> >>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to
>> >>> `fib6_rule_suppress'
>> >>>
>> >>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit
>> >>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was
>> >>> apparently not sufficient.
>> >>>
>> >>> ,
>> >>> | $ grep IPV6 .config
>> >>> | CONFIG_IPV6=m
>> >>> | # CONFIG_IPV6_ROUTER_PREF is not set
>> >>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set
>> >>> | # CONFIG_IPV6_MIP6 is not set
>> >>> | # CONFIG_IPV6_ILA is not set
>> >>> | # CONFIG_IPV6_VTI is not set
>> >>> | CONFIG_IPV6_SIT=m
>> >>> | # CONFIG_IPV6_SIT_6RD is not set
>> >>> | CONFIG_IPV6_NDISC_NODETYPE=y
>> >>> | CONFIG_IPV6_TUNNEL=m
>> >>> | CONFIG_IPV6_MULTIPLE_TABLES=y
>> >>> | # CONFIG_IPV6_SUBTREES is not set
>> >>> | # CONFIG_IPV6_MROUTE is not set
>> >>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set
>> >>> | # CONFIG_IPV6_SEG6_HMAC is not set
>> >>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set
>> >>> | # CONFIG_NF_SOCKET_IPV6 is not set
>> >>> | # CONFIG_NF_TPROXY_IPV6 is not set
>> >>> | # CONFIG_NF_DUP_IPV6 is not set
>> >>> | # CONFIG_NF_REJECT_IPV6 is not set
>> >>> | # CONFIG_NF_LOG_IPV6 is not set
>> >>> | CONFIG_NF_DEFRAG_IPV6=m
>> >>> `
>> >>>
>> >>> > Caused by commit
>> >>> >
>> >>> >   b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
>> >>> fib_rules_ops")
>> >>> >
>> >>> > # CONFIG_IPV6_MULTIPLE_TABLES is not set
>> >>> >
>> >>> > I have reverted that commit for today.
>> >>>
>> >>> Cheers,
>> >>>Sven
>> >>>

Re: linux-next: build failure after merge of the net-next tree

[Sven Joachim]

On 2020-08-22 08:16 +0200, Sven Joachim wrote:

> On 2020-08-21 09:23 -0700, Brian Vazquez wrote:
>
>> Hi Sven,
>>
>> Sorry for the late reply, did you still see this after:
>> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaib...@huawei.com/
>> ??
>
> That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so
> yes I'm still seeing it.

Still present in 5.9-rc2 as of today, I have attached my .config for
reference.  Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but
CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there.

To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES.  Not
sure why this was enabled in my .config which has grown organically over
many years.

Cheers,
   Sven



.config.xz
Description: application/xz

>> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim  wrote:
>>
>>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote:
>>>
>>> > Hi all,
>>> >
>>> > After merging the net-next tree, today's linux-next build (i386
>>> defconfig)
>>> > failed like this:
>>> >
>>> > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function
>>> `fib_rules_lookup':
>>> > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
>>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to
>>> `fib6_rule_match'
>>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to
>>> `fib6_rule_action'
>>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to
>>> `fib6_rule_action'
>>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to
>>> `fib6_rule_suppress'
>>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to
>>> `fib6_rule_suppress'
>>>
>>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit
>>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was
>>> apparently not sufficient.
>>>
>>> ,
>>> | $ grep IPV6 .config
>>> | CONFIG_IPV6=m
>>> | # CONFIG_IPV6_ROUTER_PREF is not set
>>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set
>>> | # CONFIG_IPV6_MIP6 is not set
>>> | # CONFIG_IPV6_ILA is not set
>>> | # CONFIG_IPV6_VTI is not set
>>> | CONFIG_IPV6_SIT=m
>>> | # CONFIG_IPV6_SIT_6RD is not set
>>> | CONFIG_IPV6_NDISC_NODETYPE=y
>>> | CONFIG_IPV6_TUNNEL=m
>>> | CONFIG_IPV6_MULTIPLE_TABLES=y
>>> | # CONFIG_IPV6_SUBTREES is not set
>>> | # CONFIG_IPV6_MROUTE is not set
>>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set
>>> | # CONFIG_IPV6_SEG6_HMAC is not set
>>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set
>>> | # CONFIG_NF_SOCKET_IPV6 is not set
>>> | # CONFIG_NF_TPROXY_IPV6 is not set
>>> | # CONFIG_NF_DUP_IPV6 is not set
>>> | # CONFIG_NF_REJECT_IPV6 is not set
>>> | # CONFIG_NF_LOG_IPV6 is not set
>>> | CONFIG_NF_DEFRAG_IPV6=m
>>> `
>>>
>>> > Caused by commit
>>> >
>>> >   b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
>>> fib_rules_ops")
>>> >
>>> > # CONFIG_IPV6_MULTIPLE_TABLES is not set
>>> >
>>> > I have reverted that commit for today.
>>>
>>> Cheers,
>>>Sven
>>>

Re: linux-next: build failure after merge of the net-next tree

[Sven Joachim]

On 2020-08-21 09:23 -0700, Brian Vazquez wrote:

> Hi Sven,
>
> Sorry for the late reply, did you still see this after:
> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaib...@huawei.com/
> ??

That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so
yes I'm still seeing it.

Cheers,
   Sven

> On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim  wrote:
>
>> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote:
>>
>> > Hi all,
>> >
>> > After merging the net-next tree, today's linux-next build (i386
>> defconfig)
>> > failed like this:
>> >
>> > x86_64-linux-gnu-ld: net/core/fib_rules.o: in function
>> `fib_rules_lookup':
>> > fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to
>> `fib6_rule_match'
>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to
>> `fib6_rule_action'
>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to
>> `fib6_rule_action'
>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to
>> `fib6_rule_suppress'
>> > x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to
>> `fib6_rule_suppress'
>>
>> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit
>> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was
>> apparently not sufficient.
>>
>> ,
>> | $ grep IPV6 .config
>> | CONFIG_IPV6=m
>> | # CONFIG_IPV6_ROUTER_PREF is not set
>> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set
>> | # CONFIG_IPV6_MIP6 is not set
>> | # CONFIG_IPV6_ILA is not set
>> | # CONFIG_IPV6_VTI is not set
>> | CONFIG_IPV6_SIT=m
>> | # CONFIG_IPV6_SIT_6RD is not set
>> | CONFIG_IPV6_NDISC_NODETYPE=y
>> | CONFIG_IPV6_TUNNEL=m
>> | CONFIG_IPV6_MULTIPLE_TABLES=y
>> | # CONFIG_IPV6_SUBTREES is not set
>> | # CONFIG_IPV6_MROUTE is not set
>> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set
>> | # CONFIG_IPV6_SEG6_HMAC is not set
>> | # CONFIG_IPV6_RPL_LWTUNNEL is not set
>> | # CONFIG_NF_SOCKET_IPV6 is not set
>> | # CONFIG_NF_TPROXY_IPV6 is not set
>> | # CONFIG_NF_DUP_IPV6 is not set
>> | # CONFIG_NF_REJECT_IPV6 is not set
>> | # CONFIG_NF_LOG_IPV6 is not set
>> | CONFIG_NF_DEFRAG_IPV6=m
>> `
>>
>> > Caused by commit
>> >
>> >   b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
>> fib_rules_ops")
>> >
>> > # CONFIG_IPV6_MULTIPLE_TABLES is not set
>> >
>> > I have reverted that commit for today.
>>
>> Cheers,
>>Sven
>>

Re: linux-next: build failure after merge of the net-next tree

[Sven Joachim]

On 2020-07-29 21:27 +1000, Stephen Rothwell wrote:

> Hi all,
>
> After merging the net-next tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> x86_64-linux-gnu-ld: net/core/fib_rules.o: in function `fib_rules_lookup':
> fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to 
> `fib6_rule_match'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to 
> `fib6_rule_action'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to 
> `fib6_rule_action'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to 
> `fib6_rule_suppress'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to 
> `fib6_rule_suppress'

FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit
41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was
apparently not sufficient.

,
| $ grep IPV6 .config
| CONFIG_IPV6=m
| # CONFIG_IPV6_ROUTER_PREF is not set
| # CONFIG_IPV6_OPTIMISTIC_DAD is not set
| # CONFIG_IPV6_MIP6 is not set
| # CONFIG_IPV6_ILA is not set
| # CONFIG_IPV6_VTI is not set
| CONFIG_IPV6_SIT=m
| # CONFIG_IPV6_SIT_6RD is not set
| CONFIG_IPV6_NDISC_NODETYPE=y
| CONFIG_IPV6_TUNNEL=m
| CONFIG_IPV6_MULTIPLE_TABLES=y
| # CONFIG_IPV6_SUBTREES is not set
| # CONFIG_IPV6_MROUTE is not set
| # CONFIG_IPV6_SEG6_LWTUNNEL is not set
| # CONFIG_IPV6_SEG6_HMAC is not set
| # CONFIG_IPV6_RPL_LWTUNNEL is not set
| # CONFIG_NF_SOCKET_IPV6 is not set
| # CONFIG_NF_TPROXY_IPV6 is not set
| # CONFIG_NF_DUP_IPV6 is not set
| # CONFIG_NF_REJECT_IPV6 is not set
| # CONFIG_NF_LOG_IPV6 is not set
| CONFIG_NF_DEFRAG_IPV6=m
`

> Caused by commit
>
>   b9aaec8f0be5 ("fib: use indirect call wrappers in the most common 
> fib_rules_ops")
>
> # CONFIG_IPV6_MULTIPLE_TABLES is not set
>
> I have reverted that commit for today.

Cheers,
   Sven

Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n

[Sven Joachim]

On 2019-06-11 22:08 +0300, Thomas Backlund wrote:

> Den 11-06-2019 kl. 20:40, skrev Greg Kroah-Hartman:
>> On Tue, Jun 11, 2019 at 07:33:16PM +0200, Daniel Vetter wrote:
>>> On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman
>>>  wrote:
>>>> On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote:
>>>>> Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau
>>>>> legacy contexts. (v3)") has caused a build failure for me when I
>>>>> actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):
>>>>>
>>>>> ,
>>>>> | Kernel: arch/x86/boot/bzImage is ready  (#1)
>>>>> |   Building modules, stage 2.
>>>>> |   MODPOST 290 modules
>>>>> | ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
>>>>> | scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>>>>> `
>>>
>>> Calling drm_legacy_mmap is definitely not a great idea. I think either
>>> we need a custom patch to remove that out on older kernels, or maybe
>>> even #ifdef if you want to be super paranoid about breaking stuff ...
>>>
>>>>> Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
>>>>> Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
>>>>> drm_legacy_mmap from nouveau_ttm.c.  Unfortunately that commit does not
>>>>> apply in 5.1.9.
>>>>>
>>>>> Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested
>>>>> them yet.
>>>>
>>>> They probably are.
>>>>
>>>> Should I just revert this patch in the stable tree, or add some other
>>>> patch (like the one pointed out here, which seems an odd patch for
>>>> stable...)
>>>
>>> ... or backport the above patch, that should be save to do too. Not
>>> sure what stable folks prefer?
>>
>> The above patch does not apply to all of the stable branches, so how
>> about I just revert this?  People can live with this option not able to
>> turn off for now, and if they really want it, they can use a newer
>> kernel, right?
>>
>
> Or add the simple fix suggested by Daniel (if I understand correctly):
>
>
> From: Thomas Backlund 
>
> Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit:
> b30a43ac7132) causes the build to fail with:
>
> ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
>
> Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around
> the code using drm_legacy_mmap()
>
> Fixes: b30a43ac7132 drm/nouveau: add kconfig option to turn off
> nouveau legacy contexts. (v3)
> Signed-off-by: Thomas Backlund 
>
> ---
>  drivers/gpu/drm/nouveau/nouveau_ttm.c |2 ++
>  1 file changed, 2 insertions(+)
>
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -168,8 +168,10 @@ nouveau_ttm_mmap(struct file *filp, stru
>   struct drm_file *file_priv = filp->private_data;
>   struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);
>
> +#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
>   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
>   return drm_legacy_mmap(filp, vma);
> +#endif
>
>   return ttm_bo_mmap(filp, vma, >ttm.bdev);
>  }

That's not quite correct, I am afraid.  If
CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not defined, you still need to do
the test, but return -EINVAL.  Something along these lines:

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 1543c2f8d3d3..05d513d54555 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -169,7 +169,11 @@ nouveau_ttm_mmap(struct file *filp, struct vm_area_struct 
*vma)
struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);

if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
return drm_legacy_mmap(filp, vma);
+#else
+   return -EINVAL;
+#endif

return ttm_bo_mmap(filp, vma, >ttm.bdev);
 }


At least that builds for me, need to reboot to check whether it works.

Cheers,
   Sven

Re: Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n

[Sven Joachim]

On 2019-06-11 19:33 +0200, Daniel Vetter wrote:

> On Tue, Jun 11, 2019 at 5:37 PM Greg Kroah-Hartman
>  wrote:
>> On Tue, Jun 11, 2019 at 03:56:35PM +0200, Sven Joachim wrote:
>> > Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau
>> > legacy contexts. (v3)") has caused a build failure for me when I
>> > actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):
>> >
>> > ,
>> > | Kernel: arch/x86/boot/bzImage is ready  (#1)
>> > |   Building modules, stage 2.
>> > |   MODPOST 290 modules
>> > | ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
>> > | scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>> > `
>
> Calling drm_legacy_mmap is definitely not a great idea.

Certainly not, but it was done by Dave in commit 2036eaa7403 ("nouveau:
bring back legacy mmap handler") for compatibility with old
xf86-video-nouveau versions (older than 1.0.4) that call DRIOpenDRMMaster.

If that is really necessary, it probably has been broken in Linus' tree
by commit bed2dd8421 where the test has been moved to ttm_bo_mmap() and
returns -EINVAL on failure.

> I think either
> we need a custom patch to remove that out on older kernels, or maybe
> even #ifdef if you want to be super paranoid about breaking stuff ...
>
>> > Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
>> > Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
>> > drm_legacy_mmap from nouveau_ttm.c.  Unfortunately that commit does not
>> > apply in 5.1.9.
>> >
>> > Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested
>> > them yet.
>>
>> They probably are.
>>
>> Should I just revert this patch in the stable tree, or add some other
>> patch (like the one pointed out here, which seems an odd patch for
>> stable...)
>
> ... or backport the above patch, that should be save to do too. Not
> sure what stable folks prefer?
> -Daniel

Cheers,
   Sven

Linux 5.1.9 build failure with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n

[Sven Joachim]

Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau
legacy contexts. (v3)") has caused a build failure for me when I
actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):

,
| Kernel: arch/x86/boot/bzImage is ready  (#1)
|   Building modules, stage 2.
|   MODPOST 290 modules
| ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
| scripts/Makefile.modpost:91: recipe for target '__modpost' failed
`

Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
drm_legacy_mmap from nouveau_ttm.c.  Unfortunately that commit does not
apply in 5.1.9.

Most likely 4.19.50 and 4.14.125 are also affected, I haven't tested
them yet.

Cheers,
   Sven

Re: Linux 3.18.123

[Sven Joachim]

On 2018-10-13 10:50 +0200, Greg KH wrote:

> I'm announcing the release of the 3.18.124 kernel.

$Subject inadvertently says 3.18.123, something wrong with your scripts?

Cheers,
   Sven

Re: Linux 3.18.123

[Sven Joachim]

On 2018-10-13 10:50 +0200, Greg KH wrote:

> I'm announcing the release of the 3.18.124 kernel.

$Subject inadvertently says 3.18.123, something wrong with your scripts?

Cheers,
   Sven

Re: Linux 4.18.1

[Sven Joachim]

On 2018-08-16 15:05 +0200, Adam Borowski wrote:

> On Thu, Aug 16, 2018 at 12:14:29PM +0200, Greg KH wrote:
>> I'm announcing the release of the 4.18.1 kernel.
>
> I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with:
>
> ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities':
> (.text+0x43b2): undefined reference to `l1tf_vmx_mitigation'

Same here and also in 4.17.15, but not in Linus' tree.

> .config attached.

Probably relevant:

> CONFIG_KVM=y
> # CONFIG_KVM_INTEL is not set
> CONFIG_KVM_AMD=y

I have CONFIG_KVM{,AMD}=m and CONFIG_KVM_INTEL is not set either.

Cheers,
   Sven

Re: Linux 4.18.1

[Sven Joachim]

On 2018-08-16 15:05 +0200, Adam Borowski wrote:

> On Thu, Aug 16, 2018 at 12:14:29PM +0200, Greg KH wrote:
>> I'm announcing the release of the 4.18.1 kernel.
>
> I'm afraid that I get a build failure; v4.18 is ok, v4.18.1 fails with:
>
> ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities':
> (.text+0x43b2): undefined reference to `l1tf_vmx_mitigation'

Same here and also in 4.17.15, but not in Linus' tree.

> .config attached.

Probably relevant:

> CONFIG_KVM=y
> # CONFIG_KVM_INTEL is not set
> CONFIG_KVM_AMD=y

I have CONFIG_KVM{,AMD}=m and CONFIG_KVM_INTEL is not set either.

Cheers,
   Sven

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sven Joachim]

On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:

> nother issue seen on xscale and as it affects all non SMP configured kernels
>
>
> kernel/cpu.c: In function 'boot_cpu_hotplug_init':
> kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member
> named 'booted_once'
>   this_cpu_write(cpuhp_state.booted_once, true);

I got a different error in 4.9.120 with CONFIG_SMP unset:

,
| CC  drivers/rtc/rtc-cmos.o
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h: In function 'inb_pic':
| ./arch/x86/include/asm/i8259.h:32:24: error: implicit declaration of function 
'inb' [-Werror=implicit-function-declaration]
|   unsigned char value = inb(port);
| ^~~
| ./arch/x86/include/asm/i8259.h: In function 'outb_pic':
| ./arch/x86/include/asm/i8259.h:45:2: error: implicit declaration of function 
'outb' [-Werror=implicit-function-declaration]
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h: At top level:
| ./arch/x86/include/asm/io.h:277:20: warning: conflicting types for 'outb'
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| ./arch/x86/include/asm/io.h:277:20: error: static declaration of 'outb' 
follows non-static declaration
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:45:2: note: previous implicit declaration of 
'outb' was here
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h:283:29: error: conflicting types for 'inb'
|  static inline unsigned type in##bwl(int port)\
|  ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:32:24: note: previous implicit declaration of 
'inb' was here
|   unsigned char value = inb(port);
`

Cheers,
   Sven

Re: [PATCH 4.9 000/107] 4.9.120-stable review

[Sven Joachim]

On 2018-08-15 19:01 +0200, Sebastian Gottschall wrote:

> nother issue seen on xscale and as it affects all non SMP configured kernels
>
>
> kernel/cpu.c: In function 'boot_cpu_hotplug_init':
> kernel/cpu.c:2204:28: error: 'struct cpuhp_cpu_state' has no member
> named 'booted_once'
>   this_cpu_write(cpuhp_state.booted_once, true);

I got a different error in 4.9.120 with CONFIG_SMP unset:

,
| CC  drivers/rtc/rtc-cmos.o
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h: In function 'inb_pic':
| ./arch/x86/include/asm/i8259.h:32:24: error: implicit declaration of function 
'inb' [-Werror=implicit-function-declaration]
|   unsigned char value = inb(port);
| ^~~
| ./arch/x86/include/asm/i8259.h: In function 'outb_pic':
| ./arch/x86/include/asm/i8259.h:45:2: error: implicit declaration of function 
'outb' [-Werror=implicit-function-declaration]
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h: At top level:
| ./arch/x86/include/asm/io.h:277:20: warning: conflicting types for 'outb'
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| ./arch/x86/include/asm/io.h:277:20: error: static declaration of 'outb' 
follows non-static declaration
|  static inline void out##bwl(unsigned type value, int port)  \
| ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:45:2: note: previous implicit declaration of 
'outb' was here
|   outb(value, port);
|   ^~~~
| In file included from ./include/linux/mc146818rtc.h:14:0,
|  from drivers/rtc/rtc-cmos.c:49:
| ./arch/x86/include/asm/io.h:283:29: error: conflicting types for 'inb'
|  static inline unsigned type in##bwl(int port)\
|  ^
| ./arch/x86/include/asm/io.h:316:1: note: in expansion of macro 'BUILDIO'
|  BUILDIO(b, b, char)
|  ^~~
| In file included from drivers/rtc/rtc-cmos.c:45:0:
| ./arch/x86/include/asm/i8259.h:32:24: note: previous implicit declaration of 
'inb' was here
|   unsigned char value = inb(port);
`

Cheers,
   Sven

[PATCH] stack-protector: Fix test with 32-bit userland and CONFIG_64BIT=y

[Sven Joachim]

When building a 64-bit 4.18-rc1 kernel with a 32-bit userland, I
noticed that stack protection was silently disabled.  Adding -m64 in
gcc-x86_64-has-stack-protector.sh fixed that, similar to what has been
noticed in commit 2a61f4747eea ("stack-protector: test compiler
capability in Kconfig and drop AUTO mode") for
gcc-x86_32-has-stack-protector.sh.

Signed-off-by: Sven Joachim 
---
 scripts/gcc-x86_64-has-stack-protector.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-x86_64-has-stack-protector.sh 
b/scripts/gcc-x86_64-has-stack-protector.sh
index 3755af0cd9f7..75e4e22b986a 100755
--- a/scripts/gcc-x86_64-has-stack-protector.sh
+++ b/scripts/gcc-x86_64-has-stack-protector.sh
@@ -1,4 +1,4 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0
 
-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 
-mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m64 -O0 
-mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
-- 
2.17.1

[PATCH] stack-protector: Fix test with 32-bit userland and CONFIG_64BIT=y

[Sven Joachim]

When building a 64-bit 4.18-rc1 kernel with a 32-bit userland, I
noticed that stack protection was silently disabled.  Adding -m64 in
gcc-x86_64-has-stack-protector.sh fixed that, similar to what has been
noticed in commit 2a61f4747eea ("stack-protector: test compiler
capability in Kconfig and drop AUTO mode") for
gcc-x86_32-has-stack-protector.sh.

Signed-off-by: Sven Joachim 
---
 scripts/gcc-x86_64-has-stack-protector.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-x86_64-has-stack-protector.sh 
b/scripts/gcc-x86_64-has-stack-protector.sh
index 3755af0cd9f7..75e4e22b986a 100755
--- a/scripts/gcc-x86_64-has-stack-protector.sh
+++ b/scripts/gcc-x86_64-has-stack-protector.sh
@@ -1,4 +1,4 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0
 
-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 
-mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m64 -O0 
-mcmodel=kernel -fno-PIE -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
-- 
2.17.1

Re: Linux 4.16-rc4

[Sven Joachim]

On 2018-03-05 07:38 -0600, Josh Poimboeuf wrote:

> On Mon, Mar 05, 2018 at 11:17:48AM +0100, Peter Zijlstra wrote:
>> On Mon, Mar 05, 2018 at 09:09:31AM +0100, Sven Joachim wrote:
>> > On 2018-03-04 15:15 -0800, Linus Torvalds wrote:
>> > 
>> > > Hmm. A reasonably calm week - the biggest change is to the 'kvm-stat'
>> > > tool, not any actual kernel files.
>> > >
>> > > But there's small changes all over, with architecture updates (x86,
>> > > s390, arm, parisc) and drivers (media, md, gpu, sound) being the bulk
>> > > of it.  But there's some filesystem fixes (mostly btrfs),
>> > > documentation updates etc too.
>> > >
>> > > Go test,
>> > 
>> > Huh, this version does not build for me:
>> > 
>> > ,
>> > |   CALLscripts/checksyscalls.sh
>> > |   DESCEND  objtool
>> > |   CC   /usr/local/src/linux/tools/objtool/check.o
>> > | In file included from check.c:26:0:
>> > | check.c: In function 'read_retpoline_hints':
>> > | warn.h:57:3: error: format '%ld' expects argument of type 'long int', 
>> > but argument 5 has type 'unsigned int' [-Werror=format=]
>> > |"%s: warning: objtool: " format "\n", \
>> > |^
>> > | check.c:1135:3: note: in expansion of macro 'WARN'
>> > |WARN("retpoline_safe size mismatch: %d %ld", sec->len, 
>> > sizeof(unsigned long));
>> > |^~~~
>> > | check.c:1135:44: note: format string is defined here
>> > |WARN("retpoline_safe size mismatch: %d %ld", sec->len, 
>> > sizeof(unsigned long));
>> > |   ~~^
>> > |   %d
>> > | cc1: all warnings being treated as errors
>> > | mv: cannot stat '/usr/local/src/linux/tools/objtool/.check.o.tmp': No 
>> > such file or directory
>> > | /usr/local/src/linux/tools/build/Makefile.build:96: recipe for target 
>> > '/usr/local/src/linux/tools/objtool/check.o' failed
>> > | make[3]: *** [/usr/local/src/linux/tools/objtool/check.o] Error 1
>> > `
>> > 
>> > This might be because I still use a 32-bit userland with a 64-bit
>> > kernel.
>> 
>> Urgh, so sizeof() returns size_t which is confusing. But what is the
>> actual value of sizeof(unsigned long) for you? I suspect cross building
>> objtool doesn't work right at all. We build the kernel using LP64, and
>> its retpoline_safe section is 8 bytes. But if we build objtool as ILP32
>> then it would interpret things as 4 bytes.
>> 
>> Josh, is that supposed to work? I could of course move the retpoline
>> annotation over to 4 byte relative addressing which would fix this one
>> issue. Is that really the only case?
>
> I suspect it may be the only case.  In most cases objtool relies on
> libelf for handling the object bit width.
>
> It looks like read_retpoline_hints() is "special" compared to the other
> annotation reading functions.  The easiest fix would be to convert it to
> be like the others.
>
> Sven, can you test this patch?
>
> ---
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 472e64e95891..e00ff29cb7ea 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -1112,42 +1112,29 @@ static int read_unwind_hints(struct objtool_file 
> *file)
>  
>  static int read_retpoline_hints(struct objtool_file *file)
>  {
> - struct section *sec, *relasec;
> + struct section *sec;
>   struct instruction *insn;
>   struct rela *rela;
> - int i;
>  
> - sec = find_section_by_name(file->elf, ".discard.retpoline_safe");
> + sec = find_section_by_name(file->elf, ".rela.discard.retpoline_safe");
>   if (!sec)
>   return 0;
>  
> - relasec = sec->rela;
> - if (!relasec) {
> - WARN("missing .rela.discard.retpoline_safe section");
> - return -1;
> - }
> -
> - if (sec->len % sizeof(unsigned long)) {
> - WARN("retpoline_safe size mismatch: %d %ld", sec->len, 
> sizeof(unsigned long));
> - return -1;
> - }
> -
> - for (i = 0; i < sec->len / sizeof(unsigned long); i++) {
> - rela = find_rela_by_dest(sec, i * sizeof(unsigned long));
> - if (!rela) {
> - WARN("can't find rela for retpoline_safe[%d]", i);
> + list_for_each_entry(rela, >rela_list, list) {
> +

Re: Linux 4.16-rc4

[Sven Joachim]

On 2018-03-05 07:38 -0600, Josh Poimboeuf wrote:

> On Mon, Mar 05, 2018 at 11:17:48AM +0100, Peter Zijlstra wrote:
>> On Mon, Mar 05, 2018 at 09:09:31AM +0100, Sven Joachim wrote:
>> > On 2018-03-04 15:15 -0800, Linus Torvalds wrote:
>> > 
>> > > Hmm. A reasonably calm week - the biggest change is to the 'kvm-stat'
>> > > tool, not any actual kernel files.
>> > >
>> > > But there's small changes all over, with architecture updates (x86,
>> > > s390, arm, parisc) and drivers (media, md, gpu, sound) being the bulk
>> > > of it.  But there's some filesystem fixes (mostly btrfs),
>> > > documentation updates etc too.
>> > >
>> > > Go test,
>> > 
>> > Huh, this version does not build for me:
>> > 
>> > ,
>> > |   CALLscripts/checksyscalls.sh
>> > |   DESCEND  objtool
>> > |   CC   /usr/local/src/linux/tools/objtool/check.o
>> > | In file included from check.c:26:0:
>> > | check.c: In function 'read_retpoline_hints':
>> > | warn.h:57:3: error: format '%ld' expects argument of type 'long int', 
>> > but argument 5 has type 'unsigned int' [-Werror=format=]
>> > |"%s: warning: objtool: " format "\n", \
>> > |^
>> > | check.c:1135:3: note: in expansion of macro 'WARN'
>> > |WARN("retpoline_safe size mismatch: %d %ld", sec->len, 
>> > sizeof(unsigned long));
>> > |^~~~
>> > | check.c:1135:44: note: format string is defined here
>> > |WARN("retpoline_safe size mismatch: %d %ld", sec->len, 
>> > sizeof(unsigned long));
>> > |   ~~^
>> > |   %d
>> > | cc1: all warnings being treated as errors
>> > | mv: cannot stat '/usr/local/src/linux/tools/objtool/.check.o.tmp': No 
>> > such file or directory
>> > | /usr/local/src/linux/tools/build/Makefile.build:96: recipe for target 
>> > '/usr/local/src/linux/tools/objtool/check.o' failed
>> > | make[3]: *** [/usr/local/src/linux/tools/objtool/check.o] Error 1
>> > `
>> > 
>> > This might be because I still use a 32-bit userland with a 64-bit
>> > kernel.
>> 
>> Urgh, so sizeof() returns size_t which is confusing. But what is the
>> actual value of sizeof(unsigned long) for you? I suspect cross building
>> objtool doesn't work right at all. We build the kernel using LP64, and
>> its retpoline_safe section is 8 bytes. But if we build objtool as ILP32
>> then it would interpret things as 4 bytes.
>> 
>> Josh, is that supposed to work? I could of course move the retpoline
>> annotation over to 4 byte relative addressing which would fix this one
>> issue. Is that really the only case?
>
> I suspect it may be the only case.  In most cases objtool relies on
> libelf for handling the object bit width.
>
> It looks like read_retpoline_hints() is "special" compared to the other
> annotation reading functions.  The easiest fix would be to convert it to
> be like the others.
>
> Sven, can you test this patch?
>
> ---
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 472e64e95891..e00ff29cb7ea 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -1112,42 +1112,29 @@ static int read_unwind_hints(struct objtool_file 
> *file)
>  
>  static int read_retpoline_hints(struct objtool_file *file)
>  {
> - struct section *sec, *relasec;
> + struct section *sec;
>   struct instruction *insn;
>   struct rela *rela;
> - int i;
>  
> - sec = find_section_by_name(file->elf, ".discard.retpoline_safe");
> + sec = find_section_by_name(file->elf, ".rela.discard.retpoline_safe");
>   if (!sec)
>   return 0;
>  
> - relasec = sec->rela;
> - if (!relasec) {
> - WARN("missing .rela.discard.retpoline_safe section");
> - return -1;
> - }
> -
> - if (sec->len % sizeof(unsigned long)) {
> - WARN("retpoline_safe size mismatch: %d %ld", sec->len, 
> sizeof(unsigned long));
> - return -1;
> - }
> -
> - for (i = 0; i < sec->len / sizeof(unsigned long); i++) {
> - rela = find_rela_by_dest(sec, i * sizeof(unsigned long));
> - if (!rela) {
> - WARN("can't find rela for retpoline_safe[%d]", i);
> + list_for_each_entry(rela, >rela_list, list) {
> +

Re: Linux 4.16-rc4

[Sven Joachim]

On 2018-03-04 15:15 -0800, Linus Torvalds wrote:

> Hmm. A reasonably calm week - the biggest change is to the 'kvm-stat'
> tool, not any actual kernel files.
>
> But there's small changes all over, with architecture updates (x86,
> s390, arm, parisc) and drivers (media, md, gpu, sound) being the bulk
> of it.  But there's some filesystem fixes (mostly btrfs),
> documentation updates etc too.
>
> Go test,

Huh, this version does not build for me:

,
|   CALLscripts/checksyscalls.sh
|   DESCEND  objtool
|   CC   /usr/local/src/linux/tools/objtool/check.o
| In file included from check.c:26:0:
| check.c: In function 'read_retpoline_hints':
| warn.h:57:3: error: format '%ld' expects argument of type 'long int', but 
argument 5 has type 'unsigned int' [-Werror=format=]
|"%s: warning: objtool: " format "\n", \
|^
| check.c:1135:3: note: in expansion of macro 'WARN'
|WARN("retpoline_safe size mismatch: %d %ld", sec->len, sizeof(unsigned 
long));
|^~~~
| check.c:1135:44: note: format string is defined here
|WARN("retpoline_safe size mismatch: %d %ld", sec->len, sizeof(unsigned 
long));
|   ~~^
|   %d
| cc1: all warnings being treated as errors
| mv: cannot stat '/usr/local/src/linux/tools/objtool/.check.o.tmp': No such 
file or directory
| /usr/local/src/linux/tools/build/Makefile.build:96: recipe for target 
'/usr/local/src/linux/tools/objtool/check.o' failed
| make[3]: *** [/usr/local/src/linux/tools/objtool/check.o] Error 1
`

This might be because I still use a 32-bit userland with a 64-bit
kernel.

Cheers,
   Sven

Re: Linux 4.16-rc4

[Sven Joachim]

On 2018-03-04 15:15 -0800, Linus Torvalds wrote:

> Hmm. A reasonably calm week - the biggest change is to the 'kvm-stat'
> tool, not any actual kernel files.
>
> But there's small changes all over, with architecture updates (x86,
> s390, arm, parisc) and drivers (media, md, gpu, sound) being the bulk
> of it.  But there's some filesystem fixes (mostly btrfs),
> documentation updates etc too.
>
> Go test,

Huh, this version does not build for me:

,
|   CALLscripts/checksyscalls.sh
|   DESCEND  objtool
|   CC   /usr/local/src/linux/tools/objtool/check.o
| In file included from check.c:26:0:
| check.c: In function 'read_retpoline_hints':
| warn.h:57:3: error: format '%ld' expects argument of type 'long int', but 
argument 5 has type 'unsigned int' [-Werror=format=]
|"%s: warning: objtool: " format "\n", \
|^
| check.c:1135:3: note: in expansion of macro 'WARN'
|WARN("retpoline_safe size mismatch: %d %ld", sec->len, sizeof(unsigned 
long));
|^~~~
| check.c:1135:44: note: format string is defined here
|WARN("retpoline_safe size mismatch: %d %ld", sec->len, sizeof(unsigned 
long));
|   ~~^
|   %d
| cc1: all warnings being treated as errors
| mv: cannot stat '/usr/local/src/linux/tools/objtool/.check.o.tmp': No such 
file or directory
| /usr/local/src/linux/tools/build/Makefile.build:96: recipe for target 
'/usr/local/src/linux/tools/objtool/check.o' failed
| make[3]: *** [/usr/local/src/linux/tools/objtool/check.o] Error 1
`

This might be because I still use a 32-bit userland with a 64-bit
kernel.

Cheers,
   Sven

Re: [PATCH] objtool: fix build of 64-bit kernel with 32-bit userspace

[Sven Joachim]

On 2017-11-07 11:55 -0600, Josh Poimboeuf wrote:

> [ Adding Ingo to cc because I believe it was his suggestion to hide the
>   guess unwinder behind CONFIG_EXPERT. ]
>
> On Mon, Nov 06, 2017 at 06:27:53PM -0500, Mikulas Patocka wrote:
>> This patch fixes building of 64-bit kernel on 32-bit userspace (I tested 
>> it on RHEL-6-i686 and Debian-Sid-x32).
>
> Thanks, I'll review the patch.

Any news on that?  After upgrading to 4.15-rc1 and running
"make oldconfig" I found out that the kernel would no longer build
unless I selected CONFIG_UNWINDER_FRAME_POINTER=y.

,
| $ uname -m
| x86_64
| $ dpkg --print-architecture 
| i386
`

>> There are still some more bugs - when building 64-bit kernel on 32-bit
>> Debian 7 distribution, objtool corrupts object files so that the linker
>> doesn't recognize them (ld doesn't recognize the format of the file at all
>> and gold prints a lot of errors).
>
> Hm, we should figure out what's going on there...
>
>> Another problem - when building 32-bit kernel, why do you force frame
>> pointers on and why did you hide CONFIG_GUESS_UNWINDER behind
>> CONFIG_EXPERT? Frame pointers increase code size and register pressure,
>> most users don't need precise stacktraces, so CONFIG_GUESS_UNWINDER should
>> be default for non-expert users just like it was before.
>> 
>> Is there some technical reason why do you want to avoid 
>> CONFIG_GUESS_UNWINDER?
>
> The technical reason for avoiding the guess unwinder is that it's
> sketchy: it gives false positive results.  Not only for oopses, but for
> all the other users of the unwinder: /proc//stack, perf, lockdep,
> etc.  So it's a correctness issue.
>
> I agree with you that the frame pointer unwinder has drawbacks, but if
> somebody cares about those drawbacks, I would consider that person an
> "expert" ;-)

Cheers,
   Sven

Re: [PATCH] objtool: fix build of 64-bit kernel with 32-bit userspace

[Sven Joachim]

On 2017-11-07 11:55 -0600, Josh Poimboeuf wrote:

> [ Adding Ingo to cc because I believe it was his suggestion to hide the
>   guess unwinder behind CONFIG_EXPERT. ]
>
> On Mon, Nov 06, 2017 at 06:27:53PM -0500, Mikulas Patocka wrote:
>> This patch fixes building of 64-bit kernel on 32-bit userspace (I tested 
>> it on RHEL-6-i686 and Debian-Sid-x32).
>
> Thanks, I'll review the patch.

Any news on that?  After upgrading to 4.15-rc1 and running
"make oldconfig" I found out that the kernel would no longer build
unless I selected CONFIG_UNWINDER_FRAME_POINTER=y.

,
| $ uname -m
| x86_64
| $ dpkg --print-architecture 
| i386
`

>> There are still some more bugs - when building 64-bit kernel on 32-bit
>> Debian 7 distribution, objtool corrupts object files so that the linker
>> doesn't recognize them (ld doesn't recognize the format of the file at all
>> and gold prints a lot of errors).
>
> Hm, we should figure out what's going on there...
>
>> Another problem - when building 32-bit kernel, why do you force frame
>> pointers on and why did you hide CONFIG_GUESS_UNWINDER behind
>> CONFIG_EXPERT? Frame pointers increase code size and register pressure,
>> most users don't need precise stacktraces, so CONFIG_GUESS_UNWINDER should
>> be default for non-expert users just like it was before.
>> 
>> Is there some technical reason why do you want to avoid 
>> CONFIG_GUESS_UNWINDER?
>
> The technical reason for avoiding the guess unwinder is that it's
> sketchy: it gives false positive results.  Not only for oopses, but for
> all the other users of the unwinder: /proc//stack, perf, lockdep,
> etc.  So it's a correctness issue.
>
> I agree with you that the frame pointer unwinder has drawbacks, but if
> somebody cares about those drawbacks, I would consider that person an
> "expert" ;-)

Cheers,
   Sven

[PATCH] builddeb: Pass the kernel:debarch substvar to dpkg-genchanges

[Sven Joachim]

At the end of "make bindeb-pkg" I noticed the following warning:

dpkg-genchanges: warning: unknown substitution variable ${kernel:debarch}

It turns out that since dpkg version 1.19.0 dpkg-genchanges honors
substitution variables in the Description field, while earlier
versions silently left them alone, see https://bugs.debian.org/856547.

The result is an incomplete description of the linux-headers package
in the generated .changes file.  Fix it by passing the kernel:debarch
substitution variable to dpkg-genchanges.

Signed-off-by: Sven Joachim <svenj...@gmx.de>
---
 scripts/package/builddeb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 0bc87473f68f..b4f0f2b3f8d2 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -408,9 +408,9 @@ EOF
dpkg-source -cdebian/control -ldebian/changelog --format="3.0 (custom)" 
--target-format="3.0 (quilt)" \
-b / ../${sourcename}_${version}.orig.tar.gz  
../${sourcename}_${packageversion}.debian.tar.gz
mv ${sourcename}_${packageversion}*dsc ..
-   dpkg-genchanges > ../${sourcename}_${packageversion}_${debarch}.changes
+   dpkg-genchanges -Vkernel:debarch="${debarch}" > 
../${sourcename}_${packageversion}_${debarch}.changes
 else
-   dpkg-genchanges -b > 
../${sourcename}_${packageversion}_${debarch}.changes
+   dpkg-genchanges -b -Vkernel:debarch="${debarch}" > 
../${sourcename}_${packageversion}_${debarch}.changes
 fi
 
 exit 0
-- 
2.15.0

[PATCH] builddeb: Pass the kernel:debarch substvar to dpkg-genchanges

[Sven Joachim]

At the end of "make bindeb-pkg" I noticed the following warning:

dpkg-genchanges: warning: unknown substitution variable ${kernel:debarch}

It turns out that since dpkg version 1.19.0 dpkg-genchanges honors
substitution variables in the Description field, while earlier
versions silently left them alone, see https://bugs.debian.org/856547.

The result is an incomplete description of the linux-headers package
in the generated .changes file.  Fix it by passing the kernel:debarch
substitution variable to dpkg-genchanges.

Signed-off-by: Sven Joachim 
---
 scripts/package/builddeb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 0bc87473f68f..b4f0f2b3f8d2 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -408,9 +408,9 @@ EOF
dpkg-source -cdebian/control -ldebian/changelog --format="3.0 (custom)" 
--target-format="3.0 (quilt)" \
-b / ../${sourcename}_${version}.orig.tar.gz  
../${sourcename}_${packageversion}.debian.tar.gz
mv ${sourcename}_${packageversion}*dsc ..
-   dpkg-genchanges > ../${sourcename}_${packageversion}_${debarch}.changes
+   dpkg-genchanges -Vkernel:debarch="${debarch}" > 
../${sourcename}_${packageversion}_${debarch}.changes
 else
-   dpkg-genchanges -b > 
../${sourcename}_${packageversion}_${debarch}.changes
+   dpkg-genchanges -b -Vkernel:debarch="${debarch}" > 
../${sourcename}_${packageversion}_${debarch}.changes
 fi
 
 exit 0
-- 
2.15.0

Re: Linux 4.8.11

[Sven Joachim]

On 2016-11-27 00:35 +0100, Adam Borowski wrote:

> On Sat, Nov 26, 2016 at 05:12:35PM +0100, Greg KH wrote:
>> I'm announcing the release of the 4.8.11 kernel.
>
> ... which splats during early boot where 4.8.10 worked fine.
>
> [ 0.00] Linux version 4.8.11+ (kilobyte@umbar) (gcc version 6.2.1
> 20161124 (Debian 6.2.1-5) ) #1 SMP Sat Nov 26 22:32:52 CET 2016
> [ 0.00] Command line: BOOT_IMAGE=/sys/boot/vmlinuz-4.8.11+
> root=UUID=b7c38da9-ae84-4083-a1f8-6d7b4fc33961 ro rootflags=subvol=sys
> syscall.x32=y syscall.x32=y console=tty1 console=ttyS0,115200,n81
> [0.00] x86/fpu: Legacy x87 FPU detected.
> [0.00] x86/fpu: Using 'eager' FPU context switches.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009ebff] usable
> [0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0xc7e7] usable
> [0.00] BIOS-e820: [mem 0xc7e8-0xc7e97fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xc7e98000-0xc7ec] ACPI NVS
> [0.00] BIOS-e820: [mem 0xc7ed-0xc7ef] reserved
> [0.00] BIOS-e820: [mem 0xff70-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x000237ff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.5 present.
> [0.00] AGP: No AGP bridge found
> [0.00] e820: last_pfn = 0x238000 max_arch_pfn = 0x4
> [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
> [0.00] e820: last_pfn = 0xc7e80 max_arch_pfn = 0x4
> [0.00] Using GB pages for direct mapping
> [0.00] RAMDISK: [mem 0x3668d000-0x3733dfff]
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0x000FB510 24 (v02 ACPIAM)
> [0.00] ACPI: XSDT 0xC7E80100 5C (v01 051811 XSDT1038 
> 20110518 MSFT 0097)
> [0.00] ACPI: FACP 0xC7E80290 F4 (v03 051811 FACP1038 
> 20110518 MSFT 0097)
> [ 0.00] ACPI BIOS Warning (bug): Optional FADT field
> Pm2ControlBlock has valid Length but zero Address:
> 0x/0x1 (20160422/tbfadt-658)
> [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
> FADT/Gpe0Block: 64/32 (20160422/tbfadt-624)
> [0.00] ACPI: DSDT 0xC7E80450 00DB3A (v01 A1540  A1540001 
> 0001 INTL 20060113)
> [0.00] ACPI: FACS 0xC7E98000 40
> [0.00] ACPI: FACS 0xC7E98000 40
> [0.00] ACPI: APIC 0xC7E80390 7C (v01 051811 APIC1038 
> 20110518 MSFT 0097)
> [0.00] ACPI: MCFG 0xC7E80410 3C (v01 051811 OEMMCFG  
> 20110518 MSFT 0097)
> [0.00] ACPI: OEMB 0xC7E98040 72 (v01 051811 OEMB1038 
> 20110518 MSFT 0097)
> [0.00] ACPI: SRAT 0xC7E8F650 000108 (v01 AMDFAM_F_10 
> 0002 AMD  0001)
> [0.00] ACPI: HPET 0xC7E8F760 38 (v01 051811 OEMHPET  
> 20110518 MSFT 0097)
> [0.00] ACPI: SSDT 0xC7E8F7A0 000DA4 (v01 A M I  POWERNOW 
> 0001 AMD  0001)
> [0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x02 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x03 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x04 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x05 -> Node 0
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0xc7ff]
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x237ff]
> [0.00] NUMA: Node 0 [mem 0x-0x0009] + [mem 
> 0x0010-0xc7ff] -> [mem 0x-0xc7ff]
> [0.00] NUMA: Node 0 [mem 0x-0xc7ff] + [mem 
> 0x1-0x237ff] -> [mem 0x-0x237ff]
> [0.00] NODE_DATA(0) allocated [mem 0x237ffa000-0x237ffdfff]
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x1000-0x00ff]
> [0.00]   DMA32[mem 0x0100-0x]
> [0.00]   Normal   [mem 0x0001-0x000237ff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x1000-0x0009dfff]
> [0.00]   node   0: [mem 0x0010-0xc7e7]
> [0.00]   node   0: [mem 0x0001-0x000237ff]
> [0.00] Initmem setup node 0 [mem 
> 0x1000-0x000237ff]
> [0.00] ACPI: PM-Timer IO Port: 0x808
> [0.00] IOAPIC[0]: apic_id 6, version 33, address 0xfec0, GSI 0-23
> [0.00] ACPI: 

Re: Linux 4.8.11

[Sven Joachim]

On 2016-11-27 00:35 +0100, Adam Borowski wrote:

> On Sat, Nov 26, 2016 at 05:12:35PM +0100, Greg KH wrote:
>> I'm announcing the release of the 4.8.11 kernel.
>
> ... which splats during early boot where 4.8.10 worked fine.
>
> [ 0.00] Linux version 4.8.11+ (kilobyte@umbar) (gcc version 6.2.1
> 20161124 (Debian 6.2.1-5) ) #1 SMP Sat Nov 26 22:32:52 CET 2016
> [ 0.00] Command line: BOOT_IMAGE=/sys/boot/vmlinuz-4.8.11+
> root=UUID=b7c38da9-ae84-4083-a1f8-6d7b4fc33961 ro rootflags=subvol=sys
> syscall.x32=y syscall.x32=y console=tty1 console=ttyS0,115200,n81
> [0.00] x86/fpu: Legacy x87 FPU detected.
> [0.00] x86/fpu: Using 'eager' FPU context switches.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009ebff] usable
> [0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0xc7e7] usable
> [0.00] BIOS-e820: [mem 0xc7e8-0xc7e97fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xc7e98000-0xc7ec] ACPI NVS
> [0.00] BIOS-e820: [mem 0xc7ed-0xc7ef] reserved
> [0.00] BIOS-e820: [mem 0xff70-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x000237ff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.5 present.
> [0.00] AGP: No AGP bridge found
> [0.00] e820: last_pfn = 0x238000 max_arch_pfn = 0x4
> [0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
> [0.00] e820: last_pfn = 0xc7e80 max_arch_pfn = 0x4
> [0.00] Using GB pages for direct mapping
> [0.00] RAMDISK: [mem 0x3668d000-0x3733dfff]
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0x000FB510 24 (v02 ACPIAM)
> [0.00] ACPI: XSDT 0xC7E80100 5C (v01 051811 XSDT1038 
> 20110518 MSFT 0097)
> [0.00] ACPI: FACP 0xC7E80290 F4 (v03 051811 FACP1038 
> 20110518 MSFT 0097)
> [ 0.00] ACPI BIOS Warning (bug): Optional FADT field
> Pm2ControlBlock has valid Length but zero Address:
> 0x/0x1 (20160422/tbfadt-658)
> [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
> FADT/Gpe0Block: 64/32 (20160422/tbfadt-624)
> [0.00] ACPI: DSDT 0xC7E80450 00DB3A (v01 A1540  A1540001 
> 0001 INTL 20060113)
> [0.00] ACPI: FACS 0xC7E98000 40
> [0.00] ACPI: FACS 0xC7E98000 40
> [0.00] ACPI: APIC 0xC7E80390 7C (v01 051811 APIC1038 
> 20110518 MSFT 0097)
> [0.00] ACPI: MCFG 0xC7E80410 3C (v01 051811 OEMMCFG  
> 20110518 MSFT 0097)
> [0.00] ACPI: OEMB 0xC7E98040 72 (v01 051811 OEMB1038 
> 20110518 MSFT 0097)
> [0.00] ACPI: SRAT 0xC7E8F650 000108 (v01 AMDFAM_F_10 
> 0002 AMD  0001)
> [0.00] ACPI: HPET 0xC7E8F760 38 (v01 051811 OEMHPET  
> 20110518 MSFT 0097)
> [0.00] ACPI: SSDT 0xC7E8F7A0 000DA4 (v01 A M I  POWERNOW 
> 0001 AMD  0001)
> [0.00] SRAT: PXM 0 -> APIC 0x00 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x01 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x02 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x03 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x04 -> Node 0
> [0.00] SRAT: PXM 0 -> APIC 0x05 -> Node 0
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0xc7ff]
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x237ff]
> [0.00] NUMA: Node 0 [mem 0x-0x0009] + [mem 
> 0x0010-0xc7ff] -> [mem 0x-0xc7ff]
> [0.00] NUMA: Node 0 [mem 0x-0xc7ff] + [mem 
> 0x1-0x237ff] -> [mem 0x-0x237ff]
> [0.00] NODE_DATA(0) allocated [mem 0x237ffa000-0x237ffdfff]
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x1000-0x00ff]
> [0.00]   DMA32[mem 0x0100-0x]
> [0.00]   Normal   [mem 0x0001-0x000237ff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x1000-0x0009dfff]
> [0.00]   node   0: [mem 0x0010-0xc7e7]
> [0.00]   node   0: [mem 0x0001-0x000237ff]
> [0.00] Initmem setup node 0 [mem 
> 0x1000-0x000237ff]
> [0.00] ACPI: PM-Timer IO Port: 0x808
> [0.00] IOAPIC[0]: apic_id 6, version 33, address 0xfec0, GSI 0-23
> [0.00] ACPI: 

Re: [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils

[Sven Joachim]

On 2016-11-02 18:20 +0100, Sebastian Andrzej Siewior wrote:

> Debian Woody is pre-gcc3.2 and Sarge ships 3.3 gcc. I tried to compile
> v4.8.6 on Sarge failed due to binutils:
> |arch/x86/entry/entry_32.S: Assembler messages:
> |arch/x86/entry/entry_32.S:379: Error: invalid character '"' in operand 1
> |arch/x86/entry/entry_32.S:454: Error: too many positional arguments
> |arch/x86/entry/entry_32.S:580: Error: too many positional arguments
> |arch/x86/boot/bioscall.S:68: Error: `68(%esp)' is not a valid 16 bit 
> base/index expression
>
> among other errors. Sarge comes with GNU ld version 2.15 with is not
> recent enough. I don't see those errors on Etch which ships version 2.17
> and therefore I raise the limit to 2.17.

I can confirm that binutils 2.16 is not recent enough either, while 2.17
works.

> gcc is a different story. 3.3 It throws a lot of warnings
> |include/linux/irq.h:402: warning: parameter has incomplete type
> |include/linux/irq.h:403: warning: parameter has incomplete type
> |drivers/gpu/drm/i915/i915_gem_gtt.h:312: warning: parameter has incomplete 
> type
>
> during the compile and fails then with
> | cc1: error: unrecognized option `-Wno-override-init'
>
> or later with
>
> |lib/lzo/lzo1x_compress.c: In function `lzo1x_1_do_compress':
> |lib/lzo/lzo1x_compress.c:132: error: implicit declaration of function 
> `__builtin_ctz'
>
> Etch (with gcc v4.1.2) gets to compile the kernel without plenty of
> warnings and it also chokes on Wno-override-init but that one could be
> easily fixed if we want to keep v4.1 as the minimum.
> So I think raising the bar to gcc v4.1 isn't that bad given that the
> last release of gcc 4.1 was on February 13, 2007.

For the record, the -Wno-override-init problem has already been fixed in
4.9-rc3 by commit a2209b742e6 ("x86/build: Fix build with older GCC
versions").

Cheers,
   Sven

> diff --git a/Documentation/Changes b/Documentation/Changes
> index 22797a15dc24..14e65b445707 100644
> --- a/Documentation/Changes
> +++ b/Documentation/Changes
> @@ -29,9 +29,9 @@ you probably needn't concern yourself with isdn4k-utils.
>  == ===  
> 
>  ProgramMinimal version   Command to check the version
>  == ===  
> 
> -GNU C  3.2  gcc --version
> +GNU C  4.1  gcc --version
>  GNU make   3.80 make --version
> -binutils   2.12 ld -v
> +binutils   2.17 ld -v
>  util-linux 2.10ofdformat --version
>  module-init-tools  0.9.10   depmod -V
>  e2fsprogs  1.41.4   e2fsck -V
> -- 
> 2.10.2

Re: [PATCH 1/2] Documentation/HOWTO: Use a more recent gcc + binutils

[Sven Joachim]

On 2016-11-02 18:20 +0100, Sebastian Andrzej Siewior wrote:

> Debian Woody is pre-gcc3.2 and Sarge ships 3.3 gcc. I tried to compile
> v4.8.6 on Sarge failed due to binutils:
> |arch/x86/entry/entry_32.S: Assembler messages:
> |arch/x86/entry/entry_32.S:379: Error: invalid character '"' in operand 1
> |arch/x86/entry/entry_32.S:454: Error: too many positional arguments
> |arch/x86/entry/entry_32.S:580: Error: too many positional arguments
> |arch/x86/boot/bioscall.S:68: Error: `68(%esp)' is not a valid 16 bit 
> base/index expression
>
> among other errors. Sarge comes with GNU ld version 2.15 with is not
> recent enough. I don't see those errors on Etch which ships version 2.17
> and therefore I raise the limit to 2.17.

I can confirm that binutils 2.16 is not recent enough either, while 2.17
works.

> gcc is a different story. 3.3 It throws a lot of warnings
> |include/linux/irq.h:402: warning: parameter has incomplete type
> |include/linux/irq.h:403: warning: parameter has incomplete type
> |drivers/gpu/drm/i915/i915_gem_gtt.h:312: warning: parameter has incomplete 
> type
>
> during the compile and fails then with
> | cc1: error: unrecognized option `-Wno-override-init'
>
> or later with
>
> |lib/lzo/lzo1x_compress.c: In function `lzo1x_1_do_compress':
> |lib/lzo/lzo1x_compress.c:132: error: implicit declaration of function 
> `__builtin_ctz'
>
> Etch (with gcc v4.1.2) gets to compile the kernel without plenty of
> warnings and it also chokes on Wno-override-init but that one could be
> easily fixed if we want to keep v4.1 as the minimum.
> So I think raising the bar to gcc v4.1 isn't that bad given that the
> last release of gcc 4.1 was on February 13, 2007.

For the record, the -Wno-override-init problem has already been fixed in
4.9-rc3 by commit a2209b742e6 ("x86/build: Fix build with older GCC
versions").

Cheers,
   Sven

> diff --git a/Documentation/Changes b/Documentation/Changes
> index 22797a15dc24..14e65b445707 100644
> --- a/Documentation/Changes
> +++ b/Documentation/Changes
> @@ -29,9 +29,9 @@ you probably needn't concern yourself with isdn4k-utils.
>  == ===  
> 
>  ProgramMinimal version   Command to check the version
>  == ===  
> 
> -GNU C  3.2  gcc --version
> +GNU C  4.1  gcc --version
>  GNU make   3.80 make --version
> -binutils   2.12 ld -v
> +binutils   2.17 ld -v
>  util-linux 2.10ofdformat --version
>  module-init-tools  0.9.10   depmod -V
>  e2fsprogs  1.41.4   e2fsck -V
> -- 
> 2.10.2

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-29 21:21 +0200, Tomas Janousek wrote:

> On Sat, Oct 29, 2016 at 07:03:30PM +0200, Sven Joachim wrote:
>> I cannot reproduce that, FWIW.  Also, arch/x86/entry/vdso/Makefile seems
>> to explicitly filter out -mfentry from the compiler flags, but maybe I
>> misunderstand something.
>
> Compiler flags, yes; assembler flags, no. Perhaps adding
>
> KBUILD_AFLAGS_32 := $(filter-out -mfentry,$(KBUILD_AFLAGS_32))
>
> to arch/x86/entry/vdso/Makefile would fix the build as well. I have honestly
> no idea which solution is better. :-)
>
>> Could you please show the exact command that's failing with "make V=1"?
>
> gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d -nostdinc -isystem
> /usr/lib/gcc/i686-linux-gnu/6/include -I./arch/x86/include
> -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated
> -I./include -I./arch/x86/include/uapi -I./include/uapi
> -I./include/generated/uapi -include ./include/linux/kconfig.h
> -D__KERNEL__ -D__ASSEMBLY__ -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
> -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
> -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_SHA1_NI=1
> -DCONFIG_AS_SHA256_NI=1 -Wa,-gdwarf-2 -mfentry -DCC_USING_FENTRY
> -DCC_HAVE_ASM_GOTO -DBUILD_VDSO -m32 -c -o
> arch/x86/entry/vdso/vdso32/note.o arch/x86/entry/vdso/vdso32/note.S
>
> Is this file being built with your .config?

Yes, and "-mfentry -DCC_USING_FENTRY" is missing from the gcc
commandline there.  And not only there, although I have
CONFIG_FUNCTION_TRACER=y and CONFIG_HAVE_FENTRY=y, which should cause it
to be added to KBUILD_CFLAGS and KBUILD_AFLAGS.

I don't understand that, but it's late in the evening here.

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-29 21:21 +0200, Tomas Janousek wrote:

> On Sat, Oct 29, 2016 at 07:03:30PM +0200, Sven Joachim wrote:
>> I cannot reproduce that, FWIW.  Also, arch/x86/entry/vdso/Makefile seems
>> to explicitly filter out -mfentry from the compiler flags, but maybe I
>> misunderstand something.
>
> Compiler flags, yes; assembler flags, no. Perhaps adding
>
> KBUILD_AFLAGS_32 := $(filter-out -mfentry,$(KBUILD_AFLAGS_32))
>
> to arch/x86/entry/vdso/Makefile would fix the build as well. I have honestly
> no idea which solution is better. :-)
>
>> Could you please show the exact command that's failing with "make V=1"?
>
> gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d -nostdinc -isystem
> /usr/lib/gcc/i686-linux-gnu/6/include -I./arch/x86/include
> -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated
> -I./include -I./arch/x86/include/uapi -I./include/uapi
> -I./include/generated/uapi -include ./include/linux/kconfig.h
> -D__KERNEL__ -D__ASSEMBLY__ -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
> -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
> -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_SHA1_NI=1
> -DCONFIG_AS_SHA256_NI=1 -Wa,-gdwarf-2 -mfentry -DCC_USING_FENTRY
> -DCC_HAVE_ASM_GOTO -DBUILD_VDSO -m32 -c -o
> arch/x86/entry/vdso/vdso32/note.o arch/x86/entry/vdso/vdso32/note.S
>
> Is this file being built with your .config?

Yes, and "-mfentry -DCC_USING_FENTRY" is missing from the gcc
commandline there.  And not only there, although I have
CONFIG_FUNCTION_TRACER=y and CONFIG_HAVE_FENTRY=y, which should cause it
to be added to KBUILD_CFLAGS and KBUILD_AFLAGS.

I don't understand that, but it's late in the evening here.

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-29 12:10 +0200, Tomas Janousek wrote:

> On Mon, Oct 24, 2016 at 07:32:30PM +0200, Sven Joachim wrote:
>> The attached patch works for me with Debian's gcc-6 package.
>
> I tried your patch when building 4.8.5 on an up-to-date Debian testing and
> still got this:
>
>   AS  arch/x86/entry/vdso/vdso32/note.o
> arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry
> isn’t supported for 32-bit in combination with -fpic

I cannot reproduce that, FWIW.  Also, arch/x86/entry/vdso/Makefile seems
to explicitly filter out -mfentry from the compiler flags, but maybe I
misunderstand something.

Could you please show the exact command that's failing with "make V=1"?

> Adding KBUILD_AFLAGS += $(call cc-option,-fno-pie,) helps.
> (Maybe that should be as-option instead. Don't know. There are lots of
> AFLAGS=$(call cc-option, ...) in the Makefiles, anyway.)

This is what Ubuntu is doing, so it works at least for them, I suppose.

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-29 12:10 +0200, Tomas Janousek wrote:

> On Mon, Oct 24, 2016 at 07:32:30PM +0200, Sven Joachim wrote:
>> The attached patch works for me with Debian's gcc-6 package.
>
> I tried your patch when building 4.8.5 on an up-to-date Debian testing and
> still got this:
>
>   AS  arch/x86/entry/vdso/vdso32/note.o
> arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry
> isn’t supported for 32-bit in combination with -fpic

I cannot reproduce that, FWIW.  Also, arch/x86/entry/vdso/Makefile seems
to explicitly filter out -mfentry from the compiler flags, but maybe I
misunderstand something.

Could you please show the exact command that's failing with "make V=1"?

> Adding KBUILD_AFLAGS += $(call cc-option,-fno-pie,) helps.
> (Maybe that should be as-option instead. Don't know. There are lots of
> AFLAGS=$(call cc-option, ...) in the Makefiles, anyway.)

This is what Ubuntu is doing, so it works at least for them, I suppose.

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-25 09:30 +0200, Sebastian Andrzej Siewior wrote:

> On 2016-10-24 19:32:30 [+0200], Sven Joachim wrote:
>> On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:
>> 
>> > On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
>> >> 
>> >> But make still fails with it. :-(
>> >
>> > try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
>> > the resulting kernel built with v3.2 gcc boots & works.
>> 
>> Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
>> assembler errors in arch/x86/entry/entry_32.S.  Maybe binutils 2.15 is
>> not recent enough anymore?

I have done a few more tests, and I can confirm that binutils 2.17 is
the oldest version that works.  Also, I have succeeded installing gcc
3.2 in a Debian 4.0 chroot now.

> so we use stone age gcc but take latest binutils and kernel? What about
> lifting the limit of gcc 3.2?

Would probably make sense, since gcc 3.2 cannot compile kernel/bounds.c,
at least not on x86.

,
|   CC  kernel/bounds.s
| In file included from /tmp/linux/arch/x86/include/asm/bitops.h:512,
|  from include/linux/bitops.h:22,
|  from include/linux/kernel.h:10,
|  from include/asm-generic/bug.h:13,
|  from /tmp/linux/arch/x86/include/asm/bug.h:38,
|  from include/linux/bug.h:4,
|  from include/linux/page-flags.h:9,
|  from kernel/bounds.c:9:
| /tmp/linux/arch/x86/include/asm/arch_hweight.h: In function 
`__arch_hweight32':
| /tmp/linux/arch/x86/include/asm/arch_hweight.h:29: syntax error before string 
constant
| make[1]: *** [kernel/bounds.s] Error 1
`

Building with gcc 3.3 is apparently still possible, although it produces
tons of warnings and a modpost section mismatch.  Still, requiring gcc
4.1 or newer would not be unreasonable, I think (still released a few
months earlier than binutils 2.17).

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-25 09:30 +0200, Sebastian Andrzej Siewior wrote:

> On 2016-10-24 19:32:30 [+0200], Sven Joachim wrote:
>> On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:
>> 
>> > On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
>> >> 
>> >> But make still fails with it. :-(
>> >
>> > try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
>> > the resulting kernel built with v3.2 gcc boots & works.
>> 
>> Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
>> assembler errors in arch/x86/entry/entry_32.S.  Maybe binutils 2.15 is
>> not recent enough anymore?

I have done a few more tests, and I can confirm that binutils 2.17 is
the oldest version that works.  Also, I have succeeded installing gcc
3.2 in a Debian 4.0 chroot now.

> so we use stone age gcc but take latest binutils and kernel? What about
> lifting the limit of gcc 3.2?

Would probably make sense, since gcc 3.2 cannot compile kernel/bounds.c,
at least not on x86.

,
|   CC  kernel/bounds.s
| In file included from /tmp/linux/arch/x86/include/asm/bitops.h:512,
|  from include/linux/bitops.h:22,
|  from include/linux/kernel.h:10,
|  from include/asm-generic/bug.h:13,
|  from /tmp/linux/arch/x86/include/asm/bug.h:38,
|  from include/linux/bug.h:4,
|  from include/linux/page-flags.h:9,
|  from kernel/bounds.c:9:
| /tmp/linux/arch/x86/include/asm/arch_hweight.h: In function 
`__arch_hweight32':
| /tmp/linux/arch/x86/include/asm/arch_hweight.h:29: syntax error before string 
constant
| make[1]: *** [kernel/bounds.s] Error 1
`

Building with gcc 3.3 is apparently still possible, although it produces
tons of warnings and a modpost section mismatch.  Still, requiring gcc
4.1 or newer would not be unreasonable, I think (still released a few
months earlier than binutils 2.17).

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:

> On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
>> 
>> But make still fails with it. :-(
>
> try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
> the resulting kernel built with v3.2 gcc boots & works.

Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
assembler errors in arch/x86/entry/entry_32.S.  Maybe binutils 2.15 is
not recent enough anymore?

Anyway, with CONFIG_CC_STACKPROTECTOR=y it is necessary to add -fno-pie
in scripts/gcc-x86_64-has-stack-protector.sh as well, because that
script invokes the compiler without KBUILD_CFLAGS.  That's probably not
a problem since -fstack-protector is newer than -fno-pie.  The attached
patch works for me with Debian's gcc-6 package.

Cheers,
   Sven

>From 2c72542688476168920c027cdc28c6764387ecac Mon Sep 17 00:00:00 2001
From: Sven Joachim <svenj...@gmx.de>
Date: Mon, 24 Oct 2016 18:17:26 +0200
Subject: [PATCH] kbuild: add -fno-pie to KBUILD_CFLAGS

If GCC is configured with --enable-default-pie, the build fails early
because this default is incompatible with -mcmodel=kernel.

kernel/bounds.c:1:0: error: code model kernel does not support PIC mode

Avoid that by adding -fno-pie to KBUILD_CFLAGS, if supported by the
compiler.  This flag is also needed in the x86_64 stack-protector test
script which otherwise errors out.

Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841420 and
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1574982.

Signed-off-by: Sven Joachim <svenj...@gmx.de>
---
 Makefile  | 1 +
 scripts/gcc-x86_64-has-stack-protector.sh | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 93beca4..81ef816 100644
--- a/Makefile
+++ b/Makefile
@@ -619,6 +619,7 @@ ARCH_AFLAGS :=
 ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
+KBUILD_CFLAGS	+= $(call cc-option,-fno-pie,)
 KBUILD_CFLAGS	+= $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS	+= $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS	+= $(call cc-disable-warning,frame-address,)
diff --git a/scripts/gcc-x86_64-has-stack-protector.sh b/scripts/gcc-x86_64-has-stack-protector.sh
index 973e8c1..274cba1 100755
--- a/scripts/gcc-x86_64-has-stack-protector.sh
+++ b/scripts/gcc-x86_64-has-stack-protector.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 -mcmodel=kernel -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 -mcmodel=kernel -fno-pie -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
 if [ "$?" -eq "0" ] ; then
 	echo y
 else
-- 
2.10.1

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote:

> On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote:
>> 
>> But make still fails with it. :-(
>
> try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if
> the resulting kernel built with v3.2 gcc boots & works.

Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces
assembler errors in arch/x86/entry/entry_32.S.  Maybe binutils 2.15 is
not recent enough anymore?

Anyway, with CONFIG_CC_STACKPROTECTOR=y it is necessary to add -fno-pie
in scripts/gcc-x86_64-has-stack-protector.sh as well, because that
script invokes the compiler without KBUILD_CFLAGS.  That's probably not
a problem since -fstack-protector is newer than -fno-pie.  The attached
patch works for me with Debian's gcc-6 package.

Cheers,
   Sven

>From 2c72542688476168920c027cdc28c6764387ecac Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 24 Oct 2016 18:17:26 +0200
Subject: [PATCH] kbuild: add -fno-pie to KBUILD_CFLAGS

If GCC is configured with --enable-default-pie, the build fails early
because this default is incompatible with -mcmodel=kernel.

kernel/bounds.c:1:0: error: code model kernel does not support PIC mode

Avoid that by adding -fno-pie to KBUILD_CFLAGS, if supported by the
compiler.  This flag is also needed in the x86_64 stack-protector test
script which otherwise errors out.

Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841420 and
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1574982.

Signed-off-by: Sven Joachim 
---
 Makefile  | 1 +
 scripts/gcc-x86_64-has-stack-protector.sh | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 93beca4..81ef816 100644
--- a/Makefile
+++ b/Makefile
@@ -619,6 +619,7 @@ ARCH_AFLAGS :=
 ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
+KBUILD_CFLAGS	+= $(call cc-option,-fno-pie,)
 KBUILD_CFLAGS	+= $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS	+= $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS	+= $(call cc-disable-warning,frame-address,)
diff --git a/scripts/gcc-x86_64-has-stack-protector.sh b/scripts/gcc-x86_64-has-stack-protector.sh
index 973e8c1..274cba1 100755
--- a/scripts/gcc-x86_64-has-stack-protector.sh
+++ b/scripts/gcc-x86_64-has-stack-protector.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 -mcmodel=kernel -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 -mcmodel=kernel -fno-pie -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
 if [ "$?" -eq "0" ] ; then
 	echo y
 else
-- 
2.10.1

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-23 12:23 -0700, Joe Perches wrote:

> On Sun, 2016-10-23 at 18:19 +0200, Sven Joachim wrote:
>> On 2016-10-21 23:21 +0200, Adam Borowski wrote:
>> > On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
>> > > Debian started to build the gcc with --enable-default-pie by default
> []
>> > > diff --git a/Makefile b/Makefile
> []
>> > > @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
>> > >  KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>> > > -fno-strict-aliasing -fno-common \
>> > > -Werror-implicit-function-declaration \
>> > > -   -Wno-format-security \
>> > > +   -Wno-format-security -fno-PIE \
>> > > -std=gnu89
>
> I've used this here instead:
>
> KBUILD_CFLAGS  += $(call cc-option,-fno-pie)

Where exactly do you set that?  I tried this patch:

--8<---cut here---start->8---
diff --git a/Makefile b/Makefile
index 93beca4..fde1e21 100644
--- a/Makefile
+++ b/Makefile
@@ -619,6 +619,7 @@ ARCH_AFLAGS :=
 ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
+KBUILD_CFLAGS  += $(call cc-option,-fno-pie,)
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
--8<---cut here---end--->8---

But make still fails with it. :-(

,
| $ LANG=C make  
| scripts/kconfig/conf  --silentoldconfig Kconfig
|   SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_32_ia32.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_64_x32.h
|   SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_64.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h
|   SYSHDR  
arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h
|   HOSTCC  arch/x86/tools/relocs_32.o
|   HOSTCC  arch/x86/tools/relocs_64.o
|   HOSTCC  arch/x86/tools/relocs_common.o
|   HOSTLD  arch/x86/tools/relocs
|   CHK include/config/kernel.release
|   UPD include/config/kernel.release
| Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong 
available but compiler is broken
| Makefile:1066: recipe for target 'prepare-compiler-check' failed
| make: *** [prepare-compiler-check] Error 1
`

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-23 12:23 -0700, Joe Perches wrote:

> On Sun, 2016-10-23 at 18:19 +0200, Sven Joachim wrote:
>> On 2016-10-21 23:21 +0200, Adam Borowski wrote:
>> > On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
>> > > Debian started to build the gcc with --enable-default-pie by default
> []
>> > > diff --git a/Makefile b/Makefile
> []
>> > > @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
>> > >  KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>> > > -fno-strict-aliasing -fno-common \
>> > > -Werror-implicit-function-declaration \
>> > > -   -Wno-format-security \
>> > > +   -Wno-format-security -fno-PIE \
>> > > -std=gnu89
>
> I've used this here instead:
>
> KBUILD_CFLAGS  += $(call cc-option,-fno-pie)

Where exactly do you set that?  I tried this patch:

--8<---cut here---start->8---
diff --git a/Makefile b/Makefile
index 93beca4..fde1e21 100644
--- a/Makefile
+++ b/Makefile
@@ -619,6 +619,7 @@ ARCH_AFLAGS :=
 ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
+KBUILD_CFLAGS  += $(call cc-option,-fno-pie,)
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
--8<---cut here---end--->8---

But make still fails with it. :-(

,
| $ LANG=C make  
| scripts/kconfig/conf  --silentoldconfig Kconfig
|   SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_32_ia32.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/asm/unistd_64_x32.h
|   SYSTBL  arch/x86/entry/syscalls/../../include/generated/asm/syscalls_64.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_32.h
|   SYSHDR  arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_64.h
|   SYSHDR  
arch/x86/entry/syscalls/../../include/generated/uapi/asm/unistd_x32.h
|   HOSTCC  arch/x86/tools/relocs_32.o
|   HOSTCC  arch/x86/tools/relocs_64.o
|   HOSTCC  arch/x86/tools/relocs_common.o
|   HOSTLD  arch/x86/tools/relocs
|   CHK include/config/kernel.release
|   UPD include/config/kernel.release
| Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong 
available but compiler is broken
| Makefile:1066: recipe for target 'prepare-compiler-check' failed
| make: *** [prepare-compiler-check] Error 1
`

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-21 23:21 +0200, Adam Borowski wrote:

> On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
>> Debian started to build the gcc with --enable-default-pie by default
>
> To be exact: this is since gcc-6 6.2.0-7 dated Tue, 18 Oct 2016 13:53:00 +0200
> on amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x.
>
>> so the kernel build ends before it starts properly with:
>> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>> 
>> Is this okay or do we want some kind of check to see if -fno-PIE is 
>> supported?
>> It is mentioned in the 4.4.7 gcc manpage is it is not *that* new :)
>
> A naive "git log -Sno-PIE" on gcc sources shows commit 3e7f6cce[1] from Feb
> 2004, and as gcc automatically supports no-XXX whenever XXX is added, it
> appears the option is older than that.

Testing on Debian 3.1 (sarge) chroot, it seems that GCC 3.4 is the first
release to accept -fPIE/-fno-PIE.  Which could be a problem since
according to Documentation/Changes GCC 3.2 is sufficient to build the
kernel.

>> Signed-off-by: Sebastian Andrzej Siewior 
>> ---
>>  Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/Makefile b/Makefile
>> index bf6e44a421df..97296d66b586 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
>>  KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>> -fno-strict-aliasing -fno-common \
>> -Werror-implicit-function-declaration \
>> -   -Wno-format-security \
>> +   -Wno-format-security -fno-PIE \
>> -std=gnu89
>>  
>>  KBUILD_AFLAGS_KERNEL :=
>> -- 
>> 2.9.3
>
> The patch works for me.  I haven't done any but most trivial testing,
> though.
>
>
> [1]. Using the https://gcc.gnu.org/git/gcc.git git gateway, commit hashes
> may be different elsewhere.

Cheers,
   Sven

Re: [RFC PATCH] kbuild: add -fno-PIE

[Sven Joachim]

On 2016-10-21 23:21 +0200, Adam Borowski wrote:

> On Fri, Oct 21, 2016 at 01:16:00PM +0200, Sebastian Andrzej Siewior wrote:
>> Debian started to build the gcc with --enable-default-pie by default
>
> To be exact: this is since gcc-6 6.2.0-7 dated Tue, 18 Oct 2016 13:53:00 +0200
> on amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x.
>
>> so the kernel build ends before it starts properly with:
>> |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
>> 
>> Is this okay or do we want some kind of check to see if -fno-PIE is 
>> supported?
>> It is mentioned in the 4.4.7 gcc manpage is it is not *that* new :)
>
> A naive "git log -Sno-PIE" on gcc sources shows commit 3e7f6cce[1] from Feb
> 2004, and as gcc automatically supports no-XXX whenever XXX is added, it
> appears the option is older than that.

Testing on Debian 3.1 (sarge) chroot, it seems that GCC 3.4 is the first
release to accept -fPIE/-fno-PIE.  Which could be a problem since
according to Documentation/Changes GCC 3.2 is sufficient to build the
kernel.

>> Signed-off-by: Sebastian Andrzej Siewior 
>> ---
>>  Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/Makefile b/Makefile
>> index bf6e44a421df..97296d66b586 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -398,7 +398,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
>>  KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>> -fno-strict-aliasing -fno-common \
>> -Werror-implicit-function-declaration \
>> -   -Wno-format-security \
>> +   -Wno-format-security -fno-PIE \
>> -std=gnu89
>>  
>>  KBUILD_AFLAGS_KERNEL :=
>> -- 
>> 2.9.3
>
> The patch works for me.  I haven't done any but most trivial testing,
> though.
>
>
> [1]. Using the https://gcc.gnu.org/git/gcc.git git gateway, commit hashes
> may be different elsewhere.

Cheers,
   Sven

Re: Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Sven Joachim]

On 2016-09-15 11:04 -0400, Jerome Glisse wrote:

>> On Mon, Sep 5, 2016 at 10:25 PM, Jerome Glisse  wrote:
>> >> Recently I got myself a new laptop with the following integrated GPU:
>> >>
>> >> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
>> >> Mullins [Radeon R3 Graphics] (rev 40)
>> >>
>> >> I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
>> >> and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
>> >> newer GPU when hibernating.").
>> >>
>> >> This has already been reported three months ago, but for a much older
>> >> GPU, see the thread starting at
>> >> https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
>> >> The symptoms are exactly the same as described by Boris Petkov in that
>> >> thread: after "systemctl hibernate" the screen goes blank, but the
>> >> machine remains powered on and needs to be power-cycled.
>> >>
>> >> Any suggestions would be welcome.
>> >>
>> >> Cheers,
>> >>Sven
>> >
>> > I guess we can invert the logic and only do it for the GPU for which it fix
>> > hibernation.
>> 
>> Do you remember which asics this fixed?
>> 
>
> No that's the issue, i don't have hw anymore but according to bug it is AMD 
> FirePro
> M5170 and M6170 which would make them amdgpu afaict but i remember the hw was 
> using
> radeon so i am not sure how to figure out what GPU it was really.
>
> Bug https://bugzilla.redhat.com/show_bug.cgi?id=1269009

That bug is not public, unfortunately. :-(

Are there any news on this?  As of Linux 4.8.1, I keep reverting commit
274ad65c9d02, and I'd like not having to do that indefinitely.

Cheers,
   Sven

Re: Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Sven Joachim]

On 2016-09-15 11:04 -0400, Jerome Glisse wrote:

>> On Mon, Sep 5, 2016 at 10:25 PM, Jerome Glisse  wrote:
>> >> Recently I got myself a new laptop with the following integrated GPU:
>> >>
>> >> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
>> >> Mullins [Radeon R3 Graphics] (rev 40)
>> >>
>> >> I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
>> >> and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
>> >> newer GPU when hibernating.").
>> >>
>> >> This has already been reported three months ago, but for a much older
>> >> GPU, see the thread starting at
>> >> https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
>> >> The symptoms are exactly the same as described by Boris Petkov in that
>> >> thread: after "systemctl hibernate" the screen goes blank, but the
>> >> machine remains powered on and needs to be power-cycled.
>> >>
>> >> Any suggestions would be welcome.
>> >>
>> >> Cheers,
>> >>Sven
>> >
>> > I guess we can invert the logic and only do it for the GPU for which it fix
>> > hibernation.
>> 
>> Do you remember which asics this fixed?
>> 
>
> No that's the issue, i don't have hw anymore but according to bug it is AMD 
> FirePro
> M5170 and M6170 which would make them amdgpu afaict but i remember the hw was 
> using
> radeon so i am not sure how to figure out what GPU it was really.
>
> Bug https://bugzilla.redhat.com/show_bug.cgi?id=1269009

That bug is not public, unfortunately. :-(

Are there any news on this?  As of Linux 4.8.1, I keep reverting commit
274ad65c9d02, and I'd like not having to do that indefinitely.

Cheers,
   Sven

Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Sven Joachim]

Recently I got myself a new laptop with the following integrated GPU:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Mullins [Radeon R3 Graphics] (rev 40)

I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
newer GPU when hibernating.").

This has already been reported three months ago, but for a much older
GPU, see the thread starting at
https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
The symptoms are exactly the same as described by Boris Petkov in that
thread: after "systemctl hibernate" the screen goes blank, but the
machine remains powered on and needs to be power-cycled.

Any suggestions would be welcome.

Cheers,
   Sven

Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Sven Joachim]

Recently I got myself a new laptop with the following integrated GPU:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Mullins [Radeon R3 Graphics] (rev 40)

I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
newer GPU when hibernating.").

This has already been reported three months ago, but for a much older
GPU, see the thread starting at
https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
The symptoms are exactly the same as described by Boris Petkov in that
thread: after "systemctl hibernate" the screen goes blank, but the
machine remains powered on and needs to be power-cycled.

Any suggestions would be welcome.

Cheers,
   Sven

Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Sven Joachim]

Recently I got myself a new laptop with the following integrated GPU:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Mullins [Radeon R3 Graphics] (rev 40)

I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
newer GPU when hibernating.").

This has already been reported three months ago, but for a much older
GPU, see the thread starting at
https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
The symptoms are exactly the same as described by Boris Petkov in that
thread: after "systemctl hibernate" the screen goes blank, but the
machine remains powered on and needs to be power-cycled.

Any suggestions would be welcome.

Cheers,
   Sven

Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Sven Joachim]

Recently I got myself a new laptop with the following integrated GPU:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Mullins [Radeon R3 Graphics] (rev 40)

I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
newer GPU when hibernating.").

This has already been reported three months ago, but for a much older
GPU, see the thread starting at
https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
The symptoms are exactly the same as described by Boris Petkov in that
thread: after "systemctl hibernate" the screen goes blank, but the
machine remains powered on and needs to be power-cycled.

Any suggestions would be welcome.

Cheers,
   Sven

Re: CVE-2015-1805 and 3.14-longterm?

[Sven Joachim]

On 2015-08-14 18:55 +0200, Greg KH wrote:

> On Thu, Jul 02, 2015 at 10:19:34AM +0200, Dick Snippe wrote:
>> Hello,
>> 
>> I'm sorry to bother you with this, but lwn.net reported a rather serious
>> security issue a couple of weeks ago:
>> 
>> http://lwn.net/Articles/646590/
>> https://bugzilla.redhat.com/show_bug.cgi?id=1202855
>> CVE-2015-1805
>> "It was found that the Linux kernel's implementation of vectored pipe
>> read and write functionality did not take into account the I/O vectors
>> that were already processed when retrying after a failed atomic access
>> operation, potentially resulting in memory corruption due to an I/O
>> vector array overrun. A local, unprivileged user could use this flaw to
>> crash the system or, potentially, escalate their privileges on the
>> system."
>> 
>> It appears that these upstream fixes haven't made it to 3.14.4[456]:
>> 
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f0d1bec9d58d4c038d0ac958c9af82be6eb18045
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=637b58c2887e5e57850865839cc75f59184b23d1
>> 
>> I'm just a (very happy!) user of the -longterm kernels, so I don't
>> know how this normally works. But it would appear that this bug still
>> exists in the -longterm kernels.
>
> I think, and I might be wrong here, but because
> 637b58c2887e5e57850865839cc75f59184b23d1 (switch pipe_read() to
> copy_page_to_iter()) is not in the 3.14-stable tree (it showed up in
> 3.15), that f0d1bec9d58d4c038d0ac958c9af82be6eb18045 (new helper:
> copy_page_from_iter()) isn't needed (it showed up in 3.16).
>
> So is this a problem in the 3.14-stable tree?

It seems to have been fixed by 6b17faf3d5fa6a727c40613bdf24d73b2a59df27
(pipe: iovec: Fix memory corruption when retrying atomic copy as
non-atomic) in 3.14.46.  That fix is also in 3.10.82.

Cheers,
   Sven
--
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: CVE-2015-1805 and 3.14-longterm?

[Sven Joachim]

On 2015-08-14 18:55 +0200, Greg KH wrote:

 On Thu, Jul 02, 2015 at 10:19:34AM +0200, Dick Snippe wrote:
 Hello,
 
 I'm sorry to bother you with this, but lwn.net reported a rather serious
 security issue a couple of weeks ago:
 
 http://lwn.net/Articles/646590/
 https://bugzilla.redhat.com/show_bug.cgi?id=1202855
 CVE-2015-1805
 It was found that the Linux kernel's implementation of vectored pipe
 read and write functionality did not take into account the I/O vectors
 that were already processed when retrying after a failed atomic access
 operation, potentially resulting in memory corruption due to an I/O
 vector array overrun. A local, unprivileged user could use this flaw to
 crash the system or, potentially, escalate their privileges on the
 system.
 
 It appears that these upstream fixes haven't made it to 3.14.4[456]:
 
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f0d1bec9d58d4c038d0ac958c9af82be6eb18045
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=637b58c2887e5e57850865839cc75f59184b23d1
 
 I'm just a (very happy!) user of the -longterm kernels, so I don't
 know how this normally works. But it would appear that this bug still
 exists in the -longterm kernels.

 I think, and I might be wrong here, but because
 637b58c2887e5e57850865839cc75f59184b23d1 (switch pipe_read() to
 copy_page_to_iter()) is not in the 3.14-stable tree (it showed up in
 3.15), that f0d1bec9d58d4c038d0ac958c9af82be6eb18045 (new helper:
 copy_page_from_iter()) isn't needed (it showed up in 3.16).

 So is this a problem in the 3.14-stable tree?

It seems to have been fixed by 6b17faf3d5fa6a727c40613bdf24d73b2a59df27
(pipe: iovec: Fix memory corruption when retrying atomic copy as
non-atomic) in 3.14.46.  That fix is also in 3.10.82.

Cheers,
   Sven
--
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: Getting new udev to run with 2.6.28

[Sven Joachim]

On 2015-01-10 19:09 +0100, Pavel Machek wrote:

> I was hoping someone has devtmpfs patches I could just apply over
> 2.6.28 and get a working system?

IIRC the udev version in Debian 7 does not require devtmpfs (that became
mandatory only in udev 176), but kernel 2.6.32 or higher is required for
other reasons.  See commit 67a77c8bf299f6264f001677becd056316ebce2f in
udev[1].

Cheers,
   Sven


1. 
https://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=67a77c8bf299f6264f001677becd056316ebce2f
--
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: Getting new udev to run with 2.6.28

[Sven Joachim]

On 2015-01-10 19:09 +0100, Pavel Machek wrote:

 I was hoping someone has devtmpfs patches I could just apply over
 2.6.28 and get a working system?

IIRC the udev version in Debian 7 does not require devtmpfs (that became
mandatory only in udev 176), but kernel 2.6.32 or higher is required for
other reasons.  See commit 67a77c8bf299f6264f001677becd056316ebce2f in
udev[1].

Cheers,
   Sven


1. 
https://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=67a77c8bf299f6264f001677becd056316ebce2f
--
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: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Sven Joachim]

On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:

> On 05/07/2014 09:57 AM, Linus Torvalds wrote:
>> 
>> Afaik, 16-bit programs under wine already need
>> 
>>   echo 0 > /proc/sys/vm/mmap_min_addr
>> 
>> because they want to map things at address 0, so this isn't a new concept.
>> 
>
> I think that applies to DOSEMU, but not to Wine.

DOSEMU does no longer need it either.  If vm.mmap_min_addr is > 0, it
turns on CPU emulation, which it has to use anyway due to lack of vm86
mode.

> Sven: if you have the ability to build your own kernel, could you also
> try the "x86/espfix" branch of the git tree:
>
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/
>
> (clone URLs:)
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>
> ... to make sure the proper solution works for you?

Works fine here, thanks.

> I'm somewhat curious if this program you have is actually a 32-bit
> program or if it is really a 16-bit program wrapped in a 32-bit
> installer of some kind.  Hard to know without seeing the program in
> question.

The main application (a chess database program) is 32-bit, but it comes
with several 16-bit analysis engines that are loaded on startup (I see
them in lsof output), so that's the situation described by Alexandre.

Cheers,
   Sven
--
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: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Sven Joachim]

On 2014-05-07 19:09 +0200, H. Peter Anvin wrote:

 On 05/07/2014 09:57 AM, Linus Torvalds wrote:
 
 Afaik, 16-bit programs under wine already need
 
   echo 0  /proc/sys/vm/mmap_min_addr
 
 because they want to map things at address 0, so this isn't a new concept.
 

 I think that applies to DOSEMU, but not to Wine.

DOSEMU does no longer need it either.  If vm.mmap_min_addr is  0, it
turns on CPU emulation, which it has to use anyway due to lack of vm86
mode.

 Sven: if you have the ability to build your own kernel, could you also
 try the x86/espfix branch of the git tree:

 https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/

 (clone URLs:)
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

 ... to make sure the proper solution works for you?

Works fine here, thanks.

 I'm somewhat curious if this program you have is actually a 32-bit
 program or if it is really a 16-bit program wrapped in a 32-bit
 installer of some kind.  Hard to know without seeing the program in
 question.

The main application (a chess database program) is 32-bit, but it comes
with several 16-bit analysis engines that are loaded on startup (I see
them in lsof output), so that's the situation described by Alexandre.

Cheers,
   Sven
--
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: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Sven Joachim]

On 2014-04-14 09:48 +0200, Alexandre Julliard wrote:

> Linus Torvalds  writes:
>
>> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst  wrote:
>>>
>>> I haven't tested it recently but I do know it has worked on 64-bit
>>> kernels.  There is no reason for it not to, the only thing not
>>> supported in long mode is vm86.  16-bit protected mode is unchanged.
>>
>> Afaik 64-bit windows doesn't support 16-bit binaries, so I just
>> assumed Wine wouldn't do it either on x86-64. Not for any real
>> technical reasons, though.
>>
>> HOWEVER. I'd like to hear something more definitive than "I haven't
>> tested recently". The "we don't break user space" is about having
>> actual real *users*, not about test programs.
>>
>> Are there people actually using 16-bit old windows programs under
>> wine? That's what matters.

It seems that at least some 32-bit programs are also broken, since after
upgrading the kernel to 3.14.3 I can no longer start my old chess
database program:

,
| % file CB70.exe 
| CB70.exe: PE32 executable (GUI) Intel 80386, for MS Windows
| % LANG=C wine CB70.exe
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
`

And here it just hangs, with wineboot.exe taking 100% CPU.  I had to
kill first wineboot.exe and then CB70.exe. :-(

> Yes, there is still a significant number of users, and we still
> regularly get bug reports about specific 16-bit apps. It would be really
> nice if we could continue to support them on x86-64, particularly since
> Microsoft doesn't ;-)

I would rather not set up a virtual machine just for wine (I don't have
Windows anymore).

Cheers,
   Sven
--
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: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Sven Joachim]

On 2014-04-14 09:48 +0200, Alexandre Julliard wrote:

 Linus Torvalds torva...@linux-foundation.org writes:

 On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst brge...@gmail.com wrote:

 I haven't tested it recently but I do know it has worked on 64-bit
 kernels.  There is no reason for it not to, the only thing not
 supported in long mode is vm86.  16-bit protected mode is unchanged.

 Afaik 64-bit windows doesn't support 16-bit binaries, so I just
 assumed Wine wouldn't do it either on x86-64. Not for any real
 technical reasons, though.

 HOWEVER. I'd like to hear something more definitive than I haven't
 tested recently. The we don't break user space is about having
 actual real *users*, not about test programs.

 Are there people actually using 16-bit old windows programs under
 wine? That's what matters.

It seems that at least some 32-bit programs are also broken, since after
upgrading the kernel to 3.14.3 I can no longer start my old chess
database program:

,
| % file CB70.exe 
| CB70.exe: PE32 executable (GUI) Intel 80386, for MS Windows
| % LANG=C wine CB70.exe
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
`

And here it just hangs, with wineboot.exe taking 100% CPU.  I had to
kill first wineboot.exe and then CB70.exe. :-(

 Yes, there is still a significant number of users, and we still
 regularly get bug reports about specific 16-bit apps. It would be really
 nice if we could continue to support them on x86-64, particularly since
 Microsoft doesn't ;-)

I would rather not set up a virtual machine just for wine (I don't have
Windows anymore).

Cheers,
   Sven
--
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: [ 005/117] drm/i915: make user mode sync polarity setting explicit

[Sven Joachim]

On 2013-09-25 02:17 +0200, Greg Kroah-Hartman wrote:

> 3.11-stable review patch.  If anyone has any objections, please let me know.

Sorry for being a bit late, I was traveling last week and only upgraded
my kernel yesterday.

> From: Imre Deak 
>
> commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0 upstream.
>
> Userspace can pass a mode with an unspecified vsync/hsync polarity
> setting. All encoders in the Intel driver take this to mean a negative
> polarity setting. The HW readout/state checker code on the other hand
> needs these flags to be explicitly set, otherwise the state checker will
> WARN about the mismatch.
>
> Get rid of the WARN by making the polarity setting explicit in the
> adjusted mode flags based on the requested mode flags. This will keep
> the existing behavior otherwise.
>
> Note that we could guess from the other timing parameters whether the
> user wanted a VESA or other standard mode and set the polarity
> accordingly. This is what the NV driver does
> (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
> exact and would change the existing behavior of the Intel driver.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442
> Signed-off-by: Imre Deak 
> Tested-by: cancan,feng 
> Reviewed-by: Chris Wilson 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Greg Kroah-Hartman 
>
> ---
>  drivers/gpu/drm/i915/intel_display.c |   13 +
>  1 file changed, 13 insertions(+)
>
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7809,6 +7809,19 @@ intel_modeset_pipe_config(struct drm_crt
>   pipe_config->cpu_transcoder = to_intel_crtc(crtc)->pipe;
>   pipe_config->shared_dpll = DPLL_ID_PRIVATE;
>  
> + /*
> +  * Sanitize sync polarity flags based on requested ones. If neither
> +  * positive or negative polarity is requested, treat this as meaning
> +  * negative polarity.
> +  */
> + if (!(pipe_config->adjusted_mode.flags &
> +   (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC)))
> + pipe_config->adjusted_mode.flags |= DRM_MODE_FLAG_NHSYNC;
> +
> + if (!(pipe_config->adjusted_mode.flags &
> +   (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC)))
> + pipe_config->adjusted_mode.flags |= DRM_MODE_FLAG_NVSYNC;
> +
>   /* Compute a starting value for pipe_config->pipe_bpp taking the source
>* plane pixel format and any sink constraints into account. Returns the
>* source plane bpp so that dithering can be selected on mismatches

After this patch I'm getting a drm error message on my laptop:

,
| [0.840472] [drm:intel_pipe_config_compare] *ERROR* mismatch in 
adjusted_mode.flags (expected 2, found 0)
| [0.840533] [ cut here ]
| [0.840583] WARNING: CPU: 0 PID: 66 at 
drivers/gpu/drm/i915/intel_display.c:8292 check_crtc_state+0x5f4/0x64a [i915]()
| [0.840585] pipe state doesn't match!
| [0.840587] Modules linked in: b44(+) mii sg sr_mod cdrom ssb ehci_pci(+) 
uhci_hcd ehci_hcd usbcore i915(+) cfbfillrect cfbimgblt video backlight 
usb_common thermal i2c_algo_bit cfbcopyarea drm_kms_helper drm button i2c_core
| [0.840610] CPU: 0 PID: 66 Comm: modprobe Not tainted 3.11.3-kms #1
| [0.840613] Hardware name: Acer TravelMate 2490 /Grapevine, 
BIOS V3.00 10/17/2006
| [0.840616]   ddabb884 c101d20e 2064 e011e074 ddbcc000 
dd9ca400 ddacc000
| [0.840622]  ddabb89c c101d249 0009 ddabb894 e01553ed ddabb8b0 
ddabbaf0 e011e074
| [0.840627]  e0154612 2064 e01553ed dd9ca66c ddbcc640 ddacc000 
000a c1340bfc
| [0.840633] Call Trace:
| [0.840643]  [] ? warn_slowpath_common+0x5e/0x73
| [0.840680]  [] ? check_crtc_state+0x5f4/0x64a [i915]
| [0.840685]  [] ? warn_slowpath_fmt+0x26/0x2a
| [0.840721]  [] ? check_crtc_state+0x5f4/0x64a [i915]
| [0.840765]  [] ? intel_modeset_check_state+0x305/0x54d [i915]
| [0.840803]  [] ? intel_set_mode+0x21/0x2a [i915]
| [0.840841]  [] ? intel_get_load_detect_pipe+0x295/0x2e9 [i915]
| [0.840884]  [] ? intel_tv_detect+0xc6/0x3b1 [i915]
| [0.840893]  [] ? 
drm_helper_probe_single_connector_modes+0x97/0x265 [drm_kms_helper]
| [0.840900]  [] ? drm_fb_helper_probe_connector_modes+0x32/0x40 
[drm_kms_helper]
| [0.840907]  [] ? drm_fb_helper_initial_config+0x148/0x3a9 
[drm_kms_helper]
| [0.840940]  [] ? i915_driver_load+0x912/0xa60 [i915]
| [0.840959]  [] ? drm_get_pci_dev+0x12e/0x20e [drm]
| [0.840966]  [] ? pci_device_probe+0x4c/0x83
| [0.840974]  [] ? driver_probe_device+0x7b/0x16d
| [0.840979]  [] ? __driver_attach+0x44/0x5f
| [0.840984]  [] ? bus_for_each_dev+0x50/0x5a
| [0.840988]  [] ? driver_attach+0x14/0x17
| [0.840993]  [] ? __device_attach+0x28/0x28
| [0.840997]  [] ? bus_add_driver+0xc1/0x1b6
| [0.841002]  [] ? driver_register+0x70/0xc9
| [0.841006]  [] ? 0xe0168fff
| [0.841011]  [] ? do_one_initcall+0x6a/0xdf
| [ 

Re: [ 005/117] drm/i915: make user mode sync polarity setting explicit

[Sven Joachim]

On 2013-09-25 02:17 +0200, Greg Kroah-Hartman wrote:

 3.11-stable review patch.  If anyone has any objections, please let me know.

Sorry for being a bit late, I was traveling last week and only upgraded
my kernel yesterday.

 From: Imre Deak imre.d...@intel.com

 commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0 upstream.

 Userspace can pass a mode with an unspecified vsync/hsync polarity
 setting. All encoders in the Intel driver take this to mean a negative
 polarity setting. The HW readout/state checker code on the other hand
 needs these flags to be explicitly set, otherwise the state checker will
 WARN about the mismatch.

 Get rid of the WARN by making the polarity setting explicit in the
 adjusted mode flags based on the requested mode flags. This will keep
 the existing behavior otherwise.

 Note that we could guess from the other timing parameters whether the
 user wanted a VESA or other standard mode and set the polarity
 accordingly. This is what the NV driver does
 (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
 exact and would change the existing behavior of the Intel driver.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442
 Signed-off-by: Imre Deak imre.d...@intel.com
 Tested-by: cancan,feng cancan.f...@intel.com
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

 ---
  drivers/gpu/drm/i915/intel_display.c |   13 +
  1 file changed, 13 insertions(+)

 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -7809,6 +7809,19 @@ intel_modeset_pipe_config(struct drm_crt
   pipe_config-cpu_transcoder = to_intel_crtc(crtc)-pipe;
   pipe_config-shared_dpll = DPLL_ID_PRIVATE;
  
 + /*
 +  * Sanitize sync polarity flags based on requested ones. If neither
 +  * positive or negative polarity is requested, treat this as meaning
 +  * negative polarity.
 +  */
 + if (!(pipe_config-adjusted_mode.flags 
 +   (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC)))
 + pipe_config-adjusted_mode.flags |= DRM_MODE_FLAG_NHSYNC;
 +
 + if (!(pipe_config-adjusted_mode.flags 
 +   (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC)))
 + pipe_config-adjusted_mode.flags |= DRM_MODE_FLAG_NVSYNC;
 +
   /* Compute a starting value for pipe_config-pipe_bpp taking the source
* plane pixel format and any sink constraints into account. Returns the
* source plane bpp so that dithering can be selected on mismatches

After this patch I'm getting a drm error message on my laptop:

,
| [0.840472] [drm:intel_pipe_config_compare] *ERROR* mismatch in 
adjusted_mode.flags (expected 2, found 0)
| [0.840533] [ cut here ]
| [0.840583] WARNING: CPU: 0 PID: 66 at 
drivers/gpu/drm/i915/intel_display.c:8292 check_crtc_state+0x5f4/0x64a [i915]()
| [0.840585] pipe state doesn't match!
| [0.840587] Modules linked in: b44(+) mii sg sr_mod cdrom ssb ehci_pci(+) 
uhci_hcd ehci_hcd usbcore i915(+) cfbfillrect cfbimgblt video backlight 
usb_common thermal i2c_algo_bit cfbcopyarea drm_kms_helper drm button i2c_core
| [0.840610] CPU: 0 PID: 66 Comm: modprobe Not tainted 3.11.3-kms #1
| [0.840613] Hardware name: Acer TravelMate 2490 /Grapevine, 
BIOS V3.00 10/17/2006
| [0.840616]   ddabb884 c101d20e 2064 e011e074 ddbcc000 
dd9ca400 ddacc000
| [0.840622]  ddabb89c c101d249 0009 ddabb894 e01553ed ddabb8b0 
ddabbaf0 e011e074
| [0.840627]  e0154612 2064 e01553ed dd9ca66c ddbcc640 ddacc000 
000a c1340bfc
| [0.840633] Call Trace:
| [0.840643]  [c101d20e] ? warn_slowpath_common+0x5e/0x73
| [0.840680]  [e011e074] ? check_crtc_state+0x5f4/0x64a [i915]
| [0.840685]  [c101d249] ? warn_slowpath_fmt+0x26/0x2a
| [0.840721]  [e011e074] ? check_crtc_state+0x5f4/0x64a [i915]
| [0.840765]  [e0126d2a] ? intel_modeset_check_state+0x305/0x54d [i915]
| [0.840803]  [e0126fe0] ? intel_set_mode+0x21/0x2a [i915]
| [0.840841]  [e0127d13] ? intel_get_load_detect_pipe+0x295/0x2e9 [i915]
| [0.840884]  [e013ef89] ? intel_tv_detect+0xc6/0x3b1 [i915]
| [0.840893]  [dfef84c4] ? 
drm_helper_probe_single_connector_modes+0x97/0x265 [drm_kms_helper]
| [0.840900]  [dfef6260] ? drm_fb_helper_probe_connector_modes+0x32/0x40 
[drm_kms_helper]
| [0.840907]  [dfef76b9] ? drm_fb_helper_initial_config+0x148/0x3a9 
[drm_kms_helper]
| [0.840940]  [e010b6e1] ? i915_driver_load+0x912/0xa60 [i915]
| [0.840959]  [dff890b9] ? drm_get_pci_dev+0x12e/0x20e [drm]
| [0.840966]  [c1129620] ? pci_device_probe+0x4c/0x83
| [0.840974]  [c118bdf1] ? driver_probe_device+0x7b/0x16d
| [0.840979]  [c118bf4f] ? __driver_attach+0x44/0x5f
| [0.840984]  [c118ac13] ? bus_for_each_dev+0x50/0x5a
| [0.840988]  [c118ba8a] ? driver_attach+0x14/0x17
| [0.840993]  

Re: [ 00/72] 3.10.2-stable review

[Sven Joachim]

On 2013-07-19 07:25 +0200, Greg Kroah-Hartman wrote:

> This is the start of the stable review cycle for the 3.10.2 release.
> There are 72 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Jul 21 05:25:08 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.2-rc1.gz

I've spent just half an hour trying to figure out why this kernel failed
to install with an incomprehensible error message:

,
|  BUILDDEB
| rm: invalid option -- 'c'
| Try `rm --help' for more information.
| make[2]: *** [_modinst_] Error 1
`

It turned out that there's a trailing space in the 

SUBLEVEL = 2 

line in the Makefile, and that extra space ends up in MODLIB, finally
passing the 'rm' command _two_ parameters rather than one, the second
starting with "-rc1".

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

Re: [ 00/72] 3.10.2-stable review

[Sven Joachim]

On 2013-07-19 07:25 +0200, Greg Kroah-Hartman wrote:

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

 Responses should be made by Sun Jul 21 05:25:08 UTC 2013.
 Anything received after that time might be too late.

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

I've spent just half an hour trying to figure out why this kernel failed
to install with an incomprehensible error message:

,
|  BUILDDEB
| rm: invalid option -- 'c'
| Try `rm --help' for more information.
| make[2]: *** [_modinst_] Error 1
`

It turned out that there's a trailing space in the 

SUBLEVEL = 2 

line in the Makefile, and that extra space ends up in MODLIB, finally
passing the 'rm' command _two_ parameters rather than one, the second
starting with -rc1.

Cheers,
   Sven
--
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: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL

[Sven Joachim]

On 2013-04-03 16:00 +0200, Eric Dumazet wrote:

> On Wed, 2013-04-03 at 13:41 +0200, Sven Joachim wrote:
>> On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote:
>> 
>> > 3.8-stable review patch.  If anyone has any objections, please let me know.
>> 
>> I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and
>> 3.9-rc5: "udevd[56]: sender uid=65534, message ignored".  Reverting the
>> patch below on top of 3.8.6-rc1 fixes that.  I'm using udev version 175
>> here, and 65534 is the uid of user "nobody".
>
> And if you use a 3.1 kernel (before commit
> 16e5726269611b71c930054ffe9b858c1cea88eb) are you seeing this message ?

No (tested with 3.1.10).

> It might be a wrong sender (application bug or bad identity), and udevd
> correctly discards the incoming message.

How would I find out the culprit?

Cheers,
   Sven
--
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: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL

[Sven Joachim]

On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote:

> 3.8-stable review patch.  If anyone has any objections, please let me know.

I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and
3.9-rc5: "udevd[56]: sender uid=65534, message ignored".  Reverting the
patch below on top of 3.8.6-rc1 fixes that.  I'm using udev version 175
here, and 65534 is the uid of user "nobody".

Cheers,
   Sven


> From: dingtianhong 
>
> [ Upstream commit 14134f6584212d585b310ce95428014b653dfaf6 ]
>
> SCM_SCREDENTIALS should apply to write() syscalls only either source or 
> destination
> socket asserted SOCK_PASSCRED. The original implememtation in maybe_add_creds 
> is wrong,
> and breaks several LSB testcases ( i.e. 
> /tset/LSB.os/netowkr/recvfrom/T.recvfrom).
>
> Origionally-authored-by: Karel Srot 
> Signed-off-by: Ding Tianhong 
> Acked-by: Eric Dumazet 
> Signed-off-by: David S. Miller 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  net/unix/af_unix.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1414,8 +1414,8 @@ static void maybe_add_creds(struct sk_bu
>   if (UNIXCB(skb).cred)
>   return;
>   if (test_bit(SOCK_PASSCRED, >flags) ||
> - !other->sk_socket ||
> - test_bit(SOCK_PASSCRED, >sk_socket->flags)) {
> + (other->sk_socket &&
> + test_bit(SOCK_PASSCRED, >sk_socket->flags))) {
>   UNIXCB(skb).pid  = get_pid(task_tgid(current));
>   UNIXCB(skb).cred = get_current_cred();
>   }
--
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: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL

[Sven Joachim]

On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote:

 3.8-stable review patch.  If anyone has any objections, please let me know.

I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and
3.9-rc5: udevd[56]: sender uid=65534, message ignored.  Reverting the
patch below on top of 3.8.6-rc1 fixes that.  I'm using udev version 175
here, and 65534 is the uid of user nobody.

Cheers,
   Sven


 From: dingtianhong dingtianh...@huawei.com

 [ Upstream commit 14134f6584212d585b310ce95428014b653dfaf6 ]

 SCM_SCREDENTIALS should apply to write() syscalls only either source or 
 destination
 socket asserted SOCK_PASSCRED. The original implememtation in maybe_add_creds 
 is wrong,
 and breaks several LSB testcases ( i.e. 
 /tset/LSB.os/netowkr/recvfrom/T.recvfrom).

 Origionally-authored-by: Karel Srot ks...@redhat.com
 Signed-off-by: Ding Tianhong dingtianh...@huawei.com
 Acked-by: Eric Dumazet eduma...@google.com
 Signed-off-by: David S. Miller da...@davemloft.net
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 ---
  net/unix/af_unix.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 --- a/net/unix/af_unix.c
 +++ b/net/unix/af_unix.c
 @@ -1414,8 +1414,8 @@ static void maybe_add_creds(struct sk_bu
   if (UNIXCB(skb).cred)
   return;
   if (test_bit(SOCK_PASSCRED, sock-flags) ||
 - !other-sk_socket ||
 - test_bit(SOCK_PASSCRED, other-sk_socket-flags)) {
 + (other-sk_socket 
 + test_bit(SOCK_PASSCRED, other-sk_socket-flags))) {
   UNIXCB(skb).pid  = get_pid(task_tgid(current));
   UNIXCB(skb).cred = get_current_cred();
   }
--
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: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL

[Sven Joachim]

On 2013-04-03 16:00 +0200, Eric Dumazet wrote:

 On Wed, 2013-04-03 at 13:41 +0200, Sven Joachim wrote:
 On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote:
 
  3.8-stable review patch.  If anyone has any objections, please let me know.
 
 I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and
 3.9-rc5: udevd[56]: sender uid=65534, message ignored.  Reverting the
 patch below on top of 3.8.6-rc1 fixes that.  I'm using udev version 175
 here, and 65534 is the uid of user nobody.

 And if you use a 3.1 kernel (before commit
 16e5726269611b71c930054ffe9b858c1cea88eb) are you seeing this message ?

No (tested with 3.1.10).

 It might be a wrong sender (application bug or bad identity), and udevd
 correctly discards the incoming message.

How would I find out the culprit?

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-20 21:08 +0100, Greg Kroah-Hartman wrote:

> On Tue, Mar 19, 2013 at 10:44:30PM +0100, Sven Joachim wrote:
>> On 2013-03-19 22:00 +0100, Alan Stern wrote:
>> 
>> > On Tue, 19 Mar 2013, Sven Joachim wrote:
>> >
>> >> On 2013-03-19 21:10 +0100, Alan Stern wrote:
>> >> 
>> >> > On Tue, 19 Mar 2013, Sven Joachim wrote:
>> >> >
>> >> >> > In what way is resume broken?
>> >> >> 
>> >> >> The kernel comes back, but the screen is black.  Manually switching 
>> >> >> VT's
>> >> >> is possible, and if I type something I can see it on the screen, but
>> >> >> there is no response and the cursor does not blink.  It looks as if the
>> >> >> VT is not switched backed on resume, and userspace tasks are not
>> >> >> restarted.  Sysrq combinations apparently work, but produce no output.
>> >> >
>> >> > Are there any other problems?  For example, even before you do a 
>> >> > suspend, if you type Alt-SysRq-W do you see any processes listed?
>> >> 
>> >> No.
>> >> 
>> >> > There was another report on the linux-usb mailing list today of this
>> >> > same patch causing the khubd task to hang.  I'm thinking that you might
>> >> > be facing a similar problem.
>> >> 
>> >> Maybe, but before the suspend everything seems to be normal.
>> >
>> > Just out of curiosity, does the patch posted here:
>> >
>> >http://marc.info/?l=linux-usb=136361874807411=2
>> >
>> > make any difference?
>> 
>> It fixes the problem for me, thanks. :-)
>
> Ok, I'll postpone this patch for the next stable release, in time for
> the fix to be put in at the same time.

I think patch 13/75 ("USB: EHCI: dont check DMA values in QH overlays")
should also be postponed then, at least Alan said so in
.

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-20 21:08 +0100, Greg Kroah-Hartman wrote:

 On Tue, Mar 19, 2013 at 10:44:30PM +0100, Sven Joachim wrote:
 On 2013-03-19 22:00 +0100, Alan Stern wrote:
 
  On Tue, 19 Mar 2013, Sven Joachim wrote:
 
  On 2013-03-19 21:10 +0100, Alan Stern wrote:
  
   On Tue, 19 Mar 2013, Sven Joachim wrote:
  
In what way is resume broken?
   
   The kernel comes back, but the screen is black.  Manually switching 
   VT's
   is possible, and if I type something I can see it on the screen, but
   there is no response and the cursor does not blink.  It looks as if the
   VT is not switched backed on resume, and userspace tasks are not
   restarted.  Sysrq combinations apparently work, but produce no output.
  
   Are there any other problems?  For example, even before you do a 
   suspend, if you type Alt-SysRq-W do you see any processes listed?
  
  No.
  
   There was another report on the linux-usb mailing list today of this
   same patch causing the khubd task to hang.  I'm thinking that you might
   be facing a similar problem.
  
  Maybe, but before the suspend everything seems to be normal.
 
  Just out of curiosity, does the patch posted here:
 
 http://marc.info/?l=linux-usbm=136361874807411w=2
 
  make any difference?
 
 It fixes the problem for me, thanks. :-)

 Ok, I'll postpone this patch for the next stable release, in time for
 the fix to be put in at the same time.

I think patch 13/75 (USB: EHCI: dont check DMA values in QH overlays)
should also be postponed then, at least Alan said so in
pine.lnx.4.44l0.1303191125100.15684-100...@netrider.rowland.org.

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-19 22:00 +0100, Alan Stern wrote:

> On Tue, 19 Mar 2013, Sven Joachim wrote:
>
>> On 2013-03-19 21:10 +0100, Alan Stern wrote:
>> 
>> > On Tue, 19 Mar 2013, Sven Joachim wrote:
>> >
>> >> > In what way is resume broken?
>> >> 
>> >> The kernel comes back, but the screen is black.  Manually switching VT's
>> >> is possible, and if I type something I can see it on the screen, but
>> >> there is no response and the cursor does not blink.  It looks as if the
>> >> VT is not switched backed on resume, and userspace tasks are not
>> >> restarted.  Sysrq combinations apparently work, but produce no output.
>> >
>> > Are there any other problems?  For example, even before you do a 
>> > suspend, if you type Alt-SysRq-W do you see any processes listed?
>> 
>> No.
>> 
>> > There was another report on the linux-usb mailing list today of this
>> > same patch causing the khubd task to hang.  I'm thinking that you might
>> > be facing a similar problem.
>> 
>> Maybe, but before the suspend everything seems to be normal.
>
> Just out of curiosity, does the patch posted here:
>
>   http://marc.info/?l=linux-usb=136361874807411=2
>
> make any difference?

It fixes the problem for me, thanks. :-)

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-19 21:10 +0100, Alan Stern wrote:

> On Tue, 19 Mar 2013, Sven Joachim wrote:
>
>> > In what way is resume broken?
>> 
>> The kernel comes back, but the screen is black.  Manually switching VT's
>> is possible, and if I type something I can see it on the screen, but
>> there is no response and the cursor does not blink.  It looks as if the
>> VT is not switched backed on resume, and userspace tasks are not
>> restarted.  Sysrq combinations apparently work, but produce no output.
>
> Are there any other problems?  For example, even before you do a 
> suspend, if you type Alt-SysRq-W do you see any processes listed?

No.

> There was another report on the linux-usb mailing list today of this
> same patch causing the khubd task to hang.  I'm thinking that you might
> be facing a similar problem.

Maybe, but before the suspend everything seems to be normal.

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-19 19:17 +0100, Alan Stern wrote:

> On Tue, 19 Mar 2013, Sven Joachim wrote:
>
>> On 2013-03-18 22:06 +0100, Greg Kroah-Hartman wrote:
>> 
>> > 3.8-stable review patch.  If anyone has any objections, please let me know.
>> 
>> This patch breaks resume from suspend on my system if the following
>> device is plugged in:
>> 
>> ,
>> | $ lsusb | head -n1
>> | Bus 005 Device 002: ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless 
>> Adapter(rev.C1) [Ralink RT2571W]
>> `
>> 
>> The same problem exists in 3.9-rc3, FWIW.
>> 
>> Detailed lsusb output follows, I'll be happy to provide more information
>> if needed.
>
> In what way is resume broken?

The kernel comes back, but the screen is black.  Manually switching VT's
is possible, and if I type something I can see it on the screen, but
there is no response and the cursor does not blink.  It looks as if the
VT is not switched backed on resume, and userspace tasks are not
restarted.  Sysrq combinations apparently work, but produce no output.

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-18 22:06 +0100, Greg Kroah-Hartman wrote:

> 3.8-stable review patch.  If anyone has any objections, please let me know.

This patch breaks resume from suspend on my system if the following
device is plugged in:

,
| $ lsusb | head -n1
| Bus 005 Device 002: ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless 
Adapter(rev.C1) [Ralink RT2571W]
`

The same problem exists in 3.9-rc3, FWIW.

Detailed lsusb output follows, I'll be happy to provide more information
if needed.

,
| # lsusb -s 005: -v
| Bus 005 Device 002: ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless 
Adapter(rev.C1) [Ralink RT2571W]
| Device Descriptor:
|   bLength18
|   bDescriptorType 1
|   bcdUSB   2.00
|   bDeviceClass0 (Defined at Interface level)
|   bDeviceSubClass 0 
|   bDeviceProtocol 0 
|   bMaxPacketSize064
|   idVendor   0x07d1 D-Link System
|   idProduct  0x3c03 AirPlus G DWL-G122 Wireless Adapter(rev.C1) 
[Ralink RT2571W]
|   bcdDevice0.01
|   iManufacturer   1 Ralink
|   iProduct2 802.11 bg WLAN
|   iSerial 0 
|   bNumConfigurations  1
|   Configuration Descriptor:
| bLength 9
| bDescriptorType 2
| wTotalLength   32
| bNumInterfaces  1
| bConfigurationValue 1
| iConfiguration  0 
| bmAttributes 0x80
|   (Bus Powered)
| MaxPower  300mA
| Interface Descriptor:
|   bLength 9
|   bDescriptorType 4
|   bInterfaceNumber0
|   bAlternateSetting   0
|   bNumEndpoints   2
|   bInterfaceClass   255 Vendor Specific Class
|   bInterfaceSubClass255 Vendor Specific Subclass
|   bInterfaceProtocol255 Vendor Specific Protocol
|   iInterface  0 
|   Endpoint Descriptor:
| bLength 7
| bDescriptorType 5
| bEndpointAddress 0x81  EP 1 IN
| bmAttributes2
|   Transfer TypeBulk
|   Synch Type   None
|   Usage Type   Data
| wMaxPacketSize 0x0200  1x 512 bytes
| bInterval   0
|   Endpoint Descriptor:
| bLength 7
| bDescriptorType 5
| bEndpointAddress 0x01  EP 1 OUT
| bmAttributes2
|   Transfer TypeBulk
|   Synch Type   None
|   Usage Type   Data
| wMaxPacketSize 0x0200  1x 512 bytes
| bInterval   0
| Device Qualifier (for other device speed):
|   bLength10
|   bDescriptorType 6
|   bcdUSB   2.00
|   bDeviceClass0 (Defined at Interface level)
|   bDeviceSubClass 0 
|   bDeviceProtocol 0 
|   bMaxPacketSize064
|   bNumConfigurations  1
| Device Status: 0x
|   (Bus Powered)
| 
| Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
| Device Descriptor:
|   bLength18
|   bDescriptorType 1
|   bcdUSB   2.00
|   bDeviceClass9 Hub
|   bDeviceSubClass 0 Unused
|   bDeviceProtocol 0 Full speed (or root) hub
|   bMaxPacketSize064
|   idVendor   0x1d6b Linux Foundation
|   idProduct  0x0002 2.0 root hub
|   bcdDevice3.08
|   iManufacturer   3 Linux 3.8.3-nouveau ehci_hcd
|   iProduct2 EHCI Host Controller
|   iSerial 1 :00:1d.7
|   bNumConfigurations  1
|   Configuration Descriptor:
| bLength 9
| bDescriptorType 2
| wTotalLength   25
| bNumInterfaces  1
| bConfigurationValue 1
| iConfiguration  0 
| bmAttributes 0xe0
|   Self Powered
|   Remote Wakeup
| MaxPower0mA
| Interface Descriptor:
|   bLength 9
|   bDescriptorType 4
|   bInterfaceNumber0
|   bAlternateSetting   0
|   bNumEndpoints   1
|   bInterfaceClass 9 Hub
|   bInterfaceSubClass  0 Unused
|   bInterfaceProtocol  0 Full speed (or root) hub
|   iInterface  0 
|   Endpoint Descriptor:
| bLength 7
| bDescriptorType 5
| bEndpointAddress 0x81  EP 1 IN
| bmAttributes3
|   Transfer TypeInterrupt
|   Synch Type   None
|   Usage Type   Data
| wMaxPacketSize 0x0004  1x 4 bytes
| bInterval  12
| Hub Descriptor:
|   bLength  11
|   bDescriptorType  41
|   nNbrPorts 8
|   wHubCharacteristic 0x000a
| No power switching (usb 1.0)
| Per-port 

Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-18 22:06 +0100, Greg Kroah-Hartman wrote:

 3.8-stable review patch.  If anyone has any objections, please let me know.

This patch breaks resume from suspend on my system if the following
device is plugged in:

,
| $ lsusb | head -n1
| Bus 005 Device 002: ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless 
Adapter(rev.C1) [Ralink RT2571W]
`

The same problem exists in 3.9-rc3, FWIW.

Detailed lsusb output follows, I'll be happy to provide more information
if needed.

,
| # lsusb -s 005: -v
| Bus 005 Device 002: ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless 
Adapter(rev.C1) [Ralink RT2571W]
| Device Descriptor:
|   bLength18
|   bDescriptorType 1
|   bcdUSB   2.00
|   bDeviceClass0 (Defined at Interface level)
|   bDeviceSubClass 0 
|   bDeviceProtocol 0 
|   bMaxPacketSize064
|   idVendor   0x07d1 D-Link System
|   idProduct  0x3c03 AirPlus G DWL-G122 Wireless Adapter(rev.C1) 
[Ralink RT2571W]
|   bcdDevice0.01
|   iManufacturer   1 Ralink
|   iProduct2 802.11 bg WLAN
|   iSerial 0 
|   bNumConfigurations  1
|   Configuration Descriptor:
| bLength 9
| bDescriptorType 2
| wTotalLength   32
| bNumInterfaces  1
| bConfigurationValue 1
| iConfiguration  0 
| bmAttributes 0x80
|   (Bus Powered)
| MaxPower  300mA
| Interface Descriptor:
|   bLength 9
|   bDescriptorType 4
|   bInterfaceNumber0
|   bAlternateSetting   0
|   bNumEndpoints   2
|   bInterfaceClass   255 Vendor Specific Class
|   bInterfaceSubClass255 Vendor Specific Subclass
|   bInterfaceProtocol255 Vendor Specific Protocol
|   iInterface  0 
|   Endpoint Descriptor:
| bLength 7
| bDescriptorType 5
| bEndpointAddress 0x81  EP 1 IN
| bmAttributes2
|   Transfer TypeBulk
|   Synch Type   None
|   Usage Type   Data
| wMaxPacketSize 0x0200  1x 512 bytes
| bInterval   0
|   Endpoint Descriptor:
| bLength 7
| bDescriptorType 5
| bEndpointAddress 0x01  EP 1 OUT
| bmAttributes2
|   Transfer TypeBulk
|   Synch Type   None
|   Usage Type   Data
| wMaxPacketSize 0x0200  1x 512 bytes
| bInterval   0
| Device Qualifier (for other device speed):
|   bLength10
|   bDescriptorType 6
|   bcdUSB   2.00
|   bDeviceClass0 (Defined at Interface level)
|   bDeviceSubClass 0 
|   bDeviceProtocol 0 
|   bMaxPacketSize064
|   bNumConfigurations  1
| Device Status: 0x
|   (Bus Powered)
| 
| Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
| Device Descriptor:
|   bLength18
|   bDescriptorType 1
|   bcdUSB   2.00
|   bDeviceClass9 Hub
|   bDeviceSubClass 0 Unused
|   bDeviceProtocol 0 Full speed (or root) hub
|   bMaxPacketSize064
|   idVendor   0x1d6b Linux Foundation
|   idProduct  0x0002 2.0 root hub
|   bcdDevice3.08
|   iManufacturer   3 Linux 3.8.3-nouveau ehci_hcd
|   iProduct2 EHCI Host Controller
|   iSerial 1 :00:1d.7
|   bNumConfigurations  1
|   Configuration Descriptor:
| bLength 9
| bDescriptorType 2
| wTotalLength   25
| bNumInterfaces  1
| bConfigurationValue 1
| iConfiguration  0 
| bmAttributes 0xe0
|   Self Powered
|   Remote Wakeup
| MaxPower0mA
| Interface Descriptor:
|   bLength 9
|   bDescriptorType 4
|   bInterfaceNumber0
|   bAlternateSetting   0
|   bNumEndpoints   1
|   bInterfaceClass 9 Hub
|   bInterfaceSubClass  0 Unused
|   bInterfaceProtocol  0 Full speed (or root) hub
|   iInterface  0 
|   Endpoint Descriptor:
| bLength 7
| bDescriptorType 5
| bEndpointAddress 0x81  EP 1 IN
| bmAttributes3
|   Transfer TypeInterrupt
|   Synch Type   None
|   Usage Type   Data
| wMaxPacketSize 0x0004  1x 4 bytes
| bInterval  12
| Hub Descriptor:
|   bLength  11
|   bDescriptorType  41
|   nNbrPorts 8
|   wHubCharacteristic 0x000a
| No power switching (usb 1.0)
| Per-port 

Re: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-19 19:17 +0100, Alan Stern wrote:

 On Tue, 19 Mar 2013, Sven Joachim wrote:

 On 2013-03-18 22:06 +0100, Greg Kroah-Hartman wrote:
 
  3.8-stable review patch.  If anyone has any objections, please let me know.
 
 This patch breaks resume from suspend on my system if the following
 device is plugged in:
 
 ,
 | $ lsusb | head -n1
 | Bus 005 Device 002: ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless 
 Adapter(rev.C1) [Ralink RT2571W]
 `
 
 The same problem exists in 3.9-rc3, FWIW.
 
 Detailed lsusb output follows, I'll be happy to provide more information
 if needed.

 In what way is resume broken?

The kernel comes back, but the screen is black.  Manually switching VT's
is possible, and if I type something I can see it on the screen, but
there is no response and the cursor does not blink.  It looks as if the
VT is not switched backed on resume, and userspace tasks are not
restarted.  Sysrq combinations apparently work, but produce no output.

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-19 21:10 +0100, Alan Stern wrote:

 On Tue, 19 Mar 2013, Sven Joachim wrote:

  In what way is resume broken?
 
 The kernel comes back, but the screen is black.  Manually switching VT's
 is possible, and if I type something I can see it on the screen, but
 there is no response and the cursor does not blink.  It looks as if the
 VT is not switched backed on resume, and userspace tasks are not
 restarted.  Sysrq combinations apparently work, but produce no output.

 Are there any other problems?  For example, even before you do a 
 suspend, if you type Alt-SysRq-W do you see any processes listed?

No.

 There was another report on the linux-usb mailing list today of this
 same patch causing the khubd task to hang.  I'm thinking that you might
 be facing a similar problem.

Maybe, but before the suspend everything seems to be normal.

Cheers,
   Sven
--
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: [ 12/75] USB: EHCI: work around silicon bug in Intels EHCI controllers

[Sven Joachim]

On 2013-03-19 22:00 +0100, Alan Stern wrote:

 On Tue, 19 Mar 2013, Sven Joachim wrote:

 On 2013-03-19 21:10 +0100, Alan Stern wrote:
 
  On Tue, 19 Mar 2013, Sven Joachim wrote:
 
   In what way is resume broken?
  
  The kernel comes back, but the screen is black.  Manually switching VT's
  is possible, and if I type something I can see it on the screen, but
  there is no response and the cursor does not blink.  It looks as if the
  VT is not switched backed on resume, and userspace tasks are not
  restarted.  Sysrq combinations apparently work, but produce no output.
 
  Are there any other problems?  For example, even before you do a 
  suspend, if you type Alt-SysRq-W do you see any processes listed?
 
 No.
 
  There was another report on the linux-usb mailing list today of this
  same patch causing the khubd task to hang.  I'm thinking that you might
  be facing a similar problem.
 
 Maybe, but before the suspend everything seems to be normal.

 Just out of curiosity, does the patch posted here:

   http://marc.info/?l=linux-usbm=136361874807411w=2

 make any difference?

It fixes the problem for me, thanks. :-)

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-03-03 21:23 +0100, Yann E. MORIN wrote:

> On Thursday 28 February 2013 Sven Joachim wrote:
>> On 2013-02-28 10:59 +0100, j...@gentoo.org wrote:
>
>> >  scripts/kconfig/Makefile | 4 +++-
>> >  1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>> > index 3091794..c372976 100644
>> > --- a/scripts/kconfig/Makefile
>> > +++ b/scripts/kconfig/Makefile
>> > @@ -216,7 +216,9 @@ HOSTCFLAGS_gconf.o = `pkg-config --cflags gtk+-2.0 
>> > gmodule-2.0 libglade-2.0` \
>> >  
>> >  HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) 
>> > -ldflags $(HOSTCC))
>> >  
>> > -HOSTLOADLIBES_nconf   = -lmenu -lpanel -lncurses
>> > +HOSTLOADLIBES_nconf   = -lmenu -lpanel
>> > +HOSTLOADLIBES_nconf   += $(shellncursesw5-config --libs 
>> > 2>/dev/null \
>> > + || ncurses5-config --libs 2>/dev/null  )
>> 
>> This will link with ncursesw, not ncurses.  Probably not what you want,
>> since nconf.h does not #include the right headers for that.
>> 
>> On Debian/Ubuntu, there's also the problem that ncursesw5-config exists
>> even if the libncursesw5-dev package is not installed, so this patch
>> makes the build fail in such cases.
>
> The same goes for ncurses5-config, which is provided by ncurses-bin, and
> so is present even if the devel package is not installed, and the build
> will break, too.

This is not the same: if libncurses5-dev is not installed, the build is
going to fail anyway, since there is no -lmenu or -lpanel then.

I second the proposal to try pkg-config and fall back to -lncurses, BTW.

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-03-03 21:23 +0100, Yann E. MORIN wrote:

 On Thursday 28 February 2013 Sven Joachim wrote:
 On 2013-02-28 10:59 +0100, j...@gentoo.org wrote:

   scripts/kconfig/Makefile | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
  index 3091794..c372976 100644
  --- a/scripts/kconfig/Makefile
  +++ b/scripts/kconfig/Makefile
  @@ -216,7 +216,9 @@ HOSTCFLAGS_gconf.o = `pkg-config --cflags gtk+-2.0 
  gmodule-2.0 libglade-2.0` \
   
   HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) 
  -ldflags $(HOSTCC))
   
  -HOSTLOADLIBES_nconf   = -lmenu -lpanel -lncurses
  +HOSTLOADLIBES_nconf   = -lmenu -lpanel
  +HOSTLOADLIBES_nconf   += $(shellncursesw5-config --libs 
  2/dev/null \
  + || ncurses5-config --libs 2/dev/null  )
 
 This will link with ncursesw, not ncurses.  Probably not what you want,
 since nconf.h does not #include the right headers for that.
 
 On Debian/Ubuntu, there's also the problem that ncursesw5-config exists
 even if the libncursesw5-dev package is not installed, so this patch
 makes the build fail in such cases.

 The same goes for ncurses5-config, which is provided by ncurses-bin, and
 so is present even if the devel package is not installed, and the build
 will break, too.

This is not the same: if libncurses5-dev is not installed, the build is
going to fail anyway, since there is no -lmenu or -lpanel then.

I second the proposal to try pkg-config and fall back to -lncurses, BTW.

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-03-01 14:47 +0100, justin wrote:

> On 01/03/13 09:36, Sven Joachim wrote:
>> Historically it seems to be an accident, and the ncurses{w,5}-config
>> scripts should have better been shipped in their development packages.
>> But nowadays we want to make the development packages multiarch-aware,
>> and since the scripts differ on architectures, moving them away from
>> ncurses-bin would mean adding two additional binary packages just for
>> these scripts.
>> 
>> See http://bugs.debian.org/480437 for a discussion on that topic.
>> 
>
> I just tested on an ubuntu installation what happens with the patches
> applied; you simply end up with the warning the you need to install the
> dev package. So I don't see any problem here.

Well, in Debian/Ubuntu are _two_ dev packages, one for the wide API
(libncursesw5-dev), and on for the non-wide API (libncurses5-dev).  Only
the latter should be necessary, but with your original patch people
would need to install the former as well.

>> Well, at least until nconf does not make any effort to explicitly detect
>> and use the wide API, trying ncurses5-config first should work.  If you
>> build ncurses yourself with --enable-widec, there is no -lmenu or -lpanel
>> anyway, these libraries are called menuw and panelw then.
>
> You are right, we only should consider ncurses5-config right now.

That seems unlikely to cause regressions on its own.

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-03-01 08:37 +0100, justin wrote:

> On 28/02/13 22:50, Sven Joachim wrote:
>> On 2013-02-28 10:59 +0100, j...@gentoo.org wrote:
>> 
>>> Ncurses provides a config script (ncurses5-config) to assist finding 
>>> ncurses.
>>> This patch makes use of it to detect the necessary libs for linking of the
>>> ncurses nconfig dialog.
>> 
>> That script is not necessarily called ncurses5-config, it might also be
>> called ncurses6-config is ncurses is configured for a different ABI
>> (--enable-ext-colors, --enable-ext-mouse).  Although I would suspect
>> that any distribution who does that provides a compatibility symlink.
>>
>
> We don't do that, but I rechecked with building ncurses manually. You
> are right. How widely spread is the usage of this options? Or is it
> rather an experimental option?

Pretty much, since it changes the ABI and everyone wants to be
compatible with the existing ncurses ABI.

> What we could do is simple extending the syntax to additionally check
> for the ABI version 6 config scripts. Is this an option to consider?

Probably.

>>>  scripts/kconfig/Makefile | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>>> index 3091794..c372976 100644
>>> --- a/scripts/kconfig/Makefile
>>> +++ b/scripts/kconfig/Makefile
>>> @@ -216,7 +216,9 @@ HOSTCFLAGS_gconf.o  = `pkg-config --cflags gtk+-2.0 
>>> gmodule-2.0 libglade-2.0` \
>>>  
>>>  HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
>>> $(HOSTCC))
>>>  
>>> -HOSTLOADLIBES_nconf= -lmenu -lpanel -lncurses
>>> +HOSTLOADLIBES_nconf= -lmenu -lpanel
>>> +HOSTLOADLIBES_nconf+= $(shellncursesw5-config --libs 
>>> 2>/dev/null \
>>> +  || ncurses5-config --libs 2>/dev/null  )
>> 
>> This will link with ncursesw, not ncurses.  Probably not what you want,
>> since nconf.h does not #include the right headers for that.
>> 
>
> That's true, and again it would change two things at once. I will go
> back to simple -lncurses as it was before.
>
>> On Debian/Ubuntu, there's also the problem that ncursesw5-config exists
>> even if the libncursesw5-dev package is not installed, so this patch
>> makes the build fail in such cases.
>
> Will be solved when reverting as described above. But actually it smells
> like a bug in the package management, doesn't it? Why are build time
> config scripts shipped in runtime only packages? What is their purpose?

Historically it seems to be an accident, and the ncurses{w,5}-config
scripts should have better been shipped in their development packages.
But nowadays we want to make the development packages multiarch-aware,
and since the scripts differ on architectures, moving them away from
ncurses-bin would mean adding two additional binary packages just for
these scripts.

See http://bugs.debian.org/480437 for a discussion on that topic.

>> Can we just call ncurses5-config and not ncursesw5-config, or are there
>> any distros who ship the latter and not the former?
>> 
>
> I can't talk about distro wide situation, but manual building gives only
> one of the two. So there might be a situation where only one of the two
> is present.
>
> It seems we have a little dilemma here. Any suggestions how to solve it?

Well, at least until nconf does not make any effort to explicitly detect
and use the wide API, trying ncurses5-config first should work.  If you
build ncurses yourself with --enable-widec, there is no -lmenu or -lpanel
anyway, these libraries are called menuw and panelw then.

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-03-01 08:37 +0100, justin wrote:

 On 28/02/13 22:50, Sven Joachim wrote:
 On 2013-02-28 10:59 +0100, j...@gentoo.org wrote:
 
 Ncurses provides a config script (ncurses5-config) to assist finding 
 ncurses.
 This patch makes use of it to detect the necessary libs for linking of the
 ncurses nconfig dialog.
 
 That script is not necessarily called ncurses5-config, it might also be
 called ncurses6-config is ncurses is configured for a different ABI
 (--enable-ext-colors, --enable-ext-mouse).  Although I would suspect
 that any distribution who does that provides a compatibility symlink.


 We don't do that, but I rechecked with building ncurses manually. You
 are right. How widely spread is the usage of this options? Or is it
 rather an experimental option?

Pretty much, since it changes the ABI and everyone wants to be
compatible with the existing ncurses ABI.

 What we could do is simple extending the syntax to additionally check
 for the ABI version 6 config scripts. Is this an option to consider?

Probably.

  scripts/kconfig/Makefile | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
 index 3091794..c372976 100644
 --- a/scripts/kconfig/Makefile
 +++ b/scripts/kconfig/Makefile
 @@ -216,7 +216,9 @@ HOSTCFLAGS_gconf.o  = `pkg-config --cflags gtk+-2.0 
 gmodule-2.0 libglade-2.0` \
  
  HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
 $(HOSTCC))
  
 -HOSTLOADLIBES_nconf= -lmenu -lpanel -lncurses
 +HOSTLOADLIBES_nconf= -lmenu -lpanel
 +HOSTLOADLIBES_nconf+= $(shellncursesw5-config --libs 
 2/dev/null \
 +  || ncurses5-config --libs 2/dev/null  )
 
 This will link with ncursesw, not ncurses.  Probably not what you want,
 since nconf.h does not #include the right headers for that.
 

 That's true, and again it would change two things at once. I will go
 back to simple -lncurses as it was before.

 On Debian/Ubuntu, there's also the problem that ncursesw5-config exists
 even if the libncursesw5-dev package is not installed, so this patch
 makes the build fail in such cases.

 Will be solved when reverting as described above. But actually it smells
 like a bug in the package management, doesn't it? Why are build time
 config scripts shipped in runtime only packages? What is their purpose?

Historically it seems to be an accident, and the ncurses{w,5}-config
scripts should have better been shipped in their development packages.
But nowadays we want to make the development packages multiarch-aware,
and since the scripts differ on architectures, moving them away from
ncurses-bin would mean adding two additional binary packages just for
these scripts.

See http://bugs.debian.org/480437 for a discussion on that topic.

 Can we just call ncurses5-config and not ncursesw5-config, or are there
 any distros who ship the latter and not the former?
 

 I can't talk about distro wide situation, but manual building gives only
 one of the two. So there might be a situation where only one of the two
 is present.

 It seems we have a little dilemma here. Any suggestions how to solve it?

Well, at least until nconf does not make any effort to explicitly detect
and use the wide API, trying ncurses5-config first should work.  If you
build ncurses yourself with --enable-widec, there is no -lmenu or -lpanel
anyway, these libraries are called menuw and panelw then.

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-03-01 14:47 +0100, justin wrote:

 On 01/03/13 09:36, Sven Joachim wrote:
 Historically it seems to be an accident, and the ncurses{w,5}-config
 scripts should have better been shipped in their development packages.
 But nowadays we want to make the development packages multiarch-aware,
 and since the scripts differ on architectures, moving them away from
 ncurses-bin would mean adding two additional binary packages just for
 these scripts.
 
 See http://bugs.debian.org/480437 for a discussion on that topic.
 

 I just tested on an ubuntu installation what happens with the patches
 applied; you simply end up with the warning the you need to install the
 dev package. So I don't see any problem here.

Well, in Debian/Ubuntu are _two_ dev packages, one for the wide API
(libncursesw5-dev), and on for the non-wide API (libncurses5-dev).  Only
the latter should be necessary, but with your original patch people
would need to install the former as well.

 Well, at least until nconf does not make any effort to explicitly detect
 and use the wide API, trying ncurses5-config first should work.  If you
 build ncurses yourself with --enable-widec, there is no -lmenu or -lpanel
 anyway, these libraries are called menuw and panelw then.

 You are right, we only should consider ncurses5-config right now.

That seems unlikely to cause regressions on its own.

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-02-28 10:59 +0100, j...@gentoo.org wrote:

> Ncurses provides a config script (ncurses5-config) to assist finding ncurses.
> This patch makes use of it to detect the necessary libs for linking of the
> ncurses nconfig dialog.

That script is not necessarily called ncurses5-config, it might also be
called ncurses6-config is ncurses is configured for a different ABI
(--enable-ext-colors, --enable-ext-mouse).  Although I would suspect
that any distribution who does that provides a compatibility symlink.

>  scripts/kconfig/Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index 3091794..c372976 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -216,7 +216,9 @@ HOSTCFLAGS_gconf.o= `pkg-config --cflags gtk+-2.0 
> gmodule-2.0 libglade-2.0` \
>  
>  HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
> $(HOSTCC))
>  
> -HOSTLOADLIBES_nconf  = -lmenu -lpanel -lncurses
> +HOSTLOADLIBES_nconf  = -lmenu -lpanel
> +HOSTLOADLIBES_nconf  += $(shellncursesw5-config --libs 2>/dev/null \
> +|| ncurses5-config --libs 2>/dev/null  )

This will link with ncursesw, not ncurses.  Probably not what you want,
since nconf.h does not #include the right headers for that.

On Debian/Ubuntu, there's also the problem that ncursesw5-config exists
even if the libncursesw5-dev package is not installed, so this patch
makes the build fail in such cases.

Can we just call ncurses5-config and not ncursesw5-config, or are there
any distros who ship the latter and not the former?

Cheers,
   Sven
--
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: [PATCH 2/2] kconfig: use config scripts to detect ncurses libs

[Sven Joachim]

On 2013-02-28 10:59 +0100, j...@gentoo.org wrote:

 Ncurses provides a config script (ncurses5-config) to assist finding ncurses.
 This patch makes use of it to detect the necessary libs for linking of the
 ncurses nconfig dialog.

That script is not necessarily called ncurses5-config, it might also be
called ncurses6-config is ncurses is configured for a different ABI
(--enable-ext-colors, --enable-ext-mouse).  Although I would suspect
that any distribution who does that provides a compatibility symlink.

  scripts/kconfig/Makefile | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
 index 3091794..c372976 100644
 --- a/scripts/kconfig/Makefile
 +++ b/scripts/kconfig/Makefile
 @@ -216,7 +216,9 @@ HOSTCFLAGS_gconf.o= `pkg-config --cflags gtk+-2.0 
 gmodule-2.0 libglade-2.0` \
  
  HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
 $(HOSTCC))
  
 -HOSTLOADLIBES_nconf  = -lmenu -lpanel -lncurses
 +HOSTLOADLIBES_nconf  = -lmenu -lpanel
 +HOSTLOADLIBES_nconf  += $(shellncursesw5-config --libs 2/dev/null \
 +|| ncurses5-config --libs 2/dev/null  )

This will link with ncursesw, not ncurses.  Probably not what you want,
since nconf.h does not #include the right headers for that.

On Debian/Ubuntu, there's also the problem that ncursesw5-config exists
even if the libncursesw5-dev package is not installed, so this patch
makes the build fail in such cases.

Can we just call ncurses5-config and not ncursesw5-config, or are there
any distros who ship the latter and not the former?

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

Re: [ 00/46] 3.5.3-stable review

[Sven Joachim]

I would like to see commit 2064db725cc6d4ea19a24c138bc37939b63e3ae6
(drm/nv86/fifo: suspend fix) cherry-picked to the 3.5 kernel series, it
makes suspend work again on my machine.  Could you please queue this up
for 3.5.4?

Apologies for thread hijacking, my attempts to directly send the request
to sta...@vger.kernel.org failed (mail seems to have disappeared in the
bit bucket). :-(

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

Re: [ 00/46] 3.5.3-stable review

[Sven Joachim]

I would like to see commit 2064db725cc6d4ea19a24c138bc37939b63e3ae6
(drm/nv86/fifo: suspend fix) cherry-picked to the 3.5 kernel series, it
makes suspend work again on my machine.  Could you please queue this up
for 3.5.4?

Apologies for thread hijacking, my attempts to directly send the request
to sta...@vger.kernel.org failed (mail seems to have disappeared in the
bit bucket). :-(

Cheers,
   Sven
--
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: [bisected] nouveau: "Failed to idle channel x" after resume

[Sven Joachim]

On 2012-08-08 08:18 +0200, Sven Joachim wrote:

> On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>
>> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>>> once, subsequent attempts fail:
>>> 
>>> ,
>>> | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
>>> | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
>>> | suspend, -16
>>> | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
>>> DRM][:01:00.0] resuming display...
>>> `
>> Interesting.  Were there any messages prior to that?
>
> Nothing interesting:
>
> ,
> | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
> DRM][:01:00.0] suspending fbcon...
> | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
> DRM][:01:00.0] suspending display...
> | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
> DRM][:01:00.0] unpinning framebuffer(s)...
> | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
> DRM][:01:00.0] evicting buffers...
> | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
> DRM][:01:00.0] suspending client object trees...
> `
>
>> I guess the the fifo
>> code detected a timeout when trying to save the graphics context, I have
>> I have other patches in my tree (I'll push them soon, tied up with other
>> work atm) that might help here.
>
> Thanks, I'll try them when they are available.

With current nouveau master ("drm/nouveau: fix find/replace bug in
license header") suspending works again, thanks!  However, it is a bit
slow, taking between two and five seconds:

,
| Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
done.
| Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space processes 
... (elapsed 0.01 seconds) done.
| Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
tasks ... (elapsed 0.01 seconds) done.
| Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
no_console_suspend to debug)
| Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] Synchronizing 
SCSI cache
| Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping disk
| Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
| Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
| Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
capability disabled by ACPI
| Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
DRM][:01:00.0] suspending fbcon...
| Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
DRM][:01:00.0] suspending display...
| Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
DRM][:01:00.0] unpinning framebuffer(s)...
| Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
DRM][:01:00.0] evicting buffers...
| Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
DRM][:01:00.0] suspending client object trees...
| Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices complete 
after 4863.181 msecs
`

With the 3.4.8 kernel, suspending takes little more than one second.

Cheers,
   Sven
--
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: [bisected] nouveau: Failed to idle channel x after resume

[Sven Joachim]

On 2012-08-08 08:18 +0200, Sven Joachim wrote:

 On 2012-08-08 08:08 +0200, Ben Skeggs wrote:

 On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
 Not for me on my GeForce 8500 GT, and I still cannot suspend more than
 once, subsequent attempts fail:
 
 ,
 | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
 | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
 | suspend, -16
 | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
 DRM][:01:00.0] resuming display...
 `
 Interesting.  Were there any messages prior to that?

 Nothing interesting:

 ,
 | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
 DRM][:01:00.0] suspending fbcon...
 | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
 DRM][:01:00.0] suspending display...
 | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
 DRM][:01:00.0] unpinning framebuffer(s)...
 | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
 DRM][:01:00.0] evicting buffers...
 | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
 DRM][:01:00.0] suspending client object trees...
 `

 I guess the the fifo
 code detected a timeout when trying to save the graphics context, I have
 I have other patches in my tree (I'll push them soon, tied up with other
 work atm) that might help here.

 Thanks, I'll try them when they are available.

With current nouveau master (drm/nouveau: fix find/replace bug in
license header) suspending works again, thanks!  However, it is a bit
slow, taking between two and five seconds:

,
| Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
done.
| Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space processes 
... (elapsed 0.01 seconds) done.
| Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
tasks ... (elapsed 0.01 seconds) done.
| Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
no_console_suspend to debug)
| Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] Synchronizing 
SCSI cache
| Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping disk
| Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
| Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
| Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
capability disabled by ACPI
| Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
DRM][:01:00.0] suspending fbcon...
| Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
DRM][:01:00.0] suspending display...
| Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
DRM][:01:00.0] unpinning framebuffer(s)...
| Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
DRM][:01:00.0] evicting buffers...
| Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
DRM][:01:00.0] suspending client object trees...
| Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices complete 
after 4863.181 msecs
`

With the 3.4.8 kernel, suspending takes little more than one second.

Cheers,
   Sven
--
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: [bisected] nouveau: "Failed to idle channel x" after resume

[Sven Joachim]

On 2012-08-08 08:08 +0200, Ben Skeggs wrote:

> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>> once, subsequent attempts fail:
>> 
>> ,
>> | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
>> | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
>> | suspend, -16
>> | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
>> DRM][:01:00.0] resuming display...
>> `
> Interesting.  Were there any messages prior to that?

Nothing interesting:

,
| Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
DRM][:01:00.0] suspending fbcon...
| Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
DRM][:01:00.0] suspending display...
| Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
DRM][:01:00.0] unpinning framebuffer(s)...
| Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
DRM][:01:00.0] evicting buffers...
| Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
DRM][:01:00.0] suspending client object trees...
`

> I guess the the fifo
> code detected a timeout when trying to save the graphics context, I have
> I have other patches in my tree (I'll push them soon, tied up with other
> work atm) that might help here.

Thanks, I'll try them when they are available.

Cheers,
   Sven
--
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: [bisected] nouveau: "Failed to idle channel x" after resume

[Sven Joachim]

On 2012-08-08 07:37 +0200, Ben Skeggs wrote:

> On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
>> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote: 
>> > On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote: 
>> > > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus  
>> > > wrote:
>> > > >
>> > > > On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
>> > > > > after resuming from suspend nouveau starts writing Failed to idle
>> > > > > channel x (where x is 2 or 3) to the log and X appears to stop and
>> > > > > then restart only to stop again. Starting Firefox after resuming
>> > > > > triggers the bugs every time, and bisecting leads to 03bd6efa
>> > > > > ("drm/nv50/fifo: use hardware channel kickoff functionality").
>> > > >
>> > > > Hi Ben,
>> > > > I'm still seeing this bug with the latest from Linus
>> > > > (v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
>> > > >
>> > > > lspci output:
>> > > > 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
>> > > > 8400M GS] (rev a1)
>> > > >
>> > > > Sorry I haven't followed up on this earlier,
>> > > > Martin
>> > > 
>> > > I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
>> > > Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
>> > > Seems related to this bug:
>> > > http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
>> > > . If I can do anything else
>> > > to help, I will be glad to.
>> > Added nouv...@lists.freedesktop.org>
>> > 
>> > I confirm the same issue here.
>> > will try to do dig it.
>> Nope,can't dig this :-(
> Interestingly, this works just fine for me after the driver rework.

Not for me on my GeForce 8500 GT, and I still cannot suspend more than
once, subsequent attempts fail:

,
| Aug  8 07:49:16 turtle kernel: [   91.697068] nouveau W[  
PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed suspend, -16
| Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
DRM][:01:00.0] resuming display...
`

> I can confirm issues on G86 with 3.5/3.6-rc1 stock though.  I'll
> attempt to find a fix suitable for the non-reworked driver.

Thanks.  I'm currently stuck on 3.4 because of this problem.

Cheers,
   Sven
--
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: [bisected] nouveau: Failed to idle channel x after resume

[Sven Joachim]

On 2012-08-08 07:37 +0200, Ben Skeggs wrote:

 On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
 On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote: 
  On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote: 
   On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus martin.ny...@gmx.com 
   wrote:
   
On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
 after resuming from suspend nouveau starts writing Failed to idle
 channel x (where x is 2 or 3) to the log and X appears to stop and
 then restart only to stop again. Starting Firefox after resuming
 triggers the bugs every time, and bisecting leads to 03bd6efa
 (drm/nv50/fifo: use hardware channel kickoff functionality).
   
Hi Ben,
I'm still seeing this bug with the latest from Linus
(v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
   
lspci output:
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
8400M GS] (rev a1)
   
Sorry I haven't followed up on this earlier,
Martin
   
   I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
   Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
   Seems related to this bug:
   http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
   . If I can do anything else
   to help, I will be glad to.
  Added nouv...@lists.freedesktop.org
  
  I confirm the same issue here.
  will try to do dig it.
 Nope,can't dig this :-(
 Interestingly, this works just fine for me after the driver rework.

Not for me on my GeForce 8500 GT, and I still cannot suspend more than
once, subsequent attempts fail:

,
| Aug  8 07:49:16 turtle kernel: [   91.697068] nouveau W[  
PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed suspend, -16
| Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
DRM][:01:00.0] resuming display...
`

 I can confirm issues on G86 with 3.5/3.6-rc1 stock though.  I'll
 attempt to find a fix suitable for the non-reworked driver.

Thanks.  I'm currently stuck on 3.4 because of this problem.

Cheers,
   Sven
--
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: [bisected] nouveau: Failed to idle channel x after resume

[Sven Joachim]

On 2012-08-08 08:08 +0200, Ben Skeggs wrote:

 On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
 Not for me on my GeForce 8500 GT, and I still cannot suspend more than
 once, subsequent attempts fail:
 
 ,
 | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
 | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
 | suspend, -16
 | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
 DRM][:01:00.0] resuming display...
 `
 Interesting.  Were there any messages prior to that?

Nothing interesting:

,
| Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
DRM][:01:00.0] suspending fbcon...
| Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
DRM][:01:00.0] suspending display...
| Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
DRM][:01:00.0] unpinning framebuffer(s)...
| Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
DRM][:01:00.0] evicting buffers...
| Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
DRM][:01:00.0] suspending client object trees...
`

 I guess the the fifo
 code detected a timeout when trying to save the graphics context, I have
 I have other patches in my tree (I'll push them soon, tied up with other
 work atm) that might help here.

Thanks, I'll try them when they are available.

Cheers,
   Sven
--
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: [ 33/73] x86, microcode: Sanitize per-cpu microcode reloading interface

[Sven Joachim]

On 2012-07-31 06:43 +0200, Ben Hutchings wrote:

> 3.2-stable review patch.  If anyone has any objections, please let me know.

Alas, this does not build if CONFIG_SMP is unset:

,
| arch/x86/kernel/microcode_core.c: In function 'reload_store':
| arch/x86/kernel/microcode_core.c:304:19: error: 'struct cpuinfo_x86' has no 
member named 'cpu_index'
`

Cheers,
   Sven


> From: Borislav Petkov 
>
> commit c9fc3f778a6a215ace14ee556067c73982b6d40f upstream.
>
> Microcode reloading in a per-core manner is a very bad idea for both
> major x86 vendors. And the thing is, we have such interface with which
> we can end up with different microcode versions applied on different
> cores of an otherwise homogeneous wrt (family,model,stepping) system.
>
> So turn off the possibility of doing that per core and allow it only
> system-wide.
>
> This is a minimal fix which we'd like to see in stable too thus the
> more-or-less arbitrary decision to allow system-wide reloading only on
> the BSP:
>
> $ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload
> ...
>
> and disable the interface on the other cores:
>
> $ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload
> -bash: echo: write error: Invalid argument
>
> Also, allowing the reload only from one CPU (the BSP in
> that case) doesn't allow the reload procedure to degenerate
> into an O(n^2) deal when triggering reloads from all
> /sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
> simultaneously.
>
> A more generic fix will follow.
>
> Cc: Henrique de Moraes Holschuh 
> Cc: Peter Zijlstra 
> Signed-off-by: Borislav Petkov 
> Link: http://lkml.kernel.org/r/1340280437-7718-2-git-send-email...@amd64.org
> Signed-off-by: H. Peter Anvin 
> Signed-off-by: Ben Hutchings 
> ---
>  arch/x86/kernel/microcode_core.c |   26 +++---
>  1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/kernel/microcode_core.c 
> b/arch/x86/kernel/microcode_core.c
> index fbdfc69..24b852b 100644
> --- a/arch/x86/kernel/microcode_core.c
> +++ b/arch/x86/kernel/microcode_core.c
> @@ -298,19 +298,31 @@ static ssize_t reload_store(struct device *dev,
>   const char *buf, size_t size)
>  {
>   unsigned long val;
> - int cpu = dev->id;
> - ssize_t ret = 0;
> + int cpu;
> + ssize_t ret = 0, tmp_ret;
> +
> + /* allow reload only from the BSP */
> + if (boot_cpu_data.cpu_index != dev->id)
> + return -EINVAL;
>  
>   ret = kstrtoul(buf, 0, );
>   if (ret)
>   return ret;
>  
> - if (val == 1) {
> - get_online_cpus();
> - if (cpu_online(cpu))
> - ret = reload_for_cpu(cpu);
> - put_online_cpus();
> + if (val != 1)
> + return size;
> +
> + get_online_cpus();
> + for_each_online_cpu(cpu) {
> + tmp_ret = reload_for_cpu(cpu);
> + if (tmp_ret != 0)
> + pr_warn("Error reloading microcode on CPU %d\n", cpu);
> +
> + /* save retval of the first encountered reload error */
> + if (!ret)
> + ret = tmp_ret;
>   }
> + put_online_cpus();
>  
>   if (!ret)
>   ret = size;
--
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: [ 33/73] x86, microcode: Sanitize per-cpu microcode reloading interface

[Sven Joachim]

On 2012-07-31 06:43 +0200, Ben Hutchings wrote:

 3.2-stable review patch.  If anyone has any objections, please let me know.

Alas, this does not build if CONFIG_SMP is unset:

,
| arch/x86/kernel/microcode_core.c: In function 'reload_store':
| arch/x86/kernel/microcode_core.c:304:19: error: 'struct cpuinfo_x86' has no 
member named 'cpu_index'
`

Cheers,
   Sven


 From: Borislav Petkov borislav.pet...@amd.com

 commit c9fc3f778a6a215ace14ee556067c73982b6d40f upstream.

 Microcode reloading in a per-core manner is a very bad idea for both
 major x86 vendors. And the thing is, we have such interface with which
 we can end up with different microcode versions applied on different
 cores of an otherwise homogeneous wrt (family,model,stepping) system.

 So turn off the possibility of doing that per core and allow it only
 system-wide.

 This is a minimal fix which we'd like to see in stable too thus the
 more-or-less arbitrary decision to allow system-wide reloading only on
 the BSP:

 $ echo 1  /sys/devices/system/cpu/cpu0/microcode/reload
 ...

 and disable the interface on the other cores:

 $ echo 1  /sys/devices/system/cpu/cpu23/microcode/reload
 -bash: echo: write error: Invalid argument

 Also, allowing the reload only from one CPU (the BSP in
 that case) doesn't allow the reload procedure to degenerate
 into an O(n^2) deal when triggering reloads from all
 /sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
 simultaneously.

 A more generic fix will follow.

 Cc: Henrique de Moraes Holschuh h...@hmh.eng.br
 Cc: Peter Zijlstra pet...@infradead.org
 Signed-off-by: Borislav Petkov borislav.pet...@amd.com
 Link: http://lkml.kernel.org/r/1340280437-7718-2-git-send-email...@amd64.org
 Signed-off-by: H. Peter Anvin h...@zytor.com
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
  arch/x86/kernel/microcode_core.c |   26 +++---
  1 file changed, 19 insertions(+), 7 deletions(-)

 diff --git a/arch/x86/kernel/microcode_core.c 
 b/arch/x86/kernel/microcode_core.c
 index fbdfc69..24b852b 100644
 --- a/arch/x86/kernel/microcode_core.c
 +++ b/arch/x86/kernel/microcode_core.c
 @@ -298,19 +298,31 @@ static ssize_t reload_store(struct device *dev,
   const char *buf, size_t size)
  {
   unsigned long val;
 - int cpu = dev-id;
 - ssize_t ret = 0;
 + int cpu;
 + ssize_t ret = 0, tmp_ret;
 +
 + /* allow reload only from the BSP */
 + if (boot_cpu_data.cpu_index != dev-id)
 + return -EINVAL;
  
   ret = kstrtoul(buf, 0, val);
   if (ret)
   return ret;
  
 - if (val == 1) {
 - get_online_cpus();
 - if (cpu_online(cpu))
 - ret = reload_for_cpu(cpu);
 - put_online_cpus();
 + if (val != 1)
 + return size;
 +
 + get_online_cpus();
 + for_each_online_cpu(cpu) {
 + tmp_ret = reload_for_cpu(cpu);
 + if (tmp_ret != 0)
 + pr_warn(Error reloading microcode on CPU %d\n, cpu);
 +
 + /* save retval of the first encountered reload error */
 + if (!ret)
 + ret = tmp_ret;
   }
 + put_online_cpus();
  
   if (!ret)
   ret = size;
--
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: [ 000/187] 3.4.5-stable review

[Sven Joachim]

On 2012-07-12 21:24 +0200, Greg KH wrote:

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

As has been noted already, some of the patches are actually missing.

> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.5-rc1.gz

Seems it's not there?

Cheers,
   Sven
--
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: [ 000/187] 3.4.5-stable review

[Sven Joachim]

On 2012-07-12 21:24 +0200, Greg KH wrote:

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

As has been noted already, some of the patches are actually missing.

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

Seems it's not there?

Cheers,
   Sven
--
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/

Suspend/resume/suspend broken in Linux 3.5-rc5

[Sven Joachim]

Hi,

I'm sorry having to report that I'm only able to suspend once with Linux
3.5-rc5; any subsequent attempts fail.  This is a regression from 3.4
where suspend/resume worked flawlessly and arbitrarily often on my
machine.

Bisection show that the problem was introduced in commit c420b2dc8dc:

,
| commit c420b2dc8dc3cdd507214f4df5c5f96f08812cbe
| Author: Ben Skeggs 
| Date:   Tue May 1 20:48:08 2012 +1000
| 
| drm/nouveau/fifo: turn all fifo modules into engine modules
| 
| Been tested on each major revision that's relevant here, but I'm sure 
there
| are still bugs waiting to be ironed out.
| 
| This is a *very* invasive change.
| 
| There's a couple of pieces left that I don't like much (eg. other engines
| using fifo_priv for the channel count), but that's an artefact of there
| being a master channel list still.  This is changing, slowly.
| 
| Signed-off-by: Ben Skeggs 
`

My graphics cards is the following:

VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1)

Any advice would be appreciated.

Cheers,
   Sven
--
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/

Suspend/resume/suspend broken in Linux 3.5-rc5

[Sven Joachim]

Hi,

I'm sorry having to report that I'm only able to suspend once with Linux
3.5-rc5; any subsequent attempts fail.  This is a regression from 3.4
where suspend/resume worked flawlessly and arbitrarily often on my
machine.

Bisection show that the problem was introduced in commit c420b2dc8dc:

,
| commit c420b2dc8dc3cdd507214f4df5c5f96f08812cbe
| Author: Ben Skeggs bske...@redhat.com
| Date:   Tue May 1 20:48:08 2012 +1000
| 
| drm/nouveau/fifo: turn all fifo modules into engine modules
| 
| Been tested on each major revision that's relevant here, but I'm sure 
there
| are still bugs waiting to be ironed out.
| 
| This is a *very* invasive change.
| 
| There's a couple of pieces left that I don't like much (eg. other engines
| using fifo_priv for the channel count), but that's an artefact of there
| being a master channel list still.  This is changing, slowly.
| 
| Signed-off-by: Ben Skeggs bske...@redhat.com
`

My graphics cards is the following:

VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1)

Any advice would be appreciated.

Cheers,
   Sven
--
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/