mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Harvey <harv@gmx.de>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: Jonathan Woithe <jwoithe@just42.net>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Kernel error messages: leds fujitsu::radio_led: Setting an LED's brightness failed
Date: Tue, 1 Aug 2017 09:53:00 +0200	[thread overview]
Message-ID: <ae932745-46f2-d65b-bdad-89387b499b0a@gmx.de> (raw)
In-Reply-To: <20170720064257.GA4942@larwa.localdomain>


[-- Attachment #1.1.1: Type: text/plain, Size: 5640 bytes --]

Hi Michał,

> A photo would be useful (though please do not attach it to your message,

> https://www.notebookcheck.net/fileadmin/_migrated/pics/Fujitsu-LB-E751-Tastatur_1j.jpg

That is exactly my laptop (well, except for those ugly windows badges ;))

To be completely sure I have taken two photos and posted them here:
http://picpaste.com/IMG_20170720_125716-RazF0yQa.jpg
http://picpaste.com/IMG_20170720_125736-zdpEGoHR.jpg
Beware, the photos will only stay online for seven days.

> Are these the 11 LEDs you mentioned?
> 
>   - top, left: E, HDD, Num Lock, Caps Lock, Scroll Lock,
>   - top, right: I, Power Button,
>   - front (not pictured in the first photo above): Power Supply, Battery
>     Charging, Battery 1, Battery 2.

Yes, these are the LEDs in question

>> 1783:Jul 14 12:33:48 gruenix kernel: leds fujitsu::radio_led: Setting an
>> LED's brightness failed (-2147483648)
> 
> 4.11 included a patch which sets the default trigger for the radio LED
> to rfkill-any, which would explain why you only started seeing these
> errors after upgrading to that version.  See also below.
> 
>> Some of the LEDs are not working under linux, especially the bluetooth
>> one
> 
> Where is the Bluetooth LED located?  I cannot see it.  Can you show it
> on a photo?  How does it behave under other operating systems?

Well, IIRC the one in the I(nformation) key was acting as a bluetooth
LED. I have another Harddisk with a working Win7 Installation which I
will mount and report back later when I have the time.

>> and three others E,
> 
> According to a manual I found [1], this is an "Energy saving functions
> indicator", which is lit when "energy function are enabled".  My guess
> would be it can be repurposed under Linux.

Correct. Would be nice to reuse it in one way or another under linux

>> I(nformation)
> 
> According to the same manual, this LED signals battery level when the
> laptop is off (S5 state) and the "I" key is pressed.  Not sure it can be
> repurposed, but how does it behave under other operating systems?

See above. Will report this later when I changed harddisks. Under linux
it does nothing. When suspended the three LEDs (1)Power (beneath the
power button) (2)Power beneath the wireless slider (both blue) and
(3)Battery2 are blinking.

>> and one that shows the sign of a
>> lock with up and down arrows in it.
> 
> That is Scroll Lock.  I do not think fujitsu-laptop has anything to do
> with it.  If it does not work the way you expect it to, you might want
> to search the web, because there are known inconsistencies in how
> various distributions handle it.

Scroll lock works as expected. KDE had taken scroll lock due to a
configuration I had forgotten. <Blush>

>> The case is equipped with a slider
>> for Wireless on/off, if that matters.
> 
> It does, see also below.
> 
>> Although the message seems to be harmless I am somewhat embarrassed what
>> happens here and thought I might report it to someone with more knowledge ;)
> 
> Again, thank you for the report, because implementing a feature like
> this in a platform driver often requires at least some guesswork, which
> may result in that feature working for some users and misbehaving for
> others.  This is an example of such a situation.
> 
> As you may have inferred from the patchwork link you visited, I was not
> sure whether my method of detecting radio LED presence was correct.
> Your report clearly proves I was wrong.  Could you please send me the
> BTNI value reported on your laptop?  You should be able to look it up by
> running:
> 
>     $ dmesg | grep BTNI

682:[   12.189363] fujitsu_laptop: BTNI: [0x10f0101]

> In fact, posting your entire dmesg output somewhere would not hurt
> either.

http://pasted.co/ce997722

> Anyway, you were curious what causes these log messages to appear.  I
> believe it happens because fujitsu-laptop _thinks_ you have a radio LED
> present on your machine, which causes it to register this LED with a
> default trigger set to rfkill-any.  This means the kernel tries to
> enable this LED whenever any radio transmitter is active and disable it
> when all radio transmissions are disabled.  In order to set the state of
> the LED, the kernel driver calls a function exposed by the firmware.
> This function returns an error, which is logged.  The specific error
> number you are seeing (-2147483648) means "unsupported command", which
> means fujitsu-laptop attempted to use a feature which is unsupported by
> your laptop's firmware.  If you want to get rid of these messages,
> running the following after every reboot should be enough:
> 
>     # echo "none" > /sys/class/leds/fujitsu::radio_led/trigger
> 
> However, I would appreciate it if you could help us with finding out the
> correct way to detect the radio LED (it may as well turn out it is not
> possible by just checking firmware contents).  For starters, we will
> need your laptop's DSDT table, which you can extract using:
> 
>     # cat /sys/firmware/acpi/tables/DSDT > dsdt.bin
> 
> The resulting binary file dsdt.bin is what is needed for further
> analysis.

See attachded file

> [1] http://www.lpmanual.com/manuals/fujitsu/Fujitsu_LIFEBOOK_E751.pdf
> 

Conclusion: Only the LED I(nformation) and E(mpowering) LEDs are not
working at all.

Glad to help further on. Don't hesitate to contact me. As said before I
am in Spain right now but will frequently check my mail though.

Greetings
Harvey

-- 
I am root. If you see me laughing, you'd better have a backup!




[-- Attachment #1.1.2: dsdt.bin --]
[-- Type: application/octet-stream, Size: 36680 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  parent reply	other threads:[~2017-08-01  7:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fede7169-e944-3ca8-8b8d-e17a95b8dcfe@gmx.de>
2017-07-20  6:42 ` Michał Kępień
2017-07-23  6:14   ` Jonathan Woithe
2017-07-25 12:14   ` Harvey
2017-08-01  7:53   ` Harvey [this message]
2017-08-03 10:21   ` Harvey
2017-08-04  6:13     ` Michał Kępień
2017-08-04  8:55       ` Harvey
2017-10-25  4:39         ` Michał Kępień
2017-10-25 13:17           ` Harvey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae932745-46f2-d65b-bdad-89387b499b0a@gmx.de \
    --to=harv@gmx.de \
    --cc=jwoithe@just42.net \
    --cc=kernel@kempniu.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®