Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Se pare că am tras lozul câștigător. Am boot-at cu acpi_no_static_ssdt și a mers. Kernelul a pornit în 1.5s: [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F0120 24 (v02 FUJ ) [0.00] ACPI: XSDT 0xDAFFE170 BC (v01 FUJPC 020B FUJ 0001) [0.00] ACPI: FACP 0xDAFEC000 00010C (v05 FUJPC 020B FUJ 0001) [0.00] ACPI: DSDT 0xDAFEF000 009C75 (v02 FUJFJNB253 020B INTL 20061109) [0.00] ACPI: FACS 0xDAF9D000 40 [0.00] ACPI: SLIC 0xDAFFD000 000176 (v01 FUJPC 020B FUJ 0001) [0.00] ACPI: Ignoring installation of SSDT at DAFFC000 [0.00] ACPI: Ignoring installation of SSDT at DAFFB000 [0.00] ACPI: Ignoring installation of SSDT at DAFFA000 [0.00] ACPI: Ignoring installation of SSDT at DAFF9000 [0.00] ACPI: HPET 0xDAFEB000 38 (v01 FUJPC 020B FUJ 0001) [0.00] ACPI: APIC 0xDAFEA000 98 (v03 FUJPC 020B FUJ 0001) [0.00] ACPI: MCFG 0xDAFE9000 3C (v01 FUJPC 020B FUJ 0001) [0.00] ACPI: FPDT 0xDAFE8000 64 (v01 FUJPC 020B FUJ 0001) [0.00] ACPI: ASF! 0xDAFEE000 A5 (v32 FUJPC 020B FUJ 0001) [0.00] ACPI: Ignoring installation of SSDT at DAFE7000 [0.00] ACPI: Ignoring installation of SSDT at DAFE6000 [0.00] ACPI: UEFI 0xDAFE5000 3E (v01 FUJPC 020B FUJ 0001) ... [0.696568] ACPI: Added _OSI(Module Device) [0.696573] ACPI: Added _OSI(Processor Device) [0.696577] ACPI: Added _OSI(3.0 _SCP Extensions) [0.696581] ACPI: Added _OSI(Processor Aggregator Device) [0.698461] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored [0.698621] ACPI: Dynamic OEM Table Load: [0.698819] ACPI: SSDT 0x8DBDD89B4000 000CA9 (v02 FUJWin8Ssdt 0001 INTL 20061109) [0.702928] ACPI : EC: EC started [0.702934] ACPI : EC: interrupt blocked [0.702964] ACPI: \_SB_.PCI0.LPCB.EC__: Used as first EC [0.702969] ACPI: \_SB_.PCI0.LPCB.EC__: GPE=0x17, EC_CMD/EC_SC=0x66, EC_DATA=0x62 [0.702976] ACPI: \_SB_.PCI0.LPCB.EC__: Used as boot DSDT EC to handle transactions [0.702982] ACPI: Interpreter enabled [0.703018] ACPI: (supports S0 S3 S4 S5) [0.703022] ACPI: Using IOAPIC for interrupt routing [0.703055] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [0.709563] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-3e]) Văd că se plânge de niște treburi, dar bateria merge și nu mai am efectul de time warp pe care îl aveam cu acpi=off, așa că sunt fericit! [9.483986] ACPI Warning: SystemIO range 0x0428-0x042F conflicts with OpRegion 0x0400-0x047F (\_SB.PCI0.LPCB.PMIO) (20160831/utaddress-247) [9.483992] ACPI: If an ACPI driver is available for this device, you should use it instead of the nati ve driver [9.483995] ACPI Warning: SystemIO range 0x0540-0x054F conflicts with OpRegion 0x0500-0x054B (\_SB.PCI0.LPCB.OGIO) (20160831/utaddress-247) [9.483999] ACPI: If an ACPI driver is available for this device, you should use it instead of the nati ve driver [9.484000] ACPI Warning: SystemIO range 0x0530-0x053F conflicts with OpRegion 0x0500-0x054B (\_SB.PCI0.LPCB.OGIO) (20160831/utaddress-247) [9.484003] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [9.484004] ACPI Warning: SystemIO range 0x0500-0x052F conflicts with OpRegion 0x0500-0x054B (\_SB.PCI0.LPCB.OGIO) (20160831/utaddress-247) [9.484007] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver Trebuia să fi săpat mai mult acum 2 ani... Weekend plăcut! On Thu, Mar 1, 2018 at 12:27 PM, Adrian Popa wrote: > Ok, e timpul pentru un update. Luna care a trecut m-am tot luptat cu > upgrade-ul de kernel. > > Din MSDOS nu a vrut și pace. > Am încercat cu un GandalfPE (Windows 10 bootabil) și am reușit să fac > update la Bios 2.07JJ. Din păcate update-ul la 2.11 nu a mers. Am fost > nevoit să pun un windows 10 pe un HDD și de acolo am reușit să instalez > update-ul la 2.11. Yay! Din păcate, update-ul de 2.16 nu merge - dă eroare > că nu găsește un fișier care e în directorul updater-ului. > Am încercat să instalez DeskUpdater, care e un tool al lui Fujitsu pentru > update de drivere (https://support.ts.fujitsu.com/DeskUpdate/Index.asp), > dar ghinion, Windows 10 nu e suportat. Nu am chef să pun Windows 7 să > reîncerc... > > Din păcate cu BIOS 2.11 nu se vede nici o diferență la boot în linux. > Varianta cu ținutul laptopului
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Ok, e timpul pentru un update. Luna care a trecut m-am tot luptat cu
upgrade-ul de kernel.
Din MSDOS nu a vrut și pace.
Am încercat cu un GandalfPE (Windows 10 bootabil) și am reușit să fac
update la Bios 2.07JJ. Din păcate update-ul la 2.11 nu a mers. Am fost
nevoit să pun un windows 10 pe un HDD și de acolo am reușit să instalez
update-ul la 2.11. Yay! Din păcate, update-ul de 2.16 nu merge - dă eroare
că nu găsește un fișier care e în directorul updater-ului.
Am încercat să instalez DeskUpdater, care e un tool al lui Fujitsu pentru
update de drivere (https://support.ts.fujitsu.com/DeskUpdate/Index.asp),
dar ghinion, Windows 10 nu e suportat. Nu am chef să pun Windows 7 să
reîncerc...
Din păcate cu BIOS 2.11 nu se vede nici o diferență la boot în linux.
Varianta cu ținutul laptopului în hibernate to disk nu e viabilă pentru că
la trezire oricum trebuie să booteze kernelul și aștept 40s. :(
N-am încercat să fac update de bios din WINE (deși presupun că nu o să
meargă că pare să folosească chestii low-level)...
Planul F, la care am ajuns e să mai bibilesc parametrii ACPI ai
kernel-ului, poate îl conving să nu mai piardă vremea la inițializare:
acpi= [HW,ACPI,X86,ARM64]
Advanced Configuration and Power Interface
Format: { force | on | off | strict | noirq | rsdt |
copy_dsdt }
force -- enable ACPI if default was off
on -- enable ACPI but allow fallback to DT [arm64]
off -- disable ACPI if default was on
noirq -- do not use ACPI for IRQ routing
strict -- Be less tolerant of platforms that are not
strictly ACPI specification compliant.
rsdt -- prefer RSDT over (default) XSDT
copy_dsdt -- copy DSDT to memory
For ARM64, ONLY "acpi=off", "acpi=on" or "acpi=force"
are available
See also Documentation/power/runtime_pm.txt, pci=noacpi
acpi_apic_instance= [ACPI, IOAPIC]
Format:
2: use 2nd APIC table, if available
1,0: use 1st APIC table
default: 0
acpi_backlight= [HW,ACPI]
acpi_backlight=vendor
acpi_backlight=video
If set to vendor, prefer vendor specific driver
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
of the ACPI video.ko driver.
acpi_force_32bit_fadt_addr
force FADT to use 32 bit addresses rather than the
64 bit X_* addresses. Some firmware have broken 64
bit addresses for force ACPI ignore these and use
the older legacy 32 bit addresses.
acpica_no_return_repair [HW, ACPI]
Disable AML predefined validation mechanism
This mechanism can repair the evaluation result to make
the return objects more ACPI specification compliant.
This option is useful for developers to identify the
root cause of an AML interpreter issue when the issue
has something to do with the repair mechanism.
acpi.debug_layer= [HW,ACPI,ACPI_DEBUG]
acpi.debug_level= [HW,ACPI,ACPI_DEBUG]
Format:
CONFIG_ACPI_DEBUG must be enabled to produce any ACPI
debug output. Bits in debug_layer correspond to a
_COMPONENT in an ACPI source file, e.g.,
#define _COMPONENT ACPI_PCI_COMPONENT
Bits in debug_level correspond to a level in
ACPI_DEBUG_PRINT statements, e.g.,
ACPI_DEBUG_PRINT((ACPI_DB_INFO, ...
The debug_level mask defaults to "info". See
Documentation/acpi/debug.txt for more information about
debug layers and levels.
Enable processor driver info messages:
acpi.debug_layer=0x2000
Enable PCI/PCI interrupt routing info messages:
acpi.debug_layer=0x40
Enable AML "Debug" output, i.e., stores to the Debug
object while interpreting AML:
acpi.debug_layer=0x acpi.debug_level=0x2
Enable all messages related to ACPI hardware:
acpi.debug_layer=0x2 acpi.debug_level=0x
Some values produce so much output that the system is
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Mulțumesc pentru sfaturi! 2018-02-05 22:16 GMT+02:00 Dumitru Ciobarcianu : > On 05-Feb-18 11:15 AM, Adrian Popa wrote: > > Legat de hibernare - ca să meargă trebuie să am swap partition > ram? Sau > > care e requirement-ul? > > Nu m-am mai uitat de mult prin subsistemul de suspend al linux însă > ultima oară când am verificat, primul lucru pe care îl face este să facă > drop la caches (nu are sens să pierzi timpul cu scrisul la atâta > informație în swap) iar la scrierea efectivă a informației "utile" se > face un minim de compresie (tot din motivul "timp", discul este cea mai > lentă parte a sistemului, cu cât ai mai puțin de scris cu atât se > termină operațiunea mai repede). > > Mai multe informații la: > https://www.kernel.org/doc/Documentation/power/interface.txt > Citez: > "/sys/power/image_size controls the size of hibernation images. > [...] > Reading from this file returns the current image size limit, which is > set to around 2/5 of available RAM by default." > > Dumitru "de cele mai multe ori prefer suspend-to-ram" C. > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
On 05-Feb-18 11:15 AM, Adrian Popa wrote: > Legat de hibernare - ca să meargă trebuie să am swap partition > ram? Sau > care e requirement-ul? Nu m-am mai uitat de mult prin subsistemul de suspend al linux însă ultima oară când am verificat, primul lucru pe care îl face este să facă drop la caches (nu are sens să pierzi timpul cu scrisul la atâta informație în swap) iar la scrierea efectivă a informației "utile" se face un minim de compresie (tot din motivul "timp", discul este cea mai lentă parte a sistemului, cu cât ai mai puțin de scris cu atât se termină operațiunea mai repede). Mai multe informații la: https://www.kernel.org/doc/Documentation/power/interface.txt Citez: "/sys/power/image_size controls the size of hibernation images. [...] Reading from this file returns the current image size limit, which is set to around 2/5 of available RAM by default." Dumitru "de cele mai multe ori prefer suspend-to-ram" C. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Incearca sa pui intai 2.07FJJ (25/02/2013) Abia apoi sa pui 2.11 (15/07/2014) si la urma 2.16 (05/06/2017) nu poti sa sari de la 2.04 la 2.16 e obligatoriu sa treci prin 2.07 Succes! Pe 5 februarie 2018, 11:15, Adrian Popa a scris: > Mulțumesc tuturor. > Se pare că nu am ultimul BIOS, am 2.04. O să mai încerc să îi fac upgrade > la ultima versiune, dar din păcate installerul din DOS a crash-uit, deci > trebuie să fac rost de un windows și să încerc așa... > > Da, sunt de acord că fără ACPI o să fie greu... :) > Legat de hibernare - ca să meargă trebuie să am swap partition > ram? Sau > care e requirement-ul? > > 2018-02-04 19:53 GMT+02:00 Dumitru Ciobarcianu < > dumitru.ciobarci...@ines.ro> > : > > > On 04-Feb-18 17:28 PM, Adrian Popa wrote: > > > Scuze că reînviu threadul ăsta după 2+ ani, dar după doi ani de trăit > cu > > > problema mi-a ajuns cuțitul la os și am început săpăturile. > > > > > [0.700443] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored > > > > Cine a scris BIOS-ul trebuie trimis la sapă. > > > > Vezi dacă te ajută pașii de aici: > > > > https://wiki.archlinux.org/index.php/DSDT > > > > (nu distribuția contează). > > > > > > Dumitru "încă nu m-am hotărât cine e mai lame, BIOS sau PHP" C. > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > > > > > ___ > > RLUG mailing list > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Mulțumesc tuturor. Se pare că nu am ultimul BIOS, am 2.04. O să mai încerc să îi fac upgrade la ultima versiune, dar din păcate installerul din DOS a crash-uit, deci trebuie să fac rost de un windows și să încerc așa... Da, sunt de acord că fără ACPI o să fie greu... :) Legat de hibernare - ca să meargă trebuie să am swap partition > ram? Sau care e requirement-ul? 2018-02-04 19:53 GMT+02:00 Dumitru Ciobarcianu : > On 04-Feb-18 17:28 PM, Adrian Popa wrote: > > Scuze că reînviu threadul ăsta după 2+ ani, dar după doi ani de trăit cu > > problema mi-a ajuns cuțitul la os și am început săpăturile. > > > [0.700443] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored > > Cine a scris BIOS-ul trebuie trimis la sapă. > > Vezi dacă te ajută pașii de aici: > > https://wiki.archlinux.org/index.php/DSDT > > (nu distribuția contează). > > > Dumitru "încă nu m-am hotărât cine e mai lame, BIOS sau PHP" C. > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
On 04-Feb-18 17:28 PM, Adrian Popa wrote: > Scuze că reînviu threadul ăsta după 2+ ani, dar după doi ani de trăit cu > problema mi-a ajuns cuțitul la os și am început săpăturile. > [0.700443] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored Cine a scris BIOS-ul trebuie trimis la sapă. Vezi dacă te ajută pașii de aici: https://wiki.archlinux.org/index.php/DSDT (nu distribuția contează). Dumitru "încă nu m-am hotărât cine e mai lame, BIOS sau PHP" C. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Un update de BIOS ai incercat? Ce versiune ai? Pe site la ei apare 2.16 (05/06/2017) cu stima, Sebastian Georgescu Pe 4 februarie 2018, 17:28, Adrian Popa a scris: > Scuze că reînviu threadul ăsta după 2+ ani, dar după doi ani de trăit cu > problema mi-a ajuns cuțitul la os și am început săpăturile. > > Mesajele la boot arată cam așa: > [0.698347] ACPI: Added _OSI(Module Device) > [0.698351] ACPI: Added _OSI(Processor Device) > [0.698355] ACPI: Added _OSI(3.0 _SCP Extensions) > [0.698359] ACPI: Added _OSI(Processor Aggregator Device) > [0.700443] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored > [0.700603] ACPI: Dynamic OEM Table Load: > [0.700831] ACPI: SSDT 0x96F5189B5000 000CA9 (v02 FUJWin8Ssdt > 0001 INTL 20061109) > [ 39.359608] ACPI: Dynamic OEM Table Load: > [ 39.359624] ACPI: SSDT 0x96F518A2A000 0008EA (v01 PmRef Cpu0Cst > 3001 INTL 20061109) > [ 39.360035] ACPI: Dynamic OEM Table Load: > [ 39.360046] ACPI: SSDT 0x96F518A26C00 000303 (v01 PmRef ApIst > 3000 INTL 20061109) > [ 39.360316] ACPI: Dynamic OEM Table Load: > [ 39.360326] ACPI: SSDT 0x96F518A1D600 000119 (v01 PmRef ApCst > 3000 INTL 20061109) > [ 39.362110] ACPI : EC: EC started > [ 39.362116] ACPI : EC: interrupt blocked > > Am crezut că SSDT are legătură cu SSD-ul, așa că l-am schimbat cu un HDD > normal, dar problema a persistat. Am încercat și cu alte kernele (4.9) și > alte distribuții (SystemRescueCD) și problema a persistat. > Așa că pasul 2 a fost să bootez cu acpi=off - și surpriză - a bootat în 10 > secunde. > Problema e că de când am bootat cu acpi=off, am următoarele dude: > 1. Nu mai vede bateria (upower -d nu o mai arata) > 2. Am problema cu timerele. Ocazional "ceasul" bate mult mai repede și asta > duce la duplicarea tastelor apăsate > 3. Probabil mai sunt o tonă de probleme pe care nu le-am descoperit încă. > > Întrebarea mea e - pot boota cu acpi=off și să-l activez după boot? Mă > deranjează doar că la boot îi ia mult. În BIOS nu am văzut ceva relevant > legat de ACPI. > Alte idei? > > Mersi! > > 2015-05-10 11:20 GMT+03:00 Adrian Popa : > > > Timpul măsurat de boot este fără quiet și splash. Outputul era din alt > > boot. > > > > @Mihai - mulțumesc de sugestie - o să caut să văd cu ce block size > citește > > kernelul grub-ul. > > > > 2015-05-09 14:41 GMT+03:00 : > > > >> On Saturday 09 May 2015 10:29:19 Petru Ratiu wrote: > >> > 2015-05-09 10:24 GMT+03:00 Adrian Popa : > >> > > Salutare, > >> > > > >> > > Am un laptop Fujitsu S782, i7, SSD, 4G RAM care are un delay de > aprox > >> 30s > >> > > în momentul în care bootează un kernel Ubuntu (am încercat cu > kernelul > >> > > default pe 14.04, 14.10 și 15.04). Delay-ul de 30s îl măsor de când > >> > > selectez boot în grub până când încep să văd pe ecran primele mesaje > >> de > >> > > boot ale kernelului (momentan 3.19.0-16-generic #16-Ubuntu SMP). > >> > > > >> > > adrianp@stingray:~$ cat /proc/cmdline > >> > > BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic > >> > > root=UUID=84371afa-e0bf-4d67-8622-87b20fdeaa6e ro quiet splash > >> > > vt.handoff=7 > >> > > > >> > > A mai întâlnit cineva ceva asemănător? O să încerc să bootez și alte > >> > > distribuții, să văd dacă e o diferență, dar la ce ar trebui să mă > uit > >> în > >> > > kernel config? > >> > > >> > In primul rand scoate "quiet" si "splash" de la argumentele de boot > >> > (recunosc ca nu stiu sigur cum se comporta in ubuntu fara plymouth sau > >> cum > >> > se cheama splash-screenul ala, dar ar trebui sa se descurce). Sunt > >> aproape > >> > sigur ca o sa vezi dupa ce anume sta. > >> Din cate imi aduc aminte am avut si eu problema asta dar pe slackware nu > >> ne-au > >> dat grub decat in "extra" :) > >> Exista o optiune "compact" in lilo.conf care a rezolvat problema. > >> In principiu e vorba de felul in care vede device-ul de boot , nu mai > tin > >> minte din ce motiv dar citeste in blocuri foarte mici si din cauza asta > >> incarca foarte greu kernelul. Presupun ca exista si pe grub un > echivalent. > >> ___ > >> RLUG mailing list > >> RLUG@lists.lug.ro > >> http://lists.lug.ro/mailman/listinfo/rlug > >> > > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
On 02/04/2018 05:28 PM, Adrian Popa wrote: Scuze că reînviu threadul ăsta după 2+ ani, dar după doi ani de trăit cu problema mi-a ajuns cuțitul la os și am început săpăturile. Mesajele la boot arată cam așa: [0.698347] ACPI: Added _OSI(Module Device) [0.698351] ACPI: Added _OSI(Processor Device) [0.698355] ACPI: Added _OSI(3.0 _SCP Extensions) [0.698359] ACPI: Added _OSI(Processor Aggregator Device) [0.700443] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored [0.700603] ACPI: Dynamic OEM Table Load: [0.700831] ACPI: SSDT 0x96F5189B5000 000CA9 (v02 FUJWin8Ssdt 0001 INTL 20061109) [ 39.359608] ACPI: Dynamic OEM Table Load: [ 39.359624] ACPI: SSDT 0x96F518A2A000 0008EA (v01 PmRef Cpu0Cst 3001 INTL 20061109) [ 39.360035] ACPI: Dynamic OEM Table Load: [ 39.360046] ACPI: SSDT 0x96F518A26C00 000303 (v01 PmRef ApIst 3000 INTL 20061109) [ 39.360316] ACPI: Dynamic OEM Table Load: [ 39.360326] ACPI: SSDT 0x96F518A1D600 000119 (v01 PmRef ApCst 3000 INTL 20061109) [ 39.362110] ACPI : EC: EC started [ 39.362116] ACPI : EC: interrupt blocked Am crezut că SSDT are legătură cu SSD-ul, așa că l-am schimbat cu un HDD normal, dar problema a persistat. Am încercat și cu alte kernele (4.9) și alte distribuții (SystemRescueCD) și problema a persistat. Așa că pasul 2 a fost să bootez cu acpi=off - și surpriză - a bootat în 10 secunde. Problema e că de când am bootat cu acpi=off, am următoarele dude: 1. Nu mai vede bateria (upower -d nu o mai arata) 2. Am problema cu timerele. Ocazional "ceasul" bate mult mai repede și asta duce la duplicarea tastelor apăsate 3. Probabil mai sunt o tonă de probleme pe care nu le-am descoperit încă. Întrebarea mea e - pot boota cu acpi=off și să-l activez după boot? din cite stiu eu, nu. iar in acest context, citez mai jos un mesaj de acum 4 luni de pe o lista la care sint abonat. daca nu gresesc, kernelul la care se refera el va fi acelasi indiferent ca ruleaza pe x86 sau ARM Mă deranjează doar că la boot îi ia mult. eu am un blade ibm la care initializarea dureaza vreo 2 min ... În BIOS nu am văzut ceva relevant legat de ACPI. Alte idei? update bios e probabil unica solutie. si da, stiu, probabil ai deja cea mai recenta versiune :) eu, cind pe calculatorul de acasa am fost in situatia ta, am ales sa utilizez hibernare in loc de power off Iata si citatul promis: Hi all, Most of you know me. For those who don't, I'm Chief ARM Architect at Red Hat and started the internal Red Hat ARM team back in 2011. I've also worked on creating most of the ARM server standards, and with every silicon vendor since their design was a paper napkin drawing. So it is with some authority I can tell you that ARM servers without ACPI have no future. Those of you booting with "acpi=off" are running machines completely in violation of the ARM server specs (which mandate the use of ACPI tables). You can choose to do this, but such configs have never been tested and are completely guaranteed to break randomly in the future when you update the distribution, or the hardware. But not everyone has fully gotten this message. Beginning in the next release of the upstream distro from which CentOS inherits its sources, there is a nasty warning message which will be printed if you boot while attempting to disable ACPI, or even if the platform contains DeviceTree tables (whether used or not). The kernel will also taint itself if it detects the presence of DeviceTree on a platform at all. Going forward, I am instituting logic that will cause the kernel to panic and fail to boot at all when a platform contains a DeviceTree (whether used or not) unless some parameter like "platform_is_broken" is passed to the kernel. This is irrespective of whether you actually boot with ACPI or not. All platforms that aren't simply ACPI must be removed from the face of the earth as quickly as possible and replaced with fully standardized ones compliant with the ARM server specs. The good news is that firmware updates will allow anyone still shipping a DeviceTree to remove it from future platform updates to be compliant. Now is a good time to stop thinking about disabling ACPI. It is only going to get much, much harder to turn it off. Jon. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
On Sunday, February 4, 2018 5:28:28 PM EET Adrian Popa wrote: > Scuze că reînviu threadul ăsta după 2+ ani, dar după doi ani de trăit cu > problema mi-a ajuns cuțitul la os și am început săpăturile. Cu update de BIOS ai incercat? -- Claudiu N. Cismaru ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Scuze că reînviu threadul ăsta după 2+ ani, dar după doi ani de trăit cu problema mi-a ajuns cuțitul la os și am început săpăturile. Mesajele la boot arată cam așa: [0.698347] ACPI: Added _OSI(Module Device) [0.698351] ACPI: Added _OSI(Processor Device) [0.698355] ACPI: Added _OSI(3.0 _SCP Extensions) [0.698359] ACPI: Added _OSI(Processor Aggregator Device) [0.700443] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored [0.700603] ACPI: Dynamic OEM Table Load: [0.700831] ACPI: SSDT 0x96F5189B5000 000CA9 (v02 FUJWin8Ssdt 0001 INTL 20061109) [ 39.359608] ACPI: Dynamic OEM Table Load: [ 39.359624] ACPI: SSDT 0x96F518A2A000 0008EA (v01 PmRef Cpu0Cst 3001 INTL 20061109) [ 39.360035] ACPI: Dynamic OEM Table Load: [ 39.360046] ACPI: SSDT 0x96F518A26C00 000303 (v01 PmRef ApIst 3000 INTL 20061109) [ 39.360316] ACPI: Dynamic OEM Table Load: [ 39.360326] ACPI: SSDT 0x96F518A1D600 000119 (v01 PmRef ApCst 3000 INTL 20061109) [ 39.362110] ACPI : EC: EC started [ 39.362116] ACPI : EC: interrupt blocked Am crezut că SSDT are legătură cu SSD-ul, așa că l-am schimbat cu un HDD normal, dar problema a persistat. Am încercat și cu alte kernele (4.9) și alte distribuții (SystemRescueCD) și problema a persistat. Așa că pasul 2 a fost să bootez cu acpi=off - și surpriză - a bootat în 10 secunde. Problema e că de când am bootat cu acpi=off, am următoarele dude: 1. Nu mai vede bateria (upower -d nu o mai arata) 2. Am problema cu timerele. Ocazional "ceasul" bate mult mai repede și asta duce la duplicarea tastelor apăsate 3. Probabil mai sunt o tonă de probleme pe care nu le-am descoperit încă. Întrebarea mea e - pot boota cu acpi=off și să-l activez după boot? Mă deranjează doar că la boot îi ia mult. În BIOS nu am văzut ceva relevant legat de ACPI. Alte idei? Mersi! 2015-05-10 11:20 GMT+03:00 Adrian Popa : > Timpul măsurat de boot este fără quiet și splash. Outputul era din alt > boot. > > @Mihai - mulțumesc de sugestie - o să caut să văd cu ce block size citește > kernelul grub-ul. > > 2015-05-09 14:41 GMT+03:00 : > >> On Saturday 09 May 2015 10:29:19 Petru Ratiu wrote: >> > 2015-05-09 10:24 GMT+03:00 Adrian Popa : >> > > Salutare, >> > > >> > > Am un laptop Fujitsu S782, i7, SSD, 4G RAM care are un delay de aprox >> 30s >> > > în momentul în care bootează un kernel Ubuntu (am încercat cu kernelul >> > > default pe 14.04, 14.10 și 15.04). Delay-ul de 30s îl măsor de când >> > > selectez boot în grub până când încep să văd pe ecran primele mesaje >> de >> > > boot ale kernelului (momentan 3.19.0-16-generic #16-Ubuntu SMP). >> > > >> > > adrianp@stingray:~$ cat /proc/cmdline >> > > BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic >> > > root=UUID=84371afa-e0bf-4d67-8622-87b20fdeaa6e ro quiet splash >> > > vt.handoff=7 >> > > >> > > A mai întâlnit cineva ceva asemănător? O să încerc să bootez și alte >> > > distribuții, să văd dacă e o diferență, dar la ce ar trebui să mă uit >> în >> > > kernel config? >> > >> > In primul rand scoate "quiet" si "splash" de la argumentele de boot >> > (recunosc ca nu stiu sigur cum se comporta in ubuntu fara plymouth sau >> cum >> > se cheama splash-screenul ala, dar ar trebui sa se descurce). Sunt >> aproape >> > sigur ca o sa vezi dupa ce anume sta. >> Din cate imi aduc aminte am avut si eu problema asta dar pe slackware nu >> ne-au >> dat grub decat in "extra" :) >> Exista o optiune "compact" in lilo.conf care a rezolvat problema. >> In principiu e vorba de felul in care vede device-ul de boot , nu mai tin >> minte din ce motiv dar citeste in blocuri foarte mici si din cauza asta >> incarca foarte greu kernelul. Presupun ca exista si pe grub un echivalent. >> ___ >> RLUG mailing list >> RLUG@lists.lug.ro >> http://lists.lug.ro/mailman/listinfo/rlug >> > > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Timpul măsurat de boot este fără quiet și splash. Outputul era din alt boot. @Mihai - mulțumesc de sugestie - o să caut să văd cu ce block size citește kernelul grub-ul. 2015-05-09 14:41 GMT+03:00 : > On Saturday 09 May 2015 10:29:19 Petru Ratiu wrote: > > 2015-05-09 10:24 GMT+03:00 Adrian Popa : > > > Salutare, > > > > > > Am un laptop Fujitsu S782, i7, SSD, 4G RAM care are un delay de aprox > 30s > > > în momentul în care bootează un kernel Ubuntu (am încercat cu kernelul > > > default pe 14.04, 14.10 și 15.04). Delay-ul de 30s îl măsor de când > > > selectez boot în grub până când încep să văd pe ecran primele mesaje de > > > boot ale kernelului (momentan 3.19.0-16-generic #16-Ubuntu SMP). > > > > > > adrianp@stingray:~$ cat /proc/cmdline > > > BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic > > > root=UUID=84371afa-e0bf-4d67-8622-87b20fdeaa6e ro quiet splash > > > vt.handoff=7 > > > > > > A mai întâlnit cineva ceva asemănător? O să încerc să bootez și alte > > > distribuții, să văd dacă e o diferență, dar la ce ar trebui să mă uit > în > > > kernel config? > > > > In primul rand scoate "quiet" si "splash" de la argumentele de boot > > (recunosc ca nu stiu sigur cum se comporta in ubuntu fara plymouth sau > cum > > se cheama splash-screenul ala, dar ar trebui sa se descurce). Sunt > aproape > > sigur ca o sa vezi dupa ce anume sta. > Din cate imi aduc aminte am avut si eu problema asta dar pe slackware nu > ne-au > dat grub decat in "extra" :) > Exista o optiune "compact" in lilo.conf care a rezolvat problema. > In principiu e vorba de felul in care vede device-ul de boot , nu mai tin > minte din ce motiv dar citeste in blocuri foarte mici si din cauza asta > incarca foarte greu kernelul. Presupun ca exista si pe grub un echivalent. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
On Saturday 09 May 2015 10:29:19 Petru Ratiu wrote: > 2015-05-09 10:24 GMT+03:00 Adrian Popa : > > Salutare, > > > > Am un laptop Fujitsu S782, i7, SSD, 4G RAM care are un delay de aprox 30s > > în momentul în care bootează un kernel Ubuntu (am încercat cu kernelul > > default pe 14.04, 14.10 și 15.04). Delay-ul de 30s îl măsor de când > > selectez boot în grub până când încep să văd pe ecran primele mesaje de > > boot ale kernelului (momentan 3.19.0-16-generic #16-Ubuntu SMP). > > > > adrianp@stingray:~$ cat /proc/cmdline > > BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic > > root=UUID=84371afa-e0bf-4d67-8622-87b20fdeaa6e ro quiet splash > > vt.handoff=7 > > > > A mai întâlnit cineva ceva asemănător? O să încerc să bootez și alte > > distribuții, să văd dacă e o diferență, dar la ce ar trebui să mă uit în > > kernel config? > > In primul rand scoate "quiet" si "splash" de la argumentele de boot > (recunosc ca nu stiu sigur cum se comporta in ubuntu fara plymouth sau cum > se cheama splash-screenul ala, dar ar trebui sa se descurce). Sunt aproape > sigur ca o sa vezi dupa ce anume sta. Din cate imi aduc aminte am avut si eu problema asta dar pe slackware nu ne-au dat grub decat in "extra" :) Exista o optiune "compact" in lilo.conf care a rezolvat problema. In principiu e vorba de felul in care vede device-ul de boot , nu mai tin minte din ce motiv dar citeste in blocuri foarte mici si din cauza asta incarca foarte greu kernelul. Presupun ca exista si pe grub un echivalent. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
2015-05-09 10:24 GMT+03:00 Adrian Popa : > Salutare, > > Am un laptop Fujitsu S782, i7, SSD, 4G RAM care are un delay de aprox 30s > în momentul în care bootează un kernel Ubuntu (am încercat cu kernelul > default pe 14.04, 14.10 și 15.04). Delay-ul de 30s îl măsor de când > selectez boot în grub până când încep să văd pe ecran primele mesaje de > boot ale kernelului (momentan 3.19.0-16-generic #16-Ubuntu SMP). > > adrianp@stingray:~$ cat /proc/cmdline > BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic > root=UUID=84371afa-e0bf-4d67-8622-87b20fdeaa6e ro quiet splash vt.handoff=7 > > A mai întâlnit cineva ceva asemănător? O să încerc să bootez și alte > distribuții, să văd dacă e o diferență, dar la ce ar trebui să mă uit în > kernel config? > > In primul rand scoate "quiet" si "splash" de la argumentele de boot (recunosc ca nu stiu sigur cum se comporta in ubuntu fara plymouth sau cum se cheama splash-screenul ala, dar ar trebui sa se descurce). Sunt aproape sigur ca o sa vezi dupa ce anume sta. -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
[rlug] Pornirea kernelului durează 30s pe un Fujitsu S782
Salutare, Am un laptop Fujitsu S782, i7, SSD, 4G RAM care are un delay de aprox 30s în momentul în care bootează un kernel Ubuntu (am încercat cu kernelul default pe 14.04, 14.10 și 15.04). Delay-ul de 30s îl măsor de când selectez boot în grub până când încep să văd pe ecran primele mesaje de boot ale kernelului (momentan 3.19.0-16-generic #16-Ubuntu SMP). adrianp@stingray:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.19.0-16-generic root=UUID=84371afa-e0bf-4d67-8622-87b20fdeaa6e ro quiet splash vt.handoff=7 A mai întâlnit cineva ceva asemănător? O să încerc să bootez și alte distribuții, să văd dacă e o diferență, dar la ce ar trebui să mă uit în kernel config? După boot totul merge corect și rapid (demn de SSD). Mulțumesc de idei! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
