#219 closed defect (worksforme)
kernel panic on amd64
Reported by: | Štěpán Henek | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 0.4.3 |
Component: | helenos/unspecified | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description (last modified by )
After cca 20 "tasks" commands on kconsole kernel panics.
qemu and VirtualBox
latest unmodified sources from bzr://bzr.helenos.org/mainline
gcc_native option
gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
Target: x86_64-pc-linux-gnu
Attachments (1)
Change History (10)
by , 14 years ago
Attachment: | helenos-panic.png added |
---|
follow-up: 2 comment:1 by , 14 years ago
comment:2 by , 14 years ago
Replying to jermar:
I have not been able to reproduce this on Qemu + cross compiler so far.
Can the submitter try to reproduce this using the supported cross compiler (i.e. installed by our toolchain script)?
Cross compiler seems to work fine.
It would be also useful to see the rest of the panic message including the possible stack trace and have at least kernel.disasm attached.
I haven't seen the rest of the message. The message always looks like this.
Can't attach whole kernel.disasm (file limit 256KB)
http://www.ms.mff.cuni.cz/~henes5am/kernel.disasm
follow-up: 4 comment:3 by , 14 years ago
Could you also upload the corresponding image.iso somewhere? So that we have a chance to investigate? (Please make sure the image.iso matches the kernel.disasm).
comment:4 by , 14 years ago
Replying to jermar:
Could you also upload the corresponding image.iso somewhere? So that we have a chance to investigate? (Please make sure the image.iso matches the kernel.disasm).
Compiled HelenOS root dir is in http://www.ms.mff.cuni.cz/~henes5am/HelenOS.tar.bz2
follow-up: 6 comment:5 by , 14 years ago
Hi Stepan, I have one idea which could help us to get this one resolved. Could you please try to reproduce this on the current head with qemu logging turned on? Just run qemu with -d int,cpu_reset option. That will create a log file in /tmp/qemu.log. When the issue is reproduced, can you grep it for occurrence of 'Triple fault' and tell us whether it was present or not? You may want to build a recent version of qemu for that.
comment:6 by , 14 years ago
Replying to jermar:
Hi Stepan, I have one idea which could help us to get this one resolved. Could you please try to reproduce this on the current head with qemu logging turned on? Just run qemu with -d int,cpu_reset option. That will create a log file in /tmp/qemu.log. When the issue is reproduced, can you grep it for occurrence of 'Triple fault' and tell us whether it was present or not? You may want to build a recent version of qemu for that.
Hi Jakub,
I tried my original qemu 0.11.1 and there were no occurrences of 'Triple fault' in /tmp/qemu.log.
I upgraded to qemu 0.12.3, but I wasn't able to boot HelenOS
$ qemu-system-x86_64 -d int,cpu_reset -vga std -boot d -cdrom image.iso
gave me Error: "No-execute pages not supported. System halted."
I tried to boot other x86_64 system using this command and it went OK.
I there any special option to use when booting HelenOS with qemu-0.12.3?
comment:7 by , 14 years ago
Description: | modified (diff) |
---|
comment:8 by , 14 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I am closing this as not-reproducible. The issue has been only ever observed with an unsupported, native compiler.
Moreover, the supplied packed workspace is at changeset:mainline,400 which does not contain many of the important fixes for the then-just-integrated measuring branch, sleeping while holding a spinlock and scheduler running on destroyed TASK/AS. Therefore it is difficult to say whether the issue reproducible with the image.iso from the packed workspace is the original one or some issue caused by the above bugs which were later fixed in mainline.
comment:9 by , 14 years ago
It is possible that the described issue is caused by the bug fixed in changeset:mainline,605.1.19
I have not been able to reproduce this on Qemu + cross compiler so far.
Can the submitter try to reproduce this using the supported cross compiler (i.e. installed by our toolchain script)?
It would be also useful to see the rest of the panic message including the possible stack trace and have at least kernel.disasm attached.