Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update config.strip for amd64 boot failure in VirtualBox #32

Closed
wants to merge 1 commit into from
Closed

Update config.strip for amd64 boot failure in VirtualBox #32

wants to merge 1 commit into from

Conversation

bconway
Copy link
Contributor

@bconway bconway commented Apr 9, 2015

This would most likely fatten up the kernel too much to be accepted, but I wanted to put it out for posterity. I spent the time going through line-by-line and group-by-group (ugh) to see which options from radeondrm onward cause a crash during kernel load in VirtualBox 4.3.26.

I also opened a ticket in the hopes that some of the problem is on their end, with a testable disk image: https://www.virtualbox.org/ticket/14035

Of note: None of these changes are needed to boot i386 in the same VirtualBox configuration. Weird.

This would most likely fatten up the kernel too much to be accepted, but I wanted to put it out for posterity. I spent the time going through line-by-line and group-by-group (ugh) to see which options from radeondrm onward cause a crash during kernel load in VirtualBox 4.3.26.

I also opened a ticket in the hopes that some of the problem is on their end, with a testable disk image: https://www.virtualbox.org/ticket/14035

Of note: None of these changes are needed to boot i386 in the same VirtualBox configuration. Weird.
@yellowman
Copy link
Owner

It seems apparent the real problem is somewhere else in the kernel. Also, funny enough, these changes might break amd64 on real hardware. I don't know if you've tried that?

@bconway bconway closed this Apr 11, 2015
@yellowman
Copy link
Owner

Well the problem is still a problem. The diagnostics from Frank give us a way to fix the problem. I think the IDT setup needs to be addressed. Can you peek at the kernel some more in this regard? The FLASHRD kernel configs continually expose this problem. I think it's a generic problem that is layout dependent????

@bconway
Copy link
Contributor Author

bconway commented Apr 11, 2015

This is mostly getting above my head now, but I'm happy to try. Will have some free time next week.

@bconway
Copy link
Contributor Author

bconway commented Jun 11, 2015

We are not alone. Doo doo dooo.

https://www.mail-archive.com/misc@openbsd.org/msg138735.html

@yellowman
Copy link
Owner

I believe the issue you faced here was fixed here in the 5.8 release:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/mpbios_intr_fixup.c.diff?r1=1.6&r2=1.7

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/mpbios_intr_fixup.c.diff?r1=1.5&r2=1.6

However, this guy also says that he no longer saw the issue as of Jul 10th and reiterated it was fixed for "all sizes" of ramdisks as of Jul 14th, a month before these fixes were added to the tree.

I suspect your specific issue is fixed by Mike Larkin in these commits. But i'm also going to merge your patch because it fits in with my original intent; to make a largely GENERIC kernel available to users, because Mike's patch actually fixes the original problem that I was trying to solve the wrong way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants