Two drivers, one physical device: How to deal with that?

[Andre Albsmeier]

On Mon, 29-Dec-2008 at 14:35:21 -1000, Jeff Roberson wrote:
> On Mon, 29 Dec 2008, Andre Albsmeier wrote:
> 
> > Hello,
> >
> > I have written a driver which attaches to the host bridge in
> > order to periodically read the appropriate registers and
> > inform the user about ECC errors (ECC-Monitor). No I have
> > run across a mainboard where the host bridge is already
> > taken by the agp driver. Of course, I can detach the agp
> > driver and attach myself and everything is working but
> > what is if someone does not want to loose the agp
> > functionality?
> >
> > How does one deal with the case when two separate drivers
> > have to access the same device (the host bridge in my case)?
> >
> > I assume, the correct way would be to join the AGP and
> > ECC functionality in one driver but maybe there are other
> > tricks I am not aware of?
> 
> Well I don't think it would be correct to merge two conceptually seperate 
> drivers into one just to share the same device.  It sounds like the right 
> solution is to make a generic layer the attaches to the host bridge and 
> arbitrates access to it.  Then allow other device to find and communicate 

I see, yes, that sounds as a good idea. I also didn't
like the idea of uniting the two functionalities. However,
I assume my kernel programming skills are not good enough
to implement something like this ;-)

> with this generic layer.  For the host bridge this doesn't have to be 
> particularly fancy.
> 
> I am curious; how do you test the ECC functionality?  Is there a way to 
> induce an error?

The most common method is to lower the voltage and heat up the
DIMMs. Some chips react rather quickly, others nearly have to be
molten down ;-). Another possibility is to use a not too weak
radioactive source (an old Radiomir watch is not enough) to
bomb the RAMs with betas and gammas (this is of course not for
everybody ;-)).

But the easiest and safest way is to buy an Asus P5W board and
enable the "Quick Boot" option in the BIOS.  With this setting,
lots of ECC-errors are produced in a short time. The rate goes
down as the uptime rises. I don't know why this happens but I
assume the chipset reads memory cells which have never been written
to and therefore the data is inconsistent. As soon as you disable
the "Quick Boot" option (which implies a memory writing test being
performed by the BIOS) the errors go away. You can then even enable
"Quick Boot" again, as long as you don't switch of the power...

Thanks,

	-Andre

-- 
GNU is Not Unix / Linux Is Not UniX