Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.
-
Catchpole
- Level 4
- Posts: 338
- Joined: Sat Dec 24, 2011 4:15 am
- Location: Leeds UK
ACPI BIOS Error (bug): [SOLVED]
When I start up my Desktop with Linux Mint 20.1 I get these messages:
Is this just a bug which will go away after some future update?
What is it looking for?
dmesg gives:
[ 1.011765] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.011788] fbcon: Taking over console
[ 1.011792] No Local Variables are initialized for Method [_GTF]
[ 1.011792] No Arguments are initialized for method [_GTF]
[ 1.011794] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT4._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
[ 1.011802] ata5.00: ATAPI: TSSTcorp CDDVDW SH-S223B, SB01, max UDMA/100
[ 1.011855] Console: switching to colour frame buffer device 128×48
[ 1.012200] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.012208] No Local Variables are initialized for Method [_GTF]
[ 1.012209] No Arguments are initialized for method [_GTF]
[ 1.012211] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT1._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
[ 1.012424] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.012430] No Local Variables are initialized for Method [_GTF]
[ 1.012431] No Arguments are initialized for method [_GTF]
[ 1.012432] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT0._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
[ 1.012441] ata2.00: ATA-8: ST500DM002-1BD142, KC45, max UDMA/133
[ 1.012443] ata2.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 32)
[ 1.012533] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT4._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.012539] No Local Variables are initialized for Method [_GTF]
[ 1.012540] No Arguments are initialized for method [_GTF]
[ 1.012541] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT4._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
[ 1.012549] ata5.00: configured for UDMA/100
[ 1.013829] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.013892] No Local Variables are initialized for Method [_GTF]
[ 1.013893] No Arguments are initialized for method [_GTF]
[ 1.013894] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT1._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
[ 1.014219] ata2.00: configured for UDMA/133
[ 1.015831] ata1.00: ATA-10: CT480BX500SSD1, M6CR022, max UDMA/133
[ 1.015833] ata1.00: 937703088 sectors, multi 1: LBA48 NCQ (depth 32), AA
[ 1.021653] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.021695] No Local Variables are initialized for Method [_GTF]
[ 1.021696] No Arguments are initialized for method [_GTF]
[ 1.021698] ACPI Error: Aborting method _SB.PCI0.SAT0.SPT0._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
Has this got anything to do with it?
Its a warning before the Error but not flagged up on the screen on startup;
[ 0.639660] r8169 0000:04:00.0: can’t disable ASPM; OS doesn’t have ASPM control
[ 0.641211] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (PMIO) (20190816/utaddress-204)
[ 0.641217] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 0.641220] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (GPIO) (20190816/utaddress-204)
[ 0.641223] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 0.641224] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (GPIO) (20190816/utaddress-204)
[ 0.641228] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 0.641229] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000051F (LED) (20190816/utaddress-204)
[ 0.641233] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (GPIO) (20190816/utaddress-204)
[ 0.641237] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 0.641237] lpc_ich: Resource conflict(s) found affecting gpio_ich
[ 0.642074] libphy: r8169: probed
[ 0.642085] i801_smbus 0000:00:1f.3: enabling device (0001 -> 0003)
[ 0.642219] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
[ 0.642370] r8169 0000:04:00.0 eth0: RTL8168evl/8111evl, 94
[ 0.642372] r8169 0000:04:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 0.659537] ahci 0000:00:1f.2: version 3.0
80:57:80:e8, XID 2c9, IRQ 29My system details:
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Graphics card = nvidia GEFORCE 210
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa Mate desktop» (64bit)
Memory = 12GB
What is it and what do I need to do?
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa «Mate desktop» (64bit)
Memory = 12GB
-
Catchpole
- Level 4
- Posts: 338
- Joined: Sat Dec 24, 2011 4:15 am
- Location: Leeds UK
Re: ACPI BIOS Error (bug):
Post
by Catchpole » Wed Feb 24, 2021 3:24 am
Hi SimpleLinuxUser,
I forgot to mention that everything is working OK.
However the startup is delayed whilst it deals with the fault so I’d like a solution to speed things up.
Being an engineer I pay attention to details and this «bug» is bugging me. I like things to be neat and tidy.
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa «Mate desktop» (64bit)
Memory = 12GB
-
t42
- Level 9
- Posts: 2539
- Joined: Mon Jan 20, 2014 6:48 pm
Re: ACPI BIOS Error (bug):
Post
by t42 » Wed Feb 24, 2021 3:29 am
Catchpole wrote: ↑
Wed Feb 24, 2021 3:24 am
However the startup is delayed whilst it deals with the fault so I’d like a solution to speed things up.
Being an engineer I pay attention to details.
«However the startup is delayed» — how much?
Did you check a possibility of the motherboard BIOS update?
-=t42=-
-
Catchpole
- Level 4
- Posts: 338
- Joined: Sat Dec 24, 2011 4:15 am
- Location: Leeds UK
Re: ACPI BIOS Error (bug):
Post
by Catchpole » Wed Feb 24, 2021 4:51 am
Hi t42,
I’ll have to time the delay. Timing it on the screen is easy enough but the total delay will be harder to measure.
Did you check a possibility of the motherboard BIOS update?
I don’t know if I dare do a bios update but It’s a thought. If anything goes wrong I can upgrade the board with a new one. 
What problems would I have upgrading the motherboard (MB) with respect to the operating system? I wouldn’t want to have to do another clean install when I’ve just done it recently!
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa «Mate desktop» (64bit)
Memory = 12GB
-
t42
- Level 9
- Posts: 2539
- Joined: Mon Jan 20, 2014 6:48 pm
Re: ACPI BIOS Error (bug):
Post
by t42 » Wed Feb 24, 2021 5:16 am
Catchpole wrote: ↑
Wed Feb 24, 2021 4:51 am
I’ll have to time the delay. Timing it on the screen is easy enough but the total delay will be harder to measure.
These three commands may help
Code: Select all
systemd-analyze
systemd-analyze critical-chain
systemd-analyze blameCatchpole wrote: ↑
Wed Feb 24, 2021 4:51 am
What problems would I have upgrading the motherboard (MB) with respect to the operating system?
BIOS update can mess with computer on the far low level than OS. Usually motherboard is unbootable if something goes wrong and you need to prepare procedure to revert to the previews firmware.
-=t42=-
-
AndyMH
- Level 20
- Posts: 11043
- Joined: Fri Mar 04, 2016 5:23 pm
- Location: Wiltshire
Re: ACPI BIOS Error (bug):
Post
by AndyMH » Wed Feb 24, 2021 5:21 am
Homebrew i5-8400+GTX1080 Cinnamon 19.0, 4 x Thinkpad T430 Cinnamon 20.1, 2 x i7-3632 , i5-3320, i5-3210, Thinkpad T60 19.0 Mate
-
Catchpole
- Level 4
- Posts: 338
- Joined: Sat Dec 24, 2011 4:15 am
- Location: Leeds UK
Re: ACPI BIOS Error (bug):
Post
by Catchpole » Wed Feb 24, 2021 7:42 am
Hi t42,
The results of your commands are:
Code: Select all
user@computer:~$ systemd-analyze
Startup finished in 3.454s (kernel) + 3.083s (userspace) = 6.537s
graphical.target reached after 3.049s in userspace
user@computer:~$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @3.049s
└─multi-user.target @3.049s
└─networkd-dispatcher.service @2.310s +738ms
└─basic.target @2.263s
└─sockets.target @2.263s
└─uuidd.socket @2.263s
└─sysinit.target @2.260s
└─apparmor.service @2.055s +97ms
└─local-fs.target @2.054s
└─boot-efi.mount @2.040s +13ms
└─systemd-fsck@dev-disk-byx2duuid-9934x2d6DD8.service @1.781s +258ms
└─dev-disk-byx2duuid-9934x2d6DD8.device @1.780s
user@computer:~$ systemd-analyze blame
1.811s apt-daily-upgrade.service
1.434s dev-sda2.device
738ms networkd-dispatcher.service
563ms udisks2.service
374ms accounts-daemon.service
306ms ubuntu-system-adjustments.service
304ms systemd-journal-flush.service
258ms systemd-fsck@dev-disk-byx2duuid-9934x2d6DD8.service
248ms avahi-daemon.service
237ms NetworkManager.service
230ms ufw.service
229ms systemd-logind.service
225ms upower.service
223ms polkit.service
222ms ModemManager.service
205ms keyboard-setup.service
190ms gpu-manager.service
183ms thermald.service
182ms e2scrub_reap.service
177ms systemd-journald.service
175ms wpa_supplicant.service
166ms systemd-udevd.service
158ms systemd-modules-load.service
152ms systemd-udev-trigger.service
151ms systemd-resolved.service
It seems to be just a matter of mili-seconds delay to the overall progress.
So after reading the link from AndyMH, I think I’ll just leave it as it is and avoid making a mistake in the pursuit of a triviality that makes things worse.
The result of the inquiry is: leave it alone. I think that means [SOLVED]. (Or does it?)
I’ll mark it as [SOLVED]
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa «Mate desktop» (64bit)
Memory = 12GB
-
Catchpole
- Level 4
- Posts: 338
- Joined: Sat Dec 24, 2011 4:15 am
- Location: Leeds UK
Re: ACPI BIOS Error (bug): [SOLVED]
Post
by Catchpole » Sat Feb 27, 2021 8:36 am
Hi t42,
Catchpole wrote: ↑
Wed Feb 24, 2021 9:51 am
I’ll have to time the delay. Timing it on the screen is easy enough but the total delay will be harder to measure.
As I didn’t time the startup when the system was working OK I can only make a guess as to the total delay.
However, when I switched the computer on I used to do a couple of things and by the time I had finished them it was jut the right time to sign in.
So from the time of switching on and after doing the same couple of things, the total time delay now is about 20 second later to get to the sign in screen.
As for the bios upgrade:
There is only one upgrade from the «F1» bios version to version «F3c» but its a «beta».
F3c
2.85 MB
2014/03/04
DownloadBeta BIOS
Improve High-End Display card compatibility==============================================
F2
2.82 MB
2013/03/19
DownloadFirst Release
So unfortunately there is still a problem and I was a little hasty accepting the data from the error log and in adding the [SOLVED] marker!
You live and learn.
I’ve set «ACHI» and UEFI, turned off «Secure Boot» and made sure «CSM» is disabled.
If I’ve done all I can with the bios I guess I’ll have to live with it or get a new motherboard. (unless there’s another solution)
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa «Mate desktop» (64bit)
Memory = 12GB
-
Catchpole
- Level 4
- Posts: 338
- Joined: Sat Dec 24, 2011 4:15 am
- Location: Leeds UK
Re: ACPI BIOS Error (bug): [SOLVED]
Post
by Catchpole » Sun Feb 28, 2021 8:54 am
A re-run of the commands suggested by: t42
Code: Select all
systemd-analyze
systemd-analyze critical-chain
systemd-analyze blamegives:
Code: Select all
28th Feb 2021 11:39hrs
user@computer:~$ systemd-analyze
Startup finished in 3.302s (kernel) + 35.977s (userspace) = 39.279s
graphical.target reached after 28.153s in userspace
user@computer:~$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @28.153s
└─multi-user.target @28.153s
└─postfix.service @28.146s +6ms
└─postfix@-.service @24.114s +4.029s
└─network-online.target @24.107s
└─NetworkManager-wait-online.service @17.438s +6.668s
└─NetworkManager.service @17.169s +266ms
└─dbus.service @17.165s
└─basic.target @17.147s
└─sockets.target @17.147s
└─uuidd.socket @17.147s
└─sysinit.target @17.143s
└─apparmor.service @17.030s +112ms
└─local-fs.target @17.029s
└─run-user-1000-gvfs.mount @35.402s
└─run-user-1000.mount @32.935s
└─swap.target @524ms
└─swapfile.swap @391ms +133ms
└─systemd-remount-fs.service @361ms +28ms
└─systemd-journald.socket @343ms
user@computer:~$ systemd-analyze blame
18.731s fstrim.service
16.606s dev-sda2.device
6.668s NetworkManager-wait-online.service
4.029s postfix@-.service
1.056s man-db.service
925ms networkd-dispatcher.service
757ms udisks2.service
538ms logrotate.service
511ms apt-daily-upgrade.service
485ms ubuntu-system-adjustments.service
482ms apt-daily.service
451ms systemd-logind.service
449ms accounts-daemon.service
349ms systemd-journal-flush.service
323ms networking.service
290ms ModemManager.service
266ms NetworkManager.service
260ms fwupd-refresh.service
245ms avahi-daemon.service
238ms polkit.service
237ms systemd-resolved.service
228ms ufw.service
214ms upower.service
This gives much longer delay than when it was first run.
I can’t understand why it didn’t pick up the time delay in the first instance.
Does the fstrim.service take 18 seconds to complete?
I’ve done some reading around but can’t find a solution.
Can anyone point me in the right direction?
Last edited by Catchpole on Mon Mar 01, 2021 3:23 am, edited 1 time in total.
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa «Mate desktop» (64bit)
Memory = 12GB
-
Catchpole
- Level 4
- Posts: 338
- Joined: Sat Dec 24, 2011 4:15 am
- Location: Leeds UK
Re: ACPI BIOS Error (bug): [SOLVED]
Post
by Catchpole » Sun Feb 28, 2021 10:17 am
I’ve found the cause of the problem at last!!
It was my graphics card — nvidia GEFORCE 210 That was causing the conflict.
Using the «Driver Manager» I changed the driver from the «recommended» proprietary driver to the Ubuntu one offered instead.
Now its back to its normal speed that I had before with the Mint 19.1 Operating System.
Perhaps Mint 20.1 will catch up with some future updates in the near future.
Thanks to everyone for your help.
Desktop Computer:
Motherboard = Gigabyte GA-H61M-USB3V
CPU = Intel i3-3240 3.4GHz
Monitor = BENQ BL2411PT rev 00-012-AL
Mint 20.1 Ulyssa «Mate desktop» (64bit)
Memory = 12GB
Как правильно задавать вопросы
Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Для начала воспользуйтесь поиском форума. 2. Укажите версию ОС вместе с разрядностью. Пример: LM 19.3 x64, LM Sarah x32 3. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 4. Какое железо. (достаточно вывод inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот
-
Longin
- Сообщения: 2
- Зарегистрирован: 29 авг 2022, 15:55
- Контактная информация:
ACPI BIOS Error
29 авг 2022, 15:58
При загрузки Linux mint происходит ошибка
[ 0.358585] ACPI BIOS Error (bug): Could not resolve symbol [_PR.CPU0._CPC], AE_NOT_FOUND (20210730/psargs-330)
[ 0.358599] ACPI Error: Aborting method _PR.CPU1._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.358636] ACPI BIOS Error (bug): Could not resolve symbol [_PR.CPU0._CPC], AE_NOT_FOUND (20210730/psargs-330)
[ 0.358645] ACPI Error: Aborting method _PR.CPU2._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.358680] ACPI BIOS Error (bug): Could not resolve symbol [_PR.CPU0._CPC], AE_NOT_FOUND (20210730/psargs-330)
[ 0.358688] ACPI Error: Aborting method _PR.CPU3._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
что с этим делать?
Откатывал на другие ядра толку нет.
-
slant
- Сообщения: 4028
- Зарегистрирован: 21 июн 2017, 18:09
- Решено: 79
- Благодарил (а): 50 раз
- Поблагодарили: 1762 раза
- Контактная информация:
ACPI BIOS Error
#2
29 авг 2022, 16:24
Longin писал(а): ↑
29 авг 2022, 15:58
что с этим делать?
Если система грузится и работает нормально — ничего.
-
Longin
- Сообщения: 2
- Зарегистрирован: 29 авг 2022, 15:55
- Контактная информация:
ACPI BIOS Error
#3
29 авг 2022, 16:27
slant писал(а): ↑
29 авг 2022, 16:24
Longin писал(а): ↑
29 авг 2022, 15:58
что с этим делать?Если система грузится и работает нормально — ничего.
А что это такое вообще? хотелось бы понять. разобраться.
-
yarichin
- Сообщения: 137
- Зарегистрирован: 13 июн 2021, 14:08
- Решено: 2
- Поблагодарили: 21 раз
- Контактная информация:
ACPI BIOS Error
#4
29 авг 2022, 17:33
Longin писал(а): ↑
29 авг 2022, 16:27
А что это такое вообще? хотелось бы понять. разобраться.
Если очень хочется , введи кусок строки в гугл и почитай баги. — ACPI BIOS Error (bug): Could not resolve symbol
Running Ubuntu 22.04, Kernel 5.15.0-40-generic x86_64
Since the last kernel update about 3 weeks ago, I have started to get the following errors:-
I have updated the ASUS laptop with the latest BIOS version V322 — but this has done nothing.
ACPI errors shown here...
[ 0.341051] ACPI BIOS Error (bug): Could not resolve symbol [_PR.PR00._CPC], AE_NOT_FOUND (20210730/psargs-330)
[ 0.341075] ACPI Error: Aborting method _PR.PR01._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.341153] ACPI BIOS Error (bug): Could not resolve symbol [_PR.PR00._CPC], AE_NOT_FOUND (20210730/psargs-330)
[ 0.341171] ACPI Error: Aborting method _PR.PR02._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.341250] ACPI BIOS Error (bug): Could not resolve symbol [_PR.PR00._CPC], AE_NOT_FOUND (20210730/psargs-330)
[ 0.341268] ACPI Error: Aborting method _PR.PR03._CPC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
[ 0.342812] ACPI: thermal: Thermal Zone [THRM] (34 C)
Pilot6
86.1k88 gold badges196 silver badges303 bronze badges
asked Jun 28, 2022 at 7:56
2
To get rid of these messages while booting, you can add loglevel=3 to GRUB_CMDLINE_LINUX_DEFAULT in etc/default/grub, so that it will look like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash loglevel=3"
then update grub using command:
sudo update-grub
Note that, adding ‘loglevel=3’ simply disables the non-critical error but doesn’t resolve it. Since this is an active issue reported on bugzilla and has been resolved for 5.18.xx kernels, you can try upgrading your linux kernel to this version using software and updates. Hopefully, it could be resolved soon for 5.15.XX and other kernels. To get more info on why this happens @LordBoltar has explained very well in this thread.
answered Jun 28, 2022 at 18:20
1
I installed Linux Mint 21 on my HP laptop. I got some errors I don’t know how to solve. The first 2 days after installation, I had the following errors:
This is the error I was getting after I boot the system: https://i.imgur.com/AX95fTC.jpg
This is the error that was appearing immediately after the first error shown in the above image: https://i.imgur.com/UPhbRwz.jpg
This is the error I was getting after I press the Power Off button and the system began to shut down: https://i.imgur.com/6wj8u4Z.jpg
The last error disappeared by itself; now the system doesn’t show any messages when shutting down.
The following line:
[ 0.163290] x86/cpu: VMX (outside TXT) disabled by BIOS
Was solved when I enabled the virtualization option in the BIOS: https://i.imgur.com/ENzbo9g.jpg
However, the rest of the errors remained unsolved:
[ 0.232719] ACPI BIOS Error (bug): Could not resolve symbol [SB.OSC.CDW1], AE_NOT_FOUND (20210730/psargs-330)
[ 0.232848] ACPI Error: Aborting method _SB._OSC due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
Does anyone know how to solve those errors? I heard I need to change the ACPI option. The problem is that I don’t have access to the advanced settings in the BIOS menu — InsydeH20 Setup Utility. And I don’t know how to get access to the advanced settings menu (the ACPI options are inside the advanced settings menu).
Also, I will be thankful if someone explains to me what causes those errors. I didn’t have such errors when i used Linux Mint 20.3 and when the kernel wasn’t version 5 (or above). The problems started appearing in Linux Mint 21 and kernel 5 (and above).
When I plug my Lenovo ThinkPad T490 in to my LG 32UL950 via Thunderbolt 3, the following messages are repeated in journalctl 8 times/second:
Feb 04 09:12:46 <hostname> kernel: ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.RP09.PEGP.NVDN], AE_NOT_FOUND (20210730/psargs-330)
Feb 04 09:12:46 <hostname> kernel:
Feb 04 09:12:46 <hostname> kernel: No Local Variables are initialized for Method [_Q27]
Feb 04 09:12:46 <hostname> kernel:
Feb 04 09:12:46 <hostname> kernel: No Arguments are initialized for method [_Q27]
Feb 04 09:12:46 <hostname> kernel:
Feb 04 09:12:46 <hostname> kernel: ACPI Error: Aborting method _SB.PCI0.LPCB.EC._Q27 due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
The power (as reported from while true; do cat /sys/class/power_supply/AC/online; done) flickers on and off, and the battery drains pretty quickly.
This started sometime within the past week or two and makes it very inconvenient to use this monitor.
System information:
$ lsb_release -a
LSB Version: core-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy
$ uname -a
Linux <hostname> 5.15.0-60-generic #66-Ubuntu SMP Fri Jan 20 14:29:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Hi, some weeks ago i got a new laptop and i installed Linux Mint 20.1 Cinnamon via my usb flash drive on it. Everything went and worked well for some days but now i got the following error message while booting and i can’t proceed unfortunately. Please help me. My Laptop is a ‘HP 43,9 cm (17,3) AMD Ryzen 7, 512 GB, 8 GB Notebook , Radeon RX Vega 10, 17-ca1286ng’ Notebook. It was brandnew and had no operating system installed.
Here is the error code:
[ 0.408913] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.GPP2.BCM5], AE_NOT_FOUND (20190816/dswload2-162)
[ 0.408935] ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20190816/psobject-220)
[ 0.613674] Initramfs unpacking failed: Decoding failed
[ 0.625860] pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
[ 18.771128] psmouse serio1: elantech: synaptics_send_cmd query 0x01 failed.
[ 18.771161] psmouse serio1: elantech: failed to query firmware version.
[ 36.804930] watchdog: BUG: soft lockup — CPU#0 stuck for 23s! [systemd-udevd:196]
and here the content of the terminal when i type in ‘inxi -Fz’:
System:
Kernel: 5.8.0-40-generic x86_64 bits: 64 Desktop: Cinnamon 4.8.6
Distro: Linux Mint 20.1 Ulyssa
Machine:
Type: Laptop System: HP product: HP Laptop 17-ca1xxx v: N/A
serial: <filter>
Mobo: HP model: 85B3 v: 91.47 serial: <filter> UEFI: AMI v: F.56
date: 07/13/2020
Battery:
ID-1: BAT0 charge: 9.2 Wh condition: 40.8/40.8 Wh (100%)
CPU:
Topology: Quad Core model: AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
bits: 64 type: MT MCP L2 cache: 2048 KiB
Speed: 1244 MHz min/max: 1400/2300 MHz Core speeds (MHz): 1: 1222 2: 1222
3: 1255 4: 1262 5: 1222 6: 1222 7: 1222 8: 1222
Graphics:
Device-1: AMD Picasso driver: amdgpu v: kernel
Display: x11 server: X.Org 1.20.9 driver: amdgpu,ati
unloaded: fbdev,modesetting,vesa resolution: 1920×1080~60Hz
OpenGL: renderer: AMD RAVEN (DRM 3.38.0 5.8.0-40-generic LLVM 11.0.0)
v: 4.6 Mesa 20.2.6
Audio:
Device-1: AMD Raven/Raven2/Fenghuang HDMI/DP Audio driver: snd_hda_intel
Device-2: AMD Raven/Raven2/FireFlight/Renoir Audio Processor driver: N/A
Device-3: AMD Family 17h HD Audio driver: snd_hda_intel
Sound Server: ALSA v: k5.8.0-40-generic
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169
IF: eno1 state: down mac: <filter>
Device-2: Realtek RTL8723DE 802.11b/g/n PCIe Adapter driver: rtw_8723de
IF: wlp3s0 state: up mac: <filter>
Drives:
Local Storage: total: 476.94 GiB used: 19.18 GiB (4.0%)
ID-1: /dev/nvme0n1 vendor: Intel model: SSDPEKNW512G8H size: 476.94 GiB
Partition:
ID-1: / size: 467.96 GiB used: 19.17 GiB (4.1%) fs: ext4
dev: /dev/nvme0n1p2
Sensors:
System Temperatures: cpu: 37.5 C mobo: 0.0 C gpu: amdgpu temp: 37 C
Fan Speeds (RPM): N/A
Info:
Processes: 246 Uptime: 30m Memory: 5.78 GiB used: 2.68 GiB (46.3%)
Shell: bash inxi: 3.0.38
Comments
sys-oak
pushed a commit
that referenced
this issue
Aug 13, 2021
[ Upstream commit 5acc7d3 ]
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Fixes: aa8d3a7 ("bpf, xdp: Add bpf_link-based XDP attachment API")
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210710031635.41649-1-xuanzhuo@linux.alibaba.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Dec 29, 2021
commit b4d25abf9720b69a03465b09d0d62d1998ed6708 upstream.
In commit 142639a ("drm/msm/a6xx: fix crashstate capture for
A650") we changed a6xx_get_gmu_registers() to read 3 sets of
registers. Unfortunately, we didn't change the memory allocation for
the array. That leads to a KASAN warning (this was on the chromeos-5.4
kernel, which has the problematic commit backported to it):
BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430
Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209
CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22
Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT)
Call trace:
dump_backtrace+0x0/0x248
show_stack+0x20/0x2c
dump_stack+0x128/0x1ec
print_address_description+0x88/0x4a0
__kasan_report+0xfc/0x120
kasan_report+0x10/0x18
__asan_report_store8_noabort+0x1c/0x24
_a6xx_get_gmu_registers+0x144/0x430
a6xx_gpu_state_get+0x330/0x25d4
msm_gpu_crashstate_capture+0xa0/0x84c
recover_worker+0x328/0x838
kthread_worker_fn+0x32c/0x574
kthread+0x2dc/0x39c
ret_from_fork+0x10/0x18
Allocated by task 209:
__kasan_kmalloc+0xfc/0x1c4
kasan_kmalloc+0xc/0x14
kmem_cache_alloc_trace+0x1f0/0x2a0
a6xx_gpu_state_get+0x164/0x25d4
msm_gpu_crashstate_capture+0xa0/0x84c
recover_worker+0x328/0x838
kthread_worker_fn+0x32c/0x574
kthread+0x2dc/0x39c
ret_from_fork+0x10/0x18
Fixes: 142639a ("drm/msm/a6xx: fix crashstate capture for A650")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20211103153049.1.Idfa574ccb529d17b69db3a1852e49b580132035c@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sys-oak
pushed a commit
that referenced
this issue
Dec 30, 2021
commit b4d25abf9720b69a03465b09d0d62d1998ed6708 upstream.
In commit 142639a ("drm/msm/a6xx: fix crashstate capture for
A650") we changed a6xx_get_gmu_registers() to read 3 sets of
registers. Unfortunately, we didn't change the memory allocation for
the array. That leads to a KASAN warning (this was on the chromeos-5.4
kernel, which has the problematic commit backported to it):
BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430
Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209
CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22
Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT)
Call trace:
dump_backtrace+0x0/0x248
show_stack+0x20/0x2c
dump_stack+0x128/0x1ec
print_address_description+0x88/0x4a0
__kasan_report+0xfc/0x120
kasan_report+0x10/0x18
__asan_report_store8_noabort+0x1c/0x24
_a6xx_get_gmu_registers+0x144/0x430
a6xx_gpu_state_get+0x330/0x25d4
msm_gpu_crashstate_capture+0xa0/0x84c
recover_worker+0x328/0x838
kthread_worker_fn+0x32c/0x574
kthread+0x2dc/0x39c
ret_from_fork+0x10/0x18
Allocated by task 209:
__kasan_kmalloc+0xfc/0x1c4
kasan_kmalloc+0xc/0x14
kmem_cache_alloc_trace+0x1f0/0x2a0
a6xx_gpu_state_get+0x164/0x25d4
msm_gpu_crashstate_capture+0xa0/0x84c
recover_worker+0x328/0x838
kthread_worker_fn+0x32c/0x574
kthread+0x2dc/0x39c
ret_from_fork+0x10/0x18
Fixes: 142639a ("drm/msm/a6xx: fix crashstate capture for A650")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20211103153049.1.Idfa574ccb529d17b69db3a1852e49b580132035c@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sys-oak
pushed a commit
that referenced
this issue
Jan 10, 2022
…port_id()
[ Upstream commit 1d72d9f960ccf1052a0630a68c3d358791dbdaaa ]
The array param[] in elantech_change_report_id() must be at least 3
bytes, because elantech_read_reg_params() is calling ps2_command() with
PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but
it's defined in the stack as an array of 2 bytes, therefore we have a
potential stack out-of-bounds access here, also confirmed by KASAN:
[ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0
[ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118
[ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110
[ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020
[ 6.512436] Workqueue: events_long serio_handle_event
[ 6.512453] Call Trace:
[ 6.512462] show_stack+0x52/0x58
[ 6.512474] dump_stack+0xa1/0xd3
[ 6.512487] print_address_description.constprop.0+0x1d/0x140
[ 6.512502] ? __ps2_command+0x372/0x7e0
[ 6.512516] __kasan_report.cold+0x7d/0x112
[ 6.512527] ? _raw_write_lock_irq+0x20/0xd0
[ 6.512539] ? __ps2_command+0x372/0x7e0
[ 6.512552] kasan_report+0x3c/0x50
[ 6.512564] __asan_load1+0x6a/0x70
[ 6.512575] __ps2_command+0x372/0x7e0
[ 6.512589] ? ps2_drain+0x240/0x240
[ 6.512601] ? dev_printk_emit+0xa2/0xd3
[ 6.512612] ? dev_vprintk_emit+0xc5/0xc5
[ 6.512621] ? __kasan_check_write+0x14/0x20
[ 6.512634] ? mutex_lock+0x8f/0xe0
[ 6.512643] ? __mutex_lock_slowpath+0x20/0x20
[ 6.512655] ps2_command+0x52/0x90
[ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse]
[ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse]
[ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse]
[ 6.512863] ? ps2_command+0x7f/0x90
[ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse]
[ 6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse]
[ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse]
[ 6.513064] ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse]
[ 6.513122] ? phys_pmd_init+0x30e/0x521
[ 6.513137] elantech_init+0x8a/0x200 [psmouse]
[ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse]
[ 6.513249] ? elantech_query_info+0x440/0x440 [psmouse]
[ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse]
[ 6.513342] ? elantech_query_info+0x440/0x440 [psmouse]
[ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse]
[ 6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse]
[ 6.513476] ? psmouse_try_protocol+0x170/0x170 [psmouse]
[ 6.513519] ? mutex_unlock+0x22/0x40
[ 6.513526] ? ps2_command+0x7f/0x90
[ 6.513536] ? psmouse_probe+0xa3/0xf0 [psmouse]
[ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse]
[ 6.513624] psmouse_connect+0x272/0x530 [psmouse]
[ 6.513669] serio_driver_probe+0x55/0x70
[ 6.513679] really_probe+0x190/0x720
[ 6.513689] driver_probe_device+0x160/0x1f0
[ 6.513697] device_driver_attach+0x119/0x130
[ 6.513705] ? device_driver_attach+0x130/0x130
[ 6.513713] __driver_attach+0xe7/0x1a0
[ 6.513720] ? device_driver_attach+0x130/0x130
[ 6.513728] bus_for_each_dev+0xfb/0x150
[ 6.513738] ? subsys_dev_iter_exit+0x10/0x10
[ 6.513748] ? _raw_write_unlock_bh+0x30/0x30
[ 6.513757] driver_attach+0x2d/0x40
[ 6.513764] serio_handle_event+0x199/0x3d0
[ 6.513775] process_one_work+0x471/0x740
[ 6.513785] worker_thread+0x2d2/0x790
[ 6.513794] ? process_one_work+0x740/0x740
[ 6.513802] kthread+0x1b4/0x1e0
[ 6.513809] ? set_kthread_struct+0x80/0x80
[ 6.513816] ret_from_fork+0x22/0x30
[ 6.513832] The buggy address belongs to the page:
[ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7
[ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[ 6.513860] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[ 6.513867] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 6.513872] page dumped because: kasan: bad access detected
[ 6.513879] addr ffff8881024d77c2 is located in stack of task kworker/2:1/118 at offset 34 in frame:
[ 6.513887] elantech_change_report_id+0x0/0x256 [psmouse]
[ 6.513941] this frame has 1 object:
[ 6.513947] [32, 34) 'param'
[ 6.513956] Memory state around the buggy address:
[ 6.513962] ffff8881024d7680: f2 f2 f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 00
[ 6.513969] ffff8881024d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.513976] >ffff8881024d7780: 00 00 00 00 f1 f1 f1 f1 02 f3 f3 f3 00 00 00 00
[ 6.513982] ^
[ 6.513988] ffff8881024d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.513995] ffff8881024d7880: 00 f1 f1 f1 f1 03 f2 03 f2 03 f3 f3 f3 00 00 00
[ 6.514000] ==================================================================
Define param[] in elantech_change_report_id() as an array of 3 bytes to
prevent the out-of-bounds access in the stack.
Fixes: e4c9062 ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
BugLink: https://bugs.launchpad.net/bugs/1945590
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Reviewed-by: Wolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Jan 20, 2022
…port_id()
[ Upstream commit 1d72d9f960ccf1052a0630a68c3d358791dbdaaa ]
The array param[] in elantech_change_report_id() must be at least 3
bytes, because elantech_read_reg_params() is calling ps2_command() with
PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but
it's defined in the stack as an array of 2 bytes, therefore we have a
potential stack out-of-bounds access here, also confirmed by KASAN:
[ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0
[ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118
[ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110
[ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020
[ 6.512436] Workqueue: events_long serio_handle_event
[ 6.512453] Call Trace:
[ 6.512462] show_stack+0x52/0x58
[ 6.512474] dump_stack+0xa1/0xd3
[ 6.512487] print_address_description.constprop.0+0x1d/0x140
[ 6.512502] ? __ps2_command+0x372/0x7e0
[ 6.512516] __kasan_report.cold+0x7d/0x112
[ 6.512527] ? _raw_write_lock_irq+0x20/0xd0
[ 6.512539] ? __ps2_command+0x372/0x7e0
[ 6.512552] kasan_report+0x3c/0x50
[ 6.512564] __asan_load1+0x6a/0x70
[ 6.512575] __ps2_command+0x372/0x7e0
[ 6.512589] ? ps2_drain+0x240/0x240
[ 6.512601] ? dev_printk_emit+0xa2/0xd3
[ 6.512612] ? dev_vprintk_emit+0xc5/0xc5
[ 6.512621] ? __kasan_check_write+0x14/0x20
[ 6.512634] ? mutex_lock+0x8f/0xe0
[ 6.512643] ? __mutex_lock_slowpath+0x20/0x20
[ 6.512655] ps2_command+0x52/0x90
[ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse]
[ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse]
[ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse]
[ 6.512863] ? ps2_command+0x7f/0x90
[ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse]
[ 6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse]
[ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse]
[ 6.513064] ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse]
[ 6.513122] ? phys_pmd_init+0x30e/0x521
[ 6.513137] elantech_init+0x8a/0x200 [psmouse]
[ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse]
[ 6.513249] ? elantech_query_info+0x440/0x440 [psmouse]
[ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse]
[ 6.513342] ? elantech_query_info+0x440/0x440 [psmouse]
[ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse]
[ 6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse]
[ 6.513476] ? psmouse_try_protocol+0x170/0x170 [psmouse]
[ 6.513519] ? mutex_unlock+0x22/0x40
[ 6.513526] ? ps2_command+0x7f/0x90
[ 6.513536] ? psmouse_probe+0xa3/0xf0 [psmouse]
[ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse]
[ 6.513624] psmouse_connect+0x272/0x530 [psmouse]
[ 6.513669] serio_driver_probe+0x55/0x70
[ 6.513679] really_probe+0x190/0x720
[ 6.513689] driver_probe_device+0x160/0x1f0
[ 6.513697] device_driver_attach+0x119/0x130
[ 6.513705] ? device_driver_attach+0x130/0x130
[ 6.513713] __driver_attach+0xe7/0x1a0
[ 6.513720] ? device_driver_attach+0x130/0x130
[ 6.513728] bus_for_each_dev+0xfb/0x150
[ 6.513738] ? subsys_dev_iter_exit+0x10/0x10
[ 6.513748] ? _raw_write_unlock_bh+0x30/0x30
[ 6.513757] driver_attach+0x2d/0x40
[ 6.513764] serio_handle_event+0x199/0x3d0
[ 6.513775] process_one_work+0x471/0x740
[ 6.513785] worker_thread+0x2d2/0x790
[ 6.513794] ? process_one_work+0x740/0x740
[ 6.513802] kthread+0x1b4/0x1e0
[ 6.513809] ? set_kthread_struct+0x80/0x80
[ 6.513816] ret_from_fork+0x22/0x30
[ 6.513832] The buggy address belongs to the page:
[ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7
[ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[ 6.513860] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[ 6.513867] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 6.513872] page dumped because: kasan: bad access detected
[ 6.513879] addr ffff8881024d77c2 is located in stack of task kworker/2:1/118 at offset 34 in frame:
[ 6.513887] elantech_change_report_id+0x0/0x256 [psmouse]
[ 6.513941] this frame has 1 object:
[ 6.513947] [32, 34) 'param'
[ 6.513956] Memory state around the buggy address:
[ 6.513962] ffff8881024d7680: f2 f2 f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 00
[ 6.513969] ffff8881024d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.513976] >ffff8881024d7780: 00 00 00 00 f1 f1 f1 f1 02 f3 f3 f3 00 00 00 00
[ 6.513982] ^
[ 6.513988] ffff8881024d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.513995] ffff8881024d7880: 00 f1 f1 f1 f1 03 f2 03 f2 03 f3 f3 f3 00 00 00
[ 6.514000] ==================================================================
Define param[] in elantech_change_report_id() as an array of 3 bytes to
prevent the out-of-bounds access in the stack.
Fixes: e4c9062 ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
BugLink: https://bugs.launchpad.net/bugs/1945590
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Reviewed-by: Wolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Jan 30, 2022
…port_id()
[ Upstream commit 1d72d9f960ccf1052a0630a68c3d358791dbdaaa ]
The array param[] in elantech_change_report_id() must be at least 3
bytes, because elantech_read_reg_params() is calling ps2_command() with
PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but
it's defined in the stack as an array of 2 bytes, therefore we have a
potential stack out-of-bounds access here, also confirmed by KASAN:
[ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0
[ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118
[ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110
[ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020
[ 6.512436] Workqueue: events_long serio_handle_event
[ 6.512453] Call Trace:
[ 6.512462] show_stack+0x52/0x58
[ 6.512474] dump_stack+0xa1/0xd3
[ 6.512487] print_address_description.constprop.0+0x1d/0x140
[ 6.512502] ? __ps2_command+0x372/0x7e0
[ 6.512516] __kasan_report.cold+0x7d/0x112
[ 6.512527] ? _raw_write_lock_irq+0x20/0xd0
[ 6.512539] ? __ps2_command+0x372/0x7e0
[ 6.512552] kasan_report+0x3c/0x50
[ 6.512564] __asan_load1+0x6a/0x70
[ 6.512575] __ps2_command+0x372/0x7e0
[ 6.512589] ? ps2_drain+0x240/0x240
[ 6.512601] ? dev_printk_emit+0xa2/0xd3
[ 6.512612] ? dev_vprintk_emit+0xc5/0xc5
[ 6.512621] ? __kasan_check_write+0x14/0x20
[ 6.512634] ? mutex_lock+0x8f/0xe0
[ 6.512643] ? __mutex_lock_slowpath+0x20/0x20
[ 6.512655] ps2_command+0x52/0x90
[ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse]
[ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse]
[ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse]
[ 6.512863] ? ps2_command+0x7f/0x90
[ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse]
[ 6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse]
[ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse]
[ 6.513064] ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse]
[ 6.513122] ? phys_pmd_init+0x30e/0x521
[ 6.513137] elantech_init+0x8a/0x200 [psmouse]
[ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse]
[ 6.513249] ? elantech_query_info+0x440/0x440 [psmouse]
[ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse]
[ 6.513342] ? elantech_query_info+0x440/0x440 [psmouse]
[ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse]
[ 6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse]
[ 6.513476] ? psmouse_try_protocol+0x170/0x170 [psmouse]
[ 6.513519] ? mutex_unlock+0x22/0x40
[ 6.513526] ? ps2_command+0x7f/0x90
[ 6.513536] ? psmouse_probe+0xa3/0xf0 [psmouse]
[ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse]
[ 6.513624] psmouse_connect+0x272/0x530 [psmouse]
[ 6.513669] serio_driver_probe+0x55/0x70
[ 6.513679] really_probe+0x190/0x720
[ 6.513689] driver_probe_device+0x160/0x1f0
[ 6.513697] device_driver_attach+0x119/0x130
[ 6.513705] ? device_driver_attach+0x130/0x130
[ 6.513713] __driver_attach+0xe7/0x1a0
[ 6.513720] ? device_driver_attach+0x130/0x130
[ 6.513728] bus_for_each_dev+0xfb/0x150
[ 6.513738] ? subsys_dev_iter_exit+0x10/0x10
[ 6.513748] ? _raw_write_unlock_bh+0x30/0x30
[ 6.513757] driver_attach+0x2d/0x40
[ 6.513764] serio_handle_event+0x199/0x3d0
[ 6.513775] process_one_work+0x471/0x740
[ 6.513785] worker_thread+0x2d2/0x790
[ 6.513794] ? process_one_work+0x740/0x740
[ 6.513802] kthread+0x1b4/0x1e0
[ 6.513809] ? set_kthread_struct+0x80/0x80
[ 6.513816] ret_from_fork+0x22/0x30
[ 6.513832] The buggy address belongs to the page:
[ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7
[ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[ 6.513860] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[ 6.513867] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 6.513872] page dumped because: kasan: bad access detected
[ 6.513879] addr ffff8881024d77c2 is located in stack of task kworker/2:1/118 at offset 34 in frame:
[ 6.513887] elantech_change_report_id+0x0/0x256 [psmouse]
[ 6.513941] this frame has 1 object:
[ 6.513947] [32, 34) 'param'
[ 6.513956] Memory state around the buggy address:
[ 6.513962] ffff8881024d7680: f2 f2 f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 00
[ 6.513969] ffff8881024d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.513976] >ffff8881024d7780: 00 00 00 00 f1 f1 f1 f1 02 f3 f3 f3 00 00 00 00
[ 6.513982] ^
[ 6.513988] ffff8881024d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.513995] ffff8881024d7880: 00 f1 f1 f1 f1 03 f2 03 f2 03 f3 f3 f3 00 00 00
[ 6.514000] ==================================================================
Define param[] in elantech_change_report_id() as an array of 3 bytes to
prevent the out-of-bounds access in the stack.
Fixes: e4c9062 ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
BugLink: https://bugs.launchpad.net/bugs/1945590
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Reviewed-by: Wolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Apr 6, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Apr 8, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Apr 12, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Apr 14, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
May 9, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sys-oak
pushed a commit
that referenced
this issue
Nov 24, 2022
[ Upstream commit 8cfb08575c6d4585f1ce0deeb189e5c824776b04 ]
Li Huafei reports that mcount-based ftrace with module PLTs was broken
by commit:
a6253579977e4c6f ("arm64: ftrace: consistently handle PLTs.")
When a module PLTs are used and a module is loaded sufficiently far away
from the kernel, we'll create PLTs for any branches which are
out-of-range. These are separate from the special ftrace trampoline
PLTs, which the module PLT code doesn't directly manipulate.
When mcount is in use this is a problem, as each mcount callsite in a
module will be initialized to point to a module PLT, but since commit
a6253579977e4c6f ftrace_make_nop() will assume that the callsite has
been initialized to point to the special ftrace trampoline PLT, and
ftrace_find_callable_addr() rejects other cases.
This means that when ftrace tries to initialize a callsite via
ftrace_make_nop(), the call to ftrace_find_callable_addr() will find
that the `_mcount` stub is out-of-range and is not handled by the ftrace
PLT, resulting in a splat:
| ftrace_test: loading out-of-tree module taints kernel.
| ftrace: no module PLT for _mcount
| ------------[ ftrace bug ]------------
| ftrace failed to modify
| [<ffff800029180014>] 0xffff800029180014
| actual: 44:00:00:94
| Initializing ftrace call sites
| ftrace record flags: 2000000
| (0)
| expected tramp: ffff80000802eb3c
| ------------[ cut here ]------------
| WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270
| Modules linked in:
| CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22
| Hardware name: linux,dummy-virt (DT)
| pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : ftrace_bug+0x94/0x270
| lr : ftrace_bug+0x21c/0x270
| sp : ffff80000b2bbaf0
| x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000
| x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00
| x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8
| x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff
| x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118
| x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666
| x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030
| x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4
| x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001
| x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022
| Call trace:
| ftrace_bug+0x94/0x270
| ftrace_process_locs+0x308/0x430
| ftrace_module_init+0x44/0x60
| load_module+0x15b4/0x1ce8
| __do_sys_init_module+0x1ec/0x238
| __arm64_sys_init_module+0x24/0x30
| invoke_syscall+0x54/0x118
| el0_svc_common.constprop.4+0x84/0x100
| do_el0_svc+0x3c/0xd0
| el0_svc+0x1c/0x50
| el0t_64_sync_handler+0x90/0xb8
| el0t_64_sync+0x15c/0x160
| ---[ end trace 0000000000000000 ]---
| ---------test_init-----------
Fix this by reverting to the old behaviour of ignoring the old
instruction when initialising an mcount callsite in a module, which was
the behaviour prior to commit a6253579977e4c6f.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Fixes: a6253579977e ("arm64: ftrace: consistently handle PLTs.")
Reported-by: Li Huafei <lihuafei1@huawei.com>
Link: https://lore.kernel.org/linux-arm-kernel/20220929094134.99512-1-lihuafei1@huawei.com
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20220929134525.798593-1-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Содержание
- Шо, опять? Ядро 5.6 и ACPI.
- Linux Mint Forums
- [Solved] ACPI errors during boot
- [Solved] ACPI errors during boot
- Re: ACPI errors during boot
- Re: ACPI errors during boot
- Re: ACPI errors during boot
- Re: ACPI errors during boot
- Re: ACPI errors during boot
- Re: ACPI errors during boot
- Re: [Solved] ACPI errors during boot
- Re: [Solved] ACPI errors during boot
- Linux Mint Forums
- [SOLVED] ACPI errors and graphics card drivers issues
- [SOLVED] ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
- Re: ACPI errors and graphics card drivers issues
Шо, опять? Ядро 5.6 и ACPI.
При переходе на 5.6 после выхода из саспенда dmesg спамит, и много чего перестаёт работать:
На 5.5 такого не было.
Куда деваться то со своим «старым» (P8Z68) железом?
Куда деваться то со своим «старым» (P8Z68) железом?
На свалку. У меня на лаптопе еще не такое происходить стало со временем, и всем пофиг на мои баг-репорты. Так что либо придумывай собственные костыли, либо меняй железку.
Как? i7-2600K на свалку?
Разбить? Пол-литру!? Вдребезги? Да я тебя!
не знаю про i7, но на i5 2400 даже сайты уже притормаживают, а на всяком дне типа i5 2410m не стесняясь тормозят в полную силу.
Зачем ты суспендишь десктоп?
ryzen 5 2600/b450 aorus elite
это появилось на 5 ядре, на 4.xx (точно не помню на каком именно), такого не было
У 2600K райзены первого поколения по синглкору посасывают, тащемт.
Я даже растерялся… А почему бы мне его не суспендить?
Каждый день пользуюсь. Наверное, чтоб просто клацнуть кнопкой и сразу начать пользоваться?
Если его не суспендить тоже можно просто сразу пользоваться, лол.
Предлагаешь не выключать?
Ну а сколько он там жрёт? В простое частота падает до 800мгц или сколько там.
Нет, конечно. Это пока «нытик-тред».
оставайся на 4.19
Могут сказать точно, что жрёт 80+ Ватт, так он ещё и не бесшумный.
а есть вообще разумный довод использовать максимально свежее ядро ?
А лучше обновится до Darwin Kernel Version 19.4.0
а есть вообще разумный довод использовать максимально свежее ядро ?
Вообще, конечно, нет.
_GTF — acpi функция переводящая (s)ata порт в состояние по умолчанию (или просто — инициализация).
DSSP — это какой-то флаг, на который ссылается эта функция, и который не установлен. Баг acpi/bios.
Скорее всего, в предыдущих версиях ядра из-за жалоб на эту ошибку, эта функция не вызывалась, а ядро само инициализировало sata-порты (сделали заглушку для конкретной материнки). После очередной чистки кода от старья эту заглушку выкинули и честно дергают acpi-функцию
Если нет проблем с дисками, то эту ошибку можно игнорировать.
Если нет проблем с дисками, то эту ошибку можно игнорировать.
Смотря что считать за проблему с дисками, точно есть проблемы с кедами, последний раз начали крашится ksshaskpass и system settings и может ещё что, обратил внимание только на это, ну и общая отзывчивость системы падает — в этом плане проблемы с дисками несомненно есть.
Ты привел только одну ошибку. И эта acpi-функция в основном простая заглушка, которая ничего не делает, максимум установит еще какой-нибудь флаг, ничего не значащий для работающей системы, чисто внутренняя для acpi, что типа порт инициализирован.
Думаю, у тебя скорее всего поломалось где-то в другом месте. Иначе у тебя при нормальном старте (не пробуждении из suspend) так же глючила система из-за дисков.
Думаю, у тебя скорее всего поломалось где-то в другом месте.
Всё может быть. Но мне кажется, что это всё-таки в ядре дело. На 5.5 не глючит так после выхода из сна.
Куда деваться то со своим «старым» (P8Z68) железом?
Ладно со старым, у меня с новым за последний год дважды спящий режим ломали.
глючит так после выхода из сна.
Это нормальное состояние вплоть до того, что при смене минорной версии (версиии патча) могут поломать засыпание. Потому что это неважная часть линукса, могут глобально перелопатить логику засыпания между патчами с соответствующими последствиями.
Конечно, всё бывает в первый раз. Но не припомню такие проблемы, системнику 8-10 лет.
Но не припомню такие проблемы, системнику 8-10 лет.
Купи себе модный (китайский) ноутбук/нетбук/планшет — будет что припомнить, что забывать не будешь успевать 🙂
Кто-то еще выключает компьютеры, кроме тех, кто собирает шумные ящики?
- скорее не связанные вещи, вот у меня с 5.3
ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20190703/psargs-330)
- саспенды всегда работали, работают, будут работать с линуксами через одно место. Проще не использовать, тем более, еcли у тебя корабасный десктоп. Выключай на ночь и нормально.
Так было и так будет всегда: кривые, не соответствующие стандартам прошивки на платах Asus. Поэтому в ядре фиксить это никогда не будут.
Впрочем, они почти везде кривые в потребительском железе. Из того, что можно купить за разумные деньги «для дома, для семьи» – только с Supermicro не бывает проблем. Ну, или смотрите списки сертифицированного оборудования, например, redhat.
Как я понимаю ты позорище опенсорса имеешь ввиду сайты как браузер, а не как сервер?
Как сервер www, ppp, ftp, samba, dns, router, и ррочая и прочая даже первый пень до сих пор работоспособным будет.
(и особенно первый, второй и третий пни, так как у них биос в съёмном ПЗУ, а не на флеше, их сейчас как золото беззондовое хранить нужно)
Источник
Linux Mint Forums
Welcome to the Linux Mint forums!
[Solved] ACPI errors during boot
[Solved] ACPI errors during boot
Post by zenmaker » Fri May 20, 2022 10:48 am
During boot get these ACPI errors especially AE NOT found.
So I have 2 ssd and 2 hdd, one ssd is transcend and has windows install and 2 partitions.
The other ssd has linux mint and is crucial, uses ext4 and bios for grub.
The error seem to be related to the transcend ssd no error throws up for other disks in the journal. It feels like some grub or boot mbr issue though have tried reinstalling grub but still get the message.
is it a bad error to have.
during boot these errors show up
Re: ACPI errors during boot
Post by rene » Fri May 20, 2022 10:57 am
Re: ACPI errors during boot
Post by zenmaker » Sat May 21, 2022 6:43 am
The thing was i didnt have this error before, when i was using ubuntu 21.10, hated 22.04 due to snap and stuff and was distro hopping, from debian to fedora to pop but settled on mint.
Its just annoying to see that, im sure its some issue with boot managers on how they are reading the windows disk.
Re: ACPI errors during boot
Post by rene » Sat May 21, 2022 8:34 am
It’s definitely not — but Mint 20.x is on a Ubuntu 20.04 base, i.e., significantly older than 21.10 and.or 22.04, and you are explicitly using the standard 5.4 kernel series.
If you’re sure that 21.10 and/or 22.04 did not show you the ACPI messages you may try upgrading to the 5.13 series: Upgrade Manager -> View -> Linux kernels; pick the newest 5.13 series kernel and reboot into it. Although it doesn’t tend to happen, as a matter of the in the linked tutorial post described BIOS kernel interaction a kernel-sides update may have also fixed (or more likely, simply silenced) this on your system after all.
If not you’d «need» to follow the advise given there as to replacing quiet with loglevel=3 — which for all I know might in fact be something newer Ubuntu releases do OOTB at the moment, although I doubt it.
Re: ACPI errors during boot
Post by zenmaker » Mon May 23, 2022 6:31 am
Hi thanks for the help, so i tested out ubuntu 21.10 impish and jammy on live usb to make sure, funnily impish is the only version it doesnt appear i think its cause of their splash logo probably has the fix you mentioned, while in jammy the errors throw up before logo shows up.
So ended up using loglevel=3 on mint and is now nice and quiet boot, and i can show off to my windows friends how superior linux is without all those errors throwing up on boot
Again thanks for the help and your time much appreciate it.
Re: ACPI errors during boot
Post by Reddog1 » Mon May 23, 2022 8:21 pm
The kernel developers, in their great wisdom, decided to print lower log-level errors on the boot screen, and this has led to a heap of questions about why the acpi errors are occurring. Some other distributions have set the log level=3 out-of-the-box in order to avoid this nuisance.
Please set the topic as [solved]
Re: ACPI errors during boot
Post by rene » Tue May 24, 2022 7:07 am
Re: [Solved] ACPI errors during boot
Post by Reddog1 » Tue May 24, 2022 10:23 pm
Yes, you are right, it is a decision made by the distribution (and those with the distribution that make determinations about the kernel). Anytime errors are shown at boot, it is definitely going to cause consternation, especially among new users. As I mentioned, some distributions have specifically set the /etc/default/grub to not print that log-level of messages.
Here is the stock grub line from an arch-based distro:
GRUB_CMDLINE_LINUX_DEFAULT=»quiet loglevel=3 nowatchdog nvme_load=YES»
Re: [Solved] ACPI errors during boot
Post by rene » Wed May 25, 2022 6:14 am
Источник
Linux Mint Forums
Welcome to the Linux Mint forums!
[SOLVED] ACPI errors and graphics card drivers issues
[SOLVED] ACPI errors and graphics card drivers issues
Post by Lock3 » Sat Aug 15, 2020 5:50 pm
It’s my first post here, so hello everyone.
I’ve just installed for the first time Linux Mint 64 bits in dual-boot with Windows 10 both in legacy mode.
The dual-boot works fine and so does Mint except that I have these ACPI errors on boot :
Moreover, it is impossible to install the Nvidia drivers which are recommended in the driver manager. When I try to do it, the system doesn’t recognize my graphics card anymore and the image is only managed by the CPU. I specify that I have an RTX 2070.
Secure boot is disabled as well as fast boot on windows 10.
I browsed the forum and tried to modify GRUB without success. Is this a kernel problem?
Thank you in advance for your answers
Re: ACPI errors and graphics card drivers issues
Post by Pjotr » Sat Aug 15, 2020 6:05 pm
(if you type: the letter F is a capital letter, and don’t omit the space after inxi!)
Copy/paste the output in your next message.
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Sun Aug 16, 2020 3:23 am
Re: ACPI errors and graphics card drivers issues
Post by Pjotr » Sun Aug 16, 2020 4:22 am
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Sun Aug 16, 2020 5:20 am
I chose a 2015 firmware version because the version of 2018 was still in beta status.
It still doesn’t work.
When I installed Mint I chose «Something Else» in the installer option and I have created a partition in ext4 an / for mount. Do I have to create a swap partition like older version of ubuntu ? Or this is irrelevant for this subject ?
Re: ACPI errors and graphics card drivers issues
Post by Pjotr » Sun Aug 16, 2020 5:59 am
I chose a 2015 firmware version because the version of 2018 was still in beta status.
That’s indeed irrelevant.
You might try a kernel update from the Canonical Kernel Team PPA:
https://easylinuxtipsproject.blogspot.c . t.html#ID8
(item 8 )
That should give you the latest kernel from the 5.4 series, which hopefully contains improvements that are relevant for your problem.
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Sun Aug 16, 2020 8:36 am
I did as you said and switched to the 5.4.0-44 and unfortunately it doesn’t change anything.
I experience some weird crashes too : I tried to open Rhythmbox or the firewall and it’s stop the current session and send me back to the login screen. (It happens before the kernel update)
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Sun Aug 16, 2020 12:46 pm
So I tried the tip with
I still have the ACPI errors and the graphic card still doesn’t work.
Re: ACPI errors and graphics card drivers issues
Post by Pjotr » Sun Aug 16, 2020 1:03 pm
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Sun Aug 16, 2020 1:42 pm
This beta bios was made only for spectre vulnerability on CPU wich I am already protected.
Many users had issues with this Bios and I will not take my chance with it I think.
It’s a shame beacause Mint works flawlessly on my laptop and it seems to have many issues with a dual boot on legacy mode. Perhaps should I try to convert all the os on EFI mode ? Is it possible anyway without reinstalling the two OS ?
Re: ACPI errors and graphics card drivers issues
Post by SMG » Sun Aug 16, 2020 1:43 pm
When the Nvidia driver loads properly, you will see nvidia in both the device driver and the display driver.
Graphics:
Device-1: NVIDIA TU106 [GeForce RTX 2070 Rev. A] vendor: Micro-Star MSI
driver: nvidia v: 450.57 bus ID: 01:00.0
Display: x11 server: X.Org 1.20.8 driver: fbdev,modesetting,nouveau
unloaded: vesa resolution: 640×480
I don’t see it loaded or unloaded in the display drivers, so I’m going to suggest the driver did not install properly. I don’t what method you used to install it, but Pjotr’s website has a section on NVIDIA: how to install the latest video card drivers and roblm has tips for installing on LM20 in this post (scroll to the section in big blue letters — Mint 20 Nvidia Driver Installation Update).
Hopefully information in one of those two places (or both) can help you.
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Sun Aug 16, 2020 2:21 pm
I tried the first step already without success unfortunately.
I will try the second one with driver directly downloaded from nvidia website.
Thanks for answering guys.
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Sun Aug 16, 2020 6:32 pm
The second one was better than the others
Driver nvidia-450 has worked flawlessly with the roblm installation technique (with the driver downloaded on nvidia website) after
, every program on Mint worked fine, no crashes. UNTIL I have rebooted the system and now the driver is gone, with the GPU. Mint is on hardware only with 640*480 resolution.
ACPI errors still there but it seems to be not the real problem here.
The boot sequence don’t recognize the nvidia driver I think.
Boot issue ? kernel issue ? I don’t know
Re: ACPI errors and graphics card drivers issues
Post by SMG » Sun Aug 16, 2020 8:26 pm
UNTIL I have rebooted the system and now the driver is gone, with the GPU. Mint is on hardware only with 640*480 resolution.
ACPI errors still there but it seems to be not the real problem here.
The boot sequence don’t recognize the nvidia driver I think.
Boot issue ? kernel issue ? I don’t know
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Mon Aug 17, 2020 4:59 am
Yes I removed the nomodeset.
I tried a fresh install again this morning, but again it’s like Mint can’t find the GPU nivdia-driver after or during the boot sequence.
Re: ACPI errors and graphics card drivers issues
Post by Lock3 » Mon Aug 17, 2020 5:30 am
OK I’ve got something new here.
As I said, I did a fresh install and installed the recommanded nvidia-driver-440 an rebooted. Nothing new for this part, the driver didn’t launch.
But I have just disconnected (close session) and login again (without reboot) and then everything works fine.
So the issue seems to be in the boot process of Mint 20. Something is preventing the driver from starting but I don’t know what.
Re: ACPI errors and graphics card drivers issues
Post by SMG » Mon Aug 17, 2020 12:09 pm
OK I’ve got something new here.
As I said, I did a fresh install and installed the recommanded nvidia-driver-440 an rebooted. Nothing new for this part, the driver didn’t launch.
But I have just disconnected (close session) and login again (without reboot) and then everything works fine.
So the issue seems to be in the boot process of Mint 20. Something is preventing the driver from starting but I don’t know what.
That sounds similar to what was happening to several people in this thread. Maybe reading through the thread will help. As I understand it, it is not that something is preventing the driver from starting, but rather something is not telling the driver to start at the correct time in the start-up sequence. I know there is a way to fix this (since several people in the thread were able to do it), but I don’t currently have the knowledge level to be able to guide something through the correct steps for doing it.
Perhaps someone with more knowledge than I currently have will be able to help
Источник
У меня на компьютере установлены такие ос Вантуз 11, Ubuntu 22.04 и Linux Mint 21 Cinnamon.
Я предполагаю, что обе описанные мной проблемы связаны, так как они присутствуют и на Ubuntu и на Linux Mint, а также при запуске этих двух операционных систем вылетают 2 ошибки.
Код
[ 0.360921] ACPI BIOS ERROR (bug) could not resolve symbol [_SB.PC00.MHBR], AE_NOT__FOUND (20210730/psargs-330) [ 0.360964] ACPI BIOS ERROR (bug) could not resolve symbol [_SB.PTID.PBAR], AE_NOT__FOUND (20210730/dsfield-500)
Первая проблема заключается в том,что если я зайду в спящий режим, а после попытаюсь из него выйти, то экран помигает и погаснет, а после чего просто останется чёрным, и поможет только принудительная перезагрузка.
Вторая проблема. Когда подключаю к компьютеру по hdmi второй экран, то ни Linux Mint, ни Ubuntu его не видят.
На винде обе эти проблемы не возникают.
Как мне их исправить?
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь