From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: "Adam J. Richter" <adam@yggdrasil.com>,
eblade@blackmagik.dynup.net, linux-kernel@vger.kernel.org,
rmk@arm.linux.org.uk, ebiederm@xmission.com
Subject: Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should n
Date: Mon, 14 Oct 2002 20:36:54 +0200 [thread overview]
Message-ID: <49A685A38EF@vcnet.vc.cvut.cz> (raw)
On 14 Oct 02 at 13:48, Richard B. Johnson wrote:
> > > itself as random of other programs, not getting through the reboot
> > > process half of the time, etc.
> >
>
> A processor reset will get the processor onto the bus even if there is
> an ongoing DMA operation. Since the first of many instructions are
> fetched from ROM, it is quite likely that any DMA activity would have
> stopped before the ROM is shadowed by the BIOS. I don't see "ongoing"
> DMA as being a problem, which you can verify by forcing a reset in
> the FDC code (easiest to do) while waiting for read DMA to complete.
> FDC DMA is slow, so you can catch it 100% of the time.
Not all DMA transfer finishes in finite time. When I have enabled
picture feed to videoram on LML33 I have here in my dual AMD, nothing
is going to stop transfer: it will happilly feed data during soft
reboot. Either computer will refuse to boot completely because of
videobios will not be able to initialize videoram (Hey, you have
with no usable video memory, all write-verify cycles failed: returned
data differ from written one. Please add some memory chips...),
or you'll see garbage on screen until device's busmastering bit
is disabled (when LML33 driver is loaded...).
Only problem is when you are going to disable busmastering: like
we have early printk console, we need its counterpart on shutdown,
as PCI video drivers can be unloaded long before other drivers finish
unloading (== poweroff does not work on my system for some time.
I assume that it oopses somewhere after matroxfb shutdown), and
after shutting down PCI-AGP bridge no message can find its way to
the screen, even with any early printk solution...
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
reply other threads:[~2002-10-14 18:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=49A685A38EF@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=adam@yggdrasil.com \
--cc=ebiederm@xmission.com \
--cc=eblade@blackmagik.dynup.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=root@chaos.analogic.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