search for: ioremapping

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

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

...b/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-mm-for-linus Andres Salomon (1): x86, mm: Create symbolic index into address_markers array Borislav Petkov (1): x86, tlb: Clean up and correct used type Florian Zumbiehl (1): x86, iomap: Fix wrong page aligned size calculation in ioremapping code Jiri Slaby (1): x86-64, mm: Initialize VDSO earlier on 64 bits Kenji Kaneshige (2): x86, ioremap: Fix incorrect physical address handling in PAE mode x86, ioremap: Fix normal ram range check Marcin Slusarz (1): x86, kmmio/mmiotrace: Fix double free of kmmio_fault_pag...

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

Hello , I have installed RHEL 5 on a Intel Core Duo processor based board. It has 1 GB of physical memory. I have a driver which uses the memory reserved at the top of the high memory. Well this driver worked fine on all the previous versions of RHEL/FC and also with RHEL 5 with virtualization disabled. But with virtualization enabled , the ioremap to the memory reserved at the top of high

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

http://bugs.freedesktop.org/show_bug.cgi?id=14941 Summary: ioremap leak in DRM Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

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

Hi, > I am a newbie, andy gave me some directions to submit the patch, eg: check > ioremap leak. At this time, I found that the bochs driver may have similar > problems, so I submitted this patch, then, Andy said the best is to switch > this driver to use pcim _ * () functions and drop tons of legacy code. > I think we might be able to fix this issue first, after that, drop tons

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

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,