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(a)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(a)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