On Fri, May 09, 2008 at 12:53:06AM -0300, Henrique de Moraes Holschuh wrote:
quoted text
> On Fri, 09 May 2008, Karol Lewandowski wrote:
> > On my Thinkpad T21 executing:
> 
> Please send me by private email the acpidump and dmidecode information
> for your ThinkPad, I don't have any for the T21.  Feel free to
> XXXXXX-out the UUID and serial number of your T21 in the dmidecode
> output.

(Sent.)


quoted text
> The machine was clean after a boot, correct? (no sleeps or other
> known-to-be-busted-in-2.6.26 operations before the OOPS?)

Yes, that's after clean boot.

 
quoted text
> Assuming the comments on the LED code from the first ibm-acpi maintainer
> are correct, the T20-T22 use the same LED interface, the "LED_OLD"
> ibm-acpi codepath.  That codepath is indeed NOT tested often, as I don't
> have a way to do so.  Bugs there wouldn't surprise me too much.

Well, I try to "test" that... actually I try to use it, and see if it
breaks horribly. ;-)

It's regression from 2.6.25.

 
quoted text
> If you try it using the sysfs led class, do you get the same OOPS? (I
> expect you to. If you don't, I *need* to know this).

Yes, I get oops in the same place, call stack is different of course.

BUG: unable to handle kernel paging request at d096a000
IP: [<d0960534>] :thinkpad_acpi:led_set_status+0xac/0xc3
*pde = 0f81c067 *pte = 00000000 
Oops: 0002 [#1] PREEMPT 
Modules linked in: nfs lockd nfs_acl sunrpc ipv6 autofs4 nls_iso8859_1 dm_snapshot dm_mirror dm_log thinkpad_acpi hwmon backlight led_class nvram fuse irtty_sir sir_dev snd_cs46xx snd_seq_midi snd_rawmidi rt2500pci rt2x00pci parport_pc rt2x00lib irda snd_ac97_codec parport uhci_hcd eeprom_93cx6 ac97_bus

Pid: 1253, comm: ktpacpid Not tainted (2.6.26-rc1-bizet #4)
EIP: 0060:[<d0960534>] EFLAGS: 00010246 CPU: 0
EIP is at led_set_status+0xac/0xc3 [thinkpad_acpi]
EAX: 00000000 EBX: 00000080 ECX: cf801150 EDX: 00000000
ESI: 00000000 EDI: cfb891e8 EBP: d096054b ESP: ced1ff9c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process ktpacpid (pid: 1253, ti=ced1f000 task=cfafd630 task.ti=ced1f000)
Stack: cfb891ec cfbc6fe0 c0126f5f cfbc6fe0 c0127573 ced1ffd0 00000000 c012761d 
       00000000 cfafd630 c01298b2 ced1ffc8 ced1ffc8 cfbc6fe0 00000000 c01297ff 
       c01297c9 00000000 c0104293 cec14dec 00000000 00000000 00000000 4efbfdff 
Call Trace:
 [<c0126f5f>] run_workqueue+0x83/0x10e
 [<c0127573>] worker_thread+0x0/0xb4
 [<c012761d>] worker_thread+0xaa/0xb4
 [<c01298b2>] autoremove_wake_function+0x0/0x2d
 [<c01297ff>] kthread+0x36/0x5b
 [<c01297c9>] kthread+0x0/0x5b
 [<c0104293>] kernel_thread_helper+0x7/0x10
 =======================
Code: eb 25 ff 34 b5 f0 24 96 d0 53 68 f8 29 96 d0 6a 00 6a 00 ff 35 ec 9d 96 d0 e8 65 ec ff ff 83 c4 18 85 c0 74 0f eb 14 85 c0 75 14 <89> 34 9d 00 9e 96 d0 eb 0b b8 fb ff ff ff eb 04 31 c0 eb ec 5b 
EIP: [<d0960534>] led_set_status+0xac/0xc3 [thinkpad_acpi] SS:ESP 0068:ced1ff9c
---[ end trace 7c7a86bd66b8f726 ]---

 
quoted text
> Is it always a problem with the last led (number 7), or other leds also
> cause the OOPS?

Leds 1-6 are ok, i.e. they do change state (on/off) and don't cause
ill effects.

Writing anything (on/off/blink) to led 7 (procfs) or "tpacpi::standby"
(sysfs) causes an reproductible oops.


quoted text
> Also, please try the patch below, and send me the debug output it will
> generate.

Hmm, I added following to my .config and recompiled kernel with your patch:

 +CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y	# this was automatically added
 +CONFIG_DEBUG_BUGVERBOSE=y
 +CONFIG_DEBUG_INFO=y
 +CONFIG_FRAME_POINTER=y

The result is:

 thinkpad_acpi: debug: led 7, status 1, mode 2
 thinkpad_acpi: debug: led is now 0x80
 thinkpad_acpi: debug: will write A=0x0, B=0x80

Yes, no oops...  writing on/off/blink all works through procfs and
sysfs interface works too.

Without .config changes:

 thinkpad_acpi: debug: led 7, status 1, mode 2
 thinkpad_acpi: debug: led is now 0x80
 thinkpad_acpi: debug: will write A=0x0, B=0x80

No oops here either.  Reverting this patch gives:

BUG: unable to handle kernel paging request at d098e000
IP: [<d0984534>] :thinkpad_acpi:led_set_status+0xac/0xc3
*pde = 0f81c067 *pte = 00000000 
Oops: 0002 [#1] PREEMPT 
Modules linked in: nfs lockd nfs_acl sunrpc ipv6 autofs4 nls_iso8859_1 dm_snapshot dm_mirror dm_log thinkpad_acpi hwmon backlight led_class nvram fuse irtty_sir sir_dev snd_cs46xx snd_seq_midi snd_rawmidi rt2500pci rt2x00pci snd_ac97_codec rt2x00lib parport_pc parport ac97_bus irda eeprom_93cx6 uhci_hcd

Pid: 2119, comm: bash Not tainted (2.6.26-rc1-git+afa26be-tpacpi+patch #2)
EIP: 0060:[<d0984534>] EFLAGS: 00010246 CPU: 0
EIP is at led_set_status+0xac/0xc3 [thinkpad_acpi]
EAX: 00000000 EBX: 00000080 ECX: cf801150 EDX: 00000000
ESI: 00000001 EDI: 00000005 EBP: d098d660 ESP: cef7af1c
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process bash (pid: 2119, ti=cef7a000 task=cf89f0d0 task.ti=cef7a000)
Stack: cecc6588 fffffff4 d0986028 cecc658e 00000007 cecc6588 d0986433 09954c08 
       d09863d1 cf95e080 09954c08 fffffffb c0190dc7 d098d660 cfb83c60 c0190da2 
       cf95e080 c018d5a5 cef7afa0 00000005 09954c08 cf95e080 09954c08 c018d528 
Call Trace:
 [<d0986028>] led_write+0x83/0xa1 [thinkpad_acpi]
 [<d0986433>] dispatch_procfs_write+0x62/0x7f [thinkpad_acpi]
 [<d09863d1>] dispatch_procfs_write+0x0/0x7f [thinkpad_acpi]
 [<c0190dc7>] proc_file_write+0x25/0x2e
 [<c0190da2>] proc_file_write+0x0/0x2e
 [<c018d5a5>] proc_reg_write+0x7d/0x90
 [<c018d528>] proc_reg_write+0x0/0x90
 [<c015ed04>] vfs_write+0x83/0xf6
 [<c015f192>] sys_write+0x3c/0x63
 [<c0103721>] sysenter_past_esp+0x6a/0x91
 [<c0320000>] ieee80211_duration+0x157/0x189
 =======================
Code: eb 25 ff 34 b5 f0 64 98 d0 53 68 f8 69 98 d0 6a 00 6a 00 ff 35 ec dd 98 d0 e8 65 ec ff ff 83 c4 18 85 c0 74 0f eb 14 85 c0 75 14 <89> 34 9d 00 de 98 d0 eb 0b b8 fb ff ff ff eb 04 31 c0 eb ec 5b 
EIP: [<d0984534>] led_set_status+0xac/0xc3 [thinkpad_acpi] SS:ESP 0068:cef7af1c
---[ end trace a75276ec710f1fa4 ]---


Any ideas?

(Newest kernel out there, namely git:28a4acb, still produces oops. :-)
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/