On Fri, Jun 03, 2005 at 08:11:01AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2005-06-02 at 14:02 -0300, Marcelo Tosatti wrote: > > Hi Ben, > > > > On Thu, Jun 02, 2005 at 12:46:32PM +1000, Benjamin Herrenschmidt wrote: > > > On Wed, 2005-06-01 at 13:50 -0300, Marcelo Tosatti wrote: > > > > > > Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With > > > "proper" PCMCIA controllers, those are swallowed properly when the card > > > is removed. The eating of the machine check is a bit too hackish to my > > > taste... Better is to "not do that" by making sure the legacy crap isn't > > > trying to tap unexisting ports, but then, if PCMCIA is also a > > > problem... > > > > Well, cardmgr calls the driver's shutdown/close routine as soon as > > the card is removed. Some of those methods write to IO registers in > > the process (eg net/pcmcia/pcnet_cs.c). > > > > I dont see any elegant change that could be done in PCMCIA. > > I know, the thing is, on platforms with a "classical" PCI<->PCMCIA > bridge, the bridge will not issue machine checks when the card is > removed. I don't know if that is possible with your HW setup, I suppose > you are hooking PCMCIA directly to the CPU IO bus ...
I think the PCMCIA bus is hooked directly to the CPU, yes. > > One possibility that comes to mind would be to enforce the rule > > that drivers should not writeout in case of a removal event, > > They can't know, they get the removal even too late. The driver may be > in the middle of writing when you remove the card. If there is no HW way > to prevent the machine check, then you'll need software recovery. > > > but that does not sound feasible to me: It just looks too messy, > > however I have no good argument against it. > > > > Well, its restricted to 8xx (maybe 32-bit PPC) with PCMCIA, so its > > just not worth the trouble? > > Hehe... dunno. > > > Hmmm... I'll look that up. My limited testing on HW in question does not > > exhibit longer MCE delays than "twi/isync/nop" sequence - actually, it is > > always triggered during the IO access instruction itself. > > I suppose the 8xx may actually be quite synchronous on IOs then... > > > Where can I find information about write posting on 8xx? Is there a > > term for it used in PPC documentation? I can't find anything... > > Well, do you have a store queue ? What does the 8xx manual says about > ordering & queueing of non cacheable loads & stores ? Maybe the chip is > fully synchronous on IOs ? It seems so, yes. Section 6.1 of MPC860UM.pdf: "All exceptions associated with memory are implemented as precise, which means that a load/store instruction is not complete until all possible error indications are sampled from the load/store bus. This also imples that a store or nonspeculative load instruction is not issued to the load/store bus until all previous instructions have completed." I'll prepare a new patch reflecting this information, thanks again Ben.