Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #50703 > unrolled thread

Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood

Started by"Robert Schlabbach" <Robert.Schlabbach@gmx.net>
First post2015-09-03 12:30 +0200
Last post2018-03-04 19:00 +0100
Articles 8 — 6 participants

Back to article view | Back to linux.debian.kernel

Contents

  Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood "Robert Schlabbach" <Robert.Schlabbach@gmx.net> - 2015-09-03 12:30 +0200
    Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood Ian Campbell <ijc@debian.org> - 2015-10-04 15:10 +0200
      Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood Ben Hutchings <ben@decadent.org.uk> - 2015-10-04 23:30 +0200
        Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood Ian Campbell <ijc@debian.org> - 2015-10-05 10:40 +0200
      Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood Martin Michlmayr <tbm@cyrius.com> - 2015-12-10 01:20 +0100
        Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood Ian Campbell <ijc@debian.org> - 2015-12-10 08:40 +0100
          Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood Ian Campbell <ijc@hellion.org.uk> - 2015-12-10 09:40 +0100
    Bug#797881: marked as done (QNAP TS-219P II: qcontrol no longer  works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-03-04 19:00 +0100

#50703 — Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood

From"Robert Schlabbach" <Robert.Schlabbach@gmx.net>
Date2015-09-03 12:30 +0200
SubjectBug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood
Message-ID<q4zWh-NK-1@gated-at.bofh.it>
Package: linux-image-4.1.0-0.bpo.1-kirkwood
Version: 4.1.3-1~bpo8+1
 
After installing this Linux kernel on my QNAP TS-219P II, qcontrol no longer works:
 
1. The status LED remains in red/green blink mode (as set by the boot loader). It should be set to solid green when the kernel is loaded.
2. The buzzer does not buzz. It should buzz when the kernel is loaded and when the kernel is shutting down.
 
Removing and reinstalling the qcontrol package did not help.
 
Solely reverting to the debian jessie kernel 3.16.7-ckt11-1+deb8u3 fixes these problems, i.e. the LED status is correctly set and the buzzer buzzes again.
 
Best Regards,
Robert Schlabbach

[toc] | [next] | [standalone]

#50922

FromIan Campbell <ijc@debian.org>
Date2015-10-04 15:10 +0200
Message-ID<qfRd8-1dd-1@gated-at.bofh.it>
In reply to#50703
On Thu, 2015-09-03 at 12:20 +0200, Robert Schlabbach wrote:
> Package: linux-image-4.1.0-0.bpo.1-kirkwood
> Version: 4.1.3-1~bpo8+1
>  
> After installing this Linux kernel on my QNAP TS-219P II, qcontrol no
> longer works:
>  
> 1. The status LED remains in red/green blink mode (as set by the boot
> loader). It should be set to solid green when the kernel is loaded.
> 2. The buzzer does not buzz. It should buzz when the kernel is loaded
> and when the kernel is shutting down.
>  
> Removing and reinstalling the qcontrol package did not help.

I suspect this is due to the device path for the input node changing
from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
-path/platform-gpio-keys-event. With the version of qcontrol in Jessie
it won't even start if it can't find the device, even though it can do
many of its core things without it (the node is for button input only).

This is fixed by qcontrol 0.5.4-4 in testing (both looking for old and
new names, as well as not treating failure to find either as a
catastrophe), but for Jessie you can just edit the path in
/etc/qcontrol.conf.

If that works for you then it might be worth uploading an updated
qcontrol to backports.

Thanks,
Ian.

[toc] | [prev] | [next] | [standalone]

#50924

FromBen Hutchings <ben@decadent.org.uk>
Date2015-10-04 23:30 +0200
Message-ID<qfZ10-3QB-9@gated-at.bofh.it>
In reply to#50922

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2015-10-04 at 14:04 +0100, Ian Campbell wrote:
> On Thu, 2015-09-03 at 12:20 +0200, Robert Schlabbach wrote:
> > Package: linux-image-4.1.0-0.bpo.1-kirkwood
> > Version: 4.1.3-1~bpo8+1
> >  
> > After installing this Linux kernel on my QNAP TS-219P II, qcontrol no
> > longer works:
> >  
> > 1. The status LED remains in red/green blink mode (as set by the boot
> > loader). It should be set to solid green when the kernel is loaded.
> > 2. The buzzer does not buzz. It should buzz when the kernel is loaded
> > and when the kernel is shutting down.
> >  
> > Removing and reinstalling the qcontrol package did not help.
> 
> I suspect this is due to the device path for the input node changing
> from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
> -path/platform-gpio-keys-event. With the version of qcontrol in Jessie
> it won't even start if it can't find the device, even though it can do
> many of its core things without it (the node is for button input only).

The change seems to have been in the other direction.

> This is fixed by qcontrol 0.5.4-4 in testing (both looking for old and
> new names, as well as not treating failure to find either as a
> catastrophe), but for Jessie you can just edit the path in
> /etc/qcontrol.conf.
> 
> If that works for you then it might be worth uploading an updated
> qcontrol to backports.

I think the name change in the kernel should be reverted (not just in
Debian, but upstream) since it broke existing userland.  Presumably
that would be:

--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -32,7 +32,7 @@
 		};
 	};
 
-	gpio_keys {
+	gpio-keys {
 		compatible = "gpio-keys";
 		#address-cells = <1>;
 		#size-cells = <0>;
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -42,7 +42,7 @@
 		};
 	};
 
-	gpio_keys {
+	gpio-keys {
 		compatible = "gpio-keys";
 		#address-cells = <1>;
 		#size-cells = <0>;
--- END ---

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

[toc] | [prev] | [next] | [standalone]

#50926

FromIan Campbell <ijc@debian.org>
Date2015-10-05 10:40 +0200
Message-ID<qg9tn-230-3@gated-at.bofh.it>
In reply to#50924
On Sun, 2015-10-04 at 22:21 +0100, Ben Hutchings wrote:
> On Sun, 2015-10-04 at 14:04 +0100, Ian Campbell wrote:
> > On Thu, 2015-09-03 at 12:20 +0200, Robert Schlabbach wrote:
> > > Package: linux-image-4.1.0-0.bpo.1-kirkwood
> > > Version: 4.1.3-1~bpo8+1
> > >  
> > > After installing this Linux kernel on my QNAP TS-219P II, qcontrol no
> > > longer works:
> > >  
> > > 1. The status LED remains in red/green blink mode (as set by the boot
> > > loader). It should be set to solid green when the kernel is loaded.
> > > 2. The buzzer does not buzz. It should buzz when the kernel is loaded
> > > and when the kernel is shutting down.
> > >  
> > > Removing and reinstalling the qcontrol package did not help.
> > 
> > I suspect this is due to the device path for the input node changing
> > from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
> > -path/platform-gpio-keys-event. With the version of qcontrol in Jessie
> > it won't even start if it can't find the device, even though it can do
> > many of its core things without it (the node is for button input only).
> 
> The change seems to have been in the other direction.

Right.

> > This is fixed by qcontrol 0.5.4-4 in testing (both looking for old and
> > new names, as well as not treating failure to find either as a
> > catastrophe), but for Jessie you can just edit the path in
> > /etc/qcontrol.conf.
> > 
> > If that works for you then it might be worth uploading an updated
> > qcontrol to backports.
> 
> I think the name change in the kernel should be reverted (not just in
> Debian, but upstream) since it broke existing userland.

I agree, I did mention this upstream at the time this was first
discovered[0] and the consensus seemed to be that this would be hard to fix
(or at least no one knew how).

> Presumably that would be:

I don't think DTB node names generally have any actual meaning and the
gpio_keys is the module name (which the kernel has normalised with "tr -
_", like it generally does), compared with the older board file based stuff
which was, I suppose, non-modular or otherwise hard coded somewhere.

It happened enough releases ago now that I think it is unlikely to change
back :-/. I probably should have chased harder at the time.

Ian.

[0] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/2237
91.html and some relevant replies:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224933.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/225917.html

> 
> --- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
> +++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
> @@ -32,7 +32,7 @@
>  		};
>  	};
>  
> -	gpio_keys {
> +	gpio-keys {
>  		compatible = "gpio-keys";
>  		#address-cells = <1>;
>  		#size-cells = <0>;
> --- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
> +++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
> @@ -42,7 +42,7 @@
>  		};
>  	};
>  
> -	gpio_keys {
> +	gpio-keys {
>  		compatible = "gpio-keys";
>  		#address-cells = <1>;
>  		#size-cells = <0>;
> --- END ---
> 
> Ben.
>

[toc] | [prev] | [next] | [standalone]

#51651

FromMartin Michlmayr <tbm@cyrius.com>
Date2015-12-10 01:20 +0100
Message-ID<qDX7I-73a-11@gated-at.bofh.it>
In reply to#50922
* Ian Campbell <ijc@debian.org> [2015-10-04 14:04]:
> I suspect this is due to the device path for the input node changing
> from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
> -path/platform-gpio-keys-event. With the version of qcontrol in Jessie
> it won't even start if it can't find the device, even though it can do
> many of its core things without it (the node is for button input only).
> 
> This is fixed by qcontrol 0.5.4-4 in testing (both looking for old and
> new names, as well as not treating failure to find either as a
> catastrophe), but for Jessie you can just edit the path in
> /etc/qcontrol.conf.
> 
> If that works for you then it might be worth uploading an updated
> qcontrol to backports.

Ian, were you going to upload qcontrol to backports or did you want
someone else to do it?

-- 
Martin Michlmayr
http://www.cyrius.com/

[toc] | [prev] | [next] | [standalone]

#51670

FromIan Campbell <ijc@debian.org>
Date2015-12-10 08:40 +0100
Message-ID<qE3Zw-31E-5@gated-at.bofh.it>
In reply to#51651
On Wed, 2015-12-09 at 16:04 -0800, Martin Michlmayr wrote:
> * Ian Campbell <ijc@debian.org> [2015-10-04 14:04]:
> > I suspect this is due to the device path for the input node
> changing
> > from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
> > -path/platform-gpio-keys-event. With the version of qcontrol in
> Jessie
> > it won't even start if it can't find the device, even though it can
> do
> > many of its core things without it (the node is for button input
> only).
> > 
> > This is fixed by qcontrol 0.5.4-4 in testing (both looking for old
> and
> > new names, as well as not treating failure to find either as a
> > catastrophe), but for Jessie you can just edit the path in
> > /etc/qcontrol.conf.
> > 
> > If that works for you then it might be worth uploading an updated
> > qcontrol to backports.
> 
> Ian, were you going to upload qcontrol to backports or did you want
> someone else to do it?

I wasn't, but now I am. I've left a build going and will (hopefully)
upload after breakfast.

Ian.

[toc] | [prev] | [next] | [standalone]

#51671

FromIan Campbell <ijc@hellion.org.uk>
Date2015-12-10 09:40 +0100
Message-ID<qE4Vz-3E8-9@gated-at.bofh.it>
In reply to#51670
On Thu, 2015-12-10 at 07:36 +0000, Ian Campbell wrote:
> On Wed, 2015-12-09 at 16:04 -0800, Martin Michlmayr wrote:
> > * Ian Campbell <ijc@debian.org> [2015-10-04 14:04]:
> > > I suspect this is due to the device path for the input node
> > changing
> > > from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
> > > -path/platform-gpio-keys-event. With the version of qcontrol in
> > Jessie
> > > it won't even start if it can't find the device, even though it
> can
> > do
> > > many of its core things without it (the node is for button input
> > only).
> > > 
> > > This is fixed by qcontrol 0.5.4-4 in testing (both looking for
> old
> > and
> > > new names, as well as not treating failure to find either as a
> > > catastrophe), but for Jessie you can just edit the path in
> > > /etc/qcontrol.conf.
> > > 
> > > If that works for you then it might be worth uploading an updated
> > > qcontrol to backports.
> > 
> > Ian, were you going to upload qcontrol to backports or did you want
> > someone else to do it?
> 
> I wasn't, but now I am. I've left a build going and will (hopefully)
> upload after breakfast.

Done (pending a successful dinstall run).

Cheers,
Ian.

[toc] | [prev] | [next] | [standalone]

#60399 — Bug#797881: marked as done (QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood)

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2018-03-04 19:00 +0100
SubjectBug#797881: marked as done (QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood)
Message-ID<vpG5x-7Un-5@gated-at.bofh.it>
In reply to#50703

[Multipart message — attachments visible in raw view] — view raw

Your message dated Sun, 4 Mar 2018 18:31:09 +0100
with message-id <20180304173109.elqj4fqy22zj36iv@jirafa.cyrius.com>
and subject line Re: Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood
has caused the Debian Bug report #797881,
regarding QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
797881: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797881
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web