Date: Mon, 11 Mar 1996 15:14:35 +1100 (EST) From: michael butler <imb@scgt.oz.au> To: terry@lambert.org (Terry Lambert) Cc: current@freebsd.org Subject: Re: AMD doesn't like SNAP! (panic: unwire: page not in pmap) Message-ID: <199603110414.PAA14846@asstdc.scgt.oz.au> In-Reply-To: <199603101921.MAA01621@phaeton.artisoft.com> from "Terry Lambert" at Mar 10, 96 12:21:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > I note that through a number of drivers there is mention of > > cache-invalidation instructions (software-style) but none of them seem > > to implement anything of this nature. Is there a problem with doing this > > .. that is .. to invalidate the page(s) into which data has just been > > transferred prior to the application being told that the transfer > > completed? No other cases need to be considered do they ? > OK. This is an interesting topic. 8-(. :-) > Before, when I suggested that a DMA be triggered as part of a probe > process on a per controller basis to determine if bounce buffers > were necessary, I neglected the non-working cache case. The cache > cases need to be considered at the same time because they need to > trigger similar controller/memory events in order to be detectable. This was actually what I was hinting at .. it is as difficult to establish if a controller/mother-board combination will perform reliable IDE multi-block transfers or direct DMA above 16 meg. For those cases, the default configuration takes the "safe" option .. in the former case, we don't attempt multi-block transfers and, in the latter, "bounce-buffers" are enabled in the GENERIC kernel (with some special cases dealt with in the relevant driver, e.g. BT445S). My idea was that we assume the hardware is broken and it is up to the owner of the box to decide when (or if) to test the potentially "optimal" case. > When a bus master DMA occurs, there is supposed to be a cache > notification, and the L1 and L2 cache lines are supposed to be > invalidated or written back for the memory range in which the DMA > took place. Ah .. one case I forgot .. write-back has to occur prior to the DMA being initiated in the "write" transaction .. oops :-( > It isn't worthwhile to BINVD in the majority of cases, because the > majority is people with functional cache hardware. Admittedly, we > have self-selected this by not "fixing" the problem in software for > people without the good hardware. The number of people who are likely to buy "write-back" CPUs because they are led to believe by some over-enthusiastic sales-droid that there is something to be gained will probably increase. I'm (conceptually) looking to assist them in making the default case work. > A decent fix would require a lot of effort and a lot of hooks to make > it work in all cases (for instance, I could have two VLB controllers, > one in a "master" slot, one not; the fix has to have a per controller > granularity, etc.). 8-(. My proposed default of assuming brain-damage would work in this case although sub-optimally. If they change it and it breaks, the fix is obvious and it (should) be apparent that whatever they changed broke it, i.e. it was not FreeBSD's fault that their hardware isn't up to standard. As I think we're all aware, perception is far more powerful than technical excellence if you're looking for market-share .. some large PC software companies continue to prove that daily :-(. Working sub-optimally is better than not at all, michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603110414.PAA14846>