After googling, I found the relevant Dell docuentaion about restoring the BIOS using CTRL ESC.
Guess what ?
Changed nothing. Still the same set of errors :
ACPI Error: Aborting method \_SB.PCI0.SPI1.FPNT._CRS due to previous error (AE_AML_INVALID_RESOURCE_TYPE) (20190703/psparse-529)
ACPI Error: Method execution failed \_SB.PCI0.SPI1.FPNT._CRS due to previous error (AE_AML_INVALID_RESOURCE_TYPE) (20190703/uteval-68)
ACPI Error: Aborting method \_SB.PCI0.SPI2.FPNT._CRS due to previous error (AE_AML_INVALID_RESOURCE_TYPE) (20190703/psparse-529)
ACPI Error: Method execution failed \_SB.PCI0.SPI2.FPNT._CRS due to previous error (AE_AML_INVALID_RESOURCE_TYPE) (20190703/uteval-68)
ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20190703/nsarguments-59)
So I'm left with the same problem but I've gort the Expert Advice and Help ™
Come one, Dell, try again.
So, yesterday I've got another message from a Tech Expert. Here it is (I still have problems responding to the private messages) :
Please follow below link and suggest you forgo those steps for how to disable ACPI in BIOS
If not found then advise also make BiOS default and save changes and check
Also suggest you
turn on your computer press F2 goto your BIOS
Then go to Advance Select ATA Instead Of AHCPI Save the setting then try to reboot.
if Not solved you can check this options
This time the hint is to DISABLE the ACPI subsystem entirely. If yo do not want to hear the message, kill the messenger. Brilliant !
And, you suggest I reinstall my whole system to solve a bug which is embedded in the machine software. Do you think this will work ?
Have you, Sir, tried to use a modern computer without ACPI ? And what was your experience ? Nice ? Fair, Poor ? Terrible ? or not usable at all....
Please do not try to solve a bug by killing the software containing it.
Report these bugs to Dell Labs and ask them, kindly, as I do, to solve them and provide a correct and functional BIOS and corresponding Kernel patches for the mainstream kernel.
While waiting, I sincerely wish you a nice and bright day.
And stay safe.
So got a new message. It says :
Advice to check if Ubuntu 16.04LTS version compatible with your Hardware. Please go below link from ubuntu. You can find your hardware or model supported or not.
Also suggest for Install ubuntu with older version and check. if persist same error then advise you Recover the BIOS as earlier suggested.
First of all, I bought this machine directly from Dell. I bought it with Ubuntu 16.04LTS installed. It had an OEM kernel and some customized modules installed. When I bought it, the version of Ubuntu installed was already obsolete (18.04LTS was then current, so 16.04 was near end of life) but despite this, Dell delivered a machine with it. On these machine some hardware was non functional.... Cool....
But I guess it was supported, because Dell won't sell a machine with unsupported software ? Or am I wrong ?
And Dell banned software upgrade. Really cool !
As I need this machine, I decided to do what Dell did not : upgrade to get the latest security software and a current Ubuntu OS. Are you still running Windows Vista ? I presume not....
I was thinking that Dell did not provide specific Kernel or software because it had been merged in the main kernel line. So going to newer Ubuntu would/could solve issues.
Alas, I'm very wrong. Dell decided to drop it's machine altogether and let their customers in the wild. Fine.
Now, there is a new long term support available : 20.04 and 16.04 is dying.
I _do_ hope Dell finish the job it has started and fix their software to provide decent ACPI support on their machines. And make them usable... It is quite time....
as per the BIOS recover, I say it again. I did it. It changes nothing. The bug are still here.It is a waste of time.
So please, I _do_repeat myself. Ask Dell Labs to fix their software. Or provide the code to make it work in the mainstream Linux kernel.
Have a nice day.
Go ask on the Linux kernel mailing-lists.
Perhaps someone from Dell is reading those. That's where kernel work is discussed. I don't view support people as very competent, sorry. They are most of the time reading scripts on a screen, some are good, most are not. And if you talk of anything but Windows their incompetence shows.
<Non-public info removed>
You can re-apply the BIOS. Then, it is advised to go into the bios and reset it to default values.
Then redo any changes you might have done if you wanted to have something turned off there.
Not sure NVRAM reset will help but why not. It won't kill the machine, so you can try that.
The reported message will only be fixed with a proper BIOS fix so it doesn't trigger the kernel parsing which is done according to UEFI spec.
Seeing similar in a Vostro 3491, with BIOS 1.8.0 (dated 24 March 2020), kernel 5.6.13 on Fedora 32:
ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x00000003D) is beyond end of object (length 0x10) (20200110/exoparg2-393) ACPI Error: Aborting method \_SB.GINF due to previous error (AE_AML_PACKAGE_LIMIT) (20200110/psparse-529) ACPI Error: Aborting method \_SB.GADR due to previous error (AE_AML_PACKAGE_LIMIT) (20200110/psparse-529) ACPI Error: Aborting method \_SB.SGOV due to previous error (AE_AML_PACKAGE_LIMIT) (20200110/psparse-529) ACPI Error: Aborting method \_SB.CGWR due to previous error (AE_AML_PACKAGE_LIMIT) (20200110/psparse-529) ACPI Error: Aborting method \_SB.TBFP due to previous error (AE_AML_PACKAGE_LIMIT) (20200110/psparse-529) ACPI Error: Aborting method \_SB.WMTF.WMTF due to previous error (AE_AML_PACKAGE_LIMIT) (20200110/psparse-529)
No idea what the adverse effect of this is (\_SB.TBFP seems to be related to Thunderbolt, which this machine doesn't have), or how to provoke it. Otherwise the notebook hasn't put a foot wrong (sleeps and resumes, etc.).
I've opened a kernel bug against this to have the ACPI experts look it over, but as it says this likely is a coding defect in the ACPI tables which Dell should fix -- and no amount of fiddling in UEFI setup will change this. There are other ACPI bugs in the firmware related to fan control via sysfs (the fan works normally automatically though).
Each ACPI entry reports its size. Then, the kernel parses each and if the contents are smaller than the declared size, you will see those messages. They are Warnings, essentially. The fix can only be done in the BIOS and since it's warnings but not really missing entries or something very wrong... this is low priority (they might even never fix it, to tell the truth).