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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:51 EST