The fault:
ACPI: Video Device [VGA1] (multi-head: yes rom: no post: no)
ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.GP17.VGA.LCD._BCM.AFN7], AE_NOT_FOUND (20190816/psargs-330)
Initialized Local Variables for Method [_BCM]:
Local0: 00000000ea353c08 <Obj> Integer 00000000000000FF
Local1: 00000000418bc901 <Obj> Integer 0000000000000000
Initialized Arguments for Method [_BCM]: (1 arguments defined for method invocation)
Arg0: 00000000c180e4bd <Obj> Integer 0000000000000064
ACPI Error: Aborting method _SB.PCI0.GP17.VGA.LCD._BCM due to previous error (AE_NOT_FOUND) (20190816/psparse-531)
ACPI Error: Evaluating _BCM failed (20190816/video-357)
My System: ASRock B450 PRO4 Mainboard, AMD Ryzen 3 2200G, Ubuntu 18.04, Kernel 5.4.0-45-generic, amdgpu is loaded… Perhaps someone can help please.
lshw -c video
*-display
description: VGA compatible controller
product: Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
physical id: 0
bus info: pci@0000:09:00.0
version: c8
width: 64 bits
clock: 33MHz
capabilities: pm pciexpress msi msix vga_controller bus_master cap_list rom
configuration: driver=amdgpu latency=0
resources: irq:63 memory:c0000000-cfffffff memory:d0000000-d01fffff ioport:f000(size=256) memory:fce00000-fce7ffff memory:c0000-dffff
guiverc
26.8k4 gold badges43 silver badges68 bronze badges
asked Sep 3, 2020 at 12:43
2
The ACPI driver attempted to evaluate (execute) the ACPI brightness control method for the screen but this failed because the ACPI AML byte code in your firmware did not have the object _SB.PCI0.GP17.VGA.LCD._BCM.AFN7 defined for some reason. The upshot of all of this is that the ACPI brightness control won’t work. This is a firmware issue, I do not know of any workarounds apart from checking to see if you can get an updated BIOS firmware that may fix this.
answered Sep 3, 2020 at 12:48
Colin Ian KingColin Ian King
17.9k3 gold badges58 silver badges69 bronze badges
BIOS
ASRock B450 PRO4
You have BIOS version 4.20.
ASRock does NOT recommend updating to this BIOS if Pinnacle, Raven or Summit Ridge CPU is being used on your system.
There’s an older BIOS available, version 3.50, dated 7/25/2019, (see note below), and it can be downloaded here.
Note: Confirm that I have the correct web page for your motherboard.
Note: Take note of the warnings about some CPUs and BIOS updates. You have AMD Ryzen 3 2200G (Raven Ridge). See the CPU Support page.
Note: Have good backups before updating the BIOS.
answered Sep 3, 2020 at 13:18
5
I have a different mainboard but a very similar error message:
ACPI: _SB_.PCI0.GP17.VGA_.LCD_: _BCM evaluation failed
My conclusion and fix: The ACPI backlight driver does not work with my mainboard, this seems to be a firmware issue. But you can pass different options to the kernel parameter acpi_backlight
. In my case I choose
acpi_backlight=vendor
to enable a vendor specific driver (which I do not use though). The error message is gone. This wiki has some good hints as well.
answered Sep 12, 2022 at 12:05
2
My Ubuntu 18.04 system has been working fine for quite some time (a few years). It suddenly threw up this error. Causes the system to auto-reboot several time. Sometimes it is able to boot into the login but even after login, it is behaving in a cranky manner. What gives?
linux kernel 5.4.0-42-generic
Update:
-
The BIOS was updated and that resolved the crazy auto-reboot issue and made the system usable.
-
I found that this Error appears in the dmesg log of both 18.04 and 16.04. Below is a more detailed list of the ACPI error msg (I found some related ACPI msgs was issued but without the ACPI syntax). It seems the issue pertains to the method _GTF. What is that and what does it do? Also, what is a DSSP?
More details from dmesg on the error:
[ 1.201570] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.PRT0._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.201575] No Local Variables are initialized for Method [_GTF]
[ 1.201576] No Arguments are initialized for method [_GTF]
[ 1.201577] ACPI Error: Aborting method _SB.PCI0.SAT0.PRT0._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-531)
[ 1.205307] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.PRT0._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.205311] No Local Variables are initialized for Method [_GTF]
[ 1.205312] No Arguments are initialized for method [_GTF]
[ 1.205313] ACPI Error: Aborting method _SB.PCI0.SAT0.PRT0._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-531)
[ 1.249944] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.PRT1._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.249949] No Local Variables are initialized for Method [_GTF]
[ 1.249950] No Arguments are initialized for method [_GTF]
[ 1.249951] ACPI Error: Aborting method _SB.PCI0.SAT0.PRT1._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-531)
[ 1.333524] ACPI BIOS Error (bug): Could not resolve symbol [_SB.PCI0.SAT0.PRT1._GTF.DSSP], AE_NOT_FOUND (20190816/psargs-330)
[ 1.333529] No Local Variables are initialized for Method [_GTF]
[ 1.333530] No Arguments are initialized for method [_GTF]
[ 1.333531] ACPI Error: Aborting method _SB.PCI0.SAT0.PRT1._GTF due to previous error (AE_NOT_FOUND) (20190816/psparse-531)
- Forum
- The Ubuntu Forum Community
- Ubuntu Official Flavours Support
- Installation & Upgrades
- [ubuntu] acpi bios error bug could not resolve symbol
-
acpi bios error bug could not resolve symbol
When booting Ubuntu 20.04 I get this issue since I updated today using Ubuntu’s auto updater.
https://ibb.co/MhY6pLt
It continues booting after showing this error.
How can I fix it?
My system specs:
Intel I3 10100
16 GB DDR4 Ram (2666 MHZ)
Nvidia GTX 1060 (3GB VRam)
Ubuntu 20.04 (64 bit, Desktop)
500 GB M.2 SSD Storage
-
Re: acpi bios error bug could not resolve symbol
Code:
sudo nano /etc/default/grub
Change «quiet splash» to «quiet splash loglevel=3»
Save
Then sudo update-grub
-
Re: acpi bios error bug could not resolve symbol
-
Re: acpi bios error bug could not resolve symbol
Originally Posted by pantazi
Did I help?
Your suggestion was not in vain. It helped me.
These warning messages are somewhat peculiar because it seems to depend on the kernel being used.
The messages started appearing on my PC if I use a kernel later than 5.15.0-33-generic.Code:
edited@edited-22-04:~$ ls /boot | grep vmlinuz- vmlinuz-5.15.0-33-generic messages not displayed vmlinuz-5.15.0-39-generic messages displayed vmlinuz-5.15.0-41-generic messages displayed edited@edited-22-04:~$
Anyway, I added the Grub parameter loglevel=3 and the messages are suppressed.
Nothing untoward has appeared since using your suggestion approx 48 hours ago.I also read some internet articles about log levels but my eyes glazed over.
My vision returned after sitting in a comfy chair and sipping a glass of beer.Thanks for the suggestion.
Couple of bug reports:-
https://bugs.launchpad.net/ubuntu/+s…x/+bug/1981933
https://bugs.launchpad.net/ubuntu/+s…5/+bug/1981910
-
Re: acpi bios error bug could not resolve symbol
Thanks T41,
Glad it helped, it happened to me on the last update and I remembered reading about the bug. Took a little researching but I found the answer.
As you found, it only suppresses the information but it tidies up the booting up screen.
Appreciate the humour
Bookmarks
Bookmarks

Posting Permissions
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, 9480:57:80:e8, XID 2c9, IRQ 29
[ 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
My 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 blame
Catchpole 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 blame
gives:
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
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>
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

Ярослав Батуев
При загрузке Ubuntu на ПК сначала вылез черный экран, где показано, что загрузилось, а что нет (как он хоть называется?). В нем я и увидел у одного из пунктов вместо [OK] [FAILED]. Что там было написано разобрать не успел, но в логах написано следующее:
...
[color=green][ 1.536929][/color] ata3: SATA link down (SStatus 4 SControl 300)
[color=green][ 1.537390][/color] ACPI BIOS Error (bug): [color=red]Could not resolve [_SB.PCI0.SAT0.PRT1._GTF.DSSP], AE_NOT_FOUND (20180531/psargs-330)[/color]
[color=green][ 1.537397][/color] No Local Variables are initialized for Method [_GTF]
[color=green][ 1.537398][/color] No Arguments are initialized for method [_GTF]
[color=green][ 1.537399][/color] ACPI Error: [color=red]Method parse/execution failed _SB.PCI0.SAT0.PRT1._GTF, AE_NOT_FOUND (20180531/psparse-516)[/color]
[color=green][ 1.537847][/color] ata2.00: ATA-8: TOSHIBA HDWD110, MS2OA8J0, max UDMA/133
[color=green][ 1.537848][/color] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[color=green][ 1.538776][/color] ACPI BIOS Error (bug): [color=red]Could not resolve [_SB.PCI0.SAT0.PRT1._GTF.DSSP], AE_NOT_FOUND (20180531/psargs-330)[/color]
[color=green][ 1.538782][/color] No Local Variables are initialized for Method [_GTF]
[color=green][ 1.538782][/color] No Arguments are initialized for method [_GTF]
[color=green][ 1.538784][/color] ACPI Error: [color=red]Method parse/execution failed _SB.PCI0.SAT0.PRT1._GTF, AE_NOT_FOUND (20180531/psparse-516)[/color]
[color=green][ 1.539229][/color] ata2.00: configured for UDMA/133
[color=green][ 1.539744][/color] ACPI BIOS Error (bug): [color=red]Could not resolve [_SB.PCI0.SAT0.PRT0._GTF.DSSP], AE_NOT_FOUND (20180531/psargs-330)[/color]
[color=green][ 1.539749][/color] No Local Variables are initialized for Method [_GTF]
[color=green][ 1.539750][/color] No Arguments are initialized for method [_GTF]
[color=green][ 1.539751][/color] ACPI Error: [color=red]Method parse/execution failed _SB.PCI0.SAT0.PRT0._GTF, AE_NOT_FOUND (20180531/psparse-516)[/color]
[color=green][ 1.539757][/color] ata1.00: ATAPI: ATAPI iHAS124 F, CL9F, max UDMA/133
[color=green][ 1.540748][/color] ACPI BIOS Error (bug): [color=red]Could not resolve [_SB.PCI0.SAT0.PRT0._GTF.DSSP], AE_NOT_FOUND (20180531/psargs-330)[/color]
[color=green][ 1.540754][/color] No Local Variables are initialized for Method [_GTF]
[color=green][ 1.540754][/color] No Arguments are initialized for method [_GTF]
[color=green][ 1.540756][/color] ACPI Error: [color=red]Method parse/execution failed _SB.PCI0.SAT0.PRT0._GTF, AE_NOT_FOUND (20180531/psparse-516)[/color]
[color=green][ 1.540762][/color] ata1.00: configured for UDMA/133
...
На сколько вообще эти ошибки опасны и как их править?
ТС не появлялся на Форуме более трех месяцев по состоянию на 13/02/2020 (последняя явка: 19/09/2019). Модератором раздела принято решение закрыть тему.
—zg_nico
« Последнее редактирование: 13 Февраля 2020, 00:13:48 от zg_nico »
Как правильно задавать вопросы
Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 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