Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#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 Martin Decky)

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)

helenos-panic.png (25.8 KB ) - added by Štěpán Henek 14 years ago.

Download all attachments as: .zip

Change History (10)

by Štěpán Henek, 14 years ago

Attachment: helenos-panic.png added

comment:1 by Jakub Jermář, 14 years ago

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.

in reply to:  1 comment:2 by Štěpán Henek, 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

comment:3 by Jakub Jermář, 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).

in reply to:  3 comment:4 by Štěpán Henek, 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

comment:5 by Jakub Jermář, 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.

in reply to:  5 comment:6 by Štěpán Henek, 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 Martin Decky, 14 years ago

Description: modified (diff)

comment:8 by Jakub Jermář, 14 years ago

Resolution: worksforme
Status: newclosed

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 Jakub Jermář, 14 years ago

It is possible that the described issue is caused by the bug fixed in changeset:mainline,605.1.19

Note: See TracTickets for help on using tickets.