If the machine is still usable after the oops, either direct or through the network, yourtai is working correctly b4 i install rtnet. And I had specified rtai-installation directory while installing rtnet and everything went smoothly!!
The kernel-oops looked something like this!!
Mar 3 19:03:50 QCS-dom-linux kernel: RTnet: initialising real-time networking Mar 3 19:03:50 QCS-dom-linux kernel: RTnet: stack-mgr started Mar 3 19:03:50 QCS-dom-linux kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Mar 3 19:03:50 QCS-dom-linux kernel: printing eip: Mar 3 19:03:50 QCS-dom-linux kernel: c88f3a6d Mar 3 19:03:50 QCS-dom-linux kernel: *pde = 00000000 Mar 3 19:03:50 QCS-dom-linux kernel: Oops: 0002 Mar 3 19:03:50 QCS-dom-linux kernel: CPU: 0 Mar 3 19:03:50 QCS-dom-linux kernel: EIP: 0010:[<c88f3a6d>] Not tainted Mar 3 19:03:50 QCS-dom-linux kernel: EFLAGS: 00010246 Mar 3 19:03:50 QCS-dom-linux kernel: eax: 773593ff ebx: c88ca400 ecx: 00000000 edx: 00000000 Mar 3 19:03:50 QCS-dom-linux kernel: esi: c8921000 edi: 00000201 ebp: 00000000 esp: c56d1f98 Mar 3 19:03:50 QCS-dom-linux kernel: ds: 0018 es: 0018 ss: 0018 Mar 3 19:03:50 QCS-dom-linux kernel: Process U:HARD:0:4 (pid: 693, stackpage=c56d1000) Mar 3 19:03:50 QCS-dom-linux kernel: Stack: 00000400 c891c9f7 c56d0000 00000000 c8920c40 00000000 c8915e9e c8921000 Mar 3 19:03:50 QCS-dom-linux kernel: 00000000 c8921000 c56d0000 00000000 c8920c40 c890f780 c890015f c8920c40 Mar 3 19:03:50 QCS-dom-linux kernel: c890a3c1 00000000 00000004 00000100 c5735fb0 00000000 c01059ee 00000000 Mar 3 19:03:50 QCS-dom-linux kernel: Call Trace: [<c891c9f7>] [<c8920c40>] [<c8915e9e>] [<c8921000>] [<c8921000>] Mar 3 19:03:50 QCS-dom-linux kernel: [<c8920c40>] [<c890f780>] [<c890015f>] [<c8920c40>] [<c890a3c1>] [<c01059ee>] Mar 3 19:03:50 QCS-dom-linux kernel: [<c8900090>] Mar 3 19:03:50 QCS-dom-linux kernel: Mar 3 19:03:50 QCS-dom-linux kernel: Code: c7 01 02 00 00 00 8b 53 1c 29 d0 89 81 c8 00 00 00 8b 93 a0
I am tryin to resolve it by ksymoops but i ve never used it b4..so any help
in that regard will make my day!!
Thanx
should pass the Oops information to ksymoops. So, you could do this f.e.:
dmesg|ksymoops
or
ksymoops < oops.txt
after you have copied the oops info into the oops.txt file.
If the machine is not usable anymore, the easiest way is toattach the machine on which the Oops occurred to another machine using a null-modem cable. You can now log into the machine from that other machine using minicom, ckermit or gkermit. If you repeat the procedure to get the machine to oops, you can capture the oops through minicom (ckermit or gkermit) and save it to a file (f.e. oops.txt).
If the machine was not usable anymore, you should reboot it and get it into roughly the same
state, by loading the same modules as you loaded when the Oops occurred (except the ones which put your machine into a unusable state). Then try the abovementioned ksymoops commands. If the oops occurred on loading of a module, this method possibly will not give you all the interesting information, because the state will not be exactly the same.
If you grab the necessary info from the oopsing machine, you can also do the oops processing on another machine, which is what I do most of the time.
With friendly regards, Takis
signature.asc
Description: OpenPGP digital signature
