linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* Long stalls during boot with -next
@ 2011-09-29 12:50 Mark Brown
  2011-09-29 13:02 ` Takashi Iwai
  2011-10-07 11:50 ` Mark Brown
  0 siblings, 2 replies; 6+ messages in thread
From: Mark Brown @ 2011-09-29 12:50 UTC (permalink / raw)
  To: linux-arm-kernel

Since Tuesday I've been experiencing stalls on boot with -next kernels.
The boot appears to proceed normally but there appears to be a good ten
second delay somewhere around the late_initcall() stage with no
indication in the logs:

[    3.110000] regulator_init_complete: PVDD_1V2: disabling
[    3.120000] input: gpio-keys as /devices/platform/gpio-keys.0/input/input5
[    3.120000] wm831x-rtc wm831x-rtc.10: hctosys: unable to read the hardware clock
[   13.690000] kjournald starting.  Commit interval 5 seconds
[   13.690000] EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended

(which happens before or at about the time console output starts
appearing, I'd expect it to appear much earlier).  I've had a poke
around and I didn't spot anything yet, none of the development I've
noticed going on recently looks suspicious.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Long stalls during boot with -next
  2011-09-29 12:50 Long stalls during boot with -next Mark Brown
@ 2011-09-29 13:02 ` Takashi Iwai
  2011-09-29 13:44   ` Mark Brown
  2011-10-07 11:50 ` Mark Brown
  1 sibling, 1 reply; 6+ messages in thread
From: Takashi Iwai @ 2011-09-29 13:02 UTC (permalink / raw)
  To: linux-arm-kernel

At Thu, 29 Sep 2011 13:50:36 +0100,
Mark Brown wrote:
> 
> Since Tuesday I've been experiencing stalls on boot with -next kernels.
> The boot appears to proceed normally but there appears to be a good ten
> second delay somewhere around the late_initcall() stage with no
> indication in the logs:
> 
> [    3.110000] regulator_init_complete: PVDD_1V2: disabling
> [    3.120000] input: gpio-keys as /devices/platform/gpio-keys.0/input/input5
> [    3.120000] wm831x-rtc wm831x-rtc.10: hctosys: unable to read the hardware clock
> [   13.690000] kjournald starting.  Commit interval 5 seconds
> [   13.690000] EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended
> 
> (which happens before or at about the time console output starts
> appearing, I'd expect it to appear much earlier).  I've had a poke
> around and I didn't spot anything yet, none of the development I've
> noticed going on recently looks suspicious.

Did you check with initcall_debug boot option?


Takashi

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Long stalls during boot with -next
  2011-09-29 13:02 ` Takashi Iwai
@ 2011-09-29 13:44   ` Mark Brown
  0 siblings, 0 replies; 6+ messages in thread
From: Mark Brown @ 2011-09-29 13:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Sep 29, 2011 at 03:02:20PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > (which happens before or at about the time console output starts
> > appearing, I'd expect it to appear much earlier).  I've had a poke
> > around and I didn't spot anything yet, none of the development I've
> > noticed going on recently looks suspicious.

> Did you check with initcall_debug boot option?

Oh, I forgot to mention - that appears to make the 10s delay go down to
5s which isn't terribly helpful - it looks like the additional logging
causes some substantial reordering of some of the asynchronous parts of
boot, mainly the USB probe and accessory detection which previously
Completed earlier.  It does also appear that some of the user visible
delay here is coming prior to the kernel taking over so probably some
ARM boot code is taking a chunk of time also.

[    2.130000] wm831x-rtc wm831x-rtc.10: hctosys: unable to read the hardware clock
[    2.130000] initcall rtc_hctosys+0x0/0x120 returned -22 after 0 usecs
[    2.130000] initcall rtc_hctosys+0x0/0x120 returned with error code -22 
[    2.140000] calling  net_secret_init+0x0/0x24 @ 1
[    2.140000] initcall net_secret_init+0x0/0x24 returned 0 after 0 usecs
[    2.140000] calling  tcp_congestion_default+0x0/0x1c @ 1
[    2.140000] initcall tcp_congestion_default+0x0/0x1c returned 0 after 0 usecs
[    2.140000] calling  ip_auto_config+0x0/0x224 @ 1
[    2.140000] initcall ip_auto_config+0x0/0x224 returned 0 after 0 usecs
[    2.140000] calling  initialize_hashrnd+0x0/0x24 @ 1
[    2.140000] initcall initialize_hashrnd+0x0/0x24 returned 0 after 0 usecs
[    2.150000] async_waiting @ 1
[    2.150000] async_continuing @ 1 after 0 usec
[    2.240000] usb 1-1.1: udev 3, busnum 1, minor = 2
[    2.240000] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2514
[    2.240000] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber
=0
[    2.250000] usb 1-1.1: usb_probe_device
[    2.250000] usb 1-1.1: configuration #1 chosen from 1 choice
[    2.250000] usb 1-1.1: adding 1-1.1:1.0 (config #1, interface 0)
[    2.250000] hub 1-1.1:1.0: usb_probe_interface
[    2.250000] hub 1-1.1:1.0: usb_probe_interface - got id
[    2.250000] hub 1-1.1:1.0: USB hub found
[    2.260000] hub 1-1.1:1.0: 4 ports detected
[    2.260000] hub 1-1.1:1.0: standalone hub
[    2.260000] hub 1-1.1:1.0: individual port power switching
[    2.260000] hub 1-1.1:1.0: individual port over-current protection
[    2.260000] hub 1-1.1:1.0: power on to power good time: 100ms
[    2.260000] hub 1-1.1:1.0: local power source is good
[    2.260000] hub 1-1.1:1.0: enabling power on all ports
[    2.270000] drivers/usb/core/inode.c: creating file '003'
[    2.270000] hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0002
[    2.370000] hub 1-1.1:1.0: state 7 ports 4 chg 0000 evt 0000
[    2.970000] wm8996 1-001a: Microphone event: 402
[    2.970000] wm8996 1-001a: Jack removal detected
[    9.270000] kjournald starting.  Commit interval 5 seconds

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Long stalls during boot with -next
  2011-09-29 12:50 Long stalls during boot with -next Mark Brown
  2011-09-29 13:02 ` Takashi Iwai
@ 2011-10-07 11:50 ` Mark Brown
  2011-10-07 13:27   ` Thomas Abraham
  1 sibling, 1 reply; 6+ messages in thread
From: Mark Brown @ 2011-10-07 11:50 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Sep 29, 2011 at 01:50:36PM +0100, Mark Brown wrote:
> Since Tuesday I've been experiencing stalls on boot with -next kernels.
> The boot appears to proceed normally but there appears to be a good ten
> second delay somewhere around the late_initcall() stage with no
> indication in the logs:

I identified the problem here, the behaviour of LL_DEBUG was changed to
make it select DEBUG_ICEDCC by default which is unfortunate if one
doesn't have an EmbeddedICE connected.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Long stalls during boot with -next
  2011-10-07 11:50 ` Mark Brown
@ 2011-10-07 13:27   ` Thomas Abraham
  2011-10-07 14:23     ` Mark Brown
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Abraham @ 2011-10-07 13:27 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Mark,

On 7 October 2011 17:20, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Sep 29, 2011 at 01:50:36PM +0100, Mark Brown wrote:
>> Since Tuesday I've been experiencing stalls on boot with -next kernels.
>> The boot appears to proceed normally but there appears to be a good ten
>> second delay somewhere around the late_initcall() stage with no
>> indication in the logs:
>
> I identified the problem here, the behaviour of LL_DEBUG was changed to
> make it select DEBUG_ICEDCC by default which is unfortunate if one
> doesn't have an EmbeddedICE connected.

Thanks for your suggestion. The long stall during boot problem occurs
on Samsung boards as well with linux-next. As per your suggestion, the
following diff fixes this issue.

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 65cf8c6..035f5cd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -120,6 +120,15 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the second serial port on these devices.

+	config DEBUG_SAMSUNG_UART
+		bool "Kernel low-level debugging messages via samsung serial port"
+		depends on PLAT_SAMSUNG
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to the serial port for Samsung platforms. Choose
+		  the uart port with the "S3C UART to use for low-level debug"
+		  config option.
+
 endchoice

 config EARLY_PRINTK
@@ -139,7 +148,7 @@ config OC_ETM
 	  kernel code.

 config DEBUG_S3C_UART
-	depends on PLAT_SAMSUNG
+	depends on DEBUG_SAMSUNG_UART
 	int "S3C UART to use for low-level debug"
 	default "0"
 	help


Thanks,
Thomas.

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Long stalls during boot with -next
  2011-10-07 13:27   ` Thomas Abraham
@ 2011-10-07 14:23     ` Mark Brown
  0 siblings, 0 replies; 6+ messages in thread
From: Mark Brown @ 2011-10-07 14:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Oct 07, 2011 at 06:57:19PM +0530, Thomas Abraham wrote:
> On 7 October 2011 17:20, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > I identified the problem here, the behaviour of LL_DEBUG was changed to
> > make it select DEBUG_ICEDCC by default which is unfortunate if one
> > doesn't have an EmbeddedICE connected.

> Thanks for your suggestion. The long stall during boot problem occurs
> on Samsung boards as well with linux-next. As per your suggestion, the
> following diff fixes this issue.

Excellent, I'm using this now - please add my

Tested-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

when you send it out properly!

> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 65cf8c6..035f5cd 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -120,6 +120,15 @@ choice
>  		  Say Y here if you want the debug print routines to direct
>  		  their output to the second serial port on these devices.
> 
> +	config DEBUG_SAMSUNG_UART
> +		bool "Kernel low-level debugging messages via samsung serial port"
> +		depends on PLAT_SAMSUNG
> +		help
> +		  Say Y here if you want the debug print routines to direct
> +		  their output to the serial port for Samsung platforms. Choose
> +		  the uart port with the "S3C UART to use for low-level debug"
> +		  config option.
> +
>  endchoice
> 
>  config EARLY_PRINTK
> @@ -139,7 +148,7 @@ config OC_ETM
>  	  kernel code.
> 
>  config DEBUG_S3C_UART
> -	depends on PLAT_SAMSUNG
> +	depends on DEBUG_SAMSUNG_UART
>  	int "S3C UART to use for low-level debug"
>  	default "0"
>  	help

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-10-07 14:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-29 12:50 Long stalls during boot with -next Mark Brown
2011-09-29 13:02 ` Takashi Iwai
2011-09-29 13:44   ` Mark Brown
2011-10-07 11:50 ` Mark Brown
2011-10-07 13:27   ` Thomas Abraham
2011-10-07 14:23     ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).