similar to: ioremap failure on highmem reserved memory with RHEL 5 Xen Linux

is_local_lowmem() treats its physical address input as a machine address; this causes agpgart to fail while calling ioremap_nocache(). X still does not load on my Athlon 64 / Via S3 Unichrome, so perhaps best not to apply just yet. Signed-off-by: Avi Kivity <avi@qumranet.com> --- xen-ioremap-fix/linux-2.6-xen-sparse/arch/i386/mm/ioremap-xen.c~ioremap 2006-06-22 20:30:20.000000000 +0300

The header is not longer used and on alpha, ia64, openrisc, parisc and um it was completely unused anyway as these architectures have no highmem support. Signed-off-by: Thomas Gleixner <tglx at linutronix.de> --- V3: New patch --- arch/alpha/include/asm/kmap_types.h | 15 --------------- arch/ia64/include/asm/kmap_types.h | 13 ------------- arch/openrisc/mm/init.c |

Hi Christoph, Thanks for your comments. I'm also replying here to your comments on the previous series. On Tuesday, March 17, 2020 10:28:35 AM EDT Christoph Hellwig wrote: > Any reason drivers can't just use pci_map_rom instead? which already > does the right thing? Some machines don't expose the video BIOS in the PCI BAR and instead only make it available via EFI boot

On Fri, Mar 13, 2020 at 06:22:58PM -0400, Mikel Rychliski wrote: > /** > + * pci_platform_rom - ioremap() the ROM image provided by the platform > * @pdev: pointer to pci device struct > * @size: pointer to receive size of pci window over ROM > + * > + * Return: kernel virtual pointer to image of ROM > + * > + * The caller is responsible for removing the mapping with

Some chips that use system memory exclusively (e.g. GK20A) do not expose 2 BAR regions. For them only BAR1 exists, and it should be used for USERD mapping. Do not map BAR3 if its resource does not exist. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

Some chips that use system memory exclusively (e.g. GK20A) do not expose 2 BAR regions. For them only BAR1 exists, and it should be used for USERD mapping. Do not map BAR3 if its resource does not exist. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

Some chips that use system memory exclusively (e.g. GK20A) do not expose 2 BAR regions. For them only BAR1 exists, and it should be used for USERD mapping. Do not map BAR3 if its resource does not exist. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> Reviewed-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 6 ++++-- 1 file

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

Use ioremap() for mapping the channel user regs (that are never exposed to user space) instead of drm_addmap(). This removes the last use cases of drm_addmap/drm_rmmap from Nouveau. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 13 ++++++------- drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +++------

On Wed, Mar 18, 2020 at 10:16:23PM -0400, Mikel Rychliski wrote: > On some EFI systems, the video BIOS is provided by the EFI firmware. The > boot stub code stores the physical address of the ROM image in pdev->rom. > Currently we attempt to access this pointer using phys_to_virt(), which > doesn't work with CONFIG_HIGHMEM. > > On these systems, attempting to load the

http://bugs.freedesktop.org/show_bug.cgi?id=26813 Summary: Nouveau ioremap WARNING with current Linus' git tree Product: xorg Version: 7.5 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

I used ioremap() function to map the memory behind a PCI device to the processor main memory. How could xen be forced to use this mapped section for allocating memory for all DomU guests? Where in xen source code the respective modification has to be made? regards, Dinesh C _________________________________________________________________ Timely update on all current affairs, sports, events

I used ioremap() function to map the memory behind a PCI device to the processor main memory. How could xen be forced to use this mapped section for allocating memory for all DomU guests? Where in xen source code the respective modification has to be made? regards, Dinesh C _________________________________________________________________ Timely update on all current affairs, sports, events

Hi all, Does anybody have an idea about this "ioremap error" during the booting stage of VM CentOS7, although it can eventually bootup successfully. Regards, Allen 2014-11-05 Allen Qiu

On Tue, Apr 21, 2020 at 7:45 PM Dejin Zheng <zhengdejin5 at gmail.com> wrote: > > It forgot to call bochs_hw_fini() to release related resources when > bochs_pci_probe() fail. eg: io virtual address get by ioremap(). Good start, although I think the best is to switch this driver to use pcim_*() functions and drop tons of legacy code. > Fixes: 81da8c3b8d3df6 ("drm/bochs:

On Wed, Apr 22, 2020 at 4:52 PM Dejin Zheng <zhengdejin5 at gmail.com> wrote: > > On Tue, Apr 21, 2020 at 08:24:24PM +0300, Andy Shevchenko wrote: > > On Tue, Apr 21, 2020 at 7:45 PM Dejin Zheng <zhengdejin5 at gmail.com> wrote: > > > > > > It forgot to call bochs_hw_fini() to release related resources when > > > bochs_pci_probe() fail. eg: io