Booting Debian GNU/Hurd takes very long

[HurdFan]

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

[Samuel Thibault]

Note: the corresponding source code is available on

​http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/linux/src/drivers/scsi/eata.c#n884

[Frank Mehnert]

Still relevant with VBox 4.0.4?

[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.

[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.

[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?

[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

[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.

[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.

[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.

[Samuel Thibault]

"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)...

[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.

[Samuel Thibault]

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?

[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?

[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.

[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).

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.