On Mon, Aug 22, 2016 at 5:42 PM, Michal Hocko wrote:
> On Sat 20-08-16 00:09:53, Muni Sekhar wrote:
>> Hi All,
>>
>> I would like to know what is the maximum size limit for kmalloc() API
>> to return a valid memory?
>
> KMALLOC_MAX_CACHE_SIZE
Thanks Michal.
>
>> Does the size limit varies based o
On Sat 20-08-16 00:09:53, Muni Sekhar wrote:
> Hi All,
>
> I would like to know what is the maximum size limit for kmalloc() API
> to return a valid memory?
KMALLOC_MAX_CACHE_SIZE
> Does the size limit varies based on the flags argument?
no but different flags can greatly influence how succesfu
On Sat, 2015-06-06 at 19:10 -0400, Toan Pham wrote:
> I am experiencing a similar issue on another system (at91sam9n12) that
> uses Redpine Signal Wireless Driver 1.1.0. I do not know the root
> cause yet, but it may be related to the Redpine Signals driver. Will
> update this mailing list if th
I am experiencing a similar issue on another system (at91sam9n12) that
uses Redpine Signal Wireless Driver 1.1.0. I do not know the root
cause yet, but it may be related to the Redpine Signals driver. Will
update this mailing list if the problem is with the redpine driver.
thanks
On Thu, May 28
On Wed, 2015-05-27 at 22:15 -0700, Cong Wang wrote:
> > rsi_client: module license 'Proprietary' taints kernel.
> > Disabling lock debugging due to kernel taint
> > RSI_Init called and registering the client driver
If this is what I think it is - the redpine signals wifi driver, then I
have no in
On Thu, May 28, 2015 at 9:21 AM, pavani
wrote:
> Hi Cong ,
>
> Thanks for the response.
>
> Where we need to fix the bug ?I mean in the driver or kernel source code or
> hardware level.
The more interesting question is, is this a recent and pristine kernel
from kernel.org?
--
Thanks,
//richard
Hi Cong ,
Thanks for the response.
Where we need to fix the bug ?I mean in the driver or kernel source code
or hardware level.
Is there any possible cases in the driver to fix this issue.
please reply me as soon as possible.
Thanks
pavani
On 05/28/2015 10:45 AM, Cong Wang wrote:
(Cc'in
(Cc'ing netdev and wireless... Looks like a bug in wireless ext.)
On Wed, May 27, 2015 at 6:46 AM, pavani
wrote:
> Hi,
>
> I connected to AP with the help of wpa_supplicant in linux.After connecting
> to AP I am facing an issue like "kmalloc panic".can you help me
> how to solve this issue.Logs
On Wed, May 15, 2013 at 07:15:42AM -0700, Eric Dumazet wrote:
> On Wed, 2013-05-15 at 03:23 -0500, Robin Holt wrote:
> > Roland,
> >
> > We are seeing the following when booting on a large system.
> >
> > [ 171.399023] mlx4_core 0004:01:00.0: irq 2410 for MSI/MSI-X
> > [ 171.406560] ---
On Wed, 2013-05-15 at 03:23 -0500, Robin Holt wrote:
> Roland,
>
> We are seeing the following when booting on a large system.
>
> [ 171.399023] mlx4_core 0004:01:00.0: irq 2410 for MSI/MSI-X
> [ 171.406560] [ cut here ]
> [ 171.411734] WARNING: at mm/slab_common.c:376
On Fri, 20 Jul 2007, Pekka J Enberg wrote:
> There's some heavy-duty function inlining going on in__kmalloc so could
> you please work out the exact location of the oops as described in
> Documentation/BUG-HUNTING (look for the "use GDB to translate" part).
And, of course, please check if a5c96d
Hi Roland,
On Thu, 19 Jul 2007, Roland Dreier wrote:
> [ 1350.668590] Unable to handle kernel NULL pointer dereference at
> 0028 RIP:
> [ 1350.674068] [] __kmalloc+0x51/0xaf
There's some heavy-duty function inlining going on in__kmalloc so could
you please work out the exact locati
On Thursday 19 July 2007 21:19:29 Linus Torvalds wrote:
>
> On Thu, 19 Jul 2007, Linus Torvalds wrote:
> >
> > Does something like this fix it?
> >
> > Christoph, please go over this and see if there are other cases like that.
>
> Actually, here's a better version, I think.
>
> Andi, does this
On Thu, 19 Jul 2007, Linus Torvalds wrote:
>
> Does something like this fix it?
>
> Christoph, please go over this and see if there are other cases like that.
Actually, here's a better version, I think.
Andi, does this patch fix your problem?
Linus
---
mm/slab.c |4 ++--
Linus Torvalds wrote:
Ok, I think I see it: I think the mm/slab.c conversion of kmalloc(0) is
totally broken.
The problem? It returns ZERO_SIZE_PTR from __find_general_cachep(), not
from __kmalloc(). So anythign that uses __find_general_cachep() will get
an invalid cachep pointer, which was no
On Thu, 19 Jul 2007, Roland Dreier wrote:
>
> I think the oops below is related -- Michael reports that avoiding
> kmalloc(0) in the mlx4_ib driver makes it go away.
Ok, I think I see it: I think the mm/slab.c conversion of kmalloc(0) is
totally broken.
The problem? It returns ZERO_SIZE_PTR fro
On Thursday 19 July 2007 16:08:34 Pekka Enberg wrote:
> Hi Andi,
>
> On 7/19/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > qemu testing and booting test machines with i386 kernels wasn't very
> > successfull
> > with recent git kernels. I got either BUGs because of failing sysfs
> > initializati
On Thu, 19 Jul 2007, Andi Kleen wrote:
>
> qemu testing and booting test machines with i386 kernels wasn't very
> successfull
> with recent git kernels. I got either BUGs because of failing sysfs
> initialization
> or oopses in kmalloc, but no user land.
Can you send in the oopses and BUGs? T
I think the oops below is related -- Michael reports that avoiding
kmalloc(0) in the mlx4_ib driver makes it go away.
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Subject: oops on mlx4 modprobe
To: [EMAIL PROTECTED], Roland Dreier <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 11:47:51 +0300
Reply-T
Hi Andi,
On 7/19/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
qemu testing and booting test machines with i386 kernels wasn't very successfull
with recent git kernels. I got either BUGs because of failing sysfs
initialization
or oopses in kmalloc, but no user land.
I bisected it down to this comm
Stephane Eranian wrote:
Hi,
On Sun, Mar 25, 2007 at 06:30:34PM +0200, Folkert van Heusden wrote:
I'd say "feature", glibc's malloc also returns an address on
malloc(0).
This is implementation defined-the standard allows for return of either
null or an address.
Entirely for entertainment: AIX
Hi,
On Sun, Mar 25, 2007 at 06:30:34PM +0200, Folkert van Heusden wrote:
> > > I'd say "feature", glibc's malloc also returns an address on
> > > malloc(0).
> > >
> > This is implementation defined-the standard allows for return of either
> > null or an address.
>
> Entirely for entertainment: A
> > I'd say "feature", glibc's malloc also returns an address on
> > malloc(0).
> >
> This is implementation defined-the standard allows for return of either
> null or an address.
Entirely for entertainment: AIX (5.3) returns NULL, IRIX returns a valid
address.
Folkert van Heusden
--
MultiTai
On Thu, 22 Mar 2007, Stephane Eranian wrote:
> I ran into an issue with perfmon where I ended up calling
> kmalloc() with a size of zero. To my surprise, this did
> not return NULL but a valid data address.
>
> I am wondering if this is a property of kmalloc() or simply
> a bug. It is the case th
On Fri, 2007-03-23 at 07:08 +0530, Jan Engelhardt wrote:
>
> On Mar 22 2007 16:18, Stephane Eranian wrote:
> >
> I'd say "feature", glibc's malloc also returns an address on
> malloc(0).
>
This is implementation defined-the standard allows for return of either
null or an address.
>
> Jan
> --
>
On Mar 22 2007 16:18, Stephane Eranian wrote:
>
>Hello,
>
>I ran into an issue with perfmon where I ended up calling
>kmalloc() with a size of zero. To my surprise, this did
>not return NULL but a valid data address.
>
>I am wondering if this is a property of kmalloc() or simply
>a bug. It is the
Hey thanks,
The memory i need is not for DMA usage so i don't care
if it is contiguous or not.
later,
Petko
Arnaldo Carvalho de Melo wrote:
>
> Em Fri, Jun 15, 2001 at 10:02:08AM -0700, Petko Manolov escreveu:
> > Hi there,
> >
> > AFAIK there was similar discusion almos a year
Em Fri, Jun 15, 2001 at 10:02:08AM -0700, Petko Manolov escreveu:
> Hi there,
>
> AFAIK there was similar discusion almos a year
> ago but i can't remember the details.
>
> kmalloc fails to allocate more than 128KB of
> memory regardless of the flags (GFP_KERNEL/USER/ATOMIC)
>
> Any ideas
Petko Manolov writes:
> kmalloc fails to allocate more than 128KB of
> memory regardless of the flags (GFP_KERNEL/USER/ATOMIC)
>
> Any ideas?
Yes, this is the limit.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
> > There are people who assume 16byte alignment guarantees. I dont think anyone
> > has formally specified the guarantee beyond 4 bytes tho
>
> Userspace malloc is "suitably aligned for any kind of variable", so I think
> expecting 8 bytes alignment (long long on 32-bit platforms) should be okay
Le 06 Mar 2001 09:31:01 +0100, Rogier Wolff a écrit :
>
> > Followup to: <[EMAIL PROTECTED]>
> > By author:Kenn Humborg <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote:
> > > > >
> > > > > Does kmalloc() make a
On Sun, Mar 04, 2001 at 10:34:31PM +, Alan Cox wrote:
> > Does kmalloc() make any guarantees of the alignment of allocated
> > blocks? Will the returned block always be 4-, 8- or 16-byte
> > aligned, for example?
>
> There are people who assume 16byte alignment guarantees. I dont think anyon
> Followup to: <[EMAIL PROTECTED]>
> By author:Kenn Humborg <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote:
> > > >
> > > > Does kmalloc() make any guarantees of the alignment of allocated
> > > > blocks? Will the
Alan Cox wrote:
>
> > > It might be worth asking the question if larger blocks are more
> > > aligned?
> >
> > OK, I'll bite...
> > Are larger blocks more aligned?
>
> Only get_free_page()
>
I wonder if it would be practical/reasonable to guarantee better
alignment for larger allocations (at l
> > It might be worth asking the question if larger blocks are more
> > aligned?
>
> OK, I'll bite...
> Are larger blocks more aligned?
Only get_free_page()
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
On Mon, Mar 05, 2001 at 04:15:36PM -0800, H. Peter Anvin wrote:
> > So, to summarise (for 32-bit CPUs):
> >
> > o Alan Cox & Manfred Spraul say 4-byte alignment is guaranteed.
> >
> > o If you need larger alignment, you need to alloc a larger space,
> >round as necessary, and keep the orig
Followup to: <[EMAIL PROTECTED]>
By author:Kenn Humborg <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote:
> > >
> > > Does kmalloc() make any guarantees of the alignment of allocated
> > > blocks? Will the returned block al
On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote:
> >
> > Does kmalloc() make any guarantees of the alignment of allocated
> > blocks? Will the returned block always be 4-, 8- or 16-byte
> > aligned, for example?
> >
>
> 4-byte alignment is guaranteed on 32-bit cpus, 8-byte align
Alan Cox wrote:
> > As far as I know, you can count on 16-bytes alignment from
> > kmalloc. The trouble is that you would have to keep the original
>
> Actually it depends on the debug settings
Actually THAT's a bug in the debug stuff
Roger.
--
** [EMAIL PROTECTED] ** ht
> As far as I know, you can count on 16-bytes alignment from
> kmalloc. The trouble is that you would have to keep the original
Actually it depends on the debug settings
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Alan Cox wrote:
> > Does kmalloc() make any guarantees of the alignment of allocated
> > blocks? Will the returned block always be 4-, 8- or 16-byte
> > aligned, for example?
> There are people who assume 16byte alignment guarantees. I dont
> think anyone has formally specified the guarantee be
>
> Does kmalloc() make any guarantees of the alignment of allocated
> blocks? Will the returned block always be 4-, 8- or 16-byte
> aligned, for example?
>
4-byte alignment is guaranteed on 32-bit cpus, 8-byte alignment on
64-bit cpus.
--
Manfred
-
To unsubscribe from this list: send
> Does kmalloc() make any guarantees of the alignment of allocated
> blocks? Will the returned block always be 4-, 8- or 16-byte
> aligned, for example?
There are people who assume 16byte alignment guarantees. I dont think anyone
has formally specified the guarantee beyond 4 bytes tho
-
To unsub
On Wed, 17 Jan 2001, Rick Richardson wrote:
> Problem: kmalloc() of 4M causes kernel message "kernel BUG at slab.c:1542"
This BUG() has been been removed in the later -ac patches as it was meant
to be a temporary debugging help during the -test3 slab.c changes. This
does not however remove the c
** Reply to message from Brian Pomerantz <[EMAIL PROTECTED]> on Wed, 17
Jan 2001 12:17:19 -0800
> The most you can kmalloc() is 128KB unless this has changed in the 2.4
> kernel which I doubt. If you want a region of memory that large, use
> vmalloc(). Of course, this doesn't guarantee a conti
On Wed, Jan 17, 2001 at 01:54:20PM -0600, Rick Richardson wrote:
>
> [please cc me on any responses]
>
> Environment: 2.4.0 released, Pentium III with 256MB's of RAM.
> Problem: kmalloc() of 4M causes kernel message "kernel BUG at slab.c:1542"
>
The most you can kmalloc() is 128KB unless this
On Tue, Oct 31, 2000 at 02:11:24PM -0200, Rik van Riel wrote:
[PCAC]
> It's a nice idea, but you still want to be sure you won't
> allocate eg. page tables randomly in the middle of the
> PCACs ;)
Yes. That's why we check later, whether our hint is still true.
If we cannot free or move all pages
On Tue, 31 Oct 2000, Ingo Oeser wrote:
> On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote:
> > > Rik: What do you think about this (physical cont. area cache) for 2.5?
>^ == PCAC
> >
> > http://www.surriel.com/zone-alloc.
On Tue, 31 Oct 2000, Alan Cox wrote:
> > The code for vmalloc allocates the pages at vmalloc time, not after. The
> > TLB is populated lazily, but most definately not the page tables.
>
> Is the lazy tlb population interrupt safe or do I need to change any driver
> using vmalloced memory from a
On Tue, 31 Oct 2000 around 08:59:53 -0500, Richard B. Johnson wrote:
[snip]
> Since Linux is starting to be used in many 'strange' non-desktop
> environments, maybe it's time to provide a hook to reserve the
> top N kilobytes of RAM for strange buffers. Like:
>
> append="..,reserve=2M".
>
On Tue, Oct 31, 2000 at 11:35:46AM -0200, Rik van Riel wrote:
> > Rik: What do you think about this (physical cont. area cache) for 2.5?
^ == PCAC
>
> http://www.surriel.com/zone-alloc.html
Read it when you published it first, but di
> The code for vmalloc allocates the pages at vmalloc time, not after. The
> TLB is populated lazily, but most definately not the page tables.
Is the lazy tlb population interrupt safe or do I need to change any driver
using vmalloced memory from an IRQ ?
-
To unsubscribe from this list: send t
On Tue, 31 Oct 2000, Brian Gerst wrote:
> Andi Kleen wrote:
> >
> > On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote:
> > > This was just changed in 2.4 so that vmalloced pages are faulted in on
> > > demand.
> >
> > Could you explain how it handles the vmalloc() -- vfree() -- vmallo
On Tue, 31 Oct 2000, Ingo Oeser wrote:
> On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
> > > There are 256 megabytes of SDRAM available. I don't think it's
> > > reasonable that a 1/2 megabyte allocation would fail, especially
> > > since it's the first module being installed.
>
On Tue, 31 Oct 2000, Rik van Riel wrote:
> On Tue, 31 Oct 2000, Ingo Oeser wrote:
> > On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
>
> > > If you write the defragmentation code for the VM, I'll
> > > be happy to bump up the limit a bit ...
> >
> > Should become easier once we s
On Tue, 31 Oct 2000, Ingo Oeser wrote:
> On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
> > If you write the defragmentation code for the VM, I'll
> > be happy to bump up the limit a bit ...
>
> Should become easier once we start doing physical page scannings.
>
> We could record
Andi Kleen wrote:
>
> On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote:
> > This was just changed in 2.4 so that vmalloced pages are faulted in on
> > demand.
>
> Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same
> virtual space but different physical race
On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
> > There are 256 megabytes of SDRAM available. I don't think it's
> > reasonable that a 1/2 megabyte allocation would fail, especially
> > since it's the first module being installed.
> If you write the defragmentation code for the VM,
On Tue, Oct 31, 2000 at 09:07:29AM +, Tigran Aivazian wrote:
> On Tue, 31 Oct 2000, Andi Kleen wrote:
>
> > On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote:
> > >
> > > what do you mean?! That is, of course, impossible because it would break
> > > all existing software, so I
On Tue, 31 Oct 2000, Andi Kleen wrote:
> On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote:
> >
> > what do you mean?! That is, of course, impossible because it would break
> > all existing software, so I won't even bother checking the code, safely
> > assuming that you perhaps me
On Tue, Oct 31, 2000 at 08:49:02AM +, Tigran Aivazian wrote:
>
> what do you mean?! That is, of course, impossible because it would break
> all existing software, so I won't even bother checking the code, safely
> assuming that you perhaps meant something else, ok?
He refers to faulting int
On Tue, 31 Oct 2000, Brian Gerst wrote:
> "H. Peter Anvin" wrote:
> >
> > Followup to: <[EMAIL PROTECTED]>
> > By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will
> >
On Tue, Oct 31, 2000 at 01:11:29AM -0500, Brian Gerst wrote:
> This was just changed in 2.4 so that vmalloced pages are faulted in on
> demand.
Could you explain how it handles the vmalloc() -- vfree() -- vmalloc() of same
virtual space but different physical race ?
-Andi
-
To unsubscribe from
"Richard B. Johnson" wrote:
>
> Hello,
> How much memory would it be reasonable for kmalloc() to be able
> to allocate to a module?
>
> Oct 30 10:48:31 chaos kernel: kmalloc: Size (524288) too large
>
> Using Version 2.2.17, I can't allocate more than 64k! I need
> to allocate at least 1/2 m
On Mon, 30 Oct 2000, Rik van Riel wrote:
> On Mon, 30 Oct 2000, Richard B. Johnson wrote:
>
> > How much memory would it be reasonable for kmalloc() to be able
> > to allocate to a module?
>
> > There are 256 megabytes of SDRAM available. I don't think it's
> > reasonable that a 1/2 megabyte al
"H. Peter Anvin" wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will
> > > happily grab you 2Mb of space but it will not be phys
Followup to: <[EMAIL PROTECTED]>
By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will
> > happily grab you 2Mb of space but it will not be physically linear
> >
>
> Okay. Thanks.
On Mon, 30 Oct 2000, Alan Cox wrote:
> > How much memory would it be reasonable for kmalloc() to be able
> > to allocate to a module?
>
> 64K probably less. kmalloc allocates physically linear spaces. vmalloc will
> happily grab you 2Mb of space but it will not be physically linear
>
Okay. Tha
> How much memory would it be reasonable for kmalloc() to be able
> to allocate to a module?
64K probably less. kmalloc allocates physically linear spaces. vmalloc will
happily grab you 2Mb of space but it will not be physically linear
-
To unsubscribe from this list: send the line "unsubscribe
"Richard B. Johnson" wrote:
>
> On Mon, 30 Oct 2000, Jeff Garzik wrote:
>
> > "Richard B. Johnson" wrote:
> > > Now, I could set up a linked-list of buffers and use vmalloc()
> > > if the buffers were allocated from non-paged RAM. I don't think
> > > they are. These buffers must be present durin
On Mon, 30 Oct 2000, Jeff Garzik wrote:
> Tigran Aivazian wrote:
> >
> > On Mon, 30 Oct 2000, Jeff Garzik wrote:
> >
> > > "Richard B. Johnson" wrote:
> > > > Now, I could set up a linked-list of buffers and use vmalloc()
> > > > if the buffers were allocated from non-paged RAM. I don't think
>
On Mon, 30 Oct 2000, Jeff Garzik wrote:
> "Richard B. Johnson" wrote:
> > Now, I could set up a linked-list of buffers and use vmalloc()
> > if the buffers were allocated from non-paged RAM. I don't think
> > they are. These buffers must be present during an interrupt.
>
> Non-paged RAM? I'm no
On Mon, 30 Oct 2000, Tigran Aivazian wrote:
> On Mon, 30 Oct 2000, Richard B. Johnson wrote:
> > > So, if you don't need physically contiguous (and fast) allocations perhaps
> > > you could make use of vmalloc()/vfree() instead? There must be also some
> > > "exotic" allocation APIs like bootmem
Tigran Aivazian wrote:
>
> On Mon, 30 Oct 2000, Jeff Garzik wrote:
>
> > "Richard B. Johnson" wrote:
> > > Now, I could set up a linked-list of buffers and use vmalloc()
> > > if the buffers were allocated from non-paged RAM. I don't think
> > > they are. These buffers must be present during an
On Mon, 30 Oct 2000, Jeff Garzik wrote:
> "Richard B. Johnson" wrote:
> > Now, I could set up a linked-list of buffers and use vmalloc()
> > if the buffers were allocated from non-paged RAM. I don't think
> > they are. These buffers must be present during an interrupt.
>
> Non-paged RAM? I'm no
"Richard B. Johnson" wrote:
> Now, I could set up a linked-list of buffers and use vmalloc()
> if the buffers were allocated from non-paged RAM. I don't think
> they are. These buffers must be present during an interrupt.
Non-paged RAM? I'm not sure what you mean by that.
Both kmalloc and vmall
On Mon, 30 Oct 2000, John Levon wrote:
> On Mon, 30 Oct 2000, Richard B. Johnson wrote:
>
> >
> > Hello,
> > How much memory would it be reasonable for kmalloc() to be able
> > to allocate to a module?
> >
> > Oct 30 10:48:31 chaos kernel: kmalloc: Size (524288) too large
> >
> > Using Versi
On Mon, 30 Oct 2000, Richard B. Johnson wrote:
> How much memory would it be reasonable for kmalloc() to be able
> to allocate to a module?
> There are 256 megabytes of SDRAM available. I don't think it's
> reasonable that a 1/2 megabyte allocation would fail, especially
> since it's the first m
On Mon, 30 Oct 2000, Tigran Aivazian wrote:
> Hi Dick,
>
> Sorry, I thought you knew this already :) The maximum for kmalloc is 128K
> and is defined in mm/slab.c. It is trivial to "enhance" slab.c to support
> more but it is in practice not very useful because requesting too much
> physically-c
On Mon, 30 Oct 2000, Richard B. Johnson wrote:
> > So, if you don't need physically contiguous (and fast) allocations perhaps
> > you could make use of vmalloc()/vfree() instead? There must be also some
> > "exotic" allocation APIs like bootmem but I know nothing of them so I stop
> > here.
>
> O
On Mon, 30 Oct 2000, Richard B. Johnson wrote:
>
> Hello,
> How much memory would it be reasonable for kmalloc() to be able
> to allocate to a module?
>
> Oct 30 10:48:31 chaos kernel: kmalloc: Size (524288) too large
>
> Using Version 2.2.17, I can't allocate more than 64k! I need
> to allo
Hi Dick,
Sorry, I thought you knew this already :) The maximum for kmalloc is 128K
and is defined in mm/slab.c. It is trivial to "enhance" slab.c to support
more but it is in practice not very useful because requesting too much
physically-contiguous (which kmalloc is all about) memory is impossib
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 3 Oct 2000, Justin Schoeman wrote:
> Hi everybody,
>
> A bit of a newbie question. A while ago I was looking through the
> available web resources for information on the various malloc()'s for
> drivers.
>
> The one I did find (I just can't remember what it was called) stated
> that
84 matches
Mail list logo
