I get a very strange behavior while rebooting the board: 1. If board is booted without eth cable, reboot works as expected. 2. If board is booted with eth cable, reboot hangs at "The system is going down for reboot NOW!" on serial console and at "Sending all preocesses the TERM signal..." on console. 3. If board is booted without eth cable and I plug in the cable before reboot, the board hangs with: The system is going down for reboot NOW! root at fri2:~# irq 23: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.17-yocto-standard #2 Hardware name: Intel Corp. Fish River Island II, BIOS Tiano-TunnelCreek 11/19/2010 ed9ef3c0 ed9ef3c0 ed809ec4 c16872c4 ed809ee4 c10a1d8a c1841650 00000017 00000000 f8128522 ed9ef3c0 00000017 ed809f08 c10a214d 07eef203 00000017 c103a341 00000000 ed9ef3c0 ed9ef410 00000000 ed809f4c c10a00a9 ed809f50 Call Trace: [<c16872c4>] dump_stack+0x16/0x18 [<c10a1d8a>] __report_bad_irq+0x2a/0xd0 [<c10a214d>] note_interrupt+0xfd/0x1a0 [<c103a341>] ? __do_softirq+0x81/0x210 [<c10a00a9>] handle_irq_event_percpu+0xf9/0x230 [<c13d6a5f>] ? credit_entropy_bits.part.11+0xef/0x1e0 [<c10a0211>] handle_irq_event+0x31/0x50 [<c10a2b90>] handle_fasteoi_irq+0x50/0xe0 [<c109f844>] generic_handle_irq+0x24/0x40 [<c135533e>] pch_gpio_handler+0x4e/0x70 [<c10a0005>] handle_irq_event_percpu+0x55/0x230 [<c168eadc>] ? add_preempt_count+0xc/0xb0 [<c168eb8c>] ? sub_preempt_count+0xc/0xb0 [<c168b6b7>] ? _raw_spin_unlock_irqrestore+0x17/0x40 [<c10a0211>] handle_irq_event+0x31/0x50 [<c10a2b40>] ? unmask_irq+0x30/0x30 [<c10a2b90>] handle_fasteoi_irq+0x50/0xe0 <IRQ> [<c169250d>] ? do_IRQ+0x3d/0xb0 [<c103a5d8>] ? irq_exit+0x58/0x90 [<c16925da>] ? smp_apic_timer_interrupt+0x5a/0x8b [<c16923ec>] ? common_interrupt+0x2c/0x34 [<c104007b>] ? ftrace_raw_output_timer_class+0x1b/0x50 [<c103a341>] ? __do_softirq+0x81/0x210 [<c103a2c0>] ? __tasklet_hrtimer_trampoline+0x40/0x40 <IRQ> [<c103a5ee>] ? irq_exit+0x6e/0x90 [<c16925da>] ? smp_apic_timer_interrupt+0x5a/0x8b [<c168c001>] ? apic_timer_interrupt+0x2d/0x34 [<c107007b>] ? print_cfs_rq+0x4cb/0x1870 [<c14d8f10>] ? cpuidle_enter_state+0x40/0xc0 [<c14d9033>] ? cpuidle_idle_call+0xa3/0x220 [<c1008a8d>] ? arch_cpu_idle+0xd/0x30 [<c10755d6>] ? cpu_startup_entry+0x106/0x1f0 [<c1676591>] ? rest_init+0x71/0x80 [<c1970a18>] ? start_kernel+0x338/0x33f [<c1970514>] ? repair_env_string+0x51/0x51 [<c1970358>] ? i386_start_kernel+0x12e/0x131 handlers: [<c1541910>] azx_interrupt Disabling IRQ #23 Tested on master & dora with core-image-minimal and core-image sato.
On my fri2 with dora, I don't have any problems rebooting (shutdown -r now) with the eth cable plugged in. If more info is needed on my hardware I can provide it, or please provide more specific instructions on how to reproduce the problem, thanks.
Firmware version?
.
I am able to partially reproduce this on 1.6 M3 RC1 with MinnowBoard: 1) booting the image with ethernet cablen plugged and rebooting results in a hang NOTE: The onscreen messages vary from text output to hanged splashscreen. 2) booting the image without ethernet cablen plugged makes the image reboot without issues.
(In reply to comment #4) > I am able to partially reproduce this on 1.6 M3 RC1 with MinnowBoard: > 1) booting the image with ethernet cablen plugged and rebooting results in a > hang > NOTE: The onscreen messages vary from text output to hanged splashscreen. > 2) booting the image without ethernet cablen plugged makes the image reboot > without issues. I suspect this is a separate issue tied to the PHY used on the MinnowBoard which has some quirky hibernation "features". We're still looking for a firmware version from the reporter on the FRI2.
Investigation ongoing in order to narrow down the causes for this behavior. Will make tests on multiple platforms in this matter.
Sorry for last comment. Wrong Bug number
Andrei, is this still an issue for you?
No response in 6 months, closing this out. Andrei, please feel free to reopen if you're still running into this problem.