* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Mike Frysinger @ 2010-10-07 20:02 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <1286481532.23836.27.camel@c-dwalke-linux.qualcomm.com>
On Thu, Oct 7, 2010 at 15:58, Daniel Walker wrote:
> On Thu, 2010-10-07 at 15:48 -0400, Mike Frysinger wrote:
>> i dont think hijacking the "ttyS" namespace is acceptable, even if
>> it's behind a Kconfig. other people have tried in the past (myself
>> included) and been shot down. sounds like a shim for crappy userspace
>> apps that blindly assume /dev/ttyS*. is that really an issue anymore
>> though now that things like /dev/ttyUSB* are so common and people are
>> used to picking between multiple serial sources ?
>
> It also creates a ttyJ* which uses the same interfaces as the code for
> ttyS* .. I don't think allowing a Kconfig option to shim this in as a
> ttyS* is all that bad .. This driver is only going to be used in rare
> cases for debugging , having a ttyS* is just a level of flexibility ..
how is that any different from:
ln -s ttyJ0 /dev/ttyS0
-mike
^ permalink raw reply
* [PATCH] net: clear heap allocation for ETHTOOL_GRXCLSRLALL
From: Kees Cook @ 2010-10-07 20:03 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Ben Hutchings, Jeff Garzik, Jeff Kirsher,
Peter P Waskiewicz Jr, netdev
Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel
heap without clearing it. For the one driver (niu) that implements it,
it will leave the unused portion of heap unchanged and copy the full
contents back to userspace.
Cc: stable@kernel.org
Signed-off-by: Kees Cook <kees.cook@canonical.com>
---
net/core/ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 7a85367..4016ac6 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -348,7 +348,7 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
if (info.cmd == ETHTOOL_GRXCLSRLALL) {
if (info.rule_cnt > 0) {
if (info.rule_cnt <= KMALLOC_MAX_SIZE / sizeof(u32))
- rule_buf = kmalloc(info.rule_cnt * sizeof(u32),
+ rule_buf = kzalloc(info.rule_cnt * sizeof(u32),
GFP_USER);
if (!rule_buf)
return -ENOMEM;
--
1.7.1
--
Kees Cook
Ubuntu Security Team
^ permalink raw reply related
* Re: [PATCH] percpu_counter: change inaccurate comment
From: Eric Dumazet @ 2010-10-07 20:04 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1010071440220.28032@router.home>
Le jeudi 07 octobre 2010 à 14:42 -0500, Christoph Lameter a écrit :
> On Thu, 7 Oct 2010, Eric Dumazet wrote:
>
> > percpu_counter used to be huge objects, they are not anymore,
> > thanks to fine alloc_percpu() granularity.
> >
> > We now consume 4 bytes per possible cpu.
>
> Ahh I did not notice that they switched.... Then we may also want the
> following patch to improve performance. It would even be better if we
> could do a this_cpu_add(fbc->counters, amount) there but the 64 bit size
> fo count looks suspiciously like you are expecting overflows beyond ints
> max size.
>
Yes, this 64bit interface is very strange.
>
> Subject: percpu_counter: Use this_cpu_ptr instead of per_cpu_ptr
>
> this_cpu_ptr avoids an array lookup and can use the percpu
> offset of the local cpu directly.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
>
> ---
> lib/percpu_counter.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/lib/percpu_counter.c
> ===================================================================
> --- linux-2.6.orig/lib/percpu_counter.c 2010-10-07 14:36:39.000000000 -0500
> +++ linux-2.6/lib/percpu_counter.c 2010-10-07 14:38:43.000000000 -0500
> @@ -30,9 +30,9 @@ void __percpu_counter_add(struct percpu_
> {
> s64 count;
> s32 *pcount;
> - int cpu = get_cpu();
>
> - pcount = per_cpu_ptr(fbc->counters, cpu);
> + preempt_disable();
> + pcount = this_cpu_ptr(fbc->counters);
> count = *pcount + amount;
> if (count >= batch || count <= -batch) {
> spin_lock(&fbc->lock);
> @@ -42,7 +42,7 @@ void __percpu_counter_add(struct percpu_
> } else {
> *pcount = count;
> }
> - put_cpu();
> + preempt_enable();
> }
> EXPORT_SYMBOL(__percpu_counter_add);
>
If enclosed by preempt_disable()/preempt_enable(), maybe we could use
__this_cpu_ptr() ?
^ permalink raw reply
* Re: [PATCH RFC 2/2] usb: ehci-omap: add suspend/resume support
From: Gadiyar, Anand @ 2010-10-07 20:04 UTC (permalink / raw)
To: Laine Walker-Avina
Cc: Alan Stern, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
Gupta, Ajay Kumar
In-Reply-To: <AANLkTi=EoEUDsSVjo7somYESe6k8ziB+FGKrnMAZ2OAC@mail.gmail.com>
On Fri, Oct 8, 2010 at 1:17 AM, Laine Walker-Avina <lwalkera@ieee.org> wrote:
> On Fri, May 14, 2010 at 7:01 AM, Gadiyar, Anand <gadiyar@ti.com> wrote:
>> Alan Stern wrote:
>>> On Thu, 13 May 2010, Anand Gadiyar wrote:
>>>
>>> > Add support for suspend and resume to the ehci-omap driver.
>>> > Added routines for platform_driver suspend/resume and
>>> > wrappers around ehci_bus_suspend/resume.
>>>
...
>>> You could use the runtime-PM interface instead of explicitly suspending
>>> and resuming the controller. It is now standard.
>>>
>>
>> Will work on this. I'll be out for a while, so it could be some time
>> before I repost.
>>
>> Thanks,
>> Anand
>
> Any more developments on this?
>
Yup. We've rewritten this driver to factor out the common
TLL and UHH programming, so that it plays nicely
when EHCI and OHCI are both loaded. This was needed
to be able to use the omap_device layer to use runtime PM
We didn't want to do the work twice, that's why we
abandoned this initial patch to do it cleanly once.
The current version is being tested now and should
be posted in a while.
It's available on internal trees on dev.omapzoom.org,
if you want to take a look. I can send a link if you like.
- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: Staticise CS4270 DAI
From: Timur Tabi @ 2010-10-07 20:06 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, patches, Liam Girdwood
In-Reply-To: <1286407557-30413-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Mark Brown wrote:
> It's not needed with multi-component.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* 2.6.37 planning, and cjb in Taipei Oct 19-Nov 2
From: Chris Ball @ 2010-10-07 20:11 UTC (permalink / raw)
To: linux-mmc
Hi,
Below is the current list of patches queued for 2.6.37. If you'd like
a patch to be considered for 2.6.37 that isn't listed, please let me
know.
I'm going to be in Taipei for an OLPC board bringup from Oct 19th
to Nov 2nd -- the start of the trip will probably be during the merge
window. I'll make time to ensure that the merge goes okay, but I'll
be busier than usual, so I'm planning to have my tree ready for a pull
request before I leave. Also, if you happen to be in Taipei during
that time (or in Cambridge, MA directly afterwards) I'd be happy to
meet up in person. Thanks!
Patches in mmc-next:
Adrian Hunter (4):
mmc_test: fix performance tests that go over max_blk_count
mmc_test: fix memory allocation segment limits
mmc_test: fix display of .5 KiB
mmc: Fixes for Dual Data Rate (DDR) support
Alan Cox (2):
mmc: sdhci: Allow the probe handler to override slots
mmc: sdhci: Add Moorestown device support
Andy Shevchenko (6):
mmc: make mmc_dev_to_card() macro public
mmc: rename dev_to_mmc_card() to mmc_dev_to_card()
mmc_test: use API to check card type
mmc_test: change simple_strtol() to strict_strtol()
mmc_test: collect data and show it via sysfs by demand
mmc_test: move files from sysfs to debugfs
David Vrabel (1):
mmc: USB SD Host Controller (USHC) driver
Ethan Du (1):
mmc: name mmc queue thread by host index
George G. Davis (1):
mmc: sdhci: Make consistent use of CONFIG_MMC_DEBUG for "DEBUG"ging
Giuseppe Cavallaro (4):
mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host capabilities
mmc: sdhci-pltfm: add suspend/resume functions
mmc: sdhci: fix "pwr may be used uninitialized" warning
mmc: sdhci: split up sdhci.h for sdhci-pltfm users
H Hartley Sweeten (3):
mmc: at91_mci.c: use resource_size()
mmc: atmel-mci.c: use resource_size()
mmc: au1xmmc.c: use resource_size()
Hanumath Prasad (1):
mmc: MMC 4.4 DDR support
Hein Tibosch (1):
mmc: Make ID freq configurable
Jaehoon Chung (1):
mmc: sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
JiebingLi (1):
mmc: Use snprintf, not sprintf.
Linus Walleij (1):
mmc: Move regulator handling closer to core
Martin K. Petersen (1):
mmc: Remove distinction between hw and phys segments
Matt Fleming (1):
mmc: Add helper function to check if a card is removable
Ohad Ben-Cohen (9):
mmc: sdio: fully reconfigure oldcard on resume
mmc: propagate power save/restore ops return value
mmc: sdio: add power_restore support
mmc: add runtime PM handlers
mmc: sdio: use the generic runtime PM handlers
mmc: sdio: enable runtime PM for SDIO cards
mmc: sdio: enable runtime PM for SDIO functions
mmc: sdio: ensure mmc_sdio_detect is powered
mmc: sdio: support suspend/resume while runtime suspended
Olof Johansson (1):
mmc: make number of mmcblk minors configurable
Philip Rakity (1):
mmc: sdhci: print out controller name for register debug
Thomas Gleixner (1):
mmc: Convert "mutex" to semaphore
Xiaochen Shen (1):
mmc: sdhci: Intel Medfield support
Zhangfei Gao (4):
mmc: SDHC 3.0: support 10-bit divided clock mode
mmc: SDHC 3.0: Base clock frequency change in spec 3.0
mmc: sdhci: Enable high-speed support for MMC cards
mmc: sdhci: correct f_min calculation with SD 3.0 spec
matt mooney (1):
mmc: Makefile: Fix EXTRA_CFLAGS assignment
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 20:06 UTC (permalink / raw)
To: Mike Frysinger
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <AANLkTi=j2n-X+-zkas8HdL1awo7Lcyxwofts6FjU8vj6@mail.gmail.com>
On Thu, 2010-10-07 at 16:02 -0400, Mike Frysinger wrote:
> how is that any different from:
> ln -s ttyJ0 /dev/ttyS0
> -mike
It has the same major and minors as ttyS* does. So you don't have to run
anything on the target.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Questions about CRUSH
From: Wido den Hollander @ 2010-10-07 20:08 UTC (permalink / raw)
To: ceph-devel
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
Hi,
I'm working on a crushmap where I have my hosts spread out over 3 racks
(leafs).
I have 9 physical machines, each with one OSD, spread out over three
racks.
The replication level I intend to use is 3, my goal with this crushmap
is to prevent two replicas being stored in the same rack.
Now, this map seems fine to me, but what if one of the racks fails and
the cluster starts to fix itself, then I would get two replicas in the
same rack, wouldn't I?
Is it better to have: leafs at root = (max replication level + 1) ?
So, if I have my replication level set to 3, I should have 4 racks with
each 3 OSD's, then the cluster could restore from a complete rack
failure, without compromising my data safety.
When a complete leaf (rack) fails, the other leafs should be able to
store all the data, so if my replication level is set to 3, I should
always have at least 1/3 of free space, otherwise a full recovery won't
be possible, correct? (OSD's run out of disk space).
Am I missing something here or is this the right approach?
And I'm not completely sure about:
rule placein3racks {
ruleset 0
type replicated
min_size 2
max_size 2
step take root
step chooseleaf firstn 0 type rack
step emit
}
Is that correct? Here I say that the first step should be to choose a
rack where the replica should be saved. Should I also specify to choose
a host afterwards?
Thank you,
Wido
[-- Attachment #2: crushmap_3_racks.txt --]
[-- Type: text/plain, Size: 1391 bytes --]
device 0 device0
device 1 device1
device 2 device2
device 3 device3
device 4 device4
device 5 device5
device 6 device6
device 7 device7
device 8 device8
type 0 device
type 1 host
type 2 rack
type 3 root
# hosts
host host0 {
id -1
alg straw
hash 0
item device0 weight 1.000
}
host host1 {
id -2
alg straw
hash 0
item device1 weight 1.000
}
host host2 {
id -3
alg straw
hash 0
item device2 weight 1.000
}
host host3 {
id -4
alg straw
hash 0
item device3 weight 1.000
}
host host4 {
id -5
alg straw
hash 0
item device4 weight 1.000
}
host host5 {
id -6
alg straw
hash 0
item device5 weight 1.000
}
host host6 {
id -7
alg straw
hash 0
item device6 weight 1.000
}
host host7 {
id -8
alg straw
hash 0
item device7 weight 1.000
}
host host8 {
id -8
alg straw
hash 0
item device8 weight 1.000
}
rack rack0 {
id -9
alg straw
hash 0
item host0
item host1
item host2
}
rack rack1 {
id -10
alg straw
hash 0
item host3
item host4
item host5
}
rack rack2 {
id -11
alg straw
hash 0
item host6
item host7
item host8
}
root root {
id -12
alg straw
hash 0
item rack0
item rack1
item rack2
}
rule placein3racks {
ruleset 0
type replicated
min_size 2
max_size 2
step take root
step chooseleaf firstn 0 type rack
step emit
}
^ permalink raw reply
* Re: [PATCH] OLPC: Add XO-1 poweroff support
From: Andres Salomon @ 2010-10-07 20:09 UTC (permalink / raw)
To: Daniel Drake; +Cc: tglx, mingo, hpa, x86, linux-kernel
In-Reply-To: <20101007185952.A36859D401B@zog.reactivated.net>
On Thu, 7 Oct 2010 19:59:52 +0100 (BST)
Daniel Drake <dsd@laptop.org> wrote:
> Add a pm_power_off handler for the OLPC XO-1 laptop.
>
> Signed-off-by: Daniel Drake <dsd@laptop.org>
> ---
> arch/x86/Kconfig | 6 ++
> arch/x86/kernel/Makefile | 1 +
> arch/x86/kernel/olpc-xo1.c | 112
> ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 119
> insertions(+), 0 deletions(-) create mode 100644
> arch/x86/kernel/olpc-xo1.c
>
> The new olpc-xo1.c file will also be used for further functionality
> (suspend/resume, lid switch device, etc); patches to be submitted
> shortly after the review/merge of this one.
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index cea0cd9..19e6439 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2065,6 +2065,12 @@ config OLPC
> Add support for detecting the unique features of the OLPC
> XO hardware.
>
> +config OLPC_XO1
> + bool "OLPC XO-1 support"
Any particular reason why this can't be modular?
[...]
> +
> + pm_power_off = xo1_power_off;
> +
If this were to be modular, I'm not sure what the best option is for
pm_power_off. If the old value was saved upon module load, and
restored upon module unload, I could imagine races like the following:
module A load:
saved_ppo = pm_power_off; /* NULL */
pm_power_off = frob;
module B load:
old_ppo = pm_power_off; /* frob */
pm_power_off = foo;
module A unload:
pm_power_off = saved_ppo; /* NULL */
So I guess just clobbering whatever's in pm_power_off and setting back
to NULL upon unload, with the assumption that driver's only really
going to clobber it in the case of actual OLPC hardware, and the
callbacks being clobbered wouldn't really have done the correct thing
anyways?
> + printk(KERN_INFO "OLPC XO-1 support registered\n");
> + return 0;
> +}
> +device_initcall(olpc_xo1_init);
> +
^ permalink raw reply
* [PATCH net-next-2.6] net: Fix rxq ref counting
From: Tom Herbert @ 2010-10-07 20:09 UTC (permalink / raw)
To: davem, netdev
The rx->count reference is used to track reference counts to the
number of rx-queue kobjects created for the device. This patch
eliminates initialization of the counter in netif_alloc_rx_queues
and instead increments the counter each time a kobject is created.
This is now symmetric with the decrement that is done when an object is
released.
Signed-off-by: Tom Herbert <therbert@google.com>
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 7d14955..58b31d1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5026,7 +5026,6 @@ static int netif_alloc_rx_queues(struct net_device *dev)
return -ENOMEM;
}
dev->_rx = rx;
- atomic_set(&rx->count, count);
/*
* Set a pointer to first element in the array which holds the
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index fa81fd0..b143173 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -726,6 +726,7 @@ static struct kobj_type rx_queue_ktype = {
static int rx_queue_add_kobject(struct net_device *net, int index)
{
struct netdev_rx_queue *queue = net->_rx + index;
+ struct netdev_rx_queue *first = queue->first;
struct kobject *kobj = &queue->kobj;
int error = 0;
@@ -738,6 +739,7 @@ static int rx_queue_add_kobject(struct net_device *net, int index)
}
kobject_uevent(kobj, KOBJ_ADD);
+ atomic_inc(&first->count);
return error;
}
^ permalink raw reply related
* [Qemu-devel] Re: [PATCH 10/11] ppc: avoid write only variables
From: Alexander Graf @ 2010-10-07 20:08 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
In-Reply-To: <AANLkTimMza1pGQhXOu=jHY4fe7gaUxEPQtrhdoxW_-NL@mail.gmail.com>
Am 07.10.2010 um 20:59 schrieb Blue Swirl <blauwirbel@gmail.com>:
> On Wed, Oct 6, 2010 at 9:39 PM, Alexander Graf <agraf@suse.de> wrote:
>>
>> On 06.10.2010, at 23:34, Blue Swirl wrote:
>>
>>> Compiling with GCC 4.6.0 20100925 produced warnings:
>>> /src/qemu/target-ppc/op_helper.c: In function 'helper_icbi':
>>> /src/qemu/target-ppc/op_helper.c:351:14: error: variable 'tmp' set but
>>> not used [-Werror=unused-but-set-variable]
>>> /src/qemu/target-ppc/op_helper.c: In function 'do_6xx_tlb':
>>> /src/qemu/target-ppc/op_helper.c:3805:28: error: variable 'EPN' set
>>> but not used [-Werror=unused-but-set-variable]
>>> /src/qemu/target-ppc/op_helper.c: In function 'do_74xx_tlb':
>>> /src/qemu/target-ppc/op_helper.c:3838:28: error: variable 'EPN' set
>>> but not used [-Werror=unused-but-set-variable]
>>>
>>> Fix by making the variable declarations and their uses also conditional
>>> to debug definition. Delete tmp.
>>
>> Maybe it would make more sense to get those LOG_* macros into static inline functions. But for the issue at hand, the solution looks good to me.
>
> Perhaps all conditionally enabled debug printf stuff should be
> transformed into tracepoints? That would be more flexible than
> uncommenting DEBUG_foobar. Would it help with bitrot too?
I haven't looked at the qemu tracepoints framework yet, but some of this debug stuff is in hot paths and only very rarely used. So unless it is overhead free, I'd prefer debug function stubs.
Alex
>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> Thanks.
^ permalink raw reply
* Re: [PATCHv4 net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address
From: Arnaud Ebalard @ 2010-10-07 20:13 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Eric Dumazet, Hideaki YOSHIFUJI, netdev
In-Reply-To: <20101005041707.GA26458@gondor.apana.org.au>
Hi,
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Oct 05, 2010 at 10:11:14AM +0800, Herbert Xu wrote:
>>
>> I'm thinking about the case where each remote end (or one remote
>> end with many IP addresses) chooses to use a single SPI which then
>> all gets hashed to the same bucket.
>>
>> Outbound SAs are hashed into the same SPI hash table as inbound SAs.
>
> Another solution would be to create a hash table for inbound SAs
> only. Unfortunately I don't think we have anything in our current
> user-interface to indicate whether an SA is inbound or outbound.
>
> So to do this you'll need to use a heuristic such as doing a
> lookup on the source/destination address at insertion time.
I spent some time scratching my head trying to find a good solution. It
would indeed be perfect to have a specific hash table for inbound
SA. But as you point, this would only be via a heuristic at insertion
time and there are various cases which would not work: a SA can be
installed w/o any of the addresses being configured on the system.
I think I will try the following alternative approach based on your
comments and proposals:
- drop my patch to change spi hash computation
- handle destination address remapping during input upon failure of
xfrm_state_lookup()
- handle source address remapping as it is currently done in the patch,
i.e. by comparing received one against x->props.saddr once the
state found and do
To support the destination address remapping, I will have to reverse the
logic I currently have for destination remapping states, to allow the
lookup to be done based on the on-wire address (CoA) instead of the
address in the SA (HoA). If a remapping state is found for the on-wire
address, then a new lookup is done using the associated HoA this time.
I think it would make the feature easier less intrusive for the IPsec
stack.
Thanks for your support and patience, Herbert.
a+
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-07 20:12 UTC (permalink / raw)
To: Scott Wood; +Cc: david.hagood@gmail.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100921170700.53a99e56@udp111988uds.am.freescale.net>
> On Tue, 21 Sep 2010 17:37:15 -0400
> The MPIC interrupt numberspace in the device tree (which is not
> virtual; it is a private numberspace to MPIC) is based on the offset of
> the registers for that interrupt source. External interrupts start at
> zero (which is valid), internal at 16, and special things like MSIs at
> higher numbers (I don't think it's quite 256).
OK, so I'm slowly wrapping my head around this (OT: Has anybody considered
sending this information to the folks doing the Linux Device Drivers
books? They are just a bit x86 centric right now...).
As I understand, what I have to do is somehow get a device_node *, then
make a call to irq_of_parse_and_map() to convert that into a system IRQ.
What I am doing right now is:
device_node *mpic = of_find_node_by_type(0,"open-pic");
irq = irq_of_parse_and_map(mpic,256);
While I get a pointer from of_find_node_by_type, when I try to map IRQ
#256 via the irq_of_parse_and_map function, I get a zero back from it.
So I guess my questions would be:
1) should I be frobbing the PIC for this, or should I be looking up some
other device?
2) How do I know for certain that 256 is the right value for the first MSI
signaled via MSIR0?
^ permalink raw reply
* Re: Linux 2.6.36-rc7
From: Milan Broz @ 2010-10-07 20:13 UTC (permalink / raw)
To: device-mapper development
Cc: Linux Kernel Mailing List, just.for.lkml, hch, herbert, Tejun Heo,
Linus Torvalds
In-Reply-To: <4CAE1F47.3050105@kernel.org>
On 10/07/2010 09:28 PM, Tejun Heo wrote:
> I'm afraid there is a possibly workqueue related deadlock under high
> memory pressure. It happens on dm-crypt + md raid1 configuration.
> I'm not yet sure whether this is caused by workqueue failing to kick
> rescuers under memory pressure or the shared workqueue is making an
> already existing problem more visible and in the process of setting up
> an environment to reproduce the problem.
>
> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/34922/focus=1044784
Yes, XFS is very good to show up problems in dm-crypt:)
But there was no change in dm-crypt which can itself cause such problem,
planned workqueue changes are not in 2.6.36 yet.
Code is basically the same for the last few releases.
So it seems that workqueue processing really changed here under memory pressure.
Milan
p.s.
Anyway, if you are able to reproduce it and you think that there is problem
in per-device dm-crypt workqueue, there are patches from Andi for shared
per-cpu workqueue, maybe it can help here. (But this is really not RC material.)
Unfortunately not yet in dm-devel tree, but I have them here ready for review:
http://mbroz.fedorapeople.org/dm-crypt/2.6.36-devel/
(all 4 patches must be applied, I hope Alasdair will put them in dm quilt soon.)
^ permalink raw reply
* Re: [PATCH] percpu_counter: change inaccurate comment
From: Christoph Lameter @ 2010-10-07 20:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <1286481860.3745.30.camel@edumazet-laptop>
On Thu, 7 Oct 2010, Eric Dumazet wrote:
> If enclosed by preempt_disable()/preempt_enable(), maybe we could use
> __this_cpu_ptr() ?
The only difference between __this_cpu_ptr and this_cpu_ptr is that
this_cpu_ptr checks that preempt was disabled. __this_cpu_ptr allows use
even without preempt. Preempt must be disabled here so the use of
this_cpu_ptr is appropriate.
^ permalink raw reply
* Re: [dm-devel] Linux 2.6.36-rc7
From: Milan Broz @ 2010-10-07 20:13 UTC (permalink / raw)
To: device-mapper development
Cc: Tejun Heo, Linus Torvalds, Linux Kernel Mailing List,
just.for.lkml, hch, herbert
In-Reply-To: <4CAE1F47.3050105@kernel.org>
On 10/07/2010 09:28 PM, Tejun Heo wrote:
> I'm afraid there is a possibly workqueue related deadlock under high
> memory pressure. It happens on dm-crypt + md raid1 configuration.
> I'm not yet sure whether this is caused by workqueue failing to kick
> rescuers under memory pressure or the shared workqueue is making an
> already existing problem more visible and in the process of setting up
> an environment to reproduce the problem.
>
> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/34922/focus=1044784
Yes, XFS is very good to show up problems in dm-crypt:)
But there was no change in dm-crypt which can itself cause such problem,
planned workqueue changes are not in 2.6.36 yet.
Code is basically the same for the last few releases.
So it seems that workqueue processing really changed here under memory pressure.
Milan
p.s.
Anyway, if you are able to reproduce it and you think that there is problem
in per-device dm-crypt workqueue, there are patches from Andi for shared
per-cpu workqueue, maybe it can help here. (But this is really not RC material.)
Unfortunately not yet in dm-devel tree, but I have them here ready for review:
http://mbroz.fedorapeople.org/dm-crypt/2.6.36-devel/
(all 4 patches must be applied, I hope Alasdair will put them in dm quilt soon.)
^ permalink raw reply
* OT: compilation
From: Grzesiek Sójka @ 2010-10-07 20:14 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
I have two problems with the kernel compilation.
1. I have a small rootfs. It is too small to put all the modules there
without gzipping it first. So installing it requires lots of sweating.
That is why I was wondering if there is a (more/less easy) way to make
the "make modules_install" command gzip the modules "on the fly".
2. I modified the sources and after compilation the string
"g76f6e1f-dirty" was appended to the kernel version. It is a bit
annoying because of the lack of the space at the rootfs. Is there a way
to avoid this kind of a version extension??
Thanks for your help in advance.
^ permalink raw reply
* [U-Boot] packed attribute problem
From: Scott Wood @ 2010-10-07 20:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101007193143.19030153A7E@gemini.denx.de>
On Thu, 7 Oct 2010 21:31:43 +0200
Wolfgang Denk <wd@denx.de> wrote:
> Dear Scott Wood,
>
> In message <20101007135257.05a93975@udp111988uds.am.freescale.net> you wrote:
> >
> > > It is a pretty common method to use a pointer to some struct (for
> > > example, some form of PDU) and make it point to some I/O buffer.
> >
> > Yes, but at that point we are not talking about well-defined C, but
> > rather implementation-specific behavior. There's nothing wrong with
> > it, but the C standard is no longer authoritative on what happens in
> > such cases.
>
> Huch? Which part of that is not well-defined (or even not
> standard-conforming) C?
Well, how do you obtain the unaligned pointer?
Casting an integer to a pointer? 6.3.2.3: "An integer may be converted
to any pointer type. Except as previously specified, the result is
implementation-defined, might not be properly aligned, and might not
point to an entity of the referenced type."
Casting a pointer to a pointer of a different type? 6.3.2.3: "A pointer
to an object or incomplete type may be converted to a pointer to a
different object or incomplete type. If the resulting pointer is not
correctly aligned for the pointed-to type, the behavior is undefined."
I was expecting to find something stating that it was not well-defined
behavior if you dereference a pointer that points to data of a
different type, but couldn't (maybe I wasn't searching for the right
terms) -- though a similar limitation is present in 6.5.2.3 for unions:
"With one exception, if the value of a member of a union object is used
when the most recent store to the object was to a different member, the
behavior is implementation-defined."
Extensions like __attribute__((packed)) are obviously not
well-defined C.
> > Yes. And there would also be performance complaints if each of those
> > accesses were to trap and be emulated (even ignoring weird stuff like
> > old ARM). Thus it's nice to have some sort of pointer or data type
> > annotation to tell the compiler to be careful.
>
> I also complain about poor performance when instead of a single
> instruction (a 32 bit load) at least 4 (8 bit) instructions need to be
> executed.
So only use the unaligned annotation when there's a significant chance
of it really being unaligned -- and make sure the compiler knows
whether the cost of an unaligned access is significantly worse than the
cost of its workaround.
> > BTW, I see GCC splitting accesses to bitfields in a packed
> > struct into bytes on powerpc, even with -mno-strict-align.
>
> Indeed. Bitfields have always been evil.
Evil or not, I don't see why GCC feels the need to do this.
-Scott
^ permalink raw reply
* + rmap-make-anon_vma_free-static-fix.patch added to -mm tree
From: akpm @ 2010-10-07 19:45 UTC (permalink / raw)
To: mm-commits; +Cc: akpm, andi, namhyung
The patch titled
rmap-make-anon_vma_free-static-fix
has been added to the -mm tree. Its filename is
rmap-make-anon_vma_free-static-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: rmap-make-anon_vma_free-static-fix
From: Andrew Morton <akpm@linux-foundation.org>
Andi just added patches to linux-next which call anon_vma_free() from
mm/migrate.c.
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/rmap.h | 1 +
mm/rmap.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff -puN include/linux/rmap.h~rmap-make-anon_vma_free-static-fix include/linux/rmap.h
--- a/include/linux/rmap.h~rmap-make-anon_vma_free-static-fix
+++ a/include/linux/rmap.h
@@ -148,6 +148,7 @@ void unlink_anon_vmas(struct vm_area_str
int anon_vma_clone(struct vm_area_struct *, struct vm_area_struct *);
int anon_vma_fork(struct vm_area_struct *, struct vm_area_struct *);
void __anon_vma_link(struct vm_area_struct *);
+void anon_vma_free(struct anon_vma *);
static inline void anon_vma_merge(struct vm_area_struct *vma,
struct vm_area_struct *next)
diff -puN mm/rmap.c~rmap-make-anon_vma_free-static-fix mm/rmap.c
--- a/mm/rmap.c~rmap-make-anon_vma_free-static-fix
+++ a/mm/rmap.c
@@ -70,7 +70,7 @@ static inline struct anon_vma *anon_vma_
return kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
}
-static void anon_vma_free(struct anon_vma *anon_vma)
+void anon_vma_free(struct anon_vma *anon_vma)
{
kmem_cache_free(anon_vma_cachep, anon_vma);
}
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
maintainers-haavard-has-moved.patch
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
linux-next.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
arch-mips-include-asm-fcntlh-needs-typesh.patch
arch-x86-kernel-entry_64s-fix-build-with-gas-2161.patch
arch-x86-kernel-entry_32s-i386-too.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
drivers-media-video-cx23885-cx23885-corec-fix-cx23885_dev_checkrevision.patch
fs-notify-fanotify-fanotify_userc-fix-warnings.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-low-threshold-to-pwm-backlight.patch
serial8250-ratelimit-too-much-work-error-fix.patch
serial8250-ratelimit-too-much-work-error-fix-fix.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
drivers-message-fusion-mptsasc-fix-warning.patch
vfs-allow-mnt_want_write-to-sleep-fix.patch
mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled-cleanup.patch
memory-hotplug-unify-is_removable-and-offline-detection-code-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-checkpatch-fixes.patch
rmap-make-anon_vma_free-static-fix.patch
vmstat-include-compactionh-when-config_compaction-fix.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
hpet-factor-timer-allocate-from-open-fix.patch
m68k-__pa-cast-arg-to-long.patch
kernelh-add-minmax3-macros-fix.patch
include-linux-kernelh-add-__must_check-to-strict_strto.patch
printk-declare-printk_ratelimit_state-in-ratelimith-fix.patch
vsprintfc-use-default-pointer-field-size-for-null-strings-fix.patch
scripts-get_maintainerpl-add-git-blame-rolestats-authored-lines-information.patch
idr-fix-idr_pre_get-locking-description-fix.patch
checkpatch-returning-errno-typically-should-be-negative.patch
select-rename-estimate_accuracy-to-select_estimate_accuracy.patch
vcs-add-poll-fasync-support-fix-fix.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions-checkpatch-fixes.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection-checkpatch-fixes.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2-checkpatch-fixes.patch
drivers-char-hvc_consolec-remove-unneeded-__set_current_statetask_running.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
fuse-use-release_pages.patch
pps-add-async-pps-event-handler-fix.patch
memstick-add-driver-for-ricoh-r5c592-card-reader-fix.patch
kernel-resourcec-handle-reinsertion-of-an-already-inserted-resource.patch
ramoops-use-the-platform-data-structure-instead-of-module-params-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
getblk-handle-2tb-devices.patch
^ permalink raw reply
* RE: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
From: Savoy, Pavan @ 2010-10-07 20:17 UTC (permalink / raw)
To: Alan Cox
Cc: Jiri Slaby, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org, linux-bluetooth@vger.kernel.org
In-Reply-To: <20101007213503.657bcab0@lxorguk.ukuu.org.uk>
> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Thursday, October 07, 2010 3:35 PM
> To: Savoy, Pavan
> Cc: Jiri Slaby; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@driverdev.osuosl.org; linux-bluetooth@vger.kernel.org
> Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
>
> > ldisc is the ONLY way to do it, isn't it? Do I have any other option?
>
> Userspace but even then it wouldn't solve your problem
>
> > The situation was something similar here.
> > What I was trying to get to is how we can have a per-device context if a
> driver is just a line discipline driver?
>
> tty->driver_data
> TTY private data
> tty->disc_data
> LDISC per instance private data
>
> So when your ldisc is opened attach your data to the tty->disc_data, and
> when it is closed free the data.
But, I want to attach my data not when ldsic is opened, but when ldisc is registered.
I want to begin accessing the data when ldisc is opened.
> > I have 3 sub-devices if you will on a device which is interfaced over UART,
> > One of them is Bluetooth which requires any UART Bluetooth device to have
> its
> > Own line discipline - N_HCI.
>
> The problem is that your chip by the sound of it does not talk the
> bluetooth ldisc - it talks something more complex.
>
> The obvious question then is
>
> Does it talk
>
> 1. HCI with bits nailed on
> 2. Something rather different which contains muxed data some of
> which is reformatted up to create HCI
>
> In the first case it may be worth seeing if the existing N_HCI could
> support forwarding unknown frame types to a helper. In the latter it's a
> lot trickier. It is possible to create a mux tty layer (see n_gsm.c) but
> that is almost certainly overkill for this.
>
> I wonder what Marcel thinks in terms of re-using the bluetooth ldisc ?
Yes, Marcel did suggest extending N_HCI, But even then, there need
to be like a bunch of helpers (1 for FM, 1 for GPS, 1 for NFC, 1 for power-management), also the problem of who owns the /dev/tty begins to occur, Bluetooth has a utility called hciattach, I don't want my FM radio software to run hciattach when /dev/radio0 is opened and communicated via FM.
In any case, the ti-st/ seems better now by look of things, I certainly welcome suggestions to improve it.
Also, is there any plan to re-write whole of TTY like a the i2C or the SPI bus structure?
Here I can imagine, all TTY line disciplines being sort of protocol/client drivers, the TTY sub-system in itself would be like the algos driver and then
The uart drivers (like 8250.c) can be the adapter drivers.. What say?
With something like this all I had to do was to write a new client driver.
^ permalink raw reply
* Re: [msysGit] Re: [PULL] Pull request from msysGit
From: Pat Thoyts @ 2010-10-07 20:18 UTC (permalink / raw)
To: Peter Harris
Cc: Ramsay Jones, Pat Thoyts, Junio C Hamano, git, msysgit,
sschuberth
In-Reply-To: <4CAE1FE6.9020306@opentext.com>
On 7 October 2010 20:30, Peter Harris <pharris@opentext.com> wrote:
> On 2010-10-07 13:17, Ramsay Jones wrote:
>> Now, Peter Harris has already submitted a fix for this, which is
>> currently on the work/msvc-fixes branch, which contains:
>>
>> 358f1be Modify MSVC wrapper script
>> 38bd27d Fix MSVC build
>>
>> The suggested fix is given in commit 38bd27d. However, I prefer a
>> different solution, which is given below:
>>
>> --- >8 ---
>> diff --git a/compat/mingw.h b/compat/mingw.h
>> index afedf3a..445d1a1 100644
>> --- a/compat/mingw.h
>> +++ b/compat/mingw.h
>> @@ -12,12 +12,6 @@ typedef int pid_t;
>> #define S_ISLNK(x) (((x) & S_IFMT) == S_IFLNK)
>> #define S_ISSOCK(x) 0
>>
>> -#ifndef _STAT_H_
>> -#define S_IRUSR 0
>> -#define S_IWUSR 0
>> -#define S_IXUSR 0
>> -#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
>> -#endif
>> #define S_IRGRP 0
>> #define S_IWGRP 0
>> #define S_IXGRP 0
>> --- 8< ---
>>
>> Note that, for *both* MinGW and MSVC, the deleted #defines
>> are not wanted, pointless and just plain wrong! :-D
>
> I didn't realize that the defines were not wanted for MinGW either.
>
> I heartily approve of removing code rather than just ifdefing around it.
> Please use this version of the patch instead of mine.
>
> Peter Harris
The patch in question has been on the msysGit tree for about 10 months
now. Its somewhat disappointing not to have had it spotted before we
pushed it upstream. Are the msvc builders only working against junio's
repository?
Reverting it seems to make no difference to the msysGit build at all -
presumably because S_IRUSR and friends are all defined in the mingw
<sys/stat.h> anyway. Sebastian - can you recall why this got added?
The commit comment is not all that enlightening.
I also wonder why changes to a compat/mingw.h file should affect the
msvc build. As it has it's own compat/vcbuild and headers in there,
surely it should be independent of mingw-gcc compatability headers?
Pat Thoyts
^ permalink raw reply
* [PATCH] Fix LOCALVERSION append plus logic
From: alan.tull @ 2010-10-07 20:18 UTC (permalink / raw)
To: mmarek; +Cc: linux-kbuild, linux-kernel, Alan Tull
From: Alan Tull <alan.tull@freescale.com>
This change fixes the logic to do what the comment says
when CONFIG_LOCALVERSION_AUTO and CONFIG_LOCALVERSION are
both not set.
Also fix a spelling error in the comment.
If the kernel tree is in git, here's the config
permutations (with CONFIG_LOCALVERSION_AUTO turned off)
and the image name resulting:
CONFIG_LOCALVERSION=""
results:
patched : Linux-2.6.35.3+
unpatched : Linux-2.6.35.3
CONFIG_LOCALVERSION="-something"
results:
patched : Linux-2.6.35.3-something
unpatched : Linux-2.6.35.3-something+
Signed-off-by: Alan Tull <alan.tull@freescale.com>
---
scripts/setlocalversion | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 64a9cb5..4488a33 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -160,9 +160,9 @@ if test "$CONFIG_LOCALVERSION_AUTO" = "y"; then
# full scm version string
res="$res$(scm_version)"
else
- # apped a plus sign if the repository is not in a clean tagged
+ # append a plus sign if the repository is not in a clean tagged
# state and LOCALVERSION= is not specified
- if test "${LOCALVERSION+set}" != "set"; then
+ if test "$CONFIG_LOCALVERSION" = ""; then
scm=$(scm_version --short)
res="$res${scm:++}"
fi
--
1.6.0.4
^ permalink raw reply related
* [PATCH] Fix LOCALVERSION append plus logic
From: alan.tull @ 2010-10-07 20:18 UTC (permalink / raw)
To: mmarek; +Cc: linux-kbuild, linux-kernel, Alan Tull
From: Alan Tull <alan.tull@freescale.com>
This change fixes the logic to do what the comment says
when CONFIG_LOCALVERSION_AUTO and CONFIG_LOCALVERSION are
both not set.
Also fix a spelling error in the comment.
If the kernel tree is in git, here's the config
permutations (with CONFIG_LOCALVERSION_AUTO turned off)
and the image name resulting:
CONFIG_LOCALVERSION=""
results:
patched : Linux-2.6.35.3+
unpatched : Linux-2.6.35.3
CONFIG_LOCALVERSION="-something"
results:
patched : Linux-2.6.35.3-something
unpatched : Linux-2.6.35.3-something+
Signed-off-by: Alan Tull <alan.tull@freescale.com>
---
scripts/setlocalversion | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 64a9cb5..4488a33 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -160,9 +160,9 @@ if test "$CONFIG_LOCALVERSION_AUTO" = "y"; then
# full scm version string
res="$res$(scm_version)"
else
- # apped a plus sign if the repository is not in a clean tagged
+ # append a plus sign if the repository is not in a clean tagged
# state and LOCALVERSION= is not specified
- if test "${LOCALVERSION+set}" != "set"; then
+ if test "$CONFIG_LOCALVERSION" = ""; then
scm=$(scm_version --short)
res="$res${scm:++}"
fi
--
1.6.0.4
^ permalink raw reply related
* Re: 2.6.36-rc7 warning in __cfg80211_auth_remove
From: Johannes Berg @ 2010-10-07 20:19 UTC (permalink / raw)
To: Johannes Stezenbach; +Cc: linux-wireless
In-Reply-To: <20101007151844.GB3183@sig21.net>
On Thu, 2010-10-07 at 17:18 +0200, Johannes Stezenbach wrote:
> Hi,
>
> just got the following while testing with rt73usb on
> kernel 2.6.36-rc7 with wpa_supplicant v0.6.10:
>
> wlan0: authentication with 00:22:b0:xx:xx:xx timed out
> ------------[ cut here ]------------
> WARNING: at net/wireless/mlme.c:284 __cfg80211_auth_remove+0xc3/0xd0 [cfg80211]()
> [<ffffffffa002d980>] __cfg80211_auth_remove+0xc3/0xd0 [cfg80211]
> [<ffffffffa002e27c>] cfg80211_send_auth_timeout+0x93/0xaa [cfg80211]
> [<ffffffffa004c3eb>] ieee80211_probe_auth_done+0x2a/0x97 [mac80211]
> [<ffffffffa004e551>] ieee80211_work_work+0xecd/0xf3e [mac80211]
Oh *crap*. I thought we'd fixed these :-(
But then I really don't see how it might have happened. Was there
anything in the log before this?
johannes
^ permalink raw reply
* Re: libgee_0.6.0: gee/Makefile.am:95: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
From: Dr. Michael Lauer @ 2010-10-07 20:28 UTC (permalink / raw)
To: Steve Sakoman; +Cc: openembedded-devel@lists.openembedded.org
In-Reply-To: <AANLkTi=nS_3emPJsndTjjAM=cPwwc=pW0Ktk7DJwEj++@mail.gmail.com>
That probably needs to be converted into a DEPENDS.
Cheers,
:M:
Am 07.10.2010 um 21:35 schrieb Steve Sakoman <sakoman@gmail.com>:
> On Wed, Oct 6, 2010 at 4:33 PM, Paul Menzel
> <paulepanter@users.sourceforge.net> wrote:
>> Dear OE folks,
>>
>>
>> `configure` fails for me for `libgee_0.6.0.bb` [1].
>>
>> | gee/Makefile.am:95: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
>>
>> `libgee_0.5.2.bb` builds correctly because it does not yet use gobject-introspection.
>>
>> This question was brought up before but was left unanswered [2].
>>
>> There was no file `introspection.m4`, where `HAVE_INTROSPECTION` is
>> defined in, in
>>
>> …/work/armv7a-oe-linux-gnueabi/libgee-1_0.6.0-r1/libgee-0.6.0/m4
>>
>> as recommended in [3]. Should the m4 file be copied there as it is done
>> for the other m4 files?
>>
>> […]
>> | autoreconf: configure.ac: tracing
>> | autoreconf: running: libtoolize --copy --force
>> | libtoolize: putting auxiliary files in `.'.
>> | libtoolize: copying file `./ltmain.sh'
>> | libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
>> | libtoolize: copying file `m4/libtool.m4'
>> | libtoolize: copying file `m4/ltoptions.m4'
>> | libtoolize: copying file `m4/ltsugar.m4'
>> | libtoolize: copying file `m4/ltversion.m4'
>> | libtoolize: copying file `m4/lt~obsolete.m4'
>> […]
>>
>> I manually put the m4 file [4] into `libgee-0.6.0/m4/` and added
>> `m4/introspection.m4` to `EXTRA_DIST` in `Makefile.am` to `` but
>>
>> bitbake -c configure libgee
>>
>> still failed.
>>
>> Do you have any ideas?
>
> I found that if I built gobject-introspection-native manually, then
> libgee would complete without error.
>
> The DEPENDS_virtclass-native = "gobject-introspection-native" in the
> libgee recipe isn't triggering the build automatically.
>
> Steve
^ 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.