Maybe I wasn't clear. I CAN get a trace from ksymoops, but it's different each time. I've seen hangs in sys_create_module (printk-s proved it to be OK), I've seen hangs in stack_done, I've seen situtations where lsmod shows the module as initializing. The only thing that's consistent is the info below for one of my modules, and do_page_fault (I may be in-accurate on the name) for another module. All other 8 modules show no problems. On Tue, Apr 22, 2003 at 07:38:57PM +0200, Gilad Benjamini wrote: > Sad to say that this IS the interesting part. > The ksymoops data is very un-consistent. This is the only thing that is > consistent. Umm... Not having backtrace makes this information virtually useless. You can reconstruct backtrace manually, by looking at call stack addresses, and finding them in System.map. > > > -----Original Message----- > > From: ilya@theIlya.com [mailto:ilya@theIlya.com] > > Sent: Tuesday, April 22, 2003 6:27 PM > > To: Gilad Benjamini > > Cc: kernelnewbies@nl.linux.org; linux-mips@linux-mips.org > > Subject: Re: Crash on insmod > > > > > > I think this is not an interesting part. > > run the whole thing through ksymoops, and send output here. > > For mor information see linux/Documentation/OOPS-tracing > > > > Ilya > > > > On Tue, Apr 22, 2003 at 10:15:32AM +0000, Gilad Benjamini wrote: > > > This is the interesting part from the oops message: > > > > > > Using /lib/modules/2.4.20-pre6-sb20021114 ... > > > unable to handle kernel paging request at virtual address > > 00006e76, epc == c0005100, ra == 80117e08 > > > Oops in fault.c::do_page_fault, line 224: > > > > > > > > > > > > > > > > >
