I now believe radeon_cp.c is not the problem. In fact, the radeon DRM driver appears to be completely innocent. I'd appreciate any help or suggestions where to look next.
Less short: Using alternate versions of radeon_cp.c and the entire radeon driver directory to compile the radeon.ko kernel module, I was still able to trigger the bug on Debian. Verbose: I've been compiling kernel modules to see if I can interpolate the point where the bug is triggered. I had been suspecting drivers/gpu/drm/radeon/radeon_cp.c since that seemed to be the most obvious change between the working and non-working drivers. I now am 85% sure that radeon_cp.c is not the problem.¹ I copied Ubuntu's radeon_cp.c file (and the associated firmware .h) to an otherwise pure Debian/testing box. When I compiled and installed that kernel module the bug still occurred; that is, my filesystem was corrupted. Next I tried copying the entire driver/gpu/drm/radeon directory from Ubuntu and compiled that kernel module under Debian. I was surprised to find that the bug still manifested using that kernel module as well. I also attempted to force Ubuntu's precompiled radeon.ko to load but didn't go any further than the error: Unknown symbol pv_lock_ops. Summary: Debian/stable (2.6.26): DRI works perfectly. Ubuntu/karmic (2.6.31): DRI works perfectly Debian/testing (2.6.32): DRI destroys file system Debian/testing using karmic's radeon driver: DRI destroys file system --Ben __ ¹ The 15% uncertainty is because I have only tested this a few times. Occasionally the filesystem would become so corrupted it had to be completely wiped and reinstalled, which makes for slow debugging. On Tue, Jan 12, 2010 at 8:29 AM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Tue, 2010-01-12 at 04:30 -0800, Ben Wong wrote: >> I have organized this bug report so that the most important information >> is at the top so that you can stop reading as soon as you get bored. >> >> This bug, #550562, should be reclassified as a critical bug and possibly >> merged with #560126. > > I think you're right. > >> This bug causes severe filesystem corruption and catastrophic loss of >> data by scribbling on the hard drives. It is completely reproducible. >> It seems to only affect systems that use the radeon/R200_cp.bin >> firmware when it is separated from the kernel. (Could it be that the >> binary blob didn't get copied correctly when it was split?) > > I've compared them again - they're identical to the blobs previously > embedded in the driver (except for byteswapping). > > When you say it 'only affect systems that use the radeon/R200_cp.bin > firmware' do you mean that you tested systems with other Radeon GPU > versions and they were not affected, or that this problem appeared after > the firmware was separated out (Debian package version 2.6.29-1)? > > Ben. > > -- > Ben Hutchings > The generation of random numbers is too important to be left to chance. > - Robert Coveyou > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
