Bug 230451 - nanosleep hangs forever
Summary: nanosleep hangs forever
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 11.2-STABLE
Hardware: i386 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-08 09:15 UTC by mail-freebsd
Modified: 2019-06-12 23:49 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mail-freebsd 2018-08-08 09:15:29 UTC 
Summary says it all. Calling nanosleep() or using /bin/sleep will never end waiting, ^C works though. Needless to say this breaks things pretty soon.

This is on a Fujitsu-Siemens thin client with crappy INSYDE BIOS.

CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x5a2  Family = 5  Model = a  Stepping = 2
  Features=0x88a93d<FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX>
  AMD Features=0xc0400000<MMX+,3DNow!+,3DNow!>
acpi0: <INSYDE RSDT_000> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, eeb0000 (3) failed
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x9c10-0x9c13 on acpi0

Linux or other OSes work fine. Where do I start to dig?
Comment 1 Conrad Meyer freebsd_committer freebsd_triage 2018-08-08 15:02:37 UTC 
Please paste output from "grep -i time /var/run/dmesg.boot" on FreeBSD; maybe also 'sysctl kern.timecounter kern.eventtimer'.

If possible, it would be helpful for you to determine which timer Linux chooses on this platform (perhaps it is logged in dmesg or discoverable some other way).
Comment 2 mail-freebsd 2018-08-09 05:20:00 UTC 
kern.timecounter.tick: 1
kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 4294967295
kern.timecounter.tc.i8254.counter: 1803
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.ACPI-fast.counter: 4294967295
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 1000
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 2479337771
kern.timecounter.tc.TSC.frequency: 498054037
kern.timecounter.tc.TSC.quality: 800
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0

Choosing TSC instead of shitty ACPI solved the issue, thanks!
Comment 3 Hans Petter Selasky freebsd_committer freebsd_triage 2019-04-10 18:26:21 UTC 
When sleep hangs, can you show output from:

procstat -ak


--HPS
Comment 4 mail-freebsd 2019-04-13 19:44:29 UTC 
  284 100048 sleep            -                mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep kern_nanosleep nanosleep syscall Xint0x80_syscall