VirtualBox

Ticket #7368 (new defect)

Opened 4 years ago

Last modified 3 years ago

Booting Debian GNU/Hurd takes very long

Reported by: HurdFan Owned by:
Priority: minor Component: VMM
Version: VirtualBox 4.0.4 Keywords: hurd mach boot
Cc: Guest type: other
Host type: Windows

Description

gnumach takes minutes to boot on VirtualBox, because VirtualBox apparently takes a very long time to implement the port probing that some drivers of gnumach do.

The same problem does not exist on qemu and kvm.

In rare cases I also received a guru mediation at the same boot stage.

See also the discussion thread at debian-hurd:

 http://lists.debian.org/debian-hurd/2010/08/msg00064.html

To reproduce you can use the current debian-installer image for Debian GNU/Hurd:

 http://people.debian.org/~sthibault/hurd-i386/mini.iso

 http://wiki.debian.org/DebianInstaller/Hurd

Attachments

VBox.log.1 Download (131.6 KB) - added by HurdFan 4 years ago.
VBox.png.1 Download (12.4 KB) - added by HurdFan 4 years ago.

Change History

Changed 4 years ago by HurdFan

Changed 4 years ago by HurdFan

comment:1 Changed 4 years ago by sthibaul

comment:2 Changed 3 years ago by frank

Still relevant with VBox 4.0.4?

comment:3 Changed 3 years ago by HurdFan

Yes, booting is still fairly slow, no visible improvement.

I haven't checked the guru mediation, because I don't have the original virtual machine anymore, but the slow booting is quite a showstopper by itself.

comment:4 Changed 3 years ago by frank

  • Version changed from VirtualBox 3.2.8 to VirtualBox 4.0.4

comment:5 Changed 3 years ago by HurdFan

The driver that causes the problem is not eata, but gdth. (I found that out by trial and error.)

The source code would be:

 http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/linux/src/drivers/scsi/gdth.c

and the related files in:

 http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/linux/src/drivers/scsi/

It's actually an old Linux (2.0?) driver that Mach uses to provide SCSI support for a GDT SCSI disk array controller.

comment:6 Changed 3 years ago by marcello.nuccio

I think I have the same problem with all guests. For example, the Windows guest does boot normally, but I have to wait a few minutes to get a fully working network. The same does happen with the Ubuntu guest.

The host is Ubuntu 11.04, and VirtualBox-4.1 is installed from deb packages from www.virtualbox.org.

If this is a different issue, is there a bug report for my issue?

comment:7 Changed 3 years ago by HurdFan

@marcello: I don't think your problem is related to mine, you should check the network settings of your VMs. See  http://www.virtualbox.org/manual/ch06.html

comment:8 Changed 3 years ago by HurdFan

I actually got a bit further on this issue, it seems the driver is probing for SCSI controllers on a *lot* of PCI adresses and this takes very long on VirtualBox.

This could be the fault of the SCSI driver in GNU mach which is in fact an old Linux 2.2 driver, but it could also be a problem with the VirtualBox PCI emulation, I guess.

comment:9 Changed 3 years ago by marcello.nuccio

@HurdFun: I already played with the network settings many times for more than an year.

The reason I think we have the same problem, is that on my guest it takes a few minutes for the network devices to show up.

For example, if on the WindowsXP guest, after boot, I go to Control Panel -> Network Connections, the Network Connections window freezes until the network devices do show up. Everything else continues to work, but every program that accesses the network freezes waiting for the network devices.

comment:10 Changed 3 years ago by HurdFan

Marcello: Have you tried using another host OS? Do you have any unusual network related packages or setup on your host?

Have you tried to ask for advice in the forum, yet? Maybe someone already had the same problem.

If that doesn't help you should open a new ticket for your issue here and/or at the Ubuntu bug tracker if you haven't already done that.

My issue is related to low level problems with a very old SCSI driver and the way VirtualBox emulates the PCI bus, I doubt it is related to what you describe.

comment:11 follow-up: ↓ 12 Changed 3 years ago by sthibaul

"a *lot* of PCI addresses", you mean "probing eata on xx88"? Well, that's only 15 addresses, I would expect hardware virtualization to go faster (and it clearly does with kvm)...

comment:12 in reply to: ↑ 11 Changed 3 years ago by HurdFan

Replying to sthibaul:

"a *lot* of PCI addresses", you mean "probing eata on xx88"? Well, that's only 15 addresses, I would expect hardware virtualization to go faster (and it clearly does with kvm)...

It's not the eata driver, it's the gdth driver that is causing the issue, see my comment above.

comment:13 follow-up: ↓ 14 Changed 3 years ago by sthibaul

Oops, right, sorry, I hadn't read the whole thread again.

I however still find only a few ports being tried in the gdth, in gdth_detect. Is it perhaps the gdth_delay function which waits far too much?

comment:14 in reply to: ↑ 13 Changed 3 years ago by HurdFan

Replying to sthibaul:

Oops, right, sorry, I hadn't read the whole thread again.

I however still find only a few ports being tried in the gdth, in gdth_detect. Is it perhaps the gdth_delay function which waits far too much?

Commenting out the whole body of the gdth_delay function didn't help, any other ideas?

comment:15 follow-up: ↓ 16 Changed 3 years ago by HurdFan

The problem still exists in VirtualBox 4.1.4.

The problem is at this loop:

 http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/linux/src/drivers/scsi/gdth.c#n3112

The gdth_search_pci() function is called with the values 1 to 13 then 256 to about 750, each time it takes a few hundred ms.

Either the loop itself is somehow wrong or the code in the loop is just too slow on VirtualBox.

comment:16 in reply to: ↑ 15 Changed 3 years ago by HurdFan

Replying to HurdFan:

The gdth_search_pci() function is called with the values 1 to 13 then 256 to about 750, each time it takes a few hundred ms.

This is the device parameter, the index parameter is always 0 and the gdth_search_pci() always returns false (as expected).

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use