The subject says it all. I'm seeing segfaults from v86d using the 2.6.30-gentoo-r4 kernel, similar to those reported in previous kernels. Here are the facts: - Gcc version doesn't seem to matter (tested with 4.1.2 and 4.3.2) - Compiling with +x86emu will make v86d work properly only if I recompile the kernel after. Only compiling v86d will still result in the crash. - I have uvesafb built into the kernel, but there was a report on the forums that leads me to believe that this problem might also affect those who compile uvesafb as a module: http://forums.gentoo.org/viewtopic-t-778841-highlight-.html Essentially what happens, on first boot there will be a delay before the initramfs start booting, where all I see is a black screen. This also occurs when taking uvesafb out of the command line parameters. After this black screen passes, the machine boots perfectly, however when switching from X to a virtual terminal, or even between 2 virtual terminals there is a long pause with a black screen again. Dmesg shows that v86d segfaulted (sorry i don't have the exact messages, but they were nearly identical to those posted in some of the previous bugs about v86d segfaulting.) Not sure if this is only affecting me due to some other misconfiguration... Reproducible: Always Steps to Reproduce: 1. Emerge v86d using -x86emu 2. Install 2.6.30-gentoo-r4 kernel 3. Reboot into new kernel Actual Results: Black screen on first boot with v86d segfaulting Expected Results: No segfault, and not pause on boot
Did you see these segfaults with older kernel versions as well?
(In reply to comment #1) > Did you see these segfaults with older kernel versions as well? > No, in previous kernels I was using v86d with -x86emu. 2.6.30-gentoo-r4 was the first kernel where I experienced the crashes. Let me know if you need me to post some additional information to help track down the crash.
(In reply to comment #2) > No, in previous kernels I was using v86d with -x86emu. 2.6.30-gentoo-r4 was > the first kernel where I experienced the crashes. Let me know if you need me > to post some additional information to help track down the crash. It will be helpful if you can let us know what was the last revision of gentoo-kernel that worked properly. It would be also nice if you could rebuild that last working kernel and see whether it still works (to make sure this is a kernel issue not related to toolchain or klibc).
(In reply to comment #3) > It will be helpful if you can let us know what was the last revision of > gentoo-kernel that worked properly. It would be also nice if you could rebuild > that last working kernel and see whether it still works (to make sure this is a > kernel issue not related to toolchain or klibc). > Sure thing... I should have some time later to reproduce the crash. The last kernel version that was working was 2.6.28-gentoo-r2. I also had uvesafb in the 2.6.24 kernel running before then without problem. Each time I recompiled v86d I also recompiled klibc. I'm not sure if that was necessary, but I figured it couldn't hurt. I recently upgraded to gcc-4.3.2 and glibc-2.9* so I suppose it could be a toolchain issue. I recompiled binutils just to make sure things are in a sane state before I do more testing.
Don't know if this is helpful or if this bug is still beingworked, but I have several machines that have the same issue, most recently with kernel 2.6.31-r6. I have another machine running 2.6.30-gentoo-r8 that works perfectly. On the machines that don't work, the error on boot is v86d segfault at c32a6 ip 0000 32bc sp 0000fc0 error 7 in v86d [9000+1000] getting mode info block for mode 0x113 failed eax 0x4f01, err=1 the mode number counted up a lot, then the machine booted in 80x25 display mode. I am happy to help with information and test builds.
