;
In a msg of , Kris Steenhaut writes to Eddy Thilleman:
;
Kris,

 KS> If there is a PCI EIDE controller in your system, and you happen
 KS> to have a Matrox video board, then the boot process might just
 KS> stop at a certain point or fail with a trap 8. This is due to a
 KS> horribly nasty behaviour of the Matrox driver wich scans all
 KS> ports with addresses Cx0yh (x = 0..F, y = 0..3) at initialization
 KS> of the base video handler even if these addresses are not
 KS> assigned to the video board. I wouldn't call it playing by the
 KS> rules beating the bush and looking if some sort of MGA drops out
 KS> of it.

 KS> If any other PCI device gets assigned addresses matching the
 KS> above pattern, *anything* can happen. To work around this
 KS> problem, I have added a new option /MGAFIX which detects EIDE
 KS> hardware with addresses affected by that, and tries to push them
 KS> away a little by reprogramming the address decoders so that they
 KS> are no longer potential scan targets.

 KS> On my system here, the /MGAFIX trick doesn't work, btw.

 KS> And I do have the "anything could happen" feature. ((-:


I think it fair to point out here (again), as Dani did in the hardware list,
that the above refers only to a 'failure to boot' problem that occurs EVERY
TIME you boot.  If it doesn't happen EVERY TIME you boot, or problems crop up
after you have booted and run for a while YOU DO *NOT* HAVE the problem she
described, and '/MGAFIX' will not solve the problem.

And again, the 'block on high processing' and 'crash on large file transfers'
you have mentioned are not a result of the problem '/MGAFIX' solves.  I think
you may be more prudent to investigate the National version thing that the
Matrox drivers.

-[Steve]-

--- GoldED/2 3.0.1/#