|
Bugzilla – Full Text Bug Listing |
| Summary: | OSD always appears with no reason | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Perret Florian <f-perret> |
| Component: | Mobile Devices | Assignee: | Timo Hoenig <thoenig> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | aj, behlert, jbshuler, trenn |
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
test
test 2 proposed patch to stop the syslog flood on affected systems |
||
|
Description
Perret Florian
2005-09-02 13:22:41 UTC
/var/log/messages takes 5,5mo ! The start is : Sep 4 12:00:05 linux syslog-ng[4413]: new configuration initialized Sep 4 12:00:05 linux syslog-ng[4413]: Changing permissions on special file /dev/xconsole Sep 4 12:00:05 linux syslog-ng[4413]: Changing permissions on special file /dev/tty10 Sep 4 12:00:05 linux kernel: Asus ACPI: Error reading LCD status Sep 4 12:00:05 linux kernel: Asus ACPI: Error reading LCD status Sep 4 12:00:05 linux kernel: Asus ACPI: Error reading LCD status Sep 4 12:00:05 linux kernel: Asus ACPI: Error reading LCD status ... This last line is repeat every second ! sorry I'm not responsible for the scenario you mentioned here Are you using the ial package? I've just made the default install with KDE as desktop, and ial is effectively install. Looks like a buggy BIOS, but nevertheless there should not be so many messages. I see two bugs here: the numner of messages in /var/log/messages (syslog should collect them and say something like 'last message repeated 1234 times'), and the appearing of the OSD. I'll try to find the origin of the message today. This is clearly a bug of acpi_asus. I will take care. Please do the following $ rmmod acpi_asus $ modprobe acpi_asus and attach the ouput of $ tail -n 50 /var/log/messages to this bug. rmmod acpi_asus : ERROR: Module acpi_asus does not exist in /proc/modules modprobe acpi_asus : FATAL: Module acpi_asus not found. tail -n 50 /var/log/messages : Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:39 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:40 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sep 6 11:52:41 linux kernel: Asus ACPI: Error reading LCD status Sorry I've it should have been: $ rmmod asus_acpi and $ modprobe asus_acpi Please do not inline the log but rather the output as file. Created attachment 48896 [details]
test
Powersave daemon and KDE still accessing the driver's interface. Please close your X session, do $ rcpowersaved stop and attach a new log of above's procedure. Created attachment 48900 [details]
test 2
It seems better. A "brightness" OSD appears with the two commands. PS : I didn't have this bug in beata 3. So here's the analysis:
* asus_acpi loads with default values for ASUS laptops which are _not_ explicitly supported
* These default values are not sane for some systems (e.g. the one of this bug report). Thus, once
/proc/acpi/asus/lcd is read, an error is logged to syslog.
* If KDE starts up and KMILO is able to access /proc/acpi/asus/lcd it constantly polls this interface
at a insane rate. A short
$ strace `pidof kded`
shows almost exclusively syscalls triggered by of KMILO's ASUS module. On each iteration, a syslog
error gets logged and the OSD pops up (even though it didn't gather any reasonable data from the
kernel interface).
Solution:
KMILO has to
* quit polling at such a high rate, a polling intervall of 250ms for gathering the display brightness is
enough
* quit showing the OSD if it did not gather reasonable data from /proc/acpi/asus/lcd
Raising severity to gain attention. its a laptop, right? *** This bug has been marked as a duplicate of 104270 *** We're not talking about the probing of modules. We're talking about KMILO's polling intervall (comment #14). It's a laptop Asus A6G with an ATI Radeon M 9700 and a 1280*800 LCD. Elevate severity to critical. fixed for 10.0 /work/built/mbuild/oldboy-dmueller-454 contains the patched rpm that doesn't just disable it.. if only I could get hold of one of those asus laptops so that I can test it.. but maybe someone else here can. sorting Could you give a complete URL to test this patch ? Thanks. Perret, I can provide a ... a updated rpm of kdeutils3. See private mail. cc'ing Daniel. He's got a ASUS with RC1. He originally doesn't suffer from this bug's problem, but there are chances that we can provoke the bug on his system. Daniel, please install kdeutils3 and kdeutils3-laptop of Dirk's mbuild (comment #22). Florian, please post the results once you're on RC1 with the updated packages I've sent. It would make more sense to fix the kernel module or to drop it. Andreas ? Fixing yes, dropping no. I am preparing a patch for the module which prevents the flodding of syslog. Created attachment 49354 [details]
proposed patch to stop the syslog flood on affected systems
cc'ing Olaf and Thomas. Please review the patch. It applies on top of patches.suse/acpi-asus-panasonic-sony.patch. I've tested the patched driver and it works fine. I'd say the proc_read_lcd should return -ENODEV if the get_lcd_state() fails and KMilo/whatever should evaluate whether the read was successful and stop polling if not. But this would certainly be too much change for RCX. And you could do it with every func... So let's just suppress the message as Timo supposed ... Hmm, KMilo will probably use the wrong value as it cannot evaluate an error? But as said, I think it's too much for RC. Reassigning to okir, I don't have kernel commit rights... It's not the optimal solution, indeed. I would also have suggested using printk_ratelimit(KERN_NOTICE) rather than these somewhat awkward #ifdefs. Nevertheless, it's rather late in the game so in it goes. Please make sure you discuss this with the upstream maintainer. That's what I first thought of. Does rate_limit also help in this case: Error A Error A Error B Error B Error A Error A I'll talk to the upstream maintainers. There's more to discuss than this one... printk_ratelimit will basically blanket out any kernel messages within a certain interval if we're flooding the syslog. So it may not be such a good idea after all. The patch committed to CVS does not even apply, so it is obviously totally untested. So the patch has been dropped now. I've the same problem with RC1 and patches. OSD always appears and here the log : linux:/home/flo #rmmod asus_acpi linux:/home/flo # modprobe asus_acpi linux:/home/flo # tail -n 50 /var/log/messages Sep 10 08:25:41 linux kernel: Asus ACPI: Error reading LCD status Sep 10 08:25:41 linux kernel: Asus ACPI: Error reading LCD status Sep 10 08:25:41 linux kernel: Asus ACPI: Error reading LCD status Sep 10 08:25:41 linux kernel: Asus ACPI: Error reading LCD status Sep 10 08:25:42 linux kernel: Asus ACPI: Error reading LCD status Sep 10 08:25:42 linux kernel: Asus ACPI: Error reading LCD status ... The syslog flooding will be gone in RC2, I can send you an updated kernel module to verify the resolution in RC1. I'll take care of the OSD appearing on Monday once I got my hands on a ASUS machine. If I don't find a quick solution we will disable the KMILO plugin. Reopening the bug. I'll take care. Reassigning to me. Florian, Daniel: Can you please tell me whether the OSD pops up _after_ logging into X/KDE? If so, and if it is annoying I'd vote for disabling the ASUS KMILO plugin. Please respond quick, we're already in the middle of the RC phase. According to dmueller the KMILO plugins for ASUS laptops is now disabled. We'll look into this one again once the the kernel module is fixed. *** Bug 118532 has been marked as a duplicate of this bug. *** Now WOFOME with Suse 10 GM This bug be back when I upgrade to KDE 3.5 RC1. How could I disable Kmilo ? Folrian, are you still with us? Will you be able and willing to have a look on a upcoming Beta1? I'm still here. What should I do for testing ? Cool, glad to hear this. With Beta1 being released by tomorrow, I'd love to know whether your issues are fixed now. I expect the ASUS driver to be working (it was a kernel bug, the ACPI subsystem is to blame, not the ASUS driver). Thus, I expect the kmilo bug to be gone, too. Hence, would be great if you grab a copy of Beta1 and check if everything is working as expected. Thanks! Just had a look ar our kernel source. 2.6.15 _still_ seems not to provide support for the A6. I'll cook up a patch for you over the next days. Moving to 10.1, cc'ing seife. I always have in /var/log/messages : Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status Feb 3 11:21:24 linux klogd: Asus ACPI: Error reading LCD status But now the Kmilo advert doesn't appear. Florian -- again ;-) -- are you still with us? ASUS ACPI 0.30 is in and it now should be easy to add support for the A6. However, I'd need your help for testing. I'm stil here but I don't have anymore my Asus laptop. I've changed for a laptop with less problem (a Sony Vaio SZ). Sorry, I can't help you anymore... anyone else with an Asus here ? Well, it has to be a A6 in order to fix the issue for this model ;-) Nevermind, I'll see whether I can find someone with a A6. Thanks! The bug as described in the initial report was fixed with a patch for asus_acpi.c. See bug #166920 for details. To support more ASUS models I've opened a bug for 10.2 (bug #171517). Closing as FIXED. |