Boot problem on PPC with 4.4-git - Bisected to commit 21266be

DISCUSSION Larry Finger 2 participants 7 messages Jan 20, 2016 Library code

Share & tools

Larry Finger

author

2016-01-20 20:01 UTC #0 lore raw

My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the 4.4-git series. The problem was bisected to commit 21266be. It took a while to figure out why a commit that only rearranges the Kconfig files could cause the problem.

The answer came when I read the commit message for 90a545e98126 and saw that "Recompiling with CONFIG_IO_STRICT_DEVMEM=n" might be necessary. After I made that change, the system boots.

If it is the graphics hardware driver at fault, the VGA controller is listed as an ATI RV350 [Mobility Radeon 9600 M10] with PCI ID 1002:4350. It uses radeon as the driver.

I'm not sure if this is a bug in the configuration, but I know that selecting the default answer to all the new configuration parameters leaves me with a machine that is unbootable.

Larry

Dan Williams

2016-01-20 20:08 UTC #1 lore raw

Quoted 9 lines · Larry Finger

My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the 4.4-git series. The problem was bisected to commit 21266be. It took a while to figure out why a commit that only rearranges the Kconfig files could cause the problem.
The answer came when I read the commit message for 90a545e98126 and saw that "Recompiling with CONFIG_IO_STRICT_DEVMEM=n" might be necessary. After I made that change, the system boots.

Quoted 7 lines

If it is the graphics hardware driver at fault, the VGA controller is listed as an ATI RV350 [Mobility Radeon 9600 M10] with PCI ID 1002:4350. It uses radeon as the driver.
I'm not sure if this is a bug in the configuration, but I know that selecting the default answer to all the new configuration parameters leaves me with a machine that is unbootable.

I agree that the default configuration should remain bootable. I'll send a change that does not force that default.

Thanks for the report and sorry for the inconvenience.

Dan Williams

2016-01-20 20:16 UTC #2 lore raw

Quoted 15 lines · Dan Williams

Quoted 13 lines · Larry Finger
My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the 4.4-git series. The problem was bisected to commit 21266be. It took a while to figure out why a commit that only rearranges the Kconfig files could cause the problem.
The answer came when I read the commit message for 90a545e98126 and saw that "Recompiling with CONFIG_IO_STRICT_DEVMEM=n" might be necessary. After I made that change, the system boots.
If it is the graphics hardware driver at fault, the VGA controller is listed as an ATI RV350 [Mobility Radeon 9600 M10] with PCI ID 1002:4350. It uses radeon as the driver.

Quoted 8 lines

Quoted 3 lines
I'm not sure if this is a bug in the configuration, but I know that selecting the default answer to all the new configuration parameters leaves me with a machine that is unbootable.
I agree that the default configuration should remain bootable. I'll send a change that does not force that default.
Thanks for the report and sorry for the inconvenience.

Are you sure that the bisect is pointing to "21266be9ed54 arch:
consolidate CONFIG_STRICT_DEVM in lib/Kconfig.debug" and not "90a545e98126 restrict /dev/mem to idle io memory ranges"? The default for CONFIG_STRICT_DEVM should be unchanged in 21266be9ed54, it's not until 90a545e98126 that I would expect a behavior change.

Dan Williams

2016-01-20 20:33 UTC #3 lore raw

Quoted 23 lines · Dan Williams

Quoted 22 lines · Dan Williams
Quoted 9 lines · Larry Finger
My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the 4.4-git series. The problem was bisected to commit 21266be. It took a while to figure out why a commit that only rearranges the Kconfig files could cause the problem.
The answer came when I read the commit message for 90a545e98126 and saw that "Recompiling with CONFIG_IO_STRICT_DEVMEM=n" might be necessary. After I made that change, the system boots.
Quoted 7 lines
If it is the graphics hardware driver at fault, the VGA controller is listed as an ATI RV350 [Mobility Radeon 9600 M10] with PCI ID 1002:4350. It uses radeon as the driver.
I'm not sure if this is a bug in the configuration, but I know that selecting the default answer to all the new configuration parameters leaves me with a machine that is unbootable.
I agree that the default configuration should remain bootable. I'll send a change that does not force that default.

Quoted 7 lines

Quoted 1 line
Thanks for the report and sorry for the inconvenience.
Are you sure that the bisect is pointing to "21266be9ed54 arch:
consolidate CONFIG_STRICT_DEVM in lib/Kconfig.debug" and not "90a545e98126 restrict /dev/mem to idle io memory ranges"? The default for CONFIG_STRICT_DEVM should be unchanged in 21266be9ed54, it's not until 90a545e98126 that I would expect a behavior change.

Sorry for the mail flurry... if you can verify that the following change resolves this problem I'll send it up:

lib/Kconfig.debug +0 -0

index f75a33f29f6e..7d0b49c536c5 100644
@@ -1919,7 +1919,6 @@ config STRICT_DEVMEM

config IO_STRICT_DEVMEM
bool "Filter I/O access to /dev/mem"
depends on STRICT_DEVMEM
- default STRICT_DEVMEM
---help---
If this option is disabled, you allow userspace (root) access to all io-memory regardless of whether a driver is actively using that

Larry Finger

author

2016-01-20 21:36 UTC #4 lore raw

Quoted 40 lines · Dan Williams

Quoted 23 lines · Dan Williams
Quoted 22 lines · Dan Williams
Quoted 9 lines · Larry Finger
My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the 4.4-git series. The problem was bisected to commit 21266be. It took a while to figure out why a commit that only rearranges the Kconfig files could cause the problem.
The answer came when I read the commit message for 90a545e98126 and saw that "Recompiling with CONFIG_IO_STRICT_DEVMEM=n" might be necessary. After I made that change, the system boots.
Quoted 7 lines
If it is the graphics hardware driver at fault, the VGA controller is listed as an ATI RV350 [Mobility Radeon 9600 M10] with PCI ID 1002:4350. It uses radeon as the driver.
I'm not sure if this is a bug in the configuration, but I know that selecting the default answer to all the new configuration parameters leaves me with a machine that is unbootable.
I agree that the default configuration should remain bootable. I'll send a change that does not force that default.
Quoted 7 lines
Quoted 1 line
Thanks for the report and sorry for the inconvenience.
Are you sure that the bisect is pointing to "21266be9ed54 arch:
consolidate CONFIG_STRICT_DEVM in lib/Kconfig.debug" and not "90a545e98126 restrict /dev/mem to idle io memory ranges"? The default for CONFIG_STRICT_DEVM should be unchanged in 21266be9ed54, it's not until 90a545e98126 that I would expect a behavior change.
Sorry for the mail flurry... if you can verify that the following change resolves this problem I'll send it up:
lib/Kconfig.debug +0 -0
index f75a33f29f6e..7d0b49c536c5 100644
@@ -1919,7 +1919,6 @@ config STRICT_DEVMEM

Quoted 7 lines

config IO_STRICT_DEVMEM
bool "Filter I/O access to /dev/mem"
depends on STRICT_DEVMEM
- default STRICT_DEVMEM
---help---
If this option is disabled, you allow userspace (root) access to all io-memory regardless of whether a driver is actively using that

That isn't quite right. I added that patch, and restored the 4.4.0 configuration. That one has "CONFIG_STRICT_DEVM=y". After I ran "make oldconfig", CONFIG_STRICT_DEVM was still set, which kills rebooting.

When I repeated the process, but removed the CONFIG_STRICT_DEVM line from .config before I ran "make oldconfig", then I got a bootable configuration. It seems that once STRICT_DEVM is yes, only a "make menuconfig", or equivalent, will let you turn it off.

Larry

Dan Williams

2016-01-20 22:19 UTC #5 lore raw

Quoted 9 lines · Larry Finger

On 01/20/2016 02:33 PM, Dan Williams wrote:
That isn't quite right. I added that patch, and restored the 4.4.0 configuration. That one has "CONFIG_STRICT_DEVM=y". After I ran "make oldconfig", CONFIG_STRICT_DEVM was still set, which kills rebooting.
When I repeated the process, but removed the CONFIG_STRICT_DEVM line from .config before I ran "make oldconfig", then I got a bootable configuration. It seems that once STRICT_DEVM is yes, only a "make menuconfig", or equivalent, will let you turn it off.

This matches my expectation. The fix stops defaulting it on when CONFIG_STRICT_DEVM is set, but if you already have it set this change will have no effect. In other words if you take a old config from before CONFIG_IO_STRICT_DEVMEM was introduced it won't get turned on...

Larry Finger

author

2016-01-20 20:40 UTC #6 lore raw

In reply to Dan Williams

Quoted 23 lines · Dan Williams

Quoted 22 lines · Dan Williams
Quoted 9 lines · Larry Finger
My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the 4.4-git series. The problem was bisected to commit 21266be. It took a while to figure out why a commit that only rearranges the Kconfig files could cause the problem.
The answer came when I read the commit message for 90a545e98126 and saw that "Recompiling with CONFIG_IO_STRICT_DEVMEM=n" might be necessary. After I made that change, the system boots.
Quoted 7 lines
If it is the graphics hardware driver at fault, the VGA controller is listed as an ATI RV350 [Mobility Radeon 9600 M10] with PCI ID 1002:4350. It uses radeon as the driver.
I'm not sure if this is a bug in the configuration, but I know that selecting the default answer to all the new configuration parameters leaves me with a machine that is unbootable.
I agree that the default configuration should remain bootable. I'll send a change that does not force that default.

Quoted 7 lines

Quoted 1 line
Thanks for the report and sorry for the inconvenience.
Are you sure that the bisect is pointing to "21266be9ed54 arch:
consolidate CONFIG_STRICT_DEVM in lib/Kconfig.debug" and not "90a545e98126 restrict /dev/mem to idle io memory ranges"? The default for CONFIG_STRICT_DEVM should be unchanged in 21266be9ed54, it's not until 90a545e98126 that I would expect a behavior change.

Yes. Commit 21266be9ed54 was the reported bad commit; however, the previous test kernel was 90a545e98126. In fact, I was struck that the final bisection build did not change any object files, thus you are right that 90a545e98126 is likely the bad commit.

Larry