Bug 45461
| Summary: | Samsung NP530U3B and NP535U3C lid close does not suspend | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Pat (source) |
| Component: | BIOS | Assignee: | acpi_bios |
| Status: | CLOSED DOCUMENTED | ||
| Severity: | normal | CC: | aaron.lu, adborden, alan, angiolucci, bosconovic, branislav.klocok, bryan+lk, clancy.kieran+kernel, cribari, cwml2937, dennis.jansen, efgiovanini, email, guilherme, h, impulse221, jagerman, jan, joonas, jos.ferraris, juanmanuel.cabo, kernel, lenb, lyderic.lefever, mephisto.pheles.nyan, mthoring, nils, numian, r.goerke, reshad, rheluani, rui.zhang, san, sebastian.riemer, teppot, thomas, tianyu.lan, tpfaff, zenderro, zygimantas.b |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | any | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmidecode
disassembled dsdt dmesg acpidump acpidump acpidump acpidump BIOS version 10K. Nothing has changed. sys/firmware/acpi/interrupts/* sys/firmware/acpi/interrupts/* dmesg grep dmesg grep dmesg grep 2 dmesg grep complete Full dmesg output as requested in #51 dmidecode |
||
|
Description
Pat
2012-08-02 18:18:30 UTC
Created attachment 76911 [details]
dmidecode
Created attachment 76921 [details]
disassembled dsdt
I also experience this behavior on Arch Linux (kernel 3.4.7-1-ARCH) on my Samsung NP530U4BI (firmware version 08XK) which seems to use the same firmware. I was able to get the lid working using acpi_os_name="Windows 2012". After booting with this parameter, I was able to suspend via the lid switch several times successfully. However, this stopped working after about 2 or 3 suspends (the next day). It also seems that other ACPI events (AC adapter) are effected / not working all of the time. Prior to setting the acpi_os_name, it seemed that the AC status (never the lid switch) would work for a time if I booting into Windows (7 x64) then rebooted into Linux. (In reply to comment #0) > 5 - One odd thing was that after installing the latest bios on the laptop > using > Windows 7, then restarting into Ubuntu worked once, then it never worked > again. > I tried booting in to Windows then rebooting back in to Ubuntu to see if that > is what changed something but it did not work that time. Pat, I think what you're seeing here is the state after the firmware has been reset. This is done after a firmware upgrade or by removing power and using a paperclip to press the battery disconnect button on the bottom of the laptop. Created attachment 76941 [details]
dmesg
Yes, that makes sense, I had read somewhere that a bios reset does make a difference. I was intending to try your suggestion of the acpi_os_name="Windows 2012", however I've been busy with work. It's strange that these work initially then fail. Same problem here, it went away after doing a complete poweroff by pressing the battery button on the rear side. You need to power down, remove ac plug, press the button and plug ac power in before you power on. Reading the manual might also help. (In reply to comment #7) > Same problem here, it went away after doing a complete poweroff by pressing > the > battery button on the rear side. > You need to power down, remove ac plug, press the button and plug ac power in > before you power on. > Reading the manual might also help. As I noted above, this indeed resolves the issue. However, this is only temporary. I've never exceeded 24 hours (uptime) with this working. Same problem here with samsung np-530u3c. The workaround with the battery button doesn't work for me. There's also a problem with the charger. When connecting, the kernel doesn't recognize that and thinks the laptop is still running on battery. I can confirm this behavior on OpenSuse 12.1 with kernel 3.5.2-1-desktop #1 SMP PREEMPT Wed Aug 15 21:49:59 UTC 2012 (4904750) x86_64 x86_64 x86_64 GNU/Linux Both mentioned behaviors are present: Closing lid does not trigger anything. Plugging in the ac adapter is not recognized and the battery indicator still shows running on battery. On to of that suspend to RAM does not work properly and the system does not wake up. Setting acpi_os_name="Windows 2012" did nothing.
Resetting BIOS as per:
> You need to power down, remove ac plug, press the button and plug ac power in
> before you power on.
seems to solve the issue, but I need to wait more time to see if it is stable.
The attached DSDT does not invoke the ACPI \_OS method,
and so it would ignore whatever Linux answers to that method.
So you should see the same if you leave the default
("Microsoft Windows NT"), or override it to something else
with acpi_os_name="....".
If this parameter has any effect on your system, I'm interested
to see the complete output from acpidump for your system --
please attach it to this bug report.
After few days, I have the same problem again. It seems, that closing the lid does nothing. If I ask the system to suspend or hibernate manually it works. acpidump is attached. Created attachment 78251 [details]
acpidump
Created attachment 78311 [details]
acpidump
My acpidump looks different than Branislav's.
Created attachment 78321 [details]
acpidump
Created attachment 78341 [details]
acpidump
acpidump as requested
I upgraded to firmware version 09XK (Samsung NP530U4BI). So far, it seems to exhibit the same behavior. However, I'm hoping it was just a fluke immediately after the update. It's still working after my last reset. I'll report back if and when ACPI event reporting breaks again. Brandon: Do I understand correctly, that upgrade of firmware solved the problem? Hi, I've just updated mine, Samsung NP530U3B, to version 09XK and can confirm the suspend still does not work when closing the lid. Same behavior on firmware version 09XK. It works for a bit after a firmware reset, but now the ACPI events are not coming in again. I can confirm #10 on a samsung 900x3c. Except in my case suspending to RAM does work initiated by the power button or through the menu. Complete poweroff by the battery button works. I think it stopped working the first time it was off AC power. Ubuntu 12.04 x86_64, kernel 3.5.0-14. Created attachment 82311 [details]
BIOS version 10K. Nothing has changed.
(In reply to comment #7) > Same problem here, it went away after doing a complete poweroff by pressing > the > battery button on the rear side. > You need to power down, remove ac plug, press the button and plug ac power in > before you power on. > Reading the manual might also help. This fix bugs with battery indicator and suspend when lid is closed. Well, laptop does not wakeup when lid is opened. When lid is closed, laptop go to a suspend. But not wakeup when opened. *** Bug 48401 has been marked as a duplicate of this bug. *** After reboot, all problems go back to my laptop. Is there any news on this matter? Like mephisto said, even after "unppluging" the battery, all problems goes back after a reboot. I believe it's a serious issue, my laptop almost overheated because I believed that it had gone to sleep after I closed its lid and put it inside my laptop case, when I took it to use it was so warm that almost burned my hands. Also I'd like to add that since kernel 3.6, my laptop does not shutdown anymore, when I ask it to shutdown (unsing init 0 for example) it powers again as if I have asked it to reboot. guilherme: I have tried to prevent these situations by setting some idle time and then suspending to ram automatically no matter if the lid is closed or not, but it is not a solution to the problem. I am using opensuse 12.2. and standard kernel 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/Linux without major issues, the only big problems are: rfkill switch does not work and closed lid is not recognized. The notebook is also very power consuming (according to powertop some 24-32w), I have tried to tune this, but without major success, so I am living with some 1,5 hours of battery life, which is terrible especially, when I am taking the flights. Hope this gets solved soon. It seems like everything related to the embedded controller "Device (H_EC)" doesn't work. "LID0" is connected to it and it should return the 1-bit value "LIDS" from the controller registers with method "_LID". This method is described in the ACPI spec: http://www.acpi.info/DOWNLOADS/ACPIspec50.pdf . The "_LID" method is only called by the following: "Notify (LID0, 0x80)" and this is part of "Method (_Q5E, 0, NotSerialized)" as well as "Method (_Q5F, 0, NotSerialized)" which are embedded controller queries. So if nothing queries that embedded controller, then it can't be reported if the lid is closed or not. It is the same for the power source "ADP1" and the battery "BAT1" as described in bug 44161. These are also connected to that EC. Perhaps, something has to activate that embedded controller first. It is the Intel HM76 chipset. http://www.intel.com/content/www/us/en/chipsets/performance-chipsets/mobile-chipset-hm76.html They have an OEM manual where they describe their embedded controller. http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7-series-chipset-pch-datasheet.pdf Look at page 197. The EC is connected to the SMBus via "SMLink1". Confirmed that there is no access to _OS in the AML of the 5 attached BIOS images. So use of acpi_os_name= should have 0 effect on this system. Does the power button work on this system, or does it fail along with AC and lid events? grep acpi /proc/interrupts will tell you if you get ACPI interrupts grep . /sys/firmware/acpi/interrupts/* will tell you which ones you get if you have a /proc/acpi/event, then kill acpid and "cat /proc/acpi/event" and provoke acpi events such as power button and lid close will tell you what events are getting sent to user-space. If the EC is failing... What does "dmesg | grep -i acpi" show? Finally, does "manual" suspend work on this system? eg. can you "echo mem > /sys/power/state" and then wake up via power button? Confirming this bug on Samsung 530U3C - suspend works nicely when triggered via operating system (Ubuntu 12.10 - 3.7.9-030709-generic) but does not work when lid closed. Power buttons and all that stuff works very well. The laptop just does not realize the lid is closed. Also effected by battery bug #44161 which I guess is somehow related. *** Bug 44161 has been marked as a duplicate of this bug. *** Hi Jason:
Could you do following test and attach the output? This will be helpful to locate the cause. Thanks in advance.
(In reply to comment #31)
> Does the power button work on this system,
> or does it fail along with AC and lid events?
>
> grep acpi /proc/interrupts
> will tell you if you get ACPI interrupts
>
> grep . /sys/firmware/acpi/interrupts/*
> will tell you which ones you get
>
> if you have a /proc/acpi/event,
> then kill acpid and "cat /proc/acpi/event"
> and provoke acpi events such as power button
> and lid close will tell you what events are getting
> sent to user-space.
>
> If the EC is failing... What does "dmesg | grep -i acpi" show?
>
> Finally, does "manual" suspend work on this system?
> eg. can you "echo mem > /sys/power/state"
> and then wake up via power button?
(In reply to comment #34) > > Does the power button work on this system, > > or does it fail along with AC and lid events? Power button works. > > grep acpi /proc/interrupts > > will tell you if you get ACPI interrupts $ grep acpi /proc/interrupts 9: 2362 2053 981 921 IO-APIC-fasteoi acpi > > grep . /sys/firmware/acpi/interrupts/* > > will tell you which ones you get Will attach as sys.firmware.acpi.interrupts file > > if you have a /proc/acpi/event, > > then kill acpid and "cat /proc/acpi/event" > > and provoke acpi events such as power button > > and lid close will tell you what events are getting > > sent to user-space. Killing acpid just restarts it and cat /proc/acpi/event just gives the following; cat: /proc/acpi/event: Device or resource busy Not sure how to do this test? > > If the EC is failing... What does "dmesg | grep -i acpi" show? Attaching dmesg_grep file. No output here when lid closed or power button pressed. Some errors there though, from boot time? > > Finally, does "manual" suspend work on this system? > > eg. can you "echo mem > /sys/power/state" > > and then wake up via power button? Works like a dream. Anything else I can help with? It's a work laptop so anything that doesn't face risk of bricking it ;) Created attachment 93701 [details] sys/firmware/acpi/interrupts/* Relating to comment https://bugzilla.kernel.org/show_bug.cgi?id=45461#c35 Comment on attachment 93701 [details]
sys/firmware/acpi/interrupts/*
will try again with text mimetype
Created attachment 93711 [details] sys/firmware/acpi/interrupts/* Related to comment: https://bugzilla.kernel.org/show_bug.cgi?id=45461#c35 Created attachment 93721 [details] dmesg grep Related to comment https://bugzilla.kernel.org/show_bug.cgi?id=45461#c35 This is a EC bug. I can confirm the behaviour on Arch Linux kernel 3.8.3-2-ARCH #1 SMP PREEMPT Sun Mar 17 13:04:22 CET 2013 x86_64 GNU/Linux with newest BIOS 12XK installed from Samsung. Immediately after upgrading the BIOS it worked for a few reboots but then it does not again. Plugging in or removing power cable ist also not recognized. There is no output from acpi_listen when I close the lid or remove AC plug. *** Bug 56081 has been marked as a duplicate of this bug. *** Hi: EC driver seems not to work on these SunSamg machines. Please apply the following patch to open EC driver debug and attach the output of dmesg to get more clues. https://bugzilla.kernel.org/attachment.cgi?id=96101 Please plug/unplug ec or open/close lid before getting the dmesg. Thanks. I'm recompiling now with your patch. Can you please take a look at bug #56071, seems related to this. Thank you. Created attachment 97051 [details]
dmesg grep
Rebuilded 3.9.0rc5 with your patch, here is the dmesg grep
Created attachment 97061 [details]
dmesg grep 2
another dmesg grep. I've opened and closed the lid, plugged and unplugged AC, used backlight fn keys
Ok. Thanks. I look through the info and there is no sci event.... Strange. Could you provide the complete dmesg also with the operation? It may have more clues. Created attachment 97071 [details]
dmesg grep complete
This is the complete dmesg grep, I've plugged\unplugged AC, used several FN keys, opened\closed the lid.
how on 13xk bios? I just updated BIOS to newest Version 13XK and can say that it looks good so far! Closing lid and (un)plugging AC adapter is recognized and also reported by acpi_listen. I have restarted (powered off and on) my notebook five times now and it still works. Oh. Great to hear this. Ralf, Could you apply EC debug patch and attach the output of dmesg after Closing lid and (un)plugging AC adapter? Thanks in advance. https://bugzilla.kernel.org/attachment.cgi?id=96101 Others, can you try the newes bios? I have bad news because today I see the old situation. (Un)plugging AC and closing the lid isn't recognized anymore. Yesterday after applying new BIOS it worked perfectly even after powering off and on several times. Is there anything else I can help with? How about to reset bios via using a needle and reset the hole on the bottom of the laptop? This is from other Samsung bug reporter. I reset the BIOS as you suggested and now it works again. What I can say now ... it's a bios issue. Could you provide the info I need in the Comment #51 now? Created attachment 97631 [details]
Full dmesg output as requested in #51
Comment on attachment 97631 [details]
Full dmesg output as requested in #51
This is the full output of dmesg with applied debug patch and BIOS 13XK after resetting BIOS. I have (un)plugged AC and closed the lid. It still works.
Thanks for your info. I have seen the sci event is triggered
[ 93.420083] ACPI: EC: ~~~> interrupt, status:0x20 <==
[ 93.420090] ACPI: EC: ---> status = 0x20
[ 93.420095] ACPI: EC: ---> status = 0x20
[ 93.420098] ACPI: EC: push gpe query to the queue
[ 93.420137] ACPI: EC: ---> status = 0x20
[ 93.420140] ACPI: EC: ~~~> interrupt, status:0x20 <==
[ 93.420145] ACPI: EC: ---> status = 0x20
[ 93.420150] ACPI: EC: ---> status = 0x20
[ 93.420164] ACPI: EC: <--- command = 0x84
[ 93.420377] ACPI: EC: ---> status = 0x29
[ 93.420381] ACPI: EC: ~~~> interrupt, status:0x29
[ 93.420386] ACPI: EC: ---> data = 0x66
[ 93.420391] ACPI: EC: ---> status = 0x28
[ 93.420399] ACPI: EC: ---> status = 0x28
[ 93.420401] ACPI: EC: push gpe query to the queue
[ 93.420436] ACPI: EC: ---> status = 0x28
[ 93.420439] ACPI: EC: ~~~> interrupt, status:0x28 <==
[ 93.420444] ACPI: EC: ---> status = 0x28
[ 93.420449] ACPI: EC: ---> status = 0x28
Hi Francescodario:
Can you try to update the bios and test on the NP535U3C?
Yes, but I can do it tomorrow because unfortunately I forgot my AC adapter to the house of a friend. I'll try do update and I'll post dmesg grep tomorrow evening ! Checked just now but there isn't BIOS update for the NP535U3C, latest version is the P06RAG. Some good news... I've updated to 3.9rc6 and lid switch and AC adapter are working and backlight works like a charme with gnome slider. Fn keys for backlight still not working. And I also still have performance decrease bug when I'm on AC. However during the build I've enabled some kernel modules this time : AMD MCE AMD Microcode and under ACPI Support : Deprecated /proc/acpi Deprecated power /proc/acpi directioryes EC read write access through /sys/kernel/ec Deprecated /proc/acpi/event support AC Adapter Battery Button Fan Processor IPMI Thermal Zone Under Hardware Monitoring AMD Famili 15h processor power (In reply to comment #61) > Some good news... I've updated to 3.9rc6 and lid switch and AC adapter are > working and backlight works like a charme with gnome slider. > Fn keys for backlight still not working. And I also still have performance > decrease bug when I'm on AC. > Ok. Great. Can you attach the output of dmesg with ec debug patch after only change backlight? > However during the build I've enabled some kernel modules this time : Could you check whether enable follow two modules to make ec event work? > > AMD MCE > AMD Microcode Please keep /proc/acpi/* avaible. Removing them maybe cause some application work abnormally. Thanks. > Deprecated /proc/acpi > Deprecated power /proc/acpi directioryes > > EC read write access through /sys/kernel/ec > Deprecated /proc/acpi/event support > AC Adapter > Battery > Button > Fan > Processor > IPMI > Thermal Zone > > Under Hardware Monitoring > > AMD Famili 15h processor power I'm sure that enabling AMD MCE and AMD Microcode hasn't helped to make EC event work. I think enabling /proc/acpi/* did the trick. It probably is /proc/acpi/* or something in there as I can recall both the lid and power used to work in the past(September when I got my laptop). Haven't tried the new kernel on my laptop yet though. I've done some tests, and I found out that fn keys should be a catalyst driver bug, because with opensource driver fn keys for backlight works well. (In reply to comment #65) > I've done some tests, and I found out that fn keys should be a catalyst > driver > bug, because with opensource driver fn keys for backlight works well. Ok. Thanks for test. If you can find which commit fix this issue, that will be best;) So there is no problem on the Samsung NP535U3C. Samsung NP530U3B problem seems to be resolved by Bios. Stop, stop, stop, how about fix resume when lid open? Very useful feature. > how about fix resume when lid open?
I would not mix up different issues in this bug.
There are quite some people in CC (24). If everybody starts to report other issues here, it will be too confusing. No one who reads up the bug later or is added to help with a specific issue will go through all the comments (we are already at #67...)
The title of this bug is:
Samsung NP530U3B and NP535U3C lid close does not suspend
if the issue is resolved, the bug should get closed.
If you have another bug which is related to this one (HW or whatever), you may want to add a pointer to the new bug here.
https://bugzilla.kernel.org/show_bug.cgi?id=56451 resume from suspend when lid is open doesn't work bug Bad news... Today I just plugged the AC adapter in and the bug is again here. I really don't know what I should do. At this point I think that the difference was made not by enabling the deprecated /proc/acpi but by the installation of Windows 8. This sounds to me very weird, but after the installation of Windows 8 everything worked well for one day. T_T I just resetted the firmware by pressing the button at the bottom of the laptop and starts to work againg. At this point I think that this should be a BIOS bug. Bug isn't fixed. Certainly not fixed for NP530U3C at least - or missed how to fix it in the comments. Hi all:
From Comment #71 and Comment #57, Samsung NP535U3C and NP530U3B on the newest Bios can close lid to suspend and produce AC (un)plug events. If not work,
please try to reset Bios by pressing the button at the bottom of the laptop and then it should work, right?
OK I will try to get a hold of the latest BIOS (for NP530U3C) to verify. Samsung Finland website says there is some version available but it is only available in Windows executable format. Any ideas? @Lan... Actually I have to press the button at the bottom every time before booting the laptop to make ACPI events work. Who I have to contact for the BIOS bug ? I've tried to mail Samsung Italy but they simply answered me that they support only Windows. But this is a BIOS bug. @Jason, mephisto : Try this : - power off the laptop - press the button at the bottom for 10 seconds - boot in linux - should work Let me know. (In reply to comment #76) > @Lan... Actually I have to press the button at the bottom every time before > booting the laptop to make ACPI events work. Who I have to contact for the > BIOS > bug ? Sorry, I have no idea. > I've tried to mail Samsung Italy but they simply answered me that they > support only Windows. But this is a BIOS bug. > Yes, most OEM just support Windows and they normally provide some specific drivers for their machine only on Windows but not for linux. This is why there is a difference between Windows and Linux. Currently, I have found the gap on the machine is WMI driver. I can see there is WMI support code in the Bios ACPI table. But there is no Samsung WMI driver in the linux. This maybe cause. Just from my guess. > @Jason, mephisto : Try this : > > - power off the laptop > - press the button at the bottom for 10 seconds > - boot in linux > - should work > Please have try. > Let me know. I can confirm with NP530U3C that powering off, battery disconnect (=10 secs of button on bottom pinhole), boot and it works. Both AC events and suspend via closing lid. But it has also been confirmed many times (comments #8, #13, #21, #22, #26, #41, #52, #70 + comments in other bugs like related AC events bug) that any workarounds (resetting BIOS or disconnecting battery) only resolve the issue temporarily. I have booted the laptop a few times and done suspends - but it doesn't mean it will not be back soon. I will let you know once it appears again, within a few days seems quite common :) But anyway, this bug IMHO should be confirmed - not needinfo. We know the bug exists, we just don't know the permanent fix. Also if anyone is interested, I am going to make a formal complaint to the Finnish consumer protection agency about Samsung only offering BIOS updates via Windows executables. I suggest you do the same in your country and also tell Samsung directly. *** Bug 56451 has been marked as a duplicate of this bug. *** Resumed from a longer weekend long suspend and the buggy behaviour is back - plugging in the adapter did not make the battery icon recognize it. Could it be the length of the suspend/shutdown that matters? I did many on Friday and the buggy behaviour did not come back, but having the computer in suspend for the whole weekend brought it back. I don't know how to explain it, but ACPI events just start to work... The only thing I changed is the update of gnome from v. 3.6.3 to v3.8.1 on ArchLinux. I'm on kernel 3.8.8-ck from [repo-ck]. I have also set to load at startup the following modules : processor thermal sbs fam15h_power msr cpuid microcode samsung-laptop And this is the ouput of my lsmod : [alastor@NP535U3C ~]$ lsmod Module Size Used by usb_storage 47575 1 hid_generic 1145 0 usbhid 41596 0 hid 87098 2 hid_generic,usbhid rndis_host 7858 0 cdc_ether 7148 1 rndis_host usbnet 24588 2 rndis_host,cdc_ether ipt_MASQUERADE 2154 1 nf_conntrack_netbios_ns 1077 0 nf_conntrack_broadcast 1253 1 nf_conntrack_netbios_ns xt_tcpudp 3111 34 ip6table_nat 3521 1 nf_nat_ipv6 3640 1 ip6table_nat ip6table_mangle 1716 1 ip6t_REJECT 3852 2 nf_conntrack_ipv6 9769 22 nf_defrag_ipv6 9651 1 nf_conntrack_ipv6 iptable_nat 3358 1 nf_nat_ipv4 3600 1 iptable_nat nf_nat 15571 5 ipt_MASQUERADE,nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat iptable_mangle 1616 1 ipt_REJECT 2281 2 nf_conntrack_ipv4 9326 18 nf_defrag_ipv4 1371 1 nf_conntrack_ipv4 xt_conntrack 3329 38 nf_conntrack 69746 11 nf_conntrack_netbios_ns,ipt_MASQUERADE,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,nf_conntrack_broadcast,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6 ebtable_filter 1799 0 ebtables 24401 1 ebtable_filter ip6table_filter 1460 1 ip6_tables 17408 3 ip6table_filter,ip6table_mangle,ip6table_nat iptable_filter 1520 1 ip_tables 17730 3 iptable_filter,iptable_mangle,iptable_nat x_tables 17831 12 ip6table_filter,ip6table_mangle,ip_tables,xt_tcpudp,ipt_MASQUERADE,xt_conntrack,iptable_filter,ebtables,ipt_REJECT,iptable_mangle,ip6_tables,ip6t_REJECT ath3k 7045 0 btusb 14633 0 bluetooth 303008 2 ath3k,btusb uvcvideo 73384 0 videobuf2_vmalloc 3400 1 uvcvideo videobuf2_memops 2335 1 videobuf2_vmalloc videobuf2_core 27541 1 uvcvideo videodev 105524 2 uvcvideo,videobuf2_core media 10597 2 uvcvideo,videodev nvram 5938 0 joydev 9631 0 acpi_cpufreq 10662 0 mperf 1235 1 acpi_cpufreq kvm_amd 52738 0 kvm 394075 1 kvm_amd snd_hda_codec_realtek 62407 1 btrfs 767760 2 reiserfs 244499 1 snd_hda_codec_hdmi 28529 1 snd_hda_intel 34202 7 crc32c 1768 0 crc32c_intel 14313 1 snd_hda_codec 103106 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel ghash_clmulni_intel 5013 0 snd_hwdep 6492 1 snd_hda_codec libcrc32c 1002 1 btrfs aesni_intel 46263 1 aes_x86_64 7587 1 aesni_intel xts 3135 1 aesni_intel lrw 3661 1 aesni_intel snd_pcm 78108 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel zlib_deflate 20764 1 btrfs gf128mul 6274 2 lrw,xts ablk_helper 2228 1 aesni_intel cryptd 8729 3 ghash_clmulni_intel,aesni_intel,ablk_helper snd_page_alloc 7426 2 snd_pcm,snd_hda_intel evdev 10072 20 snd_timer 18975 1 snd_pcm snd 60077 20 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec,snd_hda_intel soundcore 5482 1 snd pcspkr 1995 0 psmouse 77225 0 serio_raw 5105 0 r8169 57015 0 mii 4059 2 r8169,usbnet k10temp 3082 0 i2c_piix4 10279 0 wmi 8539 0 ac 2568 0 battery 7002 0 vboxdrv 1827688 0 vboxvideo 1901 0 drm 227283 1 vboxvideo i2c_core 23350 3 drm,i2c_piix4,videodev cpufreq_userspace 3360 0 cpuid 2199 0 msr 2597 0 samsung_laptop 8753 0 video 11170 1 samsung_laptop microcode 14356 0 loop 18663 0 fuse 69380 3 fam15h_power 2788 0 f2fs 104577 0 cpufreq_powersave 1246 0 cpufreq_conservative 4289 0 fglrx 5163315 201 amd_iommu_v2 7316 1 fglrx button 4701 1 fglrx arc4 2064 2 ath9k 102439 0 ath9k_common 2160 1 ath9k ath9k_hw 361818 2 ath9k_common,ath9k ath 15521 3 ath9k_common,ath9k,ath9k_hw mac80211 469761 1 ath9k cfg80211 435761 3 ath,ath9k,mac80211 rfkill 16145 5 cfg80211,samsung_laptop,bluetooth sbs 6414 0 sbshc 3515 1 sbs thermal 8513 0 processor 27239 3 acpi_cpufreq ext4 478244 2 crc16 1359 2 ext4,bluetooth jbd2 78312 1 ext4 mbcache 5994 1 ext4 sd_mod 30978 8 ahci 22160 5 ohci_hcd 26576 0 ehci_pci 4120 0 libahci 20855 1 ahci ehci_hcd 47695 1 ehci_pci libata 170821 2 ahci,libahci xhci_hcd 91061 0 scsi_mod 131567 3 usb_storage,libata,sd_mod usbcore 175503 13 ath3k,btusb,uvcvideo,rndis_host,usb_storage,ohci_hcd,ehci_hcd,ehci_pci,usbhid,usbnet,xhci_hcd,cdc_ether usb_common 954 1 usbcore Hi, same problems with some odd behaviour related to power button. - Lid Close does not suspend the machine and lid open does not wake it up; - System does not detect when the AC is connected or disconnected; - Suspend via O.S works fine; and this is the odd behaviour that nobody mentioned: - The power buttons is configured to suspend, but when I press it, it shuts down the computer. So the suspend function only works via O.S. I have a NP530U3C, running openSUSE 12.3 x86_64 (kernel 3.7.10-1.1-desktop). My BIOS version is P09ABH, it's the newest that I can have from Samsung Brazil. I have disabled UEFI before installing Linux and I'm using CSM OS option inside BIOS (due to the BRICK bug). Please let me know what are the system outputs and additional info that I must provide to help you. Tested on kernel 3.9.0-030900 (Ubuntu 13.04 64 bit). The problem stays. My Samsungs model code: NP535U3C-A04SE (AMD A6) I can confirm that lid open/close is not detected anymore after disconnecting or connecting the power cord while in sleep mode. Only way to restore it is to power off and "reset" the battery with the small button underneath. I have also testet Linux both with UEFI and BIOS emulation (CSM OS). The behaviour is identical in both modes. Verified on both 3.8.0-21 and 3.9.0-030900 (Ubuntu 13.04 64 bit). Well, from what I understood the problem isn't related to kernel but is a BIOS bug. Reassign this bug to Bios category. Has anyone tried contacting Samsung over this? Do we have Samsung kernel developers who could maybe help? Yes I have tried to contact them several times but the support guys always pissed me off saying "we only support Winzoz". Samsung unfortunately doesn't care about laptop Linux users. They don't even offer BIOS updates in non-MS format, at least for the NP530.. That's why I finally sold my NP530 and bought a Thinkpad. By the way I am really happy with it :-) Never Samsung again as long they ignore Linux. I mean this seems to be a BIOS bug and they are not willing to help in any way. That's ridiculous. Anyway thank you very much for your help here. @Teppo, unfortunately Samsung does not support linux. I've tried to contact the support chat, but they argue that they only support Windows and I can void the warranty if I install a different OS - well, I think I don't have the warranty anymore =). The default driver and bios update tool uses a Windows app to download and install all the stuff, and they don't have links to these files on their support page. I don't know if we can expect something about this *possible* BIOS bug from them. I didn't mean end-user support. I was thinking more along the lines of asking Samsung kernel developers to talk to Samsung BIOS developers. Sorry for not making that clear. So, this is the end? No updates since more than a mounth.. I suppouse the only patch is sell this peace of aluminium and buy a proper laptop that support linux. so sad.. j0lly, I haven't found any Samsung BIOS developer on LinkedIn. I guess what it really takes is a professional reverse engineer for Windows and computer hardware stuff. If I read in platform drivers things like "unknown magic constant", then it is clear that it has been done via reverse engineering (RE). RE always takes a lot of time and requires very advanced skills. Windows EULA forbids RE. So you need somebody who doesn't mind fighting the dark side with dark force. These people are really rare, busy, hard to trust and difficult to find. Sell the laptop to somebody like that, if you want to get the job done. ;-) Don't expect these guys to send such patches themselves. They want to remain anonymous. I've got a similar legal issue with Wine and advanced game trainer development on Linux. I may only cheat and reverse engineer FOSS games. So I'm having more an education project than a tool I can promote. Can confirm this bug with a new Manufacturer: SAMSUNG ELECTRONICS CO., LTD. Product Name: 530U3C/530U4C/532U3C BIOS Version: P07ABH running Linux birra 3.8.13-gentoo #5 SMP Tue Aug 6 14:53:13 BRT 2013 x86_64 Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz GenuineIntel GNU/Linux Lid is reported always open in $ cat /proc/acpi/button/lid/LID0/state state: open And acpi_listen does not report any events on either lid close/open or plugging/unplugging the AC. Don't even have windo$ on this one so will have to live with this cause won't be able to update the BIOS. Created attachment 107123 [details]
dmidecode
Posting my dmidecode in case its different than one of the previous reporters.
Good news! In Linux 3.11 was added intel rapid start technology support, can somebody test our ultrabook with this kernel? I've updated the kernel to the latest 3.11 mainline. Now there is a strange problem : if I write from terminal acpi -a, the adapter state is showing correctly, but if I write acpi -b the battery state isn't showing correctly, like before. I started having this on my SAMSUNG NP530U3c-A05EE machine this September (or at least I did not notice it before, although I had been using it with Quantal since June). Decided to upgrade to Saucy, however this did not fix the issue for me. No ACPI event is triggered after connecting/disconnecting the AC cable and/or closing the laptop lid. Booted into Windows to see if there is a BIOS update avaible, as suggested by someone here, alas nothing has been provided by SAMSUNG so far. (And I do not believe it will be.) In the duplicated bug report one user reported:
> I have a samsung series 9 np900x3c affected by the same issue.
> I've noticed a pattern in this bug's behavior and I would like to know if
> someone else can confirm the following:
>
> The bug triggers ONLY if a suspend/resume (hibernate/thaw) event happens
> while the laptop is connected to the charger. I've tested this for about 3
> weeks now; I always unplug the charger before suspending (heck, even before
> shutting down the system, although that's unlikely to cause any harm) and
> always plug it in (if needed) only after resume.
>
> Can anyone confirm that I haven't just hit a lucky streak?
I have been following this advice for the past week and it indeed seems to be the case. If I unplug it before suspending AND resume with it being unplugged (in fact, you can actually plug it in *after* suspending, just be sure to unplug it before resuming), the bug DOES NOT get triggered.
However, I should I forget to unplug it before suspending or resume while it is plugged in, the bug occurs and the only way to get rid of it is to press the reset button underneath the laptop.
In my case it is a SAMSUNG Series 5 Ultra NP530U3C-A05EE machine.
I confirm this behavior reported by Žygimantas Beručka and the other user. If I suspend the laptop while plugged in the bug appears and the lid close event is not detected until the reset button is pressed. My laptop is a np900x3c and I'm running kernel 3.11.6 Same deal on my NP9003XC-K01AU. My main work-around is to just press the power button to suspend. Same deal on my new np900x4c - lid state is "open" even when you close the lid. I'm using dual boot with Ubuntu 12.04 and Windows 8. I didn't notice mentioned previously that the same happens in windows 8. Meaning that if my laptop doesn't suspend when the lid is closed in Ubuntu, it doesn't suspend in Windows 8 either (and it ignores all the settings for lid close in windows Power settings). Curiously enought that in windows along with lid the fn keys for display brightness doesn't work too (I had this issue 2 times and both times fn brighness keys got broken with the lid state). Just tried holding up the tiny button at the bottom of the laptop as mentioned previously as a temporary workaround - for now it's working, but i doubt it will last long. I've taken my laptop to samsung service here in Russia - evidently they have not the slightest idea on what is going on and they even changed the motherboard trying to fix it with no result 9 (a pity i googled up this topic just now). Hello, I've installed the latest version of openSUSE (13.1, kernel 3.11.6, KDE 4.11.2, Catalyst proprietary driver on NP535U3C), I'm testing it for a couple of days and it seems that the bug is not present. Everything is working well, like suspend on lid close, hibernation, fn keys, AC adapter plugged and unplugged is correctly recognized, no CPU high usage. The only problem is that fn keys does not work after suspension or hibernation (but this seems to be a Catalyst bug). The strange thing is that if I install ArchLinux, kernel 3.12.1 the bug is stil here. How this is possible ? (In reply to Francescodario Cuzzocrea from comment #105) > The strange thing is that if I install ArchLinux, kernel 3.12.1 the bug is > stil here. > > How this is possible ? They compile INTEL_MEI and INTEL_MEI_ME into the kernel: http://kernel.opensuse.org/cgit/kernel-source/tree/config/x86_64/default?h=openSUSE-13.1 According to this they do it for an "Altera FPGA firmware download module". They also maintain custom patches for the kernel. Arch compiles the MEI stuff as modules which doesn't work correctly it seems. What sebastian.riemer said is correct! compile INTEL_MEI and INTEL_MEI_ME into the kernel , reset the power and LID CLOSE and AC/BATTERY switch will work. LID CLOSE working. Switch to AC or Battery working. LID OPEN not working properly (it's not detected). What I've done: I compiled a 3.12.1 vanilla kernel, and set the INTEL_MEI and INTEL_MEI_ME to be compiled into the kernel. I also pressed the "reset power" button, under the laptop for 15 secs. It's still working now, 5 day after the above steps. NOTE: If you change the LID CLOSE/OPEN settings in gnome-tweak-tool, everything will stop to work, and you'll need to use the "reset power" button again. That was the only issue I've noticed. Em Qua 27 Nov. 2013, às 14:56, bugzilla-daemon@bugzilla.kernel.org escreveu: > https://bugzilla.kernel.org/show_bug.cgi?id=45461 > > --- Comment #106 from Sebastian Riemer > <sebastian.riemer@profitbricks.com> --- > (In reply to Francescodario Cuzzocrea from comment #105) > > The strange thing is that if I install ArchLinux, kernel 3.12.1 the bug is > > stil here. > > > > How this is possible ? > > They compile INTEL_MEI and INTEL_MEI_ME into the kernel: > > http://kernel.opensuse.org/cgit/kernel-source/tree/config/x86_64/default?h=openSUSE-13.1 > > According to this they do it for an "Altera FPGA firmware download > module". > They also maintain custom patches for the kernel. > > Arch compiles the MEI stuff as modules which doesn't work correctly it > seems. > > -- > You are receiving this mail because: > You are on the CC list for the bug. Unfortunately I can't confirm that building MEI modules into the kernel is effective. With Ubuntu saucy on a mainline 3.12 kernel with those built in, I have identical behavior as the kernel shipping with saucy. It lasts up to a couple of days working normally, and then the problem returns. Yes, the problem returned after 5 days. Bulding MEI into the kernel is not effective as I expected. Sorry about the "false positive". Em Seg 2 Dez. 2013, às 13:43, bugzilla-daemon@bugzilla.kernel.org escreveu: > https://bugzilla.kernel.org/show_bug.cgi?id=45461 > > --- Comment #108 from Bryan Stine <bryan+lk@southcape.org> --- > Unfortunately I can't confirm that building MEI modules into the kernel > is > effective. > > With Ubuntu saucy on a mainline 3.12 kernel with those built in, I have > identical behavior as the kernel shipping with saucy. It lasts up to a > couple > of days working normally, and then the problem returns. > > -- > You are receiving this mail because: > You are on the CC list for the bug. Please compare with bug 44161. The LMS has to be running in user-space as well. But it only works on (by hardware) Intel vPro enabled systems. For other systems like the NP900X4C-A03US there is no solution, yet. But with another MEI client software or custom kernel hacking it could possibly also work for these systems. I would look for hardware access (like setting activation bits) in the MEI driver to see why it's working on vPro/AMT enabled systems. The kernel entry point for the LMS is in drivers/misc/mei/main.c, function mei_ioctl(). Does the laptop also slow down during charging for any of you? Maybe it's related to this Samsung bug? https://bugzilla.kernel.org/show_bug.cgi?id=57271 Possible fix found - see: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c125 The program from https://launchpadlibrarian.net/166660507/samsung_fix_ec_events.c did help my system to accurately find when AC is plugged in and out. However it did not fix the lid issue for me. But I think it's a good approach. (Using the battery / hard reset button on the buttom of the laptop did.) Actually, it does seem to fix the issue mostly. While it takes a few seconds, lid close is now detected with the latest patch from https://bugzilla.kernel.org/show_bug.cgi?id=44161. For me, lid close always took about 10 seconds to be detected, even in windows. I guess this is by design to avoid stray inputs. In my experience with NP900X4C, the originally shipped Windows system suspended on lid immediately. I believe some part of Samsung's Easy Settings program, or perhaps some OEM driver they shipped with Windows, may have prodded something to make it behave better. Eventually, after removing the original installation of Windows and using a "vanilla" Windows 7 in dual boot with Linux, lid close detection was delayed in Windows as well. In addition to the delay on lid close notifications, the EC workaround also has no apparent effect on the inability of the lid to wake the system from S3 (with or without my weak attempts at DSDT hacks). Thanks for the excellent work, Juan. Your work is a great breakthrough on what has been a major pain for many Samsung users. Agree with Juan. Please read https://bugzilla.kernel.org/show_bug.cgi?id=44161#c157 from comment no. 157. Not sure about windows. (In reply to Bryan Stine from comment #116) > In my experience with NP900X4C, the originally shipped Windows system > suspended on lid immediately. I believe some part of Samsung's Easy Settings > program, or perhaps some OEM driver they shipped with Windows, may have > prodded something to make it behave better. > > Eventually, after removing the original installation of Windows and using a > "vanilla" Windows 7 in dual boot with Linux, lid close detection was delayed > in Windows as well. > Then this seems to be a hardware/firmware problem, right? Bug closed, please feel free to re-open it if this is a real Linux kernel problem. |