* Re: [Patch 2/2] tracepoints for softirq entry/exit - tracepoints
From: Mathieu Desnoyers @ 2009-03-16 19:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jason Baron, mingo, linux-kernel, acme, fweisbec, fche, peterz
In-Reply-To: <alpine.DEB.2.00.0903161446510.27978@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
>
> On Mon, 16 Mar 2009, Steven Rostedt wrote:
>
> >
> > On Mon, 16 Mar 2009, Mathieu Desnoyers wrote:
> > > > >
> > > > > The softirq tracepoints are a good idea indeed (I have similar ones in
> > > > > the LTTng tree). My main concern is about the fact that you output the
> > > > > softirq name in plain text to the trace buffers. I would rather prefer
> > > > > to save only the softirq (h-vec) into the trace and dump the mapping
> > > > > (h-vec) to name only once, so we can save precious trace bytes.
> > > >
> > > > The TP_FMT is only used by those tracers that want to use it. Any tracer
> > > > can still hook directly to the trace point and do what every they want.
> > > >
> > > > -- Steve
> > > >
> > >
> > > By doing so, you are removing the ability to use the TP_FMT information
> > > to perform high-speed system-wide tracing. I thought the goal was to
> > > create a unified buffering, but sadly I don't see the high-speed
> > > requirements being part of that plan.
> >
> > TP_FMT has nothing to do with the unified buffering. The unified buffer
> > does not even know about it. But if you want high-speed event tracing,
> > that is what the TRACE_EVENT was created for.
>
> Here's an example:
>
> The "event tracing" uses the format field to show those events for the
> hook in the sched switching, and wake ups.
>
> The wake up tracer on the other hand, does not care about the format, it
> only cares about having a hook where a a task is woken up, and where it
> gets scheduled in, and perhaps events in between. But it uses its own
> formatting to do the output.
>
> -- Steve
>
If I understand you correctly, the format string is only useful to the
text-output tracer ? Why can't it be used to identify both text and
binary events ?
And remember that from my perspective, information is only useful if
available for system-wide tracing. Specialized tracers come as a subset
of system-wide tracing anyway when the latter is implemented with the
proper hooks.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: [aarcange@redhat.com: [PATCH] fork vs gup(-fast) fix]
From: Linus Torvalds @ 2009-03-16 19:22 UTC (permalink / raw)
To: Nick Piggin
Cc: KOSAKI Motohiro, Benjamin Herrenschmidt, Andrea Arcangeli,
Ingo Molnar, Nick Piggin, Hugh Dickins, KAMEZAWA Hiroyuki,
linux-mm
In-Reply-To: <200903170533.48423.nickpiggin@yahoo.com.au>
On Tue, 17 Mar 2009, Nick Piggin wrote:
>
> > So is all the extra flags for no
> > good reason.
>
> Which extra flags are you referring to?
Fuck me, didn't you even read your own patch?
What do you call PG_dontcow?
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2] memory_accessor: new interface for reading/writing persistent memory
From: David Brownell @ 2009-03-16 19:27 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-kernel
In-Reply-To: <1236478048-11075-1-git-send-email-khilman@deeprootsystems.com>
I was kind of hoping you'd address the locking and chunking
comments I made ... I'll ack if it includes something like
the appended patch.
---
drivers/misc/eeprom/at24.c | 43 ++++++++++++++++++++++++++++---------------
1 file changed, 28 insertions(+), 15 deletions(-)
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -226,14 +226,11 @@ static ssize_t at24_eeprom_read(struct a
return status;
}
-static ssize_t at24_bin_read(struct kobject *kobj, struct bin_attribute *attr,
+static ssize_t at24_read(struct at24_data *at24,
char *buf, loff_t off, size_t count)
{
- struct at24_data *at24;
ssize_t retval = 0;
- at24 = dev_get_drvdata(container_of(kobj, struct device, kobj));
-
if (unlikely(!count))
return count;
@@ -263,6 +260,15 @@ static ssize_t at24_bin_read(struct kobj
return retval;
}
+static ssize_t at24_bin_read(struct kobject *kobj, struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct at24_data *at24;
+
+ at24 = dev_get_drvdata(container_of(kobj, struct device, kobj));
+ return at24_read(at24, buf, off, count);
+}
+
/*
* Note that if the hardware write-protect pin is pulled high, the whole
@@ -341,14 +347,11 @@ static ssize_t at24_eeprom_write(struct
return -ETIMEDOUT;
}
-static ssize_t at24_bin_write(struct kobject *kobj, struct bin_attribute *attr,
+static ssize_t at24_write(struct at24_data *at24,
char *buf, loff_t off, size_t count)
{
- struct at24_data *at24;
ssize_t retval = 0;
- at24 = dev_get_drvdata(container_of(kobj, struct device, kobj));
-
if (unlikely(!count))
return count;
@@ -378,6 +381,15 @@ static ssize_t at24_bin_write(struct kob
return retval;
}
+static ssize_t at24_bin_write(struct kobject *kobj, struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct at24_data *at24;
+
+ at24 = dev_get_drvdata(container_of(kobj, struct device, kobj));
+ return at24_write(at24, buf, off, count);
+}
+
/*-------------------------------------------------------------------------*/
/*
@@ -386,20 +398,20 @@ static ssize_t at24_bin_write(struct kob
* data generated on the manufacturing floor.
*/
-static ssize_t at24_read(struct memory_accessor *macc, char *buf,
+static ssize_t at24_macc_read(struct memory_accessor *macc, char *buf,
off_t offset, size_t count)
{
struct at24_data *at24 = container_of(macc, struct at24_data, macc);
- return at24_eeprom_read(at24, buf, offset, count);
+ return at24_read(at24, buf, offset, count);
}
-static ssize_t at24_write(struct memory_accessor *macc, char *buf,
+static ssize_t at24_macc_write(struct memory_accessor *macc, char *buf,
off_t offset, size_t count)
{
struct at24_data *at24 = container_of(macc, struct at24_data, macc);
- return at24_eeprom_write(at24, buf, offset, count);
+ return at24_write(at24, buf, offset, count);
}
/*-------------------------------------------------------------------------*/
@@ -470,9 +482,6 @@ static int at24_probe(struct i2c_client
goto err_out;
}
- at24->macc.read = at24_read;
- at24->macc.write = at24_write;
-
mutex_init(&at24->lock);
at24->use_smbus = use_smbus;
at24->chip = chip;
@@ -487,6 +496,8 @@ static int at24_probe(struct i2c_client
at24->bin.read = at24_bin_read;
at24->bin.size = chip.byte_len;
+ at24->macc.read = at24_macc_read;
+
writable = !(chip.flags & AT24_FLAG_READONLY);
if (writable) {
if (!use_smbus || i2c_check_functionality(client->adapter,
@@ -494,6 +505,8 @@ static int at24_probe(struct i2c_client
unsigned write_max = chip.page_size;
+ at24->macc.write = at24_macc_write;
+
at24->bin.write = at24_bin_write;
at24->bin.attr.mode |= S_IWUSR;
^ permalink raw reply
* [Buildroot] svn commit: [25683] trunk/buildroot: package project
From: Peter Korsgaard @ 2009-03-16 19:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20090316200849.2beaada3@surf>
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
Thomas> I haven't read the whole patch in its context, but from a
Thomas> quick look, I would I've written:
Thomas> PKG_CONFIG="$(HOST_DIR)/usr/bin/pkg-config" \
Thomas> PKG_CONFIG_PATH="$(STAGING_DIR)/usr/lib/pkgconfig/:$(PKG_CONFIG_PATH)"
Thomas> since the pkg-config binary compiled by Buildroot should probably be
Thomas> installed in $(HOST_DIR) (since it's a host binary) and the .pc files
Thomas> for the target architecture are installed in
Thomas> $(STAGING_DIR)/usr/lib/pkgconfig.
Yes, but I didn't want to move pkgconfig just yet. The PKG_CONFIG_PATH
is correct though, as this is HOST_CONFIGURE_OPTS, E.G. the options to
configure where you're compiling for the host.
I'll move over the existing host tools (pkgconfig, auto*, libtool)
soonish.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: ext2/3: document conditions when reliable operation is possible
From: Rob Landley @ 2009-03-16 19:26 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, Andrew Morton, mtk.manpages, tytso, rdunlap,
linux-doc, linux-ext4
In-Reply-To: <20090316122847.GI2405@elf.ucw.cz>
On Monday 16 March 2009 07:28:47 Pavel Machek wrote:
> Hi!
> > > + Fortunately writes failing are very uncommon on traditional
> > > + spinning disks, as they have spare sectors they use when write
> > > + fails.
> >
> > I vaguely recall that the behavior of when a write error _does_ occur is
> > to remount the filesystem read only? (Is this VFS or per-fs?)
>
> Per-fs.
Might be nice to note that in the doc.
> > Is there any kind of hotplug event associated with this?
>
> I don't think so.
There probably should be, but that's a separate issue.
> > I'm aware write errors shouldn't happen, and by the time they do it's too
> > late to gracefully handle them, and all we can do is fail. So how do we
> > fail?
>
> Well, even remount-ro may be too late, IIRC.
Care to elaborate? (When a filesystem is mounted RO, I'm not sure what
happens to the pages that have already been dirtied...)
> > (Writes aren't always cleanly at the start of an erase block, so critical
> > data _before_ what you touch is endangered too.)
>
> Well, flashes do remap, so it is actually "random blocks".
Fun.
When "please do not turn of your playstation until game save completes"
honestly seems like the best solution for making the technology reliable,
something is wrong with the technology.
I think I'll stick with rotating disks for now, thanks.
> > > + otherwise, disks may write garbage during powerfail.
> > > + Not sure how common that problem is on generic PC machines.
> > > +
> > > + Note that atomic write is very hard to guarantee for RAID-4/5/6,
> > > + because it needs to write both changed data, and parity, to
> > > + different disks.
> >
> > These days instead of "atomic" it's better to think in terms of
> > "barriers".
>
> This is not about barriers (that should be different topic). Atomic
> write means that either whole sector is written, or nothing at all is
> written. Because raid5 needs to update both master data and parity at
> the same time, I don't think it can guarantee this during powerfail.
Good point, but I thought that's what journaling was for?
I'm aware that any flash filesystem _must_ be journaled in order to work
sanely, and must be able to view the underlying erase granularity down to the
bare metal, through any remapping the hardware's doing. Possibly what's
really needed is a "flash is weird" section, since flash filesystems can't be
mounted on arbitrary block devices.
Although an "-O erase_size=128" option so they _could_ would be nice. There's
"mtdram" which seems to be the only remaining use for ram disks, but why there
isn't an "mtdwrap" that works with arbitrary underlying block devices, I have
no idea. (Layering it on top of a loopback device would be most useful.)
> > > +Requirements
> > > +* write errors not allowed
> > > +
> > > +* sector writes are atomic
> > > +
> > > +(see expectations.txt; note that most/all linux block-based
> > > +filesystems have similar expectations)
> > > +
> > > +* write caching is disabled. ext2 does not know how to issue barriers
> > > + as of 2.6.28. hdparm -W0 disables it on SATA disks.
> >
> > And here we're talking about ext2. Does neither one know about write
> > barriers, or does this just apply to ext2? (What about ext4?)
>
> This document is about ext2. Ext3 can support barriers in
> 2.6.28. Someone else needs to write ext4 docs :-).
>
> > Also I remember a historical problem that not all disks honor write
> > barriers, because actual data integrity makes for horrible benchmark
> > numbers. Dunno how current that is with SATA, Alan Cox would probably
> > know.
>
> Sounds like broken disk, then. We should blacklist those.
It wasn't just one brand of disk cheating like that, and you'd have to ask him
(or maybe Jens Axboe or somebody) whether the problem is still current. I've
been off in embedded-land for a few years now...
Rob
^ permalink raw reply
* Re: [crash] Re: Latest brk patchset
From: Jeremy Fitzhardinge @ 2009-03-16 19:25 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <49BE97D5.4010002@zytor.com>
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>> Yinghai Lu wrote:
>>> could be max_pfn_mapped change in head_32.S that reduce mapping
>>> range to _end only.
>>>
>>
>> Yes, I would say you're right. Trimming the mapping to _end only
>> leaves the space under the kernel avaliable for allocating pagetable
>> from e820 space. In this case we've got DEBUG_PAGEALLOC enabled,
>> which inhibits the use of PSE, and BIOS corruption checking on, which
>> eats a chunk of low memory. In combination, there's only 0x8f000
>> bytes free below the kernel, and it needs 0xe1000 to allocate for
>> pagetables.
>>
>> Reverting 2bd2753ff46346543ab92e80df9d96366e21baa5 fixes the problem
>> for me, though it does result in a kernel with a 73MB BSS...
>>
>
> Waitaminute... there is no way we could end up with 73 MB page tables
> unless something is seriously screwy. Even with PAE and !PSE, we only
> get 2 MB worth of page tables for each 1 GB mapped -- even with a 4:4
> scheme this is only 8 MB.
Yes, something odd happened there.
Anyway, this patch fixes it. I also removed ALLOCATOR_SLOP, because it
is left over from when we used the bootmem allocator for the linear
mapping pagetable, before using e820 allocation.
Did you also want to pull the changes to put the brk in .brk and rename
the reservation symbols?
J
The following changes since commit 2bd2753ff46346543ab92e80df9d96366e21baa5:
Yinghai Lu (1):
x86: put initial_pg_tables into .bss
are available in the git repository at:
ssh://master.kernel.org/~jeremy/git/xen.git tip/x86/setup-memory
Jeremy Fitzhardinge (2):
x86-32: make sure we map enough to fit linear map pagetables
x86-32: remove ALLOCATOR_SLOP from head_32.S
arch/x86/kernel/head_32.S | 32 ++++++++++++++++++++------------
1 files changed, 20 insertions(+), 12 deletions(-)
>From 378c46828de3f34d94d83f08b2d6d81a0fc8f108 Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date: Mon, 16 Mar 2009 12:07:54 -0700
Subject: [PATCH] x86-32: make sure we map enough to fit linear map pagetables
head_32.S needs to map the kernel itself, and enough space so
that mm/init.c can allocate space from the e820 allocator
for the linear map of low memory.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index c79741c..e929619 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -38,8 +38,8 @@
#define X86_VENDOR_ID new_cpu_data+CPUINFO_x86_vendor_id
/*
- * This is how much memory *in addition to the memory covered up to
- * and including _end* we need mapped initially.
+ * This is how much memory in addition to the memory covered up to
+ * and including _end we need mapped initially.
* We need:
* (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
* (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
@@ -52,19 +52,28 @@
* KERNEL_IMAGE_SIZE should be greater than pa(_end)
* and small than max_low_pfn, otherwise will waste some page table entries
*/
-LOW_PAGES = (KERNEL_IMAGE_SIZE + PAGE_SIZE_asm - 1)>>PAGE_SHIFT
#if PTRS_PER_PMD > 1
-PAGE_TABLE_SIZE = (LOW_PAGES / PTRS_PER_PMD) + PTRS_PER_PGD
+#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) + PTRS_PER_PGD)
#else
-PAGE_TABLE_SIZE = (LOW_PAGES / PTRS_PER_PGD)
+#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
#endif
ALLOCATOR_SLOP = 4
-INIT_MAP_SIZE = (PAGE_TABLE_SIZE + ALLOCATOR_SLOP) * PAGE_SIZE_asm
-RESERVE_BRK(pagetables, INIT_MAP_SIZE)
+/* Enough space to fit pagetables for the low memory linear map */
+MAPPING_BEYOND_END = (PAGE_TABLE_SIZE(1 << (32 - PAGE_SHIFT)) * PAGE_SIZE)
/*
+ * Worst-case size of the kernel mapping we need to make:
+ * the worst-case size of the kernel itself, plus the extra we need
+ * to map for the linear map.
+ */
+KERNEL_PAGES = (KERNEL_IMAGE_SIZE + MAPPING_BEYOND_END)>>PAGE_SHIFT
+
+INIT_MAP_SIZE = (PAGE_TABLE_SIZE(KERNEL_PAGES) + ALLOCATOR_SLOP) * PAGE_SIZE_asm
+RESERVE_BRK(pagetables, INIT_MAP_SIZE)
+
+/*
* 32-bit kernel entrypoint; only used by the boot CPU. On entry,
* %esi points to the real-mode code as a 32-bit pointer.
* CS and DS must be 4 GB flat segments, but we don't depend on
@@ -197,9 +206,9 @@ default_entry:
loop 11b
/*
- * End condition: we must map up to the end.
+ * End condition: we must map up to the end + MAPPING_BEYOND_END.
*/
- movl $pa(_end) + PTE_IDENT_ATTR, %ebp
+ movl $pa(_end) + MAPPING_BEYOND_END + PTE_IDENT_ATTR, %ebp
cmpl %ebp,%eax
jb 10b
1:
@@ -229,9 +238,9 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
addl $0x1000,%eax
loop 11b
/*
- * End condition: we must map up to end
+ * End condition: we must map up to the end + MAPPING_BEYOND_END.
*/
- movl $pa(_end) + PTE_IDENT_ATTR, %ebp
+ movl $pa(_end) + MAPPING_BEYOND_END + PTE_IDENT_ATTR, %ebp
cmpl %ebp,%eax
jb 10b
addl $__PAGE_OFFSET, %edi
^ permalink raw reply related
* Re: e100 firmware in 2.6.29-rc7?
From: Ben Hutchings @ 2009-03-16 19:25 UTC (permalink / raw)
To: Ben Greear; +Cc: Brandeburg, Jesse, NetDev, dwmw2, e1000-devel
In-Reply-To: <49BEA4E6.1000206@candelatech.com>
On Mon, 2009-03-16 at 12:13 -0700, Ben Greear wrote:
> Brandeburg, Jesse wrote:
> > On Fri, 13 Mar 2009, Ben Greear wrote:
> >> I have selected build-firmware-into-kernel
> >> but it seems e100 is still unhappy in 2.6.29-rc7.
> >>
> >> e100 0000:02:01.0: firmware: requesting e100/d102e_ucode.bin
> >> e100: eth4: e100_request_firmware: Failed to load firmware "e100/d102e_ucode.bin": -2
> >
> > can you post anything extra about your config? arch? full dmesg? full
> > .config?
> >
> > There have been several other reports of this but setting
> > CONFIG_FIRMWARE_IN_KERNEL=y seems to fix them in general.
> >
> > also please post lspci -vvv -s 2:1.0, after failing to load. I'm curious
> > if the device might be in D3 still.
> >
> > you can likely just get working by commenting out the firmware load for
> > e100. It may or may not re-enable a hardware bug depending upon the
> > hardware you have.
>
> We got it working by copying firmware from another system (FC8) that had
> it in /lib/firmware.
>
> Just retested with -rc8 from Friday, and it is repeatable.
>
> The config & dmesg is attached. Some of the options are for patches we've
> added, and we even have a small patch in the e100 (but have had it there
> for years, so probably un-related to this). Still, I will not complain
> if you decide to ignore the report.
[...]
Your config has CONFIG_E100=m, but CONFIG_FIRMWARE_IN_KERNEL only
applies to firmware used by non-modular drivers. The assumption is that
once userland is capable of loading modules it is also capable of
loading firmware.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] [RFC] c/r: Add UTS support (v2)
From: Serge E. Hallyn @ 2009-03-16 19:25 UTC (permalink / raw)
To: Dan Smith; +Cc: containers-qjLDD68F18O7TbgM5vRIOg
In-Reply-To: <87tz5t6zxh.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
Quoting Dan Smith (danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
> SH> Someone might complain about the per-task namespace data not
> SH> showing up in the per-task data, but I think the way you have it
> SH> simplifies things enough to justify it.
>
> Yeah, mktree would get pretty ugly without doing it ahead of time, I
> think.
>
> SH> Do add a note to Documentation/checkpoint/internals.txt (and maybe
> SH> use __NEW_UTS_LEN+1 instead of 65), but other than that it looks
> SH> good to me.
>
> I was replicating exactly what is in the struct definitions of
> linux/utsname.h, but okay :)
I know. Maybe change those too :)
-serge
^ permalink raw reply
* [PATCH v2] Fix SLAB corruption during rmmod
From: Ivo van Doorn @ 2009-03-16 19:24 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, Arnaud Patard, Gertjan van Wingerde, Dan Williams
In-Reply-To: <200903161925.41102.IvDoorn@gmail.com>
At rmmod stage, the code path is the following one :
rt2x00lib_remove_dev
=C2=A0 -> =C2=A0rt2x00lib_uninitialize()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -> rt2x00rfkill_unregister()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> rfkill_unregister()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -> rt2x00rfkill_free()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> rfkill_free()
The problem is that rfkill_free should not be called after rfkill_regis=
ter
otherwise put_device(&rfkill->dev) will be called 2 times. This patch
fixes this by only calling rt2x00rfkill_free() when rt2x00rfkill_regist=
er()
hasn't been called or has failed.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Tested-by: Arnaud Patard <apatard@mandriva.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
John, this patch is for 2.6.29 and only 2.6.29 since rfkill support its=
elf
was removed from later versions (replaced by input_polldev).
The patch is quite big to be merged in a late state of the release cycl=
e,
but since the SLAB corruption is a serious problem, I hope this can get=
in regardless.
Thanks.
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireles=
s/rt2x00/rt2x00.h
index 39ecf3b..820fdb2 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -687,8 +687,7 @@ struct rt2x00_dev {
*/
#ifdef CONFIG_RT2X00_LIB_RFKILL
unsigned long rfkill_state;
-#define RFKILL_STATE_ALLOCATED 1
-#define RFKILL_STATE_REGISTERED 2
+#define RFKILL_STATE_REGISTERED 1
struct rfkill *rfkill;
struct delayed_work rfkill_work;
#endif /* CONFIG_RT2X00_LIB_RFKILL */
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wire=
less/rt2x00/rt2x00dev.c
index 87c0f2c..e694bb7 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -1105,7 +1105,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00=
dev)
* Register extra components.
*/
rt2x00leds_register(rt2x00dev);
- rt2x00rfkill_allocate(rt2x00dev);
rt2x00debug_register(rt2x00dev);
=20
set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
@@ -1137,7 +1136,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x=
00dev)
* Free extra components
*/
rt2x00debug_deregister(rt2x00dev);
- rt2x00rfkill_free(rt2x00dev);
rt2x00leds_unregister(rt2x00dev);
=20
/*
diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h b/drivers/net/wire=
less/rt2x00/rt2x00lib.h
index 86cd26f..49309d4 100644
--- a/drivers/net/wireless/rt2x00/rt2x00lib.h
+++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
@@ -260,8 +260,6 @@ static inline void rt2x00crypto_rx_insert_iv(struct=
sk_buff *skb,
#ifdef CONFIG_RT2X00_LIB_RFKILL
void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev);
void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev);
-void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev);
-void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev);
#else
static inline void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
{
@@ -270,14 +268,6 @@ static inline void rt2x00rfkill_register(struct rt=
2x00_dev *rt2x00dev)
static inline void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00de=
v)
{
}
-
-static inline void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
-{
-}
-
-static inline void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
-{
-}
#endif /* CONFIG_RT2X00_LIB_RFKILL */
=20
/*
diff --git a/drivers/net/wireless/rt2x00/rt2x00rfkill.c b/drivers/net/w=
ireless/rt2x00/rt2x00rfkill.c
index 3298cae..08ffc6d 100644
--- a/drivers/net/wireless/rt2x00/rt2x00rfkill.c
+++ b/drivers/net/wireless/rt2x00/rt2x00rfkill.c
@@ -94,14 +94,50 @@ static void rt2x00rfkill_poll(struct work_struct *w=
ork)
&rt2x00dev->rfkill_work, RFKILL_POLL_INTERVAL);
}
=20
+static int rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
+{
+ struct device *dev =3D wiphy_dev(rt2x00dev->hw->wiphy);
+
+ rt2x00dev->rfkill =3D rfkill_allocate(dev, RFKILL_TYPE_WLAN);
+ if (!rt2x00dev->rfkill)
+ return -ENOMEM;
+
+ rt2x00dev->rfkill->name =3D rt2x00dev->ops->name;
+ rt2x00dev->rfkill->data =3D rt2x00dev;
+ rt2x00dev->rfkill->toggle_radio =3D rt2x00rfkill_toggle_radio;
+ if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags)) {
+ rt2x00dev->rfkill->get_state =3D rt2x00rfkill_get_state;
+ rt2x00dev->rfkill->state =3D
+ rt2x00dev->ops->lib->rfkill_poll(rt2x00dev) ?
+ RFKILL_STATE_SOFT_BLOCKED : RFKILL_STATE_UNBLOCKED;
+ } else {
+ rt2x00dev->rfkill->state =3D RFKILL_STATE_UNBLOCKED;
+ }
+
+ INIT_DELAYED_WORK(&rt2x00dev->rfkill_work, rt2x00rfkill_poll);
+
+ return 0;
+}
+
+static void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
+{
+ rfkill_free(rt2x00dev->rfkill);
+ rt2x00dev->rfkill =3D NULL;
+}
+
void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
{
- if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
- test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
+ if (test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
+ return;
+
+ if (rt2x00rfkill_allocate(rt2x00dev)) {
+ ERROR(rt2x00dev, "Failed to allocate rfkill handler.\n");
return;
+ }
=20
if (rfkill_register(rt2x00dev->rfkill)) {
ERROR(rt2x00dev, "Failed to register rfkill handler.\n");
+ rt2x00rfkill_free(rt2x00dev);
return;
}
=20
@@ -117,8 +153,7 @@ void rt2x00rfkill_register(struct rt2x00_dev *rt2x0=
0dev)
=20
void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
{
- if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
- !test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
+ if (!test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
return;
=20
cancel_delayed_work_sync(&rt2x00dev->rfkill_work);
@@ -127,46 +162,3 @@ void rt2x00rfkill_unregister(struct rt2x00_dev *rt=
2x00dev)
=20
__clear_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state);
}
-
-void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
-{
- struct device *dev =3D wiphy_dev(rt2x00dev->hw->wiphy);
-
- if (test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state))
- return;
-
- rt2x00dev->rfkill =3D rfkill_allocate(dev, RFKILL_TYPE_WLAN);
- if (!rt2x00dev->rfkill) {
- ERROR(rt2x00dev, "Failed to allocate rfkill handler.\n");
- return;
- }
-
- __set_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state);
-
- rt2x00dev->rfkill->name =3D rt2x00dev->ops->name;
- rt2x00dev->rfkill->data =3D rt2x00dev;
- rt2x00dev->rfkill->toggle_radio =3D rt2x00rfkill_toggle_radio;
- if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags)) {
- rt2x00dev->rfkill->get_state =3D rt2x00rfkill_get_state;
- rt2x00dev->rfkill->state =3D
- rt2x00dev->ops->lib->rfkill_poll(rt2x00dev) ?
- RFKILL_STATE_SOFT_BLOCKED : RFKILL_STATE_UNBLOCKED;
- } else {
- rt2x00dev->rfkill->state =3D RFKILL_STATE_UNBLOCKED;
- }
-
- INIT_DELAYED_WORK(&rt2x00dev->rfkill_work, rt2x00rfkill_poll);
-
- return;
-}
-
-void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
-{
- if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state))
- return;
-
- cancel_delayed_work_sync(&rt2x00dev->rfkill_work);
-
- rfkill_free(rt2x00dev->rfkill);
- rt2x00dev->rfkill =3D NULL;
-}
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" 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 related
* [Qemu-devel] [PATCH] [RFC] Syncing documentation vs. -help vs. qemu_options table v2
From: Blue Swirl @ 2009-03-16 19:23 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
Hi,
I converted all options to the new system. Because of problems with #
and ' characters, I had to move from CPP to a Perl scripts. I'm sure
any Perl expert worth their salt could compress the scripts much
further. A comment token (HXCOMM?, deleted while parsing) would be
nice, then there could be comments that describe the syntax and usage
on top of options.hx.
Comments? Objections?
A related idea: maybe the machine definition files should also enclose
a mandatory TEXI description, leading to a generated list of machines
and their devices for qemu-doc.texi.
[-- Attachment #2: option_system.diff.bz2 --]
[-- Type: application/x-bzip2, Size: 21919 bytes --]
^ permalink raw reply
* Re: [aarcange@redhat.com: [PATCH] fork vs gup(-fast) fix]
From: Linus Torvalds @ 2009-03-16 19:17 UTC (permalink / raw)
To: Nick Piggin
Cc: KOSAKI Motohiro, Benjamin Herrenschmidt, Andrea Arcangeli,
Ingo Molnar, Nick Piggin, Hugh Dickins, KAMEZAWA Hiroyuki,
linux-mm
In-Reply-To: <200903170529.08995.nickpiggin@yahoo.com.au>
On Tue, 17 Mar 2009, Nick Piggin wrote:
>
> What's buggy about it? Stupid bugs, or fundamentally broken?
The lack of locking.
> In my opinion it is not, given that you have to convert callers. If you
> say that you only care about fixing O_DIRECT, then yes I would probably
> agree the lock is nicer in that case.
F*ck me, I'm not going to bother to argue. I'm not going to merge your
patch, it's that easy.
Quite frankly, I don't think that the "bug" is a bug to begin with.
O_DIRECT+fork() can damn well continue to be broken. But if we fix it, we
fix it the _clean_ way with a simple patch, not with that shit-for-logic
horrible decow crap.
It's that simple. I refuse to take putrid industrial waste patches for
something like this.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Patch 2/2] tracepoints for softirq entry/exit - tracepoints
From: Mathieu Desnoyers @ 2009-03-16 19:23 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jason Baron, mingo, linux-kernel, acme, fweisbec, fche, peterz
In-Reply-To: <alpine.DEB.2.00.0903161441210.27978@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
>
> On Mon, 16 Mar 2009, Mathieu Desnoyers wrote:
> > > >
> > > > The softirq tracepoints are a good idea indeed (I have similar ones in
> > > > the LTTng tree). My main concern is about the fact that you output the
> > > > softirq name in plain text to the trace buffers. I would rather prefer
> > > > to save only the softirq (h-vec) into the trace and dump the mapping
> > > > (h-vec) to name only once, so we can save precious trace bytes.
> > >
> > > The TP_FMT is only used by those tracers that want to use it. Any tracer
> > > can still hook directly to the trace point and do what every they want.
> > >
> > > -- Steve
> > >
> >
> > By doing so, you are removing the ability to use the TP_FMT information
> > to perform high-speed system-wide tracing. I thought the goal was to
> > create a unified buffering, but sadly I don't see the high-speed
> > requirements being part of that plan.
>
> TP_FMT has nothing to do with the unified buffering. The unified buffer
> does not even know about it. But if you want high-speed event tracing,
> that is what the TRACE_EVENT was created for.
>
> The TRACE_FORMAT was made for things that will be recording string
> information anyway, and recording a string into the buffer via memcpy or a
> sprintf format (binary printk) doesn't make much difference.
>
Are you saying that dynamically parsing a format string in a binary
printk has the same performance impact as a memcpy ? I would be very
interested to see your benchmarks.
Mathieu
> Then trace points for entry and exit does not fall into that category, and
> should be represented by a TRACE_EVENT instead.
>
> -- Steve
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* [cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
From: Hans Verkuil @ 2009-03-16 19:22 UTC (permalink / raw)
To: linux-media
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date: Mon Mar 16 19:00:03 CET 2009
path: http://www.linuxtv.org/hg/v4l-dvb
changeset: 11038:626c136ec221
gcc version: gcc (GCC) 4.3.1
hardware: x86_64
host os: 2.6.26
linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29-rc8-armv5: OK
linux-2.6.27-armv5-ixp: OK
linux-2.6.28-armv5-ixp: OK
linux-2.6.29-rc8-armv5-ixp: OK
linux-2.6.28-armv5-omap2: OK
linux-2.6.29-rc8-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29-rc8-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29-rc8-m32r: OK
linux-2.6.22.19-mips: OK
linux-2.6.26-mips: OK
linux-2.6.27-mips: OK
linux-2.6.28-mips: OK
linux-2.6.29-rc8-mips: OK
linux-2.6.27-powerpc64: OK
linux-2.6.28-powerpc64: OK
linux-2.6.29-rc8-powerpc64: OK
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: WARNINGS
linux-2.6.28-x86_64: WARNINGS
linux-2.6.29-rc8-x86_64: WARNINGS
fw/apps: WARNINGS
sparse (linux-2.6.28): ERRORS
sparse (linux-2.6.29-rc8): ERRORS
Detailed results are available here:
http://www.xs4all.nl/~hverkuil/logs/Monday.log
Full logs are available here:
http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2
The V4L2 specification from this daily build is here:
http://www.xs4all.nl/~hverkuil/spec/v4l2.html
The DVB API specification from this daily build is here:
http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf
^ permalink raw reply
* Re: [PATCH] Fix SLAB corruption during
From: Ivo van Doorn @ 2009-03-16 19:21 UTC (permalink / raw)
To: Dan Williams
Cc: John W. Linville, linux-wireless, Arnaud Patard,
Gertjan van Wingerde
In-Reply-To: <1237230930.16956.66.camel@localhost.localdomain>
On Monday 16 March 2009, Dan Williams wrote:
> On Mon, 2009-03-16 at 19:25 +0100, Ivo van Doorn wrote:
> > At rmmod stage, the code path is the following one :
> >
> > rt2x00lib_remove_dev
> > -> rt2x00lib_uninitialize()
> > -> rt2x00rfkill_unregister()
> > -> rfkill_unregister()
> > -> rt2x00rfkill_free()
> > -> rfkill_free()
> >
> > The problem is that rfkill_free should not be called after rfkill_free
> > otherwise put_device(&rfkill->dev) will be called 2 times. This patch
> > fix this by removing the call to rfkill_free
>
> Needs a better patch title :) During what? And I assume you mean
> "rfkill_free() should not be called after rfkill_unregister(), right?
Oops, me and copy & pasting. :)
Will resend with correct information.
Ivo
> Dan
>
> > Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
> > Tested-by: Arnaud Patard <apatard@mandriva.com>
> > Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> >
> > ---
> > John, this patch is for 2.6.29 and only 2.6.29 since rfkill support itself
> > was removed from later versions (replaced by input_polldev).
> > The patch is quite big to be merged in a late state of the release cycle,
> > but since the SLAB corruption is a serious problem, I hope this can get in regardless.
> >
> > Thanks.
> >
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
> > index 39ecf3b..820fdb2 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00.h
> > +++ b/drivers/net/wireless/rt2x00/rt2x00.h
> > @@ -687,8 +687,7 @@ struct rt2x00_dev {
> > */
> > #ifdef CONFIG_RT2X00_LIB_RFKILL
> > unsigned long rfkill_state;
> > -#define RFKILL_STATE_ALLOCATED 1
> > -#define RFKILL_STATE_REGISTERED 2
> > +#define RFKILL_STATE_REGISTERED 1
> > struct rfkill *rfkill;
> > struct delayed_work rfkill_work;
> > #endif /* CONFIG_RT2X00_LIB_RFKILL */
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
> > index 87c0f2c..e694bb7 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> > @@ -1105,7 +1105,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
> > * Register extra components.
> > */
> > rt2x00leds_register(rt2x00dev);
> > - rt2x00rfkill_allocate(rt2x00dev);
> > rt2x00debug_register(rt2x00dev);
> >
> > set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
> > @@ -1137,7 +1136,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
> > * Free extra components
> > */
> > rt2x00debug_deregister(rt2x00dev);
> > - rt2x00rfkill_free(rt2x00dev);
> > rt2x00leds_unregister(rt2x00dev);
> >
> > /*
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h b/drivers/net/wireless/rt2x00/rt2x00lib.h
> > index 86cd26f..49309d4 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00lib.h
> > +++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
> > @@ -260,8 +260,6 @@ static inline void rt2x00crypto_rx_insert_iv(struct sk_buff *skb,
> > #ifdef CONFIG_RT2X00_LIB_RFKILL
> > void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev);
> > void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev);
> > -void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev);
> > -void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev);
> > #else
> > static inline void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
> > {
> > @@ -270,14 +268,6 @@ static inline void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
> > static inline void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
> > {
> > }
> > -
> > -static inline void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
> > -{
> > -}
> > -
> > -static inline void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
> > -{
> > -}
> > #endif /* CONFIG_RT2X00_LIB_RFKILL */
> >
> > /*
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00rfkill.c b/drivers/net/wireless/rt2x00/rt2x00rfkill.c
> > index 3298cae..08ffc6d 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00rfkill.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00rfkill.c
> > @@ -94,14 +94,50 @@ static void rt2x00rfkill_poll(struct work_struct *work)
> > &rt2x00dev->rfkill_work, RFKILL_POLL_INTERVAL);
> > }
> >
> > +static int rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
> > +{
> > + struct device *dev = wiphy_dev(rt2x00dev->hw->wiphy);
> > +
> > + rt2x00dev->rfkill = rfkill_allocate(dev, RFKILL_TYPE_WLAN);
> > + if (!rt2x00dev->rfkill)
> > + return -ENOMEM;
> > +
> > + rt2x00dev->rfkill->name = rt2x00dev->ops->name;
> > + rt2x00dev->rfkill->data = rt2x00dev;
> > + rt2x00dev->rfkill->toggle_radio = rt2x00rfkill_toggle_radio;
> > + if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags)) {
> > + rt2x00dev->rfkill->get_state = rt2x00rfkill_get_state;
> > + rt2x00dev->rfkill->state =
> > + rt2x00dev->ops->lib->rfkill_poll(rt2x00dev) ?
> > + RFKILL_STATE_SOFT_BLOCKED : RFKILL_STATE_UNBLOCKED;
> > + } else {
> > + rt2x00dev->rfkill->state = RFKILL_STATE_UNBLOCKED;
> > + }
> > +
> > + INIT_DELAYED_WORK(&rt2x00dev->rfkill_work, rt2x00rfkill_poll);
> > +
> > + return 0;
> > +}
> > +
> > +static void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
> > +{
> > + rfkill_free(rt2x00dev->rfkill);
> > + rt2x00dev->rfkill = NULL;
> > +}
> > +
> > void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
> > {
> > - if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
> > - test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> > + if (test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> > + return;
> > +
> > + if (rt2x00rfkill_allocate(rt2x00dev)) {
> > + ERROR(rt2x00dev, "Failed to allocate rfkill handler.\n");
> > return;
> > + }
> >
> > if (rfkill_register(rt2x00dev->rfkill)) {
> > ERROR(rt2x00dev, "Failed to register rfkill handler.\n");
> > + rt2x00rfkill_free(rt2x00dev);
> > return;
> > }
> >
> > @@ -117,8 +153,7 @@ void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
> >
> > void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
> > {
> > - if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
> > - !test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> > + if (!test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> > return;
> >
> > cancel_delayed_work_sync(&rt2x00dev->rfkill_work);
> > @@ -127,46 +162,3 @@ void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
> >
> > __clear_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state);
> > }
> > -
> > -void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
> > -{
> > - struct device *dev = wiphy_dev(rt2x00dev->hw->wiphy);
> > -
> > - if (test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state))
> > - return;
> > -
> > - rt2x00dev->rfkill = rfkill_allocate(dev, RFKILL_TYPE_WLAN);
> > - if (!rt2x00dev->rfkill) {
> > - ERROR(rt2x00dev, "Failed to allocate rfkill handler.\n");
> > - return;
> > - }
> > -
> > - __set_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state);
> > -
> > - rt2x00dev->rfkill->name = rt2x00dev->ops->name;
> > - rt2x00dev->rfkill->data = rt2x00dev;
> > - rt2x00dev->rfkill->toggle_radio = rt2x00rfkill_toggle_radio;
> > - if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags)) {
> > - rt2x00dev->rfkill->get_state = rt2x00rfkill_get_state;
> > - rt2x00dev->rfkill->state =
> > - rt2x00dev->ops->lib->rfkill_poll(rt2x00dev) ?
> > - RFKILL_STATE_SOFT_BLOCKED : RFKILL_STATE_UNBLOCKED;
> > - } else {
> > - rt2x00dev->rfkill->state = RFKILL_STATE_UNBLOCKED;
> > - }
> > -
> > - INIT_DELAYED_WORK(&rt2x00dev->rfkill_work, rt2x00rfkill_poll);
> > -
> > - return;
> > -}
> > -
> > -void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
> > -{
> > - if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state))
> > - return;
> > -
> > - cancel_delayed_work_sync(&rt2x00dev->rfkill_work);
> > -
> > - rfkill_free(rt2x00dev->rfkill);
> > - rt2x00dev->rfkill = NULL;
> > -}
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 2/2] tracepoints for softirq entry/exit - tracepoints
From: Mathieu Desnoyers @ 2009-03-16 19:21 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jason Baron, mingo, linux-kernel, acme, fweisbec, fche, peterz
In-Reply-To: <alpine.DEB.2.00.0903161514590.27978@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
>
> On Mon, 16 Mar 2009, Jason Baron wrote:
>
> > hi,
> >
> > ok, below is a re-spun patch 2/2 which converts to the TRACE_EVENT
> > format.
>
> Thanks, some comments though.
>
> >
> > thanks,
> >
> > -Jason
> >
> >
> > Signed-off-by: Jason Baron <jbaron@redhat.com>
> >
> > ---
> >
> > include/trace/irq_event_types.h | 36 ++++++++++++++++++++++++++++++++++++
> > kernel/softirq.c | 7 ++++++-
> > 2 files changed, 42 insertions(+), 1 deletions(-)
> >
> >
> > diff --git a/include/trace/irq_event_types.h b/include/trace/irq_event_types.h
> > index 214bb92..de1f2a9 100644
> > --- a/include/trace/irq_event_types.h
> > +++ b/include/trace/irq_event_types.h
> > @@ -40,4 +40,40 @@ TRACE_EVENT(irq_handler_exit,
> > __entry->irq, __entry->ret ? "handled" : "unhandled")
> > );
> >
> > +TRACE_EVENT(softirq_action_entry,
> > +
> > + TP_PROTO(struct softirq_action *h, struct softirq_action *vec),
> > +
> > + TP_ARGS(h, vec),
> > +
> > + TP_STRUCT__entry(
> > + __array( char, softirq_name, MAX_SOFTIRQ_NAME_LEN )
> > + ),
> > +
> > + TP_fast_assign(
> > + memcpy(__entry->softirq_name, softirq_to_name[h-vec],
> > + MAX_SOFTIRQ_NAME_LEN);
>
> memcpy isn't fast ;-)
>
When given a constant size, memcpy is inlined by the compiler and turned
into a simple mov instruction. That shouldn't change a thing.
Mathieu
> What you want is this:
>
> TP_STRUCT__entry(
> __field( int, vec )
> ),
>
> TP_fast_assign(
> __entry->vec = h - vec;
> > + ),
> > +
> > + TP_printk("softirq entry: %s", __entry->softirq_name)
>
> TP_printk("softirq entry: %s", softirq_to_name[__entry->vec])
>
> > +);
> > +
> > +TRACE_EVENT(softirq_action_exit,
> > +
> > + TP_PROTO(struct softirq_action *h, struct softirq_action *vec),
> > +
> > + TP_ARGS(h, vec),
> > +
> > + TP_STRUCT__entry(
> > + __array( char, softirq_name, MAX_SOFTIRQ_NAME_LEN )
> > + ),
> > +
> > + TP_fast_assign(
> > + memcpy(__entry->softirq_name, softirq_to_name[h-vec],
> > + MAX_SOFTIRQ_NAME_LEN);
> > + ),
> > +
> > + TP_printk("softirq exit: %s", __entry->softirq_name)
>
>
> And do the same here.
>
> -- Steve
>
> > +);
> > +
> > #undef TRACE_SYSTEM
> > diff --git a/kernel/softirq.c b/kernel/softirq.c
> > index 8f3ae57..5e96c77 100644
> > --- a/kernel/softirq.c
> > +++ b/kernel/softirq.c
> > @@ -24,6 +24,7 @@
> > #include <linux/ftrace.h>
> > #include <linux/smp.h>
> > #include <linux/tick.h>
> > +#include <trace/irq.h>
> >
> > #include <asm/irq.h>
> > /*
> > @@ -185,6 +186,9 @@ EXPORT_SYMBOL(local_bh_enable_ip);
> > */
> > #define MAX_SOFTIRQ_RESTART 10
> >
> > +DEFINE_TRACE(softirq_action_entry);
> > +DEFINE_TRACE(softirq_action_exit);
> > +
> > asmlinkage void __do_softirq(void)
> > {
> > struct softirq_action *h;
> > @@ -211,8 +215,9 @@ restart:
> > if (pending & 1) {
> > int prev_count = preempt_count();
> >
> > + trace_softirq_action_entry(h, softirq_vec);
> > h->action(h);
> > -
> > + trace_softirq_action_exit(h, softirq_vec);
> > if (unlikely(prev_count != preempt_count())) {
> > printk(KERN_ERR "huh, entered softirq %td %s %p"
> > "with preempt_count %08x,"
> >
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: automatic fsck?
From: JustinLove @ 2009-03-16 19:19 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <20090315204509.GA17505@rainbow>
Dmitry Artamonow wrote:
> If I remember correctly, you also need to specify your fs type (ext3 instead
> of auto) and real device (/dev/mmcblk0p2 instead of rootfs) in your
> fstab. Maybe that'll help.
One or both of those was successful. Guess I was unscientific in applying both
at once ;^)
> In fact there's other problem, and much bigger - by default rootfs
> gets mounted with 'defaults' option, and it silently wears your flash,
> because 'defaults' imply atime turned on. It may be one of the causes
> of FS corruption too. Guess, I'll roll a patch fixing that.
I also added 'noatime' to fstab, but 'mount' does not show noatime set for
either rootfs or /dev/root.
I tried using rootflags=noatime on the kernel command line, but it said it was
an unrecognized mount option, and failed to mount root at all.
--
Justin Love
Creative Electronics & Software
650 Sundown Road
South Elgin, IL 60177
Phone 847-695-0023 x233
FAX 847-695-0483
^ permalink raw reply
* Re: AMD Quad core - PCI-DMA: Out of IOMMU space on > 4 GB RAM
From: Luis R. Rodriguez @ 2009-03-16 19:18 UTC (permalink / raw)
To: wireless, joerg.roedel; +Cc: linux-kernel@vger.kernel.org, iommu
In-Reply-To: <43e72e890903161215u343cbb19v6d6cbf36794e252a@mail.gmail.com>
On Mon, Mar 16, 2009 at 12:15 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> I've run into "PCI-DMA: Out of IOMMU space" messages after loading and
> unloading a module 30 times. The interesting thing is this only
> happens if I have > 4 GB of memory. The box this occurs has AMD Phenom
> quad core CPU so I take it a harware IOMMU is being used. Below are
> example relevant messages with > 4 GB and then < 4 GB of memory. The
> driver I tested this with was ath9k. It could be an issue perhaps with
> ath9k but I am unable to find an issue in our probe/removal.
>
> Could this be an issue with the AMD IOMMU used? Or is it more likely a
> driver issue?
I forgot to mention I'm using l Linus 2.6.29-rc8 with some
serialization patches applied for ath9k (which are unrelated to
DMA/IOMMU/probe) [1].
http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2009-03-12/serialization-v6/for-2.6.29/
Luis
^ permalink raw reply
* Re: [PATCH] Fix SLAB corruption during
From: Dan Williams @ 2009-03-16 19:15 UTC (permalink / raw)
To: Ivo van Doorn
Cc: John W. Linville, linux-wireless, Arnaud Patard,
Gertjan van Wingerde
In-Reply-To: <200903161925.41102.IvDoorn@gmail.com>
On Mon, 2009-03-16 at 19:25 +0100, Ivo van Doorn wrote:
> At rmmod stage, the code path is the following one :
>
> rt2x00lib_remove_dev
> -> rt2x00lib_uninitialize()
> -> rt2x00rfkill_unregister()
> -> rfkill_unregister()
> -> rt2x00rfkill_free()
> -> rfkill_free()
>
> The problem is that rfkill_free should not be called after rfkill_free
> otherwise put_device(&rfkill->dev) will be called 2 times. This patch
> fix this by removing the call to rfkill_free
Needs a better patch title :) During what? And I assume you mean
"rfkill_free() should not be called after rfkill_unregister(), right?
Dan
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
> Tested-by: Arnaud Patard <apatard@mandriva.com>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
>
> ---
> John, this patch is for 2.6.29 and only 2.6.29 since rfkill support itself
> was removed from later versions (replaced by input_polldev).
> The patch is quite big to be merged in a late state of the release cycle,
> but since the SLAB corruption is a serious problem, I hope this can get in regardless.
>
> Thanks.
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
> index 39ecf3b..820fdb2 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00.h
> @@ -687,8 +687,7 @@ struct rt2x00_dev {
> */
> #ifdef CONFIG_RT2X00_LIB_RFKILL
> unsigned long rfkill_state;
> -#define RFKILL_STATE_ALLOCATED 1
> -#define RFKILL_STATE_REGISTERED 2
> +#define RFKILL_STATE_REGISTERED 1
> struct rfkill *rfkill;
> struct delayed_work rfkill_work;
> #endif /* CONFIG_RT2X00_LIB_RFKILL */
> diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
> index 87c0f2c..e694bb7 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> @@ -1105,7 +1105,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
> * Register extra components.
> */
> rt2x00leds_register(rt2x00dev);
> - rt2x00rfkill_allocate(rt2x00dev);
> rt2x00debug_register(rt2x00dev);
>
> set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
> @@ -1137,7 +1136,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
> * Free extra components
> */
> rt2x00debug_deregister(rt2x00dev);
> - rt2x00rfkill_free(rt2x00dev);
> rt2x00leds_unregister(rt2x00dev);
>
> /*
> diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h b/drivers/net/wireless/rt2x00/rt2x00lib.h
> index 86cd26f..49309d4 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00lib.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
> @@ -260,8 +260,6 @@ static inline void rt2x00crypto_rx_insert_iv(struct sk_buff *skb,
> #ifdef CONFIG_RT2X00_LIB_RFKILL
> void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev);
> void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev);
> -void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev);
> -void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev);
> #else
> static inline void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
> {
> @@ -270,14 +268,6 @@ static inline void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
> static inline void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
> {
> }
> -
> -static inline void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
> -{
> -}
> -
> -static inline void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
> -{
> -}
> #endif /* CONFIG_RT2X00_LIB_RFKILL */
>
> /*
> diff --git a/drivers/net/wireless/rt2x00/rt2x00rfkill.c b/drivers/net/wireless/rt2x00/rt2x00rfkill.c
> index 3298cae..08ffc6d 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00rfkill.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00rfkill.c
> @@ -94,14 +94,50 @@ static void rt2x00rfkill_poll(struct work_struct *work)
> &rt2x00dev->rfkill_work, RFKILL_POLL_INTERVAL);
> }
>
> +static int rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
> +{
> + struct device *dev = wiphy_dev(rt2x00dev->hw->wiphy);
> +
> + rt2x00dev->rfkill = rfkill_allocate(dev, RFKILL_TYPE_WLAN);
> + if (!rt2x00dev->rfkill)
> + return -ENOMEM;
> +
> + rt2x00dev->rfkill->name = rt2x00dev->ops->name;
> + rt2x00dev->rfkill->data = rt2x00dev;
> + rt2x00dev->rfkill->toggle_radio = rt2x00rfkill_toggle_radio;
> + if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags)) {
> + rt2x00dev->rfkill->get_state = rt2x00rfkill_get_state;
> + rt2x00dev->rfkill->state =
> + rt2x00dev->ops->lib->rfkill_poll(rt2x00dev) ?
> + RFKILL_STATE_SOFT_BLOCKED : RFKILL_STATE_UNBLOCKED;
> + } else {
> + rt2x00dev->rfkill->state = RFKILL_STATE_UNBLOCKED;
> + }
> +
> + INIT_DELAYED_WORK(&rt2x00dev->rfkill_work, rt2x00rfkill_poll);
> +
> + return 0;
> +}
> +
> +static void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
> +{
> + rfkill_free(rt2x00dev->rfkill);
> + rt2x00dev->rfkill = NULL;
> +}
> +
> void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
> {
> - if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
> - test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> + if (test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> + return;
> +
> + if (rt2x00rfkill_allocate(rt2x00dev)) {
> + ERROR(rt2x00dev, "Failed to allocate rfkill handler.\n");
> return;
> + }
>
> if (rfkill_register(rt2x00dev->rfkill)) {
> ERROR(rt2x00dev, "Failed to register rfkill handler.\n");
> + rt2x00rfkill_free(rt2x00dev);
> return;
> }
>
> @@ -117,8 +153,7 @@ void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
>
> void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
> {
> - if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
> - !test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> + if (!test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
> return;
>
> cancel_delayed_work_sync(&rt2x00dev->rfkill_work);
> @@ -127,46 +162,3 @@ void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
>
> __clear_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state);
> }
> -
> -void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
> -{
> - struct device *dev = wiphy_dev(rt2x00dev->hw->wiphy);
> -
> - if (test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state))
> - return;
> -
> - rt2x00dev->rfkill = rfkill_allocate(dev, RFKILL_TYPE_WLAN);
> - if (!rt2x00dev->rfkill) {
> - ERROR(rt2x00dev, "Failed to allocate rfkill handler.\n");
> - return;
> - }
> -
> - __set_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state);
> -
> - rt2x00dev->rfkill->name = rt2x00dev->ops->name;
> - rt2x00dev->rfkill->data = rt2x00dev;
> - rt2x00dev->rfkill->toggle_radio = rt2x00rfkill_toggle_radio;
> - if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags)) {
> - rt2x00dev->rfkill->get_state = rt2x00rfkill_get_state;
> - rt2x00dev->rfkill->state =
> - rt2x00dev->ops->lib->rfkill_poll(rt2x00dev) ?
> - RFKILL_STATE_SOFT_BLOCKED : RFKILL_STATE_UNBLOCKED;
> - } else {
> - rt2x00dev->rfkill->state = RFKILL_STATE_UNBLOCKED;
> - }
> -
> - INIT_DELAYED_WORK(&rt2x00dev->rfkill_work, rt2x00rfkill_poll);
> -
> - return;
> -}
> -
> -void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
> -{
> - if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state))
> - return;
> -
> - cancel_delayed_work_sync(&rt2x00dev->rfkill_work);
> -
> - rfkill_free(rt2x00dev->rfkill);
> - rt2x00dev->rfkill = NULL;
> -}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 2/2] tracepoints for softirq entry/exit - tracepoints
From: Steven Rostedt @ 2009-03-16 19:17 UTC (permalink / raw)
To: Jason Baron; +Cc: mingo, linux-kernel, acme, fweisbec, fche, peterz, compudj
In-Reply-To: <20090316190047.GB3111@redhat.com>
On Mon, 16 Mar 2009, Jason Baron wrote:
> hi,
>
> ok, below is a re-spun patch 2/2 which converts to the TRACE_EVENT
> format.
Thanks, some comments though.
>
> thanks,
>
> -Jason
>
>
> Signed-off-by: Jason Baron <jbaron@redhat.com>
>
> ---
>
> include/trace/irq_event_types.h | 36 ++++++++++++++++++++++++++++++++++++
> kernel/softirq.c | 7 ++++++-
> 2 files changed, 42 insertions(+), 1 deletions(-)
>
>
> diff --git a/include/trace/irq_event_types.h b/include/trace/irq_event_types.h
> index 214bb92..de1f2a9 100644
> --- a/include/trace/irq_event_types.h
> +++ b/include/trace/irq_event_types.h
> @@ -40,4 +40,40 @@ TRACE_EVENT(irq_handler_exit,
> __entry->irq, __entry->ret ? "handled" : "unhandled")
> );
>
> +TRACE_EVENT(softirq_action_entry,
> +
> + TP_PROTO(struct softirq_action *h, struct softirq_action *vec),
> +
> + TP_ARGS(h, vec),
> +
> + TP_STRUCT__entry(
> + __array( char, softirq_name, MAX_SOFTIRQ_NAME_LEN )
> + ),
> +
> + TP_fast_assign(
> + memcpy(__entry->softirq_name, softirq_to_name[h-vec],
> + MAX_SOFTIRQ_NAME_LEN);
memcpy isn't fast ;-)
What you want is this:
TP_STRUCT__entry(
__field( int, vec )
),
TP_fast_assign(
__entry->vec = h - vec;
> + ),
> +
> + TP_printk("softirq entry: %s", __entry->softirq_name)
TP_printk("softirq entry: %s", softirq_to_name[__entry->vec])
> +);
> +
> +TRACE_EVENT(softirq_action_exit,
> +
> + TP_PROTO(struct softirq_action *h, struct softirq_action *vec),
> +
> + TP_ARGS(h, vec),
> +
> + TP_STRUCT__entry(
> + __array( char, softirq_name, MAX_SOFTIRQ_NAME_LEN )
> + ),
> +
> + TP_fast_assign(
> + memcpy(__entry->softirq_name, softirq_to_name[h-vec],
> + MAX_SOFTIRQ_NAME_LEN);
> + ),
> +
> + TP_printk("softirq exit: %s", __entry->softirq_name)
And do the same here.
-- Steve
> +);
> +
> #undef TRACE_SYSTEM
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 8f3ae57..5e96c77 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -24,6 +24,7 @@
> #include <linux/ftrace.h>
> #include <linux/smp.h>
> #include <linux/tick.h>
> +#include <trace/irq.h>
>
> #include <asm/irq.h>
> /*
> @@ -185,6 +186,9 @@ EXPORT_SYMBOL(local_bh_enable_ip);
> */
> #define MAX_SOFTIRQ_RESTART 10
>
> +DEFINE_TRACE(softirq_action_entry);
> +DEFINE_TRACE(softirq_action_exit);
> +
> asmlinkage void __do_softirq(void)
> {
> struct softirq_action *h;
> @@ -211,8 +215,9 @@ restart:
> if (pending & 1) {
> int prev_count = preempt_count();
>
> + trace_softirq_action_entry(h, softirq_vec);
> h->action(h);
> -
> + trace_softirq_action_exit(h, softirq_vec);
> if (unlikely(prev_count != preempt_count())) {
> printk(KERN_ERR "huh, entered softirq %td %s %p"
> "with preempt_count %08x,"
>
^ permalink raw reply
* Re: [PATCH] [RFC] c/r: Add UTS support (v2)
From: Dan Smith @ 2009-03-16 19:16 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: containers-qjLDD68F18O7TbgM5vRIOg
In-Reply-To: <20090316190738.GB7329-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
SH> Someone might complain about the per-task namespace data not
SH> showing up in the per-task data, but I think the way you have it
SH> simplifies things enough to justify it.
Yeah, mktree would get pretty ugly without doing it ahead of time, I
think.
SH> Do add a note to Documentation/checkpoint/internals.txt (and maybe
SH> use __NEW_UTS_LEN+1 instead of 65), but other than that it looks
SH> good to me.
I was replicating exactly what is in the struct definitions of
linux/utsname.h, but okay :)
--
Dan Smith
IBM Linux Technology Center
email: danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
^ permalink raw reply
* Re: [PATCH 24/27] Convert gfp_zone() to use a table of precalculated values
From: Christoph Lameter @ 2009-03-16 19:12 UTC (permalink / raw)
To: Mel Gorman
Cc: Linux Memory Management List, Pekka Enberg, Rik van Riel,
KOSAKI Motohiro, Johannes Weiner, Nick Piggin,
Linux Kernel Mailing List, Lin Ming, Zhang Yanmin, Peter Zijlstra
In-Reply-To: <1237226020-14057-25-git-send-email-mel@csn.ul.ie>
On Mon, 16 Mar 2009, Mel Gorman wrote:
> +int gfp_zone_table[GFP_ZONEMASK] __read_mostly;
The gfp_zone_table is compile time determinable. There is no need to
calculate it.
const int gfp_zone_table[GFP_ZONEMASK] = {
ZONE_NORMAL, /* 00 No flags set */
ZONE_DMA, /* 01 Only GFP_DMA set */
ZONE_HIGHMEM, /* 02 Only GFP_HIGHMEM set */
ZONE_DMA, /* 03 GFP_HIGHMEM and GFP_DMA set */
ZONE_DMA32, /* 04 Only GFP_DMA32 set */
ZONE_DMA, /* 05 GFP_DMA and GFP_DMA32 set */
ZONE_DMA32, /* 06 GFP_DMA32 and GFP_HIGHMEM set */
ZONE_DMA, /* 07 GFP_DMA, GFP_DMA32 and GFP_DMA32 set */
ZONE_MOVABLE, /* 08 Only ZONE_MOVABLE set */
ZONE_DMA, /* 09 MOVABLE + DMA */
ZONE_MOVABLE, /* 0A MOVABLE + HIGHMEM */
ZONE_DMA, /* 0B MOVABLE + DMA + HIGHMEM */
ZONE_DMA32, /* 0C MOVABLE + DMA32 */
ZONE_DMA, /* 0D MOVABLE + DMA + DMA32 */
ZONE_DMA32, /* 0E MOVABLE + DMA32 + HIGHMEM */
ZONE_DMA /* 0F MOVABLE + DMA32 + HIGHMEM + DMA
};
Hmmmm... Guess one would need to add some #ifdeffery here to setup
ZONE_NORMAL in cases there is no DMA, DMA32 and HIGHMEM.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: undoing something
From: Junio C Hamano @ 2009-03-16 19:14 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AEFA4@EXCHANGE.trad.tradestation.com>
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> I made a mistake. Big deal, now that I know that git storage is
> immutable and changes just add to what's already there.
>
> A quick look at
> git reflog show topic
> tells me that {1} is the one I want. So, how do I rewind branch topic
> to point to topic@{1} ?
> I did it by making a tag, and then in gitk pointing to it and picking
> "reset to here" from the context menu.
>
> A while back I was looking for the right/easy way to simply repoint my
> branch to where I wanted. The best answer was to use push.
The answer was best only because in your previous question you wanted to
ensure fast-forwardness, i.e. "git push . origin/dev:dev" without plus in
front to cause it to fail if it is not fast-forward.
If you know you have one unwanted commit you would want to discard at the
tip of topic, you do not want fast-foward safety to kick in.
(1) if you are on the topic branch, you can say "git reset --hard HEAD^";
or
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
If the garbage you have at the tip of the topic is not just a single
commit, you can replace HEAD^ and topic^ in the above with whatever commit
you would want to point the tip at.
^ permalink raw reply
* AMD Quad core - PCI-DMA: Out of IOMMU space on > 4 GB RAM
From: Luis R. Rodriguez @ 2009-03-16 19:15 UTC (permalink / raw)
To: wireless, joerg.roedel; +Cc: linux-kernel@vger.kernel.org, iommu
I've run into "PCI-DMA: Out of IOMMU space" messages after loading and
unloading a module 30 times. The interesting thing is this only
happens if I have > 4 GB of memory. The box this occurs has AMD Phenom
quad core CPU so I take it a harware IOMMU is being used. Below are
example relevant messages with > 4 GB and then < 4 GB of memory. The
driver I tested this with was ath9k. It could be an issue perhaps with
ath9k but I am unable to find an issue in our probe/removal.
Could this be an issue with the AMD IOMMU used? Or is it more likely a
driver issue?
With > 4 GB of RAM:
phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011820000, irq=19
phy1: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20012520000, irq=19
phy2: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy3: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy4: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy5: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy6: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy7: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy8: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy9: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy10: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy11: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy12: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy13: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy14: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy15: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy16: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy17: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy18: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy19: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy20: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy21: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy22: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy23: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy24: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy25: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy26: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy27: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy28: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
phy29: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117c0000, irq=19
phy30: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200117a0000, irq=19
ath9k 0000:01:06.0: PCI-DMA: Out of IOMMU space for 3904 bytes
ath9k 0000:01:06.0: PCI-DMA: Out of IOMMU space for 3904 bytes
ath9k 0000:01:06.0: PCI-DMA: Out of IOMMU space for 3904 bytes
... etc
The full log can be seen at:
http://bombadil.infradead.org/~mcgrof/logs/log-out-of-mem-full
With < 4GB RAM:
phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011200000, irq=19
phy1: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200125a0000, irq=19
phy2: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy3: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy4: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy5: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy6: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy7: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy8: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy9: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy10: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy11: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy12: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy13: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy14: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy15: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy16: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy17: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy18: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy19: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy20: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy21: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy22: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy23: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy24: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy25: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy26: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy27: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy28: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy29: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
phy30: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc200110a0000, irq=19
phy31: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81:
mem=0xffffc20011140000, irq=19
..etc goes on and on
The full log can be seen at:
http://bombadil.infradead.org/~mcgrof/logs/log-out-of-mem-full-NOT
Luis
^ permalink raw reply
* [Qemu-devel] Re: 440 emulation?
From: Hollis Blanchard @ 2009-03-16 19:15 UTC (permalink / raw)
To: Rob Landley; +Cc: qemu-devel
In-Reply-To: <200903161405.37420.rob@landley.net>
On Mon, 2009-03-16 at 14:05 -0500, Rob Landley wrote:
> I'm trying to come up with a working 440 toolchain and root filesystem, and I
> think I've built one (--with-cpu=440 for the binutils and gcc config seems to
> be the magic), but my attempt to test it under qemu with -M bamboo led to an
> "Unable to initialize CPU" message, because apparently the 440 isn't actually
> supported.
Correct, 440 is not supported by TCG, so I'm not sure what you're trying
to do?
> I tried feeding in "-cpu 405" in hopes of getting something to at least launch
> (that's what the source code does when it's using kvm, anyway), but it still
> said it couldn't initialize the cpu.
As you can see from quick inspection, none of the code involved pays any
attention to your -cpu option. If you want to make that work, it should
simply be a matter of plumbing 'cpu_model' through ppc440ep_init().
> Presumably this works for somebody, but I dunno how to get it to do anything
> interesting. What is the status of the bamboo board?
It works, as long as you can provide working core emulation.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 24/27] Convert gfp_zone() to use a table of precalculated values
From: Christoph Lameter @ 2009-03-16 19:12 UTC (permalink / raw)
To: Mel Gorman
Cc: Linux Memory Management List, Pekka Enberg, Rik van Riel,
KOSAKI Motohiro, Johannes Weiner, Nick Piggin,
Linux Kernel Mailing List, Lin Ming, Zhang Yanmin, Peter Zijlstra
In-Reply-To: <1237226020-14057-25-git-send-email-mel@csn.ul.ie>
On Mon, 16 Mar 2009, Mel Gorman wrote:
> +int gfp_zone_table[GFP_ZONEMASK] __read_mostly;
The gfp_zone_table is compile time determinable. There is no need to
calculate it.
const int gfp_zone_table[GFP_ZONEMASK] = {
ZONE_NORMAL, /* 00 No flags set */
ZONE_DMA, /* 01 Only GFP_DMA set */
ZONE_HIGHMEM, /* 02 Only GFP_HIGHMEM set */
ZONE_DMA, /* 03 GFP_HIGHMEM and GFP_DMA set */
ZONE_DMA32, /* 04 Only GFP_DMA32 set */
ZONE_DMA, /* 05 GFP_DMA and GFP_DMA32 set */
ZONE_DMA32, /* 06 GFP_DMA32 and GFP_HIGHMEM set */
ZONE_DMA, /* 07 GFP_DMA, GFP_DMA32 and GFP_DMA32 set */
ZONE_MOVABLE, /* 08 Only ZONE_MOVABLE set */
ZONE_DMA, /* 09 MOVABLE + DMA */
ZONE_MOVABLE, /* 0A MOVABLE + HIGHMEM */
ZONE_DMA, /* 0B MOVABLE + DMA + HIGHMEM */
ZONE_DMA32, /* 0C MOVABLE + DMA32 */
ZONE_DMA, /* 0D MOVABLE + DMA + DMA32 */
ZONE_DMA32, /* 0E MOVABLE + DMA32 + HIGHMEM */
ZONE_DMA /* 0F MOVABLE + DMA32 + HIGHMEM + DMA
};
Hmmmm... Guess one would need to add some #ifdeffery here to setup
ZONE_NORMAL in cases there is no DMA, DMA32 and HIGHMEM.
^ 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.