Created attachment 180471 [details] journalctl-output Hi I have purchased a new ACER machine and installed FEDORA 22 on the same. But when I try to SHUTDOWN/REBOOT, the machine initiates shutdown process, and black screen appears with "Powering off" message, and FAILS to power OFF the machine. journalctl has following message in it : Jun 21 00:18:19 localhost.localdomain kernel: ACPI Warning: SystemIO range 0x0000000000002000-0x000000000000201F conflicts with OpRegion 0x0000000000002000-0x000000000000200F (\_SB_.PCI0.SBUS.SMBI) (20150204/utaddress-254) Jun 21 00:18:19 localhost.localdomain kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Attaching the txt file with the message.
Created attachment 180481 [details] lspci.txt
Created attachment 180491 [details] lsusb.txt
Please do let me know , if any more info is needed.
To Power off the Acer laptop, the POWER button needs to be kept pressed fro 5-6 seconds.
The machine Powers OFF/Reboot perfectly fine with Ubuntu 14.04.2 with kernel 3.16.
Hi, IMO, the ACPI log may not be related to the issue. You should be able to see it with kernel 3.16. And if so, this bug is not related to ACPICA-Core. Thanks and best regards -Lv
Can you please bisect? Also, you can try latest upstream kernel v4.1.
Thanks a lot Lv and Aaron for the reply. 1) I'll check the ACPI log with kernel 3.16 & will also share the result with kernel 4.1. 2) Since I had observed the issue with Fedora kernel "4.0.5-300.fc22.x86_64", so should I simply upgrade the kernel to "4.1"(if available) or MANUALLY upgrade the kernel by downloading and upgrading the kernel, from kernal.org site. 3) @Aaron, I didn't get what you wanted to convey by saying "bisect". Please do let me know if any other logs are needed. Thanks & Regards Kumar
bisect means git bisect, it would require building some kernels to verify which git commit breaks your system. See this: http://git-scm.com/docs/git-bisect
IMO, in order to report Linux kernel upstream bugs, you need to download and upgrade the kernels from kernel.org. You should clone the following git repository: # git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git And apply your current distribution's kernel .config to it to build the kernel to boot. For bisect, you may use "git tag" output to select the initial "good"/"bad" kernels. Thanks and best regards -Lv
Mark as regression since v3.16 works while v4.0 doesn't.
Hi Aron/Lv, I had downloaded the lated kernel from kernel.org, compiled it, installed it and booted the machine with kernel 4.1.1, but the behavior was same. Attached is the journal logs. Please do let me know if you need any more help. Thanks & Regards Kumar Abhishek
Created attachment 182361 [details] 4.1.1 Journal July 10 2015 Journal logs after booting the test machine with kernel 4.1.1. The machine is still not able to comletely shutdown/reboot.
Hi Aron/Lv, How can I compare the linux kernel 3.16 from Ubuntu with the kernel 4.1.1 from kernel.org? Will be sharing the git bisect result of linux kernel(v3.16-v4.1.1) from kernel.org, by tomorrow morning. Thanks & Regards Kumar Abhishek
git bisect will take some time so no hurry. You will need to find out which kernel version starts to break, instead of bisecting between v3.16 and v4.1, that would be too much commits in between. You need clone Linus' git tree first: $ git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Suppose you find out v3.17 starts to break, then in the cloned tree, you can start bisect by: $ git bisect start $ git bisect bad v3.17 $ git bisect good v3.16 Then it will checking out the commit in the middle of v3.16..v3.17 and you need build kernel and test; according to the result, you need mark that commit as either good or bad: $ git bisect bad/good Then it will checking out a new commit and the steps repeat till the offending commit is found.
okies.. It seems to be challenging, but its nice to learn it. One more thing, is Ubuntu Linux Kernel 3.16 different from mainline 3.16 ? How can I compare the linux kernel 3.16 from Ubuntu with the kernel 4.1.1 from kernel.org? thanks a lot Aaron. Regards Kumar Abhishek
Please use the cloned git tree to build kernel and test, no need to use Ubuntu's v3.16 kernel. So I think you can build v3.16 from the cloned tree first and see if it works, and then v3.17, ... till you find two adjacent kernels that one work while the other doesn't and start the bisect between the two. We can probably avoid bisect if we have some clue what the cause might be, but we have no idea at the moment.
No Problem Aaron. 1) Will try building each kernel from v3.16 and test it on the test machine. Test machine is an ACER machine, and I guess , its power management is broken. 2) Will try the "git-bisect" in parallel on another machine. Thanks & Regards Kumar Abhishek
Can you please check all major kernel releases between 3.16 and 4.1 and identify the first one that doesn't work as expected?
Hi Rafael I had checked the following major Kernel released on the kernel.org site : 1) 3.14.47 2) 3.18.17 3) 4.0.8 4) 4.1.1 Reboot/Shutdown worked for the following :- 1) 3.14.47 2) 3.18.17 3) 4.0.8 Observed the issue on 4.1.1 for the first time. Although the issue was initially observed in Fedora kernel 4.0.5-300.fc22.x86_64. Thanks & Regards Kumar Abhishek
Hi Kumar, Please test kernels like v3.16, v3.17, etc., not v3.16.1, v3.17.2, etc. If you have the git cloned tree, you can get the specified kernel release tree and build kernels like this: $ cd src/cloned-linux-tree $ git reset --hard v3.16 build and test $ git reset --hard v3.17 build and test $ git reset --hard v3.18 build and test ... Thanks.
In particular, I'd like to know whether or not it works with plain 4.0.0. If not, it would be good to check v3.19, v3.18 etc until you find a working one.
Hi Rafael I'm extremely sorry for the delay. My apologies. Below are the results : v3.18 : ====== Reboot : Working. Shutdown : Working. v3.19 : ====== Reboot : Not Working. Shutdown : Not Working. Stuck at "Powering off". v4.0.0 : ======= Screen FLICKERING at boot time. Reboot : Not Working. Shutdown : Not Working. Stuck at "Powering off". v4.1.0 : ======= Reboot : Not Working. Shutdown : Not Working. Stuck at "Powering off". Will share the v3.17 result shortly. Thanks & Regards Kumar Abhishek
Hi v3.17 : ====== Reboot : Working. Shutdown : Working. Thanks & Regards Kumar Abhishek
So it looks like the regression comes from v3.19, possible to bisect?
Hi Aron Which all versions do I need to bisect? Regards Kumar Abhishek
(In reply to Aaron Lu from comment #25) > So it looks like the regression comes from v3.19, possible to bisect? Hi Aaron Which all versions do I need to bisect? Regards Kumar Abhishek
(In reply to Kumar from comment #27) > Which all versions do I need to bisect? start bisect between v3.18(the last working version) and v3.19(the first bad version) by: $ git bisect start $ git bisect bad v3.19 $ git bisect good v3.18 ... ...
Hi Aaron/Rafael Following is the output of git bisect : [root@localhost linux-stable]# git bisect bad v3.19 [root@localhost linux-stable]# git bisect good v3.18 Bisecting: 6825 revisions left to test after this (roughly 13 steps) [54850e73e86e3bc092680d1bdb84eb322f982ab1] zram: change parameter from vaild_io_request() [root@localhost linux-stable]# Thanks & Regards Kumar Abhishek
(In reply to Kumar from comment #29) > Hi Aaron/Rafael > > Following is the output of git bisect : > > [root@localhost linux-stable]# git bisect bad v3.19 > > [root@localhost linux-stable]# git bisect good v3.18 > Bisecting: 6825 revisions left to test after this (roughly 13 steps) > [54850e73e86e3bc092680d1bdb84eb322f982ab1] zram: change parameter from > vaild_io_request() > > [root@localhost linux-stable]# You will now need to build the kernel and test if this commit is good or bad, and then mark it with: $ git bisect good(bad) Then git will re-checkout a commit for you to build and test again and again till you find the first bad commit.
Hi Following are the commits between v3.18 & v3.19: ################################################################# [root@localhost linux-stable]# git bisect good 54850e73e86e3bc092680d1bdb84eb322f982ab1 Bisecting: 2787 revisions left to test after this (roughly 12 steps) [dab363f938a53ddaee60bfecc1aebdbb3d3af5f0] Merge tag 'staging-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging [root@localhost linux-stable]# git bisect good dab363f938a53ddaee60bfecc1aebdbb3d3af5f0 => Reboot/Shutdown Not Working Bisecting: 1394 revisions left to test after this (roughly 11 steps) [5e6c2c97c56eb1b656e27fdcfaa3722828a9eca5] Merge tag 'mmc-v3.19-2' of git://git.linaro.org/people/ulf.hansson/mmc [root@localhost linux-stable]# git bisect good 5e6c2c97c56eb1b656e27fdcfaa3722828a9eca5 Bisecting: 687 revisions left to test after this (roughly 10 steps) [d0ac5d8e673aa7317c0d132ba3092935dac53298] Merge tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc [root@localhost linux-stable]# git bisect good d0ac5d8e673aa7317c0d132ba3092935dac53298 Bisecting: 332 revisions left to test after this (roughly 9 steps) [59343cd7c4809cf7598789e1cd14563780ae4239] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net [root@localhost linux-stable]# git bisect good 59343cd7c4809cf7598789e1cd14563780ae4239 Bisecting: 164 revisions left to test after this (roughly 7 steps) [f3c2352df1347ffc6f9265476ca475ea70b81656] Merge tag 'pci-v3.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci [root@localhost linux-stable]# git bisect good f3c2352df1347ffc6f9265476ca475ea70b81656 Bisecting: 82 revisions left to test after this (roughly 6 steps) [9d82f5eb3376cbae96ad36a063a9390de1694546] MMerge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net [root@localhost linux-stable]# git bisect good 9d82f5eb3376cbae96ad36a063a9390de1694546 Bisecting: 50 revisions left to test after this (roughly 5 steps) [48beb121f0600070184a4265bae77e7d8382f747] Merge branch 'akpm' (patches from Andrew Morton) [root@localhost linux-stable]# git bisect good 48beb121f0600070184a4265bae77e7d8382f747 Bisecting: 25 revisions left to test after this (roughly 5 steps) [2af613d3739b04b16fbd3c2b824b9ebaace89328] Merge tag 'sound-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound [root@localhost linux-stable]# git bisect good 2af613d3739b04b16fbd3c2b824b9ebaace89328 Bisecting: 11 revisions left to test after this (roughly 4 steps) [26cdd1f76a889a21faa851bcb260782db2c7f0a9] Merge branches 'timers-urgent-for-linus' and 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/ kernel/git/tip/tip [root@localhost linux-stable]# git bisect good 26cdd1f76a889a21faa851bcb260782db2c7f0a9 Bisecting: 4 revisions left to test after this (roughly 3 steps) [4e02370f64167a30ff7ba35ae5bc296f09b964d3] Merge tag 'trace-fixes-v3.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace [root@localhost linux-stable]# git bisect good 4e02370f64167a30ff7ba35ae5bc296f09b964d3 Bisecting: 2 revisions left to test after this (roughly 1 step) [cdecbb336e64b8a846bf97c5a275dc94fdb1083d] Merge git://git.kvack.org/~bcrl/aio-fixes [root@localhost linux-stable]# git bisect good cdecbb336e64b8a846bf97c5a275dc94fdb1083d Bisecting: 0 revisions left to test after this (roughly 1 step) [da2d96d3aa181c367ac4fcb9c11ee5eb15697cdd] Merge tag 'nios2-fixes-v3.19-final' of git://git.rocketboards.org/linux-socfpga-next ############################################################### I had compiled and installed the Kernel in the following manner : This is the second commit after v3.18. git reset --hard dab363f938a53ddaee60bfecc1aebdbb3d3af5f0 make menuconfig make -j 4 ; make modules_install install Then I booted the newly compiled and installed kernel. The machine booted and I was able to log in successfully. Reboot & Shutdown is NOT working. Thanks & Regards Kumar Abhishek
Discard the last comment. The actual culprit is the commit ID : 54850e73e86e3bc092680d1bdb84eb322f982ab1 ############################################################### I had compiled and installed the Kernel in the following manner : This is the first commit after v3.18. git reset --hard 54850e73e86e3bc092680d1bdb84eb322f982ab1 make menuconfig make -j 4 ; make modules_install install Then I booted the newly compiled and installed kernel. The machine booted and I was able to log in successfully. Reboot & Shutdown is NOT working. Thanks & Regards Kumar Abhishek
What about commit b627cff3d308d3ccb3ec73a89260f5c7872e46a4, the one that is immediately before the said culprit commit, does it work?
That commit comes after the commit, I have mentioned in my last comment. Regards Kumar On Mon Sep 14 07:43:52 2015 GMT+0530, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=100221 > > --- Comment #33 from Aaron Lu <aaron.lu@intel.com> --- > What about commit b627cff3d308d3ccb3ec73a89260f5c7872e46a4, the one that is > immediately before the said culprit commit, does it work? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
54850e73e86e3bc092680d1bdb84eb322f982ab1 doesn't seem to be a functional change... Thanks and best regards -Lv
Can you please check the commit ID that you had highlighted...? What should I do now..? Is there any way, we can chat in order to get the issue resolved faster..? On Mon Sep 14 08:53:39 2015 GMT+0530, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=100221 > > --- Comment #35 from Lv Zheng <lv.zheng@intel.com> --- > 54850e73e86e3bc092680d1bdb84eb322f982ab1 doesn't seem to be a functional > change... > > Thanks and best regards > -Lv > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
Maybe you can: $ git bisect start $ git bisect bad 54850e73e $ git bisect good v3.18 And try again. Thanks and best regards -Lv
Okies. Suppose I get a commit ID abc, then should I be doing the following : git reset --hard abc make menuconfig make -j 4 ; make modules_install install Please do correct me , if I'm wrong. Thanks & Regards Kumar Abhishek
(In reply to Kumar from comment #34) > That commit comes after the commit, I have mentioned in my last comment. Which git tree are you using? It doesn't seem we are talking about the same git tree, I'm using Linus' git tree, you should too.
(In reply to Aaron Lu from comment #39) > (In reply to Kumar from comment #34) > > That commit comes after the commit, I have mentioned in my last comment. > > Which git tree are you using? It doesn't seem we are talking about the same > git tree, I'm using Linus' git tree, you should too. yup, I'm using Linus' git tree too.
(In reply to Kumar from comment #40) > (In reply to Aaron Lu from comment #39) > > (In reply to Kumar from comment #34) > > > That commit comes after the commit, I have mentioned in my last comment. > > > > Which git tree are you using? It doesn't seem we are talking about the same > > git tree, I'm using Linus' git tree, you should too. > > yup, I'm using Linus' git tree too. Hi Are you checking the commit ID "dab363f938a53ddaee60bfecc1aebdbb3d3af5f0".. ? Regards Kumar
(In reply to Kumar from comment #41) > Hi > > Are you checking the commit ID "dab363f938a53ddaee60bfecc1aebdbb3d3af5f0".. ? No I didn't do that, I thought you meant the commit 54850e73e86e " zram: change parameter from vaild_io_request()" is the culprit commit so I asked you to test the commit immediately before it too, which is commit b627cff3d308 "zram: remove bio parameter from zram_bvec_rw()". BTW, do you use zram at all?
I'm not sure about it.
(In reply to Aaron Lu from comment #42) > (In reply to Kumar from comment #41) > > Hi > > > > Are you checking the commit ID "dab363f938a53ddaee60bfecc1aebdbb3d3af5f0".. > ? > > No I didn't do that, I thought you meant the commit 54850e73e86e " > zram: change parameter from vaild_io_request()" is the culprit commit so I > asked you to test the commit immediately before it too, which is commit > b627cff3d308 "zram: remove bio parameter from zram_bvec_rw()". > > BTW, do you use zram at all? Just 1 more question : 1) How can I check all the commite between v3.18 & v3.19 ? 2) Suppose I get a commit ID abc, then should I be doing the following : git reset --hard abc make menuconfig make -j 4 ; make modules_install install Please do correct me , if I'm wrong. Thanks & Regards Kumar Abhishek
(In reply to Kumar from comment #44) > Just 1 more question : > > 1) How can I check all the commite between v3.18 & v3.19 ? Use git bisect, it's designed for this purpose. > > 2) Suppose I get a commit ID abc, then should I be doing the following : If you get the commit ID abc by using git bisect, then -> > > git reset --hard abc <- no, you shouldn't reset here, you just build the kernel, no need to change kernel config either, just build and according to test result, tell git bisect the result with "git bisect good" or "git bisect bad". > make menuconfig > make -j 4 ; make modules_install install > > Please do correct me , if I'm wrong. Like I said above, if you are in the process of bisecting, no need to do "git reset", the bisect will automatically check out the code according to a specified commit abc. If you are just testing out a specified commit without using bisect, then yes, you can do the steps as you have written. But since there are a huge lot of commits between v3.18 and v3.19, you really shouldn't test commit one by one, instead, please use bisect. > > Thanks & Regards > Kumar Abhishek
(In reply to Aaron Lu from comment #45) > (In reply to Kumar from comment #44) > > Just 1 more question : > > > > 1) How can I check all the commite between v3.18 & v3.19 ? > > Use git bisect, it's designed for this purpose. > > > > > 2) Suppose I get a commit ID abc, then should I be doing the following : > > If you get the commit ID abc by using git bisect, then -> > > > > > git reset --hard abc > > <- > no, you shouldn't reset here, you just build the kernel, no need to change > kernel config either, just build and according to test result, tell git > bisect the result with "git bisect good" or "git bisect bad". > > > make menuconfig > > make -j 4 ; make modules_install install > > > > Please do correct me , if I'm wrong. > > Like I said above, if you are in the process of bisecting, no need to do > "git reset", the bisect will automatically check out the code according to a > specified commit abc. > > If you are just testing out a specified commit without using bisect, then > yes, you can do the steps as you have written. But since there are a huge > lot of commits between v3.18 and v3.19, you really shouldn't test commit one > by one, instead, please use bisect. > > > > > Thanks & Regards > > Kumar Abhishek That was really nice and helpful of you. Thanks a lot. Will share the results within a day or 2. Regards Kumar Abhishek
hi, Kumar, is there any update?
(In reply to Zhang Rui from comment #47) > hi, Kumar, > is there any update? Hi I had performed the below mentioned steps : ########################################## [root@localhost linux-git]# git bisect start [root@localhost linux-git]# git bisect bad v3.19 [root@localhost linux-git]# git bisect good v3.18 Bisecting: 6825 revisions left to test after this (roughly 13 steps) [54850e73e86e3bc092680d1bdb84eb322f982ab1] zram: change parameter from vaild_io_request() [root@localhost linux-git]# ########################################## After this, I compiled the kernel using : make -j 4 ; make modules_install install ########################################## After this, I had booted the recently compiled and installed, linux kernel. This issue is observed across the models of ACER laptops. Regards Kumar Abhishek
Then you need to tell git that the commit "[54850e73e86e3bc092680d1bdb84eb322f982ab1] zram: change parameter from vaild_io_request()" is bad by: $ git bisect bad And then git will checkout a new commit for you to test.
ping...
Hi I'm really sorry for the delay. Currently 6 iterations are left. The status is in progress. On Mon Nov 9 08:47:16 2015 GMT+0530, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=100221 > > --- Comment #50 from Zhang Rui <rui.zhang@intel.com> --- > ping... > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
(In reply to Kumar from comment #51) > Hi > I'm really sorry for the delay. > Currently 6 iterations are left. > The status is in progress. > > On Mon Nov 9 08:47:16 2015 GMT+0530, bugzilla-daemon@bugzilla.kernel.org > wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=100221 > > > > --- Comment #50 from Zhang Rui <rui.zhang@intel.com> --- > > ping... > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > You reported the bug. > > Hi I had tested till : [root@localhost linux]# git bisect bad b5cd43f062717b6c92f93bc0c593764e144ea331 Bisecting: 45 revisions left to test after this (roughly 6 steps) [86817ffb492b509b87b20be4a4f1afc74f04dccf] mmc: block: Use mmc_get_ext_csd() instead of mmc_send_ext_csd() [root@localhost linux]# The above merge was also buggy, as I had compiled, installed the kernel and tested reboot/shutdown. Then I followed along : [root@localhost linux]# git bisect start [root@localhost linux]# git bisect good v3.18 [root@localhost linux]# git bisect bad 86817ffb492b509b87b20be4a4f1afc74f04dccf ==> Previous merge. The output is as follows : Bisecting: a merge base must be tested [206c5f60a3d902bc4b56dab2de3e88de5eb06108] Linux 3.18-rc4 Now it does not say "xx revisions left to test after this (roughly y steps)" What should I do now? Should I continue?
I Had continued the compilation and installation and following errors were observed : cp: cannot stat ‘sound/soundcore.ko’: No such file or directory Can't read module INSTALL sound/synth/emux/snd-emux-synth.ko cp: cannot stat ‘sound/synth/emux/snd-emux-synth.ko’: No such file or directory Can't read module INSTALL sound/synth/snd-util-mem.ko cp: cannot stat ‘sound/synth/snd-util-mem.ko’: No such file or directory Can't read module Can't read module INSTALL sound/usb/6fire/snd-usb-6fire.ko INSTALL sound/usb/caiaq/snd-usb-caiaq.ko cp: cannot stat ‘sound/usb/6fire/snd-usb-6fire.ko’: No such file or directory cp: cannot stat ‘sound/usb/caiaq/snd-usb-caiaq.ko’: No such file or directory Can't read module INSTALL sound/usb/hiface/snd-usb-hiface.ko cp: cannot stat ‘sound/usb/hiface/snd-usb-hiface.ko’: No such file or directory Can't read module INSTALL sound/usb/misc/snd-ua101.ko cp: cannot stat ‘sound/usb/misc/snd-ua101.ko’: No such file or directory Can't read module Can't read module INSTALL sound/usb/snd-usb-audio.ko INSTALL sound/usb/snd-usbmidi-lib.ko cp: cannot stat ‘sound/usb/snd-usb-audio.ko’: No such file or directory cp: cannot stat ‘sound/usb/snd-usbmidi-lib.ko’: No such file or directory Can't read module INSTALL sound/usb/usx2y/snd-usb-us122l.ko cp: cannot stat ‘sound/usb/usx2y/snd-usb-us122l.ko’: No such file or directory Can't read module INSTALL sound/usb/usx2y/snd-usb-usx2y.ko cp: cannot stat ‘sound/usb/usx2y/snd-usb-usx2y.ko’: No such file or directory Can't read module Can't read module Can't read module Can't read module [root@localhost linux]# Kindly guide me through, as I have no idea, how to proceed. regards Kumar Abhishek
(In reply to Kumar from comment #52) > Hi > > I had tested till : > > [root@localhost linux]# git bisect bad > b5cd43f062717b6c92f93bc0c593764e144ea331 > Bisecting: 45 revisions left to test after this (roughly 6 steps) > [86817ffb492b509b87b20be4a4f1afc74f04dccf] mmc: block: Use mmc_get_ext_csd() > instead of mmc_send_ext_csd() > [root@localhost linux]# > > The above merge was also buggy, as I had compiled, installed the kernel and > tested reboot/shutdown. > > Then I followed along : > > [root@localhost linux]# git bisect start > [root@localhost linux]# git bisect good v3.18 > [root@localhost linux]# git bisect bad > 86817ffb492b509b87b20be4a4f1afc74f04dccf ==> Previous merge. > > The output is as follows : > Bisecting: a merge base must be tested > [206c5f60a3d902bc4b56dab2de3e88de5eb06108] Linux 3.18-rc4 > Now it does not say "xx revisions left to test after this (roughly y steps)" > > > What should I do now? > > Should I continue? According to: https://wiki.ubuntu.com/Kernel/KernelBisection#Bisecting:_a_merge_base_must_be_tested You need to tell git if commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108, which is v3.18-rc4 is good or bad. I think you can do that by testing it.
Created attachment 192921 [details] Kernel-test-fit-bisect
Hi Below are my observations : I had compiled and tested till =============================== [root@localhost linux]# git bisect bad 86817ffb492b509b87b20be4a4f1afc74f04dccf Bisecting: 22 revisions left to test after this (roughly 5 steps) [eaaceb6cbf7ef6f480b3f80468beb21eafe82ac0] mmc: msm_sdcc: Use platform_set|get_drvdata [root@localhost linux]# =============================== The above merge also was bad. So I had followed as below : [root@localhost linux]# git bisect start Checking out files: 100% (658/658), done. Previous HEAD position was eaaceb6... mmc: msm_sdcc: Use platform_set|get_drvdata Switched to branch 'master' Your branch is behind 'origin/master' by 77823 commits, and can be fast-forwarded. (use "git pull" to update your local branch) [root@localhost linux]# git bisect good v3.18 [root@localhost linux]# git bisect bad eaaceb6cbf7ef6f480b3f80468beb21eafe82ac0 Bisecting: a merge base must be tested [206c5f60a3d902bc4b56dab2de3e88de5eb06108] Linux 3.18-rc4 [root@localhost linux]# git bisect bad 206c5f60a3d902bc4b56dab2de3e88de5eb06108 The merge base 206c5f60a3d902bc4b56dab2de3e88de5eb06108 is bad. This means the bug has been fixed between 206c5f60a3d902bc4b56dab2de3e88de5eb06108 and [b2776bf7149bddd1f4161f14f79520f17fc1d71d]. [root@localhost linux]# =========================== Regards Kumar Abhishek
Ping...
The "git bisect start" should be used only once during a bisect cycle.
(In reply to Aaron Lu from comment #58) > The "git bisect start" should be used only once during a bisect cycle. What I do is as follows : 1) git bisect start 2) git bisect good abc 3) git bisect bad xxx 4) make menuconfig => save the file. 5) make -j 4 ; make modules_install install 6) reboot/shutdown 7) start from step 1 again. Am I on the right path?
7) start from step 2 or 3 depending on the test result, i.e. if poweroff works after shutdown/reboot, start from 2: 2) git bisect good or if poweroff doesn't work, start from 3: 3) git bisect bad
################################################# [root@localhost linux]# git bisect bad 0031a98a85e9fca282624bfc887f9531b2768396 0031a98a85e9fca282624bfc887f9531b2768396 is the first bad commit commit 0031a98a85e9fca282624bfc887f9531b2768396 Author: Baruch Siach <baruch@tkos.co.il> Date: Mon Sep 22 10:12:51 2014 +0300 mmc: block: add newline to sysfs display of force_ro Make force_ro consistent with other sysfs entries. Fixes: 371a689f64b0d ('mmc: MMC boot partitions support') Cc: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> :040000 040000 7db31a98adb527e1cf5f87bb6143232429f473f8 74332bda32b4780f71eba91ff51735730e08e82a M drivers [root@localhost linux]# ################################################
(In reply to Aaron Lu from comment #60) > 7) start from step 2 or 3 depending on the test result, i.e. if poweroff > works after shutdown/reboot, start from 2: > 2) git bisect good > or if poweroff doesn't work, start from 3: > 3) git bisect bad ################################################# [root@localhost linux]# git bisect bad 0031a98a85e9fca282624bfc887f9531b2768396 0031a98a85e9fca282624bfc887f9531b2768396 is the first bad commit commit 0031a98a85e9fca282624bfc887f9531b2768396 Author: Baruch Siach <baruch@tkos.co.il> Date: Mon Sep 22 10:12:51 2014 +0300 mmc: block: add newline to sysfs display of force_ro Make force_ro consistent with other sysfs entries. Fixes: 371a689f64b0d ('mmc: MMC boot partitions support') Cc: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> :040000 040000 7db31a98adb527e1cf5f87bb6143232429f473f8 74332bda32b4780f71eba91ff51735730e08e82a M drivers [root@localhost linux]# ################################################
Well, this still doesn't seem to be the culprit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0031a98 It only adds "\n" output to an sysfs attribute file. Thanks -Lv
ok, will check it again and update as soon as possible. Thanks Kumar
For all practical purposes we need to treat that as a problem that has always been there (unless you can do a reliable bisect), so clearing the regression flag for this one.
ping Kumar...
Bug closed as there is no response from the bug reporter. Please feel free to reopen it if you can provide the information requested.