Oopses and ACPI problems (Linus 2.6.29-rc4)

Oopses and ACPI problems (Linus 2.6.29-rc4)

[Darren Salt]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

I'm seeing various oopses with -rc4, where -rc3 is fine; config, dmesg
(captured via netconsole) and decoded oops data attached ¹. The last few
oopses were followed by a scrambled display and a hard lockup.

All oopses follow an otherwise successful suspend-to-RAM.

Also, I see that Fn-Fx don't seem to be reported via /proc/acpi/events any
more, or at least I'm seeing no evidence of them via acpi_listen (and, not
coincidentally, I can't adjust the volume etc. via eeepc-acpi-scripts).

The only other (significant) change is that I've installed X from Debian
experimental, though -rc3 and 2.6.28.* seem fine with this. (Oh, and I can
get UXA to cause OOM quite trivially... several Iceweasel tabs is enough.)


¹ Yes, I decided not to include symbol names in the running kernel...

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less.          BE MORE ENERGY EFFICIENT.

I'll have what the bloke on the floor is having...


[-- Attachment #2: config-eee901.gz --]
[-- Type: application/x-gzip, Size: 14395 bytes --]

[-- Attachment #3: eee-oops.txt --]
[-- Type: text/plain, Size: 9629 bytes --]

ksymoops 2.4.11 on i686 2.6.29-rc4-eee901.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.6.29-rc4-eee901/ (default)
     -m /boot/System.map-2.6.29-rc4-eee901 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
CPU 1 is now offline
WARNING: at fs/sysfs/group.c:138 ()
Pid: 330, comm: pciehpd Not tainted 2.6.29-rc4-eee901 #2
Call Trace:
 [<c011fab7>] 0xc011fab7
 [<c032ca9d>] 0xc032ca9d
 [<f81760d5>] 0xf81760d5
 [<c01f112c>] 0xc01f112c
 [<c0118940>] 0xc0118940
 [<c011fc82>] 0xc011fc82
 [<c016b8aa>] 0xc016b8aa
 [<c0190b6b>] 0xc0190b6b
 [<c016b9a8>] 0xc016b9a8
 [<c016b738>] 0xc016b738
 [<c019102a>] 0xc019102a
 [<c0191faa>] 0xc0191faa
 [<c025a8d4>] 0xc025a8d4
 [<c025a9c9>] 0xc025a9c9
 [<c01fae3c>] 0xc01fae3c
 [<c01faf00>] 0xc01faf00
 [<c0205ca4>] 0xc0205ca4
 [<c0204a68>] 0xc0204a68
 [<c0204eb3>] 0xc0204eb3
 [<c0204e2d>] 0xc0204e2d
 [<c012bd8f>] 0xc012bd8f
 [<c012c51d>] 0xc012c51d
 [<c012c5d1>] 0xc012c5d1
 [<c012e9ac>] 0xc012e9ac
 [<c012c51d>] 0xc012c51d
 [<c012e8de>] 0xc012e8de
 [<c012e8a6>] 0xc012e8a6
 [<c010349b>] 0xc010349b
BUG: unable to handle kernel NULL pointer dereference at 00000010
*pde = 00000000 
Oops: 0000 [#1] PREEMPT SMP 
Pid: 330, comm: pciehpd Tainted: G        W  (2.6.29-rc4-eee901 #2) 901
EIP: 0060:[<c03ccef7>] EFLAGS: 00010246 CPU: 0
Using defaults from ksymoops -t elf32-i386 -a i386
EAX: 00000000 EBX: 00000001 ECX: 00000046 EDX: 00000001
ESI: f17dd470 EDI: f70f7c5c EBP: 00000000 ESP: f7339f00
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
 f17dd45c 00000000 f70f7c5c c025a9c9 f7060b40 f7311a80ff 83 c0 89 83 cf db 74 19 f6 06 01 74 11 6a 00 ---[ end trace 449537779ba90603 ]---
Warning (Oops_read): Code line not seen, dumping what data is available


Trace; c011fab7 <warn_slowpath+7d/94>
Trace; c032ca9d <__alloc_skb+4b/103>
Trace; f81760d5 <END_OF_CODE+37c160d5/????>
Trace; c01f112c <cpumask_next_and+23/33>
Trace; c0118940 <find_busiest_group+242/725>
Trace; c011fc82 <__call_console_drivers+51/5d>
Trace; c016b8aa <find_inode+1b/56>
Trace; c0190b6b <sysfs_ilookup_test+0/d>
Trace; c016b9a8 <ifind+3a/74>
Trace; c016b738 <iput+21/4a>
Trace; c019102a <sysfs_addrm_finish+4a/1ae>
Trace; c0191faa <sysfs_remove_group+34/8d>
Trace; c025a8d4 <device_del+32/11f>
Trace; c025a9c9 <device_unregister+8/10>
Trace; c01fae3c <pci_stop_dev+20/3a>
Trace; c01faf00 <pci_remove_bus_device+27/88>
Trace; c0205ca4 <pciehp_unconfigure_device+108/180>
Trace; c0204a68 <pciehp_disable_slot+12d/1d6>
Trace; c0204eb3 <pciehp_power_thread+86/cd>
Trace; c0204e2d <pciehp_power_thread+0/cd>
Trace; c012bd8f <run_workqueue+71/f1>
Trace; c012c51d <worker_thread+0/bf>
Trace; c012c5d1 <worker_thread+b4/bf>
Trace; c012e9ac <autoremove_wake_function+0/2b>
Trace; c012c51d <worker_thread+0/bf>
Trace; c012e8de <kthread+38/5e>
Trace; c012e8a6 <kthread+0/5e>
Trace; c010349b <kernel_thread_helper+7/10>

>>EIP; c03ccef7 <klist_put+f/59>   <=====

BUG: unable to handle kernel paging request at 7a9d5f5c
*pde = 00000000 
Oops: 0000 [#2] PREEMPT SMP 
Pid: 4094, comm: bash Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
EIP: 0060:[<c015bb0a>] EFLAGS: 00010006 CPU: 1
EAX: 00000000 EBX: c04c7d90 ECX: 7a9d5f5c EDX: c180ff6c
ESI: 00000282 EDI: c04c7d90 EBP: 00000040 ESP: ee9f1e38
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 7a9d5f5c 000080d0 f173f7c0 c194c488 7ac532a8 fe280a2e c194c488 c0194004
 f173f7c0 c194c488 f6e64498 0000003e f6e02458 c019aaa0 c194c488 00000000
 ee949600 c194cff8 00000000 ee949600 ee949600 f6e02458 00000000 c019ab55
Call Trace:
 [<c0194004>] 0xc0194004
 [<c019aaa0>] 0xc019aaa0
 [<c019ab55>] 0xc019ab55
 [<c01405ce>] 0xc01405ce
 [<c0102cf1>] 0xc0102cf1
56 BUG: unable to handle kernel paging request at 7a9d5f5c
*pde = 00000000 
Oops: 0000 [#3] PREEMPT SMP 
Pid: 3147, comm: xfce4-systemloa Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
EIP: 0060:[<c015b4e5>] EFLAGS: 00010006 CPU: 1
EAX: 00000000 EBX: 00000292 ECX: 7a9d5f5c EDX: c180ff6c
ESI: 00000040 EDI: c018d53c EBP: c04c7d90 ESP: f16ebe34
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 7a9d5f5c 000000d0 f702c00a ee949300 f73e35e0 c018d53c 00000000 c017059b
 00000000 f73e35e0 fffffff4 c018d53c ee949300 c0170678 00000000 f7029000
 fffffff4 00001000 ee949300 c018d51e f173f2a0 f70e9680 c018d4d0 f70e96cc
Call Trace:
 [<c018d53c>] 0xc018d53c
 [<c017059b>] 0xc017059b
 [<c018d53c>] 0xc018d53c
 [<c0170678>] 0xc0170678
 [<c018d51e>] 0xc018d51e
 [<c018d4d0>] 0xc018d4d0
 [<c01887b8>] 0xc01887b8
 [<c017006d>] 0xc017006d
 [<c012e9ac>] 0xc012e9ac
 [<c0102cf1>] 0xc0102cf1
BUG: unable to handle kernel paging request at 7a9d5f5c
*pde = 00000000 
Oops: 0000 [#4] PREEMPT SMP 
Pid: 3137, comm: xfce4-panel Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
EIP: 0060:[<c015b4e5>] EFLAGS: 00010006 CPU: 1
EAX: 00000000 EBX: 00000296 ECX: 7a9d5f5c EDX: c180ff6c
ESI: 00000040 EDI: ee939f7c EBP: c04c7d90 ESP: f1653ecc
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 7a9d5f5c 000000d0 00000000 ee814440 00000000 ee939f7c 01200011 c012c900
 ee938380 eea4fff8 c048d53c ee814440 c0101a87 01200011 ee814440 00000000
 ee939f7c ee814440 00000000 ee939f7c 01200011 c011e9cb f1653fb8 bf9e8d30
Call Trace:
 [<c012c900>] 0xc012c900
 [<c0101a87>] 0xc0101a87
 [<c011e9cb>] 0xc011e9cb
 [<c011f085>] 0xc011f085
eb BUG: unable to handle kernel paging request at 7a9d5f5c
*pde = 00000000 
Oops: 0000 [#5] PREEMPT SMP 
Pid: 2942, comm: Xorg Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
EIP: 0060:[<c015bb0a>] EFLAGS: 00213006 CPU: 1
EAX: 00000000 EBX: c04c7d90 ECX: 7a9d5f5c EDX: c180ff6c
ESI: 00203282 EDI: c04c7d90 EBP: 00000040 ESP: f68adef4
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 7a9d5f5c 000000d0 00203286 00000000 fffffff4 40286454 f6a86800 f81ea6f4
 f6b2d420 f8348c59 f83583e4 f6950080 bfbc1eb4 40286454 c0167680 bfbc1eb4
 f6950080 f6f1e7f8 08a84b40 f68ac000 c0167bb4 0000000d 00203082 f68adf9c
Call Trace:
 [<f81ea6f4>] 0xf81ea6f4
 [<f8348c59>] 0xf8348c59
 [<c0167680>] 0xc0167680
 [<c0167bb4>] 0xc0167bb4
 [<c0122ac3>] 0xc0122ac3
 [<c0122c59>] 0xc0122c59
f4 BUG: unable to handle kernel paging request at 7a9d5f5c
*pde = 00000000 
Oops: 0000 [#6] PREEMPT SMP 
Pid: 1219, comm: udevd Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
EIP: 0060:[<c015b4e5>] EFLAGS: 00010006 CPU: 1
EAX: 00000000 EBX: 00000292 ECX: 7a9d5f5c EDX: c180ff6c
ESI: 00000040 EDI: c018d53c EBP: c04c7d90 ESP: f68fbe34
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 7a9d5f5c 000000d0 f708c00a ee949c80 f73e3720 c018d53c 00000000 c017059b
 f6c12964 f73e3720 fffffff4 c018d53c ee949c80 c0170678 00000000 f708e000
 fffffff4 00001000 ee949c80 c018d51e f173fa20 f70e9680 c018d4d0 f70e96cc
Call Trace:
 [<c018d53c>] 0xc018d53c
 [<c017059b>] 0xc017059b
 [<c018d53c>] 0xc018d53c
 [<c0170678>] 0xc0170678
Warning (Oops_read): Code line not seen, dumping what data is available


>>EIP; c015bb0a <__kmalloc+83/c0>   <=====

>>EBX; c04c7d90 <kmalloc_caches+210/480>
>>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
>>EDI; c04c7d90 <kmalloc_caches+210/480>

Trace; c0194004 <ext3_htree_store_dirent+26/de>
Trace; c019aaa0 <htree_dirblock_to_tree+d6/11b>
Trace; c019ab55 <ext3_htree_fill_tree+70/1cb>
Trace; c01405ce <find_lock_page+10/43>
Trace; c0102cf1 <sysenter_do_call+12/25>

>>EIP; c015b4e5 <kmem_cache_alloc+48/83>   <=====

>>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
>>EDI; c018d53c <show_stat+0/680>
>>EBP; c04c7d90 <kmalloc_caches+210/480>

Trace; c018d53c <show_stat+0/680>
Trace; c017059b <seq_open+23/6d>
Trace; c018d53c <show_stat+0/680>
Trace; c0170678 <single_open+48/68>
Trace; c018d51e <stat_open+4e/6c>
Trace; c018d4d0 <stat_open+0/6c>
Trace; c01887b8 <proc_reg_open+89/ed>
Trace; c017006d <single_release+0/1b>
Trace; c012e9ac <autoremove_wake_function+0/2b>
Trace; c0102cf1 <sysenter_do_call+12/25>

>>EIP; c015b4e5 <kmem_cache_alloc+48/83>   <=====

>>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
>>EBP; c04c7d90 <kmalloc_caches+210/480>

Trace; c012c900 <alloc_pid+18/2b6>
Trace; c0101a87 <copy_thread+2f/f3>
Trace; c011e9cb <copy_process+917/e42>
Trace; c011f085 <do_fork+11a/268>

>>EIP; c015bb0a <__kmalloc+83/c0>   <=====

>>EBX; c04c7d90 <kmalloc_caches+210/480>
>>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
>>ESI; 00203282 <phys_startup_32+103282/c0000000>
>>EDI; c04c7d90 <kmalloc_caches+210/480>

Trace; f81ea6f4 <END_OF_CODE+37c8a6f4/????>
Trace; f8348c59 <END_OF_CODE+37de8c59/????>
Trace; c0167680 <vfs_ioctl+47/5d>
Trace; c0167bb4 <do_vfs_ioctl+446/47c>
Trace; c0122ac3 <do_setitimer+157/2a9>
Trace; c0122c59 <sys_setitimer+44/71>

>>EIP; c015b4e5 <kmem_cache_alloc+48/83>   <=====

>>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
>>EDI; c018d53c <show_stat+0/680>
>>EBP; c04c7d90 <kmalloc_caches+210/480>

Trace; c018d53c <show_stat+0/680>
Trace; c017059b <seq_open+23/6d>
Trace; c018d53c <show_stat+0/680>
Trace; c0170678 <single_open+48/68>


3 warnings and 1 error issued.  Results may not be reliable.

[-- Attachment #4: eeepc.log.gz --]
[-- Type: application/x-gzip, Size: 5441 bytes --]

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Ingo Molnar]

* Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:

> I'm seeing various oopses with -rc4, where -rc3 is fine; config, dmesg
> (captured via netconsole) and decoded oops data attached ¹. The last few
> oopses were followed by a scrambled display and a hard lockup.
> 
> All oopses follow an otherwise successful suspend-to-RAM.

Various folks Cc:-ed. There's been a late, rather large ACPI merge, so
one post-rc3 suspect would be one of these commits:

f12b12a: Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
2d29c6a: Merge branches 'release', 'asus', 'bugzilla-12450', 'cpuidle', 'debug', 'ec', 'misc', 'printk' and 'processor' into release
370154b: ACPI: Kconfig text - Fix the ACPI_CONTAINER module name according to the real module name.
7695fb0: eeepc-laptop: fix oops when changing backlight brightness during eeepc-laptop init
386e4a8: ACPICA: Fix table entry truncation calculation
d96f94c: ACPI: Enable bit 11 in _PDC to advertise hw coord
db1461a: ACPI: struct device - replace bus_id with dev_name(), dev_set_name()
4d93915: ACPI: add missing KERN_* constants to printks
fc5a9f8: ACPI: dock: Don't eval _STA on every show_docked sysfs read
9e3a9d1: ACPI: disable ACPI cleanly when bad RSDP found
9fdd54f: ACPI: delete CPU_IDLE=n code
62663ea: ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc entries
5ec5d38: ACPI: make some IO ports off-limits to AML
3e0676a: ACPICA: add debug dump of BIOS _OSI strings
f3b39f1: ACPI: proc_dir_entry 'video/VGA' already registered
0a3db1c: ACPI: Skip the first two elements in the _BCL package
31878dd: ACPI: remove BM_RLD access from idle entry path
a2b7b01: ACPI: remove locking from PM1x_STS register reads
2b25c9f: eeepc-laptop: use netlink interface
5740294: eeepc-laptop: Implement rfkill hotplugging in eeepc-laptop
c9ddf8f: eeepc-laptop: Check return values from rfkill_register
b5f6f26: eeepc-laptop: Add support for extended hotkeys
ed6f442: asus-laptop: fix label indentation
12d6f35: asus-laptop: update Kconfig for input layer
034ce90: asus-laptop: hotkeys via the generic input interface
2a7dc0d: asus-laptop: use generic netlink interface
1021e21: asus_acpi: Add R1F support
a9df80c: eeepc-laptop: split eeepc_backlight_exit()
2b190e7: panasonic-laptop: fix X[ ARRAY_SIZE(X) ]
4312495: ACPI: Fix crash on ASUS laptops
5d8b532: ACPI suspend: Fix compilation warnings in drivers/acpi/sleep.c
091d71e: PM: Fix compilation warning in kernel/power/main.c

> Also, I see that Fn-Fx don't seem to be reported via /proc/acpi/events any
> more, or at least I'm seeing no evidence of them via acpi_listen (and, not
> coincidentally, I can't adjust the volume etc. via eeepc-acpi-scripts).
> 
> The only other (significant) change is that I've installed X from Debian
> experimental, though -rc3 and 2.6.28.* seem fine with this. (Oh, and I can
> get UXA to cause OOM quite trivially... several Iceweasel tabs is enough.)
> 
> 
> ¹ Yes, I decided not to include symbol names in the running kernel...
> 
> -- 
> | Darren Salt    | linux or ds at              | nr. Ashington, | Toon
> | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
> | + Use more efficient products. Use less.          BE MORE ENERGY EFFICIENT.
> 
> I'll have what the bloke on the floor is having...
> 


> ksymoops 2.4.11 on i686 2.6.29-rc4-eee901.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.6.29-rc4-eee901/ (default)
>      -m /boot/System.map-2.6.29-rc4-eee901 (default)
> 
> Warning: You did not tell me where to find symbol information.  I will
> assume that the log matches the kernel and modules that are running
> right now and I'll use the default options above for symbol resolution.
> If the current kernel and/or modules do not match the log, you can get
> more accurate output by telling me the kernel version and where to find
> map, modules, ksyms etc.  ksymoops -h explains the options.
> 
> Error (regular_file): read_ksyms stat /proc/ksyms failed
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> CPU 1 is now offline
> WARNING: at fs/sysfs/group.c:138 ()
> Pid: 330, comm: pciehpd Not tainted 2.6.29-rc4-eee901 #2
> Call Trace:
>  [<c011fab7>] 0xc011fab7
>  [<c032ca9d>] 0xc032ca9d
>  [<f81760d5>] 0xf81760d5
>  [<c01f112c>] 0xc01f112c
>  [<c0118940>] 0xc0118940
>  [<c011fc82>] 0xc011fc82
>  [<c016b8aa>] 0xc016b8aa
>  [<c0190b6b>] 0xc0190b6b
>  [<c016b9a8>] 0xc016b9a8
>  [<c016b738>] 0xc016b738
>  [<c019102a>] 0xc019102a
>  [<c0191faa>] 0xc0191faa
>  [<c025a8d4>] 0xc025a8d4
>  [<c025a9c9>] 0xc025a9c9
>  [<c01fae3c>] 0xc01fae3c
>  [<c01faf00>] 0xc01faf00
>  [<c0205ca4>] 0xc0205ca4
>  [<c0204a68>] 0xc0204a68
>  [<c0204eb3>] 0xc0204eb3
>  [<c0204e2d>] 0xc0204e2d
>  [<c012bd8f>] 0xc012bd8f
>  [<c012c51d>] 0xc012c51d
>  [<c012c5d1>] 0xc012c5d1
>  [<c012e9ac>] 0xc012e9ac
>  [<c012c51d>] 0xc012c51d
>  [<c012e8de>] 0xc012e8de
>  [<c012e8a6>] 0xc012e8a6
>  [<c010349b>] 0xc010349b
> BUG: unable to handle kernel NULL pointer dereference at 00000010
> *pde = 00000000 
> Oops: 0000 [#1] PREEMPT SMP 
> Pid: 330, comm: pciehpd Tainted: G        W  (2.6.29-rc4-eee901 #2) 901
> EIP: 0060:[<c03ccef7>] EFLAGS: 00010246 CPU: 0
> Using defaults from ksymoops -t elf32-i386 -a i386
> EAX: 00000000 EBX: 00000001 ECX: 00000046 EDX: 00000001
> ESI: f17dd470 EDI: f70f7c5c EBP: 00000000 ESP: f7339f00
>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
>  f17dd45c 00000000 f70f7c5c c025a9c9 f7060b40 f7311a80ff 83 c0 89 83 cf db 74 19 f6 06 01 74 11 6a 00 ---[ end trace 449537779ba90603 ]---
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> 
> Trace; c011fab7 <warn_slowpath+7d/94>
> Trace; c032ca9d <__alloc_skb+4b/103>
> Trace; f81760d5 <END_OF_CODE+37c160d5/????>
> Trace; c01f112c <cpumask_next_and+23/33>
> Trace; c0118940 <find_busiest_group+242/725>
> Trace; c011fc82 <__call_console_drivers+51/5d>
> Trace; c016b8aa <find_inode+1b/56>
> Trace; c0190b6b <sysfs_ilookup_test+0/d>
> Trace; c016b9a8 <ifind+3a/74>
> Trace; c016b738 <iput+21/4a>
> Trace; c019102a <sysfs_addrm_finish+4a/1ae>
> Trace; c0191faa <sysfs_remove_group+34/8d>
> Trace; c025a8d4 <device_del+32/11f>
> Trace; c025a9c9 <device_unregister+8/10>
> Trace; c01fae3c <pci_stop_dev+20/3a>
> Trace; c01faf00 <pci_remove_bus_device+27/88>
> Trace; c0205ca4 <pciehp_unconfigure_device+108/180>
> Trace; c0204a68 <pciehp_disable_slot+12d/1d6>
> Trace; c0204eb3 <pciehp_power_thread+86/cd>
> Trace; c0204e2d <pciehp_power_thread+0/cd>
> Trace; c012bd8f <run_workqueue+71/f1>
> Trace; c012c51d <worker_thread+0/bf>
> Trace; c012c5d1 <worker_thread+b4/bf>
> Trace; c012e9ac <autoremove_wake_function+0/2b>
> Trace; c012c51d <worker_thread+0/bf>
> Trace; c012e8de <kthread+38/5e>
> Trace; c012e8a6 <kthread+0/5e>
> Trace; c010349b <kernel_thread_helper+7/10>
> 
> >>EIP; c03ccef7 <klist_put+f/59>   <=====
> 
> BUG: unable to handle kernel paging request at 7a9d5f5c
> *pde = 00000000 
> Oops: 0000 [#2] PREEMPT SMP 
> Pid: 4094, comm: bash Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
> EIP: 0060:[<c015bb0a>] EFLAGS: 00010006 CPU: 1
> EAX: 00000000 EBX: c04c7d90 ECX: 7a9d5f5c EDX: c180ff6c
> ESI: 00000282 EDI: c04c7d90 EBP: 00000040 ESP: ee9f1e38
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>  7a9d5f5c 000080d0 f173f7c0 c194c488 7ac532a8 fe280a2e c194c488 c0194004
>  f173f7c0 c194c488 f6e64498 0000003e f6e02458 c019aaa0 c194c488 00000000
>  ee949600 c194cff8 00000000 ee949600 ee949600 f6e02458 00000000 c019ab55
> Call Trace:
>  [<c0194004>] 0xc0194004
>  [<c019aaa0>] 0xc019aaa0
>  [<c019ab55>] 0xc019ab55
>  [<c01405ce>] 0xc01405ce
>  [<c0102cf1>] 0xc0102cf1
> 56 BUG: unable to handle kernel paging request at 7a9d5f5c
> *pde = 00000000 
> Oops: 0000 [#3] PREEMPT SMP 
> Pid: 3147, comm: xfce4-systemloa Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
> EIP: 0060:[<c015b4e5>] EFLAGS: 00010006 CPU: 1
> EAX: 00000000 EBX: 00000292 ECX: 7a9d5f5c EDX: c180ff6c
> ESI: 00000040 EDI: c018d53c EBP: c04c7d90 ESP: f16ebe34
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>  7a9d5f5c 000000d0 f702c00a ee949300 f73e35e0 c018d53c 00000000 c017059b
>  00000000 f73e35e0 fffffff4 c018d53c ee949300 c0170678 00000000 f7029000
>  fffffff4 00001000 ee949300 c018d51e f173f2a0 f70e9680 c018d4d0 f70e96cc
> Call Trace:
>  [<c018d53c>] 0xc018d53c
>  [<c017059b>] 0xc017059b
>  [<c018d53c>] 0xc018d53c
>  [<c0170678>] 0xc0170678
>  [<c018d51e>] 0xc018d51e
>  [<c018d4d0>] 0xc018d4d0
>  [<c01887b8>] 0xc01887b8
>  [<c017006d>] 0xc017006d
>  [<c012e9ac>] 0xc012e9ac
>  [<c0102cf1>] 0xc0102cf1
> BUG: unable to handle kernel paging request at 7a9d5f5c
> *pde = 00000000 
> Oops: 0000 [#4] PREEMPT SMP 
> Pid: 3137, comm: xfce4-panel Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
> EIP: 0060:[<c015b4e5>] EFLAGS: 00010006 CPU: 1
> EAX: 00000000 EBX: 00000296 ECX: 7a9d5f5c EDX: c180ff6c
> ESI: 00000040 EDI: ee939f7c EBP: c04c7d90 ESP: f1653ecc
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>  7a9d5f5c 000000d0 00000000 ee814440 00000000 ee939f7c 01200011 c012c900
>  ee938380 eea4fff8 c048d53c ee814440 c0101a87 01200011 ee814440 00000000
>  ee939f7c ee814440 00000000 ee939f7c 01200011 c011e9cb f1653fb8 bf9e8d30
> Call Trace:
>  [<c012c900>] 0xc012c900
>  [<c0101a87>] 0xc0101a87
>  [<c011e9cb>] 0xc011e9cb
>  [<c011f085>] 0xc011f085
> eb BUG: unable to handle kernel paging request at 7a9d5f5c
> *pde = 00000000 
> Oops: 0000 [#5] PREEMPT SMP 
> Pid: 2942, comm: Xorg Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
> EIP: 0060:[<c015bb0a>] EFLAGS: 00213006 CPU: 1
> EAX: 00000000 EBX: c04c7d90 ECX: 7a9d5f5c EDX: c180ff6c
> ESI: 00203282 EDI: c04c7d90 EBP: 00000040 ESP: f68adef4
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>  7a9d5f5c 000000d0 00203286 00000000 fffffff4 40286454 f6a86800 f81ea6f4
>  f6b2d420 f8348c59 f83583e4 f6950080 bfbc1eb4 40286454 c0167680 bfbc1eb4
>  f6950080 f6f1e7f8 08a84b40 f68ac000 c0167bb4 0000000d 00203082 f68adf9c
> Call Trace:
>  [<f81ea6f4>] 0xf81ea6f4
>  [<f8348c59>] 0xf8348c59
>  [<c0167680>] 0xc0167680
>  [<c0167bb4>] 0xc0167bb4
>  [<c0122ac3>] 0xc0122ac3
>  [<c0122c59>] 0xc0122c59
> f4 BUG: unable to handle kernel paging request at 7a9d5f5c
> *pde = 00000000 
> Oops: 0000 [#6] PREEMPT SMP 
> Pid: 1219, comm: udevd Tainted: G      D W  (2.6.29-rc4-eee901 #2) 901
> EIP: 0060:[<c015b4e5>] EFLAGS: 00010006 CPU: 1
> EAX: 00000000 EBX: 00000292 ECX: 7a9d5f5c EDX: c180ff6c
> ESI: 00000040 EDI: c018d53c EBP: c04c7d90 ESP: f68fbe34
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>  7a9d5f5c 000000d0 f708c00a ee949c80 f73e3720 c018d53c 00000000 c017059b
>  f6c12964 f73e3720 fffffff4 c018d53c ee949c80 c0170678 00000000 f708e000
>  fffffff4 00001000 ee949c80 c018d51e f173fa20 f70e9680 c018d4d0 f70e96cc
> Call Trace:
>  [<c018d53c>] 0xc018d53c
>  [<c017059b>] 0xc017059b
>  [<c018d53c>] 0xc018d53c
>  [<c0170678>] 0xc0170678
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> 
> >>EIP; c015bb0a <__kmalloc+83/c0>   <=====
> 
> >>EBX; c04c7d90 <kmalloc_caches+210/480>
> >>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
> >>EDI; c04c7d90 <kmalloc_caches+210/480>
> 
> Trace; c0194004 <ext3_htree_store_dirent+26/de>
> Trace; c019aaa0 <htree_dirblock_to_tree+d6/11b>
> Trace; c019ab55 <ext3_htree_fill_tree+70/1cb>
> Trace; c01405ce <find_lock_page+10/43>
> Trace; c0102cf1 <sysenter_do_call+12/25>
> 
> >>EIP; c015b4e5 <kmem_cache_alloc+48/83>   <=====
> 
> >>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
> >>EDI; c018d53c <show_stat+0/680>
> >>EBP; c04c7d90 <kmalloc_caches+210/480>
> 
> Trace; c018d53c <show_stat+0/680>
> Trace; c017059b <seq_open+23/6d>
> Trace; c018d53c <show_stat+0/680>
> Trace; c0170678 <single_open+48/68>
> Trace; c018d51e <stat_open+4e/6c>
> Trace; c018d4d0 <stat_open+0/6c>
> Trace; c01887b8 <proc_reg_open+89/ed>
> Trace; c017006d <single_release+0/1b>
> Trace; c012e9ac <autoremove_wake_function+0/2b>
> Trace; c0102cf1 <sysenter_do_call+12/25>
> 
> >>EIP; c015b4e5 <kmem_cache_alloc+48/83>   <=====
> 
> >>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
> >>EBP; c04c7d90 <kmalloc_caches+210/480>
> 
> Trace; c012c900 <alloc_pid+18/2b6>
> Trace; c0101a87 <copy_thread+2f/f3>
> Trace; c011e9cb <copy_process+917/e42>
> Trace; c011f085 <do_fork+11a/268>
> 
> >>EIP; c015bb0a <__kmalloc+83/c0>   <=====
> 
> >>EBX; c04c7d90 <kmalloc_caches+210/480>
> >>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
> >>ESI; 00203282 <phys_startup_32+103282/c0000000>
> >>EDI; c04c7d90 <kmalloc_caches+210/480>
> 
> Trace; f81ea6f4 <END_OF_CODE+37c8a6f4/????>
> Trace; f8348c59 <END_OF_CODE+37de8c59/????>
> Trace; c0167680 <vfs_ioctl+47/5d>
> Trace; c0167bb4 <do_vfs_ioctl+446/47c>
> Trace; c0122ac3 <do_setitimer+157/2a9>
> Trace; c0122c59 <sys_setitimer+44/71>
> 
> >>EIP; c015b4e5 <kmem_cache_alloc+48/83>   <=====
> 
> >>ECX; 7a9d5f5c <phys_startup_32+7a8d5f5c/c0000000>
> >>EDI; c018d53c <show_stat+0/680>
> >>EBP; c04c7d90 <kmalloc_caches+210/480>
> 
> Trace; c018d53c <show_stat+0/680>
> Trace; c017059b <seq_open+23/6d>
> Trace; c018d53c <show_stat+0/680>
> Trace; c0170678 <single_open+48/68>
> 
> 
> 3 warnings and 1 error issued.  Results may not be reliable.


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Darren Salt]

[Adding Matthew Garrett & Corentin Chary to Cc]

I demand that Ingo Molnar may or may not have written...

> * Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
>> I'm seeing various oopses with -rc4, where -rc3 is fine; config, dmesg
>> (captured via netconsole) and decoded oops data attached ¹. The last few
>> oopses were followed by a scrambled display and a hard lockup.

>> All oopses follow an otherwise successful suspend-to-RAM.

> Various folks Cc:-ed. There's been a late, rather large ACPI merge, so
> one post-rc3 suspect would be one of these commits:

[snip]
> 7695fb0: eeepc-laptop: fix oops when changing backlight brightness during
eeepc-laptop init

No, that one's harmless :-)

[snip]
> 2b25c9f: eeepc-laptop: use netlink interface

That one makes acpid (apparently) useless. The rest of the commit description
is:
    To be prepared for /proc/acpi/event removal we export events
    also through generic netlink interface.

Note that "also". The actual effect of the patch is "instead".

Adding the two removed lines (but removing the post-increment of the event
count) fixes this.

> 5740294: eeepc-laptop: Implement rfkill hotplugging in eeepc-laptop

Reverting this fixes the rfkill oops; things work correctly again. I don't
know why this appears to be needed, since things work fine without this patch
‒ both Fn-F2 and echoing to /sys/class/rfkill/rfkill0/state ‒ even when I
start up with init=/bin/sh and test directly from that shell.

(901; BIOS rev. 1808.)

[snip]
> 2a7dc0d: asus-laptop: use generic netlink interface

That one also says "also" where it should say "instead" (not that it affects
me).

... oh yes, there's a long delay between output of these two lines during
boot:
  input: ETPS/2 Elantech Touchpad as /class/input/input5
  eeepc: Hotkey init flags 0x41
(not seen in .28 or .28.1; not checked later .28.*.)

Anyway, a patch for the ACPI reporting problems will follow this message.

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output less CO2 => avoid massive flooding.    TIME IS RUNNING OUT *FAST*.

Life is that brief interlude between nothingness and eternity.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.29-rc4] Restore ACPI reporting via /proc/acpi/events for EeePC & other Asus laptops.

[Darren Salt]

The descriptions for the following two commits
  2a7dc0d8c60325e9bf820900bf919430e5a419ab (asus-laptop)
  2b25c9f01aa58d48129b2f93748dfb5d1f7ab0a2 (eeepc-laptop)
say that events should ALSO be exported via netlink, but the effect is that
they are INSTEAD exported via netlink. The latter commit breaks use of acpid
on my EeePC 901.

Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>

diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 56af6cf..42ecf6a 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -832,6 +832,8 @@ static void asus_hotk_notify(acpi_handle handle, u32
event, void *data)
 		lcd_blank(FB_BLANK_POWERDOWN);
 	}
 
+	acpi_bus_generate_proc_event(ehotk->device, event,
+				     ehotk->event_count[event % 128]);
 	acpi_bus_generate_netlink_event(hotk->device->pnp.device_class,
 					dev_name(&hotk->device->dev), event,
 					hotk->event_count[event % 128]++);
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index 786ed86..8511891 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -561,6 +561,8 @@ static void eeepc_hotk_notify(acpi_handle handle, u32
event, void *data)
 		return;
 	if (event >= NOTIFY_BRN_MIN && event <= NOTIFY_BRN_MAX)
 		notify_brn();
+	acpi_bus_generate_proc_event(ehotk->device, event,
+				     ehotk->event_count[event % 128]);
 	acpi_bus_generate_netlink_event(ehotk->device->pnp.device_class,
 					dev_name(&ehotk->device->dev), event,
 					ehotk->event_count[event % 128]++);

-- 
| Darren Salt    | d @ youmustbejoking,demon,co,uk | nr. Ashington, | Toon
| RISC OS, Linux | s   zap,tartarus,org            | Northumberland | Army
| + Use more efficient products. Use less.          BE MORE ENERGY EFFICIENT.

Never drink from your finger bowl; it contains only water.

Re: [PATCH 2.6.29-rc4] Restore ACPI reporting via /proc/acpi/events for EeePC & other Asus laptops.

[Corentin Chary]

On Tuesday 10 February 2009 15:54:56 Darren Salt wrote:
> The descriptions for the following two commits
>   2a7dc0d8c60325e9bf820900bf919430e5a419ab (asus-laptop)
>   2b25c9f01aa58d48129b2f93748dfb5d1f7ab0a2 (eeepc-laptop)
> say that events should ALSO be exported via netlink, but the effect is that
> they are INSTEAD exported via netlink. The latter commit breaks use of
> acpid on my EeePC 901.

Hi,
There was already two patch for that on the ml

http://patchwork.kernel.org/patch/7356/
http://patchwork.kernel.org/patch/7357/

Thanks

-- 
Corentin Chary
http://xf.iksaif.net

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Matthew Garrett]

On Tue, Feb 10, 2009 at 02:12:44PM +0000, Darren Salt wrote:

> Reverting this fixes the rfkill oops; things work correctly again. I don't
> know why this appears to be needed, since things work fine without this patch
> ‒ both Fn-F2 and echoing to /sys/class/rfkill/rfkill0/state ‒ even when I
> start up with init=/bin/sh and test directly from that shell.

If this is BIOS version specific I'm going to be upset, but the general 
case behaviour is that rfkill only works on the 901 if you either (a) 
pass force=1 to pciehp (which you shouldn't) or (b) have native support 
in a driver. My /guess/ is that you've got pciehp loaded, and there's 
some kind of awkward race between it and eeepc-laptop.

>   input: ETPS/2 Elantech Touchpad as /class/input/input5
>   eeepc: Hotkey init flags 0x41
> (not seen in .28 or .28.1; not checked later .28.*.)

BIOS bug. There's an explicit delay in the eee bios for some reason, and 
I haven't found any straightforward way to avoid it.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Darren Salt]

I demand that Matthew Garrett may or may not have written...

> On Tue, Feb 10, 2009 at 02:12:44PM +0000, Darren Salt wrote:
>> Reverting this fixes the rfkill oops; things work correctly again. I don't
>> know why this appears to be needed, since things work fine without this
>> patch ‒ both Fn-F2 and echoing to /sys/class/rfkill/rfkill0/state ‒ even
>> when I start up with init=/bin/sh and test directly from that shell.

> If this is BIOS version specific I'm going to be upset, but the general
> case behaviour is that rfkill only works on the 901 if you either (a) pass
> force=1 to pciehp (which you shouldn't) or (b) have native support in a
> driver. My /guess/ is that you've got pciehp loaded, and there's some kind
> of awkward race between it and eeepc-laptop.

I have; and yes, pciehp_force=1.

As things stand, this is likely to be a problem for anybody using lenny on
Eee hardware and upgrading (on their own) to 2.6.29, given that that
workaround is present in eeepc-acpi-scripts in lenny.

Anyway, removing that option fixes the problem.

>> [long delay between these two lines]
>>   input: ETPS/2 Elantech Touchpad as /class/input/input5
>>   eeepc: Hotkey init flags 0x41
>> (not seen in .28 or .28.1; not checked later .28.*.)

> BIOS bug. There's an explicit delay in the eee bios for some reason, and 
> I haven't found any straightforward way to avoid it.

BIOS bug or no, the fact remains that this is (AFAICS) a regression.

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less.          BE MORE ENERGY EFFICIENT.

  10 PRINT "I used to do this in Dixons": POKE 23692,255: GO TO 10
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Matthew Garrett]

On Tue, Feb 10, 2009 at 03:15:21PM +0000, Darren Salt wrote:

> As things stand, this is likely to be a problem for anybody using lenny on
> Eee hardware and upgrading (on their own) to 2.6.29, given that that
> workaround is present in eeepc-acpi-scripts in lenny.
> 
> Anyway, removing that option fixes the problem.

Ok. I'll look into ensuring that these don't collide, but fundamentally 
the problem here is distributions using broken options rather than 
fixing the problem properly in the first place.

> > BIOS bug. There's an explicit delay in the eee bios for some reason, and 
> > I haven't found any straightforward way to avoid it.
> 
> BIOS bug or no, the fact remains that this is (AFAICS) a regression.

You don't get properly working hotkeys otherwise, to the best of my 
recollection. There's an entry on the kernel bugzilla about this 
somewhere.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Darren Salt]

I demand that Matthew Garrett may or may not have written...

> On Tue, Feb 10, 2009 at 03:15:21PM +0000, Darren Salt wrote:
>> As things stand, this is likely to be a problem for anybody using lenny on
>> Eee hardware and upgrading (on their own) to 2.6.29, given that that
>> workaround is present in eeepc-acpi-scripts in lenny.
>> Anyway, removing that option fixes the problem.

> Ok. I'll look into ensuring that these don't collide, but fundamentally the
> problem here is distributions using broken options rather than fixing the
> problem properly in the first place.

Not so much "broken options" as "using the ony available workaround at the
time", I think. I have no idea what action other than using this option was
taken.

>>> BIOS bug. There's an explicit delay in the eee bios for some reason,
>>> and I haven't found any straightforward way to avoid it.
>> BIOS bug or no, the fact remains that this is (AFAICS) a regression.

> You don't get properly working hotkeys otherwise, to the best of my
> recollection.

I can't say that I've noticed any problems.

> There's an entry on the kernel bugzilla about this somewhere.

This one, I think: http://bugzilla.kernel.org/show_bug.cgi?id=12243

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Kill all extremists!

"The name's Borg, James Borg. Prepare to be assimilated, Miss Moneypenny."

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Matthew Garrett]

Can you try this (entirely untested - I don't have access to the 
hardware right now) patch? It should register the eee code with the PCI 
hotplug core. With luck that'll avoid the oops.

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index b3866ad..75a560b 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -307,6 +307,7 @@ config EEEPC_LAPTOP
 	select BACKLIGHT_CLASS_DEVICE
 	select HWMON
 	select RFKILL
+	select HOTPLUG_PCI
 	---help---
 	  This driver supports the Fn-Fx keys on Eee PC laptops.
 	  It also adds the ability to switch camera/wlan on/off.
diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 786ed86..9e5fa4c 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -31,6 +31,7 @@
 #include <linux/input.h>
 #include <linux/rfkill.h>
 #include <linux/pci.h>
+#include <linux/pci_hotplug.h>
 
 #define EEEPC_LAPTOP_VERSION	"0.1"
 
@@ -132,6 +133,7 @@ struct eeepc_hotk {
 	u16 *keycode_map;
 	struct rfkill *eeepc_wlan_rfkill;
 	struct rfkill *eeepc_bluetooth_rfkill;
+	struct hotplug_slot *hotplug_slot;
 };
 
 /* The actual device the driver binds to */
@@ -194,6 +196,15 @@ static struct acpi_driver eeepc_hotk_driver = {
 	},
 };
 
+/* PCI hotplug ops */
+static int eeepc_get_adapter_status (struct hotplug_slot *slot, u8 *value);
+
+static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
+	.owner = THIS_MODULE,
+	.get_adapter_status = eeepc_get_adapter_status,
+	.get_power_status = eeepc_get_adapter_status,
+};
+
 /* The backlight device /sys/class/backlight */
 static struct backlight_device *eeepc_backlight_device;
 
@@ -519,6 +530,19 @@ static void notify_brn(void)
 		bd->props.brightness = read_brightness(bd);
 }
 
+static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
+				    u8 *value)
+{
+	int val = get_acpi(CM_ASL_WLAN);
+
+	if (val == 1 || val == 0)
+		*value = val;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 {
 	struct pci_dev *dev;
@@ -620,6 +644,53 @@ static void eeepc_unregister_rfkill_notifier(char *node)
 	}
 }
 
+static void eeepc_cleanup_pci_hotplug(struct hotplug_slot *hotplug_slot)
+{
+	kfree(hotplug_slot->info);
+	kfree(hotplug_slot);
+}
+
+static int eeepc_setup_pci_hotplug(void)
+{
+	int ret = -ENOMEM;
+	struct pci_bus *bus = pci_find_bus(0, 1);
+
+	if (!bus) {
+		printk(EEEPC_ERR "Unable to find wifi PCI bus\n");
+		return -ENODEV;
+	}
+
+	ehotk->hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
+	if (!ehotk->hotplug_slot)
+		goto error_slot;
+
+	ehotk->hotplug_slot->info = kzalloc(sizeof(struct hotplug_slot_info),
+					    GFP_KERNEL);
+	if (!ehotk->hotplug_slot->info)
+		goto error_info;
+
+	ehotk->hotplug_slot->private = ehotk;
+	ehotk->hotplug_slot->release = &eeepc_cleanup_pci_hotplug;
+	ehotk->hotplug_slot->ops = &eeepc_hotplug_slot_ops;
+	eeepc_get_adapter_status(ehotk->hotplug_slot,
+				 &ehotk->hotplug_slot->info->adapter_status);
+
+	ret = pci_hp_register(ehotk->hotplug_slot, bus, 0, "eeepc-wifi");
+	if (ret) {
+		printk(EEEPC_ERR "Unable to register hotplug slot - %d\n", ret);
+		goto error_register;
+	}
+
+	return 0;
+	
+error_register:
+	kfree(ehotk->hotplug_slot->info);
+error_info:
+	kfree(ehotk->hotplug_slot);
+error_slot:
+	return ret;
+}
+
 static int eeepc_hotk_add(struct acpi_device *device)
 {
 	acpi_status status = AE_OK;
@@ -700,11 +771,17 @@ static int eeepc_hotk_add(struct acpi_device *device)
 			goto bluetooth_fail;
 	}
 
+	result = eeepc_setup_pci_hotplug();
+	if (result)
+		goto pci_fail;
+
 	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
 	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
 
 	return 0;
-
+ pci_fail:
+	if (ehotk->eeepc_bluetooth_rfkill)
+		rfkill_unregister(ehotk->eeepc_bluetooth_rfkill);
  bluetooth_fail:
 	if (ehotk->eeepc_bluetooth_rfkill)
 		rfkill_free(ehotk->eeepc_bluetooth_rfkill);
@@ -734,6 +811,8 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
 
+	pci_hp_deregister(ehotk->hotplug_slot);
+
 	kfree(ehotk);
 	return 0;
 }


-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Darren Salt]

I demand that Matthew Garrett may or may not have written...

> Can you try this (entirely untested - I don't have access to the hardware
> right now) patch? It should register the eee code with the PCI hotplug
> core. With luck that'll avoid the oops.

> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index b3866ad..75a560b 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -307,6 +307,7 @@ config EEEPC_LAPTOP
>  	select BACKLIGHT_CLASS_DEVICE
>  	select HWMON
>  	select RFKILL
> +	select HOTPLUG_PCI

Not HOTPLUG_PCI_PCIE?

With that selected (I see no point in testing this otherwise) *and*
pciehp_force=1, I get -EBUSY when the hotplug slot registration is attempted
and no wireless, bluetooth or hot key reporting; wireless & bluetooth are
switched off at that point (I made sure that they were enabled via BIOS
setup). Without that option, all is fine.

(As usual with my kernel builds, these are built in.)

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Travel less. Share transport more.           PRODUCE LESS CARBON DIOXIDE.

The man who raises a fist has run out of ideas.

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Matthew Garrett]

On Tue, Feb 24, 2009 at 03:29:36PM +0000, Darren Salt wrote:

> Not HOTPLUG_PCI_PCIE?

No - it just depends on the hotplug PCI core.

> With that selected (I see no point in testing this otherwise) *and*
> pciehp_force=1, I get -EBUSY when the hotplug slot registration is attempted
> and no wireless, bluetooth or hot key reporting; wireless & bluetooth are
> switched off at that point (I made sure that they were enabled via BIOS
> setup). Without that option, all is fine.

Right, so that sounds like everything works as expected. I guess to 
avoid breaking existing setups we should probably be a bit nicer there. 
Can you test whether this one works?

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index b3866ad..75a560b 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -307,6 +307,7 @@ config EEEPC_LAPTOP
 	select BACKLIGHT_CLASS_DEVICE
 	select HWMON
 	select RFKILL
+	select HOTPLUG_PCI
 	---help---
 	  This driver supports the Fn-Fx keys on Eee PC laptops.
 	  It also adds the ability to switch camera/wlan on/off.
diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 786ed86..e2412c9 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -31,6 +31,7 @@
 #include <linux/input.h>
 #include <linux/rfkill.h>
 #include <linux/pci.h>
+#include <linux/pci_hotplug.h>
 
 #define EEEPC_LAPTOP_VERSION	"0.1"
 
@@ -132,6 +133,7 @@ struct eeepc_hotk {
 	u16 *keycode_map;
 	struct rfkill *eeepc_wlan_rfkill;
 	struct rfkill *eeepc_bluetooth_rfkill;
+	struct hotplug_slot *hotplug_slot;
 };
 
 /* The actual device the driver binds to */
@@ -194,6 +196,15 @@ static struct acpi_driver eeepc_hotk_driver = {
 	},
 };
 
+/* PCI hotplug ops */
+static int eeepc_get_adapter_status (struct hotplug_slot *slot, u8 *value);
+
+static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
+	.owner = THIS_MODULE,
+	.get_adapter_status = eeepc_get_adapter_status,
+	.get_power_status = eeepc_get_adapter_status,
+};
+
 /* The backlight device /sys/class/backlight */
 static struct backlight_device *eeepc_backlight_device;
 
@@ -519,6 +530,19 @@ static void notify_brn(void)
 		bd->props.brightness = read_brightness(bd);
 }
 
+static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
+				    u8 *value)
+{
+	int val = get_acpi(CM_ASL_WLAN);
+
+	if (val == 1 || val == 0)
+		*value = val;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 {
 	struct pci_dev *dev;
@@ -620,6 +644,54 @@ static void eeepc_unregister_rfkill_notifier(char *node)
 	}
 }
 
+static void eeepc_cleanup_pci_hotplug(struct hotplug_slot *hotplug_slot)
+{
+	kfree(hotplug_slot->info);
+	kfree(hotplug_slot);
+}
+
+static int eeepc_setup_pci_hotplug(void)
+{
+	int ret = -ENOMEM;
+	struct pci_bus *bus = pci_find_bus(0, 1);
+
+	if (!bus) {
+		printk(EEEPC_ERR "Unable to find wifi PCI bus\n");
+		return -ENODEV;
+	}
+
+	ehotk->hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
+	if (!ehotk->hotplug_slot)
+		goto error_slot;
+
+	ehotk->hotplug_slot->info = kzalloc(sizeof(struct hotplug_slot_info),
+					    GFP_KERNEL);
+	if (!ehotk->hotplug_slot->info)
+		goto error_info;
+
+	ehotk->hotplug_slot->private = ehotk;
+	ehotk->hotplug_slot->release = &eeepc_cleanup_pci_hotplug;
+	ehotk->hotplug_slot->ops = &eeepc_hotplug_slot_ops;
+	eeepc_get_adapter_status(ehotk->hotplug_slot,
+				 &ehotk->hotplug_slot->info->adapter_status);
+
+	ret = pci_hp_register(ehotk->hotplug_slot, bus, 0, "eeepc-wifi");
+	if (ret) {
+		printk(EEEPC_ERR "Unable to register hotplug slot - %d\n", ret);
+		goto error_register;
+	}
+
+	return 0;
+	
+error_register:
+	kfree(ehotk->hotplug_slot->info);
+error_info:
+	kfree(ehotk->hotplug_slot);
+	ehotk->hotplug_slot = NULL;
+error_slot:
+	return ret;
+}
+
 static int eeepc_hotk_add(struct acpi_device *device)
 {
 	acpi_status status = AE_OK;
@@ -700,11 +772,25 @@ static int eeepc_hotk_add(struct acpi_device *device)
 			goto bluetooth_fail;
 	}
 
+	result = eeepc_setup_pci_hotplug();
+
+	/*
+	 * If we get -EBUSY then something else is handling the PCI hotplug -
+	 * don't fail in this case
+	 */
+
+	if (result == -EBUSY)
+		return 0;
+	else if (result)
+		goto pci_fail;
+
 	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
 	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
 
 	return 0;
-
+ pci_fail:
+	if (ehotk->eeepc_bluetooth_rfkill)
+		rfkill_unregister(ehotk->eeepc_bluetooth_rfkill);
  bluetooth_fail:
 	if (ehotk->eeepc_bluetooth_rfkill)
 		rfkill_free(ehotk->eeepc_bluetooth_rfkill);
@@ -731,8 +817,11 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	if (ACPI_FAILURE(status))
 		printk(EEEPC_ERR "Error removing notify handler\n");
 
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+	if (ehotk->hotplug_slot) {
+		eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
+		eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+		pci_hp_deregister(ehotk->hotplug_slot);
+	}
 
 	kfree(ehotk);
 	return 0;


-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Darren Salt]

I demand that Matthew Garrett may or may not have written...

> On Tue, Feb 24, 2009 at 03:29:36PM +0000, Darren Salt wrote:
>> Not HOTPLUG_PCI_PCIE?

> No - it just depends on the hotplug PCI core.

>> With that selected (I see no point in testing this otherwise) *and*
>> pciehp_force=1, I get -EBUSY when the hotplug slot registration is
>> attempted and no wireless, bluetooth or hot key reporting; wireless &
>> bluetooth are switched off at that point (I made sure that they were
>> enabled via BIOS setup). Without that option, all is fine.

> Right, so that sounds like everything works as expected. I guess to avoid
> breaking existing setups we should probably be a bit nicer there. Can you
> test whether this one works?

Works fine, AFAICS. If that's what's to be committed, then:
  Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less.     USE FEWER RESOURCES.

Beware of quantum ducks. Quark! Quark!

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Corentin Chary]

On Tue, Feb 10, 2009 at 4:45 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Feb 10, 2009 at 03:15:21PM +0000, Darren Salt wrote:
>
>> As things stand, this is likely to be a problem for anybody using lenny on
>> Eee hardware and upgrading (on their own) to 2.6.29, given that that
>> workaround is present in eeepc-acpi-scripts in lenny.
>>
>> Anyway, removing that option fixes the problem.
>
> Ok. I'll look into ensuring that these don't collide, but fundamentally
> the problem here is distributions using broken options rather than
> fixing the problem properly in the first place.
>
>> > BIOS bug. There's an explicit delay in the eee bios for some reason, and
>> > I haven't found any straightforward way to avoid it.
>>
>> BIOS bug or no, the fact remains that this is (AFAICS) a regression.
>
> You don't get properly working hotkeys otherwise, to the best of my
> recollection. There's an entry on the kernel bugzilla about this
> somewhere.
> --
> Matthew Garrett | mjg59@srcf.ucam.org

http://bugzilla.kernel.org/show_bug.cgi?id=12243
If I understand things correctly, this was already the case before,
but the kernel boot was slower, so we could'nt see that.
If it's not the case, someone with a 901 should try bisecting (I only
have a 701).


-- 
Corentin Chary
http://xf.iksaif.net

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Darren Salt]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

I demand that Corentin Chary may or may not have written...

> On Tue, Feb 10, 2009 at 4:45 PM, Matthew Garrett <mjg59@srcf.ucam.org>
> wrote:
[snip; long delay when initialising eeepc-laptop]
>>>> BIOS bug. There's an explicit delay in the eee bios for some reason, and
>>>> I haven't found any straightforward way to avoid it.
>>> BIOS bug or no, the fact remains that this is (AFAICS) a regression.
>> You don't get properly working hotkeys otherwise, to the best of my
>> recollection. There's an entry on the kernel bugzilla about this
>> somewhere.

> http://bugzilla.kernel.org/show_bug.cgi?id=12243
> If I understand things correctly, this was already the case before, but the
> kernel boot was slower, so we couldn't see that. If it's not the case,
> someone with a 901 should try bisecting (I only have a 701).

I have some timings...

>From 2.6.28.4:
[    0.898903] eeepc: Eee PC Hotkey Driver
[    0.902414] eeepc: Hotkey init (getting ACPI bus status)
[    0.905913] eeepc: Hotkey init (init flags)
[    2.620193] eeepc: Hotkey init flags 0x41
[    2.626667] eeepc: Get control methods supported: 0x101713
[    2.630215] input: Asus EeePC extra buttons as /class/input/input4

>From 2.6.29-rc4:

[    2.141971] eeepc: Eee PC Hotkey Driver
[    2.145325] eeepc: Hotkey init (getting ACPI bus status)
[    2.148555] eeepc: Hotkey init (init flags)
[    2.286445] usb 5-1: new full speed USB device using uhci_hcd and address 2
[... USB Bluetooth device; Elantech test ...]
[    2.780187] input: ETPS/2 Elantech Touchpad as /class/input/input5
[   28.088399] eeepc: Hotkey init flags 0x41
[   28.094880] eeepc: Get control methods supported: 0x101713
[   28.098425] input: Asus EeePC extra buttons as /class/input/input6

Config is as in my first posting in this thread; kernel logs are attached.
The following patch is applied:

--- ./drivers/platform/x86/eeepc-laptop.c~	2009-02-10 16:40:18.000000000 +0000
+++ ./drivers/platform/x86/eeepc-laptop.c	2009-02-10 16:40:18.000000000 +0000
@@ -452,10 +452,15 @@
 	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
 	int result;
 
+	printk(EEEPC_NOTICE "Hotkey init (getting ACPI bus status)\n");
 	result = acpi_bus_get_status(ehotk->device);
 	if (result)
+	{
+		printk(EEEPC_ERR "Hotkey init aborted (%d)\n", result);
 		return result;
+	}
 	if (ehotk->device->status.present) {
+		printk(EEEPC_NOTICE "Hotkey init (init flags)\n");
 		if (write_acpi_int(ehotk->handle, "INIT", ehotk->init_flag,
 				    &buffer)) {
 			printk(EEEPC_ERR "Hotkey initialization failed\n");

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy less and make it last longer.         INDUSTRY CAUSES GLOBAL WARMING.

If at first you don't succeed, give up. No use being a damn fool.

[-- Attachment #2: dmesg-28.4.txt.gz --]
[-- Type: application/x-gzip, Size: 10424 bytes --]

[-- Attachment #3: dmesg-29-rc4.txt.gz --]
[-- Type: application/x-gzip, Size: 10777 bytes --]

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[Matthew Garrett]

On Tue, Feb 10, 2009 at 07:16:27PM +0000, Darren Salt wrote:

> From 2.6.28.4:
> [    0.898903] eeepc: Eee PC Hotkey Driver
> [    0.902414] eeepc: Hotkey init (getting ACPI bus status)
> [    0.905913] eeepc: Hotkey init (init flags)
> [    2.620193] eeepc: Hotkey init flags 0x41
> [    2.626667] eeepc: Get control methods supported: 0x101713
> [    2.630215] input: Asus EeePC extra buttons as /class/input/input4

So we see the expected BIOS bizarro pause there...

> From 2.6.29-rc4:
> 
> [    2.141971] eeepc: Eee PC Hotkey Driver
> [    2.145325] eeepc: Hotkey init (getting ACPI bus status)
> [    2.148555] eeepc: Hotkey init (init flags)
> [    2.286445] usb 5-1: new full speed USB device using uhci_hcd and address 2
> [... USB Bluetooth device; Elantech test ...]
> [    2.780187] input: ETPS/2 Elantech Touchpad as /class/input/input5
> [   28.088399] eeepc: Hotkey init flags 0x41
> [   28.094880] eeepc: Get control methods supported: 0x101713
> [   28.098425] input: Asus EeePC extra buttons as /class/input/input6

And a rather more upsetting 26 second pause here. Yeah, ok, that's 
clearly a regression. I don't see any obvious way that it's an 
eeepc-laptop bug, though...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[yakui_zhao]

On Wed, 2009-02-11 at 00:06 +0800, Corentin Chary wrote:
> On Tue, Feb 10, 2009 at 4:45 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Tue, Feb 10, 2009 at 03:15:21PM +0000, Darren Salt wrote:
> >
> >> As things stand, this is likely to be a problem for anybody using lenny on
> >> Eee hardware and upgrading (on their own) to 2.6.29, given that that
> >> workaround is present in eeepc-acpi-scripts in lenny.
> >>
> >> Anyway, removing that option fixes the problem.
> >
> > Ok. I'll look into ensuring that these don't collide, but fundamentally
> > the problem here is distributions using broken options rather than
> > fixing the problem properly in the first place.
> >
> >> > BIOS bug. There's an explicit delay in the eee bios for some reason, and
> >> > I haven't found any straightforward way to avoid it.
> >>
> >> BIOS bug or no, the fact remains that this is (AFAICS) a regression.
> >
> > You don't get properly working hotkeys otherwise, to the best of my
> > recollection. There's an entry on the kernel bugzilla about this
> > somewhere.
> > --
> > Matthew Garrett | mjg59@srcf.ucam.org
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=12243
> If I understand things correctly, this was already the case before,
> but the kernel boot was slower, so we could'nt see that.
> If it's not the case, someone with a 901 should try bisecting (I only
> have a 701).
I have an Asus EEEPC901. And it will take about 1 second to execute the
ACPI INIT object, which is defined in BIOS.
    From the ACPI AML code it seems that there exist some explicit
delays. But we have nothing to avoid it.  
> 
> 

[PATCH] eee-laptop: Register as a pci-hotplug device

[Matthew Garrett]

eee-laptop: Register as a pci-hotplug device

The eee contains a logically (but not physically) hotpluggable PCIe slot.
Currently this is handled by adding or removing the PCI device in response
to rfkill events, but if a user has forced pciehp to bind to it (with the
force=1 argument) then both drivers will try to handle the event and
hilarity (in the form of oopses) will ensue. This can be avoided by having
eee-laptop register the slot as a hotplug slot. Only one of pciehp and
eee-laptop will successfully register this, avoiding the problem.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Darren Salt <linux@youmustbejoking.demon.co.uk>

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 284ebac..afbe441 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -341,6 +341,7 @@ config EEEPC_LAPTOP
 	select BACKLIGHT_CLASS_DEVICE
 	select HWMON
 	select RFKILL
+	select HOTPLUG_PCI
 	---help---
 	  This driver supports the Fn-Fx keys on Eee PC laptops.
 	  It also adds the ability to switch camera/wlan on/off.
diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 6f54fd1..7039dc9 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -31,6 +31,7 @@
 #include <linux/input.h>
 #include <linux/rfkill.h>
 #include <linux/pci.h>
+#include <linux/pci_hotplug.h>
 
 #define EEEPC_LAPTOP_VERSION	"0.1"
 
@@ -132,6 +133,7 @@ struct eeepc_hotk {
 	u16 *keycode_map;
 	struct rfkill *eeepc_wlan_rfkill;
 	struct rfkill *eeepc_bluetooth_rfkill;
+	struct hotplug_slot *hotplug_slot;
 };
 
 /* The actual device the driver binds to */
@@ -194,6 +196,15 @@ static struct acpi_driver eeepc_hotk_driver = {
 	},
 };
 
+/* PCI hotplug ops */
+static int eeepc_get_adapter_status(struct hotplug_slot *slot, u8 *value);
+
+static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
+	.owner = THIS_MODULE,
+	.get_adapter_status = eeepc_get_adapter_status,
+	.get_power_status = eeepc_get_adapter_status,
+};
+
 /* The backlight device /sys/class/backlight */
 static struct backlight_device *eeepc_backlight_device;
 
@@ -519,6 +530,19 @@ static void notify_brn(void)
 		bd->props.brightness = read_brightness(bd);
 }
 
+static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
+				    u8 *value)
+{
+	int val = get_acpi(CM_ASL_WLAN);
+
+	if (val == 1 || val == 0)
+		*value = val;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 {
 	struct pci_dev *dev;
@@ -624,6 +648,54 @@ static void eeepc_unregister_rfkill_notifier(char *node)
 	}
 }
 
+static void eeepc_cleanup_pci_hotplug(struct hotplug_slot *hotplug_slot)
+{
+	kfree(hotplug_slot->info);
+	kfree(hotplug_slot);
+}
+
+static int eeepc_setup_pci_hotplug(void)
+{
+	int ret = -ENOMEM;
+	struct pci_bus *bus = pci_find_bus(0, 1);
+
+	if (!bus) {
+		printk(EEEPC_ERR "Unable to find wifi PCI bus\n");
+		return -ENODEV;
+	}
+
+	ehotk->hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
+	if (!ehotk->hotplug_slot)
+		goto error_slot;
+
+	ehotk->hotplug_slot->info = kzalloc(sizeof(struct hotplug_slot_info),
+					    GFP_KERNEL);
+	if (!ehotk->hotplug_slot->info)
+		goto error_info;
+
+	ehotk->hotplug_slot->private = ehotk;
+	ehotk->hotplug_slot->release = &eeepc_cleanup_pci_hotplug;
+	ehotk->hotplug_slot->ops = &eeepc_hotplug_slot_ops;
+	eeepc_get_adapter_status(ehotk->hotplug_slot,
+				 &ehotk->hotplug_slot->info->adapter_status);
+
+	ret = pci_hp_register(ehotk->hotplug_slot, bus, 0, "eeepc-wifi");
+	if (ret) {
+		printk(EEEPC_ERR "Unable to register hotplug slot - %d\n", ret);
+		goto error_register;
+	}
+
+	return 0;
+
+error_register:
+	kfree(ehotk->hotplug_slot->info);
+error_info:
+	kfree(ehotk->hotplug_slot);
+	ehotk->hotplug_slot = NULL;
+error_slot:
+	return ret;
+}
+
 static int eeepc_hotk_add(struct acpi_device *device)
 {
 	acpi_status status = AE_OK;
@@ -704,11 +776,25 @@ static int eeepc_hotk_add(struct acpi_device *device)
 			goto bluetooth_fail;
 	}
 
+	result = eeepc_setup_pci_hotplug();
+
+	/*
+	 * If we get -EBUSY then something else is handling the PCI hotplug -
+	 * don't fail in this case
+	 */
+
+	if (result == -EBUSY)
+		return 0;
+	else if (result)
+		goto pci_fail;
+
 	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
 	eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
 
 	return 0;
-
+ pci_fail:
+	if (ehotk->eeepc_bluetooth_rfkill)
+		rfkill_unregister(ehotk->eeepc_bluetooth_rfkill);
  bluetooth_fail:
 	if (ehotk->eeepc_bluetooth_rfkill)
 		rfkill_free(ehotk->eeepc_bluetooth_rfkill);
@@ -735,8 +821,11 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 	if (ACPI_FAILURE(status))
 		printk(EEEPC_ERR "Error removing notify handler\n");
 
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
-	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+	if (ehotk->hotplug_slot) {
+		eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
+		eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+		pci_hp_deregister(ehotk->hotplug_slot);
+	}
 
 	kfree(ehotk);
 	return 0;
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] eee-laptop: Register as a pci-hotplug device

[Corentin Chary]

> +       result = eeepc_setup_pci_hotplug();
> +
> +       /*
> +        * If we get -EBUSY then something else is handling the PCI hotplug -
> +        * don't fail in this case
> +        */
> +
> +       if (result == -EBUSY)
> +               return 0;
> +       else if (result)
> +               goto pci_fail;
> +
>        eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P6");
>        eeepc_register_rfkill_notifier("\\_SB.PCI0.P0P7");
>

> -       eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
> -       eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
> +       if (ehotk->hotplug_slot) {
> +               eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
> +               eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
> +               pci_hp_deregister(ehotk->hotplug_slot);
> +       }

Hi,
This patch conflict with
http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=8082f39bb3d4a27c7bb03a76e72c70c86d55117b;hp=7ec0a7290797f57b780f792d12f4bcc19c83aa4f
A quick fix is to do :

eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
if (ehotk->hotplug_slot)
      pci_hp_deregister(ehotk->hotplug_slot);

but I'm not sure it's correct.
I should have sent a series sooner to avoid that :/
Thanks

Re: [PATCH] eee-laptop: Register as a pci-hotplug device

[Matthew Garrett]

On Sun, Apr 19, 2009 at 09:20:07AM +0200, Corentin Chary wrote:

> Hi,
> This patch conflict with
> http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=8082f39bb3d4a27c7bb03a76e72c70c86d55117b;hp=7ec0a7290797f57b780f792d12f4bcc19c83aa4f
> A quick fix is to do :
> 
> eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
> eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
> if (ehotk->hotplug_slot)
>       pci_hp_deregister(ehotk->hotplug_slot);
> 
> but I'm not sure it's correct.
> I should have sent a series sooner to avoid that :/

Ok - I'll grab that and rediff.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] eee-laptop: Register as a pci-hotplug device

[Corentin Chary]

Hi,
I take your patch and make it works against acpi4asus tree.
If you think it's ok, then I'll send a serie including this patch to Len.
(the tree is at http://git.iksaif.net/ )

From: Matthew Garrett <mjg@redhat.com>

The eee contains a logically (but not physically) hotpluggable PCIe slot.
Currently this is handled by adding or removing the PCI device in response
to rfkill events, but if a user has forced pciehp to bind to it (with the
force=1 argument) then both drivers will try to handle the event and
hilarity (in the form of oopses) will ensue. This can be avoided by having
eee-laptop register the slot as a hotplug slot. Only one of pciehp and
eee-laptop will successfully register this, avoiding the problem.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Tested-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
---
 drivers/platform/x86/Kconfig        |    1 +
 drivers/platform/x86/eeepc-laptop.c |   87 +++++++++++++++++++++++++++++++++++
 2 files changed, 88 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 284ebac..afbe441 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -341,6 +341,7 @@ config EEEPC_LAPTOP
 	select BACKLIGHT_CLASS_DEVICE
 	select HWMON
 	select RFKILL
+	select HOTPLUG_PCI
 	---help---
 	  This driver supports the Fn-Fx keys on Eee PC laptops.
 	  It also adds the ability to switch camera/wlan on/off.
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index 7aaf587..4440f6c 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -31,6 +31,7 @@
 #include <linux/input.h>
 #include <linux/rfkill.h>
 #include <linux/pci.h>
+#include <linux/pci_hotplug.h>

 #define EEEPC_LAPTOP_VERSION	"0.1"

@@ -132,6 +133,7 @@ struct eeepc_hotk {
 	u16 *keycode_map;
 	struct rfkill *eeepc_wlan_rfkill;
 	struct rfkill *eeepc_bluetooth_rfkill;
+	struct hotplug_slot *hotplug_slot;
 };

 /* The actual device the driver binds to */
@@ -197,6 +199,15 @@ static struct acpi_driver eeepc_hotk_driver = {
 	},
 };

+/* PCI hotplug ops */
+static int eeepc_get_adapter_status(struct hotplug_slot *slot, u8 *value);
+
+static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
+	.owner = THIS_MODULE,
+	.get_adapter_status = eeepc_get_adapter_status,
+	.get_power_status = eeepc_get_adapter_status,
+};
+
 /* The backlight device /sys/class/backlight */
 static struct backlight_device *eeepc_backlight_device;

@@ -529,6 +540,19 @@ static int notify_brn(void)
 	return -1;
 }

+static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
+				    u8 *value)
+{
+	int val = get_acpi(CM_ASL_WLAN);
+
+	if (val == 1 || val == 0)
+		*value = val;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 {
 	enum rfkill_state state;
@@ -655,6 +679,54 @@ static void eeepc_unregister_rfkill_notifier(char *node)
 	}
 }

+static void eeepc_cleanup_pci_hotplug(struct hotplug_slot *hotplug_slot)
+{
+	kfree(hotplug_slot->info);
+	kfree(hotplug_slot);
+}
+
+static int eeepc_setup_pci_hotplug(void)
+{
+	int ret = -ENOMEM;
+	struct pci_bus *bus = pci_find_bus(0, 1);
+
+	if (!bus) {
+		printk(EEEPC_ERR "Unable to find wifi PCI bus\n");
+		return -ENODEV;
+	}
+
+	ehotk->hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
+	if (!ehotk->hotplug_slot)
+		goto error_slot;
+
+	ehotk->hotplug_slot->info = kzalloc(sizeof(struct hotplug_slot_info),
+					    GFP_KERNEL);
+	if (!ehotk->hotplug_slot->info)
+		goto error_info;
+
+	ehotk->hotplug_slot->private = ehotk;
+	ehotk->hotplug_slot->release = &eeepc_cleanup_pci_hotplug;
+	ehotk->hotplug_slot->ops = &eeepc_hotplug_slot_ops;
+	eeepc_get_adapter_status(ehotk->hotplug_slot,
+				 &ehotk->hotplug_slot->info->adapter_status);
+
+	ret = pci_hp_register(ehotk->hotplug_slot, bus, 0, "eeepc-wifi");
+	if (ret) {
+		printk(EEEPC_ERR "Unable to register hotplug slot - %d\n", ret);
+		goto error_register;
+	}
+
+	return 0;
+
+error_register:
+	kfree(ehotk->hotplug_slot->info);
+error_info:
+	kfree(ehotk->hotplug_slot);
+	ehotk->hotplug_slot = NULL;
+error_slot:
+	return ret;
+}
+
 static int eeepc_hotk_add(struct acpi_device *device)
 {
 	acpi_status status = AE_OK;
@@ -738,8 +810,21 @@ static int eeepc_hotk_add(struct acpi_device *device)
 			goto bluetooth_fail;
 	}

+	result = eeepc_setup_pci_hotplug();
+	/*
+	 * If we get -EBUSY then something else is handling the PCI hotplug -
+	 * don't fail in this case
+	 */
+	if (result == -EBUSY)
+		return 0;
+	else if (result)
+		goto pci_fail;
+
 	return 0;

+ pci_fail:
+	if (ehotk->eeepc_bluetooth_rfkill)
+		rfkill_unregister(ehotk->eeepc_bluetooth_rfkill);
  bluetooth_fail:
 	if (ehotk->eeepc_bluetooth_rfkill)
 		rfkill_free(ehotk->eeepc_bluetooth_rfkill);
@@ -768,6 +853,8 @@ static int eeepc_hotk_remove(struct acpi_device
*device, int type)

 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+	if (ehotk->hotplug_slot)
+		pci_hp_deregister(ehotk->hotplug_slot);

 	kfree(ehotk);
 	return 0;
-- 
1.6.2.3

Re: [PATCH] eee-laptop: Register as a pci-hotplug device

[Matthew Garrett]

Hm. I /think/ that version leaks notification handlers on the failure 
path. Does this look ok? I don't have an eee to hand right now, so can't 
test this at the moment.

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 284ebac..afbe441 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -341,6 +341,7 @@ config EEEPC_LAPTOP
 	select BACKLIGHT_CLASS_DEVICE
 	select HWMON
 	select RFKILL
+	select HOTPLUG_PCI
 	---help---
 	  This driver supports the Fn-Fx keys on Eee PC laptops.
 	  It also adds the ability to switch camera/wlan on/off.
diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 7aaf587..deaf3c3 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -31,6 +31,7 @@
 #include <linux/input.h>
 #include <linux/rfkill.h>
 #include <linux/pci.h>
+#include <linux/pci_hotplug.h>
 
 #define EEEPC_LAPTOP_VERSION	"0.1"
 
@@ -132,6 +133,7 @@ struct eeepc_hotk {
 	u16 *keycode_map;
 	struct rfkill *eeepc_wlan_rfkill;
 	struct rfkill *eeepc_bluetooth_rfkill;
+	struct hotplug_slot *hotplug_slot;
 };
 
 /* The actual device the driver binds to */
@@ -197,6 +199,15 @@ static struct acpi_driver eeepc_hotk_driver = {
 	},
 };
 
+/* PCI hotplug ops */
+static int eeepc_get_adapter_status(struct hotplug_slot *slot, u8 *value);
+
+static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
+	.owner = THIS_MODULE,
+	.get_adapter_status = eeepc_get_adapter_status,
+	.get_power_status = eeepc_get_adapter_status,
+};
+
 /* The backlight device /sys/class/backlight */
 static struct backlight_device *eeepc_backlight_device;
 
@@ -529,6 +540,19 @@ static int notify_brn(void)
 	return -1;
 }
 
+static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
+				    u8 *value)
+{
+	int val = get_acpi(CM_ASL_WLAN);
+
+	if (val == 1 || val == 0)
+		*value = val;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static void eeepc_rfkill_notify(acpi_handle handle, u32 event, void *data)
 {
 	enum rfkill_state state;
@@ -655,6 +679,54 @@ static void eeepc_unregister_rfkill_notifier(char *node)
 	}
 }
 
+static void eeepc_cleanup_pci_hotplug(struct hotplug_slot *hotplug_slot)
+{
+	kfree(hotplug_slot->info);
+	kfree(hotplug_slot);
+}
+
+static int eeepc_setup_pci_hotplug(void)
+{
+	int ret = -ENOMEM;
+	struct pci_bus *bus = pci_find_bus(0, 1);
+
+	if (!bus) {
+		printk(EEEPC_ERR "Unable to find wifi PCI bus\n");
+		return -ENODEV;
+	}
+
+	ehotk->hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
+	if (!ehotk->hotplug_slot)
+		goto error_slot;
+
+	ehotk->hotplug_slot->info = kzalloc(sizeof(struct hotplug_slot_info),
+					    GFP_KERNEL);
+	if (!ehotk->hotplug_slot->info)
+		goto error_info;
+
+	ehotk->hotplug_slot->private = ehotk;
+	ehotk->hotplug_slot->release = &eeepc_cleanup_pci_hotplug;
+	ehotk->hotplug_slot->ops = &eeepc_hotplug_slot_ops;
+	eeepc_get_adapter_status(ehotk->hotplug_slot,
+				 &ehotk->hotplug_slot->info->adapter_status);
+
+	ret = pci_hp_register(ehotk->hotplug_slot, bus, 0, "eeepc-wifi");
+	if (ret) {
+		printk(EEEPC_ERR "Unable to register hotplug slot - %d\n", ret);
+		goto error_register;
+	}
+
+	return 0;
+
+error_register:
+	kfree(ehotk->hotplug_slot->info);
+error_info:
+	kfree(ehotk->hotplug_slot);
+	ehotk->hotplug_slot = NULL;
+error_slot:
+	return ret;
+}
+
 static int eeepc_hotk_add(struct acpi_device *device)
 {
 	acpi_status status = AE_OK;
@@ -738,8 +810,21 @@ static int eeepc_hotk_add(struct acpi_device *device)
 			goto bluetooth_fail;
 	}
 
+	result = eeepc_setup_pci_hotplug();
+	/*
+	 * If we get -EBUSY then something else is handling the PCI hotplug -
+	 * don't fail in this case
+	 */
+	if (result == -EBUSY)
+		return 0;
+	else if (result)
+		goto pci_fail;
+
 	return 0;
 
+ pci_fail:
+	if (ehotk->eeepc_bluetooth_rfkill)
+		rfkill_unregister(ehotk->eeepc_bluetooth_rfkill);
  bluetooth_fail:
 	if (ehotk->eeepc_bluetooth_rfkill)
 		rfkill_free(ehotk->eeepc_bluetooth_rfkill);
@@ -748,6 +833,10 @@ static int eeepc_hotk_add(struct acpi_device *device)
  wlan_fail:
 	if (ehotk->eeepc_wlan_rfkill)
 		rfkill_free(ehotk->eeepc_wlan_rfkill);
+	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
+	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+	acpi_remove_notify_handler(ehotk->handle, ACPI_SYSTEM_NOTIFY,
+				   eeepc_hotk_notify);
  ehotk_fail:
 	kfree(ehotk);
 	ehotk = NULL;
@@ -768,6 +857,8 @@ static int eeepc_hotk_remove(struct acpi_device *device, int type)
 
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6");
 	eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7");
+	if (ehotk->hotplug_slot)
+		pci_hp_deregister(ehotk->hotplug_slot);
 
 	kfree(ehotk);
 	return 0;

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] eee-laptop: Register as a pci-hotplug device

[Corentin Chary]

On Sun, Apr 26, 2009 at 7:16 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> Hm. I /think/ that version leaks notification handlers on the failure
> path. Does this look ok? I don't have an eee to hand right now, so can't
> test this at the moment.
I'll test it tomorow, but it seems ok.
Thanks

-- 
Corentin Chary
http://xf.iksaif.net

Re: Oopses and ACPI problems (Linus 2.6.29-rc4)

[yakui_zhao]

On Tue, 2009-02-10 at 02:26 +0800, Darren Salt wrote:
> I'm seeing various oopses with -rc4, where -rc3 is fine; config, dmesg
> (captured via netconsole) and decoded oops data attached ¹. The last few
> oopses were followed by a scrambled display and a hard lockup.
> 
> All oopses follow an otherwise successful suspend-to-RAM.
> 
> Also, I see that Fn-Fx don't seem to be reported via /proc/acpi/events any
> more, or at least I'm seeing no evidence of them via acpi_listen (and, not
> coincidentally, I can't adjust the volume etc. via eeepc-acpi-scripts).
> 
> The only other (significant) change is that I've installed X from Debian
> experimental, though -rc3 and 2.6.28.* seem fine with this. (Oh, and I can
> get UXA to cause OOM quite trivially... several Iceweasel tabs is enough.)
> 
>From the description it seems that this is a regression. 
Will you please use git-bisect to identify which commit causes the
regression?
   Thanks.
> 
> ¹ Yes, I decided not to include symbol names in the running kernel...
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html