macbook21: broken by 10385 (Make DSDT a file in CBFS rather than embedding it into ramstage.)

[Mono]

Ahoi Vladimir (and all),

nice to see you again!

my macbook21 lately has two issues: xserver cannot start and poweroff does not poweroff but stops after halt.
startx throws the following error:
modprobe: ERROR: could not insert 'i915': No such device
intel: waited 2020 ms for i915.ko driver to load

bisect says:
# good: [1cac2c9713a864fe90f40040cd1ede130983544c] Hide PLATFORM_USES_FSP1_1.
git bisect good 1cac2c9713a864fe90f40040cd1ede130983544c
# bad: [a4cf83df7a3ef3401e12ca3732cbe07294684d02] cbfs: Fix mismerge.
git bisect bad a4cf83df7a3ef3401e12ca3732cbe07294684d02
# only skipped commits left to test
# possible first bad commit: [a4cf83df7a3ef3401e12ca3732cbe07294684d02] cbfs: Fix mismerge.
# possible first bad commit: [1aeea7fbdf252c95e1e3cdf45339a1430125f85d] tpm: Add dummy _DSM to make Bitlocker happy.
# possible first bad commit: [36f8d27ea9f741e184b76b5f42d7f777f207edc0] Make DSDT a file in CBFS rather than embedding it into ramstage.

36f8d27 and 1aeea7f had been skipped because of a build error.
however, cherry picking a4cf83d on top of 36f8d27 is bad already. So I guess 36f8d27 might be the first bad.

Unfortunately I have no idea how to fix the problem or what the problem really is. Can you please point me to the right direction?

best regards
Mono

[Timothy Pearson]

On 06/07/2015 03:04 PM, Mono wrote:
> Ahoi Vladimir (and all),
>
> nice to see you again!
>
> my macbook21 lately has two issues: xserver cannot start and poweroff does not poweroff but stops after halt.
> startx throws the following error:
> modprobe: ERROR: could not insert 'i915': No such device
> intel: waited 2020 ms for i915.ko driver to load
>
> bisect says:
> # good: [1cac2c9713a864fe90f40040cd1ede130983544c] Hide PLATFORM_USES_FSP1_1.
> git bisect good 1cac2c9713a864fe90f40040cd1ede130983544c
> # bad: [a4cf83df7a3ef3401e12ca3732cbe07294684d02] cbfs: Fix mismerge.
> git bisect bad a4cf83df7a3ef3401e12ca3732cbe07294684d02
> # only skipped commits left to test
> # possible first bad commit: [a4cf83df7a3ef3401e12ca3732cbe07294684d02] cbfs: Fix mismerge.
> # possible first bad commit: [1aeea7fbdf252c95e1e3cdf45339a1430125f85d] tpm: Add dummy _DSM to make Bitlocker happy.
> # possible first bad commit: [36f8d27ea9f741e184b76b5f42d7f777f207edc0] Make DSDT a file in CBFS rather than embedding it into ramstage.
>
> 36f8d27 and 1aeea7f had been skipped because of a build error.
> however, cherry picking a4cf83d on top of 36f8d27 is bad already. So I guess 36f8d27 might be the first bad.
>
> Unfortunately I have no idea how to fix the problem or what the problem really is. Can you please point me to the right direction?
>
> best regards
> Mono

That same commit also broke ACPI tables when the normal/fallback 
mechanism is used.  Can you check to see if any ACPI tables are included 
in the failing ROMs (use cbfstool to dump a list of files)?

Initial failure report from REACTS:
http://www.coreboot.org/pipermail/coreboot/2015-June/079966.html

Initial attempt at a fix (incomplete, does not work):
http://review.coreboot.org/#/c/10410/1

[Mono]

Hallo Timothy,

indeed I am using normal/fallback mechanism and yes there was no file with ACPI tables in the ROM.
adding the missing table with cbfstool seems to work perfectly. ROM looks like this now:

coreboot.rom: 2048 kB, bootblocksize 2528, romsize 2097152, offset 0x0
alignment: 64 bytes, architecture: x86

Name                           Offset     Type         Size
cmos_layout.bin                0x0        cmos_layout  1828
cmos.default                   0x780      cmos_default 256
fallback/romstage              0x8c0      stage        43536
fallback/ramstage              0xb340     stage        83111
fallback/payload               0x1f840    payload      619718
normal/romstage                0xb6d40    stage        35096
normal/ramstage                0xbf680    stage        60911
normal/payload                 0xce4c0    payload      619699
config                         0x1659c0   raw          3963
revision                       0x166980   raw          603
normal/dsdt.aml                0x166c40   raw          10163
(empty)                        0x169440   null         614744

thank you for the quick help!

best regards
Mono

On Sun, Jun 07, 2015 at 03:21:17PM -0500, Timothy Pearson wrote:
> On 06/07/2015 03:04 PM, Mono wrote:
> > Ahoi Vladimir (and all),
> >
> > nice to see you again!
> >
> > my macbook21 lately has two issues: xserver cannot start and poweroff does not poweroff but stops after halt.
> > startx throws the following error:
> > modprobe: ERROR: could not insert 'i915': No such device
> > intel: waited 2020 ms for i915.ko driver to load
> >
> > bisect says:
> > # good: [1cac2c9713a864fe90f40040cd1ede130983544c] Hide PLATFORM_USES_FSP1_1.
> > git bisect good 1cac2c9713a864fe90f40040cd1ede130983544c
> > # bad: [a4cf83df7a3ef3401e12ca3732cbe07294684d02] cbfs: Fix mismerge.
> > git bisect bad a4cf83df7a3ef3401e12ca3732cbe07294684d02
> > # only skipped commits left to test
> > # possible first bad commit: [a4cf83df7a3ef3401e12ca3732cbe07294684d02] cbfs: Fix mismerge.
> > # possible first bad commit: [1aeea7fbdf252c95e1e3cdf45339a1430125f85d] tpm: Add dummy _DSM to make Bitlocker happy.
> > # possible first bad commit: [36f8d27ea9f741e184b76b5f42d7f777f207edc0] Make DSDT a file in CBFS rather than embedding it into ramstage.
> >
> > 36f8d27 and 1aeea7f had been skipped because of a build error.
> > however, cherry picking a4cf83d on top of 36f8d27 is bad already. So I guess 36f8d27 might be the first bad.
> >
> > Unfortunately I have no idea how to fix the problem or what the problem really is. Can you please point me to the right direction?
> >
> > best regards
> > Mono
>
> That same commit also broke ACPI tables when the normal/fallback mechanism
> is used.  Can you check to see if any ACPI tables are included in the
> failing ROMs (use cbfstool to dump a list of files)?
>
> Initial failure report from REACTS:
> http://www.coreboot.org/pipermail/coreboot/2015-June/079966.html
>
> Initial attempt at a fix (incomplete, does not work):
> http://review.coreboot.org/#/c/10410/1

[Timothy Pearson]

On 06/07/2015 03:45 PM, Mono wrote:
> Hallo Timothy,
>
> indeed I am using normal/fallback mechanism and yes there was no file with ACPI tables in the ROM.
> adding the missing table with cbfstool seems to work perfectly. ROM looks like this now:
>
> coreboot.rom: 2048 kB, bootblocksize 2528, romsize 2097152, offset 0x0
> alignment: 64 bytes, architecture: x86
>
> Name                           Offset     Type         Size
> cmos_layout.bin                0x0        cmos_layout  1828
> cmos.default                   0x780      cmos_default 256
> fallback/romstage              0x8c0      stage        43536
> fallback/ramstage              0xb340     stage        83111
> fallback/payload               0x1f840    payload      619718
> normal/romstage                0xb6d40    stage        35096
> normal/ramstage                0xbf680    stage        60911
> normal/payload                 0xce4c0    payload      619699
> config                         0x1659c0   raw          3963
> revision                       0x166980   raw          603
> normal/dsdt.aml                0x166c40   raw          10163
> (empty)                        0x169440   null         614744
>
> thank you for the quick help!
>
> best regards
> Mono

No problem!  It's good to know the problem is still isolated to the 
normal/fallback mechanism; hopefully that issue will be resolved soon.