IRC.

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