* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: David Mosberger @ 2004-01-27 17:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.10170.911012.262682@cargo.ozlabs.ibm.com>
>>>>> On Tue, 27 Jan 2004 19:56:26 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> David Mosberger writes:
>> How about the attached one? It will touch memory more when
>> moving an element down, but we're talking about exception tables
>> here, and I don't think module loading time would be affected in
>> any noticable fashion.
Paul> Hmmm... Stylistically I much prefer to pick up the new
Paul> element, move the others up and just drop the new element in
Paul> where it should go, rather than doing swap, swap, swap down
Paul> the list.
The original code may be slightly faster, but who cares? From a
readability point of view, I think my version is easier to understand.
Paul> Also, I don't think there is enough code there to be worth the
Paul> bother of trying to abstract the generic routine so you can
Paul> plug in different compare and move-element routines. The
Paul> whole sort routine is only 16 lines of code, after all. Why
Paul> not just have an ia64-specific version of sort_extable?
Paul> That's what I thought you would do.
That's certainly an option. It was Andrew who called for a generic
version. I tend to agree with him because even though it's just a
little sort routine, it's one of those things where stupid errors tend
to creep in. And like I mentioned earlier, Alpha needs the exact same
code (and frankly, I'm surprised there are 64-bit platforms that do
NOT use the location-relative format that Richard invented).
--david
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for
From: David Mosberger @ 2004-01-27 17:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.10170.911012.262682@cargo.ozlabs.ibm.com>
>>>>> On Tue, 27 Jan 2004 19:56:26 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> David Mosberger writes:
>> How about the attached one? It will touch memory more when
>> moving an element down, but we're talking about exception tables
>> here, and I don't think module loading time would be affected in
>> any noticable fashion.
Paul> Hmmm... Stylistically I much prefer to pick up the new
Paul> element, move the others up and just drop the new element in
Paul> where it should go, rather than doing swap, swap, swap down
Paul> the list.
The original code may be slightly faster, but who cares? From a
readability point of view, I think my version is easier to understand.
Paul> Also, I don't think there is enough code there to be worth the
Paul> bother of trying to abstract the generic routine so you can
Paul> plug in different compare and move-element routines. The
Paul> whole sort routine is only 16 lines of code, after all. Why
Paul> not just have an ia64-specific version of sort_extable?
Paul> That's what I thought you would do.
That's certainly an option. It was Andrew who called for a generic
version. I tend to agree with him because even though it's just a
little sort routine, it's one of those things where stupid errors tend
to creep in. And like I mentioned earlier, Alpha needs the exact same
code (and frankly, I'm surprised there are 64-bit platforms that do
NOT use the location-relative format that Richard invented).
--david
^ permalink raw reply
* [PATCH] RSS limit enforcement for 2.6
From: Rik van Riel @ 2004-01-27 17:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: Pavel Machek, Linus Torvalds, linux-mm, linux-kernel
Hi Andrew, Linus,
the patch below (softly) enforces RLIMIT_RSS in the 2.6 kernel,
it has been tested by Pavel and seems to work ok for his workload.
Please place it in -mm for more extensive testing.
thanks,
Rik
===== include/linux/init_task.h 1.27 vs edited =====
--- 1.27/include/linux/init_task.h Mon Aug 18 22:46:23 2003
+++ edited/include/linux/init_task.h Tue Jan 20 17:34:40 2004
@@ -2,6 +2,7 @@
#define _LINUX__INIT_TASK_H
#include <linux/file.h>
+#include <asm/resource.h>
#define INIT_FILES \
{ \
@@ -41,6 +42,7 @@
.page_table_lock = SPIN_LOCK_UNLOCKED, \
.mmlist = LIST_HEAD_INIT(name.mmlist), \
.default_kioctx = INIT_KIOCTX(name.default_kioctx, name), \
+ .rlimit_rss = RLIM_INFINITY \
}
#define INIT_SIGNALS(sig) { \
===== include/linux/sched.h 1.178 vs edited =====
--- 1.178/include/linux/sched.h Mon Jan 19 18:38:15 2004
+++ edited/include/linux/sched.h Tue Jan 20 17:32:56 2004
@@ -204,6 +204,7 @@
unsigned long arg_start, arg_end, env_start, env_end;
unsigned long rss, total_vm, locked_vm;
unsigned long def_flags;
+ unsigned long rlimit_rss;
cpumask_t cpu_vm_mask;
unsigned long saved_auxv[40]; /* for /proc/PID/auxv */
===== include/linux/swap.h 1.80 vs edited =====
--- 1.80/include/linux/swap.h Mon Jan 19 01:28:35 2004
+++ edited/include/linux/swap.h Tue Jan 20 18:16:28 2004
@@ -179,7 +179,7 @@
/* linux/mm/rmap.c */
#ifdef CONFIG_MMU
-int FASTCALL(page_referenced(struct page *));
+int FASTCALL(page_referenced(struct page *, int *));
struct pte_chain *FASTCALL(page_add_rmap(struct page *, pte_t *,
struct pte_chain *));
void FASTCALL(page_remove_rmap(struct page *, pte_t *));
@@ -188,7 +188,7 @@
/* linux/mm/shmem.c */
extern int shmem_unuse(swp_entry_t entry, struct page *page);
#else
-#define page_referenced(page) TestClearPageReferenced(page)
+#define page_referenced(page, _x) TestClearPageReferenced(page)
#define try_to_unmap(page) SWAP_FAIL
#endif /* CONFIG_MMU */
===== kernel/sys.c 1.69 vs edited =====
--- 1.69/kernel/sys.c Mon Jan 19 18:38:13 2004
+++ edited/kernel/sys.c Tue Jan 20 18:02:19 2004
@@ -1308,6 +1308,14 @@
if (retval)
return retval;
+ /* The rlimit is specified in bytes, convert to pages for mm. */
+ if (resource == RLIMIT_RSS && current->mm) {
+ unsigned long pages = RLIM_INFINITY;
+ if (new_rlim.rlim_cur != RLIM_INFINITY)
+ pages = new_rlim.rlim_cur >> PAGE_SHIFT;
+ current->mm->rlimit_rss = pages;
+ }
+
*old_rlim = new_rlim;
return 0;
}
===== mm/rmap.c 1.34 vs edited =====
--- 1.34/mm/rmap.c Mon Jan 19 01:36:00 2004
+++ edited/mm/rmap.c Tue Jan 20 18:26:03 2004
@@ -104,6 +104,7 @@
/**
* page_referenced - test if the page was referenced
* @page: the page to test
+ * rsslimit: set if the process(es) using the page is(are) over RSS limit
*
* Quick test_and_clear_referenced for all mappings to a page,
* returns the number of processes which referenced the page.
@@ -112,8 +113,9 @@
* If the page has a single-entry pte_chain, collapse that back to a PageDirect
* representation. This way, it's only done under memory pressure.
*/
-int page_referenced(struct page * page)
+int page_referenced(struct page * page, int * rsslimit)
{
+ struct mm_struct * mm;
struct pte_chain *pc;
int referenced = 0;
@@ -127,10 +129,17 @@
pte_t *pte = rmap_ptep_map(page->pte.direct);
if (ptep_test_and_clear_young(pte))
referenced++;
+
+ mm = ptep_to_mm(pte);
+ if (mm->rss > mm->rlimit_rss)
+ *rsslimit = 1;
rmap_ptep_unmap(pte);
} else {
int nr_chains = 0;
+ /* We clear it if any task using the page is under its limit. */
+ *rsslimit = 1;
+
/* Check all the page tables mapping this page. */
for (pc = page->pte.chain; pc; pc = pte_chain_next(pc)) {
int i;
@@ -142,6 +151,10 @@
p = rmap_ptep_map(pte_paddr);
if (ptep_test_and_clear_young(p))
referenced++;
+
+ mm = ptep_to_mm(p);
+ if (mm->rss < mm->rlimit_rss)
+ *rsslimit = 0;
rmap_ptep_unmap(p);
nr_chains++;
}
===== mm/vmscan.c 1.177 vs edited =====
--- 1.177/mm/vmscan.c Mon Jan 19 18:38:07 2004
+++ edited/mm/vmscan.c Fri Jan 23 14:00:48 2004
@@ -250,6 +250,7 @@
LIST_HEAD(ret_pages);
struct pagevec freed_pvec;
int pgactivate = 0;
+ int over_rsslimit;
int ret = 0;
cond_resched();
@@ -278,8 +279,8 @@
goto keep_locked;
pte_chain_lock(page);
- referenced = page_referenced(page);
- if (referenced && page_mapping_inuse(page)) {
+ referenced = page_referenced(page, &over_rsslimit);
+ if (referenced && page_mapping_inuse(page) && !over_rsslimit) {
/* In active use or really unfreeable. Activate it. */
pte_chain_unlock(page);
goto activate_locked;
@@ -597,6 +598,7 @@
long mapped_ratio;
long distress;
long swap_tendency;
+ int over_rsslimit;
lru_add_drain();
pgmoved = 0;
@@ -657,7 +659,7 @@
list_del(&page->lru);
if (page_mapped(page)) {
pte_chain_lock(page);
- if (page_mapped(page) && page_referenced(page)) {
+ if (page_mapped(page) && page_referenced(page, &over_rsslimit) && !over_rsslimit) {
pte_chain_unlock(page);
list_add(&page->lru, &l_active);
continue;
^ permalink raw reply
* [PATCH] RSS limit enforcement for 2.6
From: Rik van Riel @ 2004-01-27 17:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: Pavel Machek, Linus Torvalds, linux-mm, linux-kernel
Hi Andrew, Linus,
the patch below (softly) enforces RLIMIT_RSS in the 2.6 kernel,
it has been tested by Pavel and seems to work ok for his workload.
Please place it in -mm for more extensive testing.
thanks,
Rik
===== include/linux/init_task.h 1.27 vs edited =====
--- 1.27/include/linux/init_task.h Mon Aug 18 22:46:23 2003
+++ edited/include/linux/init_task.h Tue Jan 20 17:34:40 2004
@@ -2,6 +2,7 @@
#define _LINUX__INIT_TASK_H
#include <linux/file.h>
+#include <asm/resource.h>
#define INIT_FILES \
{ \
@@ -41,6 +42,7 @@
.page_table_lock = SPIN_LOCK_UNLOCKED, \
.mmlist = LIST_HEAD_INIT(name.mmlist), \
.default_kioctx = INIT_KIOCTX(name.default_kioctx, name), \
+ .rlimit_rss = RLIM_INFINITY \
}
#define INIT_SIGNALS(sig) { \
===== include/linux/sched.h 1.178 vs edited =====
--- 1.178/include/linux/sched.h Mon Jan 19 18:38:15 2004
+++ edited/include/linux/sched.h Tue Jan 20 17:32:56 2004
@@ -204,6 +204,7 @@
unsigned long arg_start, arg_end, env_start, env_end;
unsigned long rss, total_vm, locked_vm;
unsigned long def_flags;
+ unsigned long rlimit_rss;
cpumask_t cpu_vm_mask;
unsigned long saved_auxv[40]; /* for /proc/PID/auxv */
===== include/linux/swap.h 1.80 vs edited =====
--- 1.80/include/linux/swap.h Mon Jan 19 01:28:35 2004
+++ edited/include/linux/swap.h Tue Jan 20 18:16:28 2004
@@ -179,7 +179,7 @@
/* linux/mm/rmap.c */
#ifdef CONFIG_MMU
-int FASTCALL(page_referenced(struct page *));
+int FASTCALL(page_referenced(struct page *, int *));
struct pte_chain *FASTCALL(page_add_rmap(struct page *, pte_t *,
struct pte_chain *));
void FASTCALL(page_remove_rmap(struct page *, pte_t *));
@@ -188,7 +188,7 @@
/* linux/mm/shmem.c */
extern int shmem_unuse(swp_entry_t entry, struct page *page);
#else
-#define page_referenced(page) TestClearPageReferenced(page)
+#define page_referenced(page, _x) TestClearPageReferenced(page)
#define try_to_unmap(page) SWAP_FAIL
#endif /* CONFIG_MMU */
===== kernel/sys.c 1.69 vs edited =====
--- 1.69/kernel/sys.c Mon Jan 19 18:38:13 2004
+++ edited/kernel/sys.c Tue Jan 20 18:02:19 2004
@@ -1308,6 +1308,14 @@
if (retval)
return retval;
+ /* The rlimit is specified in bytes, convert to pages for mm. */
+ if (resource == RLIMIT_RSS && current->mm) {
+ unsigned long pages = RLIM_INFINITY;
+ if (new_rlim.rlim_cur != RLIM_INFINITY)
+ pages = new_rlim.rlim_cur >> PAGE_SHIFT;
+ current->mm->rlimit_rss = pages;
+ }
+
*old_rlim = new_rlim;
return 0;
}
===== mm/rmap.c 1.34 vs edited =====
--- 1.34/mm/rmap.c Mon Jan 19 01:36:00 2004
+++ edited/mm/rmap.c Tue Jan 20 18:26:03 2004
@@ -104,6 +104,7 @@
/**
* page_referenced - test if the page was referenced
* @page: the page to test
+ * rsslimit: set if the process(es) using the page is(are) over RSS limit
*
* Quick test_and_clear_referenced for all mappings to a page,
* returns the number of processes which referenced the page.
@@ -112,8 +113,9 @@
* If the page has a single-entry pte_chain, collapse that back to a PageDirect
* representation. This way, it's only done under memory pressure.
*/
-int page_referenced(struct page * page)
+int page_referenced(struct page * page, int * rsslimit)
{
+ struct mm_struct * mm;
struct pte_chain *pc;
int referenced = 0;
@@ -127,10 +129,17 @@
pte_t *pte = rmap_ptep_map(page->pte.direct);
if (ptep_test_and_clear_young(pte))
referenced++;
+
+ mm = ptep_to_mm(pte);
+ if (mm->rss > mm->rlimit_rss)
+ *rsslimit = 1;
rmap_ptep_unmap(pte);
} else {
int nr_chains = 0;
+ /* We clear it if any task using the page is under its limit. */
+ *rsslimit = 1;
+
/* Check all the page tables mapping this page. */
for (pc = page->pte.chain; pc; pc = pte_chain_next(pc)) {
int i;
@@ -142,6 +151,10 @@
p = rmap_ptep_map(pte_paddr);
if (ptep_test_and_clear_young(p))
referenced++;
+
+ mm = ptep_to_mm(p);
+ if (mm->rss < mm->rlimit_rss)
+ *rsslimit = 0;
rmap_ptep_unmap(p);
nr_chains++;
}
===== mm/vmscan.c 1.177 vs edited =====
--- 1.177/mm/vmscan.c Mon Jan 19 18:38:07 2004
+++ edited/mm/vmscan.c Fri Jan 23 14:00:48 2004
@@ -250,6 +250,7 @@
LIST_HEAD(ret_pages);
struct pagevec freed_pvec;
int pgactivate = 0;
+ int over_rsslimit;
int ret = 0;
cond_resched();
@@ -278,8 +279,8 @@
goto keep_locked;
pte_chain_lock(page);
- referenced = page_referenced(page);
- if (referenced && page_mapping_inuse(page)) {
+ referenced = page_referenced(page, &over_rsslimit);
+ if (referenced && page_mapping_inuse(page) && !over_rsslimit) {
/* In active use or really unfreeable. Activate it. */
pte_chain_unlock(page);
goto activate_locked;
@@ -597,6 +598,7 @@
long mapped_ratio;
long distress;
long swap_tendency;
+ int over_rsslimit;
lru_add_drain();
pgmoved = 0;
@@ -657,7 +659,7 @@
list_del(&page->lru);
if (page_mapped(page)) {
pte_chain_lock(page);
- if (page_mapped(page) && page_referenced(page)) {
+ if (page_mapped(page) && page_referenced(page, &over_rsslimit) && !over_rsslimit) {
pte_chain_unlock(page);
list_add(&page->lru, &l_active);
continue;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply
* Re: MO: opening for write in cdrom.c
From: Pascal Schmidt @ 2004-01-27 17:45 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel
In-Reply-To: <1iEqx-8bO-31@gated-at.bofh.it>
On Tue, 27 Jan 2004 17:40:45 +0100, you wrote in linux.kernel:
> I'm surprised the sense messages don't show that it's a write to a write
> protected disc (xx/27/zz, where xx == 0x07 or 0x05).
Yep, I wasn't precise, that shows up before the error=0x70 line.
> However, it's even
> more annoying to _not_ be able to write to a media because the kernel
> thinks it knows better. In your fsck case you sort of get what you ask
> for, by shooting yourself in the foot :)
Agreed. It just bit me extra hard because I was thinking my sector
size patches were screwing things up. ;)
>> It's fine with me either way. Do you want me to resend with the
>> default fallback changed?
> Yes please.
Ok, I'll do that.
>> + unsigned short sectors_per_frame = drive->queue->hardsect_size >> 9;
>
> Nitpick: sectors_per_frame = queue_hardsect_size(q) >> 9;
Yes, I agree, better to use the existing abstraction. I'll split it
then and initialize it as the first line of the function(s), otherwise
it doesn't fit into 80 columns.
> That's about, the rest looks fine.
I'll make that change everywhere and then send an updated version.
--
Ciao,
Pascal
^ permalink raw reply
* Re: [PATCH] kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
From: Jim Houston @ 2004-01-27 17:43 UTC (permalink / raw)
To: Andi Kleen; +Cc: akpm, george, amitkale, linux-kernel
In-Reply-To: <20040127155619.7efec284.ak@suse.de>
On Tue, 2004-01-27 at 09:56, Andi Kleen wrote:
> On Mon, 26 Jan 2004 22:05:29 -0500 (EST)
> Jim Houston <jim.houston@comcast.net> wrote:
> > The attached patch updates my kgdb-x86_64-support.patch to work
> > with linux-2.6.2-rc1-mm3.
>
> I already did this merge yesterday. Didn't you get mail?
Hi Andi,
No. I didn't see your mail until this morning.
It looks like we were working in lock step. I had been meaning to
update the patch so when I saw that Andrew had dropped it from
2.6.2-rc1-mm3 it seemed like a good time.
I'll leave it to you and Andrew to decide how we should resolve our
conflicting patches.
I'm including my notes on the difference between our patches.
Jim Houston - Concurrent Computer Corp.
--
arch/x86_64/kernel/kgdb_stub.c
Lots of white space changes. I assume these are my fault.
I use the variable kgdb_enable to decide if the system should
stop in kgdb on an oops or other failure. My intention was to
set this variable when the user connected. I was doing this
for serial but not for kgdboe.
I removed a \n from print_extra_info.
init/main.c
This change puts trap_init before parse_args(). I needed this
for the early entry into kgdb with the gdb command line argument
to work.
arch/x86_64/boot/compressed/head.S
arch/x86_64/boot/compressed/misc.c
include/linux/config.h
On the i386 asm/kgdb.h is included from config.h. These changes
make the x86_64 do the same. I'm not a fan of globally
included header files, but I wanted the x86_64 to work the same
as the i386. The asm/kgdb.h provides a stub for
kgdb_process_breakpoint() avoiding the undefined symbol.
arch/x86_64/kernel/irq.c
This change is not needed with the change above.
arch/x86_64/Kconfig
arch/x86_64/Kconfig.kgdb
We used a different approach to selecting DEBUG_INFO.
I was not really happy with the way select DEBUG_INFO worked.
Makefile
I added -g to AFLAGS so the .S files get line number info.
I have a problem where gdb identifies error_exit as being
in elf_core.h. I had hoped this would help. It didn't,
but I still like this change.
include/linux/bitops.h
I dropped this one. I suspect that this fixed a compile
warning in a forgotten Concurrent tree.
include/asm-x86_64/kgdb_local.h
This file seems to be missing from your patch. Maybe I'm
missing something. In my patch it is a copy of the i386
version.
^ permalink raw reply
* Netfilter and Squid
From: Glen Spidal @ 2004-01-27 17:41 UTC (permalink / raw)
To: netfilter
Hello all,
I have the following setup:
Internet->PublicIP_Router->Cross-over-cable->Squid_Server->LAN
Squid works fine as does Dans' Guardian web filter. MY question is what do
I need to do to route web traffic through squid and allow email traffic to
flow around Squid? Currently, client-based email (Outlook and Entourage)
does not work because there is no route. I must make sure that all LAN
clients go through squid since it is a school.
I've looked through the how-to's but have not found specific examples and
syntax.
Glen Spidal
Cybercorp Computers
Hillsboro, OR 97123
PH: 503-681-9786 -- FX: 503-615-2936
glens@cybercorpinc.com -- www.cybercorpinc.com
^ permalink raw reply
* Re: 2.6.1 dual xeon
From: Justin Cormack @ 2004-01-27 17:41 UTC (permalink / raw)
To: Alexander Nyberg; +Cc: LKML
In-Reply-To: <1075223587.1173.5.camel@llhosts>
You can run irqbalance in one shot mode not continously. Check the
options.
On Tue, 2004-01-27 at 17:13, Alexander Nyberg wrote:
> On Tue, 2004-01-27 at 08:38, Sander wrote:
> > Wakko Warner wrote (ao):
> > > > > I recently aquired a dual xeon system. HT is enabled which shows
> > > > > up as 4 cpus. I noticed that all interrupts are on CPU0. Can
> > > > > anyone tell me why this is?
> > > >
> > > > The APIC needs to be programmed to deliver interrupts to certain
> > > > processors.
> > > >
> > > > In 2.6, this is done in user-space via a program called irqbalance:
> > >
> > > Thanks, working great. (Debian by the way)
> >
> > Ehm, IIRC the "all interrupts are on CPU0" is how it is supposed to work
> > with a 2.6 kernel? The interrupts should spread if you have _a_lot_ of
> > them. This gives better performance than spreading the interrupts. Did I
> > read this on the list, or am I completely wrong here?
>
> Apparently it was way especially better performance wise to have
> interrupts that hit often (ethernet cards ie.) on the same cpu.
>
> But I can't see a reason for not dividing the different interrupt on
> different cpu's and letting them stay put. Maybe if you keep all
> interrupts on the same cpu the cache on the other ones will not have to
> be flushed often, which would be a good thing.
>
> How would it be to maybe remove all interrupts from a cpu (except
> between cpu's) and have a few cpu's merely working with data and one "in
> control". Bad idea I guess as I haven't seen any such work.
>
> Alex
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Dosemu 1.2.0 & kernel 2.6 crash
From: Bart Oldeman @ 2004-01-27 17:39 UTC (permalink / raw)
To: Vaclav Cermak; +Cc: linux-msdos
In-Reply-To: <1075215756.24117.9.camel@infiwo>
On 27 Jan 2004, Vaclav Cermak wrote:
> 2.6.0-1.104custom is kernel from similar rpms compiled by myself (i
> turned off APM support).
Ok, I'll try that someday (probably next week).
A couple things though:
> 0MB HIGHMEM available.
> 511MB LOWMEM available.
> mapped 4G/4G trampoline to ffff3000.
you could try to turn off the 4G/4G trampoline or any other highmem
options. It really isn't necessary if you "only" have 512MB RAM.
DOSEMU may well have problems with 4G/4G today -- most likely someone will
solve them in the future though.
Bart
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: David Mosberger @ 2004-01-27 17:39 UTC (permalink / raw)
To: Jes Sorensen
Cc: davidm, Paul Mackerras, Andrew Morton, linux-kernel, linux-ia64
In-Reply-To: <yq0y8rtreug.fsf@wildopensource.com>
>>>>> On 27 Jan 2004 03:11:03 -0500, Jes Sorensen <jes@wildopensource.com> said:
>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:
Jes> David,
Jes> I am just nitpicking here, but wouldn't it be better to stick
Jes> to the convention of all upper case defines for the #ifdef
Jes> check?
Yeah, it is nitpicking! ;-)
Jes> Maybe use something like? #define ARCH_EXTABLE_COMPARE_ENTRIES
Jes> ia64_extable_compare_entries
I'd rather have ARCH_HAS_EXTABLE_COMPARE_ENTRIES or something like
that, in that case.
--david
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: David Mosberger @ 2004-01-27 17:39 UTC (permalink / raw)
To: Jes Sorensen
Cc: davidm, Paul Mackerras, Andrew Morton, linux-kernel, linux-ia64
In-Reply-To: <yq0y8rtreug.fsf@wildopensource.com>
>>>>> On 27 Jan 2004 03:11:03 -0500, Jes Sorensen <jes@wildopensource.com> said:
>>>>> "David" = David Mosberger <davidm@napali.hpl.hp.com> writes:
Jes> David,
Jes> I am just nitpicking here, but wouldn't it be better to stick
Jes> to the convention of all upper case defines for the #ifdef
Jes> check?
Yeah, it is nitpicking! ;-)
Jes> Maybe use something like? #define ARCH_EXTABLE_COMPARE_ENTRIES
Jes> ia64_extable_compare_entries
I'd rather have ARCH_HAS_EXTABLE_COMPARE_ENTRIES or something like
that, in that case.
--david
^ permalink raw reply
* Re: [2.0.40-rc8] Works well
From: David Weinehall @ 2004-01-27 17:38 UTC (permalink / raw)
To: Markus Hästbacka; +Cc: Kernel Mailinglist
In-Reply-To: <1075223456.5219.1.camel@midux>
On Tue, Jan 27, 2004 at 07:10:56PM +0200, Markus Hästbacka wrote:
> Hey David,
> I just mail to tell you that 2.0.40-rc8 seems to work really well, no
> problems compiling (except a few warnings :) and absolutely no problem
> running. Great work!
Most of the compile-time warning I got was from using a newer binutils,
but I'll try to fix all warnings (that are fixable without causing bugs)
in 2.0.41.
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
^ permalink raw reply
* Re: [parisc-linux] error?
From: Matthew Wilcox @ 2004-01-27 17:37 UTC (permalink / raw)
To: Grant Grundler; +Cc: parisc-linux, Naresh Kumar
In-Reply-To: <20040127172256.GB28476@colo.lackof.org>
On Tue, Jan 27, 2004 at 10:22:56AM -0700, Grant Grundler wrote:
> On Tue, Jan 27, 2004 at 03:16:16PM +0530, Naresh Kumar wrote:
> > r->end = p->end;
> > r->flags = IORESOURCE_MEM;
> > r->parent = r->sibling = r->child = NULL;
> > break;
> > lba_dev->gmmio_base = p->start;
> > break;
> >
> > case PAT_NPIOP:
> > printk(KERN_WARNING MODULE_NAME
> > " range[%d] : ignoring NPIOP (0x%lx)\n",
> > i, p->start);
> > break;
> > -------------------------------------------------------------------
> >
> > Please note the extra lines after the 'break;'. The version of
> > 'lba_pci.c' is 1.7. Seems to have happened due to oversight.
>
> Those are "extra"?
> The version of code in linux-2.4 CVS has:
> case PAT_GMMIO:
> printk(KERN_WARNING MODULE_NAME
> " range[%d] : ignoring GMMIO (0x%lx)\n",
> i, p->start);
> lba_dev->gmmio_base = p->start;
> break;
>
> The code you quoted is missing the "case PAT_GMMIO" and printk.
The bit he's referring to is:
> break;
> lba_dev->gmmio_base = p->start;
> break;
which is clearly bogus.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
^ permalink raw reply
* Re: 2.6.1: process start times by procps
From: Petri Kaukasoina @ 2004-01-27 17:31 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040127155254.GA1656@elektroni.ee.tut.fi>
On Tue, Jan 27, 2004 at 05:52:54PM +0200, Petri Kaukasoina wrote:
> I made an experiment shown below. I know nothing about kernel programming,
> so this is probably not correct, but at least btime seemed to stay constant.
> (I don't believe this fixes procps, though. If HZ if off by 180 ppm then I
> guess ps can't possibly get its calculations involving HZ right. But at
> least the bootup time reported by procinfo stays constant.)
Yes, btime stays now constant. But to make ps work right, I replaced all uses of
variable Hertz in ps source (procps 2.0.18) with constant 100.0172.
After uptime 4 h 42 min, the error is already 3 seconds in the default ps,
and ./ps which is the "fixed" one, displays the right start time.
Tue Jan 27 19:17:57 EET 2004
kaukasoi 13388 0.0 0.1 2652 740 pts/5 R 19:17 0:00 ps uxw
kaukasoi 13392 0.0 0.1 2636 724 pts/5 R 19:17 0:00 ./ps uxw
Tue Jan 27 19:17:57 EET 2004
kaukasoi 13398 0.0 0.1 2652 740 pts/5 R 19:18 0:00 ps uxw
kaukasoi 13402 0.0 0.1 2636 724 pts/5 R 19:17 0:00 ./ps uxw
Tue Jan 27 19:17:57 EET 2004
...
Tue Jan 27 19:17:59 EET 2004
kaukasoi 13979 0.0 0.1 2652 740 pts/5 R 19:18 0:00 ps uxw
kaukasoi 13983 0.0 0.1 2636 724 pts/5 R 19:18 0:00 ./ps uxw
Tue Jan 27 19:18:00 EET 2004
So the problem is the inaccuracy of HZ.
^ permalink raw reply
* Linux on a Motorola MPC5200 ?
From: Sylvain Munaut @ 2004-01-27 17:28 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I'd like to run linux on a future custom board based on a motorola
MPC5200 and I have a few questions :
- What is the current support for it ? Stable ... I'd need the DMA (
well, their 'special DMA fancy stuff' ;) ), ATA, DDR, I2S, AC97 mainly.
- I'd really like to run a 2.6 kernel on it. If it's not yet ported to
the 2.6 what is the current ppc support for 2.6 ? Would I "only" need to
port MPC specifics ?
- Where can I find the current stuff ? I've taken what is in
ppc.bkbits.net/linux-2.4-mpc5xxx, is there other things I should consider ?
Thanks for any informations
Munaut Sylvain
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [LARTC] Force internal re-routing for certain subnets
From: Manuel Schroeder @ 2004-01-27 17:26 UTC (permalink / raw)
To: lartc
Hi list,
I have an ipcop 1.3.0 with one regular ip address on its green
(internal) interface 172.25.0.1 with one subnet 172.25.0.0/22 related to
it.
In addition I have assigned two further ip addresses 172.25.64.1. and
172.25.68.1 to right that green network card with two respective further
subnets 172.25.64.0/22 and 172.25.68.0/22 related to each for certain
reasons.
Now I want to force all external (red) traffic from / to both the
further green subnets 172.25.64.0/22 and 172.25.68.0/22 to go through
the first "regular" green interface.
This is because this "regular" green interface 172.25.0.1 is where
squid, dnsmasq and others are listening and such I want to ease other
alternative networking calamities which I encountered.
Can one give me a hand how to arrange this internal re-routing with ip
rule ... / ip route ... etc.?
I had a look at
http://www.linuxguruz.com/iptables/howto/2.4routing-4.html and tried to
figure out but such easy it didn't work for me.
Many thanks and cheers
Manuel
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [parisc-linux] error?
From: Grant Grundler @ 2004-01-27 17:22 UTC (permalink / raw)
To: Naresh Kumar; +Cc: parisc-linux
In-Reply-To: <40163368.74DACC64@india.hp.com>
On Tue, Jan 27, 2004 at 03:16:16PM +0530, Naresh Kumar wrote:
> r->end = p->end;
> r->flags = IORESOURCE_MEM;
> r->parent = r->sibling = r->child = NULL;
> break;
> lba_dev->gmmio_base = p->start;
> break;
>
> case PAT_NPIOP:
> printk(KERN_WARNING MODULE_NAME
> " range[%d] : ignoring NPIOP (0x%lx)\n",
> i, p->start);
> break;
> -------------------------------------------------------------------
>
> Please note the extra lines after the 'break;'. The version of
> 'lba_pci.c' is 1.7. Seems to have happened due to oversight.
Those are "extra"?
The version of code in linux-2.4 CVS has:
case PAT_GMMIO:
printk(KERN_WARNING MODULE_NAME
" range[%d] : ignoring GMMIO (0x%lx)\n",
i, p->start);
lba_dev->gmmio_base = p->start;
break;
The code you quoted is missing the "case PAT_GMMIO" and printk.
thanks,
grant
^ permalink raw reply
* Re: [parisc-linux] Using PAT_IO calls for PCI config space reads and writes.
From: Grant Grundler @ 2004-01-27 17:20 UTC (permalink / raw)
To: Naresh Kumar; +Cc: parisc-linux
In-Reply-To: <401623CA.59AE3CCD@india.hp.com>
On Tue, Jan 27, 2004 at 02:09:38PM +0530, Naresh Kumar wrote:
> When I was trying to bring up PA-Linux-2.4 on some of the newer boxes, I
> discovered that reads/writes from the PCI config space were failing (
Naresh,
Awesome!
Thanks for pulling this together and sending it out.
...
> have been made to three files:
>
> 1. arch/parisc/kernel/firmware.c - Rev 1.47
> 2. arch/parisc/kernel/lba_pci.c - Rev 1.54
> 3. include/asm-parisc/pdc.h - Rev 1.48
>
> Kindly let me know your comments:
>
> --------------------START------------------------------------------------------------------------------
>
> --- lba_pci.c.1.54 Fri Jan 23 15:47:41 2004
> +++ lba_pci.c.modified Fri Jan 23 15:53:15 2004
The diff should apply with:
cd /usr/src/linux-2.4; patch -p1 < ~/diff-2.4-PAT_CFG
This patch doesn't do that or even come close.
Can you send a new patch generated with:
cd /usr/src/linux-2.4 ; cvs diff -uNp > ~/diff-2.4-PAT_CFG
thanks,
grant
^ permalink raw reply
* Re: [parisc-linux] A fix for B2k and CONFIG_PDC_CONSOLE pb
From: Joel Soete @ 2004-01-27 17:17 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Christoph Plattner, Grant Grundler, parisc-linux
In-Reply-To: <20040126172505.GQ11844@parcelfarce.linux.theplanet.co.uk>
Hi all,
Sorry but don't apply this this patch, I just do more test and unfortunately
it broken sti console :(.
hmm I check a bit more but mem_kbd.iodc_io was always zero?
and I don't notice any diference in PAGE0->mem_kbd... between a boot with
console set to graphics(0) and a boot with serial_1?
Any idea?
Thanks again,
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr
^ permalink raw reply
* Re: 2.6.1 dual xeon
From: Alexander Nyberg @ 2004-01-27 17:13 UTC (permalink / raw)
To: LKML
In-Reply-To: <20040127073801.GB9708@favonius>
On Tue, 2004-01-27 at 08:38, Sander wrote:
> Wakko Warner wrote (ao):
> > > > I recently aquired a dual xeon system. HT is enabled which shows
> > > > up as 4 cpus. I noticed that all interrupts are on CPU0. Can
> > > > anyone tell me why this is?
> > >
> > > The APIC needs to be programmed to deliver interrupts to certain
> > > processors.
> > >
> > > In 2.6, this is done in user-space via a program called irqbalance:
> >
> > Thanks, working great. (Debian by the way)
>
> Ehm, IIRC the "all interrupts are on CPU0" is how it is supposed to work
> with a 2.6 kernel? The interrupts should spread if you have _a_lot_ of
> them. This gives better performance than spreading the interrupts. Did I
> read this on the list, or am I completely wrong here?
Apparently it was way especially better performance wise to have
interrupts that hit often (ethernet cards ie.) on the same cpu.
But I can't see a reason for not dividing the different interrupt on
different cpu's and letting them stay put. Maybe if you keep all
interrupts on the same cpu the cache on the other ones will not have to
be flushed often, which would be a good thing.
How would it be to maybe remove all interrupts from a cpu (except
between cpu's) and have a few cpu's merely working with data and one "in
control". Bad idea I guess as I haven't seen any such work.
Alex
^ permalink raw reply
* Re: gdb problems
From: Wolfgang Denk @ 2004-01-27 17:13 UTC (permalink / raw)
To: cjohnson; +Cc: linuxppc-dev
In-Reply-To: <4016965F.5060706@gcctech.com>
In message <4016965F.5060706@gcctech.com> you wrote:
>
> Problem #1: When I start host side gdb, I get the message:
> warning: unable to find dynamic linker breakpoint function
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code
You missed to set solib-absolute-prefix - see
http://www.denx.de/twiki/bin/view/DULG/DebuggingApplication#Section_9.5.2.
> The program starts and breakpoint don't work.
>
> Problem #2: (Maybe related?) on the target side gdbserver, after
> starting things with "c" on the host side, this message appears:
> gdb: error initializing thread_db library.
> gdb: error initializing thread_db library.
>
> Yes, twice.
Well, guess what that means?
> Why is gdbserver on the target having trouble? I see I have correctly
> delivered the thread_db library in /lib on the target, so what gives?
Probably you have other problems with your build of GDB / gdbserver.
We had to fix a couple of problems to get thread support working.
> Any help or guidance would be greatly appreciated. I build my toolchain
> with crosstools.
Feel free to try out the GDB / gdbserver that come with the ELDK.
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
The moral of the story is: "Don't stop to tighten your shoe laces
during the Olympics 100m finals".
- Kevin Jones in <DEJo68.K1t@bri.hp.com>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: gdb problems
From: Christopher R. Johnson @ 2004-01-27 17:13 UTC (permalink / raw)
To: cjohnson, linuxppc-dev
In-Reply-To: <4016965F.5060706@gcctech.com>
Ok, answering some of my own questions:
in host-side gdb, use the two commands:
set solib-absolute-prefix
set solib-search-path
I set the first to /dev/null and the second to the path where my
filesystem is constructed and its /lib directory (where all my shared
libs are on the host).
All the below error messages go away, but I am left with my original
problem. I can set breakpoints but they don't work. What am I missing?
Christopher R. Johnson wrote:
>
> Maybe not the right list for this, if you have a suggestion for
> somewhere better let me know...
>
> My new tool chain build is working well, except that debugging with
> gdb/gdbserver is somewhat broken. I figured out that I needed thread_db
> and have that built in now and delivered to the target platform.
>
> Problem #1: When I start host side gdb, I get the message:
> warning: unable to find dynamic linker breakpoint function
> GDB will be unable to debug shared library initializers
> and track explicitly loaded dynamic code
>
> I don't need to debug initializers, so I set a breakpoint at main and
> continue. Two error messages appear:
> Error while mapping shared library sections:
> /lib/ld.so.1: No such file or directory
> Error while mapping shared library symbols:
> /lib/ld.so.1: No such file or directory
>
> The program starts and breakpoint don't work.
>
> Problem #2: (Maybe related?) on the target side gdbserver, after
> starting things with "c" on the host side, this message appears:
> gdb: error initializing thread_db library.
> gdb: error initializing thread_db library.
>
> Yes, twice.
>
> Why is the host side looking in /lib for target libraries? Can I
> control that? How?
>
> Why is gdbserver on the target having trouble? I see I have correctly
> delivered the thread_db library in /lib on the target, so what gives?
>
> Any help or guidance would be greatly appreciated. I build my toolchain
> with crosstools.
>
> --
> Christopher R. Johnson
>
>
>
--
Christopher R. Johnson
Principal Software Engineer
GCC Printers
(781)276-8763
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [OT] Sco
From: Wakko Warner @ 2004-01-27 17:25 UTC (permalink / raw)
To: Timothy Miller; +Cc: walt, Linux Kernel
In-Reply-To: <40169031.50603@techsource.com>
> >> There's a new virus out called W32/MyDoom.A that between feb 1st and
> >> 12th it
> >> will DoS www.sco.com. I didn't see anything on the list about it this
> >> morning so I thought I'd share.
> >
> >
> > So, are you suggesting that we all start using Outlook Express on Jan 31?
I never said this. I was only stating that the virus existed.
> As much as SCO disturbs me, these kinds of underhanded attacks against
> them disgust me. They stoop to SCO's level, or worse. SCO can and will
> be dealt with properly through the use of FACTS.
I did not imply that the linux community help spread this. Having to deal
with windows users (Add 'L's where appropriate), I've been bombarded with
this thing at work as I receive all virus infected emails.
> Besides, DoS attacks against SCO will only be blamed on the Linux
> community. So the developer of that virus is either a complete idiot or
> is acting to intentionally hurt our image.
If the former, then this is probably a windows person. After all, the virus
is for *windows* and not linux.
--
Lab tests show that use of micro$oft causes cancer in lab animals
^ permalink raw reply
* [2.0.40-rc8] Works well
From: Markus Hästbacka @ 2004-01-27 17:10 UTC (permalink / raw)
To: David Weinehall; +Cc: Kernel Mailinglist
In-Reply-To: <20040125222914.GB20879@khan.acc.umu.se>
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
Hey David,
I just mail to tell you that 2.0.40-rc8 seems to work really well, no
problems compiling (except a few warnings :) and absolutely no problem
running. Great work!
Markus
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: atkbd.c: Unknown key released
From: Voluspa @ 2004-01-27 17:10 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: linux-kernel
citerar Vojtech Pavlik:
> On Tue, Jan 27, 2004 at 08:16:59AM +0100, Voluspa wrote:
[...]
>
> > > > I keep getting the following in my syslog whenever I startx:
> >
> > In fact, it is preemptively written even _before_ I start X :-)
[...]
> Do you use 'kbdrate' in your bootup scripts? That's another one touching
> the keyboard controller directly, when there are ioctls for that.
>
> I guess I should modify to make the message not point not directly to X,
> but 'some application'.
Yes, 'kbdrate' is used here.
Mvh
Mats Johannesson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.