acpi4asus

Could you also send a dmesg ?
Thanks

Adi A. wrote:

Corentin Chary wrote:

Could you also send a dmesg ?
Thanks

Of course, here it is.
Thanks

It seems that you use the asus_eee module. I think this conflict with eeepc-laptop.
Why do you use it ?
Can you try eeepc-laptop without it ?

Corentin Chary wrote:

Adi A. wrote:

Corentin Chary wrote:

Could you also send a dmesg ?
Thanks

Of course, here it is.
Thanks

It seems that you use the asus_eee module. I think this conflict with eeepc-laptop.
Why do you use it ?
Can you try eeepc-laptop without it ?

Using to control/monitor fan settings, could be obsolete by latest enhancements in your eeepc-laptop, relly don't know.
I removed it:
1. rmmod asus_eee
2. lsmod | grep asus
nothing is displayed
3. modprobe eeepc-laptop
FATAL: Error inserting eeepc_laptop (/lib/modules/2.6.32-rc5_EeePC1000H/kernel/drivers/platform/x86/eeepc-laptop.ko): No such device

Same setup worked without problems (both eeepc-laptop and asus_eee loaded) until updated to 2204.
The only thing changed is the BIOS. Yesterday mornig worked perfect with prev BIOS, updated BIOS and now not working.

Thanks.

Adi A. wrote:

Corentin Chary wrote:

Adi A. wrote:

Corentin Chary wrote:

Could you also send a dmesg ?
Thanks

Of course, here it is.
Thanks

It seems that you use the asus_eee module. I think this conflict with eeepc-laptop.
Why do you use it ?
Can you try eeepc-laptop without it ?

Using to control/monitor fan settings, could be obsolete by latest enhancements in your eeepc-laptop, relly don't know.
I removed it:
1. rmmod asus_eee
2. lsmod | grep asus
nothing is displayed
3. modprobe eeepc-laptop
FATAL: Error inserting eeepc_laptop (/lib/modules/2.6.32-rc5_EeePC1000H/kernel/drivers/platform/x86/eeepc-laptop.ko): No such device

Same setup worked without problems (both eeepc-laptop and asus_eee loaded) until updated to 2204.
The only thing changed is the BIOS. Yesterday mornig worked perfect with prev BIOS, updated BIOS and now not working.

Thanks.

can you also check if i2c-i801 is loaded ? (and try to remove it)
eeepc-laptop allow you to control and monitor the fan using a standard hmon interface (with lm sensors I think).
There is nothing new in dmesg when you try to modprobe eeepc-laptop ?

Can you check if the wmi module is loaded, and unload it is ?
Asus added a wmi interface in the latest bios, but this seems to conflict with the eeepc-laptop

Corentin Chary wrote:

Can you check if the wmi module is loaded, and unload it is ?
Asus added a wmi interface in the latest bios, but this seems to conflict with the eeepc-laptop

Also, wmi check if wmi is built in, or compiled as a module

1/ Can you send me a lsmod
2/ Can you try to remove acer-wmi and wmi from your configuration (this won't work, but we can try)
3/ In my previous patch, can you replace pr_info("init 3\n"); by pr_info("init 3 %d\n", result); and send me a dmesg
4/ Can you try to enable acpi debug (Power management and ACPI / ACPI (Advanced Configuration and Power Interface) Support / Debug statements ) and send me a dmesg

Thanks

Could you send me your current eeepc-laptop.c ?
I really don't understand what's happening :/

could you try to remove all __devinit attributes ? (before eeepc_hotk_add and eeepc_enable_camera)
also in eeepc_module_init add a pr_info("%p\n", eeepc_hotk_driver.ops.add);

thanks

if that doesn't work, try to boot with "acpi.debug_layer=0xffffffff acpi.debug_level=0xffffffff" and send me the dmesg
the boot might be slow

Corentin Chary wrote:

could you try to remove all __devinit attributes ? (before eeepc_hotk_add and eeepc_enable_camera)
also in eeepc_module_init add a pr_info("%p

", eeepc_hotk_driver.ops.add);

thanks

Not found such a method: eeepc_module_init. Assuming eeepc_laptop_init:

eeepc_laptop: init 1
eeepc_laptop: init 2
eeepc_laptop: init 3: 0
eeepc_laptop: f91b6fa0
eeepc_laptop: init 4

Adi A. wrote:

Corentin Chary wrote:

could you try to remove all __devinit attributes ? (before eeepc_hotk_add and eeepc_enable_camera)
also in eeepc_module_init add a pr_info("%p

", eeepc_hotk_driver.ops.add);

thanks

Not found such a method: eeepc_module_init. Assuming eeepc_laptop_init:

eeepc_laptop: init 1
eeepc_laptop: init 2
eeepc_laptop: init 3: 0
eeepc_laptop: f91b6fa0
eeepc_laptop: init 4

Sorry, just saw your post too late. Rebooting now with the debug params.

Adi A. wrote:

Corentin Chary wrote:

if that doesn't work, try to boot with "acpi.debug_layer=0xffffffff acpi.debug_level=0xffffffff" and send me the dmesg
the boot might be slow

Here it is. Unfortunatelly is truncated and I really don't know how to get a full dmesg.

Should be in /var/log/[dmesg|syslog|messages]

There is something strange in your syslog:
SB.ATKD.PBLG is called. This ACPI method is used by eeepc-laptop (and only by eeepc-laptop) to read/write the brightness.
Are you sure eeepc-laptop is not built in your current kernel image ?
Thanks

Corentin Chary wrote:

There is something strange in your syslog:
SB.ATKD.PBLG is called. This ACPI method is used by eeepc-laptop (and only by eeepc-laptop) to read/write the brightness.
Are you sure eeepc-laptop is not built in your current kernel image ?
Thanks

CONFIG_EEEPC_LAPTOP=m

I pretty sure is built as a module. I'm thinking about 2 possibilities for that trace:
1. I tried to modprobe eeepc-laptop;
2. On 1000h, brightness Fn+F5/F6 doesn't need any driver. It is working without any driver. Basically is working everywhere (BIOS, POST, linux, windows) . Could be from here?

Thanks.
Adi

eeepc-laptop only manipulate brightness if loaded successfully.
SB.ATKD.PBLG is acceded when someone read/write the brightness in /sys/class/backlight. For example gnome and kde do it on startup.

To check the current config (to be certain) use /proc/config.gz
You can also grep eeepc /boot/System.map

Corentin Chary wrote:

eeepc-laptop only manipulate brightness if loaded successfully.
SB.ATKD.PBLG is acceded when someone read/write the brightness in /sys/class/backlight. For example gnome and kde do it on startup.

To check the current config (to be certain) use /proc/config.gz
You can also grep eeepc /boot/System.map

100% sure eeepc-laptop is a module.

Could you send me a "tree /sys/class/backlight /sys/class/rfkill" ?
Also could you try with "acpi.debug_layer=0x00010000 acpi.debug_level=0x00000004"

Then try to modprobe the module and save dmesg.

Then reboot without acpi.debug

echo 0xffffffff > /sys/module/acpi/parameters/debug_level
echo 0xffffffff > /sys/module/acpi/parameters/debug_layer

Then try to modprobe the module and save dmesg.

If this doesn't help me, I'll try to make a patch with more verbosity.

Thanks for your help ;)

Corentin Chary wrote:

Then .. we will try function tracers:

Set these options

[...]

make, make install modules_install, rebuild all external modules (eg: ndiswrapper, nvidia, fglrx, vboxdrv, ...) , reboot

[...]

Download trace.c
[...]

Excuse my ignorance, this command
'./trace function modprobe eeepc-laptop > /tmp/function'
is running for about 2 hours, collecting ~21M of data and growing. How long it will take? Should I stop it?

The console output is:
/trace function modprobe eeepc-laptop > /tmp/function
Waiting child
FATAL: Error inserting eeepc_laptop (/lib/modules/2.6.32-rc5_EeePC1000H/kernel/drivers/platform/x86/eeepc-laptop.ko): No such device
Child terminated, copying trace

Adi A. wrote:

Corentin Chary wrote:

Excuse my ignorance, this command
'./trace function modprobe eeepc-laptop > /tmp/function'
is running for about 2 hours, collecting ~21M of data and growing. How long it will take? Should I stop it?

Now it should take only a few seconds .. but I think my code was wrong (and something didn't work with set_ftrace_pid)

Could you try this version please ?

I think we have the same problem. Stopped after 2 minutes. I attached my kernel config and also the generated function file, may be it can help.

Thanks.

Hum ..
Could you retry, but :
cd /debug/tracing/

echo find_symbol_in_section > set_ftrace_notrace
echo strcmp > set_ftrace_notrace
cat set_ftrace_notrace
to check ...

If it's take long again, try to disable CONFIG_DEBUG_KERNEL

Adi A. wrote:

If it's take long again, try to disable CONFIG_DEBUG_KERNEL

After setting CONFIG_DEBUG_KERNEL=n we have some results. Unfortunatelly the function_graph contains no useful data.

Can you check that CONFIG_FUNCTION_GRAPH_TRACER is enabled in config ? (is has some strange dependencies).

function_graph would really be easier to read :)

But I'll try to read function log to see what's happening.

Adi A. wrote:

Corentin Chary wrote:

Here is a patch to add more verbosity to acpi_bus_register_driver.
Could you try to modprobe eeepc-laptop with it ?
Thanks

Here it is.
Thanks

Ok, I think I found somehting, the acpi interface seems to be disabled if the kernel is recognized as Windows 7.
Can you try to boot with acpi_osi="Linux" parameter ?
Or even acpi_osi="Windows 2006"

Thanks

Corentin Chary wrote:

Adi A. wrote:

Corentin Chary wrote:

Here is a patch to add more verbosity to acpi_bus_register_driver.
Could you try to modprobe eeepc-laptop with it ?
Thanks

Here it is.
Thanks

Ok, I think I found somehting, the acpi interface seems to be disabled if the kernel is recognized as Windows 7.
Can you try to boot with acpi_osi="Linux" parameter ?
Or even acpi_osi="Windows 2006"

Thanks

Looks like acpi_osi="Linux" worked (at least the module is loaded)! I have to verbose test.

Thanks

Anonymous wrote:

Corentin Chary wrote:

Adi A. wrote:

Corentin Chary wrote:

Here is a patch to add more verbosity to acpi_bus_register_driver.
Could you try to modprobe eeepc-laptop with it ?
Thanks

Here it is.
Thanks

Ok, I think I found somehting, the acpi interface seems to be disabled if the kernel is recognized as Windows 7.
Can you try to boot with acpi_osi="Linux" parameter ?
Or even acpi_osi="Windows 2006"

Thanks

Looks like acpi_osi="Linux" worked (at least the module is loaded)! I have to verbose test.

Thanks

So almost excellent news ;-)

3 Issues remaining:
- the backlight is no longer symlinked in /sys/devices/platform/eeepc but is available in /sys/class/backlight
- webcam is always on even if is disabled in BIOS. Of course can be switched on/off but will be always on upon reboot. I think I'll open another issue concerning this because is an old story not BIOS update related.
- on 1000 (only?) series the Fn+F2 is switching on/off both WLAN and BT with this pattern [WB] [0,0] [1,0] [1,1] [0,1]. I saw that in kernel 2.6.32-rcX this was changed - the Fn+F2 will directly command rfkill on WLAN but not on BT. Tell me if you want to open another issue for this too.

Thanks for your help.

Adi A. wrote:

Anonymous wrote:

Corentin Chary wrote:

Adi A. wrote:

Corentin Chary wrote:

Here is a patch to add more verbosity to acpi_bus_register_driver.
Could you try to modprobe eeepc-laptop with it ?
Thanks

Here it is.
Thanks

Ok, I think I found somehting, the acpi interface seems to be disabled if the kernel is recognized as Windows 7.
Can you try to boot with acpi_osi="Linux" parameter ?
Or even acpi_osi="Windows 2006"

Thanks

Looks like acpi_osi="Linux" worked (at least the module is loaded)! I have to verbose test.

Thanks

So almost excellent news ;-)

3 Issues remaining:
- the backlight is no longer symlinked in /sys/devices/platform/eeepc but is available in /sys/class/backlight

Backlight is probably controled by acpi/video.ko module. It's ok.

- webcam is always on even if is disabled in BIOS. Of course can be switched on/off but will be always on upon reboot. I think I'll open another issue concerning this because is an old story not BIOS update related.

It's a feature, not a bug. If you want to save power see : http://patchwork.kernel.org/patch/54413/ for the discussion.

- on 1000 (only?) series the Fn+F2 is switching on/off both WLAN and BT with this pattern [WB] [0,0] [1,0] [1,1] [0,1]. I saw that in kernel 2.6.32-rcX this was changed - the Fn+F2 will directly command rfkill on WLAN but not on BT. Tell me if you want to open another issue for this too.

Fn+F2 only produce an event, that handled by userspace later. If you want to open an issue for that, check who handle the event, and try controling rfkill interface by hand (echo 1 > rfkillX/state, echo 0 ...) to see if they work as excepeted.

For the current issue, could you try different settings for acpi_osi, and tell me which one works better so I can make a patch for this ?

Thanks

Anonymous wrote:

Corentin Chary wrote:

Adi A. wrote:

Corentin Chary wrote:

Here is a patch to add more verbosity to acpi_bus_register_driver.
Could you try to modprobe eeepc-laptop with it ?
Thanks

Here it is.
Thanks

Ok, I think I found somehting, the acpi interface seems to be disabled if the kernel is recognized as Windows 7.
Can you try to boot with acpi_osi="Linux" parameter ?
Or even acpi_osi="Windows 2006"

Thanks

Looks like acpi_osi="Linux" worked (at least the module is loaded)! I have to verbose test.

Thanks

Hello,

Working with:
Linux

Not working with:
"Darwin"
"Windows 2006"

Fn+F2 only produce an event, that handled by userspace later. If you want to open an issue for that, check who handle the event, and try controling rfkill interface by hand (echo 1 > rfkillX/state, echo 0 ...) to see if they work as excepeted.

Don't know what to say, I'm not an expert but here is how is worked in 2.6.29 for example:
Fn+F2 genereated an ACPI event processed by acpid daemon then my script performed echo 0/1 to rfkill WLAN or BT. As I remember if acpid was stopped then no WLAN or BT switch.

In 2.6.32 for example things was changed. Even with acpid stopped the Fn+F2 kills my WLAN. On every Fn+F2 the WLAN is switched on or off.

If is normal can this behavior also be implemented for BT ?

Are you using gnome or kde ?

Corentin Chary wrote:

Are you using gnome or kde ?

nope, testing in single user mode (init 1).

this may be related to acpi_osi="Linux"

Could you try : acpi_osi="!Windows 2009"

Corentin Chary wrote:

this may be related to acpi_osi="Linux"

Could you try : acpi_osi="!Windows 2009"

tried with acpi_osi="!Windows 2009", same behaviour.
this Fn+F2 behaviour is old, before BIOS update and before using acpi_osi.

Hum .. so the behavior changed between 2.6.29 and 2.6.32, am I right ?
In single mode, without anything handling acpi event (to be sure, kill all process, just keep bash), Fn+F2 still toggle wlan ?

Anonymous wrote:

Corentin Chary wrote:

Hum .. so the behavior changed between 2.6.29 and 2.6.32, am I right ?
In single mode, without anything handling acpi event (to be sure, kill all process, just keep bash), Fn+F2 still toggle wlan ?

Yes I think. Here is a ps output with all running processes when testing Fn+F2 (kernel is 2.6.32-rc6).

Hum .. could you re-test on a 2.6.29 ? on a 2.6.30 ? on a 2.6.31 ?
This may take you some time, but as I don't have the hardware, there is no easy way for me to debug that.

Thansk

Corentin Chary wrote:

Anonymous wrote:

Corentin Chary wrote:

Hum .. so the behavior changed between 2.6.29 and 2.6.32, am I right ?
In single mode, without anything handling acpi event (to be sure, kill all process, just keep bash), Fn+F2 still toggle wlan ?

Yes I think. Here is a ps output with all running processes when testing Fn+F2 (kernel is 2.6.32-rc6).

Hum .. could you re-test on a 2.6.29 ? on a 2.6.30 ? on a 2.6.31 ?
This may take you some time, but as I don't have the hardware, there is no easy way for me to debug that.

Thansk

Pretty strange, tested on 2.6.29.1 and I got the same behaviour. Could be the BIOS update?
I wrote a script wich toggle W and B according to the pattern described in a prev post above. The script reads current B/W state and toggles according to the pattern. Now that script worked with no problem. If, let's name it 'hardware Fn+F2 toggle' were present int the past kernels then my script shouldn't work as for example:
1. hw toggle put WLAN off then generate an ACPI key event
2. the ACPI key event is treated by acpid and routed to my script
3. the script will read rfkill state and perform 'state=!state' and this should cancel hw toggle, simply put the Fn+F2 would be useless.

Anyway, I can live with this behaviour and adapt my scipt somehow.

Thanks for your support.

Hi,
I don't understand why it' s doing that. I'll re-read your dsdt and check on my 901 to compare.

Could you send me a dmidecode ?
Also, could you open another issue for the rfkill bug ?

Thanks

Adi A. wrote:

Corentin Chary wrote:

Could you send me a dmidecode ?
Also, could you open another issue for the rfkill bug ?

Thanks

Hello,

Here you have the dmidecode.
Regarding the rfkill bug , I want to agree with you because I'm not sure my previous posts were clear.
So in the past I used my script to switch W/B on/off. The script simply capture ACPI event and perform status=!status based on a pattern defined somewere above. I don't remember when (2.6.31 or 2.6.32rc) I have to adapt my script because the Fn+F2 behaviour changed: the Fn+F2 automatically switch on/off WLAN ("hardware rfkill"??) and also generate an ACPI hotkey event. Now i think is more clear.

Do you still want to open the rfkill bug?

Regards,
Adi

Yep, please open it ;)

Corentin Chary wrote:

Could you try these two patchs (without acpi_osi command line) ?
Should add it automatically.
Thanks

Hello,

The patches are working, there's no more need of acpi_osi. The rfkill issue is still present.

Regards,
Adi