Acer smart battery: acpi_sbs and linux-2.6.17

Acer smart battery: acpi_sbs and linux-2.6.17

[Berthold Cogel]

Hello!

I've tried the modified acpi_sbs patch (acpi_sbs-20060422, modified by
Johan Vromans) for linux-2.6.16 with linux-2.6.17.

The patch applies and builds without a problem. The same for both
modules (acpi_sbs and i2c-acpi-ec). The modules work. But when the
battery is charged, I get divide errors from the kernel.

Jun 25 14:40:54 localhost kernel: divide error: 0000 [#1]
Jun 25 14:40:54 localhost kernel: PREEMPT
Jun 25 14:40:54 localhost kernel: Modules linked in: af_packet usbhid
nls_iso8859_1 nls_cp850 vfat fat radeon drm binfmt_misc rfcomm l2cap
bluetooth irtty_sir sir_dev thermal fan button autofs4 snd_intel8x0m
ipw2200 b44 mii ieee80211_crypt_tkip ieee80211_crypt_ccmp
ieee80211_crypt_wep ieee80211 ieee80211_crypt cpufreq_conservative
cpufreq_ondemand cpufreq_performance cpufreq_powersave acpi_cpufreq
freq_table processor ide_scsi sg sr_mod
cdrom scsi_mod acpi_sbs i2c_acpi_ec pcmcia firmware_class snd_intel8x0
snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss joydev snd_pcm
snd_timer snd uhci_hcd 8250_pci soundcore snd_page_alloc ehci_hcd
intel_agp agpgart rtc usbcore i2c_i801 irda 8250 serial_core psmouse
ohci1394 ieee1394 yenta_socket rsrc_nonstatic pcmcia_core serio_raw
evdev crc_ccitt unix
Jun 25 14:40:54 localhost kernel: CPU:    0
Jun 25 14:40:54 localhost kernel: EIP:    0060:[<f99ccf50>]    Not
tainted VLI
Jun 25 14:40:54 localhost kernel: EFLAGS: 00210246   (2.6.17 #2)
Jun 25 14:40:54 localhost kernel: EIP is at
acpi_lbattery_read_state+0x111/0x1aa [acpi_sbs]
Jun 25 14:40:54 localhost kernel: eax: 00000000   ebx: dfc53800   ecx:
00000000   edx: 00000000
Jun 25 14:40:54 localhost kernel: esi: 00000001   edi: dc593640   ebp:
00000400   esp: f7c65f28
Jun 25 14:40:54 localhost kernel: ds: 007b   es: 007b   ss: 0068
Jun 25 14:40:54 localhost kernel: Process hald (pid: 3833,
threadinfo=f7c64000 task=f7c96030)
Jun 25 14:40:54 localhost kernel: Stack: f99ce463 dc593640 00000001
f7c65f54 c016bb83 dc593640 00000001 dc593660
Jun 25 14:40:54 localhost kernel:        00000000 00000001 c1bf1580
00000000 00000000 eb9af600 0807eea0 f7c65fa4
Jun 25 14:40:54 localhost kernel:        00000400 c01512b7 eb9af600
0807eea0 00000400 f7c65fa4 eb9af600 fffffff7
Jun 25 14:40:54 localhost kernel: Call Trace:
Jun 25 14:40:54 localhost kernel:  <c016bb83> seq_read+0xee/0x269
<c01512b7> vfs_read+0x87/0x11b
Jun 25 14:40:54 localhost kernel:  <c0151bdb> sys_read+0x3b/0x64
<c0102a37> sysenter_past_esp+0x54/0x75
Jun 25 14:40:54 localhost kernel: Code: 80 7b 08 00 ba 63 e4 9c f9 0f 44
c2 50 0f b7 43 0c 0f b7 93 9e 00 00 00 29 d0 0f af c6 6b c0 3c 0f b7 93
a4 00 00 00 89 d1 31 d2 <f7> f1 50 68 67 e4 9c f9 57 e8 f1 e7 79 c6 83
c4 10 eb 2d 68 a9
Jun 25 14:40:54 localhost kernel: EIP: [<f99ccf50>]
acpi_lbattery_read_state+0x111/0x1aa [acpi_sbs] SS:ESP 0068:f7c65f28


The notebook is an Acer Extensa 3002 WLMi. I don't use a modified DSDT
with this patch at the moment.


Regards,
Berthold Cogel


Regards

Re: Acer smart battery: acpi_sbs and linux-2.6.17

[Johan Vromans]

Berthold Cogel <cogel@rrz.uni-koeln.de> writes:

> I've tried the modified acpi_sbs patch (acpi_sbs-20060422, modified by
> Johan Vromans) for linux-2.6.16 with linux-2.6.17.

Just did the same for my WLMi4001.

> The patch applies and builds without a problem. The same for both
> modules (acpi_sbs and i2c-acpi-ec). The modules work. But when the
> battery is charged, I get divide errors from the kernel.

Hmm. I've yet to see this problem, but I'll be careful (and save
often) for a while.

I remember that when I first tried the patch with 2.6.16 I got a
kernel crash once in the beginning, but never since.

(I'd really hope someone with more kernel expertise would stand up and
help a hand with this patch.)

-- Johan

Re: Acer smart battery: acpi_sbs and linux-2.6.17

[Johan Vromans]

Johan Vromans <jvromans@squirrel.nl> writes:

> Hmm. I've yet to see this problem, but I'll be careful (and save
> often) for a while.

But I seem to have lost the ability to hibernate/resume. I consistently
get "swsusp: not enough free memory". Does 2.6.17 take so much more
memory than 2.6.16?

-- Johan

Re: Acer smart battery: acpi_sbs and linux-2.6.17

[Berthold Cogel]

Johan Vromans wrote:
> Johan Vromans <jvromans@squirrel.nl> writes:
> 
>> Hmm. I've yet to see this problem, but I'll be careful (and save
>> often) for a while.
> 

It's not that dangerous. The modules 'simply' stop working.... No crash
or lost data. Until now ...

> But I seem to have lost the ability to hibernate/resume. I consistently
> get "swsusp: not enough free memory". Does 2.6.17 take so much more
> memory than 2.6.16?
> 

For my System it's only about 1 MB difference in runlevel 1 with
2.6.17.1 compared with 2.6.16.20. But I'm using suspend to disk with
suspend2.


Berthold

Re: Acer smart battery: acpi_sbs and linux-2.6.17

[Johan Vromans]

Berthold Cogel <cogel@rrz.uni-koeln.de> writes:

>> But I seem to have lost the ability to hibernate/resume. I consistently
>> get "swsusp: not enough free memory". Does 2.6.17 take so much more
>> memory than 2.6.16?
>
> For my System it's only about 1 MB difference in runlevel 1 with
> 2.6.17.1 compared with 2.6.16.20.

I've gone back to 2.6.16, and didn't notice a significant difference
in 'free' figures so the size increment is probably neglectible.
But I can only hibernate when I stop X first, while with 2.6.16 I'm
could hibernate with a fully loaded (X, WM, Emacs, Xterms) system.

BTW I hibernate with 

  cd /sys/power; echo shutdown > disk; echo disk > state

I don't use the pm-hibernate program (doesn't seem to make a
difference, except that I cannot choose a kernel upon boot).

> But I'm using suspend to disk with suspend2.

I've been told that swsusp2 and swsusp share the same memory
limitation: at least half of the memory must be freeable for suspend
to be able to continue. But it could be a problem with swsusp that it
somehow isn't able to free enough memory.

Since 2.6.16 swsusp does everything I need, I never tried swsusp2.
Last time I looked it seemed work in fast progress, much like a moving
target. Besides I'd like to stick as closely as possible to my
standard Fedora kernel so I can still use the prebuilt kernel modules.

-- Johan