https://bugzilla.kernel.org/show_bug.cgi?id=42725
--- Comment #43 from Alex Shi <alex....@intel.com> 2012-06-28 02:22:12 --- (In reply to comment #42) > Updated log just in case it helps: > https://dl.dropbox.com/u/2231399/log.tar.gz > > It's been a very busy weekend at work also my ISP fucked up royally and left > every customer in the province without a working phone line for the entirety > of > Monday. Ops! > I haven't had much to report on either, I have continued as usual, narrowed > down to 3035 possible patches according to bisect, still a lot and the process > seems to get slower, the amount of skips gets demoralizing. > > I would love to narrow it down using your method but I haven't actually tried > it yet. Mostly because I feel like I don't understand it. First, how do I know > the last good and last (first?) bad? Are they just the last two patches listed > in the log file? (could you check the file in case I mess up?) Sorry for a bit later response, since too many affairs to deal with. Narrow by the following command is very useful if you know where is the problem or there is too many reboot issues in all source bisection. $git bisect start last_bad_commit_number last_good drivers/cpufreq/ drivers/acpi/ You just need to restart bisect like above, and then anything is same as full source bisection. > > If I understand this correctly, what I need to do is restart the bisect > process, then start again by telling it to only look for changes between the > last good and last bad and only in drivers/cpufreq and drivers/acpi? Sure > > I understand from your message that the bug might not be there and I should > try > to narrow it to x86, I don't know whether this is a valid concern, but the bug > is also present in amd64 (or x86_64 or whatever is the current politically > correct way to refer to it nowadays, actually, my testing system is 64bit). If so, add 'arch/x86 kernel' at the tail of above command. > > I am also very worried about the amount of panics and compilation errors being > somehow produced by me doing something wrong, could you for instance test > compile the last skip to check if it's only me? I don't worry much of skipped commits if they are in unrelated drivers. or even some of them in generic part. :) > > I'll keep with the usual method in the mean time. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are watching the assignee of the bug. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
