Date: Tue, 30 Dec 2008 14:52:16 +0100 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: Jeff Roberson <jroberson@jroberson.net> Cc: Andre Albsmeier <Andre.Albsmeier@siemens.com>, freebsd-arch@freebsd.org Subject: Re: Two drivers, one physical device: How to deal with that? Message-ID: <20081230135216.GA2182@curry.mchp.siemens.de> In-Reply-To: <20081229143221.X1076@desktop> References: <20081229212020.GA1809@curry.mchp.siemens.de> <20081229143221.X1076@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081230135216.GA2182>