Hi, 7 days, 28 minutes, 11 seconds ago, Ludovic Courtès wrote: > > Hm, this file loads fine for me: > > > > (II) Loading /usr/lib/xorg/modules/libxaa.so > > (II) Module xaa: vendor="X.Org Foundation" > > compiled for 7.0.0, module version = 1.2.0 > > ABI class: X.Org Video Driver, version 0.8 > > > > sha1sum of this file is: > > > > 7bfc397c6d7f0a174f46aede663c5338aacf6472 /usr/lib/xorg/modules/libxaa.so > > Same file here, but it still doesn't load -- but I no longer get this > message. ;-)
I should note that the above remark applied to 2.6.15, probably _before_ running X. With 2.6.16-1 (from sid), I can observe the following funny thing: # file /usr/lib/xorg/modules/libxaa.so /usr/lib/xorg/modules/libxaa.so: Sun disk label 'ST39111A cyl 17660 alt 2 hd 16 sec 63' 14285 phys cys, 51 alts/cyl, 0 blocks, boot block present With 2.6.15, it's now `libramdac.so' that gets broken: # file /usr/lib/xorg/modules/libramdac.so /usr/lib/xorg/modules/libramdac.so: sparc executable This randomness may explain why we do not experience the same problems. Anyway, I ran `apt-get install --reinstall xserver-xorg-core' to see what would happen. `debsums' then reported that _this_ package was no longer corrupt. Re-running X right after that made the system hang after the following (famous) message: error opening security policy file /etc/X11/xserver/SecurityPolicy I tried various configurations with `hdparm' on the hard disk in question and that doesn't seem to make any significant difference. Although I haven't been able to reproducibly demonstrate it, apparent file corruption seems to occur after running X (i.e., when X fails without crashing the whole system). Conclusion: the kernel might be the guilty party, but X is still suspicious as well. ;-) Have people been running X-free (no pun here) workloads, like builds, with recent kernels on sparc64? Do they trigger any such problem? Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]