Does reverting the commit help? If not, could you please bisect?

(In reply to comment #1)
> Does reverting the commit help? If not, could you please bisect?

Sorry, I've just spent the last hour trying to perform a git bisect, and got nothing except broken builds and core dumps for my troubles. So "no", you're going to have to debug the old-fashioned way instead.

(In reply to comment #2)
> (In reply to comment #1)
> > Does reverting the commit help? If not, could you please bisect?
> 
> Sorry, I've just spent the last hour trying to perform a git bisect, and got
> nothing except broken builds and core dumps for my troubles. So "no", you're
> going to have to debug the old-fashioned way instead.

To avoid segfaults (caused by incomplete rebuilds), did you have makedepend installed ?
( http://www.x.org/releases/individual/util/makedepend-1.0.2.tar.bz2 )
Otherwise you need to make clean before each rebuild. You can speed that a lot using ccache.

http://www.mail-archive.com/nouveau@lists.freedesktop.org/msg04939.html has more information.

To avoid build errors, did you have an up-to-date configure ?
$ autoreconf -iv && ./config.status --recheck && ./config.status

Read http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12767.html for more explanation.

(In reply to comment #3)
> Read http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12767.html
> for more explanation.

Yada yada yada!

The big problem with "git bisect" is that (despite what some people seem to think), it is NOT a tool which you can ask an inexperienced person to turn a handle blindly and have an answer pop out of a slot. There is no guarantee whatsoever that an intermediate build will either compile or work. In fact, it is becoming increasingly clear that I have no friggin' clue how "git bisect" is actually working because I have tried to bisect again this morning! Between now and last night, someone has checked something in that has FIXED this problem. So lets see:

This is the most recent commit in my local tree:

commit f618867645b3ce2570958bfacc1faf8c88e7a620
Author: Brian Paul <brianp@vmware.com>
Date:   Fri Apr 2 22:38:18 2010 -0600

    mesa: display list support for GL_EXT_transform_feedback

$ git bisect start
$ git bisect good

And the last commit I remember seeing last night (when it was still broken) was this one:

commit f6c7b911653fb1508256c63518ef0bd15d68186e
Author: Dave Airlie <airlied@redhat.com>
Date:   Sat Apr 3 07:00:03 2010 +1000

    r300g: make dithering work like fglrx.
    
    From fglrx traces the dithering is never enabled.

So lets declare that one as "bad":

$ git bisect bad f6c7b911653fb1508256c63518ef0bd15d68186e
Some good revs are not ancestor of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistake good and bad revs?

?????? WTF ??????? How can a commit that I already had last night be more recent (in the sense of when I added it into my local tree - which is the only measure that matters) than one I only picked up a few minutes ago this morning?

So **NO**, I am not going to use "git friggin' bisect" for you!

You need to run

git bisect reset

before starting a new bisect run, otherwise the previous bisect data is still used and can lead to inconsistent results.

(In reply to comment #5)
> You need to run
> 
> git bisect reset

Like this, you mean?

$ git bisect reset
Already on 'master'
$ git bisect start
$ git bisect good
$ git bisect bad f6c7b911653fb1508256c63518ef0bd15d68186e
Some good revs are not ancestor of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistake good and bad revs?

Been there, done that.

If this issue has been fixed, there is nothing more to see.
Why do you want to bisect something that works ?

If you are really curious and want to find what commit fixed it (instead of what commit broke it, which is the common case), you could reverse the meaning of good and bad with git bisect :
good when it is broken
bad when it works

(In reply to comment #7)
> Why do you want to bisect something that works ?

a) To find the commit that fixed the bug. (Which is precisely what I was describing in comment 4), and
b) To point out that "git bisect" is not the "magic" tool that some developers seem to think that it is. ESPECIALLY since there were only 10 possible commits that could have fixed my problem, and "git bisect" still proved to be esoteric and unhelpful!

Created attachment 34683 [details]
Screenshot of corrupt Earth textures in celestia (plus kernel WARNING)

And the corruption is back again. I took this screenshot using The Gimp, and in the process triggered this kernel warning:

------------[ cut here ]------------
WARNING: at /home/chris/LINUX/linux-2.6.33/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2a/0xad()
Hardware name: Precision WorkStation 650    
empty IPI mask
Modules linked in: fuse nfsd exportfs uvcvideo videodev v4l1_compat snd_usb_audio snd_usb_lib autofs4 nfs lockd auth_rpcgss sunrpc p4_clockmod speedstep_lib af_packet ipt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_LOG nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 binfmt_misc dm_mirror dm_region_hash dm_log dm_mod uinput snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm joydev firewire_ohci floppy usbhid snd_seq_device i2c_i801 ppdev firewire_core pcspkr snd_timer parport_pc sg parport snd_page_alloc snd_util_mem psmouse snd_hwdep serio_raw snd dcdbas crc_itu_t soundcore ext3 jbd mbcache sr_mod cdrom sd_mod pata_acpi ata_piix sata_sil uhci_hcd libata ehci_hcd scsi_mod usbcore e1000 thermal button radeon intel_agp ttm drm_kms_helper drm agpgart i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect [last unloaded: processor]
Pid: 4634, comm: celestia Not tainted 2.6.33.2 #1
Call Trace:
 [<c102559b>] ? warn_slowpath_common+0x5d/0x70
 [<c10171d2>] ? __cpa_flush_range+0x0/0x24
 [<c10255e1>] ? warn_slowpath_fmt+0x26/0x2a
 [<c101274c>] ? default_send_IPI_mask_logical+0x2a/0xad
 [<c10171d2>] ? __cpa_flush_range+0x0/0x24
 [<c1011381>] ? native_send_call_func_ipi+0x4f/0x56
 [<c1043aa0>] ? smp_call_function_many+0x161/0x17a
 [<c10171d2>] ? __cpa_flush_range+0x0/0x24
 [<c1043ae2>] ? smp_call_function+0x29/0x4f
 [<c10171d2>] ? __cpa_flush_range+0x0/0x24
 [<c10297f9>] ? on_each_cpu+0x23/0x50
 [<c1017abe>] ? change_page_attr_set_clr+0x24a/0x2c6
 [<c11da880>] ? _raw_spin_unlock+0xb/0x1f
 [<c1017d44>] ? _set_memory_wc+0x21/0x48
 [<c1017fc4>] ? set_memory_wc+0x61/0x84
 [<f80bac8f>] ? ttm_tt_set_caching+0xb7/0x1a5 [ttm]
 [<f80bb61d>] ? ttm_bo_add_ttm+0x4b/0xb0 [ttm]
 [<f80bbccf>] ? ttm_bo_handle_move_mem+0xd4/0x243 [ttm]
 [<f80bd22b>] ? ttm_bo_move_buffer+0x9b/0xe3 [ttm]
 [<f80bd30f>] ? ttm_bo_validate+0x9c/0xe2 [ttm]
 [<f80bd5e3>] ? ttm_bo_init+0x28e/0x2bc [ttm]
 [<f81a0f49>] ? radeon_bo_create+0xb9/0x142 [radeon]
 [<f81a0fd2>] ? radeon_ttm_bo_destroy+0x0/0x4a [radeon]
 [<f81ad3b7>] ? radeon_gem_object_create+0x64/0xcb [radeon]
 [<f81ad469>] ? radeon_gem_create_ioctl+0x4b/0xcf [radeon]
 [<f8073223>] ? drm_ioctl+0x1f7/0x281 [drm]
 [<f81ad41e>] ? radeon_gem_create_ioctl+0x0/0xcf [radeon]
 [<c11da881>] ? _raw_spin_unlock+0xc/0x1f
 [<f80be520>] ? ttm_bo_vm_fault+0x1f3/0x1fd [ttm]
 [<c102997e>] ? irq_exit+0x38/0x63
 [<f819fba5>] ? radeon_ttm_fault+0x14/0x19 [radeon]
 [<c106fe65>] ? __do_fault+0x40/0x365
 [<c10e663f>] ? prio_tree_insert+0xe9/0x1ce
 [<c10e66a6>] ? prio_tree_insert+0x150/0x1ce
 [<f807302c>] ? drm_ioctl+0x0/0x281 [drm]
 [<c109215d>] ? vfs_ioctl+0x1c/0x7d
 [<c10926c1>] ? do_vfs_ioctl+0x45e/0x4a2
 [<c116a2f7>] ? acpi_pm_read+0xb/0x15
 [<c103bd07>] ? getnstimeofday+0x4e/0xd2
 [<c1092732>] ? sys_ioctl+0x2d/0x46
 [<c100270c>] ? sysenter_do_call+0x12/0x22
---[ end trace 7c5ac0a8dc2bf27c ]---

Earth textures are now completely missing in all rendering paths. Earth has become Hoth.

I think this bug can be closed now, as the corrupt textures have finally disappeared and not come back. In fact, the Earth is now being rendered correctly (? I think) even with the OpenGL 2.0 path.