Well, I'm currently trying the suggestion Civileme gave (to add append="
mem=nopentium" to the lilo entries). The only reference I found to that
option was in the BootPromptH2:
*
The `mem=' Argument
This argument has two purposes: The original purpose was to specify the
amount of installed memory (or a value less than that if you wanted to
limit the amount of memory available to linux). The second (and hardly
used) purpose is to specify mem=nopentium which tells the Linux kernel
to not use the 4MB page table performance feature.
*
Perhaps that explains why I was unfamiliar with it. :^) Since the
freezes were random, I'm still waiting (with my fingers crossed) to see
whether it works. I haven't tested the memories yet, but the fact that
window$ does not freeze (there were some DLL errors as usual of course,
but no freezes.) makes it unlikely to be a pure hardware problem, IMHO.
While I was making the changes to lilo.conf the system actually froze ;
it was one of the few times it gave me an error in /var/log:
*
# less /var/log/messages.1.gz |grep paging
May 19 23:08:22 pinguim kernel: Unable to handle kernel paging request
at virtual address dffe3fa4
May 26 00:07:54 pinguim kernel: Unable to handle kernel paging request
at virtual address dfcfbe88
less /var/log/messages |grep paging
May 26 13:35:30 pinguim kernel: Unable to handle kernel paging request
at virtual address dffe3fa4
*
aside from noting that the 1st and 3rd addresses are the same, I don't
know what to do with that. Perhaps I should try and ask Tosatti which
hidden monster lies in virtual address dffe3fa4... he lives just round
the corner after all... ;^)
I'd suggest people that are getting similar freezes, both with LM8.1 and
8.2, to take a look at their logs and see if they can make something out
of it. Perhaps this mem option in LILO might do them some good, as I
hope it will do for me.
Tom Brinkman wrote:
I'd start with reseating cards, ram, cables, etc. Clean out any
dust. Leave the case cover off and point a table fan into the box.
Then boot a memtest86 floppy and test your ram. Often freeze ups are
caused by poor connections, ram, or running too hot. If the ram passes
and the system doesn't freeze with a table fan blowin into it, you
probly need to improve case coolin. Heat was the problem.
If you still have freezes the next thing I'd try is renaming
XF86Config-4 to somethin like XF86Config-4-nvidia, and enable the
original XF86Config-4 to use the nv driver. You don't need to uninstall
the nvidia GLX and kernel packages. Just see if the freezes stop when
you use the open source driver. If they do, then the nvidia binaries
are the problem. Are you usin ones that were built against the kernel
you're usin 'em with?
I build all my drivers from tar.gz, BTw there is a new driver set (2960)
but I will postpone the installation till I fix this. I really do not
think it's an Nvidia driver related problem; it never occurs when I'm
using a particular graphic intensive app. But you might have a point,
though. One thing I was thinking about that matter is that I compiled
the kernel with kgcc (only way I managed to recompile Mandrake's kernel)
and the drivers with gcc. But then why oh why it WAS stable?
The first thing I thought was that the fan had died, but I opened the
case and it was running fine. I have two fans pulling air inside and one
out, and my CPU runs rather cool - never more than 40C. Besides it's
quite cold now here (well, not european cold) so its temperature is
about 36-37C. On the other hand, there is a lot of dust in there for
sure; I'll clean it over before I do the memory test.
Alastair Scott:
>>
This is very true - the first sign I got that my old machine was
misbehaving was two freezes in succession. I thought 'Linux doesn't do
this', opened the machine up, removed dust, made sure everything was
sitting properly in its sockets and, on the third reboot, the
motherboard blew and took various other things with it :/
And, on the new machine, I got a 'CPU not found' message on boot; it (an
Athlon XP 2000+) had failed but, being only a week old, I got a
replacement gratis next day.
- From my experience Linux _is_ hard on hardware and tests both ends of
the 'bathtub curve' (imagine age of component along X axis and
probability of failure along Y axis [;)]
Yes, while most components of my system are rather new, it might be
indeed a hardware failure. But then why doesn't window$ freezes as well?
I'm getting crazy with this alternatives. :^)
Etharp:
>>
on the other hand, it might be nice to know what happens when you are
"froze"
what actions do you take to shut down? and what is the results of
ctrl+alt+f2? or ctrl+alt+Backspace? might also be related to the IRQ, and
maybe the irq for USB (since the default kernal in 8.0 handles USB a little
less forgiving than in kernals after, and was not included (much) in kernals
before 8.0. (really 2.4. vs 2.2.x). you may also be having a timeout freeze
with a misconfigured service.
like the robot on lost in Space..... " need more input"
so if you could read and quote " cat /proc/interrupts" (with out the quotes
of course)
>>
I dont't use any USB devices, and they're actully disabled on BIOS. It
might be an IRQ conflict, I got some strange messages:
*
May 26 13:37:23 pinguim kernel: PCI: Found IRQ 5 for device 00:0d.0
May 26 13:37:23 pinguim kernel: PCI: Sharing IRQ 5 with 00:04.3
May 26 13:37:23 pinguim kernel: Redundant entry in serial pci_table.
Please sen
d the output of
May 26 13:37:23 pinguim kernel: lspci -vv, this message (4941,30864,4941,1)
May 26 13:37:23 pinguim kernel: and the manufacturer and name of serial
board or
modem board
May 26 13:37:23 pinguim kernel: to [EMAIL PROTECTED]
May 26 13:37:23 pinguim kernel: register_serial(): autoconfig failed
*
May 26 13:37:23 pinguim kernel: 8139too Fast Ethernet driver 0.9.18a
May 26 13:37:23 pinguim kernel: PCI: Found IRQ 12 for device 00:0a.0
May 26 13:37:23 pinguim kernel: PCI: Sharing IRQ 12 with 00:04.5
*
And I just don know what is sharing irq 5 with my beloved PCtel. But the
freezes also happened when the modem wasn't in use, so...
*
# cat /proc/interrupts
CPU0
0: 2437650 XT-PIC timer
1: 30111 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 87246 XT-PIC serial
5: 609852 XT-PIC PCTel
7: 1 XT-PIC parport0
8: 1 XT-PIC rtc
10: 31859 XT-PIC ide2
11: 1466526 XT-PIC nvidia
12: 1019087 XT-PIC eth0, VIA 82C686A
14: 5 XT-PIC ide0
NMI: 0
ERR: 0
*
BTW, the system froze completely, not even SysRq would work. But it has
already happened to me that X froze and took the keyboard with it; but I
always could telnet into it and kill X. Not those times...
Jerry:
>>
Only hang problem i have in 8.2 is (and this started yesterday so i haven't
checked it yet) durring boot, it successfully checks (kernel configuration?
i dont' remember now.. been awake too long) and just before init enters
runlevel3 it'll hang. It'll hang GOOD there too 2 hours yesterday while i
went and got something to eat & went to the store.. i can Ctrl-C but the
rest of the boot fails that way. I started just pushing buttons once and
when i hit the print screen/SysRq button BOING!!!! it went cruising along
(still had a failure but it went by too fast). then at shutdown (well..
sometime durring boot too) when it syncs with the hardware clock, it's
totally 100% dead frozen.
Any ideas on this? like i said i haven't checked the logs yet... i'll do
that... (oh.. but wait.. i dont' have syslog because that was hanging too...
eeek.) maybe partition type? does it need to be a primary partition?(i
thought for sure it was...) Other than that oddity, though, 8.2's rockin'
right along. ('cept Wine [:-(] i've lost my fileserving on mIRC)
>>
One of the facts that led me not to update to 8.2 was the fear that
something might not work as well as in 8.1 (till now). Besides, I
believe in "if it ain't broke, don't fix it" stuff. And the only thing I
really wanted to see was whether the pt_BR translation I worked in was
ok... but my friends have already said it was good, even though most of
then don't know I were translating... but I digress.
The 2.4.18 stock kernel I compiled will sometimes freeze at boot like
yours; this never happens with the mdk kernel. I guess we'l all remember
the 2.4 kernels for a long time... you might try the mem=nopentium trick
and see if it does you any good ( I don think it will harm anyways).
Perhaps downgrading the kernel, but thats a somewhat radical approach-
it seems to have worked to some people with enterprise kernels as I read
in the list.
Thanks you all, I'll keep you posted.
Wooky
--
--
shinjiteiru shinjirareru,
korekara aruku kono michi wo!
kimi ga iru yo, boku ga iru yo
sore ijou nani mo iranai.
umareta imi ,sagasu yori mo
ima ikiteru koto kanjite,
kotae yori mo, daiji na mono
hitotsu hitotsu mitsuketeiku...
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
