All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: "Luck, Tony" <tony.luck@intel.com>, Andrew Morton <akpm@osdl.org>
Cc: Adam Belay <ambx1@neo.rr.com>,
	greg@kroah.org, pavel@ucw.cz, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [patch] properly stop devices before poweroff
Date: Thu, 28 Jul 2005 01:37:57 +0000	[thread overview]
Message-ID: <42E836F5.2050803@jp.fujitsu.com> (raw)
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F03FCF24C@scsmsx401.amr.corp.intel.com>

Hi,

I think the patch Tony mentioned (ia64-halt-hangup-fix.patch)
was already merged into -mm tree. But as Tony said, it doesn't
work and removing reboot notifier of e1000 looks better than
changing ia64 version of pcibios_disable_device().

After all, I think ia64-halt-hangup-fix.patch should be removed
from -mm tree.

Thanks,
Kenji Kaneshige


Luck, Tony wrote:
> I started on my OLS homework from Andrew ... and began looking
> into what is going on here.
> 
> The story so far: Pavel added calls to device_suspend() to three of
> the cases in the sys_reboot() path.  This stopped ia64 from being
> able to shutdown.  There is a oops with a stacktrace pointing back
> at the sys_reboot call.
> 
> Initial analysis from Kenji Kaneshige said that we might fix this
> by adding a patch to the ia64 version of pcibios_disable_device()
> to make it check whether the device was enabled before calling
> acpi_pci_irq_disable().  This might fix things if the issue was
> simply problems with this being called twice.  Pavel sent a
> "Looks good", Adam said "Is it the right fix?"
> 
> I just tried it ... it doesn't work, we still see an oops from
> the sys_reboot() ... so shutdown hangs, and we can sidestep the
> issue of whether this is ideologically correct.
> 
> Then I wondered whether it was just an e1000 problem (since Pavel
> had also commented that we should perhaps removed the reboot notifier
> from the e1000 driver).  So I rebuilt my kernel with e1000 as a module
> and ran "rmmod e1000" before running shutdown.  Which promptly failed
> with a stack trace that ran through mptscsih driver instead of e1000.
> [N.B. Kaneshige-san has also noted that his i386 system which has the
> mptfusion also hangs executing a SYNCHRONIZE_CACHE command]. 
> 
> Code examination in the e1000 case shows that we are a bit confused
> and call first:
> 
> notifier_call_chain(reboot_notifier, ...)
>   e1000_notify_reboot(...)
>     e1000_suspend(...)
>       pci_disable_device(...)
>       pci_set_power_state(...)
> 
> and then:
> 
> device_suspend(...)
>    suspend_device() = dev->bus->suspend = pci_device_suspend
>      e1000_suspend()
>        pci_disable_device()
>        pciset_power_state()
> 
> So it looks like Pavel is right ... registering the reboot notifier is
> bogus in e1000.  Commenting out the register/unregister also allows
> me to get past the e1000 so that I can fail in mptscsih_suspend() path.
> But the fusion driver doesn't register a reboot notifier, so I can't
> try the same trick there :-)
> 
> Andrew: How did you get the squitty font on ia64?  The stack trace
> from the oops flies off the top of the screen.  I've tried a few
> "vga=0x0f07" type options, but I keep getting a big font.
> 
> -Tony
> 


WARNING: multiple messages have this Message-ID (diff)
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: "Luck, Tony" <tony.luck@intel.com>, Andrew Morton <akpm@osdl.org>
Cc: Adam Belay <ambx1@neo.rr.com>,
	greg@kroah.org, pavel@ucw.cz, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [patch] properly stop devices before poweroff
Date: Thu, 28 Jul 2005 10:37:57 +0900	[thread overview]
Message-ID: <42E836F5.2050803@jp.fujitsu.com> (raw)
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F03FCF24C@scsmsx401.amr.corp.intel.com>

Hi,

I think the patch Tony mentioned (ia64-halt-hangup-fix.patch)
was already merged into -mm tree. But as Tony said, it doesn't
work and removing reboot notifier of e1000 looks better than
changing ia64 version of pcibios_disable_device().

After all, I think ia64-halt-hangup-fix.patch should be removed
from -mm tree.

Thanks,
Kenji Kaneshige


Luck, Tony wrote:
> I started on my OLS homework from Andrew ... and began looking
> into what is going on here.
> 
> The story so far: Pavel added calls to device_suspend() to three of
> the cases in the sys_reboot() path.  This stopped ia64 from being
> able to shutdown.  There is a oops with a stacktrace pointing back
> at the sys_reboot call.
> 
> Initial analysis from Kenji Kaneshige said that we might fix this
> by adding a patch to the ia64 version of pcibios_disable_device()
> to make it check whether the device was enabled before calling
> acpi_pci_irq_disable().  This might fix things if the issue was
> simply problems with this being called twice.  Pavel sent a
> "Looks good", Adam said "Is it the right fix?"
> 
> I just tried it ... it doesn't work, we still see an oops from
> the sys_reboot() ... so shutdown hangs, and we can sidestep the
> issue of whether this is ideologically correct.
> 
> Then I wondered whether it was just an e1000 problem (since Pavel
> had also commented that we should perhaps removed the reboot notifier
> from the e1000 driver).  So I rebuilt my kernel with e1000 as a module
> and ran "rmmod e1000" before running shutdown.  Which promptly failed
> with a stack trace that ran through mptscsih driver instead of e1000.
> [N.B. Kaneshige-san has also noted that his i386 system which has the
> mptfusion also hangs executing a SYNCHRONIZE_CACHE command]. 
> 
> Code examination in the e1000 case shows that we are a bit confused
> and call first:
> 
> notifier_call_chain(reboot_notifier, ...)
>   e1000_notify_reboot(...)
>     e1000_suspend(...)
>       pci_disable_device(...)
>       pci_set_power_state(...)
> 
> and then:
> 
> device_suspend(...)
>    suspend_device() == dev->bus->suspend == pci_device_suspend
>      e1000_suspend()
>        pci_disable_device()
>        pciset_power_state()
> 
> So it looks like Pavel is right ... registering the reboot notifier is
> bogus in e1000.  Commenting out the register/unregister also allows
> me to get past the e1000 so that I can fail in mptscsih_suspend() path.
> But the fusion driver doesn't register a reboot notifier, so I can't
> try the same trick there :-)
> 
> Andrew: How did you get the squitty font on ia64?  The stack trace
> from the oops flies off the top of the screen.  I've tried a few
> "vga=0x0f07" type options, but I keep getting a big font.
> 
> -Tony
> 


  parent reply	other threads:[~2005-07-28  1:37 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-26 19:02 [patch] properly stop devices before poweroff Luck, Tony
2005-07-26 19:02 ` Luck, Tony
2005-07-26 19:10 ` Andrew Morton
2005-07-26 19:10   ` Andrew Morton
2005-07-27  0:14   ` tony.luck
2005-07-27  0:14     ` tony.luck
2005-07-27  0:23     ` Andrew Morton
2005-07-27  0:23       ` Andrew Morton
2005-07-27  7:40     ` Pavel Machek
2005-07-27  7:40       ` Pavel Machek
2005-07-28  1:37 ` Kenji Kaneshige [this message]
2005-07-28  1:37   ` Kenji Kaneshige
2005-07-28  1:41   ` Andrew Morton
2005-07-28  1:41     ` Andrew Morton
     [not found] <200506260105.j5Q15eBj021334@hera.kernel.org>
2005-08-01 15:19 ` [PATCH] " Olaf Hering
  -- strict thread matches above, loose matches on Subject: below --
2005-04-21 15:02 [patch] " tvrtko.ursulin
2005-04-21 11:30 tvrtko.ursulin
2005-04-21 11:38 ` Pavel Machek
2005-04-21 11:13 Pavel Machek
2005-04-29 13:18 ` Andrew Morton
2005-04-29 13:18   ` Andrew Morton
2005-04-29 13:36   ` Zwane Mwaikambo
2005-04-29 13:36     ` Zwane Mwaikambo
2005-04-30  9:47     ` Andrew Morton
2005-04-30  9:47       ` Andrew Morton
2005-04-30 13:40       ` Pavel Machek
2005-04-30 13:40         ` Pavel Machek
2005-05-01 19:09   ` Kenji Kaneshige
2005-05-01 19:09     ` Kenji Kaneshige
2005-05-01 19:57     ` Pavel Machek
2005-05-01 19:57       ` Pavel Machek
2005-05-01 22:16     ` Adam Belay
2005-05-01 22:16       ` Adam Belay
2005-05-16  7:56       ` Andrew Morton
2005-05-16  7:56         ` Andrew Morton
2005-05-19 12:43         ` Kenji Kaneshige
2005-05-19 12:43           ` Kenji Kaneshige
2005-07-27 21:14   ` Luck, Tony
2005-07-27 21:14     ` Luck, Tony
2005-05-01 22:24 ` Adam Belay
2005-05-01 23:16   ` Pavel Machek
2005-05-02  0:01     ` Adam Belay
2005-05-02  9:55       ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42E836F5.2050803@jp.fujitsu.com \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=akpm@osdl.org \
    --cc=ambx1@neo.rr.com \
    --cc=greg@kroah.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.