In /os-support/bus/Pci.c function handlePciBIOS line 1194 we see the
pciWriteLong (Tag, PCI_MEM_REG_START + (b_reg << 2) (CARD32)~0);
This is the call that remaps one of the BAR registers to the end of PCI
Configuration space. It would seem that the intention of doing this is
so that the PCI_MAP_ROM_REG and the BAR register will not overlap in PCI
Configuration space. However, this is assuming that either A. The end of
PCI Configuration space is B. If you have a conflict at that location for a
brief moment it will not destablize the system. In the problem case we have an
IDE controller at the end of PCI Configuration space and during the remapping
the grahpics card claims the transactions which belong to the IDE controller
causing a system hang and an IERR.
I tried testing basereg = -1 in hopes that the PCI Remapping could be avoided.
However, the logic of the of the handlePciBIOS routine and getValidBIOSBase
When you set basereg=-1 the first for loop will exit with b_reg= -1. Then the
getValidBIOSBase routine will be invoked and it will return false. This will
cause a continue and i will be incremeted. Eventually b_reg will get to the PCI
Remapping logic with value 1.
Egbert, could you take a look at this one? It's in a part of the code that I
think you originally wrote. It seems like there should be a way to get around
the need to remap video mem. Or, perhaps we should remap it to an area not
Egbert - any comments?
Yep. This is bad. I know. Changing this to a kernel supported method of reading
the BIOS is not really a short term (quick fix) kind of thing.
You can ask the system to find a range that's available by passing ROM_BASE_FIND
in the basereg argument.
I don't know if this will work for everybody. In our normal heuristics it is
used as the last fallback.
Maybe we should find such a range to map the unused register to.
Created attachment 3941 [details] [review]
One may try something like this. Please note: this is entirely untested. I
won't have time to test it until next week.
Also a little file for xfree86/dummylib/ is missing. I will attach it next. It
is newly created so this must be fixed in the modular build too.
Created attachment 3942 [details]
mssing file (see comment above)
Created attachment 4869 [details] [review]
final fix for monolithic tree
The patch in comment #7 applies to 6.9.0 only, however there have been various
changes to the code between 6.8.2 and 6.9.0 which cause the patch to not be
useable as-is with 6.8.x.
Code added from the SGI Altix support added to 6.9.0/7.0 are getting patched,
however it's not completely clear if we can just drop that part for 6.8.2,
or if further work is needed to make it work.
Any comments/suggestions for getting it working cleanly with 6.8.x?
egbert: ping. what's the status of this for 7.1?
(In reply to comment #9)
> egbert: ping. what's the status of this for 7.1?
egbert: PING. what's the status of this for 7.1?
I would like to see the attached patch applied. I will see if I can get around
to doing this tonight.
On Linux my OS reading patch should avoid touching this code, of course it'll
only help if the user is a) running Linux, b) running a late enough linux with
rom reading in sysfs.
applied, with minor massaging to account for bug #6377. thanks!