public inbox for linux-kernel@vger.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 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:39 UTC|newest]

Thread overview: 26+ 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:10 ` Andrew Morton
2005-07-27  0:14   ` tony.luck
2005-07-27  0:23     ` Andrew Morton
2005-07-27  7:40     ` Pavel Machek
2005-07-28  1:37 ` Kenji Kaneshige [this message]
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-07-27 21:14 [patch] " Luck, Tony
2005-04-21 15:02 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:36   ` Zwane Mwaikambo
2005-04-30  9:47     ` Andrew Morton
2005-04-30 13:40       ` Pavel Machek
2005-05-01 19:09   ` Kenji Kaneshige
2005-05-01 19:57     ` Pavel Machek
2005-05-01 22:16     ` Adam Belay
2005-05-16  7:56       ` Andrew Morton
2005-05-19 12:43         ` Kenji Kaneshige
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox