troubles with nautilus on x86_64

[Marshall Lewis]

I didn't notice this thread before.. I've had this problem (on two
x86_64 machines) and could not get it to clear until I did a clean
re-install of Fedora... at least that fixed it on one machine. On the
other machine downgrading to the shipped fc2t3 kernel fixed it, but then
a later upgrade worked without trouble.  Personally I think nautilus is
being overly sensitive to system changes.  I realize that isn't very
helpful, but I never could determine a real cause, or get it to fail
again once it was "fixed".

Oh also, I first experienced this problem running an early rawhide
version of FC2.

--
 Marshall

On Wed, 2004-05-05 at 15:03, Karen Spearel wrote:
> csm at moongroup.com wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > So it's now the middle of the week and there has been no activity on the 
> > bug report I made about nautilus. It's important (to me at least) that 
> > people realize that this is a BLOCKER bug because gnome is not usable 
> > with this bug in place. You only get about half the environment and as 
> > wwe are approaching the freeze point it would seem that *THIS* kind of 
> > bug would be quite interesting.
> > 
> > On Sun, 2 May 2004, Chuck Mead spewed into the bitstream:
> > 
> > CM>Chuck Mead wrote:
> > CM>> Chuck Mead wrote:
> > CM>> 
> > CM>>> So night before last I installed FC2T3 on an Athlon64 3000+ with a k8v 
> > CM>>> deluxe motherboard. Gnome has been a problem as nautilus dies when it 
> > CM>>> tries to start. I have a bug report (see attached) for that which is 
> > CM>>> going into bugzilla shortly. 
> > CM>
> > CM>This has been submitted as bug 122298
> > CM>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122298
> > CM>
> > CM>
> > 
> > - --
> > csm at moongroup.com, head geek
> > http://moongroup.com
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.1 (GNU/Linux)
> > 
> > iD8DBQFAmTNyv6Gjsf2pQ0oRAhu0AJ9HozmaQ3oVsZvS1uJTBPMaLbtQhACfbTRD
> > aUtCeNkq54q4Zqo25QQi1/Q=
> > =ZDJQ
> > -----END PGP SIGNATURE-----
> > 
> > 
> 
> Chuck,
> 
> Hope you don't mind getting a message off list...I know you aren't a 
> noob and this suggestion will make it seem like I think you are.
> 
> With my K8V using standard Samsung DIMMs from the Asus approved list, I 
> cannot make my system run reliably at 200 mhz FSB...this system just 
> does ***not*** like high latency memory.  I spent over 100 hrs trying 
> various memory timings and never found anything that wouldn't throw an 
> error at least once within 8 hrs.  Eventually I gave up and switched to 
> 166 mhz FSB.  The errors were always above 1000 mb...and primarily 
> triggered by Test 6.
> 
> At the very least Memtest86+ V3.00 gives a little interesting data on 
> what Asus BIOS uses for default settings.  Running Test 6 for an 
> extended period might possibly be interesting.  The very bottom timing 
> setting (cmd delay or something like that) was the only thing that 
> helped but that didn't correct the problem entirely.  BTW, these same 
> DIMMs run fine on my Athlon XP system running a 200 mhz FSB...not 
> exactly the same thing but at least I know the DIMMs are with spec.
> 
> At 166, this K8V/3200+ is dead reliable...at 200 it simply isn't. 
> Perhaps you are running faster memory...but I have seen reports of 
> problems running fast DIMMs with Winbond dram also.  I gain a little of 
> the speed back by running the CPU in turbo mode...2052 mhz which doesn't 
>   seem to phaze the CPU...the problem here is simply on the memory 
> bus...and this may indeed be a pcb layout problem...of course, Asus says 
> the problem doesn't exist and I should run Windows.  There is an article 
> on the Muskin site about the Athlon 64 and memory that I found very 
> interesting...and perhaps we know why the Opteron uses registered 
> memory...even using 2 DIMMs unbuffered is really pushing the limits.
> 
> Sorry to bother ya if you have been all thru this stuff...I know the 
> frustrations...and since I am running FC2 T3 without any problems at all...
> 
> HTH,
> KAS
>