Delay between USBHUB and setting hostuuid during boot

P

pboehmer

Setting up a new server (Dell PowerEdge R650) and experiencing ~1m30s delay between kernel and userland during boot. UEFI boot/ ZFS mirrored root system over mrsas backed 2 disk jbod. I thought I had seen this issue discussed on the forums, but I am unable to find anything relevant. I believe it may be a USB controller timeout issue (nothing logged as such), but I wanted to see if anyone else is experiencing this and if/how they resolved it.

....
uhub3 numa-domain 0 on uhub1
uhub3: <vendor 0x1604 product 0x10c0, class 9/0, rev 2.00/0.00, addr 5> on usbus0
uhub3: 4 ports with 4 removable, self powered
>>>> 1m30s pause <<<<
Setting hostuuid: 4c4c4544-0032-4410-8046-c6c04f563634.
Setting hostid: 0x363ad8b8.
Starting file system checks:
/dev/gpt/efiboot0: FILESYSTEM CLEAN; SKIPPING CHECKS
...
 
If you look at dmesg, does anything else happen during that pause? Are there any other subsystems (for example disk interfaces) that also have similar timing: partially initialized right before the pause, finish initialization right after?
 
The snippet I posted above is from dmesg -a. There are no additional console messages during the delay. It just hangs for a bit. I will add that this server has a Intel Xeon Silver 4314 w/64 cores and 128G of RAM.
 
What FreeBSD version?

Try a verbose boot (selectable from the loader menu). It will cause the kernel to print more messages and hopefully will give a better idea of what is going on.

Do you observe the same delay if you boot the installer?
 
pboehmer said:
There are no additional console messages during the delay. It just hangs for a bit.
Click to expand...
Well, what is it doing? That's a rhetorical question.

How about this: Do you have a storage device (memory stick, external disk) attached to USB? Maybe the OS is waiting for all block devices to get ready, and there is a slow disk that takes a minute and a half to get ready? This guess is not very plausible, as most disks take 10-20 seconds to spin up at most. But the "minute and a half" you're quoting might very well be a 90 second timeout that's intentional.

Anecdote: Many years ago I was using a server that had ~400 disks attached. When certain things went wrong with its SAS (serial SCSI) configuration, we used to complain that the machine doesn't even boot. Turns out we were wrong: It would eventually boot. What happens was that the BIOS could see each of those 400 disk drives, but none of them would ever spin up (interestingly complex configuration with the disks locked out). And the BIOS waited 5 minutes per disk for it to spin up, and we just didn't wait the required ~2 days for all those timeouts. And then we started a boot on a Friday, and on Monday were amazed that the machine had come up, and that's when we figured it out.
 
Version 14.2-p1.
Verbose boot did not reveal any additional relvant information.
No USB attached devices other than a KVM, and no media configured on it.
4 drive mrsas backed system configured in 2 zfs mirror pools. It is very plausible the controller is waiting for drives to "settle". They are configured as JBOD, but I'll check the controller settings to see if there is anything that would hold things up.

FWIW, this is not a deal breaker or anything. We generally only have to reboot servers on kernel updates, so a 90+sec delay is not "end of the world". I'll just make a note that this server takes a bit to come backup. Was just curious if anyone else had experienced this.
 
You must log in or register to reply here.
Back
Top