diff options
Diffstat (limited to 'open_issues/virtualbox.mdwn')
| -rw-r--r-- | open_issues/virtualbox.mdwn | 44 |
1 files changed, 41 insertions, 3 deletions
diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn index 9440284f..d0608b4a 100644 --- a/open_issues/virtualbox.mdwn +++ b/open_issues/virtualbox.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,11 +8,15 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +[[!toc]] + + +# Running GNU Mach in VirtualBox crashes during initialization. + [[!tag open_issue_gnumach]] -Running GNU Mach in VirtualBox crashes during initialization. -IRC, freenode, #hurd, 2011-08-15 +## IRC, freenode, #hurd, 2011-08-15 <BlueT_> HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once you see the Grub menu, turn off the debian hurd box. 3) Let the box boot @@ -97,3 +101,37 @@ IRC, freenode, #hurd, 2011-08-15 <youpi> what's interesting is that that one means that $USER_DS did load in %es fine at least once <youpi> and it's the reload that fails + + +# Slow SCSI probing + +[[!tag open_issue_gnumach]] + + +## IRC, freenode, #hurd, 2012-08-07 + + <braunr> youpi: it seems the slow boot on virtualbox is really because of + scsi (it spends a long time in scsi_init, probing for all the drivers) + <youpi> braunr: we know that + <youpi> isn't it in the io port probe printed at boot? + <youpi> iirc that was that + <braunr> the discussion i found was about eata + <braunr> not the whole scsi group + <youpi> there used to be another in eata, yas + <braunr> oh + <braunr> i must have missed the first discussion then + <youpi> I mean + <youpi> the eata is the first + <braunr> ok + <youpi> and scsi was mentioned later + <youpi> just nobody took the time to track it down + <braunr> ok + <braunr> so it's not just a matter of disabling a single driver :( + <youpi> braunr: I still believe it's a matter of disableing a single driver + <youpi> I don't see why scsi in general should take a lot of time + <braunr> youpi: it doesn't on qemu, it may simply be virtualbox's fault + <youpi> it is, yes + <youpi> and virtualbox people say it's hurd's fault, of course + <braunr> both are possible + <braunr> but we can't expect them to fix it :) + <youpi> that's what I mean |