laptop lockup using silicon motion driver

Rhys Ickeringill ickers at
Wed Apr 9 02:33:29 PDT 2008

Back again!

I've had a concerted effort to diagnose the source of the this problem and have now identified the line of code which causes the system lockup. Again I have attached various logs and summaries of my findings to Bug#1975 for future reference, including a gdb backtrace to the line just prior to the line which triggers the system lockup.

In a nutshell:

System lockup occurs at line 1666 of smi_driver.c in function SMI_WriteMode() calling macro
WRITE_CPR, itself defined as a wrapper around macro MMIO_OUT32.

     WRITE_CPR(pSmi, 0x00, restore->CPR00);

WRITE_CPR essentially attempts to write null to pSmi->CPRBase, the value of which gdb reports to be:

(gdb) print pSmi->CPRBase
$2 = (CARD8 *) 0xb7a76000 <Address 0xb7a76000 out of bounds>

And this is where I come to a screeching halt. I suspect from the "address out of bounds message" reported by gdb that the CARD8* base address of the CPR registers is bad. This in turn is simply defined as a constant offset from the base of mapped memory returned by xf86MapPciMem( ). But as this is my first attempt at debugging X11 code (and using gdb for that matter), I've absoltely no idea what I'm talking about and am probably completely wrong :)

On a possibly related matter - I cannot compile the siliconmotion driver to use libpciaccess [which would set the mapped memory base via pci_device_map_range( ) instead of xf86MapPciMem( )]. I get the following:

gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/xorg -I/usr/include/pixman-1 -DXSERVER_LIBPCIACCESS -DSMI_DEBUG -g3 -ggdb3 -MT smi_accel.lo -MD -MP -MF .deps/smi_accel.Tpo -c smi_accel.c  -fPIC -DPIC -o .libs/smi_accel.o
In file included from /usr/include/xorg/xf86.h:45,
                  from smi.h:38,
                  from smi_accel.c:34:
/usr/include/xorg/xf86str.h:454: error: conflicting types for 'pciVideoPtr'
smi_pcirename.h:82: error: previous declaration of 'pciVideoPtr' was here

Any suggestions on what to do/try next to resolve this nasty bug will be greatly appreciated.



More information about the xorg mailing list