hi, zhangfx I rebuild the android file system by using the cross-
compile toolchain you give to me(in an other post you give me the
link), I encounter the libwebcore.so ld problem again, by replace it
with the libwebcore.so I compile succeed early and recompile it again,
I succeed build the android file system, but when I try to boot it,
the kernel panic again, but this the init panic at the first dup2
system call, I don't know if it is the illegal instruct that result in
this panic, I will test it tomorrow as my loongson machine was token
away by another colleague :(
On 12月4日, 下午11时17分, 李晖 <lihui205...@gmail.com> wrote:
> hi, zhangfx,
> for the first question, you have explained very clearly, I
> understand it right now！
> for the second question, I will try your advise and will feedback
> then!
>
> thank you for your patient and detailed reply!
>
> andy
>
> On 12月4日, 下午4时00分, "Fuxin Zhang" <zhan...@lemote.com> wrote:
>
>
>
>
>
>
>
> > > hi, zhangfx,
> > > I followed your advice by adding printf to the do_ri function and
> > > found that when the kernel init the system, this function was called
> > > hundreds of times and then the kernel panic, so it means that there
> > > are illegal instruction exist, but why do_ri will be called so many
> > > times?
>
> > for some instructions, they are not supported by the hardware, but the
> > kernel will simulate it in software correctly, so it won't cause a fatal
> > error. But if the kernel has no code to simulate it, the related user land
> > process will be killed with SIGILL(if it happens in kernel mode, kernel
> > will panic). So check which instruction cause the exception and check if
> > do_ri has code to handle it.> another question is that by add printf to
> > the init source code, I
> > > found that the kernel panics in the open_devnull_stdio,
>
> > the kernel panic because init exit. e.g. if your init process is just one
> > line code
> > int main() return 0;
> > you will see the kernel panic.
>
> > I am not sure about your detail situation, but if the second dup2 cause a
> > segmentation fault or some other fatal fault for init process, the kernel
> > will panic shortly after. Also it is possible if the init has several
> > threads and some other threads cause the exit of the process.
>
> > The init code should have some existing switchable debug code, try to turn
> > them on to find more clues.
>
> > > void open_devnull_stdio(void)
> > > {
> > > int fd;
> > > static const char *name = "/dev/__null__";
> > > if (mknod(name, S_IFCHR | 0600, (1 << 8) | 3) == 0) {
> > > fd = open(name, O_RDWR);
> > > unlink(name);
> > > if (fd >= 0) {
> > > dup2(fd, 0); //*************************this call don't
> > > panic the kernel*******************
> > > dup2(fd, 1); //*************************panic
> > > here**************************
> > > dup2(fd, 2);
> > > if (fd > 2) {
> > > close(fd);
> > > }
> > > return;
> > > }
> > > }
>
> > > exit(1);
> > > }
>
> > > as you can see from the source code, the dup2 is a system call, and
> > > the kernel was compiled by using cross-compile from loongson
> > > community, there should no illegal instructions exist?
> > > If it possible the kernel panic at other position and the printf
> > > information don't flush out?
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "loongson-dev" group.
> > > To post to this group, send email to loongson-dev@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > loongson-dev+unsubscr...@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/loongson-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
"loongson-dev" group.
To post to this group, send email to loongson-dev@googlegroups.com.
To unsubscribe from this group, send email to
loongson-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/loongson-dev?hl=en.
