* Re: [PATCH 2.5.52] NUMA scheduler (1/2)
From: Christoph Hellwig @ 2002-12-20 15:17 UTC (permalink / raw)
To: Erich Focht
Cc: Martin J. Bligh, Michael Hohnbaum, Robert Love, Ingo Molnar,
Stephen Hemminger, linux-kernel
In-Reply-To: <200212181721.39434.efocht@ess.nec.de>
diff -urN a/arch/i386/kernel/smpboot.c b/arch/i386/kernel/smpboot.c
--- a/arch/i386/kernel/smpboot.c 2002-12-16 03:07:56.000000000 +0100
+++ b/arch/i386/kernel/smpboot.c 2002-12-18 16:53:12.000000000 +0100
@@ -1202,6 +1202,9 @@
void __init smp_cpus_done(unsigned int max_cpus)
{
zap_low_mappings();
+#ifdef CONFIG_NUMA
+ build_node_data();
+#endif
I think it would be much nicer if you had a proper stub for !CONFIG_NUMA..
@@ -20,6 +20,7 @@
#include <asm/mmu.h>
#include <linux/smp.h>
+#include <asm/topology.h>
Another header in sched.h?? And it doesn't look like it's used at all.
#include <linux/sem.h>
#include <linux/signal.h>
#include <linux/securebits.h>
@@ -446,6 +447,9 @@
# define set_cpus_allowed(p, new_mask) do { } while (0)
#endif
+#ifdef CONFIG_NUMA
+extern void build_node_data(void);
+#endif
The ifdef is superflous.
diff -urN a/kernel/sched.c b/kernel/sched.c
--- a/kernel/sched.c 2002-12-16 03:08:14.000000000 +0100
+++ b/kernel/sched.c 2002-12-18 16:53:13.000000000 +0100
@@ -158,6 +158,10 @@
struct list_head migration_queue;
atomic_t nr_iowait;
+
+ unsigned long wait_time;
+ int wait_node;
+
Here OTOH a #if CONFIG_MUA could help to avoid a little bit of bloat.
} ____cacheline_aligned;
+#define cpu_to_node(cpu) __cpu_to_node(cpu)
I wonder why we don't have a proper cpu_to_node() yet, but as long
as it doesn't exist please use __cpu_to_node() directly.
+#define LOADSCALE 128
Any explanation?
+#ifdef CONFIG_NUMA
sched.c uses #if CONFIG_FOO, not #ifdef CONFIG_FOO, it would be cool
if you could follow the style of existing source files.
+/* Number of CPUs per node: sane values until all CPUs are up */
+int _node_nr_cpus[MAX_NUMNODES] = { [0 ... MAX_NUMNODES-1] = NR_CPUS };
+int node_ptr[MAX_NUMNODES+1]; /* first cpu of node (logical cpus are sorted!)*/
+#define node_ncpus(node) _node_nr_cpus[node]
Parametrized macros and variables aren't in the ßame namespace, what about
just node_nr_cpus for the macro, too. And should these be static?
+
+#define NODE_DELAY_IDLE (1*HZ/1000)
+#define NODE_DELAY_BUSY (20*HZ/1000)
Comments, please..
+/* the following macro implies that logical CPUs are sorted by node number */
+#define loop_over_node(cpu,node) \
+ for(cpu=node_ptr[node]; cpu<node_ptr[node+1]; cpu++)
Move to asm/topology.h?
+ ptr=0;
+ for (n=0; n<numnodes; n++) {
You need to add lots of space to match Documentation/odingStyle.. :)
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ if (!cpu_online(cpu)) continue;
And linebreaks..
Btw, what about a for_each_cpu that has the cpu_online check in topology.h?
+ /* Wait longer before stealing if own node's load is average. */
+ if (NODES_BALANCED(avg_load,nd[this_node].average_load))
Shouldn't NODES_BALANCED shout less and be an inline called nodes_balanced?
+ this_rq->wait_node = busiest_node;
+ this_rq->wait_time = jiffies;
+ goto out;
+ } else
+ /* old most loaded node: check if waited enough */
+ if (jiffies - this_rq->wait_time < steal_delay)
+ goto out;
That indentation looks really strange, why not just
/* old most loaded node: check if waited enough */
} else if (jiffies - this_rq->wait_time < steal_delay)
goto out;
+
+ if ((!CPUS_BALANCED(nd[busiest_node].busiest_cpu_load,*nr_running))) {
Dito, the name shouts a bit too much
+#endif
#endif /* CONFIG_NUMA */
-#define BUSY_REBALANCE_TICK (HZ/4 ?: 1)
+#define BUSY_REBALANCE_TICK (HZ/5 ?: 1)
And explanation why you changed that constant?
p = req->task;
- cpu_dest = __ffs(p->cpus_allowed);
+ cpu_dest = __ffs(p->cpus_allowed & cpu_online_map);
+
This looks like a bugfix valid without the rest of the patch.
^ permalink raw reply
* Re: Dell OEM Soundblaster Live 5.1 with different PCI ID
From: Takashi Iwai @ 2002-12-20 15:02 UTC (permalink / raw)
To: Jeff Ridenour; +Cc: alsa-devel
In-Reply-To: <72DB76FA-13CC-11D7-9D7F-0050E4E6A73C@ics.uci.edu>
At Thu, 19 Dec 2002 19:38:05 -0800,
Jeff Ridenour wrote:
>
> Just as an update, when I try to use aplay to play a sound, I get this
> error:
>
> [root@beall-dell-01 sounds]# aplay phone.wav
> Playing WAVE 'phone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
> Stereo
> aplay: pcm_write:999: write error: Input/output error
> [root@beall-dell-01 sounds]#
this is likely an interrupt problem.
if you set "pnp os" to yes on the bios, try to set it to "no".
but even without interrupts, you should be able to hear CDs.
this is a mixer mis-configuration in most cases.
you'll need to adjust the volume of "Line Playback" and unmute it.
in addition, the volume of "AC97 Playback" must be adjusted and
unmuted.
of course, "PCM" and "Master" must be adjusted and unmuted, too.
to hear WAV, "Wave" must be adjusted and unmuted, too.
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Jon Tollefson @ 2002-12-20 15:09 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Hanna Linder, Eli Carter, Randy.Dunlap, linux-kernel
In-Reply-To: <56310000.1040350825@flay>
On Thu, 2002-12-19 at 20:20, Martin J. Bligh wrote:
> >> Anything in "OPEN" state isn't really assigned to anyone yet.
> >> (the state would really better be named "NEW", but it's not).
> >> People should move it to "ASSIGNED" if they're working on it.
> >
> > So the process is to query for all open bugs (but not
> > assigned) then email each person to let them know you are
> > working on it?
>
> Sounds about right. If we had processes ;-)
>
> >> Go to file a new bug, click on the link by the subcategories, and it'll
> >> tell you (you'll have to pick the main category first).
> >
> > That is convoluted. You have to file a bug to find out who
> > the subsystem maintainers are? Can you put it somewhere more
> > obvious?
>
> Well, you don't have to file one, you just pretend to. But it's
> not nice, I agree. Jon, is there an easier way to do this, and get
> all the information in one shot?
>
> M.
>
>
>
There is also a link to it on the query page - the Components label.
Basically its a link to
http://bugzilla.kernel.org/describecomponents.cgi
We could put a link to it on the main page or elsewhere too if that
would be more convenient. It would be easy enough to write a page to
show all the component owners in one shot too if desired.
Jon
^ permalink raw reply
* Re: 2.4.20 AGP for I845 wrong ?
From: Margit Schubert-While @ 2002-12-20 15:09 UTC (permalink / raw)
To: linux-kernel
DJ et al. I thought this had been cleared up on Dec 10 in this thread -
http://marc.theaimsgroup.com/?l=linux-kernel&m=103954588016915&w=2
Margit
^ permalink raw reply
* RE: Walnut configuration (old problem)
From: Allen Curtis @ 2002-12-20 14:59 UTC (permalink / raw)
To: llandre, linuxppc-embedded
In-Reply-To: <5.1.1.6.0.20021220132028.02337438@dns.struinfo.it>
> I've just start working with the Walnut board. I downloaded:
> 1) linuxppc_2_4 with rsync
> 2) linuxppc_2_4_devel with rsync
> 3) linuxppc_2_4_devel with bk
>
make ARCH=ppc walnut_config
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Problems with CONFIG_PREEMPT
From: Colin.Helliwell @ 2002-12-20 14:51 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips, rml
Think I'm ok with respect to interrupt handling, but what does making
globals "safe or taken care of" consist of?
Jun Sun
<jsun@mvista.com> To: Colin.Helliwell@Zarlink.Com
cc: linux-mips@linux-mips.org, rml@mvista.com, jsun@mvista.com
19-Dec-2002 05:59 Subject: Re: Problems with CONFIG_PREEMPT
PM
On Thu, Dec 19, 2002 at 09:10:40AM +0000, Colin.Helliwell@Zarlink.Com
wrote:
>
> Thanks for the patch, but unfortunately the problem is still the same.
If the problem happens very soon after you boot up, there is something
*obviously* wrong. The most common problem is that you have an interupt
handling path not going through standard do_IRQ(). Then you need to
do similar treatment like those in ll_timer_interrupt().
The second thing is to look for any *new* global variables you may
introduce in your kernel. Most of current global variables are either
safe or taken care of (Although another update patch will come out
today or tomorrow to really close the final hole we have).
> I'm
> not sure whether it occurs as a result of interrupts, or just after a
> certain amount of scheduler 'activity' as it sits there copying the
initrd
> into ram disk. A few interrupts are enabled, but its only the MIPS timer
> which should be generating any interrupts at that point (I'll check that,
> in case its relevant).
FYI, I have mips kernel with initrd running just fine with preemptible
kernel.
In fact, it has passed some very stressful tests with initrd.
> I presume the change from "sti()" to "__sti()" was a semantic (or SMP)
> thing, since the former is #defined to the latter anyway? Please note
also
> the following modification which was required to 2.4.19:
>
This is true. Since our kernel had synchronize_irq() added long time ago,
I probably forgot about it when I created the pre-k patch.
Jun
^ permalink raw reply
* Copying an audio CD
From: Paulo Jorge O. C. Matos @ 2002-12-20 14:49 UTC (permalink / raw)
To: linux-newbie
Hi all,
What's the best way to copy an audio cd under Linux? Is it possible with
cdrecord? what do I need?
Best regards,
--
Paulo J. Matos : pocm(_at_)mega.ist.utl.pt
Instituto Superior Tecnico - Lisbon WISHING YOU A MERRY
Software & Computer Engineering - A.I. CHRISTMAS, AND A GREAT
- > http://mega.ist.utl.pt/~pocm 2003!!!
---
Yes, God had a deadline...
So, He wrote it all in Lisp!
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Linux 2.4.21-pre2
From: Christoph Hellwig @ 2002-12-20 14:57 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Marcelo Tosatti, Ben Collins, lkml, linux1394-devel
In-Reply-To: <20021220144808.GF27658@fs.tum.de>
On Fri, Dec 20, 2002 at 03:48:08PM +0100, Adrian Bunk wrote:
> On Wed, Dec 18, 2002 at 05:22:50PM -0200, Marcelo Tosatti wrote:
>
> >...
> > Summary of changes from v2.4.21-pre1 to v2.4.21-pre2
> > ============================================
> >...
> > Ben Collins <bcollins@debian.org>:
> > o Linux1394 Firewire
> >...
>
> The changes to drivers/ieee1394/Makefile broke the compilation at least
> when compiling the ieee1394 code statically into the kernel:
Just revert the drivers/ieee1394/Makefile changes, they're bogus.
^ permalink raw reply
* Re: buggy scsi_register behaviour in 2.5.51
From: Willem Riede @ 2002-12-20 14:46 UTC (permalink / raw)
To: dougg; +Cc: linux-scsi
In-Reply-To: <3E006692.7020503@torque.net>
On 2002.12.18 07:14 Douglas Gilbert wrote:
>
> These are documented in Documentation/scsi/scsi_mid_low_api.txt .
> If you find mistakes or the explanation is not clear then
> complain to me.
Your doc doesn't define the second parameter to scsi_add_host.
Can you explain what the purpose is of the struct device *dev
and how I'm supposed to pull one out of my hat in __init?
I notice that the old style registration doesn't bother with
shost->host_gendev.
Thanks, Willem Riede.
^ permalink raw reply
* Re: [PATCH] joydev: fix HZ->millisecond transformation
From: Joe Korty @ 2002-12-20 14:52 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: george anzinger, Bjorn Helgaas, Marcelo Tosatti, linux-kernel
In-Reply-To: <20021220142443.A26184@ucw.cz>
[ repost -- I am going to have to get outgoing mail fixed on my lkml-reading
machine ]
> On Fri, Dec 20, 2002 at 02:41:50AM -0800, george anzinger wrote:
>> Bjorn Helgaas wrote:
>>>
>>> * fix a problem with HZ->millisecond transformation on
>>> non-x86 archs (from 2.5 change by vojtech@suse.cz)
>>> [...]
>>> +#define MSECS(t) (1000 * ((t) / HZ) + 1000 * ((t) % HZ) / HZ)
>>> [...]
> Though it might be easier to say (1000 * t) / HZ, now that I think about
> it.
The more complex version avoids integer overflow for more values of 't'
in the (1000 * t) subexpression.
Joe
^ permalink raw reply
* Re: [PATCH]: for poor sools with old I2 & 64 bits kernel
From: Juan Quintela @ 2002-12-20 14:48 UTC (permalink / raw)
To: Ralf Baechle; +Cc: mipslist
In-Reply-To: <20021220034450.A21950@linux-mips.org>
>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:
ralf> On Thu, Dec 19, 2002 at 09:04:12PM +0100, Juan Quintela wrote:
>> this small patch made possible to compile a 64bit kernel for
>> people that have old proms that only accept ecoff. As usual
>> stolen from the 32 bits version.
>>
>> The easiest way is creating the file in arch/mips/boot,
>> otherwise we need to copy elf2ecoff.c to mips64.
ralf> Applied slightly modified. I removed two other unused targets.
Please, add that back, and things will indeed compile :)
Later, Juan.
Index: arch/mips64/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips64/Makefile,v
retrieving revision 1.22.2.21
diff -u -r1.22.2.21 Makefile
--- arch/mips64/Makefile 20 Dec 2002 02:42:26 -0000 1.22.2.21
+++ arch/mips64/Makefile 20 Dec 2002 14:37:18 -0000
@@ -235,7 +235,7 @@
CORE_FILES := arch/mips64/kernel/kernel.o arch/mips64/mm/mm.o $(CORE_FILES)
LIBS := arch/mips64/lib/lib.a $(LIBS)
-MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot
+MAKEBOOT = $(MAKE) -C arch/mips/boot
ifdef CONFIG_CPU_LITTLE_ENDIAN
64bit-bfd = elf64-tradlittlemips
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [PATCH 2.5.52] NUMA scheduler: cputimes stats
From: Erich Focht @ 2002-12-20 14:49 UTC (permalink / raw)
To: Martin J. Bligh, Michael Hohnbaum
Cc: Robert Love, Ingo Molnar, Stephen Hemminger, linux-kernel
In-Reply-To: <200212181721.39434.efocht@ess.nec.de>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
The attached patch is needed for evaluating and understanding
scheduler and load balancer activity. It adds back to the kernel per
CPU user and system time statistics for each process in /proc/PID/cpu,
a feature which was around for ages and went lost in 2.5.50.
Regards,
Erich
On Wednesday 18 December 2002 17:21, Erich Focht wrote:
> This is the first part of the minimal NUMA scheduler built on top of
> the O(1) load balancer. It is rediffed for 2.5.52 and contains a small
> bugfix in build_node_data().
>
> The two patches are:
>
> 01-numa-sched-core-2.5.52-23.patch: core NUMA scheduler infrastructure
> providing a node aware load_balancer.
>
> 02-numa-sched-ilb-2.5.52-21.patch: initial load balancing, selects
> least loaded node & CPU at exec().
>
> Regards,
> Erich
[-- Attachment #2: 03-cputimes_stat-2.5.52.patch --]
[-- Type: text/x-diff, Size: 3316 bytes --]
diff -urN a/fs/proc/array.c b/fs/proc/array.c
--- a/fs/proc/array.c 2002-12-16 03:08:11.000000000 +0100
+++ b/fs/proc/array.c 2002-12-20 15:40:41.000000000 +0100
@@ -597,3 +597,26 @@
out:
return retval;
}
+
+#ifdef CONFIG_SMP
+int proc_pid_cpu(struct task_struct *task, char * buffer)
+{
+ int i, len;
+
+ len = sprintf(buffer,
+ "cpu %lu %lu\n",
+ jiffies_to_clock_t(task->utime),
+ jiffies_to_clock_t(task->stime));
+
+ for (i = 0 ; i < NR_CPUS; i++) {
+ if (cpu_online(i))
+ len += sprintf(buffer + len, "cpu%d %lu %lu\n",
+ i,
+ jiffies_to_clock_t(task->per_cpu_utime[i]),
+ jiffies_to_clock_t(task->per_cpu_stime[i]));
+
+ }
+ len += sprintf(buffer + len, "current_cpu %d\n",task_cpu(task));
+ return len;
+}
+#endif
diff -urN a/fs/proc/base.c b/fs/proc/base.c
--- a/fs/proc/base.c 2002-12-16 03:08:11.000000000 +0100
+++ b/fs/proc/base.c 2002-12-20 15:40:42.000000000 +0100
@@ -55,6 +55,7 @@
PROC_PID_STAT,
PROC_PID_STATM,
PROC_PID_MAPS,
+ PROC_PID_CPU,
PROC_PID_MOUNTS,
PROC_PID_WCHAN,
PROC_PID_FD_DIR = 0x8000, /* 0x8000-0xffff */
@@ -75,6 +76,9 @@
E(PROC_PID_CMDLINE, "cmdline", S_IFREG|S_IRUGO),
E(PROC_PID_STAT, "stat", S_IFREG|S_IRUGO),
E(PROC_PID_STATM, "statm", S_IFREG|S_IRUGO),
+#ifdef CONFIG_SMP
+ E(PROC_PID_CPU, "cpu", S_IFREG|S_IRUGO),
+#endif
E(PROC_PID_MAPS, "maps", S_IFREG|S_IRUGO),
E(PROC_PID_MEM, "mem", S_IFREG|S_IRUSR|S_IWUSR),
E(PROC_PID_CWD, "cwd", S_IFLNK|S_IRWXUGO),
@@ -1026,7 +1030,12 @@
case PROC_PID_MAPS:
inode->i_fop = &proc_maps_operations;
break;
-
+#ifdef CONFIG_SMP
+ case PROC_PID_CPU:
+ inode->i_fop = &proc_info_file_operations;
+ ei->op.proc_read = proc_pid_cpu;
+ break;
+#endif
case PROC_PID_MEM:
inode->i_op = &proc_mem_inode_operations;
inode->i_fop = &proc_mem_operations;
diff -urN a/include/linux/sched.h b/include/linux/sched.h
--- a/include/linux/sched.h 2002-12-18 16:54:40.000000000 +0100
+++ b/include/linux/sched.h 2002-12-20 15:40:42.000000000 +0100
@@ -354,6 +354,9 @@
struct timer_list real_timer;
unsigned long utime, stime, cutime, cstime;
unsigned long start_time;
+#ifdef CONFIG_SMP
+ long per_cpu_utime[NR_CPUS], per_cpu_stime[NR_CPUS];
+#endif
/* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */
unsigned long min_flt, maj_flt, nswap, cmin_flt, cmaj_flt, cnswap;
int swappable:1;
diff -urN a/kernel/fork.c b/kernel/fork.c
--- a/kernel/fork.c 2002-12-16 03:07:44.000000000 +0100
+++ b/kernel/fork.c 2002-12-20 15:40:42.000000000 +0100
@@ -795,6 +795,14 @@
p->tty_old_pgrp = 0;
p->utime = p->stime = 0;
p->cutime = p->cstime = 0;
+#ifdef CONFIG_SMP
+ {
+ int i;
+
+ for(i = 0; i < NR_CPUS; i++)
+ p->per_cpu_utime[i] = p->per_cpu_stime[i] = 0;
+ }
+#endif
p->array = NULL;
p->lock_depth = -1; /* -1 = no lock */
p->start_time = jiffies;
diff -urN a/kernel/timer.c b/kernel/timer.c
--- a/kernel/timer.c 2002-12-16 03:07:52.000000000 +0100
+++ b/kernel/timer.c 2002-12-20 15:40:42.000000000 +0100
@@ -695,6 +695,10 @@
void update_one_process(struct task_struct *p, unsigned long user,
unsigned long system, int cpu)
{
+#ifdef CONFIG_SMP
+ p->per_cpu_utime[cpu] += user;
+ p->per_cpu_stime[cpu] += system;
+#endif
do_process_times(p, user, system);
do_it_virt(p, user);
do_it_prof(p);
^ permalink raw reply
* Re: Linux 2.4.21-pre2
From: Adrian Bunk @ 2002-12-20 14:48 UTC (permalink / raw)
To: Marcelo Tosatti, Ben Collins; +Cc: lkml, linux1394-devel
In-Reply-To: <Pine.LNX.4.50L.0212181721340.18764-100000@freak.distro.conectiva>
On Wed, Dec 18, 2002 at 05:22:50PM -0200, Marcelo Tosatti wrote:
>...
> Summary of changes from v2.4.21-pre1 to v2.4.21-pre2
> ============================================
>...
> Ben Collins <bcollins@debian.org>:
> o Linux1394 Firewire
>...
The changes to drivers/ieee1394/Makefile broke the compilation at least
when compiling the ieee1394 code statically into the kernel:
1. Nothing gets built in drivers/ieee1394.
2. The final linking fails with the following error:
<-- snip -->
...
-o vmlinux
ld: cannot open drivers/ieee1394/ieee1394drv.o: No such file or directory
make: *** [vmlinux] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [LARTC] CBQ.init
From: Emmanuel SIMON @ 2002-12-20 14:37 UTC (permalink / raw)
To: lartc
hi all,
i have read about CBQ.init in the howto, your mails etc...
but what is it exactly and where can i find it and some info : i can't
access the link in the howto ... (ftp://ftp.equinox.gu.net/pub/linux/cbq/)
i hope someone can send it to me on my mailbox, but, please, mail me first.
thank you
Emmanuel
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Next round of AGPGART fixes.
From: Felix Seeger @ 2002-12-20 14:42 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
In-Reply-To: <20021220124137.GA28068@suse.de>
Am Freitag 20 Dezember 2002 13:41 schrieb Dave Jones:
> Linus,
> Please pull from bk://linux-dj.bkbits.net/agpgart to get at the
> following fixes..
>
> - AGP 3.0 now compiles as a module too.
> - beginnings of VIA KT400 AGP 3.0 support.
> (Not functional yet, more work needed).
> - corrected handling of AGP capability bit in PCI headers for chipset
> drivers. This should fix the problems on I815 and similar chipsets.
[...]
> Dave
I am running 2.5.52bk5 with you GNU patch. Doesn't help.
I do a modprobe i810 and I get:
FATAL: Error inserting i810
(/lib/modules/2.5.52bk5/kernel/drivers/char/drm/i810.ko): Cannot allocate
memory
This is from dmesg:
[drm:drm_init] *ERROR* Cannot initialize the agpgart module.
Uninitialised timer!
This is just a warning. Your computer is OK
function=0x00000000, data=0x0
Call Trace:
[<c01208a2>] check_timer_failed+0x42/0x50
[<c0120cd7>] del_timer+0x17/0x80
[<c4990dc5>] i810_takedown+0x45/0x3b0 [i810]
[<c49952d6>] i810_stub_unregister+0x36/0x3d [i810]
[<c49720e6>] 0xc49720e6
[<c4997cc0>] +0x840/0x2720 [i810]
[<c4997ca2>] +0x822/0x2720 [i810]
[<c012a782>] sys_init_module+0xfe/0x178
[<c0108d73>] syscall_call+0x7/0xb
thanks
have fun
Felix
^ permalink raw reply
* applications compiled with mips16 ISA
From: Pichai Raghavan @ 2002-12-20 14:24 UTC (permalink / raw)
To: linux-mips
Hi,
Has anyone put MIPS16 based applications on Linux 2.4.2 kernel? We
want to use this to get more flash storage but unaware of the
issues behind this. For ex: how will the loader work; will shared
libraries compiled with MIPS16 work with MIPS32 applications. Can
anyone thow light on this topic or point to us to some relevant
documentation?
Thanks in advance
Raghav
^ permalink raw reply
* Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
From: Roger Larsson @ 2002-12-20 14:27 UTC (permalink / raw)
To: Torben Frey; +Cc: linux-kernel
In-Reply-To: <3E01D7D7.2070201@mailsammler.de>
On Thursday 19 December 2002 15:29, Torben Frey wrote:
> 2 0 4 25292 2292 72056 759548 0 0 30404 20084 820 1149 4 85 11
> 0 1 3 25292 2828 72048 759012 0 0 40716 23772 845 1307 2 62 36
> 0 1 2 25292 3208 72280 758372 0 0 0 16532 573 231 6 13 81
> 1 0 2 25292 3216 72276 758404 0 0 4880 23800 530 264 2 10 88
>
Hmm... No process running but still lots of CPU used.
Are you sure that you run the disks with DMA?
You should also try to take a profile of a run.
(see
man readprofile
and
linux/Documentation/kernel-parameters.txt
profile=2 as a boot option should do)
/RogerL
--
Roger Larsson
Skellefteå
Sweden
^ permalink raw reply
* Re: Are working modules going to be in 2.6?
From: Horst von Brand @ 2002-12-20 14:27 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.3.96.1021219154713.29567A-100000@gatekeeper.tmr.com>
Bill Davidsen <davidsen@tmr.com> said:
> I have downloaded any number of modutil this and init-mod that, built them
> static, rolled my own initrd files, and as far as I can tell it just
> doesn't work with 2.5.48+.
Strange. My setup works fine with initrd, modutils from Rusty and 2.5.50 at
least. I had to redo the mkinitrd step for it to work under RH 8.0, but
that was it.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: BUG: 2.5.52-bk4
From: Colin Slater @ 2002-12-20 14:28 UTC (permalink / raw)
To: Lukas Hejtmanek; +Cc: linux-kernel
> solved that problem. Now it works ok for me.
Do you mean the patch compiles now or that it fixes the problem you
were having?
Colin
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Horst von Brand @ 2002-12-20 14:23 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200212192059.gBJKxFne002827@darkstar.example.net>
John Bradford <john@grabjohn.com> said:
> > And what about GNATS? What about the others on
> > http://www.a-a-p.org/tools_tracking.html ? A number of those address
> > the web-based concern. Do any of them answer your other concerns? If
> > there are, where do those fail that bugzilla, GNATS, etc. get it right?
>
> Why are you so against somebody sitting down and thinking, "OK, we
> need a bug tracking database designed for debugging the Linux
> kernel."?
I didn't see anybody saying that...
> I don't understand why you think it's a bad idea to start
> over. If my code was rubbish, then it wouldn't get used, and I wasted
> my time. Nobody else suffers.
Except for the users who tried it out, and the people who read the ensuing
flamewars ;-)
"Start over" is one thing, "start over as if nothing had been done before"
is another (and a bad idea, whatever you are trying to do).
Linux has borrowed much from Unix, in design and also in avoiding mistakes
made elsewhere. Do follow this example.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* RE: pb compiling cross gcc, binutils, glibc and so on ...
From: James Don @ 2002-12-20 14:12 UTC (permalink / raw)
To: 'Liu Fred-a18596', BREUVART Jean-Charles,
linuxppc-embedded
I was given this script ... it works ;-)
Just match the directory structures ;-)
Maybe it will help ... make sure you have bison,flex,tetex installed ...
Good luck,
Jim
#!/bin/bash
#-------------------------------------------------------------
# This bash script creates a linux x866 gcc cross compiler
# for powerpc. This file has been tested with the following
# modules:
# 1.) binutils-2.13.90.0.2.tar.gz
# 2.) gcc-3.2.tar.gz
# 3.) newlib-synSept12-2002.tar.gz
#-------------------------------------------------------------
# Defining target
TARGET=powerpc-linux
# Defining prefix - final toolchain location
PREFIX=$HOME/ppcgcc
# PATH must updated
PATH=$PREFIX/bin:$PATH
export PATH
# My local includes
INCLUDE=/usr/include/
# Configuring packages versions
GCC_VER=2.95.3
BINUTILS_VER=2.13.90.0.2
NEWLIB_VER=1.10.0
echo ===================================================
echo BUILDING BINUTILS FOR $TARGET
echo ===================================================
# binutils
rm -rf binutils-$BINUTILS_VER binutils
tar zxvf binutils-$BINUTILS_VER.tar.gz
mkdir binutils
cd binutils
../binutils-$BINUTILS_VER/configure --target=$TARGET --prefix=$PREFIX
make all
make install
cd ..
echo ===================================================
echo BUILDING GCC FOR $TARGET
echo ===================================================
echo extract GCC source from tar ball ...
rm -rf gcc-$GCC_VER gcc
tar zxvf gcc-core-$GCC_VER.tar.gz
tar zxvf gcc-g++-$GCC_VER.tar.gz
echo extract newlib source from tar ball- needed for gcc ...
rm -rf newlib-$NEWLIB_VER newlib
tar zxvf newlib-$NEWLIB_VER.tar.gz
echo set up symbolic links to newlib in gcc dir
cd gcc-$GCC_VER
ln -s ../newlib-$NEWLIB_VER/newlib newlib
ln -s ../newlib-$NEWLIB_VER/libgloss libgloss
cd ..
echo build gcc ...
mkdir gcc
cd gcc
../gcc-$GCC_VER/configure --target=$TARGET --with-newlib --prefix=$PREFIX
--with-gnu-as --with-gnu-ld --with-headers=$INCLUDE
make all
make install
cd ..
echo ===================================================
echo BUILDING NEWLIB FOR $TARGET
echo ===================================================
# newlib
mkdir newlib
cd newlib
../newlib-$NEWLIB_VER/configure --target=$TARGET --prefix=$PREFIX --nfp
make all
make install
cd ..
-----Original Message-----
From: Liu Fred-a18596 [mailto:fred.liu@motorola.com]
Sent: Thursday, December 19, 2002 8:58 PM
To: BREUVART Jean-Charles; linuxppc-embedded@lists.linuxppc.org
Subject: RE: pb compiling cross gcc, binutils, glibc and so on ...
> 5. build gcc core 2.95.3 for powerpc cross compile, and install it in
> /opt/powerpc-linux/ :
> - cd /usr/src/gcc-2.95.3/
> - make clean
> - make distclean
> - CC=/usr/local/bin/gcc ./configure --target=powerpc-linux
> --enable-shared --enable-languages=c --with-newlib
> --prefix=/opt/powerpc-linux
> - add /opt/powerpc-linux at the end of $PATH, otherwise
> make doesn't
> find powerpc-linux-as, powerpc-linux-ld and so on
> - make
>
> Here is the trouble :
>
> choose-temp.c:29: stdio.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:30: sys/types.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:32: unistd.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:35: stdlib.h: Aucun fichier ou r?pertoire de ce type
> choose-temp.c:38: sys/file.h: Aucun fichier ou r?pertoire de ce type
>
> there aren't any of those in /opt/powerpc-linux/ or its subdirs
>
It's true that there are no any of those files. They are in glibc which you
have not compiled yet.
Some useful tips at: http://www.mock.com/receiver/tools/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* OKBridgae and nat
From: Juan Nin @ 2002-12-20 14:09 UTC (permalink / raw)
To: netfilter
Hi,
I got the following question:
I have a box that acts as router/firewall
Behind it, I have serveral private networks
I used masquerading via ipchains, and now I upgraded the box and I'm using
nat via iptables
A customeruses a game for playing Bridge card game via internet which is
called OKBridge
When using ipchains I had the following rules to make it work:
ipchains -M -S 7200 0 0
ipmasqadm autofw -A -r tcp 1729 1729 -h xxx.xxx.xxx.xxx
being xxx.xxx.xxx.xxx the IP of this customer's machine
now.. with iptables..
do I have to issue any rule to make it work, or iptables mangles it by
itself and it's not necessary to do anything??
thanks in advance,
Juan
^ permalink raw reply
* [Fwd: ACCEPT/DROP]
From: Venkatesh Prasad Ranganath @ 2002-12-20 13:54 UTC (permalink / raw)
To: netfilter-devel
Hi,
I was looking into the iptables implementation and was intrigued about
how iptables would handle a situation in which we have identical rules
except for their targets which are contradicting, say ACCEPT and DROP.
By looking at ipt_do_table() function it seems that the first
non-IPT_RETURN verdict from any standard target will end the traversal
of a chain of a table, which seems to be a bit odd. First, such
conflicting rules must not be allowed. Even beyond, this fails in the
situation where you have a dropping rule added after an accepting rule.
For example, a packet from m.n.o.p to a.b.c.d would be accepted at
a.b.c.d because of the first rule, although it had to be dropped
according to the second rule. And this would result because of the
order in which the rules are added to the table.
iptables -A INPUT -d a.b.c.d -j ACCEPT
iptables -A INPUT -s m.n.o.p -j DROP
Is my understanding correct? If so, I am curious to know how nf-hipac
behaves in such situations?
waiting for reply,
--
Venkatesh Prasad Ranganath,
Dept. Computing and Information Science,
Kansas State University, US.
web: http://www.cis.ksu.edu/~rvprasad
^ permalink raw reply
* Re: mmap problem with personnal code driver
From: Xavier Grave @ 2002-12-20 13:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200212191610.RAA21095@ipnmail.in2p3.fr>
Now that I have reduced the number of thing in my crate (CPU + vme analyser)
I can see that my driver works fine, no more mmap problem.
Sorry for the disturbance...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [LARTC] CBQ rate question
From: René Serral @ 2002-12-20 13:45 UTC (permalink / raw)
To: lartc
In the IST-LONG project (http://www.ist-long.com) we are using TC to make our
QoS IPv6 experiments and we have one question, in CBQ, how the "rate" is
calculated? I mean, when I write "...rate 200000 bps...", this 200Kbps are
level-3 bits per second, or they include level-2 bits....
Thanks in advance.
--
---------------------------------------------------------------
René Serral Universitat Politècnica de Catalunya
rserral@ac.upc.es
UPC Campus Nord, Ed. D4 Tel: +34 934 017 432
Barcelona 08034
---------------------------------------------------------------
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ 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.