similar to: Large vmalloc segments with PXELINUX

Matthew Schumacher wrote: > List, > > I think I found a bug here because I can repeatably get the same kernel > (checked with md5sum) to decompress and to fail with the error: > > invalid compressed format (err=2) > > --System halted > > > Here is how I can reproduce the problem: > > Boot 2.6.8-rc1 > Run md5sum on 2.6.8-rc1 kernel >

I've begun tinkering with syslinux v3 and have uncovered an anomoly with the DISPLAY file when called by pxelinux.0. If I have: DISPLAY boot.msg With an "^Xsplash.lss\n" in the file boot.msg (exactly: 18 73 70 6C 61 73 68 2E 6C 73 73 0A) file, it will fail to load the rle image. And produce some goofy results in the tftpd log: Jun 5 06:27:06 pxe in.tftpd[24649]: RRQ from

Hi Everyone, I have, for the first time, installed and minimally configured a cvs server on a CentOS 5 box. I followed a "how to" to do the initial configuration, so I'm sure I haven't done anything wrond (according to the "how to", anyway). But, I keep getting this error: $ CVSROOT=:pserver:ksandhu at kermit:/var/cvs/asterisk $ cvs login Logging in to

Attempts to load *.lkrn images were failing with "Not enough memory to load specified image". These images have the su_ramdisk_max header field set to zero, and the code in core/runkernel.inc was limiting MyHighMemSize too early (before the load_high call used to load the main part of the kernel). Signed-off-by: Sergey Vlasov <vsu at altlinux.ru> --- core/runkernel.inc | 13

Hi, I'm booting an qemu VM from a virtual disk. In the success case the virtual console shows something like this: SYSLINUX 4.05 0x54f93f16 Copyright (C) 1994-2011 H. Peter Anvin et al Loading vmlinuz......... Loading initramfs.img...................................ready. [ 0.000000] Initializing cgroup subsys cpuset <etc> In the failure case I'm seeing something like this:

Hi, in syslinux-386, I think I've found a problem in com32/lib/syslinux/load_linux.c that leads to cmdline being truncated unnecessarily when e.g. linux.c32 is used. The patch below fixes the problem for me. But I don't know, whether the patch is safe in all cases. I tried to reproduce the logic found in runkernel.inc, but I might have missed something. So, feel free to tell me

Hello I''ve got a server with 3Gb of ram and I want to keep 256 for the system and allocate the rest to conntrack ... I''ve tried to change the HASHSIZE of the ip_conntrack but dmesg return me this error ! ip_conntrack version 2.4 (2097152 buckets, 16777216 max) - 236 bytes per conntrack ip_conntrack: falling back to vmalloc. .... I''ve use this "math"

Found this looping Ubuntu installs with VMI. If unlucky enough to hit a vmalloc sync fault during a lazy mode = operation (from an IRQ handler for a module which was not yet populated = in current page directory, or from inside copy_one_pte, which touches = swap_map, and hit in an unused 4M region), the required PDE update would = never get flushed, causing an infinite page fault loop. This

Found this looping Ubuntu installs with VMI. If unlucky enough to hit a vmalloc sync fault during a lazy mode = operation (from an IRQ handler for a module which was not yet populated = in current page directory, or from inside copy_one_pte, which touches = swap_map, and hit in an unused 4M region), the required PDE update would = never get flushed, causing an infinite page fault loop. This

Op 05-03-13 19:57, Marcin Slusarz schreef: > Page tables on nv50 take 48kB, which can be hard to allocate in one piece. > Let's use vmalloc. > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > Cc: stable at vger.kernel.org [3.7+] > --- > drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >

On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > I was getting a order 4 allocation failure from kmalloc when testing some game > after a few days uptime with some suspend/resumes. For big allocations vmalloc > should be used instead. I've picked up this patch with a minor modification (see below) > > Also limit size more

Some firmware images may be large (64K), so using kmalloc memory is inappropriate for them. Use vmalloc instead, to avoid high-order allocation failures. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at vger.kernel.org --- Couldn't get video decoding started on a long-running system due to high-order allocation failures. This seems like a fine use-case for vmalloc.

The subject says it all. There is no need to specify different page protection bits based on the architecture. Signed-off-by: K. Y. Srinivasan <kys at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/hv.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/staging/hv/hv.c b/drivers/staging/hv/hv.c index

The subject says it all. There is no need to specify different page protection bits based on the architecture. Signed-off-by: K. Y. Srinivasan <kys at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/hv.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/staging/hv/hv.c b/drivers/staging/hv/hv.c index

Hello. On 09/17/2013 11:21 AM, Michael S. Tsirkin wrote: > As vhost scsi device struct is large, if the device is > created on a busy system, kzalloc() might fail, so this patch does a > fallback to vzalloc(). > As vmalloc() adds overhead on data-path, add __GFP_REPEAT > to kzalloc() flags to do this fallback only when really needed. > Reported-by: Dan Aloni <alonid at

On Wed, Dec 04, 2013 at 08:43:18PM +0000, Richard Yao wrote: > The 9p-virtio transport does zero copy on things larger than 1024 bytes > in size. It accomplishes this by returning the physical addresses of > pages to the virtio-pci device. At present, the translation is usually a > bit shift. > > However, that approach produces an invalid page address when we > read/write to

On Wed, 18 Apr 2018, Mikulas Patocka wrote: > > > On Wed, 18 Apr 2018, David Miller wrote: > > > From: Mikulas Patocka <mpatocka at redhat.com> > > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT) > > > > > The structure net_device is followed by arbitrary driver-specific data > > > (accessible with the function netdev_priv). And for

On 04/19/2018 09:12 AM, Mikulas Patocka wrote: > > > These bugs are hard to reproduce because vmalloc falls back to kmalloc > only if memory is fragmented. > This sentence is wrong. .... because kvmalloc() falls back to vmalloc() ...

On Thu, 19 Apr 2018, Andrew Morton wrote: > On Thu, 19 Apr 2018 12:12:38 -0400 (EDT) Mikulas Patocka <mpatocka at redhat.com> wrote: > > > The kvmalloc function tries to use kmalloc and falls back to vmalloc if > > kmalloc fails. > > > > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then > > uses DMA-API on the returned memory or

On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote: > > In order to detect these bugs reliably I submit this patch that changes > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on. > > No way. This is just wrong! First of all, you will explode most likely > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be > enabled quite