Re: Linux 3.2.38

[tmhikaru]

	This is becoming irritating. Clearly bisect isn't capable of
figuring out the bad commit for me, so I'm going to have to walk the commits
myself. *sigh* (The commit it thinks is the one that's causing the problem
for me yet again is very obviously barking up the wrong tree)

git bisect start
# good: [2d18772602ba45629dfd4ffe1878ecb26fb3d3ed] Linux 3.2.37
git bisect good 2d18772602ba45629dfd4ffe1878ecb26fb3d3ed
# bad: [8eedd52017a07a5bae2aded2b5023bfba5971af9] Linux 3.2.38
git bisect bad 8eedd52017a07a5bae2aded2b5023bfba5971af9
# good: [157bb66c87286abc3dad2ed19a8cfb130ef24573] USB: option: add TP-LINK HSUPA Modem MA180
git bisect good 157bb66c87286abc3dad2ed19a8cfb130ef24573
# good: [6fad7bfb8aef9a8688d3d3b3ea917b3c7d1fc8b7] can: ti_hecc: fix invalid error codes
git bisect good 6fad7bfb8aef9a8688d3d3b3ea917b3c7d1fc8b7
# good: [8bdb5d1a2d352d58ac99be529bb8c006dfb9be83] sd: Reshuffle init_sd to avoid crash
git bisect good 8bdb5d1a2d352d58ac99be529bb8c006dfb9be83
# bad: [8a6d0db2f6a06c5fdfb7a208002d0f9961d1ad41] intel-iommu: Prevent devices with RMRRs from being placed into SI Domain
git bisect bad 8a6d0db2f6a06c5fdfb7a208002d0f9961d1ad41
# good: [756a6d71c4f566f840cf4e04fe2540e6927d2613] x86: Use enum instead of literals for trap values
git bisect good 756a6d71c4f566f840cf4e04fe2540e6927d2613
# bad: [c2db6e1fa351227e9849b2504075db6f9f748874] Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"
git bisect bad c2db6e1fa351227e9849b2504075db6f9f748874
# bad: [d36179913a4c811f1e1b508011f1f6b9f48c3729] staging: comedi: Kconfig: COMEDI_NI_AT_A2150 should select COMEDI_FC
git bisect bad d36179913a4c811f1e1b508011f1f6b9f48c3729

	I tested and then retested my rebuild of 3.2.37 and had no problems.
My stock distro kernel of 3.2.29 also has no problems.  As you can see from
this bisect log and the other one I performed previously, a good portion of
the commits in 3.2.38 tend to have no problems, but some of them do for me. 
Irregularly.

	I've noted that the behavior has thankfully been showing up in
console as well as Xorg since before I stopped testing the *last* set of
bisects, so to speed up testing a tad I'm going to stop testing if the cpu
is pegged in Xorg now, and only check console.

Hmm. I suppose on a lark I could try combining the results of the two
bisects for the 'bad' entries and leave out the 'good' ones and see if that
gets me somewhere different. I mean, at this point I know which commits
*don't* work right... The trick is figuring out which ones *do*

Tim McGrath

Attachment: pgp00000.pgp
Description: PGP signature