Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: Linux 2.6.25-rc4 | Date | Mon, 10 Mar 2008 15:04:17 +0100 |
| |
On Monday 10 March 2008, Rafael J. Wysocki wrote: > On Monday, 10 of March 2008, Bartlomiej Zolnierkiewicz wrote: > > On Monday 10 March 2008, Anders Eriksson wrote: > > > > > > aeriksson@fastmail.fm said: > > > > torvalds@linux-foundation.org said: > > > >> I think we do want the bisect run here. > > > >> My worry is that this is likely very timing-sensitive, so when it starts > > > >> failing it might not be because of the commit that actually introduces the > > > >> bug, but because some other timing changed, but with some luck that won't > > > >> be the case. > > > > > > > I'm on it. Slow machine. Household's router, 4000 versions to go... > > > > > > The bisect came up with this: > > > > > > 18a056feccabdfa9764016a615121b194828bc72 is first bad commit > > > commit 18a056feccabdfa9764016a615121b194828bc72 > > > > Hmm, this is the first commit _after_ the previous "guilty" > > commit 852738f39258deafb3d89c187cb1a4050820d555 so it just > > can't be the "real bad" one... > > Well, would that be practical to prepare a patch reverting this commit > and whatever depends on it so that Anders can verify it?
We've already verified that 8527 just makes the problem more likely to occur (the discussion is in the earlier "-rc3 regression" thread) so reverting 8527 or 18a0 won't really help.
Thanks, Bart
| |