Debian (9.1) machine freeze after running "sudo ./a.out" #23
Comments
|
On Thu, Oct 5, 2017 at 5:01 PM Nicolò Ciraci ***@***.***> wrote:
Type of this issue (please specify)
This is a bug in the upstream tree as-is unmodified.
System information
1. CPU: Intel (Codename: i5-4278U)
2. Kernel: Linux
3. Kernel version: 4.9.0-3-amd64
Issue description
After running sudo ./a.out the machine freeze, I was able to understand
that "ioctl" causes the freeze.
Since the machine just become unresponsive there is no logs,
Comment out the code in ept_memory_type() function and make it just return
EPT_MT_WRITEBACK, see if that fixes it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#23>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABvH5VSUGUzKAAQwZaHpY9kturU14l8Wks5spO7ZgaJpZM4PvOSh>
.
--
asamy
|
|
I'm still experiencing the problem, also when compiling I get this warning: |
|
This warning is a false positive. The host stack is 2 4-KByte pages in size. Are you testing on VM or baremetal? What is your RAM capacity? |
|
I'm testing on baremetal, 8 GB of RAM. Looking into #22, esoterix's comment can lead somewhere? |
|
No, commit 85a228d fixes what he pointed out. |
|
Someone reported that disabling some VMCS controls fixes the freeze, but he hasn't pointed out which one is faulty. Since I can't reproduce this freeze at all myself, can you disable one by one and let me know here which is faulty? He pointed out removing all bits in |
|
I'm been able to get the stack frame of the crash via tty, we get a GPF. I've attached an image because I can't get the txt log. (sorry for the quality) |
|
Upload ksmlinux.ko |
|
Here we go! |
|
I found out that after a while, the machine unfreeze. I don't understand what is happening. |
|
I had this issue before with Have it like this: #if 0
int i;
struct mtrr_range *range;
u8 type = 0xff;
for (i = 0; i < k->mtrr_count; ++i) {
range = &k->mtrr_ranges[i];
if (!in_bounds(gpa, range->start, range->end))
continue;
if (range->fixed || range->type == EPT_MT_UNCACHABLE)
return range->type;
if (range->type == EPT_MT_WRITETHROUGH && type == EPT_MT_WRITEBACK)
type = EPT_MT_WRITETHROUGH;
else
type = range->type;
}
if (type == 0xff)
type = k->mtrr_def;
return type;
#else
return EPT_MT_WRITEBACK;
#endif |
|
I was having the same issue, and I just found the problem. The MAX_RANGES in mm.h was too small. I had 10 physical memory regions, and MAX_RANGES default value is 8. |
|
Actually I commented it but since it didn't fix the issue I decommended it. I tested it right now, and the um.c don't freeze anymore but I get EDIT: I rerun a.out and another freeze |
|
I rune again but this time the machine did not froze, and I was able to get this from dmegs: |
|
Set |
|
Still freezes |
|
That physical memory range output is weird when you said you have 8 GB of RAM. Are you using VM now or something? Maybe it's not pre-allocating physical RAM like it should, so it's getting a lot of EPT violations to allocate them and that causes the freeze. Maybe the code that gets the physical memory ranges is faulty... Regardless, assuming those are the physical memory ranges you have (i.e. the output matches the actual ranges), then those are not enough. |
|
Yeah, now I'm using a VM so I don't have to reboot every time the machine freeze. |
|
So, I tested today and I haven't been able to reproduce. Both on VM and baremetal (Both Windows 10 & Linux 4.13.8-1), the only difference is my CPU is an i7-5550U (Broadwell). Have you been able to find some other clue other than the double crash? Can you disable features until you find something out of ordinary? |
|
Good morning sir, I've gotten the same 'freeze' issue on 'Ubuntu 16.04.1' (kernel version is '4.15.0-29-generic'), when I'm trying to run 'sudo ./a.out', the VM will be froze. BUT, I've found something interesting out of the blue:
so, I guess that maybe the code has been swapped to disk. My VM memory range is 2GB. |
Type of this issue (please specify)
This is a support matter (i.e. your own modified tree). I've removed CPU_DYING because it is not supported anymore.
System information
Issue description
After running
sudo ./a.outthe machine freeze, I was able to understand that "ioctl" causes the freeze.Since the machine just become unresponsive there is no logs,
The text was updated successfully, but these errors were encountered: