Partial PCI resets --- will this work?

Partial PCI resets --- will this work?

Post by bme.. » Thu, 12 Jul 2001 01:45:07


I have just run into a problem with a project that might need a bit
of atrocious kernel hacking. And as I don't quite know what I am doing :),
I thought it would be a good idea to find out whether I am setting myself
up for misery....

The project I am working on is an emulator, which however gives a high level
of hardware access to the emulated system. In particular, the emulated system
is supposed to be able to use all the PCI devices (more correctly: functions)
that are not actually in use by the kernel itself. Interrupts are mapped into
user space signals through Dmitry A. Fedorov's irq patch, and then mapped into
the emulated machine's interrupt mechanism.

This works wonderfully right now; Using for example a PCI-NE2k in the emulated
machine is rock stable.

However, there is one problem --- The emulated machine can be reset at any
time. On a real machine, this would send a RESET signal to the PCI bus,
sending all devices back to inactive, harmless settings.
In the emulation, however, no such hardware signal is generated on the
real, physical PCI bus (and if it was, the devices under linux' control
would reset as well, which would be very bad). On the other hand, I cannot
just let the devices remain active, because any interrupts they generate
won't be cleared (the device drivers running on the emulated machine are
no longer there to clear them)[1]. So whenever a reset occurs in the emulation,
I need to gracefully shut down the devices under emulator control, back
to bootup state, without touching the devices under linux' control....

After doing a fair bit of reading, it appears to me that my best bet is to
move the devices into power management mode D3hot, and back to D0, and then
restore the bootup config space settings (which I would have saved earlier,
before any drivers messed around with them). My understanding is that this
should safely put the cards back into the same inactive state they were in
right after power-up; In particular, that they won't be generating interrupts
or busmaster traffic anymore?!?

There are some issues I am not quite clear on, however:

   * There seem to be contradicting opinions on whether all PCI devices
     are safe to take to D3hot and back to D0. While some sources say
     that *all* PCI devices support D3, some disagree. Is there a definitive
     source on that one?
   * The documentation only says that one should *assume* all registers to
     be lost after a D3->D0 transition. Does that mean that theoretically,
     a device is at liberty to *not* become inactive through the D0->D3->D0
   * I have found only one rather vague source on how long the D3->D0
     transition might take (which says to wait 10ms). Is there some more
     authoritive information available somewhere?
   * Do I need to manually disable the Busmaster, I/O and memory response
     bits in the command register before the D0->D3 transition, or is it
     safe to simply send PCI devices to sleep from any active state?
   * If a PCI device is holding its interrupt line active at the time I do
     the D0->D3->D0 cycling, will my action result in the line becoming

Lots of questions, and not enough PCI hardware to do exhaustive testing
with... Thus I am appealing to the people who actually know how this stuff
is supposed to work :)

Any ideas?


P.S.: If you are replying to this in the intel.other_components.pci_chipsets
      group, please leave the linux group in --- it appears my server doesn't
      actually carry the intel one. Thanks.

[1]: Of course, this in itself isn't a problem yet. The problem comes up if
     the now unhandled PCI device shares its interrupt with another, still
     handled device; Due to the other device, the interrupt controller will
     be programmed to have the interrupt line enabled, and due to the
     unhandled device,  the interrupt will never get inactive. Baaaad
     combination :(

Thomas --- Jefferson --- still surv--
John Adams
2nd President of the US
Last words, 4 July 1826


1. /usr/bin/{reset,clear) - clear does not work even after reset

After spilling a binary file on an xterm screen, I run /usr/bin/reset to
clear things up (get normal character set back instead of the

But then /usr/bin/clear still is not working, and command
line editing is a bit flaky, too (for example, backspace does not remove
characters on the screen, just passes over them. They do get deleted
from the buffer, though).

I manually ran stty -a on a known good xterm and the bad xterm and
adjusted 2-3 settings that were different, but still no luck.

What else could it be?? Thanks ...


Speaking for myself only

2. GDBM on different platforms?

3. Will this partial-Linux strategy work to copy NTFS partition

4. vfs: Disk change detected on device ide1(22,0)

5. Strange network problem (network suddenly stops working) - partial solution

6. Removing XFree86.

7. Does 3C905 PCI work with Diamond Stealth Trio 64 (S3 764) PCI?

8. Win2000 won't talk to my linux file server!

9. highmem pci dma mapping does not work, missing cast in asm-i386/pci.h

10. need to change/reset the IRQ on a 3com PCI 3C905B-TX

11. Reset PCI card

12. PCI NCR scsi, Sony CDROM, NCR53c7xx reset is NOP

13. scsi: WARNING: /pci@8,700000/scsi@1,1 (glm3): got SCSI bus reset