Bug#550562: Blob firmware loader corrupts filesystem
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.
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?)
BEHAVIOR
Every time I run an OpenGL program, such as Xscreensaver's
gleidescope, the filesystem gets immediately hosed. The easiest way
to see the problem is to use 'df' or 'ls'. For example,
asome# df -h # This is correct.
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 687G 651G 893M 100% /
asome# df -h # This is after using OpenGL.
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 16T 16T 36G 100% /
Here are some examples of the errors the kernel spits out when
attempting to use 'ls' and 'cat' on files after using OpenGL.
asome# dmesg | tail
[ 428.751448] EXT3-fs error (device hda1): ext3_readdir: bad entry
in directory #21987919: inode out of bounds - offset=0,
inode=21987919, rec_len=12, name_len=1
[ 428.759385] EXT3-fs error (device hda1): ext3_find_entry: bad
entry in directory #37939357: inode out of bounds - offset=24,
inode=36692009, rec_len=20, name_len=10
[ 431.346902] EXT3-fs error (device hda1): ext3_readdir: bad entry
in directory #22503425: rec_len is smaller than minimal - offset=0,
inode=1, rec_len=0, name_len=0
While this bug causes many strange behaviors to accumulate, the
abnormal 16 terabyte report from df always happens immediately upon
using OpenGL and happens every single time. This makes me believe
there is some horrible interaction going on with the filesystem
drivers.
By the way, whenever I hit the Big Red Switch before the changes could
be written to disk, my system seemed unharmed. However, once as a
test I let the screensaver keep running for a while and this bug
destroyed the entire file system (not even bootable). Thank goodness
it was my scratch disk.
ABOUT MY COMPUTER
This computer had been working fine with accelerated OpenGL graphics
for a long time. When the binary blobs were split from the kernel, I
installed the firmware-linux package and immediately had problems.
As a test, I booted off of a LiveCD (Mint 7.0 Gloria) and OpenGL
worked perfectly again, without filesystem corruption. I believe this
is because the kernel on that disk, 2.6.28-11-ubuntu, has the binary
blobs built in instead of using the newer firmware loader. With that
kernel I was able to run without error the exact same libraries and
binaries (using chroot) that had triggered problems before.
Hardware: The computer has an ATI Radeon 9200 (RV280), which uses the
R200_cp.bin firmware.
Software: I'm running testing (squeeze). All packages are up-to-date
as of today (January 12, 2010).
asome$ uname -a
Linux 2.6.30-2-686 #1 SMP Fri Dec 4 00:53 UTC 2009 i686 GNU/Linux
asome$ dpkg -l xserver-xorg firmware-linux linux-image-2.6-686
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/T
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-====================================
ii firmware-linux 0.18 Binary firmware for various drivers
ii xserver-xorg 1:7.4+4 the X.Org X server
ii linux-image-2. 2.6.30+21 Linux 2.6 image on PPro/Celeron/PII/
NOT THE PROBLEM
I have done extensive testing and ruled out many things as "not the
problem". Here's a list, so that other people don't have to bother
checking these.
DMA/IRQ conflicts? Not the problem.
hdparm -d 0 /dev/hda? Not the problem.
Bad hard drive or controller card? Not the problem.
Bad cables? Not the problem.
Bad RAM? Not the problem.
Screen resolution? Not the problem.
XAA vs EXA acceleration? Not the problem.
ColorTiling? Not the problem.
AGP data xfer rate? Not the problem.
AGP aperture size? Not the problem.
CPU speed? Not the problem.
WILLING TO HELP
I have quick access to the computer with the Radeon 9200 card. Please
let me know if there's any way I can help get this catastrophic bug
repaired.
GARRULOUS HARDWARE INFO
$ hwinfo --gfxcard
19: PCI 100.0: 0300 VGA compatible controller (VGA)
[Created at pci.318]
UDI: /org/freedesktop/Hal/devices/pci_1002_5961
Unique ID: VCu0.mgsxy8+aW73
Parent ID: vSkL.X0yl1qhFqsB
SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
SysFS BusID: 0000:01:00.0
Hardware Class: graphics card
Model: "ATI RV280 5961"
Vendor: pci 0x1002 "ATI Technologies Inc"
Device: pci 0x5961 "RV280 5961"
SubVendor: pci 0x1002 "ATI Technologies Inc"
SubDevice: pci 0x2002
Revision: 0x01
Memory Range: 0xf0000000-0xf7ffffff (rw,prefetchable)
I/O Ports: 0xec00-0xecff (rw)
Memory Range: 0xff8f0000-0xff8fffff (rw,non-prefetchable)
Memory Range: 0xff800000-0xff81ffff (ro,prefetchable,disabled)
IRQ: 16 (550 events)
I/O Ports: 0x3c0-0x3df (rw)
Module Alias: "pci:v00001002d00005961sv00001002sd00002002bc03sc00i00"
Driver Info #0:
XFree86 v4 Server Module: radeon
Driver Info #1:
XFree86 v4 Server Module: radeon
3D Support: yes
Extensions: dri
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #9 (PCI bridge)
20: PCI 100.1: 0380 Display controller
[Created at pci.318]
UDI: /org/freedesktop/Hal/devices/pci_1002_5941
Unique ID: NXNs.n3gH641yH71
Parent ID: vSkL.X0yl1qhFqsB
SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.1
SysFS BusID: 0000:01:00.1
Hardware Class: graphics card
Model: "ATI RV280 [Radeon 9200] (Secondary)"
Vendor: pci 0x1002 "ATI Technologies Inc"
Device: pci 0x5941 "RV280 [Radeon 9200] (Secondary)"
SubVendor: pci 0x1002 "ATI Technologies Inc"
SubDevice: pci 0x2003
Revision: 0x01
Memory Range: 0xe8000000-0xefffffff (rw,prefetchable)
Memory Range: 0xff8e0000-0xff8effff (rw,non-prefetchable)
Module Alias: "pci:v00001002d00005941sv00001002sd00002003bc03sc80i00"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #9 (PCI bridge)
Primary display adapter: #19
Reply to: