>>> ]> Last night all was well, this morning -> no boot.
>>> ]>
>>> ]> <exerpt>
>>> ]> ds: 0018 es: 0018 ss: 0018
>>> ]> Process insmod (pid: 220, stackpage=c05b1000)
>>> ]> Stack: c05ff3eo c01154e6 c032eca0 c0399d89 ffffffff 000018c9 c05b1d4c
>>> ]> 3 more lines of address',...
>>> ]>
>>> ]> Call Trace: [<c01154e6>] [<c0107f6c>] [<c309z24>] [<c01080d2>]
>>> ]> [<c0101a08a>]
>>> ]> 7 more lines of [<address>]
>>> ]>
>>> ]> 7 more lines of [<address>]
>>> ]>
>>> ]> Code: 0f b7 42 02 f6 c4 40 74 0c 8b 42 44 c7 00 ff ff ff ff eb 0c
>>> ]> <0>Kernel paniv: Aiee, killing interupt handler!
>>> ]> In interrupt handler - not syncing
>>> ]>
>>> ]> I have been able to reboot, enter runlevel 0 fsck / and work that way
>>> but ]> i can not boot cold, i will not get by problem.
>>> ]>
>>> ]> I have not experienced this before, any ideas?
>>> ]>
>>> ]> TIA
>>> ]Hi.
>>> ]I suggest that you modify your BIOS (if possible) to use XT-PIC
>>> ]interrupts rather than APIC (Advance PIC). If you can't mod your
>>> ]BIOS to do this, then boot Linux with the following boot directive
>>> ]"acpi=off".
>>> ]To check if your got XT-PIC or APIC interrupts you can see by looking
>>> ]at /proc/interrupts and dmesg.
>>> OK, this is weird. I have been having a steadily worsening problem with
>>> this same sort of thing. It started off by a freeze in X (I left X up
>>> permanantly) every week or so, which got more frequent. Then in console
>>> mode I would get a similar panic to the above. Then in cosole mode I
>>> would get a problem running other programs. In each end every case that
>>> I could see the error output, I got a
>>> Unable to handle kernel Null Pointer dereference at virtual address
>>> 00000018.
>>> Also teh ds,es,ss registers all had 0018 in them just as does the above
>>> user's problem. the processes varied. egrep, less, run-parts would give
>>> it ( but would not crash the machine), but then swapper would get it,
>>> and would definitely crash the machine with the same Kernel Panic error
>>> message as abouve.
>>> I assumed it is hardware. I replaced the cpu (550MHz PIII-> 400MHz PII)
>>> and got the same problem. I replaced the memory, an got the same
>>> problem.
>>> t goto, it is either some motherboard fault (why are we all getting
>>> those virtual address 18 problems?--),
>>> (Just got another one while typing this in crond this time.) Again
>>> 000018 EIP: 0010 EFLAGS:00010013
>>> )
>>> Or it is some problem in Linux
>>> (kernel 2.4.8-32mdk Mandrake 8.1,)
>>> or it is some hacker who has gotten in and is playing real games with
>>> the kernel.
>>> HELP.
>> Bill,
>> Interesting, i don't know if we're experiencing the same thing but it
>> does have similiarities, if so it's definately not your processor or
>> memory but may be a motherboard issue (the machine in question is a
>> toshiba laptop with a pent mmx 266 MHz processor with 32 mb ram). I don't
>> run X, so i can't share any of your "kernel Null Pointer dereference's"
>> but i do get: ide1: unexpected interrupt, status=0x51, count=1
>> alot, it will just pop up at random times, at prompt's within `vi',
>> within `less' or `man', it doesn't seem to have a negative effect on
>> anything, it just displays to the screen (stderr).
>> It would be great to get some answer's on this.
>> --david
>> to reply axe _SPAM_BLOWS_
> Bill,
> How old is the power supply? if it on its way out or maybe the regulators
> on the board are getting a bit old it can have this affect.
> ) that started showing the same sort of probs, I monitored it with
> lm-sensors and the 5v rail was down to 4.55v, replaced board and all is
> well again
Hi guys.
Boot using "safe mode" (if your running SuSE - which I do) or
use the lilo directive at boot time to disable APIC and IDE DMA.
which is of course is distribution specific on how you may do this.
I suspect that IDE/DMA is a no no with your systems (it is with my
laptop too), and my motherboards on five system (PIII mostly all
have issues with APIC and MUST run in XTPIC mode, some with IDE/DMA
and APIC modes).
Before booting, deselect all but the very basic requirements in
/etc/rc.d/rc[35].d run modes to limit the problem area.
Initially only boot into Single user mode, and disable
individual services and see what happens, otherwise
boot into level 3 (SuSE) non X mode and check everything is AOK
before proceeding to level 5 (X mode). Look at all the logs
/var/log/* especially /var/log/messages and your X logs.
As I only have SuSE, you'll have to RTFM for your distribution /
release.
Hope this is of some help.
--
Cheers.
Grahame (at) Wildpossum (dot) com
by