Bug 2066
Summary: | Battery status regression after 2.6.1 - AE_ALREADY_EXISTS | ||
---|---|---|---|
Product: | ACPI | Reporter: | Tomassino Ferrauto (t_ferrauto) |
Component: | Power-Battery | Assignee: | Len Brown (lenb) |
Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | acpi-bugzilla, dopey, herbert, ingo, javi, kschin, marcus, ow.mun.heng, pat, ravi_n, sgy-lkml, stanpinte, tim |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.3, 2.6.3-rc1, 2.6.2 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
A kernel log obtained after the battery status stops being displayed
output of acpidmp on an Acer Travelmate 291Lmi output of acpidmp on Dell Latitude D500 bios A07 kernel 2.6.3-gentoo-r1 Dell Inspiron 8500 A05 bios acpidmp kernel logs on Dell inspiron 5150 dmesg from 2.6.4-rc2 + 20040220 acpi patches a workaround for this infamous battery state issue. Dell C640 output |
Description
Tomassino Ferrauto
2004-02-09 18:03:48 UTC
*** Bug 2067 has been marked as a duplicate of this bug. *** Redhat 9, D600 + Bios A05 2.6.3-rc3 (patched with latest patch from acpi.sourceforge.net - 20040211) The battery status just goes missing after some time. Can't pinpoint what exactly is causing it. Used to run on 2.4.24 and this problem never showed up before. I have the same thing here on a Dell Inspiron 600m, except it's BAT0. Exactly the same messages log output, same symptoms. Started with 2.6.2. My machine specs are in http://bugzilla.kernel.org/show_bug.cgi?id=1372 What broke? Same problem here! Toshiba A20 Laptop Since there are so many laptop having similar symptom with similar AE_ALREADY_EXISTS error message, I think of it as regression. To make this problem clear, I suggest all of you to have kernel 2.6.0-test11 with the following patches a try. 1) http://bugzilla.kernel.org/attachment.cgi?id=1690&action=view 2) http://bugzilla.kernel.org/attachment.cgi?id=1774&action=view 3) http://bugzilla.kernel.org/attachment.cgi?id=1796&action=view --Luming I'm compiling this as we speak. I'll let it run for a while tomorrow and let you know the results. I don't know the origin of these patches, but 2.6.0 FINAL worked properly. NOTE: The second patch failed to apply. The others applied with offsets and fuzz. I'm sorry, those patch should apply to 2.6.0 or 2.6.1 kernel with ACPI patch http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.1/a cpi-20031203-2.6.1.diff.bz2 Thanks, Luming Please post the DSDT from one of these machines The 2.6.1 kernel, patched, and then with the three additional patches does the same thing (ACPI) dies after some time. What is a DSDT? FWIW, I'm also seeing this regression on 2.6.3 with a Dell Latitude D500 bios A07. It was working for me back in 2.6.2rc2. Please attach the output from acpidmp, available in /usr/sbin, or in pmtools: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ This includes an ASCII version of the DSDT, a BIOS ACPI table. Alternatively, a binary copy of the DSDT can be had from /proc/acpi/DSDT Also, please try the latest 2.6.4, or apply the latest ACPI patch to 2.6.2 or 2.6.3: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/ thanks, -Len Hi! I have an Acer Travelmate 290Lmi with 2.4.26-pre1 kernel and cpufreq path from: ftp://ftp.linux.org.uk/pub/linux/cpufreq/ I get the same error a few minutes after boot. This is my acpidmp output: The output from acpidmp is in: http://javier-gonzalez.com/acpidmp-output-acer-tm290Lmi.txt Thanks. Sorry, I forget it, all worked well with 2.4.22 with alan cox ac4 patch :-D Created attachment 2229 [details]
A kernel log obtained after the battery status stops being displayed
Created attachment 2230 [details]
output of acpidmp on an Acer Travelmate 291Lmi
I've tried 2.6.1 + acpi patches + posted patches, but it still doesn't work. The battery status cannot be read after some time the system is up. I've attached a kernel log obtained ofter the battery status stops being displayed (I've done "echo 0xffffffff > /proc/acpi/debug_level", I don't know if it can help...) and the output of acpidmp. Other information on my system (Acer Travelmate 291Lmi) is in the first post of this bug. I'll try the latest 2.6.4 and acpi patches and let you know The output of acpidmp and whatnot is, as before, in my other bug: http://bugme.osdl.org/show_bug.cgi?id=1372 I don't know if this is supposed to change once ACPI goes nuts? I'm currently trying out 2.6.3 + Len's patches. I was not able to find a 2.6.4 on kernel.org. I will report my findings once there is something to report. Created attachment 2233 [details]
output of acpidmp on Dell Latitude D500 bios A07 kernel 2.6.3-gentoo-r1
With 2.6.3 + Len's patches, it still misbehaves. The issue must have formed between 2.6.0 and 2.6.2, since I never had 2.6.1, but 2.6.2 was broken. Multiply (Local2, 0x28, Local2) Store (Local0, Index (PBST, 0x00)) Store (0x00, Index (PBST, 0x01)) Store (Local2, Index (PBST, 0x02)) Store (Local3, Index (PBST, 0x03)) Return (PBST) This looks like the problem that was fixed by this patch: 11 February 2004. Summary of changes for version 20040211: Fixed a problem where a store of an object into an indexed package could fail if the store occurs within a different method than the method that created the package. 2) However, there could be a case where the PBST package is not being deleted, perhaps because of a race condition. It is interesting to note that it doesn't seem to start right away, only after the system is up for a while. I haven't been able to reproduce the problem with acpiexec, this may require a trace. it's only crash a few minutes after boot or if you use #acpi command a few times. (The firsty 5 o 6 times works wells, but then it crash wit this horrible error) ;-( I still have the problem under 2.6.3 + acpi-20040211-2.6.3 patch. I'm a little concerned that perhaps the methods are being reentered. Try these changes to your DSDT: - Method (_BIF, 0, NotSerialized) - Method (_BST, 0, NotSerialized) + Method (_BIF, 0, Serialized) + Method (_BST, 0, Serialized) Robert Moore i have a funny problem ... i can't find this lines in the kernel source ... where are there ? Thanks I've tried 2.6.3-bk7 and it still doesn't work. To Robet Moore: could you tell us what to do to change those things? Thanks :-) You need to 1) Extract your DSDT from the acpidmp output (acpixtract) 2) Disassemble the DSDT to ASL code (iasl -d) 3) Make the suggested changes 4) Recompile the DSDT 5) Overload the new DSDT over the old one. There are more detailed instructions somewhere, I don't know. Len? I have the DSDT code, i have just modify it. But ... I don't know how to do this: 4) Recompile the DSDT 5) Overload the new DSDT over the old one. Could you help me? Thanks Very much. I've found this url: http://acpi.sourceforge.net/wiki/index.php/ HowToOverrideTable. Hope it could help. I've tried to modify the dsdt and to recompile following the instructions on the page I've posted, but compilation returns the following errors: Intel ACPI Component Architecture ASL Optimizing Compiler / AML Disassembler version 20030918 [Sep 18 2003] Copyright (C) 2000 - 2003 Intel Corporation Supports ACPI Specification Revision 2.0b /home/tommy/working-on-dsdt/current-dsdt.dsl 84: Method (_WAK, 1, NotSerialized) Warning 2026 - Reserved method must return a value ^ (_WAK) /home/tommy/working-on-dsdt/current-dsdt.dsl 1198: If (Local1) Error 1013 - Method local variable is not initialized ^ (Local1) /home/tommy/working-on-dsdt/current-dsdt.dsl 2889: Field (ERAM, AnyAcc, Lock, Preserve) Error 1048 - Host Operation Region requires ByteAcc access ^ /home/tommy/working-on-dsdt/current-dsdt.dsl 3090: Field (ECRM, AnyAcc, Lock, Preserve) Error 1048 - Host Operation Region requires ByteAcc access ^ ASL Input: /home/tommy/working-on-dsdt/current-dsdt.dsl - 5060 lines, 209589 bytes, 2504 keywords Compilation complete. 3 Errors, 1 Warnings, 0 Remarks, 578 Optimizations I've used iasl-linux-20030918. I get the same error. Use iasl -f to ignore errors I do it and doesn't work :-( I get the same error :-( Yes, you still get the errors, but you'll notice that the AML (obj) file is created. No ... sorry ... i don't say it very well ... i ensambled it and patch the kernel, i compiled the kernel and reboot, and the error persist. Created attachment 2240 [details]
Dell Inspiron 8500 A05 bios acpidmp
Attached acpidmp output from my Dell Inspiron 8500 with the A05 bios. I've
been having the same problem as well. I've tried the 20040211 acpi patch
against vanilla 2.6.3 and the problem still occurs. I didn't notice it until
2.6.3.
How do you have CONFIG_ACPI_STRICT set? Please try toggling this option and report the result. CONFIG_ACPI_STRICT? I don't see that option anywhere. Are you referring to CONFIG_ACPI_RELAXED_AML? If so, then I've tried with relaxed aml enabled and disabled with the same results. I've exchanged some e-mails with Luming yesterday night and tested 2.6.1 + acpi 20031203 along with the additional 3 patches also included in the thread of this bug and had the same problems. I don't know how relevant this is, but I rebuilt vanilla 2.6.1. So far, the battery status hasn't failed at all on me, but I do have the occasional errors in the log that are identical to the errors that occur with 2.6.3 ( I skipped 2.6.2) when battery status starts to fail: dswload-0277: *** Error: Looking up [BST0] in namespace, AE_ALREADY_EXISTS psparse-0588 [2829] ps_parse_loop : During name lookup/catalog, AE_ALREADY_EXISTS psparse-1120: *** Error: Method execution failed [\_SB_.BAT0._BST] (Node c1558aa8), AE_ALREADY_EXISTS So it looks like 2.6.1 suffers from the same error, but recovers (or does something else) and continues to read status. I have the same problem than Andy Wang but I use 2.4.22-ac4 kernel version. Created attachment 2261 [details]
kernel logs on Dell inspiron 5150
some logs describing the problem
Furthermore, it's not only the battery status that's bad on my laptop. Check out this *wickedly fast* Pentium-M: pat@inspiron pat $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Pentium(R) M processor 1600MHz stepping : 5 cpu MHz : 4263.584 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe tm2 est bogomips : 8432.29 I haven't got this problem: (i'm using 2.6.4-rc1) # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Pentium(R) M processor 1300MHz stepping : 5 cpu MHz : 1298.996 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe tm2 est bogomips : 2580.48 Another choise ... if you don't use cpufreq in kernel ... this battery bug doesn't exist. I disagree that it's directly related to cpufreq. I am now able to reproduce this on whim. In two bash shell sessions run the same command (while true; do cat /proc/acpi/battery/BAT0/state ; done). Very quickly (a matter of seconds) the problem will occur. Looks like some sort of race condition. Kernel 2.6.1 doesn't appear to suffer from this. This also explains the time frame of this happening. I use KDE's battery meter. I also use cpufreqd. cpufreqd does battery checks occasionally as well. I think what's happening is just by timing, the two end up causing the race condition. Maybe this will help someone track down and fix the problem :) I beg to disagree on the 2.6.1 kernel as well. I did a re-compile on
vanilla 2.6.1 as Luming wanted and still saw the same kind of problem.
===My experiment which I posted to acpi-devel list====
2.6.1
2.6.2
2.6.3-rc1
2.6.3-rc2
2.6.3-rc3
2.6.2-rc2-mm1
2.6.3+acpi-20040211+laptop_mode
Steps to reproduce:
> 1st scenerio
> 1. If I were to leave gkrellm's batt stat on (only) it's ok.
> (1 sec updates)
> 2. Put in Gnome's Battery monitor together with Gkrellm..
> After a while gets
> the
> AE_ALREADY_EXIST error
>
> 2nd scenerio
> 1. do watch -n1 cat /proc/acpi/battery/BAT0/state
> 2. Repeat Step #1 x 10 times or more??
> 3. KaBoom!! Like nearly instantenous (wrong spelling)
Anyone also seeing the
osl-0886[80] os_wait_semaphore:Failed to acquire semaphore[dffac580|1|0],
AE_TIME
I think you're having a different problem. No one else here seems to have had this issue with 2.6.1, and no one has any output regarding semaphores... though they do meet the race hypothesis. In 2.6.1 I don't have the problem at all. I can my same while script, and the same AE_ALREADY_EXISTS error does show up. When the error shows up, the cat /proc/acpi/blahblah calls pause for a split second, but it never stops working. In 2.6.3 and 2.6.4-rc1 it completely stops battery status from working. I do get the same semaphore error messages though sprinkled throughout the kernel log, but they don't appear to have any negative affect. I have the battery status problem (I've had it with Debian's 2.6.2 and 2.6.3 with and without various ACPI patches and relaxed AML on and off - I've tried lots of things) on a Dell Inspiron 8600. I've also seen the semaphore problem for a long time (possibly since 2.6.0-test9 or test11), but it has not seemed to have had any negative effect. If there are any particular tests / logs / etc. that would be helpful in debugging this issue, please let me know. Re: #42 kernel logs on Dell inspiron 5150 Linux version 2.6.3swsusp (root@pablo) (version gcc 3.3.3 (Debian)) #1 Sat Feb 28 11:38:34 CET 2004 ACPI: Subsystem revision 20040116 please try at least 2.6.4-rc1 beacuse have ACPI: Subsystem revision 20040211 and btw redhat recommends compile kernel with gcc3.2 and not with gcc3.3 in FC1, they should have some reasons for that : --- Makefile 2004-02-25 00:34:53.000000000 +0000 +++ Makefile 2004-02-25 01:55:27.000000000 +0000 -HOSTCC = gcc +HOSTCC = gcc32 -CC = $(CROSS_COMPILE)gcc +CC = $(CROSS_COMPILE)gcc32 I tryed it with 2.6.4rc1 and with 2.6.4rc1-mm1. I compile it with gcc3.3 and gcc3.2 ... the bug still existing. :-( With 2.6.4-rc2 doesn't work :-( I've reproduced the problem where once an AE_ALREADY_EXISTS happens, there is no recovery. Fix forthcoming. Bob *** Bug 1975 has been marked as a duplicate of this bug. *** BTW, these control methods go against the ACPI Specification. Here is the relevant text from the description of the Method() operator: If a method is declared as Serialized, an implicit mutex associated with the method object is acquired at the specified SyncLevel. If no SyncLevel is specified, SyncLevel 0 is assumed. The serialize rule can be used to prevent reentering of a method. This is especially useful if the method creates namespace objects. Without the serialize rule, the reentering of a method will fail when it attempts to create the same namespace object. whit this patch ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.4/acpi-20040220-2.6.4.diff.gz don't work too :-( Patch release on 06/03/2004 by Len Brown. Also fails on an Acer L7200 laptop (440BX chipset, latest BIOS) using 2.6.4-rc2 thru to 2.6.3-rc's, including 2.6.4-rc2 patched with the patch mentioned by Javier Gonz Created attachment 2301 [details]
dmesg from 2.6.4-rc2 + 20040220 acpi patches
/var/log/dmesg from latest boot. Bug nas not maifisted itself yet (this boot),
but can be easily triggered on request.
Just replicated the bug again: While running "watch -n 1 `cat /proc/acpi/battery/BAT0/state`" I ran "cat /proc/acpi/battery/BAT0/state" a few times and triggered the error. To me, this looks like some sort of collision of resources (ie: only happens with 2 processes accessing the /proc/acpi entry at the same time). Previous attempts had klaptop polling once every 20sec & using watch as above. Took longer to trigger the error, and never an exact time after start or a specific number of /proc/acpi accesses. Still present in 2.6.4-rc3 (which has the 20040220 ACPI code now). PS: If a shell (ssh) on a failing box will help, one can be provided. Created attachment 2309 [details]
a workaround for this infamous battery state issue.
Since asl method which dynamic create object should be serialized, so the
correctness of execution of method which is NotSerialized should be guaranteed
by ASL prorgramer. Can you give it a try?
kernel 2.6.3 with ACPI 20040211 and the patch from luming Works partially.. Gnome Battery Monitor will Die (0%) and watch -n1 cat /proc/acpi/batterty/BAT0/state will say Upon Error : unable to read batt status however, it manages to kick itself up again. and Works after a few seconds. however, I see this a lot in the logs acpi_battery_0217 [238] acpi_battery_get_statu: Error extracting _BST Dell D600 A09 Bios yup, this patch is very nearly perfect. running two of my while loops (while true; do cat /proc/acpi/battery/BAT0/state ; done) simultaneously will occasionally give the acpi_battery-0217 [62] acpi_battery_get_statu: Error extracting error, at which point it's unable to read the battery status for a few seconds, but in general it seems to work okay. What was the change between whatever acpi versoin is in 2.6.1 that caused this behavior? With 2.6.1, it just worked although reading the BATX state seemed to block for a few seconds occasionally (I'm assuming when a similar error condition arose) Also, any suggestions on how a simple lowly person could convince dell to Serialize their AML methods? A possible workaround is to force the method to "Serialized" if 1) It is not NotSerialized 2) An ALREADY_EXISTS error happens when 2 or more threads are executing the method. Bob Whoops, 1) It is currently marked NotSerialized 2) An AE_ALREADY_EXISTS error happens when 2 or more threads are executing the method. We would get one initial error, then the method would be serialized from then on. We could even get agressive and restart the method (when it fails for the first time), but I wonder about the value of this. Bob Further tested the patch.. Found this little(?) annoyance. CPU Usage(system %) will increase significantly (up to 90% and my Pentium M speedstep will go from 600Mhz -> 1.4Ghz due to loading) whenever anything is accessing the /proc/acpi/battery/BAT0/state file. This is seen using gkrellm battery module and the gnome-battery-monitor. Also seen while performing watch cat /proc/acpi/battery/BAT0/state. Removing all of it will return the cpu usage back to normal. (~2 - 5%) Should be fixed in CA version 20040311: Fixed a problem where errors occurring during the parse phase of control method execution did not abort cleanly. For example, objects created and installed in the namespace were not deleted. This caused all subsequent invocations of the method to return the AE_ALREADY_EXISTS exception. Implemented a mechanism to force a control method to "Serialized" execution if the method attempts to create namespace objects. (The root of the AE_ALREADY_EXISTS problem.) My Dell C640 has this error with 2.6.4 from kernel.org wmacpi will crash after a few mins and BAT1/state will fail with the commonly report error messages. I will try applying the patch for the infamous battery state issue and report things later. Keith Created attachment 2326 [details]
Dell C640 output
Here is the output of dmesg, acpidmp, dmpdecode, lspci and /proc/interrupts
Lots of output.
2.6.4 and 2.6.4 with the suggested patch still has the problem. I have attached all of the debug output Keith I'm running with 2.6.4 now using the patch at: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.4/20040313021825-ACPICA20040311.patch I now get one AE_ALREADY_EXISTS error and that's it, after that, everything keeps on going and I don't see the error again until a reboot. The patch seems to work for me so far. Thanks for the patch. 2.6.4 and the patch from kernel.org works for me too. One error printed. The gnome battery tool work but the WindowMaker wmacpi one segfaults after a while. Could be an app issue or something. Keith I've tried 2.6.4 and the latest ACPI patch and it works (now also shows the remaining battery time, even if it seems to need some time to "adjust"...). I get the AE_ALREADY_EXISTS error just once. If I cat /proc/acpi/battery/BAT1/state very frequently, I get a lot of messages like these: osl-0886 [23803] os_wait_semaphore : Failed to acquire semaphore[d7ca6800|1|0], AE_TIME osl-0886 [24524] os_wait_semaphore : Failed to acquire semaphore[d7ca6800|1|0], AE_TIME osl-0886 [24542] os_wait_semaphore : Failed to acquire semaphore[d7ca6800|1|0], AE_TIME osl-0886 [24572] os_wait_semaphore : Failed to acquire semaphore[d7ca6800|1|0], AE_TIME osl-0886 [25287] os_wait_semaphore : Failed to acquire semaphore[d7ca6800|1|0], AE_TIME However, everything works fine. Thank you! Hi, in TOSHIBA A10-127 problem persist. ACPI-0279: *** Error: Looking up [BUFF] in namespace, AE_ALREADY_EXISTS ACPI-1133: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node cee91700), AE_ALREADY_EXISTS Regards. I forget kernel version... ACPI-0279: *** Error: Looking up [BUFF] in namespace, AE_ALREADY_EXISTS ACPI-1133: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node cee91700), AE_ALREADY_EXISTS root@marcus:~# uname -a Linux marcus.house 2.6.5-rc2 #5 Sat Mar 20 01:19:51 BRT 2004 i686 i686 i386 GNU/Linux Marcus 2.6.5-rc2 contains ACPICA 20040311 which contains the fix for this issue. Are you reporting that the (single) warning message persists, or that you are unable to access the battery status? Please try booting with "acpi_serialize" thanks, -Len Hi Len, Sorry, it's only warnings, see above. ACPI-0279: *** Error: Looking up [BUFF] in namespace, AE_ALREADY_EXISTS ACPI-1133: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node cee91700), AE_ALREADY_EXISTS root@marcus:~# cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: charging present rate: 15552 mW remaining capacity: 29754 mWh present voltage: 11300 mV Regards I've tried 2.6.5rc2 and 2.6.5rc3 with similar results to everyone else. Battery works great. ...BUT... Related or not, after some time, frequency scaling stops working. I don't know if it's related, but it works right after booting just fine. I mean, it allows me to set it, and reports the scaling governor and min frequency properly, even the maximum frequency if I lower it. But then /proc/cpuinfo doens't change. Hello, I seem to have the same problem here with my Acer Travelmate 291LCi. Kernel 2.6.6 with acpi20040326 included. (so the mentioned fixes are included there already) The problem persists and therefore let my notebook not to be able to shutdown, if the battery is low. I have installed some script there to be called from acpid (that did not work at all) or by cron (currently every minute). Just as the battery run under 5% capacity, the acpi-code stopped working, if I can trust my syslog. Regards, Ingo Schaefer <ingo@ingo-schaefer.de> After ACPI CA version 20040311, you should only get the error once. If you use acpi_serialize, you should not get the error at all. Hello Robert, If I can trust my kernel messages, I get this message three times, but all to the same time. I think, it is, when my script runs the first time. I have to mention, that the acpid is running as well to this time. The script does nothing than parsing the output from /proc/acpi/battery/BAT1/state (and info) to find out, if the battery is below the "capacity low" level and shut down the system in that case. If I boot the machine without the AC connected, this error occours and so the battery state is "unknown" or some other unpredicted results. The "remaining" capacity is always 2040 mAh, regardless of the "real" state of the battery. Another thing I figured out is that the remaining capacity is reported as 0 mAh, if the AC is disconnected and the battery below the "capacity low" level. So I had to match against the "battery state: critical"-line instead of the capacity. Is this specific to this machine type (a bug or a feature?)? If I boot the machine with AC connected, I don't get this message. Regards Ingo Schaefer still an issue in 2.6.9? I have not seen these symptoms since before 2.6.5, so in my opinion this one can be closed. However, I am not the original submitter. For me 2.6.9 / 2.6.10-rc2 work correct. I'm using kernel 2.6.9 and I've no problem. thanks -- closing. |