https://bugzilla.novell.com/show_bug.cgi?id=422081 User novell.com-pnt@ladisch.de added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c1 --- Comment #1 from Julian Ladisch 2008-09-02 03:48:10 MDT --- Created an attachment (id=236681) --> (https://bugzilla.novell.com/attachment.cgi?id=236681) /var/log/Xorg.0.log.old (crash) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|sndirsch@novell.com |lverhaegen@novell.com Summary|Xen - unichrome: xf86MapVidMem: Could not mmap |xf86-video-unichrome/Xen: xf86MapVidMem: Could |framebuffer (Bad address) |not mmap framebuffer (Bad address) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 User sndirsch@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c4 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cgriffin@novell.com, sndirsch@novell.com Info Provider|novell.com-pnt@ladisch.de |cgriffin@novell.com --- Comment #4 from Stefan Dirsch 2008-09-03 04:16:15 MDT --- I hope that Clyde can help here. At least he maintains our Xen kernel and is supposed to know who can help here. I'm afraid that the reporter does not know enough about the internals of our Xen kernel. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 User novell.com-pnt@ladisch.de added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c7 --- Comment #7 from Julian Ladisch 2008-09-05 09:13:45 MDT --- Created an attachment (id=237914) --> (https://bugzilla.novell.com/attachment.cgi?id=237914) xm dmesg -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 User lverhaegen@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c9 --- Comment #9 from Luc Verhaegen 2008-09-07 01:01:19 MDT --- (In reply to comment #6 from Jan Beulich)

Unfortunately I have a hard time understanding #3: How can the frame buffer validly live at (physcial) address 0?

All of the physical RAM sitting off the CPU starts at address 0, the CPUs memory controller sees all of it, including the bit reserved for the framebuffer. The BIOS, yes, through E820, just doesn't mention that reserved part (which always sits at the top of this physical ram).

/dev/mem under Xen is somewhat different from native for obvious reasons: It doesn't allow you to access RAM, only MMIO regions (as reported by BIOS INT 15 Fn E820) can be accessed (and the region mmap()-ed must be consisting of only MMIO, there may not be any RAM portions, but that's probably not the problem here).

X maps memory, any memory, through /dev/mem. I understand that Xen changes things and makes it impossible to use direct RAM access for FB. But this still leaves me wondering: how does X map a memory BAR on our graphics device if only MMIO BARs are accessible? Why are you not running into issues with other drivers? Anyway, for my driver, i am looking into two things: * Is there an easy way for me, an X driver, to tell that Xen is active, so that i can go and map the PCI BAR instead. * Is there a way for me to still map a part of physical memory? Direct RAM access really is a night and day difference on this hardware. Any read or write to the FB then becomes a simple copy from one bit of RAM to the other. Without direct access, any read/write would uselessly loop the same data over the HT busses to the northbridge. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 User jbeulich@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c10 Jan Beulich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|jbeulich@novell.com | --- Comment #10 from Jan Beulich 2008-09-08 02:02:16 MDT ---

All of the physical RAM sitting off the CPU starts at address 0, the CPUs memory controller sees all of it, including the bit reserved for the framebuffer. The BIOS, yes, through E820, just doesn't mention that reserved part (which always sits at the top of this physical ram).

As long as the E820 map reports the range in question as RAM, Xen won't allow you to map it (and Dom0 generally can't even assume it owns it). But I can't see how that scenario would work in a native kernel either. At the example of the E820 map provided (or one you would provide) - could you illustrate where the memory range in question would be located? Note that in my previous reply, I considered MMIO any memory that is not RAM from an E820 perspective - meaning that any such memory (be it, as you name them, from an MMIO BAR or a memory BAR) can be mapped through /dev/mem under Xen.

* Is there an easy way for me, an X driver, to tell that Xen is active, so that i can go and map the PCI BAR instead.

You'd see /proc/xen/ as well as various entries under /sys/hypervisor/.

* Is there a way for me to still map a part of physical memory?

As said above - as long as the memory is not marked as RAM in the E820 map, there should be no problem. But clearly, address 00000000 will always be marked as such on any PC-compatible system (and I continue to not believe that the frame buffer would be sitting there). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 User jbeulich@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c12 --- Comment #12 from Jan Beulich 2008-09-08 08:49:02 MDT --- With this E820 map you shouldn't have any problem mapping the 64Mb range at 0x1c000000 under Xen. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 User lverhaegen@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c14 Luc Verhaegen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |novell.com-pnt@ladisch.de --- Comment #14 from Luc Verhaegen 2008-09-08 10:23:39 MDT --- Hrm, so it seems to be some weirdness of Xen and Xorg and accessing pci config space. Julian, can you try this, as this goes through a direct copy the xorg servers pci infrastructure? pcitweak -r 0:0:3 0x44 pcitweak -r 0:0:3 0xA0 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Minor Priority|P5 - None |P4 - Low -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=422081 User lverhaegen@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=422081#c20 Luc Verhaegen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #20 from Luc Verhaegen 2008-12-04 08:25:50 MST --- Found it... It's stupidity when mapping/unmapping to get rid of an offending MTRR setting by the bios. This happens before the FB Base is set, yet this has never shown up as a problem before. I should've checked the code in ScreenInit before i went and blamed the host code, then i would've seen it earlier. Anyway, is fixed upstream now: http://cgit.freedesktop.org/~libv/xf86-video-unichrome/commit/?id=0d6e607f I will get a new driver package out tomorrow, as i am waiting for a positive test result on another bug as well. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.