New motherboard and processor, kernel load very slow

J

J.F.L.

Hi,

Until two days ago my bootup times were blazing fast, maybe 2 or 3 seconds between the BIOS screen and the base system starts loading. Then I upgraded the computer (skylake processor and a new z170 asus motherboard) and the kernel load started to do funny things. It now spends like 20 seconds before all the kernel modules are loaded (I can actually see the wheel spinning... slowly). After that everything returns to normal speed and the rest of the system doesn't take more than 3 or 4 seconds to get to the desktop. The hard disk is the same (a ssd sata one). Any clues of why only the kernel is slowed down? Maybe a BIOS setting I've overlooked?

Thanks
 
Does the new machine have more memory? As in a lot more? Just before the kernel loads the memory is checked. If you have more memory the test will take longer. You can turn it off by adding to /boot/loader.conf:
Code: 
hw.memtest.tests="0"
 
Yup, I think "a lot more" is exactly what it has now (from 4 GB to 32 GB :) But it wasn't that, I disabled memory check but the kernel loading time didn't change. Does the loader save information about the disk interface type? I don't know, maybe is a combination of the new motherboard defaulting to AHCI instead of whatever was the default earlier, or something like that.
 
I remember a similar problem where switching some ACPI options in the BIOS helped. Sorry I didn't remember the details.
 
J.F.L. said:
Does the loader save information about the disk interface type?
Click to expand...
No, nothing is "saved" in this respect.

I don't know, maybe is a combination of the new motherboard defaulting to AHCI instead of whatever was the default earlier, or something like that.
Click to expand...
If you have a GENERIC kernel it should detect the most common hardware and because the system does boot I don't think it's a driver issue.
 
I have something along the same alley, but I only switched the disc and file system.
With a "traditional" disc using UFS, loading of modules and kernel was almost instantanious.
With a SSD and ZFS, you can see the /|\-... in each animation step. It does take a lot longer.

All this is also before the kernel starts booting the system, that process is faster than before. But to get there takes more time.
Maybe this is related?
 
FreeBSD uses the traditional INT13h BIOS method (if not using UEFI of course, see below) for accessing the disk from the bootblocks and from loader(8) without any bells or whistles to at least try to ensure maximum compatibility. With ZFS there's a lot more steps to find out which blocks to read for each file (kernel and/or kernel modules) with INT13h than with UFS, that's probably where the slowness comes from at least in part. The other consideration is that all of the newer systems are UEFI by default and the old BIOS functions may be done on the "cheap" so that they work but don't offer any performance.
 
I think some folks may be misunderstanding the issue here. It's not a bit slow, it's extremely slow. And then suddenly, as soon as the BSD kernel kicks in really fast.

So to load a single kernel module, we're talking probably 45 seconds, the spinner is going but very slowly |/-\|/-\. It's 20mins+ to get from BTX loader to when the new console kicks in and then probably less than 5 seconds to the login prompt. At no point is there an error or a pause, it's steady and very slow. Almost like the CPU was clocked down massively.

The INT13h theory sounds plausible, but the system (judging by fans etc, and the general ploddy smoothness) doesn't feel like it's working hard at all. Also, it's slow from the beginning of BTX, before we've got to the ZFS enabled loader.
 
Same problem here, never solved it. I've moved this problem in the "I'll give up/don't care" section of my todo list. I have tried every single combination I can think of: different motherboards with different chipsets, single disk and mirror, AHCI and non-AHCI, MBR and GPT partitioning... nothing. Slow. Always.
The only common factor is that all the chipsets I have tried are NVidia. The only exception is the AMD-based (cpu, gpu and chipset) HP desktop machine that I use at work (with nothing in it made by NVidia) where boot speed is "normal".
 
With "nvidia chipset" I was referring to the motherboard chipset and, consequently, the disk controller.
More precisely, I have tried nForce 5xx and 6xx chipsets and both are painfully slow during boot.
I don't think it's a chipset "bug", because every other OS (Windows, Linux, FreeBSD+UFS) starts instantly.
 
Okay, it's not that then. My board is a Z170. I'm thinking this is a FreeBSD related mystery on certain hardware. Linux / Grub2 does not seem to have this problem.
 
I'll stay tuned for the results of this - this seems promising.

In my case, it is not a delay of minutes, by the way. It's more like 20 seconds, but it is annoying. Even more so when one also uses an old T60 (core1) machine which boots a lot faster :(
 
It doesn't build for me:

Code: 
--- all_subdir_sys ---
/usr/src/sys/boot/efi/loader/../../common/bcache.c:78:1: error: conflicting types for 'bcache_init'
bcache_init(u_int nblks, size_t bsize)
^
/usr/src/sys/boot/efi/loader/../../common/bootstrap.h:75:6: note: previous declaration is here
void  bcache_init(u_int nblks, size_t bsize);
  ^
/usr/src/sys/boot/efi/loader/../../common/bcache.c:111:1: error: no previous prototype for function 'bcache_flush' [-Werror,-Wmissing-prototypes]
bcache_flush(void)
^
/usr/src/sys/boot/efi/loader/../../common/bcache.c:144:68: error: too few arguments to function call, expected 7, have 6
  err = dd->dv_strategy(dd->dv_devdata, rw, blk, size, buf, rsize);
  ~~~~~~~~~~~~~~~  ^
/usr/src/sys/boot/efi/loader/../../common/bcache.c:200:94: error: too few arguments to function call, expected 7, have 6
  result = dd->dv_strategy(dd->dv_devdata, rw, p_blk, p_size * bcache_blksize, p_buf, NULL);
  ~~~~~~~~~~~~~~~  ^
/usr/src/sys/boot/efi/loader/../../common/bcache.c:210:90: error: too few arguments to function call, expected 7, have 6
  result = dd->dv_strategy(dd->dv_devdata, rw, p_blk, p_size * bcache_blksize, p_buf, NULL);
  ~~~~~~~~~~~~~~~  ^
/usr/src/sys/boot/efi/loader/../../common/bcache.c:228:1: error: conflicting types for 'bcache_strategy'
bcache_strategy(void *devdata, int unit, int rw, daddr_t blk, size_t size,
^
/usr/src/sys/boot/efi/loader/../../common/bootstrap.h:79:5: note: previous declaration is here
int  bcache_strategy(void *devdata, int rw, daddr_t blk, size_t offset,
  ^
/usr/src/sys/boot/efi/loader/../../common/bcache.c:245:66: error: too few arguments to function call, expected 7, have 6
  return(dd->dv_strategy(dd->dv_devdata, rw, blk, size, buf, rsize));
  ~~~~~~~~~~~~~~~  ^
7 errors generated.
*** [bcache.o] Error code 1

make[6]: stopped in /usr/src/sys/boot/efi/loader
1 error
 
Still planning to try the patch again with a different -CURRENT when I get some time, but for the record the solution is to go UEFI.

I did this by deleting my swap partition, shrinking it 800k and adding a tiny UEFI partition.
 
You must log in or register to reply here.
Back
Top