[coreboot] Re: libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS
I think we are also seeing this issue after downstreaming:
https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/1637073
+Matt Delco posted some comments on this CL.
On Tue, Jun 4, 2019 at 1:11 PM Martin Kepplinger wrote:
> Hi,
>
> Just tested a build using this config:
>
> https://github.com/merge/skulls/blob/master/x230/nonfree-defconfig-139b3cef03
> with a recent coreboot (my master branch HEAD is at 0da3a8a91b
> soc/intel/baytrail: set default VBIOS filename and PCI ID)
>
> When selecting "3" or "4" for the secondary payloads like coreinfo in
> Seabios, I always hit this:
> payloads/libpayload/drivers/i8042/keyboard.c: printf("ERROR:
> Keyboard
> reset failed ACK: 0x%x\n", ret);
>
> I get "ERROR: Keyboard reset failed ACK: 0x1".
>
> and I basically have to shutdown.
>
> what's wrong? I think commit 7ae606f57f0b3d450ae748141b0e2367041b27d3
> Paul?
>
> thanks,
> martin
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS
Hi,
Just tested a build using this config:
https://github.com/merge/skulls/blob/master/x230/nonfree-defconfig-139b3cef03
with a recent coreboot (my master branch HEAD is at 0da3a8a91b
soc/intel/baytrail: set default VBIOS filename and PCI ID)
When selecting "3" or "4" for the secondary payloads like coreinfo in
Seabios, I always hit this:
payloads/libpayload/drivers/i8042/keyboard.c: printf("ERROR: Keyboard
reset failed ACK: 0x%x\n", ret);
I get "ERROR: Keyboard reset failed ACK: 0x1".
and I basically have to shutdown.
what's wrong? I think commit 7ae606f57f0b3d450ae748141b0e2367041b27d3
Paul?
thanks,
martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Fwd: Re: Starting the coreboot 4.10 release process
-- Forwarded message - From: Matt B Date: Mon, Jun 3, 2019 at 7:19 PM Subject: Re: [coreboot] Re: Starting the coreboot 4.10 release process To: Mike Banon On a side note, when more than one option is possible, it's good to know which the tester used. Hypothetical example: did someone test the X230 with a vgabios blob or with libgfxinit? If unspecified, or if the default is the vgabiosblob (or nothing at all, as above) then who knows if libgfxinit works? -Matt On Mon, Jun 3, 2019 at 4:21 PM Mike Banon wrote: > Okay, I returned your boards but added a note that "no board_status > report yet". Hopefully you could submit them in the near future, at > least for the archival purposes. And there's a similar question to > someone else who added "Asus P8H61-M Pro" despite that the latest > report for it is one year ago. > > The default config should always be a known good config, unless the > > board isn't well maintained. Needing a specific "good config" is a > > sign of unattended bugs. > Not necessarily: it could be that a default config is bootable for > some board but still somehow inferior. For example, it may boot but > without showing anything on a display, because no VGABIOS specified or > provided. Or i.e. it may be hard to convince the people to enable some > config by default despite it being useful, e.g. a coreinfo secondary > payload. So board_status report is a great way to promote your nice > config, and hopefully the people would share them more > > On Mon, Jun 3, 2019 at 5:28 PM Matt DeVillier > wrote: > > > > I added those devices, all of which I have in my possession and were > tested over the weekend with TOT. I'd not yet had a chance to upload board > status for them, but figured knowing a good range of platforms/boards were > known working just prior to release was useful (and the purpose of the list) > > > > On Mon, Jun 3, 2019 at 9:14 AM Mike Banon wrote: > >> > >> Just noticed that someone included i.e. some Purism Librem devices to > >> a " Recently tested mainboards: " section - but, when I check > >> https://review.coreboot.org/cgit/board-status.git/log/purism , the > >> latest board status for Purism happened even before 4.9 ! And without > >> a recent enough _public_ "board status" report - containing the > >> important info about your build and its' complete configuration - I > >> don't think we could include them to a "recently tested" list, since > >> the other users won't have a chance to reproduce your build by using > >> your configuration. Same question regarding some other of these > >> additions, so removing them from a " Recently tested mainboards: " > >> list, but of course they could be re-added if someone will submit a > >> board_status reports from them. > >> > >> We would like to encourage the board status reporting, and relying on > >> the word of users ( "I tested X board and it worked" ) would not help > >> us to collect the known good configs at our coreboot/board_status > >> repository. > >> > >> To submit a board status report for your board, please run a > >> ./coreboot/util/board_status/board_status.sh script on it. > >> > >> Removed: > >> * Purism Librem 13 v1 > >> * Purism Librem 15 v2 > >> * Purism Librem 13 v2/v3 > >> * Purism Librem 15 v3 > >> * Purism Librem 13 v4 > >> * Purism Librem 15 v4 > >> * Samsung Chromebook 3 (google/celes) > >> * Acer Chromebook R11 (google/cyan) > >> * Google Chromebook Pixel 2013 (google/link) > >> * Toshiba Chromebook 2 (2014) (google/swanky) > >> * Dell Chromebook 13 7310 (google/lulu) > >> * Dell Inspiron Chromebook 14 (google/nami) > >> * Acer Chromebook 14 (google/edgar) > >> * HP Chromebook 13 G1 (google/chell) > >> * Asus Chromebox CN60 (google/panther) > >> * Asus Chromebox CN62 (google/guado) > >> * Asus Chromebox CN65 (google/fizz) > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
Okay, I returned your boards but added a note that "no board_status report yet". Hopefully you could submit them in the near future, at least for the archival purposes. And there's a similar question to someone else who added "Asus P8H61-M Pro" despite that the latest report for it is one year ago. > The default config should always be a known good config, unless the > board isn't well maintained. Needing a specific "good config" is a > sign of unattended bugs. Not necessarily: it could be that a default config is bootable for some board but still somehow inferior. For example, it may boot but without showing anything on a display, because no VGABIOS specified or provided. Or i.e. it may be hard to convince the people to enable some config by default despite it being useful, e.g. a coreinfo secondary payload. So board_status report is a great way to promote your nice config, and hopefully the people would share them more On Mon, Jun 3, 2019 at 5:28 PM Matt DeVillier wrote: > > I added those devices, all of which I have in my possession and were tested > over the weekend with TOT. I'd not yet had a chance to upload board status > for them, but figured knowing a good range of platforms/boards were known > working just prior to release was useful (and the purpose of the list) > > On Mon, Jun 3, 2019 at 9:14 AM Mike Banon wrote: >> >> Just noticed that someone included i.e. some Purism Librem devices to >> a " Recently tested mainboards: " section - but, when I check >> https://review.coreboot.org/cgit/board-status.git/log/purism , the >> latest board status for Purism happened even before 4.9 ! And without >> a recent enough _public_ "board status" report - containing the >> important info about your build and its' complete configuration - I >> don't think we could include them to a "recently tested" list, since >> the other users won't have a chance to reproduce your build by using >> your configuration. Same question regarding some other of these >> additions, so removing them from a " Recently tested mainboards: " >> list, but of course they could be re-added if someone will submit a >> board_status reports from them. >> >> We would like to encourage the board status reporting, and relying on >> the word of users ( "I tested X board and it worked" ) would not help >> us to collect the known good configs at our coreboot/board_status >> repository. >> >> To submit a board status report for your board, please run a >> ./coreboot/util/board_status/board_status.sh script on it. >> >> Removed: >> * Purism Librem 13 v1 >> * Purism Librem 15 v2 >> * Purism Librem 13 v2/v3 >> * Purism Librem 15 v3 >> * Purism Librem 13 v4 >> * Purism Librem 15 v4 >> * Samsung Chromebook 3 (google/celes) >> * Acer Chromebook R11 (google/cyan) >> * Google Chromebook Pixel 2013 (google/link) >> * Toshiba Chromebook 2 (2014) (google/swanky) >> * Dell Chromebook 13 7310 (google/lulu) >> * Dell Inspiron Chromebook 14 (google/nami) >> * Acer Chromebook 14 (google/edgar) >> * HP Chromebook 13 G1 (google/chell) >> * Asus Chromebox CN60 (google/panther) >> * Asus Chromebox CN62 (google/guado) >> * Asus Chromebox CN65 (google/fizz) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
I added those devices, all of which I have in my possession and were tested over the weekend with TOT. I'd not yet had a chance to upload board status for them, but figured knowing a good range of platforms/boards were known working just prior to release was useful (and the purpose of the list) On Mon, Jun 3, 2019 at 9:14 AM Mike Banon wrote: > Just noticed that someone included i.e. some Purism Librem devices to > a " Recently tested mainboards: " section - but, when I check > https://review.coreboot.org/cgit/board-status.git/log/purism , the > latest board status for Purism happened even before 4.9 ! And without > a recent enough _public_ "board status" report - containing the > important info about your build and its' complete configuration - I > don't think we could include them to a "recently tested" list, since > the other users won't have a chance to reproduce your build by using > your configuration. Same question regarding some other of these > additions, so removing them from a " Recently tested mainboards: " > list, but of course they could be re-added if someone will submit a > board_status reports from them. > > We would like to encourage the board status reporting, and relying on > the word of users ( "I tested X board and it worked" ) would not help > us to collect the known good configs at our coreboot/board_status > repository. > > To submit a board status report for your board, please run a > ./coreboot/util/board_status/board_status.sh script on it. > > Removed: > * Purism Librem 13 v1 > * Purism Librem 15 v2 > * Purism Librem 13 v2/v3 > * Purism Librem 15 v3 > * Purism Librem 13 v4 > * Purism Librem 15 v4 > * Samsung Chromebook 3 (google/celes) > * Acer Chromebook R11 (google/cyan) > * Google Chromebook Pixel 2013 (google/link) > * Toshiba Chromebook 2 (2014) (google/swanky) > * Dell Chromebook 13 7310 (google/lulu) > * Dell Inspiron Chromebook 14 (google/nami) > * Acer Chromebook 14 (google/edgar) > * HP Chromebook 13 G1 (google/chell) > * Asus Chromebox CN60 (google/panther) > * Asus Chromebox CN62 (google/guado) > * Asus Chromebox CN65 (google/fizz) > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
On Mon, Jun 3, 2019 at 8:55 AM Mike Banon wrote: > If the upstream edk2 is so bad - have you tried to upstream your set > of patches? It is good that your personal fork/repo is stable, but > inevitably it will always lag behind the upstream, not benefiting from > some new features and bugfixes. Same reason why I didn't want to fork > a coreboot despite having a big set of unofficial patches , instead > trying to upstream them when I have some free time. > given that CorebootPayloadPackage has been removed and replaced with UefiPayloadPackage, there's no point in doing so. If UefiPayloadPkg is functional as-is, then we can certainly switch over to it, but my understanding is that it is not. And I haven't had time to investigate/test myself. > > > On Sun, Jun 2, 2019 at 11:41 PM Matt DeVillier > wrote: > > > > there is no "stable" branch for upstream edk2 though. Previously, > coreboot used an arbitrary commit as stable, and applied ~7 patches on top > if it to make it functional. Even the UDK201x branches don't boot without > patches > > > > On Sun, Jun 2, 2019 at 3:30 PM Lance Zhao wrote: > >> > >> Tianocore master branch build from edk2 will break, but that had been > quite some time. Stable branch is working fine though. > >> > >> On Mon, Jun 3, 2019, 3:28 AM Matt DeVillier > wrote: > >>> > >>> On Sun, Jun 2, 2019 at 1:27 PM Mike Banon wrote: > > > Also, regarding the significant changes: " ### Tianocore UEFI > integrated as payload " . I hope it doesn't mean that Tianocore will > become the default payload, since there are ideological/technical > reasons against this ( I think there's a significant overlap between > the groups of people who love / interested in coreboot and hate UEFI ) > >>> > >>> > >>> the change could be reworded better I think: instead of the stable tag > for Tianocore being pulled from the upstream edk2 github repo and a series > of patches applied, it's now pulled directly from my fork/repo, which is > actually functional on most (x86_64) devices. A few tweaks (like > customizable boot splash) were added as well. > >>> > >>> there is no change to the default payload, only to the defaults for > Tianocore > >>> ___ > >>> coreboot mailing list -- coreboot@coreboot.org > >>> To unsubscribe send an email to coreboot-le...@coreboot.org > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
On 03.06.19 16:13, Mike Banon wrote: Just noticed that someone included i.e. some Purism Librem devices to a " Recently tested mainboards: " section - but, when I check https://review.coreboot.org/cgit/board-status.git/log/purism , the latest board status for Purism happened even before 4.9 ! And without a recent enough _public_ "board status" report - containing the important info about your build and its' complete configuration - I don't think we could include them to a "recently tested" list I have to object. That the boards were tested with a recent revision around the release is still much valuable information. We would like to encourage the board status reporting, and relying on the word of users ( "I tested X board and it worked" ) would not help us to collect the known good configs at our coreboot/board_status repository. The default config should always be a known good config, unless the board isn't well maintained. Needing a specific "good config" is a sign of unattended bugs. Removed: [...] Please revert. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
Thank you very much, Evgeny, and luckily I could see your additions here: https://piratenpad.de/p/coreboot4.10-release-checklist ( https://review.coreboot.org/cgit/board-status.git/log/ - Lenovo T420 , Lenovo X200 , Lenovo X220 , Lenovo T530 baseboard ) On Sun, Jun 2, 2019 at 11:12 PM Evgeny Zinoviev via coreboot wrote: > > Your plan worked, I've just uploaded board status for 4 more boards. > > On 6/2/19 9:26 PM, Mike Banon wrote: > > I've just added a "Recently tested mainboards:" section to the end of > > https://piratenpad.de/p/coreboot4.10-release-checklist . I think its' > > existence could encourage the people to submit a board status report > > for their board, to increase its' visibility and attract more > > potential users/developers who'll read these release notes at some > > opensource-dedicated websites and may become interested at coreboot > > project. This section includes 6 laptops and 2 desktops for which the > > board status reports have been submitted during May and the beginning > > of June. Luckily 4.10 release is not there yet, so the people still > > have some time to submit a fresh board status for their board and then > > it could be included to this list. > > > > Also, regarding the significant changes: " ### Tianocore UEFI > > integrated as payload " . I hope it doesn't mean that Tianocore will > > become the default payload, since there are ideological/technical > > reasons against this ( I think there's a significant overlap between > > the groups of people who love / interested in coreboot and hate UEFI ) > > > > Recently tested mainboards: > > --- > > * Lenovo Ideapad G505S > > * Lenovo Thinkpad T400 > > * Lenovo Thinkpad T430 > > * Lenovo Thinkpad T430s baseboard > > * Lenovo Thinkpad X131e Chromebook > > * Lenovo Thinkpad X230 > > * Gigabyte GA-B75M-D3H > > * Asrock E350M1 > > > > On Fri, May 10, 2019 at 11:17 PM Patrick Georgi via coreboot > > wrote: > >> Hi everybody, > >> > >> with this mail I'm officially starting the 4.10 release process. > >> As per the first step of our checklist > >> (Documentation/releases/checklist.md), I hereby announce the intent to > >> release coreboot 4.10 in about 2 weeks. I'm aiming for May 28th to avoid > >> releasing into the weekend or on Memorial Day in the US, but I'll likely > >> lock down the commit we'll designate 4.10 during those days to give some > >> room for testing. > >> > >> I created a copy of the checklist on > >> https://piratenpad.de/p/coreboot4.10-release-checklist, also including the > >> current state of the 4.10 release notes. > >> > >> Please test the boards you have around and provide fixes, please be > >> careful with intrusive changes (and maybe postpone them until after the > >> release) and please update the release notes > >> (Documentation/releases/coreboot-4.10-relnotes.md or near the bottom of > >> the etherpad doc, I'll carry them over into our git repo then). > >> > >> As promised with the 4.9 release there won't be deprecations after 4.10. > >> However we need to finalize our set of deprecations we want to announce > >> with 4.10 that will happen after the 4.11 release (those also belong in > >> the release notes). > >> > >> > >> Regards, > >> Patrick > >> -- > >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > >> Hamburg > >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > >> ___ > >> coreboot mailing list -- coreboot@coreboot.org > >> To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
Just noticed that someone included i.e. some Purism Librem devices to a " Recently tested mainboards: " section - but, when I check https://review.coreboot.org/cgit/board-status.git/log/purism , the latest board status for Purism happened even before 4.9 ! And without a recent enough _public_ "board status" report - containing the important info about your build and its' complete configuration - I don't think we could include them to a "recently tested" list, since the other users won't have a chance to reproduce your build by using your configuration. Same question regarding some other of these additions, so removing them from a " Recently tested mainboards: " list, but of course they could be re-added if someone will submit a board_status reports from them. We would like to encourage the board status reporting, and relying on the word of users ( "I tested X board and it worked" ) would not help us to collect the known good configs at our coreboot/board_status repository. To submit a board status report for your board, please run a ./coreboot/util/board_status/board_status.sh script on it. Removed: * Purism Librem 13 v1 * Purism Librem 15 v2 * Purism Librem 13 v2/v3 * Purism Librem 15 v3 * Purism Librem 13 v4 * Purism Librem 15 v4 * Samsung Chromebook 3 (google/celes) * Acer Chromebook R11 (google/cyan) * Google Chromebook Pixel 2013 (google/link) * Toshiba Chromebook 2 (2014) (google/swanky) * Dell Chromebook 13 7310 (google/lulu) * Dell Inspiron Chromebook 14 (google/nami) * Acer Chromebook 14 (google/edgar) * HP Chromebook 13 G1 (google/chell) * Asus Chromebox CN60 (google/panther) * Asus Chromebox CN62 (google/guado) * Asus Chromebox CN65 (google/fizz) Added: (just saw two new reports by Michał Żygowski here - https://review.coreboot.org/cgit/board-status.git/ ) PC Engines APU1 PC Engines APU2 New version: Recently tested mainboards: --- * Lenovo Ideapad G505S * Lenovo Thinkpad T400 * Lenovo ThinkPad T420 * Lenovo Thinkpad T430 * Lenovo Thinkpad T430s baseboard * Lenovo Thinkpad T530 baseboard * Lenovo Thinkpad X131e Chromebook (Google Stout) * Lenovo ThinkPad X200 * Lenovo Thinkpad X220 * Lenovo Thinkpad X230 * Gigabyte GA-B75M-D3H * Asrock E350M1 * PC Engines APU1 * PC Engines APU2 On Mon, Jun 3, 2019 at 4:55 PM Mike Banon wrote: > > If the upstream edk2 is so bad - have you tried to upstream your set > of patches? It is good that your personal fork/repo is stable, but > inevitably it will always lag behind the upstream, not benefiting from > some new features and bugfixes. Same reason why I didn't want to fork > a coreboot despite having a big set of unofficial patches , instead > trying to upstream them when I have some free time. > > > On Sun, Jun 2, 2019 at 11:41 PM Matt DeVillier > wrote: > > > > there is no "stable" branch for upstream edk2 though. Previously, coreboot > > used an arbitrary commit as stable, and applied ~7 patches on top if it to > > make it functional. Even the UDK201x branches don't boot without patches > > > > On Sun, Jun 2, 2019 at 3:30 PM Lance Zhao wrote: > >> > >> Tianocore master branch build from edk2 will break, but that had been > >> quite some time. Stable branch is working fine though. > >> > >> On Mon, Jun 3, 2019, 3:28 AM Matt DeVillier > >> wrote: > >>> > >>> On Sun, Jun 2, 2019 at 1:27 PM Mike Banon wrote: > > > Also, regarding the significant changes: " ### Tianocore UEFI > integrated as payload " . I hope it doesn't mean that Tianocore will > become the default payload, since there are ideological/technical > reasons against this ( I think there's a significant overlap between > the groups of people who love / interested in coreboot and hate UEFI ) > >>> > >>> > >>> the change could be reworded better I think: instead of the stable tag > >>> for Tianocore being pulled from the upstream edk2 github repo and a > >>> series of patches applied, it's now pulled directly from my fork/repo, > >>> which is actually functional on most (x86_64) devices. A few tweaks (like > >>> customizable boot splash) were added as well. > >>> > >>> there is no change to the default payload, only to the defaults for > >>> Tianocore > >>> ___ > >>> coreboot mailing list -- coreboot@coreboot.org > >>> To unsubscribe send an email to coreboot-le...@coreboot.org > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Starting the coreboot 4.10 release process
If the upstream edk2 is so bad - have you tried to upstream your set of patches? It is good that your personal fork/repo is stable, but inevitably it will always lag behind the upstream, not benefiting from some new features and bugfixes. Same reason why I didn't want to fork a coreboot despite having a big set of unofficial patches , instead trying to upstream them when I have some free time. On Sun, Jun 2, 2019 at 11:41 PM Matt DeVillier wrote: > > there is no "stable" branch for upstream edk2 though. Previously, coreboot > used an arbitrary commit as stable, and applied ~7 patches on top if it to > make it functional. Even the UDK201x branches don't boot without patches > > On Sun, Jun 2, 2019 at 3:30 PM Lance Zhao wrote: >> >> Tianocore master branch build from edk2 will break, but that had been quite >> some time. Stable branch is working fine though. >> >> On Mon, Jun 3, 2019, 3:28 AM Matt DeVillier wrote: >>> >>> On Sun, Jun 2, 2019 at 1:27 PM Mike Banon wrote: Also, regarding the significant changes: " ### Tianocore UEFI integrated as payload " . I hope it doesn't mean that Tianocore will become the default payload, since there are ideological/technical reasons against this ( I think there's a significant overlap between the groups of people who love / interested in coreboot and hate UEFI ) >>> >>> >>> the change could be reworded better I think: instead of the stable tag for >>> Tianocore being pulled from the upstream edk2 github repo and a series of >>> patches applied, it's now pulled directly from my fork/repo, which is >>> actually functional on most (x86_64) devices. A few tweaks (like >>> customizable boot splash) were added as well. >>> >>> there is no change to the default payload, only to the defaults for >>> Tianocore >>> ___ >>> coreboot mailing list -- coreboot@coreboot.org >>> To unsubscribe send an email to coreboot-le...@coreboot.org > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: linux kernel > 4.9 hang at boot on ASUS KGPE-D16
Maybe related to this: when compiling with "check PIRQ table consitency" i get following warnings: ACPI Warning: NsLookup: Type mismatch on PRQI (RegionField), searching for (Region) (20190509/nsaccess-730) ACPI Warning: NsLookup: Type mismatch on SIOI (RegionField), searching for (Region) (20190509/nsaccess-730) ACPI Warning: NsLookup: Type mismatch on INDX (RegionField), searching for (Region) (20190509/nsaccess-730) ACPI Warning: NsLookup: Type mismatch on PIOI (RegionField), searching for (Region) (20190509/nsaccess-730) As booting with acpi=off alters the behaviour in some way i guess it is maybe related to this. next thinkg i will try is booting the kernel with "irqpoll" option Am 02.06.19 um 09:15 schrieb Kinky Nekoboi: > After upgrading my Debian Stretch installation to Buster, i experienced > this behaviour. > > acpi=off lets the kernel boot, but the system is still unusable as some > controller do not work correctly. > > So i guess its something ACPI related. > > Also wrote an bugreport to debian. > > I can not give any usable debug output as the kernel hangs before giving > any output. > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org signature.asc Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
