:: On Fri, 4 Aug 2000 20:21:42 -0700 (PDT), "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> said:
Hello Nate. Thanks a lot for replying. Here are the specs: Pentium II 400 Mhz, Motherboard DFI PA61 ATX (VIA Apollo Pro 133 chipset - 693/596b) (Absolutely nothing on-board) Award BIOS 64 Mb RAM (no ECC...) Video Card Diamond SpeedStar A50 (SiS 6326 AGP, not on-board) HD: Western Digital Caviar, 13.5 Gb, 7200 RPM With stable kernels, I use ATA/33 With unstable kernels, I managed to get a patch to use ATA/66. (I still didn't completely rule out ATA66, but... The system locked with a stable kernel (and hence, with ATA33) BTW, I have checked to see if I could find anything related to problems with this chipset and HD, but found nothing. > pelleg >To see what could be the problem, I left the system with xmms running > pelleg >while I was out for 4 hours. When I came back, the keyboard was > pelleg >non-functionl, and nothing worked... Since it's a standalone box, I > pelleg >hadto reset it. I was sort of expecting this (I was actually trying to > pelleg >rule out some applications that could be locking the system) > best thing to rule out first is X windows, disable X from starting: > if you run X from a login screen like KDM/GDM/XDM remove the link: No, I use startx... > pelleg >What could be happening? (I mean, why would it just ignore the > pelleg >comments and treat them like listed modules to be loaded?) > I can't imagine a reason why it would, something else may be wrong, but > the end result is harmless. Hm, waht about the fact that it only happened after this lock? I thought that perhaps this could mean filesystem corruption... > pelleg >I really don't understand what's going on... I suspected that my > pelleg >memory could be bad, but I've compiled lots of big packages (including > pelleg >several kernels, sometimes every two days), for months and never got a > pelleg >sig11. > check the kernel log /var/log/kern.log if the kernel encounters an error > it will be reported there, assuming it is not a serious hardware problem > which causes the machine to freeze before the kernel can report anything. Nothing there... Actually, it jumps from Aug, 4 to Aug, 21:50 (when I resetted the machine). And the messages begin with the new boot... Nothing in the period in which it crashed. > pelleg >I'm beginning to suspect this may be: > pelleg > > pelleg >- PS/2 mouse (these locks began to happen after I got a new mouse) > what brand/model of mouse? I got it from a cousin... It's a "Leadership" mouse, made in China. Ordinary 3-button PS/2 mouse, it seems... > and what kind of mainboard? i had serious PS/2 > trouble on an old AOpen AP5T-3, after a few months the PS/2 port worked > intermittantly(sp) maybe one out of 10 boots and even then would cause > random crashes, eventually i just moved to a serial mouse.(that > motherboard is still in service after 3 years it currently runs > mandrake7.0 and acts solely as a TV for my bedroom) Hmmm... Maybe I should get a serial mouse... > pelleg >- X 3.3.6 (no problems happened with X 4) > pelleg >- video card (SiS 6326 AGP) > what video mode are you running in? 1280x1240. I've been using this mode, with this card... For months! > and are you using a framebuffer X server? I believe there is no support to that for this card yet... > again i would reccomend not running X to see if X has something to > do with it, X can be a very good center place for lockups. Hm, just now I realize... I use flwm as a window manager (fast, small, and not configurable at all). I did compile it myself here (and I think I tried to include some compiler options to optimize it a little bit, like --arch=pentiumpro)... And packaged. Now I've reverted to the .deb I had before... But could this be a problem? I mean... Building the package myself? I was confident that the same package compiled by the mantainer could be compiled here... You know... We can even do that automatically with apt-get... :-) > if you run X, i would also suggest redirecting the output to a logfile, > when you login run: > startx >&X.log > all output will be saved to X.log, if there is a crash check it to see if > any helpful info is available. Right... I forgot to do that, but will next time. > pelleg >Next thing I'll do is to compile X 4.0.1 and see if the problem goes > pelleg >away. If it does, then (and I'd be surprised) it'd be an X-3.3.6 > pelleg >problem... > is it onboard video? if so do you have another video card to try? i > wouldnt reccomend going to XF86 4.0.1 if you can avoid it its likely to be > more buggy then XF86 3.3.6 for that video card(but i could be wrong) Actually, I did use 4.0.1 for a few days, and it didn't crash... But it may have been too little time. (I thought this could be a reasonable option, since the code is a lot different from that of 3.3.6) > hope this helps! Yes, that helped a lot already. > nate J. -- Jeronimo Pellegrini Institute of Computing - Unicamp - Brazil http://www.ic.unicamp.br/~jeronimo mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
