Hi, I'm using vanilla Linux 4.14.91 and I've noticed that I get a reoccurring hung task on my machine: --snip-- [ 744.059986] sysrq: SysRq : Show Blocked State [ 744.060108] task PC stack pid father [ 744.060190] kworker/0:1 D 0 371 2 0x80000000 [ 744.060203] Workqueue: kacpid acpi_os_execute_deferred [ 744.060206] Call Trace: [ 744.060219] ? __schedule+0x532/0x574 [ 744.060224] schedule+0x6f/0x80 [ 744.060229] schedule_timeout+0x2d5/0x308 [ 744.060235] ? acpi_ds_create_operand+0x208/0x217 [ 744.060240] ? run_timer_softirq+0xed/0xed [ 744.060245] ? msleep+0x15/0x18 [ 744.060251] ? acpi_ut_release_mutex+0x53/0x56 [ 744.060253] msleep+0x15/0x18 [ 744.060258] acpi_ex_system_do_sleep+0x1e/0x27 [ 744.060262] acpi_ds_exec_end_op+0xc4/0x3cb [ 744.060268] acpi_ps_parse_loop+0x276/0x557 [ 744.060272] ? acpi_ds_do_implicit_return+0x34/0x52 [ 744.060278] acpi_ps_parse_aml+0x8c/0x292 [ 744.060283] acpi_ps_execute_method+0x146/0x17a [ 744.060288] acpi_ns_evaluate+0x1ba/0x247 [ 744.060292] acpi_ev_asynch_execute_gpe_method+0x93/0xfa [ 744.060297] acpi_os_execute_deferred+0x11/0x1b [ 744.060303] process_one_work+0x19d/0x2d6 [ 744.060308] ? apply_wqattrs_commit+0x108/0x108 [ 744.060312] worker_thread+0x1ca/0x29d [ 744.060318] kthread+0x117/0x11f [ 744.060323] ? kthread_create_on_node+0x3a/0x3a [ 744.060328] ret_from_fork+0x35/0x40 --snip-- I've poked around some forums, and for similar types of behavior / call traces, I've read that sometimes these are caused by BIOS bugs. I checked with the vendor, and we are using the latest BIOS release. Looking for any advice on debugging this hung task issue, and if I can prove it's a BIOS bug, would be interested in learning how to do that and provide feedback to the vendor. Looking at the kernel boot messages, this chunk caught my eye: --snip-- [ 0.659212] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored [ 0.677238] ACPI: Dynamic OEM Table Load: [ 0.683878] ACPI: Dynamic OEM Table Load: [ 0.687196] ACPI: Dynamic OEM Table Load: [ 0.736616] ACPI: Interpreter enabled [ 0.736967] ACPI: (supports S0 S5) [ 0.737001] ACPI: Using IOAPIC for interrupt routing [ 0.737376] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug --snip-- Not sure if those could be related to the hung task or not. I have several of the same make/model servers, and they all behave this way. Everyone once in a great while, I can boot one and this task is not hung, but that's pretty rare -- happens most of the time. And I should add, I'm not noticing any real problems, it's just an eye sore seeing the uptime load averages always at "1.0". =) Any help would be greatly appreciated. Thanks, Marc
