Kernel trap when booting memstick

M

MRossi

Hello,

I'm getting a "Kernel trap" error message when booting FreeBSD from USB memstick on my new laptop. How can I analyze if it's a hardware problem or maybe just a BIOS/UEFI problem, rather than a FreeBSD bug, etc?

The laptop is new, so I don't think it has some sort of hardware failure (maybe it got broken by a hit?).

Thank you all in advance, I love FreeBSD it really is a great, stable and polished OS.
 
What version of FreeBSD? What brand and model of computer? Is there a reason to install FreeBSD on the bare machine rather than as a VM?
 
FreeBSD is 9.1 and the laptop is an ASUS Vivobook S200E. Yes, of course I want to run it as the main OS; don't want to use any VM and never liked VMs at all.
 
MRossi said:
Hello,
I'm getting a "Kernel trap" error message when booting FreeBSD from USB memstick on my new laptop.
Click to expand...
Does the laptop have a CD/DVD drive? If so, try downloading, burning, and booting the ISO image instead of the memstick image.

I've run into cases where the USB hardware was vastly dissimilar to anything else, and the BIOS emulated a regular drive (INT 13, IIRC) enough that code could load from a USB drive but then when that code started looking around, it would panic due to the strange hardware.

Downloading and testing with the ISO image would also eliminate the possibility of a corrupted download of the memstick image or a problem with the flash drive itself.
 
I got this kind of error:
Code: 
Kernel trap 12 with interrupts disabled

Is it a hardware failure? This laptop is one month old only and never fell on the ground. If it's a hardware failure, then why does FreeBSD get scared every time there's a hardware failure (my other half-broken laptop, known to have an hardware problem, can run Windows and Linux decently) and fails?

Windows and Linux work fine on this laptop. I don't know what to think of.
 
MRossi said:
Is it a hardware failure? This laptop is one month old only and never fell on the ground
Click to expand...
Unlikely, particularly if it always happens at the same point in the boot process. Did you try the ISO image to see if it gives better results?
 
Terry_Kennedy said:
Unlikely, particularly if it always happens at the same point in the boot process. Did you try the ISO image to see if it gives better results?
Click to expand...

Oh, sorry I didn't see your post. No, unfortunately, I don't own one and no one can lend me one.
 
Sorry. Maybe, I have been a bit superficial. The USB memstick can boot correctly from another laptop, so I don't think it could be a corrupted download of the memstick image. The exact error message that I'm getting is:
Code: 
Kernel trap 12 with interrupts disabled
 
I'm still having this issue and FreeBSD doesn't boot on my laptop in any way. I even tried to use the ISO rather than the IMG (as suggested above) but it always crashes right at the same point. I have already reported this bug on FreeBSD's bug tracker but seems like idle so far.

Windows and Linux both boot fine, so I'm wondering what's wrong with FreeBSD and my laptop. I don't think it has anything to do with hardware failure nor dust, because it always crashes right at the same point.

Could anyone help me out more with this bug, please?
 
MRossi said:
I'm still having this issue and FreeBSD doesn't boot on my laptop in any way. I even tried to use the ISO rather than the IMG (as suggested above) but it always crashes right at the same point. I have already reported this bug on FreeBSD's bug tracker but seems like idle so far.
Click to expand...
Can you post the PR number that was assigned to your bug report?

Windows and Linux both boot fine, so I'm wondering what's wrong with FreeBSD and my laptop. I don't think it has anything to do with hardware failure nor dust, because it always crashes right at the same point.
Click to expand...
I agree that it's unlikely to be a hardware failure. The initial response to hearing about a trap 12 is often "your hardware's broken", simply because of what trap 12 means: trying to read something that isn't there. This can often come from broken hardware, but if you get it repeatedly in the same place, it is more likely to be a software problem.

Could anyone help me out more with this bug, please?
Click to expand...
I'll have to look at your PR (once you post the number) to see if you've provided all the information needed to tell what part of the kernel this is coming from.

Note that I'm not a developer - but I can help you gather enough info so that we know what area is causing the problem and which developer(s) to ask to look at your PR.
 
Sure. The PR number is PR 176094.
I have provided basic info because I'm a newbie with FreeBSD and I was waiting for someone's response before going any further. Feel free to ask me to provide more info if they're needed to fix the bug.
 
MRossi said:
Sure. The PR number is PR 176094.
I have provided basic info because I'm a newbie with FreeBSD and I was waiting for someone's response before going any further. Feel free to ask me to provide more info if they're needed to fix the bug.
Click to expand...
Ok. At a minimum, you should add to the PR with:
  • Architecture - i386 or amd64?
  • Computer make / model? (I know you gave it here, but it should be in the PR as well.)
  • Where the panic happens - is it before the boot menu is displayed, or after?
  • If after, please select the "Verbose boot" from the menu.
  • Please supply the last few lines of the message text before the trap message.
  • Please supply as much as possible* of the message text after the trap message is printed
* I say "as much as possible" because if your computer reboots automatically, the message will clear from the screen, and since this is a notebook it is unlikely to have any remote management facility that can capture the data. If you have a smartphone, you may be able to take a picture (or make a video and extract only a single frame with the data). Note that the function name and offset (like "foo+232") is generally more useful than the absolute address (like "0xffffffff80857c55") unless the address is something "magic" (for example, "0xffffffffdeadbeef").
 
Terry_Kennedy said:
Ok. At a minimum, you should add to the PR with:
  • Architecture - i386 or amd64?
  • Computer make / model? (I know you gave it here, but it should be in the PR as well.)
  • Where the panic happens - is it before the boot menu is displayed, or after?
  • If after, please select the "Verbose boot" from the menu.
  • Please supply the last few lines of the message text before the trap message.
  • Please supply as much as possible* of the message text after the trap message is printed
* I say "as much as possible" because if your computer reboots automatically, the message will clear from the screen, and since this is a notebook it is unlikely to have any remote management facility that can capture the data. If you have a smartphone, you may be able to take a picture (or make a video and extract only a single frame with the data). Note that the function name and offset (like "foo+232") is generally more useful than the absolute address (like "0xffffffff80857c55") unless the address is something "magic" (for example, "0xffffffffdeadbeef").
Click to expand...

Someone's mind is at McDonalds!
 
You must log in or register to reply here.
Back
Top