Bob Breuer wrote:
At this point, I am guessing that some pte's allocated for the framebuffer are being wrongly re-used when loading the module.
On Sat, Jan 15, 2005 at 08:25:35PM -0600, Bob Breuer wrote:
The cg14 driver is not remapping the framebuffer, and is using the mappings that were setup by the prom and recreated in linux from srmmu_inherit_prom_mappings().
How can we tell vmalloc not to step on that area of memory? Is it just from VMALLOC_START to END? Let's see, for 2.6 those are 0xfe600000 and 0xffc00000. The prom mapped the cg14 to 0xfe700000 (8MB ram) and 0xffec0000 (registers). Hmm, a bit of overlap there... And 2.4 had VMALLOC_START at 0xfe300000. So it would seem that if the total vmalloc'ed memory goes above 1 meg for me, 2.6 will have problems, but 2.4 will still be fine.
This sounds like a real problem. What happens if you move VMALLOC_START to where it was in 2.4.x?
Yes, changing it back fixes my problem for now.
The bitkeeper comments say it was changed 4 months ago to fix a framebuffer on a SparcStation 2. Looks like we need something more dynamic to cover all the bases.
Bob - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
