'3.13.0-66-lowlatency #108+7.0trisquel2' is also ok, I'm now trying to install a trisquel version of a known-to-fail kernel, to see if it's due to the configuration (or blobs)

I confirm the bug happens with '3.19.0-25-generic #26~14.04.01-Ubuntu', which is the version packaged in trisquel, stripped of any blob.

In this case I noticed this error at boot time:
ACPI PCC probe failed

Kernel '3.16.0-51-lowlatency' is also good, so regression must have happened in 3.17, 3.18 or 3.19

To find the offending kernel commit, you will need to use git bisect:
https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html

First, you will need to find out two adjacent kernels that the first works and the 2nd doesn't, and then start bisect from there.

3.18.22 is still good

I'm taking it back, 3.18.22 isn't necessarely good (I might have built it incorrectly).
By only relying on prepackaged kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ I found latest GOOD being 3.17.8 (as well as 3.17.0) and first BAD being 3.18.0 (as well as 3.18.22 and 3.18.23).

Bisect is in progress (but very very slow). So far:
3.17-19-g354f1db is GOOD
3.17-30-gdbcbe68 is BAD

Finally completed: 
dbcbe68bb76c4f8057160209859ecd7c75e86c30 is the first bad commit

Bisect log:
# bad: [f114040e3ea6e07372334ade75d1ee0775c355e1] Linux 3.18-rc1
# good: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17
git bisect start 'v3.18-rc1' 'v3.17' '--' 'drivers/acpi' 'arch/x86/kernel/acpi' 'include/acpi'
# good: [354f1dbe1905f8ab34ec5950277643a625b0c7f5] Merge branch 'acpi-video'
git bisect good 354f1dbe1905f8ab34ec5950277643a625b0c7f5
# bad: [dbcbe68bb76c4f8057160209859ecd7c75e86c30] Merge branches 'acpi-pnp' and 'acpi-blacklist'
git bisect bad dbcbe68bb76c4f8057160209859ecd7c75e86c30
# good: [871dd05c0520c2e4caf5516455fb08abc86cd703] Merge back earlier 'acpi-lpss' material for 3.18-rc1
git bisect good 871dd05c0520c2e4caf5516455fb08abc86cd703
# good: [a13f453140d542f9d5a0ee15601531c72e5401d7] Merge branch 'acpi-lpss'
git bisect good a13f453140d542f9d5a0ee15601531c72e5401d7
# good: [4990141496b82f91cb96b37100ac882ea5cee8b7] ACPI / PNP: remove Fujitsu device IDs from ACPI PNP ID list
git bisect good 4990141496b82f91cb96b37100ac882ea5cee8b7
# good: [8ee4104a681a3a30a495265825d8ebfe87d57d28] ACPI / blacklist: add Win8 OSI quirks for some Dell laptop models
git bisect good 8ee4104a681a3a30a495265825d8ebfe87d57d28
# first bad commit: [dbcbe68bb76c4f8057160209859ecd7c75e86c30] Merge branches 'acpi-pnp' and 'acpi-blacklist'

let me know how else I can be of help

The offending commit is a merge with 3 parents.
All parents are GOOD, the merge commit is BAD.
The smallest diff is against parent a13f453, and can be seen here:
http://strk.keybit.net/tmp/dbcbe68b-a13f453.diff

Created attachment 191691 [details]
lshw output

does the problem still exist if you revert these two commits?

(In reply to Zhang Rui from comment #12)
> does the problem still exist if you revert these two commits?

BTW, I don't think any of these two commits could bring any problem for your laptop. Please ignore my previous comment. :)

I will reverse-apply the patch linked in comment 11 and test again.

Actually, reverse-applying that patch takes me back to a13f453140d542f9d5a0ee15601531c72e5401d7 which I've already tested as being GOOD.

indeed I cannot confirm dbcbe68bb76c4f8057160209859ecd7c75e86c30 is bad either :(
I guess I'll have to restart bisecting

I've just found a bug in my testing procedure: lately I was testing with just "reboot" while I've just found that even 3.16.0-51-lowlatency fails with "halt" while it succeeds with "shutdown -h now" and "reboot".

Do these differences help finding out more ?

By contrary, behaviour of 4.2.5-040205-lowlatency is:
 shutdown -h now: bad                                                            
 reboot: bad                                                                     
 halt: bad

3.13.0-66-lowlatency behaves the same as 3.16.0-51-lowlatency:
 reboot: good
 shutdown -h now: good
 halt: bad

3.18.0-031800rc1-lowlatency same as 4.2.5-040205-lowlatency:
 shutdown -h now: bad                                                            
 reboot: bad                                                                     
 halt: bad

so, it seems that halt is always bad on your system...

this seems to be two problems to me, one is the halt issue and another one is the shutdown/reboot issue.
Please confirm if the halt broken is a regression or not first.

I could actually find no system where "halt" powers off the machine, so that I thought it isn't really meant to. Am I wrong ?

I think halt means the system stops, but power is not cut off.

Halt is indeed not meant to cut power, AFAIK. 

This bug also appears on Lenovo B50-10 and the firmware upgrade (to v2.04) does not yet solve it. Downgrade to kernel linux-image-3.16.0-57-generic in Ubuntu Trusty solved it. In case someone wants to try the Lenovo Insyde UEFI upgrade instructions for Linux: https://forums.lenovo.com/t5/Welcome-FAQs-Knowledge-Base/How-to-flash-InsydeH2O-EFI-under-DOS-enviroment/ta-p/278406

Looking at the offending commit part by strk@keybit.net 2015-10-31 11:05:37 UTC : is it possible that the insyde UEFI misidentifies itself? Insyde is in many cheapo business laptops, I had the same problem with HP 250 G3 (UEFI update, performed on Linux, solved it).

Will try to isolate the problem and reconfigure-recompile some kernels if I get to it.

strk@keybit.net,

Can you please restart your git bisect?
You just need to confirm if "shutdown -h now"/"reboot" work or not this time.

Zhang, I settled down for now with the latest working kernel (3.16.0-51-lowlatency) but have run out of time on the task. I guess I might get back on this on a possible future accidental upgrade...

well, it's a pity to drop your effort on this, since we have narrowed down the problem between 3.16-51 and 3.18.0-031800rc1then .
If you really don't have time for this, I will close this bug report for now.
And please feel free to re-open it at anytime when you can restart your bisection.