[Pan-users] Re: The "no-break-space" problem, aka "blank" posts, that shouldn't be

[Duncan]

walt posted on Fri, 11 Dec 2009 14:29:08 -0800 as excerpted:

> Here's what I have:
> 
> $git branch
>    master
> * testing
> 
> $git checkout master
> Switched to branch 'master'
> 
> $git branch
> * master
>    testing
> 
> $git checkout testing
> Switched to branch 'testing'

OK, I think I know what's wrong.  The git eclass used by the script 
probably just pulls the one branch, master.  That'd be why git 
checkout<tab> didn't list testing as an auto-complete possibility, only 
tags.

Do you run git kernels also?  I am, and have been regularly doing git 
bisects for... several kernels now, when I see issues.  But you're right, 
it's still largely black magic here, too.  The last bug, in 2.6.32, I 
never /did/ find.  When I come back from hibernate, sometimes I lose a 
drive -- one or more of /dev/sd[abcd] (I have four) disappears and comes 
back as e or later.  That's troublesome indeed for kernel/md RAID!  The 
problem seems to be a corruption, possibly due to a race condition, of 
either the new disk ID string or the one retained over the suspend.  They 
don't compare equal (one is the disk model number, one may be mostly 
blanks with a couple weird characters, or most but not all of the model 
number), so the kernel assumes I switched hardware and kicks it out, 
bringing it back as if it's a new drive.  But sometimes it recovers 
before actually kicking it out (I get the mismatch in the log, but 
apparently it tries again and succeeds), and sometimes it doesn't happen 
at all.

The problem, however, is bisecting it, as if it goes bad (I get the model 
number mismatch in the log, regardless of whether it actually kicks the 
disk or not), I know it, but if it doesn't on any particular hibernate, I 
don't know if it's good or simply didn't trigger that time.

Complicating the issue, the trigger seems to be X related, as I don't 
recall ever seeing it if I wasn't running X in the background (I do 
switch to a text console to hibernate, tho).  And I just upgraded my 
radeon card to a radeon hd4650, running git xf86-video-ati (no stable 
with 3D support yet to run), and critical support for it was added to 
2.6.32 as well.  I was /hoping/ the hardware change from the old card 
(radeon 9200 or 9250, never remember) would kill the bug, as it didn't 
trigger for awhile, but that was after I upgraded hardware but before I 
upgraded X driver so was still running in 2D only mode.  I've only done 
one hibernate since I got the new driver running, but the bug is back!

So now I gotta go back and report that on the bug again (I was planning 
on closing it NEEDMOREINFO or some such since I hadn't seen it after I'd 
upgraded hardware), and see if there's any possible way they can create 
some logging code I could run.  Unlike a lot of hibernate bugs, I /do/ 
return from hibernate, so in theory some sort of logging code might 
help.  Because I've tried bisecting the stupid thing three times now, 
spending more than two whole days on it, and between a stupid mistake on 
my part on the first run, apparent false negatives on the second, and 
never really completing the third as I was going much slower and upgraded 
hardware, then didn't see it for awhile, the thing just will /not/ bisect!

I /did/ try to test revert the outcome of the second run, even tho it was 
in a staging driver and I wasn't running anything staging at all, but git 
failed the revert with some error about too many files (even tho the 
commit touched only three, I guess it was too far beyond that or 
something), that was WAYYY beyond my git level to decipher, let alone fix.

OTOH, several other bugs over the last several kernels were fixed due to 
my reporting, bisecting, etc. That's a nice feeling, especially for a non-
C coder!  =:^)  Git bisect is great, when it works!

Anyway, looks like I gotta change a couple parameters in the ebuild, fed 
to the git eclass, to get it to fetch that testing branch.  I did create 
nice little scripts that let me know what changed since the last time I 
did my various git pulls (the gentoo x11 and kde overlays are git based, 
there's pan, now the xf86-video-ati driver, and the kernel, tho I manage 
the kernel with my own set of scripts, independent of gentoo's kernel 
packages).  I do understand git well enough to do that manually, I think, 
and the eclass is documented reasonably well, so it shouldn't be a big 
deal, just a matter of getting to it...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman