Hi,
On Wed Jul 11, 2012 at 15:20:33 -0500, Mai, Haohui wrote:
This is an important problem to solve. I'm seeing 60x slow down on the graphics component of L4Android right now because of this frame buffer issue.
This is software rendering versus something with hardware support.
I'm using an Eee PC which has an i945 chip. I tweaked my configuration a little bit but I still had no luck.
There're two possible bugs(?) here:
(1) The driver got confused because l4pci changes the func field of the pci table. The func field in PCI table is to describe whether there's another device attached to the slot. Here is code in Linux kernel causing problem:
gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, NULL); if (gmch_device && PCI_FUNC(gmch_device->devfn) != 0) { gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, gmch_device); }
On my machine, L4PCI reports the func field of my card (gmch_device in the code) as 1, which makes it find the "next" display card (i.e., executing the if branch). Therefore it cannot find the device.
I worked around it by disabling the if statement, and the kernel can detect the card and map in mmio memory.
Are you using PCI_bus_ident() instead of PCI_bus() in your vbus config?
(2) L4Linux is unable to execute "wbinvd" instruction. wbvind is a privileged instruction to write back all caches and invalidate them. The driver is executing this instruction at ring 3 -- thus generating a #GP fault.
This is more troublesome and I don't really have a good idea of how to fix it. I appreciate if you can tell me the quickest way of fixing it.
Looking at this a bit... this is just done for initializing the ringbuffer which lives in non-caches memory already. It does not seem to be used during runtime. There's also no comment why such a complete global flush is required at all. Maybe to flush something else? Hmm. My suggestion would thus just be to comment that out and see if it works without.
Adam