By the way, the kernel and android file system located on my U-disk，if
this affect!
As the kernel can not recognize the SATA hardware, even the
scsi device support,
scsi disk support
SCSI low-level drivers
Serial ATA and Parallel ATA
are build into the kernel.
Can you send me the .config to me for reference if possible, thank
you!
On 12月7日, 下午11时54分, 李晖 <lihui205...@gmail.com> wrote:
> 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.
