| Summary: | Reading Video BIOS using xf86ReadPciBIOS results in system hang | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | jon chaplick <chaplick> | ||||||||
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | critical | ||||||||||
| Priority: | high | CC: | eich, kem, mharris | ||||||||
| Version: | git | ||||||||||
| Hardware: | x86 (IA32) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 5041 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
jon chaplick
2005-08-19 11:47:28 UTC
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 prevents this. 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 currently occupied. 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] Possible solution 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! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.