Bug 69011

Hi, Could you provide the whole output of acpidump?

Created attachment 122881 [details]
acpidump from ASUS T100TA

*** Bug 70401 has been marked as a duplicate of this bug. ***

Same symptom and likely same cause on Venue 8 Pro and Miix2 (other Bay Trail-based tablets). Jan-Michael Brummer is currently working on this and has made some progress.

Ok. I am also working on implementing I2C ACPI operation region handler.
Jan-Michael, what are you working on? There maybe a overlapped work.

Created attachment 125681 [details]
acpidump from a Venue 8 Pro

Created attachment 129881 [details]
draft.patch

Hi Adam, could you test this patch on the Venue 8 pro?

sure. looks like it needs some rediffing, so I'll get to it tomorrow. thanks for the work!

OK, looks like you're working on top of https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/drivers/acpi/scan.c?h=linux-next&id=2bd74d91b1217d84d08db57b860d056d130248d3 which isn't in 3.14...differences don't look significant, so I've just re-diffed the patch and will test.

I've tested draft.patch on ASUS T100TA and battery status works as you can see below:

cat /sys/class/power_supply/BATC/uevent
POWER_SUPPLY_NAME=BATC
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=8
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3750000
POWER_SUPPLY_VOLTAGE_NOW=4174000
POWER_SUPPLY_CURRENT_NOW=1172000
POWER_SUPPLY_CHARGE_FULL_DESIGN=8180000
POWER_SUPPLY_CHARGE_FULL=9595000
POWER_SUPPLY_CHARGE_NOW=9316000
POWER_SUPPLY_CAPACITY=97
POWER_SUPPLY_MODEL_NAME=SR Real Battery
POWER_SUPPLY_MANUFACTURER=Intel SR 1
POWER_SUPPLY_SERIAL_NUMBER=123456789

Hum, 3.14rc7 (current Fedora Rawhide kernel) with the rediffed patch attached hangs on boot: couple of status messages from dw_i2c_acpi_space_handler , then a 'unable to handle kernel NULL pointer dereference at  (null)'.

do I maybe need some of the changes that aren't in mainline yet, in addition to this patch and the others I'm carrying in fedlet?

For my tests I've used Linus tree 3.14-rc4 merged with linux-pm/master  and broonie/for-next. I'm still using 3 patches for "black screen" and fixes for reboot and poweroff. 

broonie/for-next: ff885b90afcc4fa9c7dd19b0714f7967ba2b7795
linux-pm/master: 6c09ea49ceb8a3b2b709718f6acdb1edd92ea899
linus/master: 8427defd087ae6c5eaea9d609dfe7f165568accd

So Fedora Rawhide is now onto 3.15, so I gave this another shot. The patch applies without any rediffing needed, but still causes a crash on boot for me. First time it happened I got a proper traceback pointing to i2c_designware_platform, second time is more like I mentioned in c#11, just a couple of status messages from dw_i2c_acpi_space_handler and then a line of ===== . I'll try a couple more boots and try to get the traceback again.

An unmodified Rawhide kernel 3.15 boots OK, so it definitely seems to be to do with this patch.

well jeez, I sure wish I'd taken a photo of the traceback first time I hit it. Seems very difficult to reproduce. I either get no traceback, or way too much, till I'm hitting subsequent tainted ones. Attaching the best pictures I could manage.

The kernel I built is at http://koji.fedoraproject.org/koji/taskinfo?taskID=6700154 ; could you try installing kernel- and kernel-modules-extra- from that build and see if it boots for you? If you have a 32-bit install, of course. Oh, yeah, that may be significant: I am booting 32-bit here, I'm not using any of the 64-on-32 tricks.

er, I mean it's 'difficult to reproduce' in the sense of 'difficult to get it to hang with the best traceback visible'. It always hangs, 100% of the time.

Created attachment 131291 [details]
best image of the crash that I could manage

Created attachment 131321 [details]
debug.patch

Please try the new patches.

Looks good! With that version of the patch, fedlet (Venue 8 Pro) boots and I get battery information from GNOME. woop! Thanks :)

any word on getting this upstreamed? I don't see it queued anywhere, though I might be missing it. Seems to be working fine here (the latest version, from c#17).

I will upstream these patches after merge Window. This is feature patchset and so it targets v3.16.

If this is merged in kernel 3.16 I would recommend closing this.
Cheers Nick

I don't believe it is fully upstreamed yet. Lan?

That's Ok just reminding you to close when it's
upstream it.
Thanks Nick

No, some patches haven't been merged into v3.16 due to lack I2C maintainer's ACK.

That's fine just close this when fixed.
There seem to be a lot of bugs that aren't
closed on Bugzilla and I hope to help clean
this up. In addition I am also debugging 
when I have time.
Thanks Nick

I think we can mark this bug as resolved with patch_alread_available. When the remaining patches have been merged, close it.

Thanks fine, I just am reminding developers to close bugs that
are fixed or obsolete.
Nick

*** Bug 82651 has been marked as a duplicate of this bug. ***

Adam, could you please attach or push an updated version of https://github.com/AdamWill/baytrail-m/blob/master/kernel/x86-new-Intel-Atom-SoC-power-management-controller-driver.patch (ideally against 3.16 or so)?  TIA :)

Lan, could you please point me towards a (linux-pm?) branch that contains this work?  Somewhat lost in a flurry of patches so far...

Michael: I don't remember ever updating/rediffing it, but the copy I had in my kernel build dir was slightly different to the copy in the baytrail-m repo, so I just adjusted it to match. It was only a small change, though. This one applies against 3.16, for me.

(3.17 kernels keep hanging right after grub with just two repeating ASCII characters displayed on the console for me, which is odd.)

Just a quick note: There is a v3 version of the above patch, but Adam should be aware of that:

http://www.spinics.net/lists/kernel/msg1774068.html

I haven't been following super closely lately, with the showstopper bugs I'm hitting :( just building 3.16/3.17 as they come out and hitting fail after fail.

Created attachment 148931 [details]
acpidump from Aava Inari 8

Ah, that effect again: found http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86%2Fplatform (which holds v3 AFAICT) just shortly after having bothered people here; these commits applied to 3.16.1 with no problems:
b00055cade45379fb6a51798b70ef520d7555c5f
f855911c1f481734191615a7438a396f52a915dc
4c51cb005b29e6329d7e598bf835689b230817c9
...but result in no battery status either -- apparently like Rolf with pre-release sample of the same baytrail-based tablet before: https://lkml.org/lkml/2014/5/15/102 (judging by two models discussed above it might still fit this discussion).

I'm willing to test and provide feedback but my C (moreso kernel) skills are very basic at best, even git one is better.

The above patch in comment 13 worked great to give is battery info in kernel 3.14, on the ASUS T100TA when 3.15 come out the battery info was not merged, nor in 3.16 but some off the files in the patch have been merged into the latest mainline kernel while others have not been, all we hopefully need is someone to compare the patch with the mainline kernel files and add the patch info into the kernel and hopefully be good to go :)

make that comment 17 :)

Please apply the following patch with enabling "CONFIG_ACPI_I2C_OPREGION" and try again on the v3.17-rc2.

Created attachment 148961 [details]
0001-ACPI-temporary-dep-solution-for-battery-support.patch

it successfully adds the battery here, 

[    0.277990] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.278192] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.278210] PCI: not using MMCONFIG
[    0.278547] PCI: Using configuration type 1 for base access
[    0.286830] ACPI: Added _OSI(Module Device)
[    0.286845] ACPI: Added _OSI(Processor Device)
[    0.286854] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.286864] ACPI: Added _OSI(Processor Aggregator Device)
[    0.319450] ACPI: Dynamic OEM Table Load:
[    0.319485] ACPI: SSDT 0xEBAE2800 000353 (v01 PmRef  Cpu0Ist  00003000 INTL 20061109)
[    0.321768] ACPI: Dynamic OEM Table Load:
[    0.321797] ACPI: SSDT 0xEB852800 000442 (v01 PmRef  Cpu0Cst  00003001 INTL 20061109)
[    0.330382] ACPI: Dynamic OEM Table Load:
[    0.330410] ACPI: SSDT 0xEBB1B400 00015F (v01 PmRef  ApIst    00003000 INTL 20061109)
[    0.333927] ACPI: Dynamic OEM Table Load:
[    0.333955] ACPI: SSDT 0xEBB0D0C0 00008D (v01 PmRef  ApCst    00003000 INTL 20061109)
[    0.339945] ACPI: Interpreter enabled
[    0.339984] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140724/hwxface-580)
[    0.340009] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140724/hwxface-580)
[    0.340030] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20140724/hwxface-580)
[    0.340053] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S4_] (20140724/hwxface-580)
[    0.340082] ACPI: (supports S0)
[    0.340092] ACPI: Using IOAPIC for interrupt routing
[    0.340159] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.349819] [Firmware Info]: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] not reserved in ACPI motherboard resources
[    0.349838] PCI: not using MMCONFIG
[    0.349885] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.353839] ACPI: Power Resource [USBC] (on)
[    0.364232] ACPI: Power Resource [PLPE] (on)
[    0.371692] ACPI: \_SB_.I2C1.BATC: is added to dep device list.
[    0.373118] ACPI: Power Resource [CLK0] (on)
[    0.373247] ACPI: Power Resource [CLK1] (on)
[    0.373531] ACPI: Power Resource [P28X] (off)
[    0.373658] ACPI: Power Resource [P18X] (off)
[    0.374672] ACPI: Power Resource [TCPR] (off)


but does not put it in the ACPI power section

[    1.222898] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.222956] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    1.223156] intel_idle: MWAIT substates: 0x33000020
[    1.223162] intel_idle: v0.4 model 0x37
[    1.223166] intel_idle: lapic_timer_reliable_states 0xffffffff
[    1.223715] ipmi message handler version 39.2
[    1.224136] ACPI: AC Adapter [ADP1] (on-line)
[    1.224554] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0
[    1.224602] ACPI: Lid Switch [LID]
[    1.224736] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1
[    1.224755] ACPI: Sleep Button [SLPB]
[    1.229012] [Firmware Bug]: No valid trip found

there should be a ACPI: Battery0 [BATC] in there somewhere after the AC ADAPTER

hope this helps

thank you for your hard work

Created attachment 149061 [details]
dmesg from Aava Inari 8 (#c37 patch applied)

(In reply to Lan Tianyu from comment #36)
> Please apply the following patch with enabling "CONFIG_ACPI_I2C_OPREGION"
> and try again on the v3.17-rc2.
Thank you; here's a dmesg off v3.17-rc3 with this patch applied and CONFIG_ACPI_I2C_OPREGION=y (sorry for delay, depmod loops took me some time).

(In reply to bloften80 from comment #38)
> [    0.353839] ACPI: Power Resource [USBC] (on)
> [    0.364232] ACPI: Power Resource [PLPE] (on)
> [    0.371692] ACPI: \_SB_.I2C1.BATC: is added to dep device list.
> [    0.373118] ACPI: Power Resource [CLK0] (on)
> [    0.373247] ACPI: Power Resource [CLK1] (on)
> [    0.373531] ACPI: Power Resource [P28X] (off)
> [    0.373658] ACPI: Power Resource [P18X] (off)
> [    0.374672] ACPI: Power Resource [TCPR] (off)

Literally the same here, with this added as the second line:
ACPI: Power Resource [WWPR] (off)

Lan,

One of the people over on our Google Plus T100TA group, has the battery patch successfully working on an ubuntu 3.16 kernel, i will try to upload it here for you to look at it to see if you can incorporate it into the 3.17 mainline kernel



(In reply to Michael Shigorin from comment #39)
> Created attachment 149061 [details]
> dmesg from Aava Inari 8 (#c37 patch applied)
> 
> (In reply to Lan Tianyu from comment #36)
> > Please apply the following patch with enabling "CONFIG_ACPI_I2C_OPREGION"
> > and try again on the v3.17-rc2.
> Thank you; here's a dmesg off v3.17-rc3 with this patch applied and
> CONFIG_ACPI_I2C_OPREGION=y (sorry for delay, depmod loops took me some time).
> 
> (In reply to bloften80 from comment #38)
> > [    0.353839] ACPI: Power Resource [USBC] (on)
> > [    0.364232] ACPI: Power Resource [PLPE] (on)
> > [    0.371692] ACPI: \_SB_.I2C1.BATC: is added to dep device list.
> > [    0.373118] ACPI: Power Resource [CLK0] (on)
> > [    0.373247] ACPI: Power Resource [CLK1] (on)
> > [    0.373531] ACPI: Power Resource [P28X] (off)
> > [    0.373658] ACPI: Power Resource [P18X] (off)
> > [    0.374672] ACPI: Power Resource [TCPR] (off)
> 
> Literally the same here, with this added as the second line:
> ACPI: Power Resource [WWPR] (off)

(In reply to bloften80 from comment #40)
Attachment size limit is 5M which is way below any contemporary kernel source archive size, posting dmesg and config as attachments plus patchset description (with a reference to the exact base kernel repository used) might be more useful.

IIRC the battery status stuff works for me in current Fedlet kernels (I still have the black screen problem, but if I ssh in and run upower, I get the battery %age). I believe I'm applying x86-new-Intel-Atom-SoC-power-management-controller-driver.patch and 0001-ACPI-temporary-dep-solution-for-battery-support.patch that are relevant. I've just pushed the versions of those I have in my current 'fedlet' tree to my baytrail-m github repo - https://github.com/AdamWill/baytrail-m .

I'm away from home ATM and don't have the fedlet with me, but I'll try and check on it when I get back.

*** Bug 83941 has been marked as a duplicate of this bug. ***

Created attachment 151141 [details]
Restore battery support on kernel 3.17.0-rc5

Patch provided in comment 37 was not enough in my tests on kernel 3.17.0-rc5 (drm-intel-nigthly), so I have merged some part of original patch from comment 7.
With this additional patch, battery status works again.

confirmed working, thanks alot Jacek Danecki!!

perhaps we can get this tweaked/confirmed by the linux powers that be and get it upstreamed?

thanks!

Hi All:
      I am upstreaming DEP feature to support battery function on the T100TA. Please try the following patch with enabling "CONFIG_ACPI_I2C_OPREGION" on the v3.17-rc6. Thanks.

http://marc.info/?l=linux-acpi&m=141145626321682&w=2

downloading latest 3.17 rc6 kernel will apply this patch and confirm for you, thank you for your help!

Created attachment 151771 [details]
dmesg from Aava Inari 8 (3.17-rc6 with #c46, #c44 patches applied)

(In reply to Lan Tianyu from comment #46)
> Please try the following patch with enabling "CONFIG_ACPI_I2C_OPREGION"
> on the v3.17-rc6.
Didn't help my aava tablet unfortunately:

$ dmesg -t | grep 'ACPI.*Power'
ACPI: Power Resource [USBC] (on)
ACPI: Power Resource [WWPR] (off)
ACPI: Power Resource [PLPE] (on)
ACPI: Power Resource [CLK0] (on)
ACPI: Power Resource [CLK1] (on)
ACPI: Power Resource [P28X] (off)
ACPI: Power Resource [P18X] (off)
ACPI: Power Resource [TCPR] (off)
ACPI: Power Button [PWRF]
$ ls /sys/class/power_supply 
ADP1

(In reply to Jacek Danecki from comment #44)
> With this additional patch, battery status works again.
Didn't help either (applied on top of v3.17-rc6 + the one proposed by Lan).

Please mail me your baytrail kernel config someone -- maybe 64-bit firmware is more buggy, that's what I'm running (and would prefer to if possible)...

(In reply to Lan Tianyu from comment #46)
> Hi All:
>       I am upstreaming DEP feature to support battery function on the
> T100TA. Please try the following patch with enabling
> "CONFIG_ACPI_I2C_OPREGION" on the v3.17-rc6. Thanks.
> 
> http://marc.info/?l=linux-acpi&m=141145626321682&w=2

Greetings,

I've also tried your latest patch on my Thinkpad-8 (64bit UEFI/OS, baytrail z3795) today, but no luck. Although I've done patchworks to Utopic's latest stable kernel (3.16.0-17-23-generic). Surely I've compiled it with i2c-acpi.c and intel-soc-pmic/crystalcove. So you could see the error by INT33FD (I2C7: PMIC controller) as well...

dmesg is here: http://paste.ubuntu.com/8419018/

I too confirmed that "_STA returns 0" issue was stopped, but [\_SB_.STR1._TMP] (Node ffff88013b064168), AE_ERROR (20140424/psparse-536) was appeared now.

Created attachment 151811 [details]
dsdt.dsl

Added dsdt.dsl of my Thinkpad-8 (64bit, Z3795)

Created attachment 151831 [details]
dmesg from T100TA - kernel 3.17.0-rc5

# dmesg -t  | grep Power
ACPI: Power Resource [USBC] (on)
ACPI: Power Resource [PLPE] (on)
ACPI: Power Resource [CLK0] (on)
ACPI: Power Resource [CLK1] (on)
ACPI: Power Resource [P28X] (off)
ACPI: Power Resource [P18X] (off)
ACPI: Power Resource [TCPR] (off)

# uname -a
Linux asus 3.17.0-rc5-asus5+ #24 SMP PREEMPT Sun Sep 21 21:32:24 UTC 2014 i686 GNU/Linux

# ls -l /sys/class/power_supply/
total 0
lrwxrwxrwx 1 root root 0 Sep 24 22:12 ADP1 -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ADP1
lrwxrwxrwx 1 root root 0 Sep 24 22:12 BATC -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/80860F41:00/PNP0C0A:00/power_supply/BATC

# dmesg -t  | grep BATC         
ACPI: \_SB_.I2C1.BATC: is added to dep device list.
ACPI: \_SB_.I2C1.BATC: Device is readly
ACPI: Battery Slot [BATC] (battery present)

# ./dmidecode | grep Z3740
	Version: Intel(R) Atom(TM) CPU Z3740 @ 1.33GHz

Created attachment 151841 [details]
.config for kernel 3.17.0-rc5

and output from uevent file

# cat /sys/class/power_supply/BATC/uevent 
POWER_SUPPLY_NAME=BATC
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=20
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3750000
POWER_SUPPLY_VOLTAGE_NOW=3506000
POWER_SUPPLY_CURRENT_NOW=136000
POWER_SUPPLY_CHARGE_FULL_DESIGN=8180000
POWER_SUPPLY_CHARGE_FULL=8052000
POWER_SUPPLY_CHARGE_NOW=162000
POWER_SUPPLY_CAPACITY=2
POWER_SUPPLY_CAPACITY_LEVEL=Low
POWER_SUPPLY_MODEL_NAME=SR Real Battery
POWER_SUPPLY_MANUFACTURER=Intel SR 1
POWER_SUPPLY_SERIAL_NUMBER=123456789

(In reply to Lan Tianyu from comment #46)
> Hi All:
>       I am upstreaming DEP feature to support battery function on the
> T100TA. Please try the following patch with enabling
> "CONFIG_ACPI_I2C_OPREGION" on the v3.17-rc6. Thanks.
> 
> http://marc.info/?l=linux-acpi&m=141145626321682&w=2

This patch doesn't work on kernel 3.17.0-rc6 from drm-intel-nightly on Asus T100TA.
Battery status is missing.

confirming it doesn't seem to work on V8P either. the old 'temporary' patch gives battery status, if I replace it with the one linked in https://bugzilla.kernel.org/show_bug.cgi?id=69011#c46 , no battery status any more.

Hi All:
        Could you test my recent patch with CONFIG_ACPI_I2C_OPREGION?
http://marc.info/?l=linux-acpi&m=141442307807033&w=2

I've tested your patch with enabled CONFIG_ACPI_I2C_OPREGION and it works fine on current torvalds git. Thanks.

A better URL for the patch:
http://article.gmane.org/gmane.linux.drivers.i2c/20381
(add "/raw" to the URL to download the patch).

Building to test on a Onda v975w shortly.

(In reply to Jan-Michael Brummer from comment #56)
> I've tested your patch with enabled CONFIG_ACPI_I2C_OPREGION and it works
> fine on current torvalds git. Thanks.

Tested with the same patch on a Onda v975w, and it tries very hard to detect the battery but fails. I'll put the dmesg information in bug 83941 as those seem like different problems (if it works on the T100TA and fails on my tablet).

Patch does not apply against current master - since "ACPI: make acpi_create_platform_device() an external API" was merged , https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/acpi.h?id=083bf668cb70e47b84db64856606e94beac87f01 . It's easy enough to rediff.

With the trivial rediff, the current patch - I like using Patchwork, https://patchwork.kernel.org/patch/5161621/ - works on Venue 8 Pro, battery status is available.

Created attachment 157131 [details]
patchwork #5161621 rediffed against 3.18-rc4

Here's https://patchwork.kernel.org/patch/5161621/ rediffed for v3.18-rc4.

Works for me on Aava Inari 8 with acpi(1) presenting battery info and

[    6.915918] ACPI: AC Adapter [ADP1] (on-line)
[    6.925738] ACPI: Battery Slot [BATC] (battery present)

Hi, Tianyu,
what's the status of this bug?
I think we can mark it as resolved as all the code for this issue is available, we can close it when the code shipped in upstream kernel.

All fixed patches have been merged into upstream kernel. So close this bug.