* help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes @ 2010-08-31 19:53 Martin Steigerwald 2010-08-31 22:39 ` Ken Moffat 2010-09-01 18:47 ` Paolo Ornati 0 siblings, 2 replies; 15+ messages in thread From: Martin Steigerwald @ 2010-08-31 19:53 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1397 bytes --] Hi! I am seeking help with encircling the cause of: [Bug 16376] random - possibly Radeon DRM KMS related - freezes https://bugzilla.kernel.org/show_bug.cgi?id=16376 I started a bisection as described in which has been painful for me - at least for a first time bisection -, but after the second skip of a non- booting kernel git points me to a kernel that is outside of the initial range between good and back. good is: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33 bad is: bad: [64ba9926759792cf7b95f823402e2781edd1b5d4] Merge branch 'for- linus' of git://git.open-osd.org/linux-open-osd After skipping the last non booting kernel, git bisect put me to 5be796f0b842c5852d7397a82f8ebd6be8451872 which is just 300 lines after 2.6.33-rc2. Obviously I am not interested in kernels prior 2.6.33. Should I just do a "git bisect good" without trying the kernel or is there some other remedy? its 11 cycles already without testing anything outside the initial good/bad range and it takes about half a day to be somewhat sure that a kernel is good, so I'd like to avoid testing versions outside this range. My bug comment #35 contains a log of the bisection[1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c35 Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-08-31 19:53 help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes Martin Steigerwald @ 2010-08-31 22:39 ` Ken Moffat 2010-09-01 16:10 ` Martin Steigerwald 2010-09-01 18:47 ` Paolo Ornati 1 sibling, 1 reply; 15+ messages in thread From: Ken Moffat @ 2010-08-31 22:39 UTC (permalink / raw) To: Martin Steigerwald; +Cc: linux-kernel On Tue, Aug 31, 2010 at 09:53:43PM +0200, Martin Steigerwald wrote: > > Hi! > > I am seeking help with encircling the cause of: > > [Bug 16376] random - possibly Radeon DRM KMS related - freezes > https://bugzilla.kernel.org/show_bug.cgi?id=16376 > > I started a bisection as described in which has been painful for me - at > least for a first time bisection -, but after the second skip of a non- > booting kernel git points me to a kernel that is outside of the initial > range between good and back. > > good is: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33 > > bad is: bad: [64ba9926759792cf7b95f823402e2781edd1b5d4] Merge branch 'for- > linus' of git://git.open-osd.org/linux-open-osd > > After skipping the last non booting kernel, git bisect put me to > 5be796f0b842c5852d7397a82f8ebd6be8451872 which is just 300 lines after > 2.6.33-rc2. > > Obviously I am not interested in kernels prior 2.6.33. Should I just do a > "git bisect good" without trying the kernel or is there some other remedy? > its 11 cycles already without testing anything outside the initial > good/bad range and it takes about half a day to be somewhat sure that a > kernel is good, so I'd like to avoid testing versions outside this range. While you are bisecting, don't believe the version in Makefile. I got similarly freaked out a couple of years ago - if I understood correctly, it's something to do with when a change was created. The key point is that during bisection the apparent version *can* go back to a version that appears to be before the initial "good" kernel. ken -- das eine Mal als Tragödie, das andere Mal als Farce ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-08-31 22:39 ` Ken Moffat @ 2010-09-01 16:10 ` Martin Steigerwald 2010-09-01 18:13 ` Ken Moffat 0 siblings, 1 reply; 15+ messages in thread From: Martin Steigerwald @ 2010-09-01 16:10 UTC (permalink / raw) To: Ken Moffat; +Cc: linux-kernel [-- Attachment #1: Type: Text/Plain, Size: 2054 bytes --] Am Mittwoch 01 September 2010 schrieb Ken Moffat: > On Tue, Aug 31, 2010 at 09:53:43PM +0200, Martin Steigerwald wrote: > > Hi! > > > > I am seeking help with encircling the cause of: > > > > [Bug 16376] random - possibly Radeon DRM KMS related - freezes > > https://bugzilla.kernel.org/show_bug.cgi?id=16376 > > > > I started a bisection as described in which has been painful for me - > > at least for a first time bisection -, but after the second skip of > > a non- booting kernel git points me to a kernel that is outside of > > the initial range between good and back. > > > > good is: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33 > > > > bad is: bad: [64ba9926759792cf7b95f823402e2781edd1b5d4] Merge branch > > 'for- linus' of git://git.open-osd.org/linux-open-osd > > > > After skipping the last non booting kernel, git bisect put me to > > 5be796f0b842c5852d7397a82f8ebd6be8451872 which is just 300 lines > > after 2.6.33-rc2. > > > > Obviously I am not interested in kernels prior 2.6.33. Should I just > > do a "git bisect good" without trying the kernel or is there some > > other remedy? its 11 cycles already without testing anything outside > > the initial good/bad range and it takes about half a day to be > > somewhat sure that a kernel is good, so I'd like to avoid testing > > versions outside this range. > > While you are bisecting, don't believe the version in Makefile. I > got similarly freaked out a couple of years ago - if I understood > correctly, it's something to do with when a change was created. > > The key point is that during bisection the apparent version *can* > go back to a version that appears to be before the initial "good" > kernel. I verified the version by running git log after doing the skip. And it was just 300 lines after Linus commited 2.6.33-rc2. Can git log be showing incorrect results during a bisect? Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-01 16:10 ` Martin Steigerwald @ 2010-09-01 18:13 ` Ken Moffat 0 siblings, 0 replies; 15+ messages in thread From: Ken Moffat @ 2010-09-01 18:13 UTC (permalink / raw) To: Martin Steigerwald; +Cc: linux-kernel On Wed, Sep 01, 2010 at 06:10:24PM +0200, Martin Steigerwald wrote: > Am Mittwoch 01 September 2010 schrieb Ken Moffat: > > > > While you are bisecting, don't believe the version in Makefile. I > > got similarly freaked out a couple of years ago - if I understood > > correctly, it's something to do with when a change was created. > > > > The key point is that during bisection the apparent version *can* > > go back to a version that appears to be before the initial "good" > > kernel. > > I verified the version by running git log after doing the skip. And it was > just 300 lines after Linus commited 2.6.33-rc2. Can git log be showing > incorrect results during a bisect? > > Thanks, I suggest you go with the versions that git bisect selects. I appreciate that it takes you a long time to build and test each kernel, but hopefully you can reach a stage where the bad commit is identified. I think I've seen people report that an old commit was identified as causing a problem, and I also think that in those cases the problem was exposed by a later commit. ken -- das eine Mal als Tragödie, das andere Mal als Farce ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-08-31 19:53 help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes Martin Steigerwald 2010-08-31 22:39 ` Ken Moffat @ 2010-09-01 18:47 ` Paolo Ornati 2010-09-01 19:26 ` Martin Steigerwald 2010-09-05 7:53 ` Martin Steigerwald 1 sibling, 2 replies; 15+ messages in thread From: Paolo Ornati @ 2010-09-01 18:47 UTC (permalink / raw) To: Martin Steigerwald; +Cc: linux-kernel On Tue, 31 Aug 2010 21:53:43 +0200 Martin Steigerwald <Martin@lichtvoll.de> wrote: > Obviously I am not interested in kernels prior 2.6.33. Should I just do a > "git bisect good" without trying the kernel or is there some other remedy? No. Git is right in asking you to test that commit: you are ignoring branches and merges. Example ======== Linus Tree Usb Tree v2.6.33-rc2 | \ | | commit A (version is v2.6.33-rc2) | | commit B ( " ) v2.6.33 | commit C ( " ) | __/ | __/ | __/ |_/ X <--- MERGE So the commit you are testing it's like "commit A": it was done before (in time) v2.6.33, on a kernel based on v2.6.33-rc2, but was merged in Linus' tree _after_ v2.3.33. So this this behaviour is normal :) -- Paolo Ornati Linux 2.6.35.4 on x86_64 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-01 18:47 ` Paolo Ornati @ 2010-09-01 19:26 ` Martin Steigerwald 2010-09-05 7:53 ` Martin Steigerwald 1 sibling, 0 replies; 15+ messages in thread From: Martin Steigerwald @ 2010-09-01 19:26 UTC (permalink / raw) To: Paolo Ornati; +Cc: linux-kernel [-- Attachment #1: Type: Text/Plain, Size: 870 bytes --] Am Mittwoch 01 September 2010 schrieb Paolo Ornati: > On Tue, 31 Aug 2010 21:53:43 +0200 > > Martin Steigerwald <Martin@lichtvoll.de> wrote: > > Obviously I am not interested in kernels prior 2.6.33. Should I just > > do a "git bisect good" without trying the kernel or is there some > > other remedy? > > No. Git is right in asking you to test that commit: you are ignoring > branches and merges. > > Example [...] > So the commit you are testing it's like "commit A": it was done before > (in time) v2.6.33, on a kernel based on v2.6.33-rc2, but was merged in > Linus' tree _after_ v2.3.33. > > So this this behaviour is normal :) Thanks. That explains it. So I compile this kernel and continue bisecting as usual. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-01 18:47 ` Paolo Ornati 2010-09-01 19:26 ` Martin Steigerwald @ 2010-09-05 7:53 ` Martin Steigerwald 2010-09-05 12:20 ` Paolo Ornati 2010-09-07 2:51 ` Ted Ts'o 1 sibling, 2 replies; 15+ messages in thread From: Martin Steigerwald @ 2010-09-05 7:53 UTC (permalink / raw) To: linux-kernel; +Cc: Paolo Ornati, Ted Ts'o [-- Attachment #1: Type: Text/Plain, Size: 2850 bytes --] Am Mittwoch 01 September 2010 schrieb Paolo Ornati: > On Tue, 31 Aug 2010 21:53:43 +0200 > > Martin Steigerwald <Martin@lichtvoll.de> wrote: > > Obviously I am not interested in kernels prior 2.6.33. Should I just > > do a "git bisect good" without trying the kernel or is there some > > other remedy? > > No. Git is right in asking you to test that commit: you are ignoring > branches and merges. [...] > So this this behaviour is normal :) So as to the advice of Ted in the thread "stable? quality assurance?" I am seeking some more help with bisecting this bug. I continued bisecting and stumbled upon some problems: Quite some kernels were unbootable with an ext4 and readahead related backtrace[1]. These were all within an USB merge and after skipping about five unbootable kernels I skipped the whole range of commits in it. I wondered by git insisted taking me back to this range of commits, even in the middle of two skips, instead of automatically re-adjusting the binary search, so that range would not be hit again for a while. Cause then its would have not been hit at all eventually. Anyway, I think this problem got fixed prior to 2.6.34 so I am asking whether there is a patch, a commit that fixed it in case I should stumble about such a unbootable kernel again. I attached the backtrace screenshot to my bug comment[1]. Ted, I am not booting from USB, but from the internal harddrive. I think these backtraces are completely unrelated to that USB commits. I think the bug has been introduced before that USB merge and fixed somewhen afterwards, but from a quick glance I didn't find the commit that fixes it. I am also seeking help with selecting more suitable commits to test: If its a Radeon KMS related freeze and everything points at it, I think the offending commit is in the first quarter of what git commit shows to me[2]. Thus I'd like to select one commit before those drm/kms related commits and one after it, before testing any other commits. But I have been fooled by those branches and merges before and there is the range of skipped commits in that USB merge, thus I'd like advice on which commits to select. A current git bisect log I attached to [2]. I will continue bisecting as usual for the time being, but I really appreciate some help, cause its still above 1800 commits to test otherwise and I am quite annoyed by seeing the same roughly 11 steps even if the absolute number of commits got down by about somewhat: Bisecting: 1861 revisions left to test after this (roughly 11 steps) [1] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c37 [2] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c38 Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-05 7:53 ` Martin Steigerwald @ 2010-09-05 12:20 ` Paolo Ornati 2010-09-05 13:25 ` Martin Steigerwald 2010-09-07 2:51 ` Ted Ts'o 1 sibling, 1 reply; 15+ messages in thread From: Paolo Ornati @ 2010-09-05 12:20 UTC (permalink / raw) To: Martin Steigerwald; +Cc: linux-kernel, Ted Ts'o On Sun, 5 Sep 2010 09:53:41 +0200 Martin Steigerwald <Martin@lichtvoll.de> wrote: > I am also seeking help with selecting more suitable commits to test: If > its a Radeon KMS related freeze and everything points at it, I think the > offending commit is in the first quarter of what git commit shows to me[2]. > Thus I'd like to select one commit before those drm/kms related commits > and one after it, before testing any other commits. If you "know better" than git-bisect and want to test a particular commit, just do: git reset --hard commit_id -- Paolo Ornati Linux 2.6.35.4 on x86_64 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-05 12:20 ` Paolo Ornati @ 2010-09-05 13:25 ` Martin Steigerwald 0 siblings, 0 replies; 15+ messages in thread From: Martin Steigerwald @ 2010-09-05 13:25 UTC (permalink / raw) To: Paolo Ornati; +Cc: linux-kernel, Ted Ts'o [-- Attachment #1: Type: Text/Plain, Size: 1734 bytes --] Am Sonntag 05 September 2010 schrieb Paolo Ornati: > On Sun, 5 Sep 2010 09:53:41 +0200 > > Martin Steigerwald <Martin@lichtvoll.de> wrote: > > I am also seeking help with selecting more suitable commits to test: > > If its a Radeon KMS related freeze and everything points at it, I > > think the offending commit is in the first quarter of what git > > commit shows to me[2]. Thus I'd like to select one commit before > > those drm/kms related commits and one after it, before testing any > > other commits. > > If you "know better" than git-bisect and want to test a particular > commit, just do: > > git reset --hard commit_id That part I understood from the manpage. But I seeked help to choose exactly which commit. Well I now go with martin@shambhala:~/Computer/Shambhala/Kernel/2.6.33-2.6.34- bisect/linux-2.6> git log | head commit a27341cd5fcb7cf2d2d4726e9f324009f7162c00 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Mar 2 08:36:46 2010 -0800 Prioritize synchronous signals over 'normal' signals This makes sure that we pick the synchronous signals caused by a processor fault over any pending regular asynchronous signals sent to use by [t]kill(). When I interpret the graphical display of gitk correctly this one should be directly before the whole lot of KMS/DRM/Radeon/Intel commits being merged. Now hopefully this one boots. And is good. Then I would have skipped a whole lot of the revisions to test. But even when it just boots, but is bad, I at least know that its not in these merges. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-05 7:53 ` Martin Steigerwald 2010-09-05 12:20 ` Paolo Ornati @ 2010-09-07 2:51 ` Ted Ts'o 2010-09-09 14:18 ` Martin Steigerwald 1 sibling, 1 reply; 15+ messages in thread From: Ted Ts'o @ 2010-09-07 2:51 UTC (permalink / raw) To: Martin Steigerwald; +Cc: linux-kernel, Paolo Ornati On Sun, Sep 05, 2010 at 09:53:41AM +0200, Martin Steigerwald wrote: > > Quite some kernels were unbootable with an ext4 and readahead related > backtrace[1]. Unfortunately, you don't have a full backtrace in the picture which submitted as an attachment to the bugzilla. It shows part of the backtrace which has an ext4 and readahead stack, yes. But we didn't get to see the beginning of the stack trace with the IP and the reason for the oops. If keyboard interrupts still work, you might try seing if you can scroll upwards and see more of the backtrace. Or you might try configuring your console to use a higher resolution display so more lines can be displayed. Or you might try getting a serial console. I don't recognize the display, but the problem could just as easily be in the block layer or in the device driver for your hard drive. (i.e., the readahead stack calls ext4, which in turn will submit a read request to the block device layer which then submits the request to a device driver). But because you keep referring it to it as an ext4/readahead related backtrace, you may have disguised the symptom enough that people who might recognize it as, "Oh, yeah, there was this regression in the SATA layer", wouldn't recognize it as such from your description. That's why it's important to be careful how you describe issues; if you had said, I don't have a complete stack trace, and I don't have the IP and function where the fault occurred, that might have caused people to think a bit harder about what might be the problem, instead of thinking to themselves, "ah, well, the ext4 and readahead parts of the kernel aren't my problem, so I'll ignore this report". > I am also seeking help with selecting more suitable commits to test: If > its a Radeon KMS related freeze and everything points at it, I think the > offending commit is in the first quarter of what git commit shows to me[2]. You do know that you can restrict a git bisect to commits that modify a particular part of the tree, right? e.g., git bisect start 2.6.34 2.6.33 -- drivers/gpu/drm/radeon - Ted ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-07 2:51 ` Ted Ts'o @ 2010-09-09 14:18 ` Martin Steigerwald 2010-09-10 11:55 ` Florian Mickler 0 siblings, 1 reply; 15+ messages in thread From: Martin Steigerwald @ 2010-09-09 14:18 UTC (permalink / raw) To: Ted Ts'o; +Cc: linux-kernel, Paolo Ornati [-- Attachment #1: Type: Text/Plain, Size: 4191 bytes --] Am Dienstag 07 September 2010 schrieb Ted Ts'o: > On Sun, Sep 05, 2010 at 09:53:41AM +0200, Martin Steigerwald wrote: > > Quite some kernels were unbootable with an ext4 and readahead related > > backtrace[1]. > > Unfortunately, you don't have a full backtrace in the picture which > submitted as an attachment to the bugzilla. It shows part of the > backtrace which has an ext4 and readahead stack, yes. But we didn't > get to see the beginning of the stack trace with the IP and the reason > for the oops. If keyboard interrupts still work, you might try seing > if you can scroll upwards and see more of the backtrace. Or you might > try configuring your console to use a higher resolution display so > more lines can be displayed. Or you might try getting a serial > console. Thanks for your detailled analysis. I missed posting an update to the thread. I did not have to go back to those kernels again and bisected the issue down to about 10 revisions, when Alex suggested my bug might be a duplicate of [Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34 https://bugs.freedesktop.org/show_bug.cgi?id=28402 So I tried some patches in there and the vmembase at zero patch seems to do the trick. Although I am not sure, whether its a solution or a work- around. > I don't recognize the display, but the problem could just as easily be > in the block layer or in the device driver for your hard drive. > (i.e., the readahead stack calls ext4, which in turn will submit a > read request to the block device layer which then submits the request > to a device driver). Yes, I am aware that it may not be a Ext4 problem at all. Thus I said Ext4 / readahead related (!) backtrace (! not bug) cause that was all I could see on the screen. How else should I have described that backtrace when I can't speculate on what I can not see? > But because you keep referring it to it as an ext4/readahead related > backtrace, you may have disguised the symptom enough that people who > might recognize it as, "Oh, yeah, there was this regression in the > SATA layer", wouldn't recognize it as such from your description. > That's why it's important to be careful how you describe issues; if > you had said, I don't have a complete stack trace, and I don't have > the IP and function where the fault occurred, that might have caused > people to think a bit harder about what might be the problem, instead > of thinking to themselves, "ah, well, the ext4 and readahead parts of > the kernel aren't my problem, so I'll ignore this report". I thought thats what the provided backtrace is for. And I think that any developer can see that it isn't complete. I will include a note that the backtrace is incomplete next time nevertheless. It would be good to have a backtrace viewer and saver that still works in those conditions ;-). And when it just writes it somewhere on the swap partition were a tool can grab it after booting again. But when the kernel is completely messed up, exactly that can be very dangerous. > > I am also seeking help with selecting more suitable commits to test: > > If its a Radeon KMS related freeze and everything points at it, I > > think the offending commit is in the first quarter of what git > > commit shows to me[2]. > > You do know that you can restrict a git bisect to commits that modify > a particular part of the tree, right? e.g., > > git bisect start 2.6.34 2.6.33 -- drivers/gpu/drm/radeon Yes, I have seen that in the git manpage, but since I wasn't absolutely sure, that the freeze is radeon kms/drm related I skipped that step. From what I learned I should have looked at git bisect visualize earlier and selected from commits prior and after that drm kms related merges. That would have spared me quite some time when my suspicion was right, like it turned out to be, and wouldn't have taken many more turn arounds when it was wrong. Next time I know this. Thanks for your help, I appreciate it. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-09 14:18 ` Martin Steigerwald @ 2010-09-10 11:55 ` Florian Mickler 2010-09-10 13:49 ` Martin Steigerwald 0 siblings, 1 reply; 15+ messages in thread From: Florian Mickler @ 2010-09-10 11:55 UTC (permalink / raw) To: Martin Steigerwald; +Cc: Ted Ts'o, linux-kernel, Paolo Ornati On Thu, 9 Sep 2010 16:18:49 +0200 Martin Steigerwald <Martin@lichtvoll.de> wrote: > Yes, I am aware that it may not be a Ext4 problem at all. Thus I said Ext4 > / readahead related (!) backtrace (! not bug) cause that was all I could > see on the screen. How else should I have described that backtrace when I > can't speculate on what I can not see? I think, it is no big thing. The trick is probably to say nothing at all about the cause, when it is not clear. It's a mind thing. As soon as the association is brought up, everybody thinks along those lines. :) If you leave out the "ext4/readahead related", then people will still know that it might be ext4 readahead related because you posted the backtrace, but they will not have their mind turned to that. Instead they will think: oh a backtrace... there were some people shouting about backtraces in my area, let's see if it is realted. But of course, sometimes putting blame somewhere also does help getting attention. After all "CORRUPTION IN FILESYSTEM XYZ" sticks out more than "partial trace of a thing i don't know anything at all". Cheers, Flo ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-10 11:55 ` Florian Mickler @ 2010-09-10 13:49 ` Martin Steigerwald 2010-09-10 15:53 ` Theodore Tso 0 siblings, 1 reply; 15+ messages in thread From: Martin Steigerwald @ 2010-09-10 13:49 UTC (permalink / raw) To: Florian Mickler; +Cc: Ted Ts'o, linux-kernel, Paolo Ornati [-- Attachment #1: Type: Text/Plain, Size: 1766 bytes --] Am Freitag 10 September 2010 schrieb Florian Mickler: > On Thu, 9 Sep 2010 16:18:49 +0200 > > Martin Steigerwald <Martin@lichtvoll.de> wrote: > > Yes, I am aware that it may not be a Ext4 problem at all. Thus I said > > Ext4 / readahead related (!) backtrace (! not bug) cause that was > > all I could see on the screen. How else should I have described that > > backtrace when I can't speculate on what I can not see? > > I think, it is no big thing. The trick is probably to say nothing at > all about the cause, when it is not clear. It's a mind thing. As soon > as the association is brought up, everybody thinks along those lines. > :) > > If you leave out the "ext4/readahead related", then people will still > know that it might be ext4 readahead related because you posted the > backtrace, but they will not have their mind turned to that. Instead > they will think: oh a backtrace... there were some people shouting > about backtraces in my area, let's see if it is realted. OTOH I thought when I put in some keywords from the backtrace in my query it might get the attention of the right people. When I just say unknown backtrace, then I am adressing no one. > But of course, sometimes putting blame somewhere also does help getting > attention. After all "CORRUPTION IN FILESYSTEM XYZ" sticks out more > than "partial trace of a thing i don't know anything at all". I wouldn't do that for sensational purposes. Maybe next time: "Fails to boot with partially shown backtrace, with some ext4 / readahead function calls inside it"? Or even more general some I/O / filesystem related functions? -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-10 13:49 ` Martin Steigerwald @ 2010-09-10 15:53 ` Theodore Tso 2010-09-10 16:18 ` Martin Steigerwald 0 siblings, 1 reply; 15+ messages in thread From: Theodore Tso @ 2010-09-10 15:53 UTC (permalink / raw) To: Martin Steigerwald; +Cc: Florian Mickler, linux-kernel, Paolo Ornati On Sep 10, 2010, at 9:49 AM, Martin Steigerwald wrote: > Maybe next time: "Fails to boot with partially shown backtrace, with some > ext4 / readahead function calls inside it"? Or even more general some I/O > / filesystem related functions? Learn how to use a serial console so you can get a full backtrace, thus saving yourself and folks interesting in helping you valuable time? :-) -- Ted ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes 2010-09-10 15:53 ` Theodore Tso @ 2010-09-10 16:18 ` Martin Steigerwald 0 siblings, 0 replies; 15+ messages in thread From: Martin Steigerwald @ 2010-09-10 16:18 UTC (permalink / raw) To: Theodore Tso; +Cc: Florian Mickler, linux-kernel, Paolo Ornati [-- Attachment #1: Type: Text/Plain, Size: 1517 bytes --] Am Freitag 10 September 2010 schrieb Theodore Tso: > On Sep 10, 2010, at 9:49 AM, Martin Steigerwald wrote: > > Maybe next time: "Fails to boot with partially shown backtrace, with > > some ext4 / readahead function calls inside it"? Or even more > > general some I/O / filesystem related functions? > Learn how to use a serial console so you can get a full backtrace, thus > saving yourself and folks interesting in helping you valuable time? > :-) I know how to use a serial console. Actually I am no freaking idiot at all and I do not like being treated as such. I just did a bisect, and these kernels were unbootable. I didn't think it would have been worth the effort to put that much time in it to grab my other notebook, remember how to set up the serial stuff and all - when all I wanted to do was to complete the bisect. I already told that I missed reporting that I do not need any information relating that issue anymore cause I was able to skip the area with that unbootable kernels at all. I am sorry for that, cause then you would have known in advance that there is no need to do any further analysis. Its getting a bit ridicolous now. I am done with it, since its no issue at all anymore. My current 2.6.36-rc3 definately boots, so does 2.6.34 and 2.6.35 and thus the issue is gone and all is well. So can we be done with that now? Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-09-10 16:18 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-08-31 19:53 help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes Martin Steigerwald 2010-08-31 22:39 ` Ken Moffat 2010-09-01 16:10 ` Martin Steigerwald 2010-09-01 18:13 ` Ken Moffat 2010-09-01 18:47 ` Paolo Ornati 2010-09-01 19:26 ` Martin Steigerwald 2010-09-05 7:53 ` Martin Steigerwald 2010-09-05 12:20 ` Paolo Ornati 2010-09-05 13:25 ` Martin Steigerwald 2010-09-07 2:51 ` Ted Ts'o 2010-09-09 14:18 ` Martin Steigerwald 2010-09-10 11:55 ` Florian Mickler 2010-09-10 13:49 ` Martin Steigerwald 2010-09-10 15:53 ` Theodore Tso 2010-09-10 16:18 ` Martin Steigerwald
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.