From: ebiederm@xmission.com (Eric W. Biederman)
To: Kenneth Sumrall <ken@mvista.com>
Cc: suparna@in.ibm.com, Corey Minyard <cminyard@mvista.com>,
linux-kernel@vger.kernel.org, lkcd-devel@lists.sourceforge.net
Subject: Re: Kexec, DMA, and SMP
Date: 10 Feb 2003 22:08:01 -0700 [thread overview]
Message-ID: <m1y94nxv4e.fsf@frodo.biederman.org> (raw)
In-Reply-To: <3E48536B.272E5630@mvista.com>
Kenneth Sumrall <ken@mvista.com> writes:
> > Suparna Bhattacharya <suparna@in.ibm.com> writes:
> > Agreed. I guess the primary question is can we trust the current
> > device shutdown + reboot notifier path or do we need to make some
> > large changes to avoid it.
> >
> So are the functions registered on the reboot notifier path guaranteed
> to be non-blocking? In the kexec on panic case, calls that can block
> would obviously be a bad thing. If they can block, perhaps we could add
> a new flag SYS_PANIC or something like that to tell the driver to only
> do a non-blocking shutdown of the chip.
I think there is some amount of blocking allowed. But that has not be
clearly defined. Note in 2.5.x there is a specific subset
of the reboot notifiers the shutdown() device method. That you
don't need to register a notifier for. The rules are the same
and it is just a little bit cleaner.
> > Not primarily. Instead I am trying to address the possibility that
> > DMA is overwriting the recovery code due to a device not being shutdown
> > properly. Though it would happen to cover many cases of the wrong
> > memory address being passed to a device.
> >
> The problem we were seeing was that rogue DMA from a network interface
> chip was corrupting dentry's in the dirent cache when the rebooted
> kernel was coming back up. This caused a whole new set of panics. :-(
And this a reserved hunk of memory from of memory from say 16MB to 20MB
would handle. As the DMA could never have been setup at that address
it obviously will never be used...
Eric
next prev parent reply other threads:[~2003-02-11 4:58 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3E448745.9040707@mvista.com>
[not found] ` <m1isvuzjj2.fsf@frodo.biederman.org>
2003-02-08 20:18 ` Kexec, DMA, and SMP Corey Minyard
2003-02-09 18:39 ` Eric W. Biederman
2003-02-10 11:14 ` Kexec on 2.5.59 problems ? Suparna Bhattacharya
2003-02-10 17:09 ` [Fastboot] " Andy Pfiffer
2003-02-10 18:07 ` Eric W. Biederman
2003-02-11 7:21 ` Suparna Bhattacharya
2003-02-11 17:04 ` Andy Pfiffer
2003-02-11 23:46 ` Andy Pfiffer
2003-02-12 4:29 ` Eric W. Biederman
2003-02-12 22:31 ` Andy Pfiffer
2003-02-13 9:50 ` Suparna Bhattacharya
2003-02-13 15:10 ` Eric W. Biederman
2003-02-18 10:59 ` Suparna Bhattacharya
2003-02-18 15:06 ` Eric W. Biederman
2003-02-10 12:12 ` Kexec, DMA, and SMP Suparna Bhattacharya
2003-02-10 13:56 ` Corey Minyard
2003-02-10 15:07 ` Suparna Bhattacharya
2003-02-10 15:22 ` Corey Minyard
2003-02-10 17:56 ` Eric W. Biederman
2003-02-11 1:35 ` Kenneth Sumrall
2003-02-11 5:08 ` Eric W. Biederman [this message]
2003-02-11 17:09 ` Stephen Hemminger
2003-02-11 12:55 ` Suparna Bhattacharya
2003-02-11 13:40 ` Suparna Bhattacharya
2003-02-11 14:06 ` Corey Minyard
2003-02-11 14:40 ` Suparna Bhattacharya
2003-02-11 15:20 ` Corey Minyard
2003-02-12 4:28 ` Eric W. Biederman
2003-02-12 14:17 ` Corey Minyard
2003-02-12 14:51 ` Eric W. Biederman
2003-02-12 16:06 ` Corey Minyard
2003-02-13 11:13 ` Suparna Bhattacharya
2003-02-14 3:13 ` Werner Almesberger
2003-02-14 14:20 ` Corey Minyard
2003-02-14 18:10 ` Werner Almesberger
2003-02-14 18:23 ` Corey Minyard
2003-02-14 19:26 ` Zwane Mwaikambo
2003-02-14 19:44 ` Werner Almesberger
2003-02-14 20:00 ` Corey Minyard
2003-02-15 6:03 ` Eric W. Biederman
2003-02-16 16:22 ` Corey Minyard
2003-02-16 21:48 ` Eric W. Biederman
2003-02-17 4:26 ` Corey Minyard
2003-02-17 7:18 ` Eric W. Biederman
2003-02-17 17:32 ` Corey Minyard
2003-02-12 4:47 ` Suparna Bhattacharya
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=m1y94nxv4e.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=cminyard@mvista.com \
--cc=ken@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkcd-devel@lists.sourceforge.net \
--cc=suparna@in.ibm.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