Hide Forgot
Created attachment 479095 [details] Tunnelbroker script Description of problem: I use a tunnelbroker for ipv6 and i would test radvd for autoconfig my other computer When i start radvd or maximum 1 minute later, i have 1 kernel panic (led of keyboard flash) Version-Release number of selected component (if applicable): kernel-2.6.35.11-83.fc14.x86_64 radvd-1.6-2.fc14.x86_64 How reproducible: Mount a 6to4 tunnel start radvd Actual results: Kernel panic Expected results: When radvd is stop, i have no problem Additional info: I suspect a problem in stack ipv6, but i don't now if it's exact ;)
Created attachment 479096 [details] radvd config
We need to see the panic messages. Can you start the system in text mode and take a picture of the screen with the messages? To do this, edit /etc/grub.conf and remove string "rhgb quiet" from the options for the kernel, and replace with "ignore_loglevel vga=1 3". This will get you a text-mode boot in 50-line mode.
Hello thank you for your response I have rebooted but when the bug arrived, there is not a kernel panic, but a reboot (nothing on the screen, just a reboot) For reproduce i have : start with ignore_loglevel vga=1 3 start my tunnel with my script start radvd start fedora 15 kvm (virtual machine) with virsh from another pc ( physical windows pc), i have connected to fedora 15 (virtual), and i have ping6 ipv6.google.com, immediately my fedora 14 (physical pc) reboot But a ping6 from my fedora14 to ipv6.google.com work perfectly. Sorry for my bad english ;)
Created attachment 479358 [details] Ping6 when ip6tables is start ping6 from virtual machine (kvm) to ipv6.google.com sreen from fedora 14 (physical) ip6tables is start
Created attachment 479359 [details] Ping6 when ip6tables is stop --> kernel panic ping6 from virtual machine (kvm) to ipv6.google.com sreen from fedora 14 (physical) ip6tables is stop --> kernel panic
I have succes to reprodure kernel panix but with kernel-2.6.35.10-74.fc14.x86_64 Same problem with kernel-2.6.35.11-83.fc14.x86_64 but the computer reboot directly when kernel panic The kernel panic occurs when send a ping from my virtual machine (fedora15 in kvm) to ipv6.google.com i have 2 image : when ip6tables start and stop
(In reply to comment #5) > Created attachment 479359 [details] > Ping6 when ip6tables is stop --> kernel panic > Can you boot with the option "vga=791" (or even "vga=794" if that works) and capture the output again? We need to see more lines of text...
i have a problem, : with vga=791, my computer reboot immediately on kernel panic i have tried an hd video, but the screen view is not readable :( do you have a solution for suppress the reboot ?
I have also tried Kdump for interfec kernel panic : When i press alt+sysrq+c --> kdump intercept the kernel panic and write vmcore and dmesg in /var/crash When i reproduce the bug : the computer reboot without intercept kernel panic :(
(In reply to comment #8) > i have a problem, : with vga=791, my computer reboot immediately on kernel > panic Try vga=1 for 50-line mode
i have already tested this mode : the computer reboot immediately after the kernel panic and id not intercept by kdump :s in mode vga=0 --> 25 line I have in the trace many reference of kdump and kexec and no reboot in the kexec kernel :s with th alt-sysrq-c : the computer generate a kernel panic and reboot in the kexec kernel and generate vmcare and dmesg It's strange :s
Does this still happen on the latest f14 kernel? Also, can you recreate it without using whatever proprietary module you have loaded in the panic in comment #5?
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping