* Re: [Qemu-devel] ./configure --help and gcc checks
From: Kevin F. Quinn @ 2006-04-06 22:59 UTC (permalink / raw)
To: qemu-devel; +Cc: spetreolle
In-Reply-To: <20060406123330.44792.qmail@web26804.mail.ukl.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
On Thu, 6 Apr 2006 14:33:30 +0200 (CEST)
Sylvain Petreolle <spetreolle@yahoo.fr> wrote:
> Hi people,
> I have gcc 3.2.3 (run as gcc32) and gcc 4.1.0.
>
> ./configure --help runs the gcc check, thus displaying the following
> error : ERROR: "gcc" looks like gcc 4.x
>
> IMHO this should be changed to avoid running things like this :
> ./configure --cc=gcc32 --help
I see what you mean now :)
It would enough to just move the gcc check in the configure script to
after the help processing.
--
Kevin F. Quinn
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Lee Revell @ 2006-04-06 22:57 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144362544.9219.14.camel@localhost.localdomain>
On Thu, 2006-04-06 at 23:29 +0100, Adrian McMenamin wrote:
> I know that aica isn't in there - but the general build should still
> work and it doesn't...
Nope - I just tested it by removing the Makefile and running ./configure
with a made up card and it does not generate a new Makefile. So it must
be using an old one with incorrect kernel source locations.
Lee
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [U-Boot-Users] ppc4xx: Initializing GPIO0_OR and GPIO0_ODR
From: Tolunay Orkun @ 2006-04-06 23:00 UTC (permalink / raw)
To: u-boot
(Note: This is specific to PPC405EP but it might be applicable to other
4xx cpus)
On a PPC405EP based boards, U-Boot is initializing below registers to
select between primary and alternate functions of the GPIO pins (e.g.
GPIO10 vs CS1) using the CFG_CPIO0_... macros defined in the board
config file.
GPIO0_TCR, GPIO0_OSRH, GPIO0_OSRL, GPIO0_TSRH, GPIO0_TSRL, GPIO0_ISR1H,
GPIO0_ ISR1L
This much is sufficient for alternate function programming. However, if
a the GPIO pin is actually used as GPIO output pin, the initial signal
level presented happens to be "0" which may not be appropriate for some
implementations.
I propose to introduce CFG_GPIO0_OR and CFG_CPIO0_ODR macros that could
be defined in the appropriate board config file and initialize GPIO0_OR
and GPIO0_ODR before GPIO0_TCR. If these macros are undefined the
existing code behavior could be maintained so the additional macros
would not break any existing board or add any additional code.
I will be introducing a patch to take care of this but I wanted to get
feedback first.
FYI: For our board, we have a GPIO line connected to an active low reset
line of a custom ASIC chip. There is a pull-up so during the time while
this pin is tri-state/input we should not reset the ASIC automatically
while management processor is booting. Our ASIC can operate
independently while the management processor is booting.
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Eric W. Biederman @ 2006-04-06 22:58 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20060406220403.GA205@oleg>
Oleg Nesterov <oleg@tv-sign.ru> writes:
> On top of
> task-make-task-list-manipulations-rcu-safe.patch
>
> This patch
> pidhash-kill-switch_exec_pids.patch
>
> changed de_thread() so that it doesn't remove 'leader' from it's thread group.
> However de_thread() still adds current to init_task.tasks without removing
> 'leader' from this list. What if another CLONE_VM task starts do_coredump()
> after de_thread() drops tasklist_lock but before it calls release_task(leader) ?
>
> do_coredump()->zap_threads() will find this thread group twice on
> init_task.tasks
> list. And it will increment mm->core_waiters twice for the new leader (current
> in
> de_thread). So, exit_mm()->complete(mm->core_startup_done) doesn't happen, and
> we
> have a deadlock.
Ack. The evils of de_thread!
We need this to keep from seeing the same task twice in
do_each_thread.
This bug is in 2.6.17-rc1 so this code needs to go to Linus
sometime soon.
Eric
> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
>
> --- MM/fs/exec.c~0_DET 2006-04-06 22:37:33.000000000 +0400
> +++ MM/fs/exec.c 2006-04-06 22:51:51.000000000 +0400
> @@ -713,7 +713,7 @@ static int de_thread(struct task_struct
> attach_pid(current, PIDTYPE_PID, current->pid);
> attach_pid(current, PIDTYPE_PGID, current->signal->pgrp);
> attach_pid(current, PIDTYPE_SID, current->signal->session);
> - list_add_tail_rcu(¤t->tasks, &init_task.tasks);
> + list_replace_rcu(&leader->tasks, ¤t->tasks);
>
> current->parent = current->real_parent = leader->real_parent;
> leader->parent = leader->real_parent = child_reaper;
> --- MM/kernel/exit.c~0_DET 2006-03-23 23:02:53.000000000 +0300
> +++ MM/kernel/exit.c 2006-04-06 23:01:37.000000000 +0400
> @@ -55,7 +55,9 @@ static void __unhash_process(struct task
> detach_pid(p, PIDTYPE_PGID);
> detach_pid(p, PIDTYPE_SID);
>
> - list_del_rcu(&p->tasks);
> + /* see de_thread()->list_replace_rcu() */
> + if (likely(p->tasks.prev != LIST_POISON2))
> + list_del_rcu(&p->tasks);
> __get_cpu_var(process_counts)--;
> }
> list_del_rcu(&p->thread_group);
^ permalink raw reply
* Re: RT task scheduling
From: Peter Williams @ 2006-04-06 23:02 UTC (permalink / raw)
To: Darren Hart
Cc: linux-kernel, Ingo Molnar, Thomas Gleixner, Stultz, John,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604061024.35300.darren@dvhart.com>
Darren Hart wrote:
> On Wednesday 05 April 2006 21:19, Peter Williams wrote:
>> Darren Hart wrote:
>>> My last mail specifically addresses preempt-rt, but I'd like to know
>>> people's thoughts regarding this issue in the mainline kernel. Please
>>> see my previous post "realtime-preempt scheduling - rt_overload behavior"
>>> for a testcase that produces unpredictable scheduling results.
>>>
>>> Part of the issue here is to define what we consider "correct behavior"
>>> for SCHED_FIFO realtime tasks. Do we (A) need to strive for "strict
>>> realtime priority scheduling" where the NR_CPUS highest priority runnable
>>> SCHED_FIFO tasks are _always_ running? Or do we (B) take the best effort
>>> approach with an upper limit RT priority imbalances, where an imbalance
>>> may occur (say at wakeup or exit) but will be remedied within 1 tick.
>>> The smpnice patches improve load balancing, but don't provide (A).
>>>
>>> More details in the previous mail...
>> I'm currently researching some ideas to improve smpnice that may help in
>> this situation. The basic idea is that as well as trying to equally
>> distribute the weighted load among the groups/queues we should also try
>> to achieve equal "average load per task" for each group/queue. (As well
>> as helping with problems such as yours, this will help to restore the
>> "equal distribution of nr_running" amongst groups/queues aim that is
>> implicit without smpnice due to the fact that load is just a smoothed
>> version of nr_running.)
>
> Can you elaborate on what you mean by "average load per task" ?
It's the total weighted load on a run group/queue divided by the
nr_running for that group/queue. If this is equal for all groups/queues
and the total weighted load for them are also equal then the
distribution of priorities in each group/queue should be similar and
this will give a high probability that (for an N CPU system) the N
highest priority tasks will be on different CPUs and hence the highest
priority task on their CPU. But these are just tendencies not
guarantees as it's a statistical process not a deterministic one.
>
> Also, since smpnice is (correct me if I am wrong) load_balancing, I don't
> think it will prevent the problem from happening, but rather fix it when it
> does. If we want to prevent it from happening, I think we need to do
> something like the rt_overload code from the RT patchset.
I agree. Changes to smpnice (as described above) would help with this
problem (i.e. they'll make the distribution of tasks TEND towards the
desired state) but would not provide the necessary determinism. I think
special measures (such as rt_overload) are required if you want determinism.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: [PATCH] Allow menuconfig to cycle through choices
From: Randy.Dunlap @ 2006-04-06 23:04 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: jcrigby, zippel, sam, linux-kernel
In-Reply-To: <20060406154040.c5430029.rdunlap@xenotime.net>
On Thu, 6 Apr 2006 15:40:40 -0700 Randy.Dunlap wrote:
> On Thu, 6 Apr 2006 14:58:34 -0600 John Rigby wrote:
>
> >
> >
> Subject: [PATCH] Allow menuconfig to cycle through choices
>
> Added cycling logic to dialog_checklist identical to what
> dialog_menu already has.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Hi,
> Can you give an example of a checklist (aka radiolist in menuconfig)
> where this change has an effect?
>
> I expected Timer frequency (choosing between 100, 250, 1000 HZ) to
> cycle, but it does not. And I expected Default I/O scheduler
> to cycle, but it does not. So where can I look for a change
> after applying this patch?
Ah, I see, it cycles on the Select / Exit / Help choices, e.g,
---
~Randy
^ permalink raw reply
* [U-Boot-Users] Re: Compiled system and target board mismatched while make U-boot image..
From: Wolfgang Denk @ 2006-04-06 23:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <44357A9C.8010907@corelatus.se>
In message <44357A9C.8010907@corelatus.se> you wrote:
>
> This is not a dbau1550 question IMHO. It is an endian question for mips
> platforms and I am not qualified to determine if it is correct or not.
> I use big endian and ELDK ;-)
>
> Wolfgang?
Yessir!! I'm here at work. What's up?
Ummm... What shall I say? ELDK for MIPS supports both LE and BE
configurations, and both work just fine, except for the fact that the
dbau1x00 port produces warnings because it is broken as it uses a
definition of HZ which is not 1000:
-> export CROSS_COMPILE=mips_4KC-
-> ./MAKEALL dbau1550
Configuring for dbau1x00 board...
net.c: In function `NetStartAgain':
net.c:597: warning: integer overflow in expression
xyzModem.c: In function `xyzModem_stream_open':
xyzModem.c:455: warning: unused variable `console_chan'
text data bss dec hex filename
127896 4548 22864 155308 25eac u-boot
-> export CROSS_COMPILE=mips_4KCle-
-> ./MAKEALL dbau1550_el
Configuring for dbau1x00 board...
net.c: In function `NetStartAgain':
net.c:597: warning: integer overflow in expression
xyzModem.c: In function `xyzModem_stream_open':
xyzModem.c:455: warning: unused variable `console_chan'
text data bss dec hex filename
130072 4548 22864 157484 2672c u-boot
IMHO it's clearly a toolchain problem, but who am I to know such things?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We fight only when there is no other choice. We prefer the ways of
peaceful contact.
-- Kirk, "Spectre of the Gun", stardate 4385.3
^ permalink raw reply
* Re: RT task scheduling
From: Peter Williams @ 2006-04-06 23:06 UTC (permalink / raw)
To: Ingo Molnar
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060406073753.GA18349@elte.hu>
Ingo Molnar wrote:
> * Darren Hart <darren@dvhart.com> wrote:
>
>> My last mail specifically addresses preempt-rt, but I'd like to know
>> people's thoughts regarding this issue in the mainline kernel. Please
>> see my previous post "realtime-preempt scheduling - rt_overload
>> behavior" for a testcase that produces unpredictable scheduling
>> results.
>
> the rt_overload feature i intend to push upstream-wards too, i just
> didnt separate it out of -rt yet.
>
> "RT overload scheduling" is a totally orthogonal mechanism to the SMP
> load-balancer (and this includes smpnice too) that is more or less
> equivalent to having a 'global runqueue' for real-time tasks, without
> the SMP overhead associated with that. If there is no "RT overload" [the
> common case even on Linux systems that _do_ make use of RT tasks
> occasionally], the new mechanism is totally inactive and there's no
> overhead. But once there are more RT tasks than CPUs, the scheduler will
> do "global" decisions for what RT tasks to run on which CPU. To put even
> less overhead on the mainstream kernel, i plan to introduce a new
> SCHED_FIFO_GLOBAL scheduling policy to trigger this behavior. [it doesnt
> make much sense to extend SCHED_RR in that direction.]
>
> my gut feeling is that it would be wrong to integrate this feature into
> smpnice: SCHED_FIFO is about determinism, and smpnice is a fundamentally
> statistical approach. Also, smpnice doesnt have to try as hard to pick
> the right task as rt_overload does, so there would be constant
> 'friction' between "overhead" optimizations (dont be over-eager) and
> "latency" optimizations (dont be _under_-eager). So i'm quite sure we
> want this feature separate. [nevertheless i'd happy to be proven wrong
> via some good and working smpnice based solution]
I was thinking about this over night and came to similar conclusions.
I.e. for RT tasks it's really a problem of selecting the right CPU at
wake up time rather than a general load balancing problem. The solution
that I thought of was different (though) and involved modifying
wake_idle() so that when the woken task was high priority as well as
looking for idle CPUs it looked for the one with the lowest priority
current task and if it couldn't find an idle CPU it returned the one
with the lowest priority current task. The aim was to maximize the
probability that the newly woken task went straight onto a CPU (either
by finding an idle one or preemption).
Although aimed at this specific problem, this solution would also help
smpnice to attain equal "average load per task" values for groups/queues
which I think is a desirable secondary aim to equatable distribution of
weighted load. If both of these aims are met I think a natural outcome
would be that the highest priority tasks are well distributed among the
CPUs (but, as you imply, this would be a statistical trend rather than
an deterministic).
In summary, I think that smpnice can be modified in ways that will help
with this problem but if you need determinism then special measures are
probably necessary.
Peter
---
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-06 23:07 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 01:07 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-07-06 01:07
----------------------------------------------------------------------
This seems to be a kudzu bug. It's loading the wrong driver. I don't see
any Intel HDA device on your system.
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 70)
This should be using the snd-via82xx driver
02:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio
Controller
Not sure what this is. lspci -vn output?
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Adrian McMenamin @ 2006-04-06 23:10 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144364276.12038.31.camel@mindpipe>
On Thu, 2006-04-06 at 18:57 -0400, Lee Revell wrote:
> On Thu, 2006-04-06 at 23:29 +0100, Adrian McMenamin wrote:
> > I know that aica isn't in there - but the general build should still
> > work and it doesn't...
>
> Nope - I just tested it by removing the Makefile and running ./configure
> with a made up card and it does not generate a new Makefile. So it must
> be using an old one with incorrect kernel source locations.
>
Sorry, do you mean I am wrong or do you mean the configure script is
wrong?
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [NETFILTER]: H.323 helper: remove changelog
From: Patrick McHardy @ 2006-04-06 23:13 UTC (permalink / raw)
To: David S. Miller; +Cc: Netfilter Development Mailinglist, Jing Min Zhao
[-- Attachment #1: Type: text/plain, Size: 82 bytes --]
Since we have the git history now, remove the changelogs from
the H.323 helper.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3338 bytes --]
[NETFILTER]: H.323 helper: remove changelog
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 4a7986fa34c9eed31b2f7df81a59fe7a282f689d
tree 5df1f9c86ed575131439d866ad240464816024b1
parent f29b83bf3ca68ea545b7cf6d25f0ababe109b8a9
author Patrick McHardy <kaber@trash.net> Fri, 07 Apr 2006 01:04:53 +0200
committer Patrick McHardy <kaber@trash.net> Fri, 07 Apr 2006 01:04:53 +0200
net/ipv4/netfilter/ip_conntrack_helper_h323.c | 31 -------------------------
net/ipv4/netfilter/ip_nat_helper_h323.c | 18 ---------------
2 files changed, 0 insertions(+), 49 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
index dccc6c3..2c2fb70 100644
--- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c
+++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
@@ -9,37 +9,6 @@
* Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
*
* For more information, please see http://nath323.sourceforge.net/
- *
- * Changes:
- * 2006-02-01 - initial version 0.1
- *
- * 2006-02-20 - version 0.2
- * 1. Changed source format to follow kernel conventions
- * 2. Deleted some unnecessary structures
- * 3. Minor fixes
- *
- * 2006-03-10 - version 0.3
- * 1. Added support for multiple TPKTs in one packet (suggested by
- * Patrick McHardy)
- * 2. Avoid excessive stack usage (based on Patrick McHardy's patch)
- * 3. Added support for non-linear skb (based on Patrick McHardy's patch)
- * 4. Fixed missing H.245 module owner (Patrick McHardy)
- * 5. Avoid long RAS expectation chains (Patrick McHardy)
- * 6. Fixed incorrect __exit attribute (Patrick McHardy)
- * 7. Eliminated unnecessary return code
- * 8. Fixed incorrect use of NAT data from conntrack code (suggested by
- * Patrick McHardy)
- * 9. Fixed TTL calculation error in RCF
- * 10. Added TTL support in RRQ
- * 11. Better support for separate TPKT header and data
- *
- * 2006-03-15 - version 0.4
- * 1. Added support for T.120 channels
- * 2. Added parameter gkrouted_only (suggested by Patrick McHardy)
- * 3. Splitted ASN.1 code and data (suggested by Patrick McHardy)
- * 4. Sort ASN.1 data to avoid forwarding declarations (suggested by
- * Patrick McHardy)
- * 5. Reset next TPKT data length in get_tpkt_data()
*/
#include <linux/config.h>
diff --git a/net/ipv4/netfilter/ip_nat_helper_h323.c b/net/ipv4/netfilter/ip_nat_helper_h323.c
index 6f19c20..d45663d 100644
--- a/net/ipv4/netfilter/ip_nat_helper_h323.c
+++ b/net/ipv4/netfilter/ip_nat_helper_h323.c
@@ -7,24 +7,6 @@
*
* Based on the 'brute force' H.323 NAT module by
* Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
- *
- * Changes:
- * 2006-02-01 - initial version 0.1
- *
- * 2006-02-20 - version 0.2
- * 1. Changed source format to follow kernel conventions
- * 2. Deleted some unnecessary structures
- * 3. Minor fixes
- *
- * 2006-03-10 - version 0.3
- * 1. Added support for multiple TPKTs in one packet (suggested by
- * Patrick McHardy)
- * 2. Added support for non-linear skb (based on Patrick McHardy's patch)
- * 3. Eliminated unnecessary return code
- *
- * 2006-03-15 - version 0.4
- * 1. Added support for T.120 channels
- * 2. Added parameter gkrouted_only (suggested by Patrick McHardy)
*/
#include <linux/module.h>
^ permalink raw reply related
* Re: problem building UML kernel with 2.6.16.1 -- dies when linking vmlinux
From: Christopher Friesen @ 2006-04-06 23:14 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel
In-Reply-To: <20060406215131.GA6422@ccure.user-mode-linux.org>
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
Jeff Dike wrote:
> On Thu, Apr 06, 2006 at 02:57:08PM -0600, Christopher Friesen wrote:
>
>> gcc -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc
>>-o vmlinux -Wl,-T,arch/um/kernel/vmlinux.lds init/built-in.o
>>-Wl,--start-group usr/built-in.o arch/um/kernel/built-in.o
>>arch/um/drivers/built-in.o arch/um/os-Linux/built-in.o
>>arch/um/sys-i386/built-in.o arch/i386/crypto/built-in.o
>>kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
>>security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a
>>lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o
>>-Wl,--end-group -lutil .tmp_kallsyms2.o ; rm -f linux
>>collect2: ld returned 1 exit status
>
>
> You can't extract an error message from that somehow?
>
> There isn't much to go on there.
That's all it gave me.
I played with the config options a bit and got it to build with the
attached config.
However, now when I run it without any args (just "./linux") I get the
following:
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...missing
Checking PROT_EXEC mmap in /tmp...OK
UML running in TT mode
tracing thread pid = 8963
And it just sits there. If I then hit ctrl-C I get the following:
remove_umid_dir - actually_do_remove failed with err = -2
Tracing thread segfault at address 0xbfffc000, ip 0xa018da40
Chris
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 12842 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.16.1
# Thu Apr 6 15:53:21 2006
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_UML=y
CONFIG_MMU=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_IRQ_RELEASE_METHOD=y
#
# UML-specific options
#
CONFIG_MODE_TT=y
# CONFIG_HOST_2G_2G is not set
CONFIG_KERNEL_HALF_GIGS=1
# CONFIG_MODE_SKAS is not set
#
# Host processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_UML_X86=y
# CONFIG_64BIT is not set
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_TOP_ADDR=0xc0000000
# CONFIG_3_LEVEL_PGTABLES is not set
CONFIG_STUB_CODE=0xbfffe000
CONFIG_STUB_DATA=0xbffff000
CONFIG_STUB_START=0xbfffe000
CONFIG_ARCH_HAS_SC_SIGNALS=y
CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_LD_SCRIPT_STATIC=y
CONFIG_NET=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_HOSTFS is not set
# CONFIG_HPPFS is not set
CONFIG_MCONSOLE=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_NEST_LEVEL=0
CONFIG_HIGHMEM=y
CONFIG_KERNEL_STACK_ORDER=2
# CONFIG_UML_REAL_TIME_CLOCK is not set
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Block layer
#
CONFIG_LBD=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Block devices
#
# CONFIG_BLK_DEV_UBD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_MMAPPER is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32000
CONFIG_BLK_DEV_INITRD=y
# CONFIG_ATA_OVER_ETH is not set
#
# Character Devices
#
CONFIG_STDERR_CONSOLE=y
CONFIG_STDIO_CONSOLE=y
CONFIG_SSL=y
# CONFIG_NULL_CHAN is not set
CONFIG_PORT_CHAN=y
CONFIG_PTY_CHAN=y
CONFIG_TTY_CHAN=y
CONFIG_XTERM_CHAN=y
CONFIG_NOCONFIG_CHAN=y
CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
CONFIG_CON_CHAN="xterm"
CONFIG_SSL_CHAN="pty"
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_WATCHDOG is not set
# CONFIG_UML_SOUND is not set
# CONFIG_SOUND is not set
# CONFIG_HOSTAUDIO is not set
# CONFIG_UML_RANDOM is not set
#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set
#
# Networking
#
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
CONFIG_ATM=y
# CONFIG_ATM_CLIP is not set
# CONFIG_ATM_LANE is not set
# CONFIG_ATM_BR2684 is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# UML Network Devices
#
# CONFIG_UML_NET is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
#
# PHY device support
#
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# ATM drivers
#
# CONFIG_ATM_DUMMY is not set
# CONFIG_ATM_TCP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=y
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_INPUT is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_CMDLINE_ON_HOST is not set
CONFIG_PT_PROXY=y
# CONFIG_SYSCALL_DEBUG is not set
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Lee Revell @ 2006-04-06 23:15 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144365041.9219.18.camel@localhost.localdomain>
On Fri, 2006-04-07 at 00:10 +0100, Adrian McMenamin wrote:
> On Thu, 2006-04-06 at 18:57 -0400, Lee Revell wrote:
> > On Thu, 2006-04-06 at 23:29 +0100, Adrian McMenamin wrote:
> > > I know that aica isn't in there - but the general build should still
> > > work and it doesn't...
> >
> > Nope - I just tested it by removing the Makefile and running ./configure
> > with a made up card and it does not generate a new Makefile. So it must
> > be using an old one with incorrect kernel source locations.
> >
> Sorry, do you mean I am wrong or do you mean the configure script is
> wrong?
>
>
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/x1658.htm
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Xen Infiniband Source Code Hosted
From: Nivedita Singhvi @ 2006-04-06 23:15 UTC (permalink / raw)
To: xen-devel, openib-general; +Cc: Jiuxing Liu
[-- Attachment #1.1: Type: text/plain, Size: 964 bytes --]
Hello!
Just wanted to let everyone know Jiuxing has populated a mercurial
tree (very kindly hosted by XenSource) with his code at the following site:
http://xenbits.xensource.com/ext/xen-smartio.hg
This contains the current source code for a xen infiniband frontend
and backend driver. The source code is in very preliminary stages
of development, just a proof of concept for now (works). We have
a long way to go. We'd like to invite interested folks to take a look
and get involved in the continuing design and development as an
open-source community.
We will be putting up a Wiki page for this shortly on the Xen Wiki.
Stay tuned...
There is also a mailing list we set up for discussion on
virtualization of smart I/O in Xen at:
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-smartio
However, at Ian's request we're going to contain most discussion
to xen-devel itself.
(Please pardon my earlier post without a subject).
thanks,
Nivedita
[-- Attachment #1.2: Type: text/html, Size: 1244 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [NETFILTER]: H.323 helper: remove changelog
From: David S. Miller @ 2006-04-06 23:18 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, zhaojingmin
In-Reply-To: <4435A089.4040602@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 07 Apr 2006 01:13:13 +0200
> Since we have the git history now, remove the changelogs from
> the H.323 helper.
Applied, thanks a lot Patrick.
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Martin Langhoff @ 2006-04-06 23:22 UTC (permalink / raw)
To: Keith Packard; +Cc: Jim Radford, Git Mailing List
In-Reply-To: <1144361968.2303.288.camel@neko.keithp.com>
On 4/7/06, Keith Packard <keithp@keithp.com> wrote:
> On Fri, 2006-04-07 at 09:51 +1200, Martin Langhoff wrote:
>
> > - file additions were recorded with one-commit-per-file. I am not
> > sure how rcs is recording these, but hte user does enter a common
> > message at "commit" time. Perhaps the file addition action could be
> > ignored then?
>
> If the log message is identical, and the dates are in-range, parsecvs
> "should" put the adds in the same commit.
parsecvs is committing them with the "added file foo.x" message, not
the actual commit message.
> > - some tags made on a branch show up in HEAD. This may be due to
> > partial-tree branches, but I am not sure.
>
> Finding branch points is not perfect; it's complicated by bizzarre
> behaviour when adding files and casual CVS changes which make precise
> branch points hard to detect. Can I get at this repository to play with?
I fetch it with something along the lines of...
while ( true ) ; do
wget -qc http://cvs.sourceforge.net/cvstarballs/moodle-cvsroot.tar.bz2 &&
break
sleep 5
done
and then import the "moodle" module.
cheers,
m
^ permalink raw reply
* Re: [PATCH] crypto: add alignment handling to digest layer
From: Herbert Xu @ 2006-04-06 23:24 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-kernel, linux-crypto, akpm
In-Reply-To: <20060406.113742.15248428.nemoto@toshiba-tops.co.jp>
On Thu, Apr 06, 2006 at 11:37:42AM +0900, Atsushi Nemoto wrote:
>
> We don't. I think update functions do not need an aligned buffer for
> data which is smaller then the alignment size.
You're right. If we do ever get any hardware that requires this we can
always change it later on.
Another thing, could you pleas change the stack allocation in final so
that it does it like cbc_process_decrypt? The reason is that gcc is too
stupid to not allocate that buffer unconditionally.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Adrian McMenamin @ 2006-04-06 23:25 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144365316.12038.37.camel@mindpipe>
On Thu, 2006-04-06 at 19:15 -0400, Lee Revell wrote:
> On Fri, 2006-04-07 at 00:10 +0100, Adrian McMenamin wrote:
> > On Thu, 2006-04-06 at 18:57 -0400, Lee Revell wrote:
> > > On Thu, 2006-04-06 at 23:29 +0100, Adrian McMenamin wrote:
> > > > I know that aica isn't in there - but the general build should still
> > > > work and it doesn't...
> > >
> > > Nope - I just tested it by removing the Makefile and running ./configure
> > > with a made up card and it does not generate a new Makefile. So it must
> > > be using an old one with incorrect kernel source locations.
> > >
> > Sorry, do you mean I am wrong or do you mean the configure script is
> > wrong?
> >
> >
>
> http://www.alsa-project.org/~iwai/writing-an-alsa-driver/x1658.htm
>
And your point is?
I've written those files. cvscompile bombs
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [PATCH] Add a /proc/self/exedir link
From: Mike Hearn @ 2006-04-06 19:36 UTC (permalink / raw)
To: Bodo Eggert; +Cc: Neil Brown, linux-kernel, akpm
In-Reply-To: <Pine.LNX.4.58.0604061841150.1941@be1.lrz>
> bin/foo calls bin/bar refering to /proc/self/fd/999
> bin_2/bar does dup2(open(get_my_exedir()), 999) ***FUBAR***
So don't do that. Treat it as the same case as sending a file path via
RPC: make sure it's resolved relative to the namespace the program is in
and not anything under /proc/self.
In practice most desktop apps use "prefix paths" to locate their own
data files. They don't usually send those file paths to other processes,
not even in the case of things like GIMP plugins.
So whilst I agree you have identified a place where it breaks, I don't
think it invalidates the scheme.
> There may be no "real path" corresponding to /proc/self/fd/4711.
Only in a pathological case like running a program that you then rm -rf
the prefix of, in which case, you lose whatever happens.
> IMO it's still best to just symlink the program directory to the correct
> place and make the programs search in e.g. ~/opt/ and /opt/.
That also suffers from namespace conflicts ;)
thanks -mike
^ permalink raw reply
* Re: [PATCH] Add a /proc/self/exedir link
From: Tony Luck @ 2006-04-06 23:33 UTC (permalink / raw)
To: Mike Hearn; +Cc: Eric W. Biederman, linux-kernel, akpm
In-Reply-To: <44343C25.2000306@plan99.net>
> > I have concerns about security policy ...
>
> I'm not sure I understand. Only if you run that program, and if you
> don't have access to the intermediate directory, how do you run it?
It leaks information about the parts of the pathname below the
directory that you otherwise would not be able to see. E.g. if
I have $HOME/top-secret-projects/secret-code-name1/binary
where the top-secret-projects directory isn't readable by you,
then you may find out secret-code-name1 by reading the
/proc/{pid}/exedir symlink.
-Tony
^ permalink raw reply
* "xm top" broke in 3.0-testing
From: Matt Ayres @ 2006-04-06 23:36 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
Subject says about all..
# xm top
Failed to retrieve statistics from libxenstat
xen_caps : xen-3.0-x86_32p
platform_params : virt_start=0xf5800000
xen_changeset : Thu Apr 6 18:34:32 2006 +0100 9595:32b22f5286be
^ permalink raw reply
* patches added to release/test trees
From: Luck, Tony @ 2006-04-06 23:49 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <200601270107.k0R17838011430@agluck-lia64.sc.intel.com>
The following patches have been added to my release/test trees:
Bjorn Helgaas:
[IA64] update HP CSR space discovery via ACPI
KAMEZAWA Hiroyuki:
[IA64] for_each_possible_cpu: ia64
Tony Luck:
[IA64] Wire up new syscall sync_file_range()
[IA64] 'msg' may be used uninitialized in xpc_initiate_allocate()
[IA64] Wire up new syscalls {set,get}_robust_list
^ permalink raw reply
* udev man page suggestion (RUN needs full path)
From: Richard Neill @ 2006-04-06 23:52 UTC (permalink / raw)
To: linux-hotplug
Dear All,
I've just escaped from some confusion with udev and the RUN= key.
I eventually discovered by experiment, that programs listed there must
contain their full path.
May I suggest that this would be a useful addition to the man page.
Best wishes,
Richard
--
rn214@hermes.cam.ac.uk ** http://www.richardneill.org
Richard Neill, Trinity College, Cambridge, CB21TQ, U.K.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Junio C Hamano @ 2006-04-06 23:53 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060406205724.12216.qmail@science.horizon.com>
linux@horizon.com writes:
>> Right now we LRU the pack files and evict older ones when we
>> mmap too many, but the unit of eviction is the whole file, so it
>> would not help the case like yours at all. It might be possible
>> to mmap only part of a packfile, but it would involve fairly
>> major surgery to sha1_file.c.
>
> The simplest solution seems to be to limit pack file size to a reasonable
> fraction of a 32-bit address space. Say, 0.5 G.
I do not think that would help the original poster's situation
where only 5 revs result in a 1.5G pack. I would _almost_ say
"do not pack such a repository", but there is the initial
cloning over git-aware transports which always results in a
repository with a single pack.
^ permalink raw reply
* Re: 2.6.16-rt11: Hires timer makes sleep wait far too long
From: Jonathan Woithe @ 2006-04-06 23:58 UTC (permalink / raw)
To: tglx; +Cc: Jonathan Woithe, linux-kernel
In-Reply-To: <1144319324.5344.688.camel@localhost.localdomain>
Thomas
> On Wed, 2006-04-05 at 09:51 +0930, Jonathan Woithe wrote:
> > ENABLING IO-APIC IRQs
> > ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> > Event source pit new caps set: 05
> > Event source lapic installed with caps set: 02
> > :
> > Time: tsc clocksource has been installed.
> > hrtimers: Switched to high resolution mode CPU 0
> > :
> > Time: acpi_pm clocksource has been installed.
> > hrtimers: Switched to high resolution mode CPU 0
>
> Nothing wrong so far. I have to find a test box with pm timer to get
> some more info.
Note that the fault condition persisted no matter which clocksource was
in use: I tried all four (tsc, pm_timer, jiffies, pit) and they all resulted
in "sleep 1" lasting far longer than 1 second.
Feel free to email if I can be of further assistance. In the meantime I'll
try 2.6.16-rt12 over the weekend to see if the situation is any different.
Regards
jonathan
^ 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.