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.
