there
reflects some earlier role that the slab flag once may have had. If
its specified then SLAB_HWCACHE_ALIGN is also specified.
The flag is confusing, inconsistent and has no purpose.
Remove it.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux
Hi,
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Makes sense.
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED]
.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Cannot we use a flag in 'struct files_struct', set to one when the task is
mono-thread (at task creation in fact), and set to 0 when it creates a new
thread (or when someone remotely access to this struct files_struct
in /proc/pid/fd/... )
How
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
That's what I did first but akpm
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
On 3/9/07, Pekka Enberg [EMAIL
On 3/9/07, Pekka J Enberg [EMAIL PROTECTED] wrote:
To fix this, change sys_revoke() not to close the actual revoked file
immediately. Instead, we do filp_close() when the user does close(2)
on the revoked file descriptor.
Btw, this is safe because a filesystem implementing f_ops-revoke must
Hi Martin,
Martin Schwidefsky wrote:
Yes, please put me or Heiko on CC if you add system calls to s390.
Ok, sorry about that. I would expect akpm to send it to you guys though
whenever revoke graduates from -mm and not merge it to mainline.
Pekka
-
To
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote:
Then just drop the fget_light() 'optimisation' and always take a reference
(atomic on f_count) regardless of single-thread or not. Instead of dirtying
f_light, just do the straightforward thing and be with it.
(that is :
On Fri, 2007-03-09 at 10:15 +0200, Pekka J Enberg wrote:
+ again:
+ restart_addr = zap_page_range(vma, start_addr, end_addr - start_addr,
+ details);
+
+ need_break = need_resched() || need_lockbreak(details-i_mmap_lock);
+ if (need_break)
+
Hi,
On 3/12/07, Valerie Henson [EMAIL PROTECTED] wrote:
--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
@@ -17,11 +17,11 @@
#define DRV_NAME tulip
#ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION1.1.14-NAPI /* Keep at
On 3/12/07, Jarek Poplawski [EMAIL PROTECTED] wrote:
So, maybe it's less evil to check those NULLs where possible and add
some WARN_ONs here and there...
No, it's much better to oops rather than paper over a bug.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hi Marco,
On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote:
Hello everybody. Sorry for posting to this list, but I'm pretty lost.
Don't worry, this is the proper mailing list for bug reports.
On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote:
I don't think this is related to buggy hardware
Hi Chris,
On 3/10/07, Chris Rankin [EMAIL PROTECTED] wrote:
It looks like 2.6.20.2 is still doing Bad Things in /sys.
I have seen other reports of this too so can you please open a bug at
bugzilla.kernel.org so this is not lost in the noise?
-
To unsubscribe from this list: send the line
Hi Greg,
I think there's some sort of reference counting problem with sysfs in
2.6.20 kernels. Can you please help us debug it further?
On 3/10/07, Chris Rankin [EMAIL PROTECTED] wrote:
It looks like 2.6.20.2 is still doing Bad Things in /sys.
BUG: unable to handle kernel paging request at
On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote:
Only to tell you, that on the console linux was printing
this message:
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
access hardware directly.
Probably unrelated. CONFIG_SLAB_DEBUG should tell us what's corrupting the
Hi Andrew,
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg
[EMAIL PROTECTED] wrote:
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
n all system calls must return long.
Fixed.
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
so the modification of vm_flags is
On 3/16/07, Greg KH [EMAIL PROTECTED] wrote:
Is there any way you can use 'git bisect' to try to track down the root
cause of this?
Chris, If 2.6.19 works for you, could you please do a git bisect for
this bug? See the following URL for details:
On 3/16/07, Nick Piggin [EMAIL PROTECTED] wrote:
Also, a down_write_trylock attempt inside i_mmap_lock should be a valid
optimisation.
I am not sure what you're thinking here. down_write_trylock acquires
-mmap_sem which can deadlock with -i_mmap_lock, no?
-
To unsubscribe from this list: send
Hi Chris,
On 3/16/07, Chris Rankin [EMAIL PROTECTED] wrote:
That would take ages - the only reason I kept on plugging away with winecfg
last night
was because I was fairly certain the kernel was going to oops eventually
(which it did).
But when exactly would I be able to declare a kernel good
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote:
Serious question - do we actually need revoke() on a normal file ? BSD
has never had this, SYS5 has never had this.
It's needed for forced unmount (bits of it anyway) and
partial-revocation in SLIM.
-
To unsubscribe from this list: send the line
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote:
I'm not sure that running do_fsync() will guarantee that all sys_write()
callers will have finished their syscall. Probably they will have, in
practice. But there is logic in the sync paths to deliberately bale out
if we're competing with
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote:
Serious question - do we actually need revoke() on a normal file ? BSD
has never had this, SYS5 has never had this.
On 3/16/07, Pekka Enberg [EMAIL PROTECTED] wrote:
It's needed for forced unmount (bits of it anyway) and
partial-revocation
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote:
However, modifying i_size like this might be a problem - the inode could be
dirty and it'll get written to disk! Perhaps we could change i_size_read()
to cheat and to return zero if there's a revoke in progress.
I don't think we can actually
On 2/11/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Unfortunately it has to be done in one shot for all of the known good drivers
to avoid
user-observable regressions.
No you don't. You can make it a config option that defaults to n
during a transition period.
-
To unsubscribe from this
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote:
May I suggest another definition for a warning being entirely sucks?
The warning is entirely sucks if and only if it never has true
positives. In all other cases it's only more or less sucks, IMHO.
You're totally missing the point. False
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote:
With almost any warning out there one makes more or less efforts to
suppress the warning where it gives false positives, isn't it?
Yes, as long it's the _compiler_ that's doing the effort. You
shouldn't need to annotate the source just to
On 2/16/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Remove the ctor for the pgd cache. There's no point in having the
cache machinery do this via an indirect call when all pgd are freed in
the one place anyway.
The reason we have slab constructors and destructors is to _avoid_
On 2/17/07, Artem Bityutskiy [EMAIL PROTECTED] wrote:
+void *ubi_kzalloc(size_t size)
+{
+ void *ret;
+
+ ret = kzalloc(size, GFP_KERNEL);
+ if (unlikely(!ret)) {
+ ubi_err(cannot allocate %zd bytes, size);
+ dump_stack();
+ return
On 3/17/07, Mike Snitzer [EMAIL PROTECTED] wrote:
Thanks for the heads up; its good to see that Pekka Enberg's work has
continued. I actually stumbled onto that line of work earlier while
searching for more info on Tigran Aivazian's forced unmount (badfs)
patches:
On 3/17/07, Thomas Meyer [EMAIL PROTECTED] wrote:
Hello everybody.
I get this bug after suspending to disk twice:
http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
This happens with current git head cd05a1f818073a623455a58e756c5b419fc98db9.
If you know a kernel that works, please
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote:
BUG_ON(!PageSlab(page));
that's seriously screwed up. Do you have CONFIG_DEBUG_SLAB enabled? If
not, please enable it and retest.
This is scary. Looking at disassembly of the OOPS:
Disassembly of section .text:
.text:
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote:
EIP is at kmem_cache_free+0x29/0x5a
eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180
esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14
ds: 007b es: 007b ss: 0068
But somehow eax and edx have the same value 0xc180
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote:
You can see that mempool_free is passing a NULL pointer to
kmem_cache_free() which doesn't handle it properly. The NULL pointer
comes from bio_free() where -bi_io_vec is NULL because nr_iovecs
passed to bio_alloc_bioset() was zero.
The question
On 3/19/2007, Andrew Morton [EMAIL PROTECTED] wrote:
Would prefer to do:
static inline void kmem_cache_free_if_not_null(struct kmem_cache *cachep,
void *objp)
{
if (objp)
kmem_cache_free(cachep, objp);
}
so that we
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote:
The BUG_ON (at least) should probably be moved into CONFIG_DEBUG_SLAB.
No it shouldn't. Letting non-slab pages pass through causes nasty and
hard to debug problems which is why we have the BUG_ONs in the first
place:
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote:
This is a super-hot path.
Super-hot exactly where?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On 3/21/07, Jarek Poplawski [EMAIL PROTECTED] wrote:
I think Pekka was right (it looks he changed his mind now) something
should be done here. I think something like this should be a minimum:
BUG_ON(!objp || virt_to_cache(objp) != cachep);
to show distinctly what's going on.
No, if we were
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
In order to avoid a cache miss in kmem_cache_free() on NUMA and reduce hot path
length, we could exploit the following common facts.
It would be nice if you could cc me for slab patches.
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
+#ifdef KEEP_NODEID_IN_PAGE
+ /* kmem_cache addresses must be multiple of 64 */
+ cache_cache.buffer_size = ALIGN(cache_cache.buffer_size,
+ max(64, cache_line_size()));
+#else
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
As most shiped linux kernels are now compiled with CONFIG_SMP, there is no way
a preprocessor #if can detect if the machine is UP or SMP. Better to use
num_possible_cpus().
Looks good to me.
Acked-by: Pekka Enberg [EMAIL PROTECTED
is
safe.
Looks good to me.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 3/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
IMHO one way to find them is to actually slow down kmem_cache_free() and see
where the performance is hurt.
Yeah, I'll try to sneak a patch past Andrew.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On 3/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:
None of that please. The page flags already contain a node number that is
accessible via page_to_nid(). Just make sure that we never put a slab onto
the wrong node.
Sounds good. Do you know for a fact that we don't or are you just
afraid
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Last time I checked 'struct page', they was no nodeid in it.
Hmm, page_to_nid() in include/linx/mm.h doesn't agree with you:
#ifdef NODE_NOT_IN_PAGE_FLAGS
extern int page_to_nid(struct page *page);
#else
static inline int page_to_nid(struct
On 3/21/2007, Andi Kleen [EMAIL PROTECTED] wrote:
You can always use numa emulation on x86-64. Boot with
numa=fake=NODES
Yes, I know, but I don't have a x86-64 box either =)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On 3/21/2007, Andrew Morton [EMAIL PROTECTED] wrote:
Thing is, such a patch would amount to adding a test-for-NULL to codepaths
which we *know* do not need it. There is no point in doing that.
Now you're just being stubborn, Andrew ;-).
The extra check does not matter much at all for most
On 3/23/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Checking Christoph quicklist implementation, I found the same cache miss in
free() than SLAB has.
/* common implementation *
int virt_to_nid(const void *addr)
{
struct page *page = virt_to_page(addr);
return page_to_nid(page);
}
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks good. Thanks!
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On 3/25/07, Bin Chen [EMAIL PROTECTED] wrote:
It is done by increase gfporder for low number to high(possibly 0 to
MAX_GFP_ORDER). But why increase the gfporder(or slab size) can
decrease the internal fragmentation?)
A simple example, suppose the slab management stuff is kept off-slab,
if the
On 4/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I checked what bonnie++ actually writes to its test files, for you. It
is about 98-99% zeros.
Still, the results record sequential reads, of 232,729 K/sec, nearly
four times the physical disk read rate, 63,160 K/sec, of the hard drive.
On 4/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
YOU GUYS WILL LAUGH ABOUT THIS:
No, I am crying actually. Dear post-masters, can we have this thread
shit-canned, please?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Hi Rusty,
On 4/10/07, Rusty Russell [EMAIL PROTECTED] wrote:
+/* Jens gave me this nice helper to end all chunks of a request. */
+static void end_entire_request(struct request *req, int uptodate)
+{
+ if (end_that_request_first(req, uptodate, req-hard_nr_sectors))
+ BUG();
();
+ add_disk_randomness(req-rq_disk);
+ blkdev_dequeue_request(req);
+ end_that_request_last(req, uptodate);
+}
On 4/10/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Perhaps we should move this to generic code (i.e. block/ll_rw_blk.c)?
Uhm, I am bit confused now. Why don't you just
On 4/11/07, Rusty Russell [EMAIL PROTECTED] wrote:
What a question! end_request() doesn't end a request! What a crazy
idea!
Aah, indeed, end_request() uses req-hard_cur_sectors while
end_entire_request() uses req-hard_nr_sectors which I missed.
On 4/11/07, Rusty Russell [EMAIL PROTECTED]
On 4/11/07, Zhao Forrest [EMAIL PROTECTED] wrote:
We're using RHEL5 with kernel version 2.6.18-8.el5.
When doing a stress test on raw device for about 3-4 hours, we found
the soft lockup message in dmesg.
I know we're not reporting the bug on the latest kernel, but does any
expert know if this
On 4/15/07, hui Bill Huey [EMAIL PROTECTED] wrote:
The perception here is that there is that there is this expectation that
sections of the Linux kernel are intentionally churn squated to prevent
any other ideas from creeping in other than of the owner of that subsytem
Strangely enough, my
On 2/20/07, Adrian Bunk [EMAIL PROTECTED] wrote:
CC fs/unionfs/copyup.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In function
'create_parents_named':
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error:
'malloc_sizes' undeclared (first use
On 2/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can help us greatly
here ;)
So I guess we want the same thing for the other allocator functions
(__kmalloc et al) as
Christoph Lameter wrote:
Well could you check ksize for the old object first and if ksize = new
size then just skip the copy? I think this may allow you
to get rid of the ksize callers.
And not reallocate at all, right? I thought about that but then you
wouldn't be able to use realloc() to
On Wed, 21 Feb 2007, Pekka J Enberg wrote:
+ */
+ BUG_ON(slabp-inuse 0 || slabp-inuse = cachep-num);
+
while (slabp-inuse cachep-num batchcount--) {
On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:
I think you only need to check for 0. If
Hi Christoph,
Christoph Lameter wrote:
1. Just do not allow shrinking via realloc. Probably no big loss and best
performance.
Not a big loss if you can afford the wasted memory. But, I don't think
we should do this, there's no way for the caller to know that we will
hold on to the memory
On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:
Why not? Its a realloc call and these are the classic semantics of
realloc. Otherwise realloc will always move the memory.
Well, as a reference, the user-space equivalent is defined in SUSv3 as:
The realloc() function shall change the
Hi Andrew,
Andrew Morton wrote:
Problem is, it doesn't seem that we'll be merging unionfs any time soon so
we shouldn't be adding slab infrastructure on its behalf. And I'd prefer
not to have to carry slab changes in a filesystem tree.
I think we can merge krealloc without unionfs. I'll
Pekka Enberg wrote:
The ksize exports we can add later if unionfs is to be merged.
Actually, we probably don't need it after the krealloc optimizations. I
think we need a new unionfs patch too... :)
Pekka
-
To unsubscribe from this list: send the line
Hi Christoph,
On 2/22/07, Christoph Lameter [EMAIL PROTECTED] wrote:
This is a new slab allocator which was motivated by the complexity of the
existing code in mm/slab.c. It attempts to address a variety of concerns
with the existing implementation.
So do you want to add a new allocator or
On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
[AIM9 results go here]
Yes please. I would really like to know what we gain by making the
slab even more complex.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Hi Peter,
On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Provide a method to calculate the number of pages needed to store a given
number of slab objects (upper bound when considering possible partial and
free slabs).
So how does this work? You ask the slab allocator how many pages you
Hi Peter,
On Wed, 2007-02-21 at 17:47 +0200, Pekka Enberg wrote:
So how does this work? You ask the slab allocator how many pages you
need for a given number of objects and then those pages are available
to it via the page allocator? Can other users also dip into those
reserves?
On 2/22
On 2/22/07, Pekka Enberg [EMAIL PROTECTED] wrote:
So you are only interested in rough estimation of how much many pages
you need for a given amount of objects? Why not use ksize() for that
then?
Uhm, I obviously meant, why not expose obj_size() instead.
-
To unsubscribe from this list: send
Hi Alan,
On 2/26/07, Alan [EMAIL PROTECTED] wrote:
Whats the status on this, I was suprised to see something so important
just go dead ?
It's not dead. You can find the latest patches here:
http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/
and user-space tests here:
Hi,
On 2/26/07, Chris Rankin [EMAIL PROTECTED] wrote:
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
[snip]
EIP is at module_put+0x20/0x52
eax: 6b6b6ceb ebx: 6b6b6b6b ecx: 0001 edx: e5bf
esi: e9040b08 edi: 6b6b6b6b ebp: eae0bb3c esp: e5bf0f58
ds:
On 2/27/07, Chris Rankin [EMAIL PROTECTED] wrote:
Hmm, this bug looks interesting:
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/0514.html
Yes, my machine *is* a dual P4 with HT enabled...
Yeah, but the oops looks more like a reference counting problem with
sysfs dentries. No harm in
On 3/28/07, Nick Piggin [EMAIL PROTECTED] wrote:
+ ret = get_user_pages(tsk, tsk-mm, vma-vm_start,
+ vma-vm_end-vma-vm_start, 1, 1, NULL,
+ NULL);
get_user_pages length argument is in # of pages, rather than
On 3/30/07, Heiko Carstens [EMAIL PROTECTED] wrote:
in file mm/slab.c and routine kmem_cache_init() I found there
is no checking for allocated memory on line:
/* 4) Replace the bootstrap head arrays */
{
struct array_cache *ptr;
ptr =
Hi Peter,
On 3/31/07, Peter Samuelson [EMAIL PROTECTED] wrote:
...and here it hangs. This happened between 2.6.17-git21 and -git22.
.config is attached. I'd be happy to test patches and provide more
information.
You could try git bisect to find the exact commit that broke your kernel:
On 3/31/07, Rene Herman [EMAIL PROTECTED] wrote:
There's quite a bit of noise in dmesg though. Repeated 5 times:
===BUG: scheduling while atomic: mount/0x0001/1166
[c1170bff] __sched_text_start+0x57/0x574
[c1171964] schedule_timeout+0x70/0x8f
[c10199b2] process_timeout+0x0/0x5
On 4/1/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Looks like mcdx_xfer is sleeping while holding q-queue_lock. The
attached (untested) patch should fix it.
You also need to add a spin_lock_irq() before the call to
end_request() to Jens' patch.
-
To unsubscribe from this list: send the line
On 3/30/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
Dell people (Stuart and Charles) complained that on some USB keyboards,
if BIOS enables NumLock, it stays on even after Linux has started. Since
we always start with NumLock off, this confuses users. Quick double dab
at NumLock fixes it, but it's
Hi Rene,
On 4/2/07, Rene Herman [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:~# dd if=/dev/mcdx0 of=/dev/null bs=2048
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000221955 seconds, 0.0 kB/s
[EMAIL PROTECTED]:~#
This I know isn't:
[EMAIL PROTECTED]:~# readcd dev=/dev/mcdx0 f=/dev/null
On 4/4/07, Rene Herman [EMAIL PROTECTED] wrote:
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Can you get anything out with sysrq-t? The original oops would be
enough to conclude it's a double-free if it weren't
Hi Michael,
On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL PROTECTED] wrote:
Is it possible to create git repository in git.kernel.org for Microblaze
cpu?
You need to ask the kernel.org administrators for that:
http://www.kernel.org/faq/#account
On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL
Hi Michal,
On Jan 7, 2008 3:00 PM, Michal Simek [EMAIL PROTECTED] wrote:
You can have as many maintainers as you want but you probably don't
want to make it too many. There aren't any official responsibilities
as a maintainer, it really depends on how much time and effort you're
willing
Hi Bryan,
On Jan 8, 2008 10:28 AM, Bryan Wu [EMAIL PROTECTED] wrote:
1. Push patches to LKML when merge window open (2 weeks after a stable
kernel version release, for example 2 weeks after 2.6.24 released)
You shouldn't wait for the merge window to open to send patches for
review for the
Hi John,
On Dec 17, 2007 5:47 PM, John Reiser [EMAIL PROTECTED] wrote:
In mm/slab.c, the DEBUG variant of cache_alloc_debugcheck_after
might call cachep-ctor(objp, cachep, 0); but the non-DEBUG
variant does absolutely nothing. idr_pre_get is a routine
which notices the difference.
How
Hi,
On Dec 20, 2007 4:38 PM, David Newall [EMAIL PROTECTED] wrote:
and another one, this time tainted with the nvidia module:
5194.130985] Unable to handle kernel paging request at 0300
RIP:
Numbers like that don't suggest hardware faults. All those zeros: It's
far too
Hi,
Christoph Lameter [EMAIL PROTECTED] wrote:
In an extreme case (boot with slub_min_order=9 to get huge page sized
slabs) SLUB can win against SLAB:
N=10 Time: 0.338 Minimally faster
N=20 Time: 0.560 10% faster
N=50 Time: 1.353 15% faster
On Dec 21, 2007 2:09 PM,
thought it might be a bug but couldn't figure it out. The patch
looks good to me too, Christoph.
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
On Dec 22, 2007 1:17 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
And i hereby nominate Pekka as SLUB/SLAB co-maintainer and spokesperson
;-)
Heh, thanks
Hi Thomas,
On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer [EMAIL PROTECTED] wrote:
These:
+#define READ_SC(p, r)readb((p)-membase + RD_##r)
+#define WRITE_SC(p, r, v)writeb((v), (p)-membase + WR_##r)
and these:
+#define READ_SC_PORT(p, r) read_sc_port(p,
Hi,
On Dec 22, 2007 2:37 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Removing an interface that exposes lots of internal details when you
rewrite the subsystem and those internal details all change seems
like a good reason to me.
Yeah but then again removing an interface that has been around for
Hi Andi,
On Dec 22, 2007 2:54 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Yeah but then again removing an interface that has been around for
ever
Version 2.1 hasn't been around forever and at least slabtop does not
work over version number changes in my experience.
True but the default
Hi Ingo,
On Dec 22, 2007 3:14 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
Also please apply the cleanup patch below, it fixes 34 checkpatch errors
and warnings in mm/slub.c.
Those are already fixed in -mm:
'count_partial'
Looks good. Thanks!
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
it a second look ;-)
Sure, I'm fine with that. Can you Andrew please drop mine and use
Ingo's instead?
Acked-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
;
- page = get_object_page(object);
+ page = virt_to_head_page(object);
BUG_ON(!page);
+
+ if (unlikely(!PageSlab(page)))
+ return PAGE_SIZE compound_order(page);
+
s = page-slab;
BUG_ON(!s);
Looks good to me.
Reviewed-by: Pekka Enberg
Hi,
On Mon, Dec 03, 2007 at 12:59:00PM +0100, Ingo Molnar wrote:
audit thousands of callsites in 8 million lines of code first is a
nice euphemism for hiding from the blame forever. We had 10 years for it
On Dec 3, 2007 2:13 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Ok your approach is then
Hi,
On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote:
We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and
we can know it 2.6 era.
But are we going back to 2.4 era for out-of-tree kernel modules?
On Dec 3, 2007 3:57 PM, Adrian Bunk [EMAIL PROTECTED]
Hi Dave,
On Dec 4, 2007 3:31 AM, Dave Young [EMAIL PROTECTED] wrote:
Kobject_put should be called when kobject register functioin fails, so the
the kobj ref count touch zero and then the proper cleanup routines will be
called.
[snip]
diff -upr linux/drivers/block/pktcdvd.c
Hi,
Current git head doesn't compile. Looks like fall-out from the x86 merge?
[EMAIL PROTECTED]:~/src/linux/uml-2.6$ make ARCH=um
SYMLINK arch/um/include/kern_constants.h
SYMLINK arch/um/include/sysdep
make[1]: `arch/um/sys-i386/user-offsets.s' is up to date.
CHK
Hi,
On Fri, Nov 23, 2007 at 10:52:06AM +0200, Pekka Enberg wrote:
Current git head doesn't compile. Looks like fall-out from the x86 merge?
On Nov 23, 2007 12:13 PM, WANG Cong [EMAIL PROTECTED] wrote:
Hmm, I believe this patch[1] from Jeff can solve the problem. ;-)
[1] http://lkml.org/lkml
1 - 100 of 1778 matches
Mail list logo