Natalie Protasevich wrote:
On 9/23/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
bugzilla tries to send a mail to
Christoph Lameter wrote:
On Tue, 11 Sep 2007, Nick Piggin wrote:
But that's not my place to say, and I'm actually not arguing that high
order pagecache does not have uses (especially as a practical,
shorter-term solution which is unintrusive to filesystems).
So no, I don't think I'm really goi
Christoph Hellwig wrote:
On Sat, Aug 04, 2007 at 09:42:59PM +0200, J??rn Engel wrote:
On Sat, 4 August 2007 21:26:15 +0200, J??rn Engel wrote:
Given the choice between only "atime" and "noatime" I'd agree with you.
Heck, I use it myself. But "relatime" seems to combine the best of both
Christoph Hellwig wrote:
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote:
I'd like to see you there, so I hope we can find a date that most
people are happy with. I'll try to start working that out after we
have a rough idea of who's interested.
Do we have any data preferen
Yes, good work, thanks a lot for it! The new interface is much better and more
useful.
Greetings,
Rafael
PS
BTW, would that be possible to create the "Hibernation/Suspend" subcategory
of "Power Management" that I asked for some time ago, please? :-)
Oops. Sorry. Done.
M.
-
To unsubscr
Adrian Bunk wrote:
On Sat, Jun 02, 2007 at 01:42:06AM +0200, Rafael J. Wysocki wrote:
Hi,
Can anyone please tell me who's administering the kernel bugzilla now?
I've tried to write to [EMAIL PROTECTED] , but this address seems
to point to nowhere.
...
Martin Bligh (explicitely Cc'ed) should
Bas Westerbaan wrote:
Hello,
Quite a lot of userspace applications cache. Firefox caches pages;
mySQL caches queries; libc' free (like practically all other
userspace allocators) won't directly return the first byte of memory
freed, etc.
These applications are unaware of memory pressure. Whi
Sorry, have been out sick, and someone removed me from the cc list,
which didn't help. In response to various bits:
Firstly a general comment - we're about to upgrade versions, which
will ease a few of these issues. I should really finish the creation
of virtual category owners for *all* categori
The thing is, these reports MUST NOT go to "everybody". If they do, that
is actually *worse* than nothing, because people will just ignore them
entirely, since they aren't "directed".
The emails need to be directed to the appropriate parties, not go to
everybody. There is nobody who is interes
cc: apw ... seeing as he wrote sparsemem in the first place, please copy
him on this stuff ?
Andi Kleen wrote:
On Monday 02 April 2007 17:37, Christoph Lameter wrote:
On Sun, 1 Apr 2007, Andi Kleen wrote:
Hmm, this means there is at least 2MB worth of struct page on every node?
Or do you have
Christoph Lameter wrote:
On Fri, 2 Mar 2007, William Lee Irwin III wrote:
On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote:
Opterons seem to be particularly prone to lock starvation where a cacheline
gets captured in a single package for ever.
AIUI that phenomenon is universal to
.. and think about a realistic future.
EVERYBODY will do on-die memory controllers. Yes, Intel doesn't do it
today, but in the one- to two-year timeframe even Intel will.
What does that mean? It means that in bigger systems, you will no longer
even *have* 8 or 16 banks where turning off a few
32GB is pretty much the minimum size to reproduce some of these
problems. Some workloads may need larger systems to easily trigger
them.
We can find a 32GB system here pretty easily to test things on if
need be. Setting up large commercial databases is much harder.
That's my problem, too.
Th
Andi Kleen wrote:
I wasn't suggesting having NULL pointers for pgdats, if that's what you
mean.
That is what started the original thread at least. Can happen on some
ia64 platforms.
OK, that does seem kind of ugly.
Just nodes with no memory in them, the pgdat would still be there.
pgdat =
Christoph Lameter wrote:
On Tue, 13 Feb 2007, Andi Kleen wrote:
Adding NULL tests all over mm for this would seem like a clear case
of this to me.
Maybe there is an alternative. We are free to number the nodes right?
How about requiring the low node number to have memory and the high ones
d
Andi Kleen wrote:
Your description of the node is correct, it's an arbitrary container of
one or more resources. Not only is this definition flexible, it's also
very useful, for memory hotplug, odd types of NUMA boxes, etc.
I must disagree here. Special cases are always dangerous especially
if
KAMEZAWA Hiroyuki wrote:
In my last posintg, mempolicy-fix-for-memory-less-node patch, there was a
discussion 'what do you consider definition of "node" as...?
I found there is no consensus. But I want to go ahead.
Before posing patch again, I'd like to discuss more.
-Kame
In my understanding,
Christoph Hellwig wrote:
On Fri, Feb 02, 2007 at 10:20:12PM -0800, Christoph Lameter wrote:
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that reference
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
* Include the patch inline rather than as an attachment. Even a
text/plain attachment is very difficult to review and quote in
popular email programs.
Jeff
I'd love to, but unfortunately nobody seems to have come up with a wa
I finally re-ran memtest86 on the machine since it began to have too
many different kind of errors (GPF, invalid instruction...). It turned
out that one of the memory modules was bad. I guess my brand new
list_debug race condition debugger will be useful in the future, but not
now. :)
I'll reme
Andrew Morton wrote:
On Mon, 29 Jan 2007 17:31:20 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic().
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same ti
Arjan van de Ven wrote:
On Sun, 2007-01-28 at 17:04 +, Christoph Hellwig wrote:
On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we
Andrew Morton wrote:
On Sun, 28 Jan 2007 08:56:08 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a n
Mathieu Desnoyers wrote:
Hi,
Trying to build cross-compilers (or kernels) on a 2-way x86_64 (amd64) with
make -j3 triggers the following OOPS after about 30 minutes on
2.6.19.2. Due to the amount of time and the heavy load it takes before it
happens, I suspect a race condition. Memtest86 tests p
Christoph Hellwig wrote:
On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we may
still have a problem to me. I guess we could move the spi
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
Wha
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
Bui
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
d
Ingo Molnar wrote:
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Sun, Jan 28, 2007 at 12:51:18PM +0100, Peter Zijlstra wrote:
This patch-set breaks up the global file_list_lock which was found
to be a severe contention point under basically any filesystem
intensive workload.
Benchmarks,
Andrew Morton wrote:
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That might motivate them to fix it ;)
Actually, how
Jeff V. Merkey wrote:
Again, I agree with EVERY statement Linus made here. We operate exactly
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton driver")
and our prop
Dave Jones wrote:
On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustai
Linus Torvalds wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright. Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been set.
Greg KH wrote:
On Mon, Dec 04, 2006 at 12:12:06AM +0100, Bj?rn Steinbrink wrote:
On 2006.12.03 14:39:44 -0800, Martin J. Bligh wrote:
This PC has 1 ethernet interface, an e1000. Ubuntu Dapper.
On 2.6.14, my e1000 interface appears as eth0.
On 2.6.15 to 2.6.18, my e1000 interface appears as
This PC has 1 ethernet interface, an e1000. Ubuntu Dapper.
On 2.6.14, my e1000 interface appears as eth0.
On 2.6.15 to 2.6.18, my e1000 interface appears as eth1.
In both cases, there are no other ethX interfaces listed in
"ifconfig -a". There are no modules involved, just a static
kernel build.
The traces are a bit confusing, but I don't actually see anything wrong
there. The machine has used up all swap, has used up all memory and has
correctly gone and killed things. After that, there's free memory again.
Yeah, it's just a bit odd that it's always in the IO path. Makes me
suspect t
On 2.6.18-rc7 and later during LTP:
http://test.kernel.org/abat/48393/debug/console.log
oom-killer: gfp_mask=0x201d2, order=0
Call Trace:
[] out_of_memory+0x33/0x220
[] __alloc_pages+0x23a/0x2c3
[] __do_page_cache_readahead+0x99/0x212
[] sync_page+0x0/0x45
[] io_schedule+0x28/0x33
[] __wai
Christian Krafft wrote:
On Wed, 15 Nov 2006 16:57:56 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Thu, 16 Nov 2006, KAMEZAWA Hiroyuki wrote:
But there is no memory on the node. Does the zonelist contain the zones of
the node without memory or not? We simply fall back each alloc
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/
>
> (kernel.org propagation is slow. There's a temp copy at
> http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-mm2.bz2)
>
>
>
> - Added Andi's x86_64 tree, as separate patches
>
> - Added a driver for TI
>> >> CONFIG_NUMA was meant to (and did at one point) support both NUMA and flat
>> >> machines. This is essential in order for the distros to support it - same
>> >> will go for sparsemem.
>> >
>> > That's a different issue. The current code works if you boot a NUMA=y
>> > SPARSEMEM=y machine wi
--On Wednesday, September 07, 2005 11:27:54 -0700 Dave Hansen <[EMAIL
PROTECTED]> wrote:
> On Wed, 2005-09-07 at 11:22 -0700, Martin J. Bligh wrote:
>> CONFIG_NUMA was meant to (and did at one point) support both NUMA and flat
>> machines. This is essential in order for t
--On Wednesday, September 07, 2005 10:28:36 -0700 Dave Hansen <[EMAIL
PROTECTED]> wrote:
> On Tue, 2005-09-06 at 12:56 +0900, Magnus Damm wrote:
>> This patch for 2.6.13-git5 fixes single node sparsemem support. In the case
>> when multiple nodes are used, setup_memory() in arch/i386/mm/discontig
>> > Anticipatory prefaulting raises the highest fault rate obtainable
>> > three-fold
>> > through gang scheduling faults but may allocate some pages to a task that
>> > are
>> > not needed.
>>
>> IIRC that costed more than it saved, at least for forky workloads like a
>> kernel compile - extra
> Anticipatory prefaulting raises the highest fault rate obtainable three-fold
> through gang scheduling faults but may allocate some pages to a task that are
> not needed.
IIRC that costed more than it saved, at least for forky workloads like a
kernel compile - extra cost in zap_pte_range etc. If
Breaks build on PPC64
Lots of this:
In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
from fs/xfs/xfs.h:35,
from fs/xfs/xfs_rtalloc.c:37:
fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined
In file included from fs/xfs/xfs_rtalloc.c:50:
fs/xf
>> They're incompatible, but you could be left to choose one or the other
>> via config option.
>
> Wouldn't need config option: there's /proc/sys/kernel/randomize_va_space
> for the whole running system, compatibility check on the ELFs run, and
> the infinite stack rlimit: enough ways to suppress
--Hugh Dickins <[EMAIL PROTECTED]> wrote (on Wednesday, August 31, 2005
14:42:38 +0100):
> On Wed, 31 Aug 2005, Arjan van de Ven wrote:
>> On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote:
>> > I was going to say, doesn't randomize_va_space take away the rest of
>> > the point? But no, it a
> -scheduler-cache-hot-autodetect.patch
>
> Mabe Martin's machine crash
That machine now boots again with this -mm release. Darren and/or I
will continue trying to figure out what went wrong with this.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Friday, August 19, 2005 04:33:31
-0700):
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
>
> - Lots of fixes, updates and cleanups all over the place.
>
> - If you have the right debugging options set, t
--On Thursday, August 18, 2005 22:02:55 +0200 Samuel Thibault <[EMAIL
PROTECTED]> wrote:
> Samuel Thibault, le Thu 18 Aug 2005 21:49:41 +0200, a écrit :
>> Eric Dumazet, le Thu 18 Aug 2005 17:18:55 +0200, a écrit :
>> > I believe IRQ stacks are also allocated on node 0, that seems more serious.
--Arjan van de Ven <[EMAIL PROTECTED]> wrote (on Saturday, August 13, 2005
18:50:10 +0200):
> On Fri, 2005-08-12 at 09:35 -0700, Linus Torvalds wrote:
>>
>> On Thu, 11 Aug 2005, Steven Rostedt wrote:
>> >
>> > Found the problem. It is a bug with mmap_kmem. The order of checks is
>> > wrong, s
--On Wednesday, August 10, 2005 13:52:45 -0600 Alejandro Bonilla <[EMAIL
PROTECTED]> wrote:
>> I am trying a custom 2.6.8 kernel now, and here is my
>> 2.6.12.4 .config file.
>> Let me know what you think.
>
> I don't know much about Kernel Panics. I hope that someone that knows could
> take a
>>I am in need of some help!
>> I have installed Debian which has 2.6.8-2 kernel on it. After a fresh
>> install I downloaded the 2.6.12.4 kernel and went to upgrade. After
>> making the necessary changes in menuconfig I rebuilt the kernel and
>> install it. It boots up until I get:
>> Modu
--On Wednesday, August 10, 2005 23:50:22 +0200 Pavel Machek <[EMAIL PROTECTED]>
wrote:
> Hi!
>
>> > Swsusp is the main "is valid ram" user I have in mind here. It
>> > wants to know whether or not it should save and restore the
>> > memory of a given `struct page`.
>>
>> Why can't it follow the
http://bugzilla.kernel.org/show_bug.cgi?id=5041
Summary: Encountered this kernel Panic on system boot up
Kernel Version: 2.6.13-rc5-mm1
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
CC: [E
--On Tuesday, August 09, 2005 11:55:36 -0500 James Bottomley <[EMAIL
PROTECTED]> wrote:
> On Tue, 2005-08-09 at 07:59 -0700, Martin J. Bligh wrote:
>> Dear novice test examiner,
>>
>> It's in http://test.kernel.org with everything else ;-)
>> 2.6.
--On Tuesday, August 09, 2005 15:03:32 -0700 "Siddha, Suresh B" <[EMAIL
PROTECTED]> wrote:
> On Fri, Aug 05, 2005 at 04:29:45PM -0700, Darren Hart wrote:
>> I have some concerns as to the intent vs. actual implementation of
>> SD_BALANCE_FORK and the sched_balance_fork() routine.
>
> Intent
>> On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
>>> pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
>>> have a backing struct page for that address. Could be an IO mapped device,
>>> a small memory hole, wh
--On Tuesday, August 09, 2005 20:41:00 +0100 Russell King <[EMAIL PROTECTED]>
wrote:
> On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
>> pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
>> have a backing struct page f
--James Bottomley <[EMAIL PROTECTED]> wrote (on Tuesday, August 09, 2005
09:26:44 -0500):
> On Mon, 2005-08-08 at 21:41 -0700, Martin J. Bligh wrote:
>> Nope, is the same as before with this patch
>
> Dear novice bug reporter,
>
> Thank you for taki
--Russell King <[EMAIL PROTECTED]> wrote (on Tuesday, August 09, 2005 08:08:53
+0100):
> On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
>> That would work for swsusp, but there are other users that want to
>> know if a struct page is valid ram (eg. ioremap), so in that case
>> swsus
> On Fri, 2005-08-05 at 07:36 -0700, Martin J. Bligh wrote:
>> Howcome it works on all mainline kernels, and not -mm then? ;-)
>> Did we fix an error path to detect failures, maybe?
>
> Well, OK, it might be something to do with your drives trying to
> negotiate IU and QA
--Michael Ellerman <[EMAIL PROTECTED]> wrote (on Monday, August 08, 2005
18:49:34 +1000):
> On Mon, 8 Aug 2005 16:09, Nikhil Dharashivkar wrote:
>> Hi Martin,
>> But e1000_notify_reboot () function calls this e1000_suspend()
>> function irrespective of CONFIG_FM is defined or not. So accor
f CONFIG_FM is not defined.
Odd. I wonder why I get a warning then. H
M.
> On 8/8/05, Martin J. Bligh <[EMAIL PROTECTED]> wrote:
>> e1000_suspend is only used under #ifdef CONFIG_PM. Move the declaration
>> of it to be the same way, just like e1000_resume, otherwise gcc wh
--Lee Revell <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 15:56:06
-0400):
> On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote:
>> Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS)
>> supported?
>>
>
> Wow, Google has really declined in quality. I got zero hits for
>
> I like these patches. They greatly simplify a lot of the work I
> had anticipated was necessary for Xen. I.e. - LDT / GDT accessors
> are not needed for most updates, only updates to live descriptor
> table entries (for GDT this is TLS, LDT, TSS?, entries and there
> is 1 LDT update case).
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 17:41:29
-0700):
> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> --Chris Wright <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005
>> 16:44:11
--Chris Wright <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 16:44:11
-0700):
> * Martin J. Bligh ([EMAIL PROTECTED]) wrote:
>> Starting on the work to merge xen cleanly as a subarch.
>> Introduce make_pages_readonly and make_pages_writable where appropriate
>
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005
21:21:30 -0700):
> --"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005
> 18:17:33 -0700):
>> --Andrew Morton <[EMAIL PROTECTED]> wr
Starting on the work to merge xen cleanly as a subarch.
Introduce make_pages_readonly and make_pages_writable where appropriate
for Xen, defined as a no-op on other subarches. Same for
add_context_to_unpinned and del_context_from_unpinned.
Abstract out install_ldt_entry().
This will do have no e
e1000_suspend is only used under #ifdef CONFIG_PM. Move the declaration
of it to be the same way, just like e1000_resume, otherwise gcc whines
on compile. I offer as evidence:
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
.id_table =
>> If it's going to spout crap when I'm not even using the deprecated
>> function, it's worse than useless, I'm afraid.
>> ...
>
> It's reminding us that we are still offering a deprecated function. ;-)
Might be useful as an option. But not to irritate every poor sod who
does a kernel compile, e
Get rid of unused variable warning:
drivers/scsi/aic7xxx/aic7770.c: In function `aic7770_config':
drivers/scsi/aic7xxx/aic7770.c:129: warning: unused variable `l'
Not used anywhere in the function, even under ifdef. Delete.
diff -aurpN -X /home/fletch/.diff.exclude virgin/drivers
--Adrian Bunk <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005 20:23:12
+0200):
> On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote:
>> I'm getting lots of errors like this nowadays:
>>
>> drivers/serial/8250.c:2651: warning: `register_serial
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Sunday, August 07, 2005
11:07:59 -0700):
> I'm getting lots of errors like this nowadays:
>
> drivers/serial/8250.c:2651: warning: `register_serial' is deprecated
> (declared at drivers/serial/8250.c:26
I'm getting lots of errors like this nowadays:
drivers/serial/8250.c:2651: warning: `register_serial' is deprecated
(declared at drivers/serial/8250.c:2607)
Which is just: "EXPORT_SYMBOL(register_serial);"
Sorry, but that's just compile-time noise, not anything useful.
Warning on real usages of
>>> > Freeing unused kernel memory: 248k freed
>>> > VM: killing process hotplug
>>> > VM: killing process hotplug
>>> > VM: killing process hotplug
>>> > VM: killing process hotplug
>>> > Unable to handle kernel paging request at fff28017b5be RIP:
>>> > []
>>>
>>> Looks weird. Just to make s
--James Bottomley <[EMAIL PROTECTED]> wrote (on Friday, August 05, 2005
09:24:52 -0500):
> On Thu, 2005-08-04 at 23:39 -0700, Andrew Morton wrote:
>> James, could some of the scsi core rework have caused this?
>
> Well, I don't think so. The error below:
>
>> > sdc: Unit Not Ready, sense:
>>
If you look on http://test.kernel.org/, you'll see in the rightmost
column there's a yellow box under elm3b70 for 2.6.13-rc4-mm1, but
current mainline kernels are all green (ie no problems). That means
one test failed, in this case making an fs on the spare partition.
Odd. I went digging ...
Look
--Hugh Dickins <[EMAIL PROTECTED]> wrote (on Friday, August 05, 2005 00:06:25
+0100):
> On Thu, 5 Aug 2005, Andi Kleen wrote:
>> [EMAIL PROTECTED] (Danny ter Haar) writes:
>> >
>> > Freeing unused kernel memory: 248k freed
>> > VM: killing process hotplug
>> > VM: killing process hotplug
>> >
-git1 works fine, but -git2 fails in a strange way. Only on my AMD64 box,
the other seem fine. Boots all the way up, then seems to slaughter any
userspace process:
--
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Free
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005
18:17:33 -0700):
> --Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005
> 23:10:29 -0700):
>
>> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>>
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005 23:10:29
-0700):
> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>>
>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>> identified earlier with the sche
--Sonny Rao <[EMAIL PROTECTED]> wrote (on Monday, August 01, 2005 02:23:22
-0400):
> On Mon, Aug 01, 2005 at 12:27:42AM -0500, Paul Mackerras wrote:
>> From: Mike Kravetz <[EMAIL PROTECTED]>
>>
>> If CONFIG_NUMA is set, some POWER 4 systems will fail to boot. This is
>> because of special pro
>> We are iterating over all nodes in nr_free_zone_pages(). Because the
>> fallback zonelists contain all nodes in the system, and we walk all
>> the zonelists, we're counting memory multiple times (once for each
>> node). This caused us to make a size estimate of 32GB for an 8GB
>> AMD64 box,
s all the dirty ratio calculations, etc incorrect.
There's still a further bug to fix from e820 holes causing overestimation
as well, but this fix is separate, and good as is, and fixes one class
of problems. Problem found by Badari, and tested by Ram Pai - thanks!
Signed-off-by: Martin J. Bli
>> > - There's a pretty large x86_64 update here which naughty maintainer wants
>> > in 2.6.13. Extra testing, please.
>>
>> Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
>> Talked to Andi about it at OLS, but then drank too much to remember the
>> conclusion ... howeve
OK, and one last one ... on a more postitive note. rc3-mm3 does indeed fix
the problems crashing on boot I was having on PPC64 with -rc3-mm2. I'll
close the bugzilla bug.
Thanks!
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
identified earlier with the sched patches ...
http://test.kernel.org/9398/debug/console.log
Works with mainline still (including -rc4) ... hopefully those patches
aren't on their way upstream anytime soon ;-)
M.
-
To unsubs
> - There's a pretty large x86_64 update here which naughty maintainer wants
> in 2.6.13. Extra testing, please.
Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
Talked to Andi about it at OLS, but then drank too much to remember the
conclusion ... however, it's still bro
Seems to have some odd problem on PPC64 - crashes on boot.
Seems to affect power 4 boxes, both LPAR and bare metal.
raid5: using function: 32regs (4524.000 MB/sec)
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
oprofile: using ppc64/power4 performance monitoring.
NET
> I don't think so. We're getting the wrong answer out of
> calculate_zone_totalpages() which is an init-time thing.
>
> Maybe nr_free_zone_pages() is supposed to fix that up post-facto somehow,
> but calculate_zone_totalpages() sure as heck shouldn't be putting 1568768
> into my ZONE_NORMAL's
> It happens here, a bit. My machine goes up to 60% dirty when it should be
> clamping at 40%.
>
> The variable `total_pages' in page-writeback.c (from
> nr_free_pagecache_pages()) is too high. I trace it back to here:
>
> On node 0 totalpages: 1572864
> DMA zone: 4096 pages, LIFO batch:1
>
>> > After KS & OLS discussions about memory pressure, I wanted to re-do
>> > iSCSI testing with "dd"s to see if we are throttling writes.
>>
>> Could you also try with shared writable mmap, to see if that
>> works ok or triggers a deadlock ?
>
>
> I can, but lets finish addressing one issue a
--Andi Kleen <[EMAIL PROTECTED]> wrote (on Tuesday, July 26, 2005 17:17:54
+0200):
>> But that's really for ISA DMA, which nobody uses any more apart from the
>> floppy disk, and the stone-tablet adaptor. For now, I'm guessing that if
>> you remove that __GFP_DMA, your machine will be happier,
Paul Jackson wrote:
Matthew wrote:
Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't.
Or perhaps I'm confused. There's a good chance
--On Wednesday, July 13, 2005 17:24:41 -0400 Lee Revell <[EMAIL PROTECTED]>
wrote:
> On Wed, 2005-07-13 at 14:16 -0700, Chris Wedgwood wrote:
>> Both can be detected from you .config and we could see HZ as needed
>> there and everyone else could avoid this surely?
>
> Does anyone object to set
>> Len Brown, a year ago: "The bottom line number to laptop users is
>> battery lifetime. Just today somebody complained to me that Windows
>> gets twice the battery life that Linux does."
>
> It seems the motivation for lower HZ is really:
>
>(1) ACPI/SMM suckage in laptops
>
>(2) NUMA
--On Wednesday, July 13, 2005 14:32:02 -0500 Dmitry Torokhov <[EMAIL
PROTECTED]> wrote:
> Hi,
>
> On 7/13/05, Lee Revell <[EMAIL PROTECTED]> wrote:
>> On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
>> > So we should aim for a HZ value that makes it easy to convert to and from
>> > th
1 - 100 of 144 matches
Mail list logo
