Created attachment 286067 [details] log file shutdown Hello all, sorry for my bad English here I am installing an archlinux32bits on an old laptop (Acer Aspire 1680). Everything works startup, reboot, wifi, touchpad etc ... except the shutdown of the pc which is incredibly long. I managed to copy the messages that are displayed before the shutdown of the laptop: INFO: task shutdown:1 blocked for more than 120 seconds. Tainted: G W 4.19.81-1.0-lts #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: __schedule+0x264/0x8e0 schedule+0x2e/0x80 schedule_timeout+0x2a5/0x420 ? acpi_ut_delete_internal_object_list+0x2a/0x2e wait_for_common+0x9e/0x130 ? wake_up_q+0x60/0x60 wait_for_completion+0x17/0x20 flush_workqueue+0xf9/0x3d0 acpi_os_wait_events_complete+0x2b/0x30 acpi_power_off_prepare+Ox1c/0x20 kernel_power_off+040/0x70 sys_reboot+0x104/0x200 ? do_iter_write+0xc2/0x190 ? vfs_wrtiev+0x7d/0xe0 do_fast_syscall_32+0x87/0x1f0 entry_SYSENTER_32+0x6b/0xbe EIP: 0xb7ee2d19 Code: Bad RIP value. EAX: ffffffda EBX: fee1dead ECX: 28121969 EDX: 4321fedc ESI: 00000000 EDI: bfee8c1c EBP: bfee8d18 ESP: bfee8b78 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292 This problem is no longer present by compiling the kernel 3.16.78 (recovered on https://www.kernel.org). I tested the compilations of several kernel 4.x and 5.x but this problem comes back. Do not hesitate to ask log or other files to try to allow me to understand where the problem lies. I performed a debug of the system shutdown by following the instructions of https://freedesktop.org/wiki/Software/systemd/Debugging/#Diagnosing_Shutdown_Problems and i attach the result file.
Hello everyone, there is no one who could help me? It would be really nice if a charitable soul could give me a hand.
Hi all, I add this information if it can help solve my problem: kernel 4.19.86-1.0-lts : dmesg | grep acpi : [ 0.341496] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.404617] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 1) [ 0.406857] acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI] [ 0.406866] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM [ 0.406871] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. [ 0.407749] acpi PNP0A03:00: host bridge window [io 0x0000-0x0cf7 window] (ignored) [ 0.407751] acpi PNP0A03:00: host bridge window [io 0x0cf8-0x0cff] (ignored) [ 0.407754] acpi PNP0A03:00: host bridge window [io 0x0d00-0xffff window] (ignored) [ 0.407757] acpi PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff window] (ignored) [ 0.407759] acpi PNP0A03:00: host bridge window [mem 0x000d4000-0x000d7fff window] (ignored) [ 0.407761] acpi PNP0A03:00: host bridge window [mem 0x000d8000-0x000dbfff window] (ignored) [ 0.407764] acpi PNP0A03:00: host bridge window [mem 0x80000000-0xfebfffff window] (ignored) [ 0.484157] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns [ 1.167790] clocksource: Switched to clocksource acpi_pm [ 13.487942] Modules linked in: b44(+) cfg80211 ssb mmc_core rfkill snd_intel8x0 yenta_socket snd_intel8x0m pcmcia_rsrc mii snd_ac97_codec libphy ac97_bus pcmcia snd_pcm pcmcia_core evdev mac_hid sbs(+) snd_timer snd sbshc lpc_ich soundcore rng_core intel_agp intel_gtt i2c_i801 pcc_cpufreq acpi_cpufreq sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic pata_acpi ata_piix libata uhci_hcd serio_raw firewire_ohci atkbd libps2 scsi_mod ehci_pci tifm_7xx1 firewire_core tifm_core crc_itu_t ehci_hcd i8042 serio radeon i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart [ 17.916855] audit: type=1130 audit(1576081456.639:17): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=acpid comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' kernel 3.18.99: dmesg | grep acpi: [ 0.032785] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.173354] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 1) [ 0.174701] acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI] [ 0.174708] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM [ 0.175519] acpi PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored) [ 0.175523] acpi PNP0A03:00: host bridge window [io 0x0d00-0xffff] (ignored) [ 0.175526] acpi PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored) [ 0.175530] acpi PNP0A03:00: host bridge window [mem 0x000d4000-0x000d7fff] (ignored) [ 0.175534] acpi PNP0A03:00: host bridge window [mem 0x000d8000-0x000dbfff] (ignored) [ 0.175538] acpi PNP0A03:00: host bridge window [mem 0x80000000-0xfebfffff] (ignored) [ 0.175545] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. [ 0.227340] Switched to clocksource acpi_pm [ 9.594331] ACPI: acpi_idle registered with cpuidle [ 9.600027] Switched to clocksource acpi_pm [ 15.884371] audit: type=1130 audit(1576081843.331:15): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=acpid comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
(In reply to Pask from comment #2) > Hi all, > I add this information if it can help solve my problem: > > > > kernel 4.19.86-1.0-lts : > dmesg | grep acpi : > > > [ 0.341496] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [ 0.404617] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 1) > [ 0.406857] acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI] > [ 0.406866] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM > [ 0.406871] acpi PNP0A03:00: fail to add MMCONFIG information, can't > access extended PCI configuration space under this bridge. > [ 0.407749] acpi PNP0A03:00: host bridge window [io 0x0000-0x0cf7 > window] (ignored) > [ 0.407751] acpi PNP0A03:00: host bridge window [io 0x0cf8-0x0cff] > (ignored) > [ 0.407754] acpi PNP0A03:00: host bridge window [io 0x0d00-0xffff > window] (ignored) > [ 0.407757] acpi PNP0A03:00: host bridge window [mem > 0x000a0000-0x000bffff window] (ignored) > [ 0.407759] acpi PNP0A03:00: host bridge window [mem > 0x000d4000-0x000d7fff window] (ignored) > [ 0.407761] acpi PNP0A03:00: host bridge window [mem > 0x000d8000-0x000dbfff window] (ignored) > [ 0.407764] acpi PNP0A03:00: host bridge window [mem > 0x80000000-0xfebfffff window] (ignored) > [ 0.484157] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, > max_idle_ns: 2085701024 ns > [ 1.167790] clocksource: Switched to clocksource acpi_pm > [ 13.487942] Modules linked in: b44(+) cfg80211 ssb mmc_core rfkill > snd_intel8x0 yenta_socket snd_intel8x0m pcmcia_rsrc mii snd_ac97_codec > libphy ac97_bus pcmcia snd_pcm pcmcia_core evdev mac_hid sbs(+) snd_timer > snd sbshc lpc_ich soundcore rng_core intel_agp intel_gtt i2c_i801 > pcc_cpufreq acpi_cpufreq sg crypto_user ip_tables x_tables ext4 > crc32c_generic crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic pata_acpi > ata_piix libata uhci_hcd serio_raw firewire_ohci atkbd libps2 scsi_mod > ehci_pci tifm_7xx1 firewire_core tifm_core crc_itu_t ehci_hcd i8042 serio > radeon i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt > fb_sys_fops ttm drm agpgart seems that there is already something bad happens during startup? please attach the full dmesg after boot
(In reply to Zhang Rui from comment #3) Thanks for answering me, what is the command to display the full dsmeg? Is it just dsmeg or do I need to add a specific option? Thank you in advance.
just run "dmesg > dmesg.out" after boot, and attach the dmesg.out here.
Ok, I attach the dmesg.out file to you. I also wish you a happy new year
Created attachment 286569 [details] dmesg
(In reply to Pask from comment #0) > > This problem is no longer present by compiling the kernel 3.16.78 (recovered > on https://www.kernel.org). I tested the compilations of several kernel 4.x > and 5.x but this problem comes back. > so this seems like a kernel regression? following is part of the debug trace in your boot dmesg, let's make clear if the trace log is related with the shutdown issue or not first. [ 12.638326] ------------[ cut here ]------------ [ 12.638389] WARNING: CPU: 0 PID: 210 at drivers/ssb/driver_gpio.c:464 ssb_gpio_init.cold+0xa/0x15 [ssb] [ 12.638390] Modules linked in: snd_intel8x0(+) input_leds snd_intel8x0m(+) psmouse b44(+) ssb cfg80211 snd_ac97_codec mmc_core ac97_bus snd_pcm mii yenta_socket libphy rfkill pcmcia_rsrc snd_timer pcmcia pcmcia_core snd sbs(+) soundcore evdev sbshc lpc_ich mac_hid intel_agp intel_gtt rng_core i2c_i801 pcc_cpufreq acpi_cpufreq sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic pata_acpi ata_piix firewire_ohci serio_raw atkbd libps2 uhci_hcd libata tifm_7xx1 ehci_pci firewire_core scsi_mod tifm_core crc_itu_t ehci_hcd i8042 serio radeon i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart [ 12.638434] CPU: 0 PID: 210 Comm: systemd-udevd Not tainted 4.19.91-1.0-lts #1 [ 12.638435] Hardware name: Acer Aspire 1680 /Aspire 1680 , BIOS 3A10 10/12/2004 [ 12.638443] EIP: ssb_gpio_init.cold+0xa/0x15 [ssb] [ 12.638446] Code: f7 e8 b1 36 c5 d5 0f 0b 58 e9 b9 ed ff ff 68 64 39 e7 f7 e8 9f 36 c5 d5 0f 0b 5a e9 21 ec ff ff 68 8c 39 e7 f7 e8 8d 36 c5 d5 <0f> 0b 58 83 c8 ff e9 c8 f1 ff ff 68 8c 39 e7 f7 e8 78 36 c5 d5 0f [ 12.638448] EAX: 00000024 EBX: f61d9000 ECX: f6ff0a80 EDX: f6fe9d10 [ 12.638450] ESI: f7e74c68 EDI: f61d9000 EBP: f5b9bc7c ESP: f5b9bc78 [ 12.638452] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246 [ 12.638454] CR0: 80050033 CR2: b640d008 CR3: 35b84000 CR4: 000006d0 [ 12.638455] Call Trace: [ 12.638467] ssb_attach_queued_buses+0xe2/0x310 [ssb] [ 12.638473] ssb_bus_register+0x179/0x1d0 [ssb] [ 12.638479] ? ssb_pci_xtal+0x1d0/0x1d0 [ssb] [ 12.638486] ssb_bus_pcibus_register+0x29/0x80 [ssb] [ 12.638492] ssb_pcihost_probe+0xb7/0x110 [ssb] [ 12.638498] pci_device_probe+0xd4/0x160 [ 12.638504] really_probe+0x206/0x360 [ 12.638507] driver_probe_device+0xd9/0x130 [ 12.638510] __driver_attach+0xd9/0x100 [ 12.638513] ? driver_probe_device+0x130/0x130 So can you please confirm if the debug trace always happens in bad kernel, and does not happen in good kernel? Say, back to 3.26.78, which shutdown works, does the log still exists? and does the shutdown problem/trace log still happen in the latest upstream kernel?
- "so this seems like a kernel regression?" Somehow or, at least I tried to understand where this problem came from so I tried to compile an earlier kernel lts 3.16.78, but I had to change to 3.18.99 because some software had memfd functionality requirements. - "following is part of the debug trace in your boot dmesg, let's make clear if the trace log is related with the shutdown issue or not first." How do you proceed? - "So can you please confirm if the debug trace always happens in bad kernel, and does not happen in good kernel? Say, back to 3.26.78, which shutdown works, does the log still exists? and does the shutdown problem/trace log still happen in the latest upstream kernel?" I confirm that the problem only occurs when the kernel lts 4.19.xx and even earlier as well as the kernel 5.x. This problem does not occur with 3.x kernels. The debug message: INFO: task shutdown:1 blocked for more than 120 seconds. Tainted: G W 4.19.81-1.0-lts #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: __schedule+0x264/0x8e0 schedule+0x2e/0x80 schedule_timeout+0x2a5/0x420 ? acpi_ut_delete_internal_object_list+0x2a/0x2e wait_for_common+0x9e/0x130 ? wake_up_q+0x60/0x60 wait_for_completion+0x17/0x20 flush_workqueue+0xf9/0x3d0 acpi_os_wait_events_complete+0x2b/0x30 acpi_power_off_prepare+Ox1c/0x20 kernel_power_off+040/0x70 sys_reboot+0x104/0x200 ? do_iter_write+0xc2/0x190 ? vfs_wrtiev+0x7d/0xe0 do_fast_syscall_32+0x87/0x1f0 entry_SYSENTER_32+0x6b/0xbe EIP: 0xb7ee2d19 Code: Bad RIP value. EAX: ffffffda EBX: fee1dead ECX: 28121969 EDX: 4321fedc ESI: 00000000 EDI: bfee8c1c EBP: bfee8d18 ESP: bfee8b78 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292 this message only occurs during shutdown. It repeats itself 2 3 or even 4 times before the laptop turns off. This problem does not arise if I request a restart only the shutdown. I noticed something else, it's the power button. In the power supply parameters I selected "on demand" for the power button, but when I press it the time for the dialog window to appear is also very long. While under kernel 3.18.99 this is done normally. I reconfirm that this problem does not occur with the kernel 3.18.99
Created attachment 286583 [details] dmesg kernel 3.18.99 to compare I attach the dmesg output of the kernel 3.18.99
(In reply to Pask from comment #9) > - "so this seems like a kernel regression?" > > Somehow or, at least I tried to understand where this problem came from so I > tried to compile an earlier kernel lts 3.16.78, but I had to change to > 3.18.99 because some software had memfd functionality requirements. > So the problem does not exist in 3.18.99. > > - "following is part of the debug trace in your boot dmesg, let's make clear > if the trace log is related with the shutdown issue or not first." > > How do you proceed? boot into any good/bad kernel, check if the boot trace log exists or not, shutdown and check if the shutdown problem exists or not. > > > - "So can you please confirm if the debug trace always happens in bad > kernel, and does not happen in good kernel? Say, back to 3.26.78, which > shutdown works, does the log still exists? and does the shutdown > problem/trace log still happen in the latest upstream kernel?" > > I confirm that the problem only occurs when the kernel lts 4.19.xx and even > earlier as well as the kernel 5.x. > > This problem does not occur with 3.x kernels. So the boot trace log is probably related with the shutdown issue, right? Then please rebuild your 4.x and 5.x kernel with CONFIG_SSB cleared, and check a) if the boot trace log still exists b) if the shutdown issue still exists > > The debug message: > > INFO: task shutdown:1 blocked for more than 120 seconds. > Tainted: G W 4.19.81-1.0-lts #1 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Call Trace: > __schedule+0x264/0x8e0 > schedule+0x2e/0x80 > schedule_timeout+0x2a5/0x420 > ? acpi_ut_delete_internal_object_list+0x2a/0x2e > wait_for_common+0x9e/0x130 > ? wake_up_q+0x60/0x60 > wait_for_completion+0x17/0x20 > flush_workqueue+0xf9/0x3d0 > acpi_os_wait_events_complete+0x2b/0x30 > acpi_power_off_prepare+Ox1c/0x20 > kernel_power_off+040/0x70 > sys_reboot+0x104/0x200 > ? do_iter_write+0xc2/0x190 > ? vfs_wrtiev+0x7d/0xe0 > do_fast_syscall_32+0x87/0x1f0 > entry_SYSENTER_32+0x6b/0xbe > EIP: 0xb7ee2d19 > Code: Bad RIP value. > EAX: ffffffda EBX: fee1dead ECX: 28121969 EDX: 4321fedc > ESI: 00000000 EDI: bfee8c1c EBP: bfee8d18 ESP: bfee8b78 > DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292 > > this message only occurs during shutdown. It repeats itself 2 3 or even 4 > times before the laptop turns off. This problem does not arise if I request > a restart only the shutdown. I noticed something else, it's the power > button. In the power supply parameters I selected "on demand" for the power > button, what do you mean by "power supply parameters"? > but when I press it the time for the dialog window to appear is also > very long. While under kernel 3.18.99 this is done normally. > I reconfirm that this problem does not occur with the kernel 3.18.99 please attach the output of "cat /proc/interrupts" and "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the power button, in both good and bad kernels.
Created attachment 286601 [details] "cat /proc/interrupts" and "grep . /sys/firmware/acpi/interrupts/*" Here is the result of the commands you asked me for.
(In reply to Zhang Rui from comment #11) > So the problem does not exist in 3.18.99. actually this problem does not appear with this kernel. > > > > - "following is part of the debug trace in your boot dmesg, let's make > clear > > if the trace log is related with the shutdown issue or not first." > > > > How do you proceed? > > boot into any good/bad kernel, check if the boot trace log exists or not, > shutdown and check if the shutdown problem exists or not. With what command can i do this log trace search? Or when to see the trace log? > So the boot trace log is probably related with the shutdown issue, right? This i do not know... but the problem appears just to shutdown no to reboot > Then please rebuild your 4.x and 5.x kernel with CONFIG_SSB cleared, and > check > a) if the boot trace log still exists > b) if the shutdown issue still exists how should i proceed for cleared CONFIG_SSB because i can't do it with make menuconfig. does the SSB match well to a Sonics Silicon Backplane? > what do you mean by "power supply parameters"? Power settings is present in the xfce desktop settings. There are several options which can be configured as the action of the power button or what it does when the hood is closed, etc. For the action of the power button I indicate "on demand" this opens the window where you can choose to turn off or reboot or close the session or hibernate etc ...
In 3.18.99 before: /sys/firmware/acpi/interrupts/sci: 3824 after: /sys/firmware/acpi/interrupts/sci: 4358 in 4.19.91 before: /sys/firmware/acpi/interrupts/sci: 21967 after: /sys/firmware/acpi/interrupts/sci: 26918 are you sure you got the "before" number right before pressing the power button and the "after" number right after pressing the power button? if yes, then this suggests that we're getting much more ACPI interrupts in the later kernel, and this interrupt storm can cause the system slow to respond to anything.
(In reply to Zhang Rui from comment #14) > In 3.18.99 > before: /sys/firmware/acpi/interrupts/sci: 3824 > after: /sys/firmware/acpi/interrupts/sci: 4358 > > in 4.19.91 > before: /sys/firmware/acpi/interrupts/sci: 21967 > after: /sys/firmware/acpi/interrupts/sci: 26918 > > are you sure you got the "before" number right before pressing the power > button and the "after" number right after pressing the power button? Yes i am sure to have executed the commands before and after pressing the power button for the two kernel. > if yes, then this suggests that we're getting much more ACPI interrupts in > the later kernel, and this interrupt storm can cause the system slow to > respond to anything. Do you think there is a solution to overcome this problem?
up
Please attach the acpidump output. please confirm if the problem exist or not in the latest upstream kernel, say, 5.7 or 5.8-rc
Bug closed as there is no response from the bug reporter. Please feel free to re-open it if you can provide the information required in comment #18
(In reply to Zhang Rui from comment #19) > Bug closed as there is no response from the bug reporter. > Please feel free to re-open it if you can provide the information required > in comment #18 Hello, I am sorry for the long time of my absence. I come back to you with new leads. I had to give up using the 3.18.99 kernel because it was preventing the system from working because it was too old. Now the system uses the 5.15.3 kernel (which I compiled). But the problem persists and it would appear randomly and the error message has changed: INFO: task shutdown:1 blocked for more than 120 seconds. Not tainted 5.15.3Pask00 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. This message runs just as the number of seconds changes and the machine stops after 4 or 5 repetitions of the error message. However I discovered that by blacklisting the SBS module the machine stops normally and the call by the stop button responds perfectly because with the SBS module activated I noticed that from time to time the machine behaves normally (stop ok, power button responds normally) except when I unplug the power cord the problem occurs and it also occurs randomly when starting the machine (it's even more problematic than without). But by blacklisting the SBS module other problem appears: the state of the battery is no longer accessible and the restart has the same problem. I do not know if it is the SBS module that is the culprit or if it is a problem with the information of the state of the battery or some other problem because I do not know how to debug this kind of problem. Charitable help would be welcome to try to resolve this problem. Thanks in advance.
Sorry but how can I get acpidump output. I do not know how to go about obtaining this information.(In reply to Pask from comment #20) > (In reply to Zhang Rui from comment #19) > > Bug closed as there is no response from the bug reporter. > > Please feel free to re-open it if you can provide the information required > > in comment #18 > > Hello, I am sorry for the long time of my absence. > I come back to you with new leads. > I had to give up using the 3.18.99 kernel because it was preventing the > system from working because it was too old. > > Now the system uses the 5.15.3 kernel (which I compiled). > But the problem persists and it would appear randomly and the error message > has changed: > > INFO: task shutdown:1 blocked for more than 120 seconds. > Not tainted 5.15.3Pask00 #1 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this > message. > This message runs just as the number of seconds changes and the machine > stops after 4 or 5 repetitions of the error message. > > However I discovered that by blacklisting the SBS module the machine stops > normally and the call by the stop button responds perfectly because with the > SBS module activated I noticed that from time to time the machine behaves > normally (stop ok, power button responds normally) except when I unplug the > power cord the problem occurs and it also occurs randomly when starting the > machine (it's even more problematic than without). > > But by blacklisting the SBS module other problem appears: > the state of the battery is no longer accessible and the restart has the > same problem. > > I do not know if it is the SBS module that is the culprit or if it is a > problem with the information of the state of the battery or some other > problem because I do not know how to debug this kind of problem. > Charitable help would be welcome to try to resolve this problem. > Thanks in advance. Sorry but how can I get acpidump output. I do not know how to go about obtaining this information.
Ok i'm use this command for acpidump : acpidump -b It's correctly?? I am attaching you the output files of this command. Cordially.
Created attachment 299699 [details] acpidump
(In reply to Zhang Rui from comment #19) > Bug closed as there is no response from the bug reporter. > Please feel free to re-open it if you can provide the information required > in comment #18 Hello, I'm not really sure, but I think the very slow shutdown problem is caused by SBS. Indeed when I blacklist this module everything works perfectly and the laptop is more responsive. However by carrying out this manipulation I lose the status of the battery. I don't really know where the problem is. How to debug such information to find out where the problem is in order to correct it? I really need help in order to achieve this and in the future to better understand this kind of problem. Thank in advence.
Then please do the same test and give the output of "cat /proc/interrupts" and "grep . /sys/firmware/acpi/interrupts/*" in your latest kernel, both with and without SBS module loaded. It may also be an interrupt storm caused by the SBS.
Created attachment 301309 [details] results "cat /proc/interrupts" and "grep . /sys/firmware/acpi/interrupts/*" hello, I would like to thank you for taking the time to answer me and to look into my problem. I am attaching the results of the commands you request from me. Big thanks for you.
Created attachment 301310 [details] result hello, I would like to thank you for taking the time to answer me and to look into my problem. I am attaching the results of the commands you request from me. Big thanks for you.
Created attachment 301311 [details] results hello, I would like to thank you for taking the time to answer me and to look into my problem. I am attaching the results of the commands you request from me. Big thanks for you.
Created attachment 301312 [details] results hello, I would like to thank you for taking the time to answer me and to look into my problem. I am attaching the results of the commands you request from me. Big thanks for you.
sorry for the repetition of the messages but I could not add several files in attachment really sorry
According to the dmesg output, the "sbs" module is loaded. I had the same problem on my Acer Travelmate 4002 WLMi, with suspend and shutdown stalling due to the acpi notification workqueue failing to flush. The culprit was the sbs module mishandling certain hardware configurations, causing the acpi notification workqueue to get spammed with work items. Does the issue remain when you unload the sbs module? If yes, then the issue will likely get fixed in kernel 6.4.
(In reply to Armin Wolf from comment #33) > According to the dmesg output, the "sbs" module is loaded. I had the same > problem on my Acer Travelmate 4002 WLMi, with suspend and shutdown stalling > due to the acpi notification workqueue failing to flush. > > The culprit was the sbs module mishandling certain hardware configurations, > causing the acpi notification workqueue to get spammed with work items. > > Does the issue remain when you unload the sbs module? If yes, then the issue > will likely get fixed in kernel 6.4. I overlooked that you already blacklisted the sbs module to solve the problem. In this case, kernel 6.4 will likely solve this issue, the necessary fixes are already inside the linux-pm git tree.