* Re: [patch 1/4] net: percpufy frequently used vars -- add percpu_counter_mod_bh
From: Andrew Morton @ 2006-03-09 2:32 UTC (permalink / raw)
To: Andi Kleen; +Cc: bcrl, linux-kernel, davem, netdev, shai
In-Reply-To: <p733bhswe6j.fsf@verdi.suse.de>
Andi Kleen <ak@suse.de> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
> >
> > x86_64 is signed 32-bit!
>
> I'll change it. You want signed 64bit?
>
Well it's all random at present. Since the API is defined as unsigned I
guess it's be best to make it unsigned for now. Later, when someone gets
down to making it signed and reviewing all the users they can flip x86_64
to signed along with the rest of the architectures.
^ permalink raw reply
* Re: 2.6.16-rc5-mm3
From: Matthias Urlichs @ 2006-03-09 2:30 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-kernel-announce
In-Reply-To: <20060307021929.754329c9.akpm@osdl.org>
Hi, Andrew Morton wrote:
> - To fetch an -mm tree using git, use (for example)
>
> git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
The importer hit a snag and didn't get the last three -mm kernels or so.
Should fix itself during the next few hours.
Please tell me directly if there's a problem; usually, new -mm releases
should be available as git trees 2h after an announcement.
--
Matthias Urlichs
^ permalink raw reply
* Re: [PATCH] mm: yield during swap prefetching
From: Con Kolivas @ 2006-03-09 2:30 UTC (permalink / raw)
To: Nick Piggin; +Cc: Pavel Machek, Andrew Morton, linux-kernel, linux-mm, ck
In-Reply-To: <440F9154.2080909@yahoo.com.au>
On Thu, 9 Mar 2006 01:22 pm, Nick Piggin wrote:
> Pavel Machek wrote:
> >On Ut 07-03-06 16:05:15, Andrew Morton wrote:
> >>Why do you want that?
> >>
> >>If prefetch is doing its job then it will save the machine from a pile of
> >>major faults in the near future. The fact that the machine happens
> >
> >Or maybe not.... it is prefetch, it may prefetch wrongly, and you
> >definitely want it doing nothing when system is loaded.... It only
> >makes sense to prefetch when system is idle.
>
> Right. Prefetching is obviously going to have a very low work/benefit,
> assuming your page reclaim is working properly, because a) it doesn't
> deal with file pages, and b) it is doing work to reclaim pages that
> have already been deemed to be the least important.
>
> What it is good for is working around our interesting VM that apparently
> allows updatedb to swap everything out (although I haven't seen this
> problem myself), and artificial memory hogs. By moving work to times of
> low cost. No problem with the theory behind it.
>
> So as much as a major fault costs in terms of performance, the tiny
> chance that prefetching will avoid it means even the CPU usage is
> questionable. Using sched_yield() seems like a hack though.
Yeah it's a hack alright. Funny how at last I find a place where yield does
exactly what I want and because we hate yield so much noone wants me to use
it all.
Cheers,
Con
--
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] mm: yield during swap prefetching
From: Con Kolivas @ 2006-03-09 2:30 UTC (permalink / raw)
To: Nick Piggin; +Cc: Pavel Machek, Andrew Morton, linux-kernel, linux-mm, ck
In-Reply-To: <440F9154.2080909@yahoo.com.au>
On Thu, 9 Mar 2006 01:22 pm, Nick Piggin wrote:
> Pavel Machek wrote:
> >On Út 07-03-06 16:05:15, Andrew Morton wrote:
> >>Why do you want that?
> >>
> >>If prefetch is doing its job then it will save the machine from a pile of
> >>major faults in the near future. The fact that the machine happens
> >
> >Or maybe not.... it is prefetch, it may prefetch wrongly, and you
> >definitely want it doing nothing when system is loaded.... It only
> >makes sense to prefetch when system is idle.
>
> Right. Prefetching is obviously going to have a very low work/benefit,
> assuming your page reclaim is working properly, because a) it doesn't
> deal with file pages, and b) it is doing work to reclaim pages that
> have already been deemed to be the least important.
>
> What it is good for is working around our interesting VM that apparently
> allows updatedb to swap everything out (although I haven't seen this
> problem myself), and artificial memory hogs. By moving work to times of
> low cost. No problem with the theory behind it.
>
> So as much as a major fault costs in terms of performance, the tiny
> chance that prefetching will avoid it means even the CPU usage is
> questionable. Using sched_yield() seems like a hack though.
Yeah it's a hack alright. Funny how at last I find a place where yield does
exactly what I want and because we hate yield so much noone wants me to use
it all.
Cheers,
Con
^ permalink raw reply
* Re: git-fmt-merge-msg cleanup
From: Junio C Hamano @ 2006-03-09 2:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603081753270.32577@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Since I've started using the "merge.summary" flag in my repo, my merge
> messages look nicer, but I dislike how I get notifications of merges
> within merges.
>
> So I'd suggest this trivial change..
Makes sense. Thanks.
^ permalink raw reply
* Re: [PATCH] mm: yield during swap prefetching
From: Nick Piggin @ 2006-03-09 2:22 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, Con Kolivas, linux-kernel, linux-mm, ck
In-Reply-To: <20060308222404.GA4693@elf.ucw.cz>
Pavel Machek wrote:
>On Út 07-03-06 16:05:15, Andrew Morton wrote:
>
>>Why do you want that?
>>
>>If prefetch is doing its job then it will save the machine from a pile of
>>major faults in the near future. The fact that the machine happens
>>
>
>Or maybe not.... it is prefetch, it may prefetch wrongly, and you
>definitely want it doing nothing when system is loaded.... It only
>makes sense to prefetch when system is idle.
>
Right. Prefetching is obviously going to have a very low work/benefit,
assuming your page reclaim is working properly, because a) it doesn't
deal with file pages, and b) it is doing work to reclaim pages that
have already been deemed to be the least important.
What it is good for is working around our interesting VM that apparently
allows updatedb to swap everything out (although I haven't seen this
problem myself), and artificial memory hogs. By moving work to times of
low cost. No problem with the theory behind it.
So as much as a major fault costs in terms of performance, the tiny
chance that prefetching will avoid it means even the CPU usage is
questionable. Using sched_yield() seems like a hack though.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [PATCH] mm: yield during swap prefetching
From: Nick Piggin @ 2006-03-09 2:22 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, Con Kolivas, linux-kernel, linux-mm, ck
In-Reply-To: <20060308222404.GA4693@elf.ucw.cz>
Pavel Machek wrote:
>On Ut 07-03-06 16:05:15, Andrew Morton wrote:
>
>>Why do you want that?
>>
>>If prefetch is doing its job then it will save the machine from a pile of
>>major faults in the near future. The fact that the machine happens
>>
>
>Or maybe not.... it is prefetch, it may prefetch wrongly, and you
>definitely want it doing nothing when system is loaded.... It only
>makes sense to prefetch when system is idle.
>
Right. Prefetching is obviously going to have a very low work/benefit,
assuming your page reclaim is working properly, because a) it doesn't
deal with file pages, and b) it is doing work to reclaim pages that
have already been deemed to be the least important.
What it is good for is working around our interesting VM that apparently
allows updatedb to swap everything out (although I haven't seen this
problem myself), and artificial memory hogs. By moving work to times of
low cost. No problem with the theory behind it.
So as much as a major fault costs in terms of performance, the tiny
chance that prefetching will avoid it means even the CPU usage is
questionable. Using sched_yield() seems like a hack though.
--
Send instant messages to your online friends http://au.messenger.yahoo.com
--
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 1/4] net: percpufy frequently used vars -- add percpu_counter_mod_bh
From: Andi Kleen @ 2006-03-09 2:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: bcrl, linux-kernel, davem, netdev, shai
In-Reply-To: <20060308150609.344c62fa.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
>
> x86_64 is signed 32-bit!
I'll change it. You want signed 64bit?
-Andi
^ permalink raw reply
* [uml-devel] new filesystem images
From: Antoine Martin @ 2006-03-09 2:20 UTC (permalink / raw)
To: user-mode-linux-devel, user-mode-linux-user
In-Reply-To: <20060221071402.EB05F338E2@sc8-sf-spam1.sourceforge.net>
Hi list,
I have added some new images here:
http://uml.nagafix.co.uk/
Fedora Core 4 AMD64, Mandriva-2006 x86 & AMD64, OpenSuse x86.
All these now work well with TLS, tested with 2.6.15.6-bs3-tls.
The last images should be uploaded by the time you get this email.
I still have to rebuild some new Honeypot images - avoid those.
Also, do not use FC4-x86, this one still has a problem with TLS.
Do let me know of any problems.
Antoine
PS: here is the problem with FC4-x86:
Setting hostname localhost: [ OK ]
set_thread_area failed when setting up thread-local storage
/etc/rc.d/rc.sysinit: line 323: 1441 Done echo
"raidautorun /dev/md0"
1442 Segmentation fault | nash --quiet
set_thread_area failed when setting up thread-local storage
/etc/rc.d/rc.sysinit: line 340: 1445 Done echo
"mkdmnod"
1446 Segmentation fault | /sbin/nash --quiet >/dev/null 2>&1
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/ubda
set_thread_area failed when setting up thread-local storage
Warning... fsck.ext3 for device /dev/ubda exited with signal 11.
[FAILED]
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: 2.6.15-rt20, "bad page state", jackd
From: Fernando Lopez-Lezcano @ 2006-03-09 2:19 UTC (permalink / raw)
To: Ingo Molnar, Steven Rostedt; +Cc: carrlane, nando, Linux Kernel Mailing List
In-Reply-To: <1141864232.5262.47.camel@cmn3.stanford.edu>
[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]
On Wed, 2006-03-08 at 16:30 -0800, Fernando Lopez-Lezcano wrote:
> On Wed, 2006-03-08 at 13:48 -0800, Fernando Lopez-Lezcano wrote:
> > On Wed, 2006-03-08 at 11:36 -0800, Fernando Lopez-Lezcano wrote:
> > > Hi all, I reported this in mid January (I thought I had sent to the list
> > > but the report went to Ingo and Steven off list)
> > >
> > > I'm seeing the same problem in 2.6.15-rt21 in some of my machines. After
> > > a reboot into the kernel I just login as root in a terminal, start the
> > > jackd sound server ("jackd -d alsa -d hw") and when stopping it (just
> > > doing a <ctrl>c) I get a bunch of messages of this form:
> > >
> > > > Trying to fix it up, but a reboot is needed
> > > > Bad page state at __free_pages_ok (in process 'jackd', page c10012fc)
> > >
> > > Has anyone else seen this?
> > >
> > > I'm in the process of building an -rt21 kernel before posting more
> > > detailed error messages (this kernel is patched with some additional
> > > stuff).
> >
> > This is what the errors look like (I'm attaching the whole dmesg output
> > and the .config file used to build the smp kernel):
> >
> > Bad page state at __free_pages_ok (in process 'jackd', page c1013ce0)
> > flags:0x00000414 mapping:00000000 mapcount:0 count:0
> > Backtrace:
> > [<c015947d>] bad_page+0x7d/0xc0 (8)
> > [<c01598fd>] __free_pages_ok+0x9d/0x180 (36)
> > [<c015a5ac>] __pagevec_free+0x3c/0x50 (40)
> > [<c015db47>] release_pages+0x127/0x1a0 (16)
> > [<c016c93d>] free_pages_and_swap_cache+0x7d/0xc0 (80)
> > [<c01681ae>] unmap_region+0x13e/0x160 (28)
> > [<c0168461>] do_munmap+0xe1/0x120 (48)
> > [<c01684df>] sys_munmap+0x3f/0x60 (32)
> > [<c01034a1>] syscall_call+0x7/0xb (16)
> > Trying to fix it up, but a reboot is needed
>
> [MUNCH]
>
> > I'm now building another -rt21 with DEBUG_PAGEALLOC and DEBUG_SLAB
> > enabled to see if I can pinpoint in more detail what's happening (if I
> > can get it to boot!).
>
> I'm not able to boot with those two options enabled. It looks like it is
> hanging after loading the sound drivers - this is on top of fc4. I can't
> even get to single user and I'm searching for a serial cable right now
> to see if I can get more information in a way that can be posted here.
> Arghhh :-)
A kind soul (thanks Carr!) made the proper null modem cable for me...
So, I'm attaching the result of <ctrl><sys>T when the machine is hung.
This is when trying to boot single user into -rt21 with the previously
posted .config and DEBUG_PAGEALLOC and DEBUG_SLAB enabled. Without those
two options the kernel boots but I get the aforementioned errors when
stopping jackd.
Let me know if I could try something else.
-- Fernando
[-- Attachment #2: dump.txt --]
[-- Type: text/plain, Size: 60159 bytes --]
SysRq : Changing Loglevel
Loglevel set to 9
SysRq : Show State
sibling
task PC pid father child younger older
hm, tasklist_lock write-locked.
ignoring ...
init [f7eb4a70]D 00000000 5896 1 0 2 (NOTLB)
f7eb7eec 00000000 00000000 00000000 c1c6d6bc f2c27c73 0000000d 00000642
f7eb4ba8 f7eb4a70 c03dfc40 c1f0f160 f2c986a3 0000000d 00000000 00000002
f7eb6000 00800100 ffffffff f7eb7f14 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0176cac>] kfree+0x2c/0x80 (80)
[<c018efaf>] sys_select+0x2ff/0x3c0 (16)
[<c0103447>] sysenter_past_esp+0x54/0x75 (64)
migration/0 [f7e00a70]S F7E03F78 7676 2 1 3 (L-TLB)
f7e03f7c f757fa70 00000076 f7e03f78 c01211a1 2e251b80 0000000d 00001451
f7e00ba8 f7e00a70 f7544a70 c1f0f160 2e316fc5 0000000d f7e03f84 c011f473
f7e02000 c1f0f160 00000000 f7e03fa4 c037ffc5 f5301f4c f5301f48 f5301f4c
Call Trace:
[<c01211a1>] move_tasks+0x181/0x300 (20)
[<c011f473>] activate_task+0xa3/0x100 (44)
[<c037ffc5>] schedule+0xa5/0x120 (20)
[<c01228ef>] complete+0x3f/0x70 (16)
[<c0123f3c>] migration_thread+0x12c/0x1b0 (24)
[<c01228ef>] complete+0x3f/0x70 (12)
[<c0123e10>] migration_thread+0x0/0x1b0 (20)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-high/ [f7e06a70]S F7E06A70 7552 3 1 4 2 (L-TLB)
f7e09f6c ffffffff ffffffff f7e06a70 f7e09f50 51387f00 00000009 00001eaf
f7e06ba8 f7e06a70 f7e0ba70 c1f0f160 513c5d73 00000009 c1f0f1ac 0000007d
f7e08000 00000001 c1f0ffe0 f7e09f94 c037ffc5 00000246 00000003 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c012e975>] ksoftirqd+0x1d5/0x240 (24)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-timer [f7e0ba70]R 00000006 [on rq #0] 7560 4 1 5 3 (L-TLB)
f7e0df6c c010b5b0 00000001 00000006 c1f10224 be51147a 00000093 000008d0
f7e0bba8 f7e0ba70 c03dfc40 c1f0f160 be511fa6 00000093 00000518 00000002
f7e0c000 c0499380 c1f10018 f7e0df94 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c010b5b0>] tsc_update_callback+0x0/0xc0 (8)
[<c037ffc5>] schedule+0xa5/0x120 (76)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c012e975>] ksoftirqd+0x1d5/0x240 (32)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-net-t [f7e10a70]S F7E10A70 7696 5 1 6 4 (L-TLB)
f7e13f6c ffffffff ffffffff f7e10a70 f7e13f50 513edda7 00000009 00000cc5
f7e10ba8 f7e10a70 f7e15a70 c1f0f160 513fdeb8 00000009 c1f0f1ac 0000007d
f7e12000 00000001 c1f10050 f7e13f94 c037ffc5 00000246 00000005 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c012e975>] ksoftirqd+0x1d5/0x240 (24)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-net-r [f7e15a70]S 00000383 7684 6 1 7 5 (L-TLB)
f7e17f6c f5a36380 00100100 00000383 f7e1007b 7fea7bed 00000034 00000daf
f7e15ba8 f7e15a70 f7e24a70 c1f0f160 7ff04a2a 00000034 f7e17f84 00000001
f7e16000 c0499380 c1f10088 f7e17f94 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c012e975>] ksoftirqd+0x1d5/0x240 (32)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-scsi/ [f7e1aa70]S F7E1AA70 7696 7 1 8 6 (L-TLB)
f7e1df6c ffffffff ffffffff f7e1aa70 f7e1df50 513edda7 00000009 00000a15
f7e1aba8 f7e1aa70 f7e1fa70 c1f0f160 513ff381 00000009 c1f0f1ac 0000007d
f7e1c000 00000001 c1f100c0 f7e1df94 c037ffc5 00000246 00000007 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c012e975>] ksoftirqd+0x1d5/0x240 (24)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-taskl [f7e1fa70]R F765EDA8 [on rq #0] 7400 8 1 9 7 (L-TLB)
f7e21f6c c1f115c0 00000001 f765eda8 f7e21f3c bd2fa196 00000093 00000952
f7e1fba8 f7e1fa70 f7e24a70 c1f0f160 bd383639 00000093 00000000 00000001
f7e20000 c0499380 c1f100f8 f7e21f94 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c012e975>] ksoftirqd+0x1d5/0x240 (32)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-hrtim [f7e24a70]D 00000001 7552 9 1 10 8 (L-TLB)
f7e27edc 01a74f60 c011f473 00000001 00000000 bd2fa196 00000093 00000ef8
f7e24ba8 f7e24a70 c03dfc40 c1f0f160 bd384531 00000093 f7c05a70 00000002
f7e26000 0100a140 ffffffff f7e27f04 c037ffc5 c0142fbe 00000004 00000000
Call Trace:
[<c011f473>] activate_task+0xa3/0x100 (12)
[<c037ffc5>] schedule+0xa5/0x120 (72)
[<c0142fbe>] task_blocks_on_lock+0x11e/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c013527e>] send_group_sig_info+0x1e/0x50 (80)
[<c012cce0>] it_real_fn+0x0/0x60 (8)
[<c012ccfd>] it_real_fn+0x1d/0x60 (8)
[<c012cce0>] it_real_fn+0x0/0x60 (8)
[<c0142824>] run_hrtimer_softirq+0x84/0x110 (4)
[<c012e8e7>] ksoftirqd+0x147/0x240 (36)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
watchdog/0 [f7e29a70]S 00000200 7760 10 1 11 9 (L-TLB)
f7e2bf94 00000001 c01e037a 00000200 f7e2bf64 513edda7 00000009 000009b5
f7e29ba8 f7e29a70 f7e2ea70 c1f0f160 514152e6 00000009 00000001 c1f0f160
f7e2a000 f7eb7f18 00000000 f7e2bfbc c037ffc5 0000007d ffffffff c1f0f1ac
Call Trace:
[<c01e037a>] avc_has_perm+0x5a/0x70 (12)
[<c037ffc5>] schedule+0xa5/0x120 (72)
[<c0152bc0>] watchdog+0x0/0x60 (36)
[<c0152c03>] watchdog+0x43/0x60 (4)
[<c013e78c>] kthread+0xac/0xb0 (12)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
desched/0 [f7e2ea70]S F71C0000 7436 11 1 12 10 (L-TLB)
f7e31f94 00000000 00000000 f71c0000 c0175f95 32d892f3 0000000d 000011da
f7e2eba8 f7e2ea70 f754ea70 c1f0f160 32e167b6 0000000d f7e31fa0 c21df300
f7e30000 f7e30000 00000000 f7e31fbc c037ffc5 c0176c63 00000000 f7e30000
Call Trace:
[<c0175f95>] cache_free_debugcheck+0x245/0x2b0 (20)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c0176c63>] kmem_cache_free+0x53/0x70 (4)
[<c01277b0>] desched_thread+0x0/0x80 (32)
[<c01277fe>] desched_thread+0x4e/0x80 (4)
[<c013e78c>] kthread+0xac/0xb0 (12)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
migration/1 [f7e33a70]S 00000004 7688 12 1 13 11 (L-TLB)
f7e35f7c 00000001 00000293 00000004 c1f1fae0 2babe609 0000000d 000012f0
f7e33ba8 f7e33a70 f764da70 c1f1f160 2bb15780 0000000d f7e35f84 c011f473
f7e34000 c1f1f160 00000001 f7e35fa4 c037ffc5 f5153f4c f5153f48 f5153f4c
Call Trace:
[<c011f473>] activate_task+0xa3/0x100 (64)
[<c037ffc5>] schedule+0xa5/0x120 (20)
[<c01228ef>] complete+0x3f/0x70 (16)
[<c0123f3c>] migration_thread+0x12c/0x1b0 (24)
[<c01228ef>] complete+0x3f/0x70 (12)
[<c0123e10>] migration_thread+0x0/0x1b0 (20)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-high/ [f7e67a70]S F7E67A70 7696 13 1 14 12 (L-TLB)
f7e69f6c ffffffff ffffffff f7e67a70 f7e69f50 00000000 00000000 0000025d
f7e67ba8 f7e67a70 f7e6ca70 c1f1f160 51646848 00000009 c1f1f1ac 00000073
f7e68000 00000001 c1f1ffe0 f7e69f94 c037ffc5 00000246 0000000d 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c012e975>] ksoftirqd+0x1d5/0x240 (24)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-timer [f7e6ca70]S 00000006 7576 14 1 15 13 (L-TLB)
f7e6ff6c f7ee3f28 00000001 00000006 c1f20224 594d805b 00000094 00000169
f7e6cba8 f7e6ca70 f7eb9a70 c1f1f160 5a8d7ad7 00000094 00000750 00000001
f7e6e000 c0499380 c1f20018 f7e6ff94 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c012e975>] ksoftirqd+0x1d5/0x240 (32)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-net-t [f7e71a70]S F7E71A70 7696 15 1 16 14 (L-TLB)
f7e73f6c ffffffff ffffffff f7e71a70 f7e73f50 00000000 00000000 0000015b
f7e71ba8 f7e71a70 f7e76a70 c1f1f160 5164840f 00000009 c1f1f1ac 00000073
f7e72000 00000001 c1f20050 f7e73f94 c037ffc5 00000246 0000000f 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c012e975>] ksoftirqd+0x1d5/0x240 (24)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-net-r [f7e76a70]S F7E76A70 7696 16 1 17 15 (L-TLB)
f7e79f6c ffffffff ffffffff f7e76a70 f7e79f50 00000000 00000000 00000105
f7e76ba8 f7e76a70 f7e7ba70 c1f1f160 51648e46 00000009 c1f1f1ac 00000073
f7e78000 00000001 c1f20088 f7e79f94 c037ffc5 00000246 00000010 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c012e975>] ksoftirqd+0x1d5/0x240 (24)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-scsi/ [f7e7ba70]S F7E7BA70 7696 17 1 18 16 (L-TLB)
f7e7df6c ffffffff ffffffff f7e7ba70 f7e7df50 00000000 00000000 00000102
f7e7bba8 f7e7ba70 f7c00a70 c1f1f160 51649860 00000009 c1f1f1ac 00000073
f7e7c000 00000001 c1f200c0 f7e7df94 c037ffc5 00000246 00000011 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c012e975>] ksoftirqd+0x1d5/0x240 (24)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-taskl [f7c00a70]D 00000001 7488 18 1 19 17 (L-TLB)
f7c03ed8 376fd163 00000000 00000001 00000001 33a54edb 0000000d 0000024c
f7c00ba8 f7c00a70 f757fa70 c1f1f160 33a576b8 0000000d f757fa70 f757ff8c
f7c02000 0100a140 ffffffff f7c03f00 c037ffc5 c0142fbe 00000004 f5109e80
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142fbe>] task_blocks_on_lock+0x11e/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0176c49>] kmem_cache_free+0x39/0x70 (80)
[<c013bdd7>] rcu_process_callbacks+0x57/0x80 (24)
[<c012e619>] __tasklet_action+0x79/0x110 (12)
[<c012e8e7>] ksoftirqd+0x147/0x240 (32)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
softirq-hrtim [f7c05a70]D 00000000 7416 19 1 20 18 (L-TLB)
f7c07e68 00000000 00000000 00000000 00000000 bd365ef6 00000093 00000167
f7c05ba8 f7c05a70 f7eb9a70 c1f1f160 bd385455 00000093 f7c05a70 00000001
f7c06000 0100a140 ffffffff f7c07e90 c037ffc5 c0142f53 00000004 f7c03f14
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0133b60>] __sigqueue_alloc+0x20/0x70 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0133b60>] __sigqueue_alloc+0x20/0x70 (28)
[<c01346bb>] send_signal+0xab/0x140 (12)
[<c0134bdc>] __group_send_sig_info+0x6c/0xe0 (20)
[<c01343c1>] check_kill_permission+0x61/0x110 (8)
[<c0134d95>] group_send_sig_info+0xb5/0x100 (20)
[<c0135289>] send_group_sig_info+0x29/0x50 (28)
[<c012cce0>] it_real_fn+0x0/0x60 (8)
[<c012ccfd>] it_real_fn+0x1d/0x60 (8)
[<c012cce0>] it_real_fn+0x0/0x60 (8)
[<c0142824>] run_hrtimer_softirq+0x84/0x110 (4)
[<c012e8e7>] ksoftirqd+0x147/0x240 (36)
[<c012e7a0>] ksoftirqd+0x0/0x240 (48)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
watchdog/1 [f7c0aa70]S 00000200 7760 20 1 21 19 (L-TLB)
f7c0df94 00000001 c01e037a 00000200 f7c0df64 00000000 00000000 000000b5
f7c0aba8 f7c0aa70 f7c0fa70 c1f1f160 5164b2e1 00000009 c1f1f1ac c1f1f160
f7c0c000 f7eb7eec 00000001 f7c0dfbc c037ffc5 00000073 ffffffff c1f1f1ac
Call Trace:
[<c01e037a>] avc_has_perm+0x5a/0x70 (12)
[<c037ffc5>] schedule+0xa5/0x120 (72)
[<c0152bc0>] watchdog+0x0/0x60 (36)
[<c0152c03>] watchdog+0x43/0x60 (4)
[<c013e78c>] kthread+0xac/0xb0 (12)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
desched/1 [f7c0fa70]S F75A2000 7392 21 1 22 20 (L-TLB)
f7c11f94 00000000 00000000 f75a2000 c0175f95 3349e830 0000000d 00000c33
f7c0fba8 f7c0fa70 f7206a70 c1f1f160 334c49c7 0000000d f7c11fa0 c21df300
f7c10000 f7c10000 00000001 f7c11fbc c037ffc5 c0176c63 00000001 f7c10000
Call Trace:
[<c0175f95>] cache_free_debugcheck+0x245/0x2b0 (20)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c0176c63>] kmem_cache_free+0x53/0x70 (4)
[<c01277b0>] desched_thread+0x0/0x80 (32)
[<c01277fe>] desched_thread+0x4e/0x80 (4)
[<c013e78c>] kthread+0xac/0xb0 (12)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
events/0 [f7fe5a70]D F7768000 7456 22 1 23 21 (L-TLB)
f7c19eb4 00000000 c062ab40 f7768000 c1cffc9c 8515fce4 0000000d 00001524
f7fe5ba8 f7fe5a70 c03dfc40 c1f0f160 85162901 0000000d c03e8880 00000002
f7c18000 0000a040 ffffffff f7c19edc c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c01773e2>] cache_reap+0x92/0x260 (80)
[<c01227fc>] __wake_up+0x3c/0x70 (24)
[<c0177350>] cache_reap+0x0/0x260 (16)
[<c013a74a>] worker_thread+0x17a/0x250 (16)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
events/1 [f7fe8a70]S 94FE8088 7200 23 1 24 22 (L-TLB)
f7febf3c 76786e43 1e3e7ae3 94fe8088 069edbdb c8d241ff 00000094 000001b0
f7fe8ba8 f7fe8a70 f7eb9a70 c1f1f160 c8d26335 00000094 c0177350 00000001
f7fea000 f7ee3f20 f7ee3ef8 f7febf64 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c0177350>] cache_reap+0x0/0x260 (60)
[<c037ffc5>] schedule+0xa5/0x120 (24)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c0177350>] cache_reap+0x0/0x260 (16)
[<c013a7e5>] worker_thread+0x215/0x250 (16)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
khelper [f7c7ea70]S 00000004 6944 24 1 25 23 (L-TLB)
f7c2bf3c 00000001 00000246 00000004 c1f1fae0 0dcc685e 0000000d 00000321
f7c7eba8 f7c7ea70 f760ea70 c1f1f160 0dce7680 0000000d f7c2bf4c 00000001
f7c2a000 f7feef20 f7feeef8 f7c2bf64 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c013a1e0>] __call_usermodehelper+0x0/0x50 (16)
[<c013a7e5>] worker_thread+0x215/0x250 (16)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
kthread [f7fa5a70]S F7FA6000 7188 25 1 32 366 24 (L-TLB)
f7fa7f3c 00800711 00000286 f7fa6000 f50e3dc0 20d734ee 0000000d 00000122
f7fa5ba8 f7fa5a70 f7068a70 c1f1f160 20e408d9 0000000d f50e3dc0 00000001
f7fa6000 f7f84f20 f7f84ef8 f7fa7f64 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c013e790>] keventd_create_kthread+0x0/0x70 (16)
[<c013a7e5>] worker_thread+0x215/0x250 (16)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
kblockd/0 [f7f1ba70]S C04E8A14 7576 32 25 33 (L-TLB)
f7f1df3c c8408800 c04e8980 c04e8a14 0082fddf 328c679e 0000000d 00000da1
f7f1bba8 f7f1ba70 f764da70 c1f0f160 328d38ff 0000000d 00000000 00000001
f7f1c000 c2388f20 c2388ef8 f7f1df64 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c01ffb70>] blk_unplug_work+0x0/0x10 (16)
[<c013a7e5>] worker_thread+0x215/0x250 (16)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
kblockd/1 [f7f45a70]S C0206A09 7576 33 25 34 32 (L-TLB)
f7f47f3c 00000000 f7846180 c0206a09 c8408800 d1eec07a 0000000c 00000dd1
f7f45ba8 f7f45a70 f74f9a70 c1f1f160 d1ef70dc 0000000c f7f47f28 00000001
f7f46000 c2389f20 c2389ef8 f7f47f64 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c0206a09>] as_dispatch_request+0x129/0x410 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<c02076e0>] as_work_handler+0x0/0x30 (16)
[<c013a7e5>] worker_thread+0x215/0x250 (16)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
kacpid [f7f20a70]S 00000080 7716 34 25 35 33 (L-TLB)
f7f23f3c 00000080 00000100 00000080 00000100 5d3af66f 00000009 000003e9
f7f20ba8 f7f20a70 f7eb9a70 c1f1f160 5d475150 00000009 f7f23f3c 00000001
f7f22000 f7f22000 c23b7ef8 f7f23f64 c037ffc5 c0136d8a f7f24c24 f7f22000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0136d8a>] do_sigaction+0x1ca/0x210 (4)
[<c013a7e5>] worker_thread+0x215/0x250 (36)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 9 [f7f4aa70]S F7F4AA70 7712 35 25 306 34 (L-TLB)
f7f4df7c ffffffff ffffffff f7f4aa70 f7f4df60 5d52b46c 00000009 000003ac
f7f4aba8 f7f4aa70 c03dfc40 c1f0f160 5d5cb452 00000009 f7f4df94 00000002
f7f4c000 00000009 c03e5e84 f7f4dfa4 c037ffc5 00000246 00000023 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c0154203>] do_irqd+0x113/0x1b0 (24)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
khubd [f78bea70]S 00000000 7780 306 25 364 35 (L-TLB)
f7b29f7c f7b28000 f7b29fac 00000000 00000002 7ec25516 00000009 000001cf
f78beba8 f78bea70 c03dfc40 c1f0f160 7ecb87b8 00000009 f7b28000 00000002
f7b28000 f7b28000 c013ec80 f7b29fa4 c037ffc5 7ecb43c1 f7b29fac c040a800
Call Trace:
[<c013ec80>] autoremove_wake_function+0x0/0x50 (76)
[<c037ffc5>] schedule+0xa5/0x120 (8)
[<c02d5e30>] hub_thread+0x0/0xe0 (20)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (12)
[<c02d5e30>] hub_thread+0x0/0xe0 (4)
[<c02d5edf>] hub_thread+0xaf/0xe0 (4)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (12)
[<c013e78c>] kthread+0xac/0xb0 (24)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
pdflush [f7bc6a70]S F7BC9F80 7764 364 25 365 306 (L-TLB)
f7bc9f6c 0003fff0 c015bc39 f7bc9f80 00000000 e4a4f6ed 00000017 00000158
f7bc6ba8 f7bc6a70 c03dfc40 c1f0f160 e4a6550a 00000017 00000000 00000002
f7bc8000 f7bc9fbc f7bc9fb0 f7bc9f94 c037ffc5 00000000 00001363 00000000
Call Trace:
[<c015bc39>] get_dirty_limits+0x29/0x120 (12)
[<c037ffc5>] schedule+0xa5/0x120 (72)
[<c015cb60>] pdflush+0x0/0x30 (36)
[<c015ca41>] __pdflush+0x81/0x1a0 (4)
[<c015cb88>] pdflush+0x28/0x30 (20)
[<c013e78c>] kthread+0xac/0xb0 (32)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
pdflush [f7850a70]S 00000282 7556 365 25 367 364 (L-TLB)
f7b83f6c c03eaf68 c0132527 00000282 c014382d d678ea85 00000092 00000268
f7850ba8 f7850a70 c03dfc40 c1f0f160 d67fd305 00000092 f7b83f88 00000002
f7b82000 f7b83fbc f7b83fb0 f7b83f94 c037ffc5 00000005 00000000 00000000
Call Trace:
[<c0132527>] __mod_timer+0x97/0xe0 (12)
[<c014382d>] rt_up_read+0x2d/0x80 (8)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c015cb60>] pdflush+0x0/0x30 (36)
[<c015ca41>] __pdflush+0x81/0x1a0 (4)
[<c015cb88>] pdflush+0x28/0x30 (20)
[<c013e78c>] kthread+0xac/0xb0 (32)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
kswapd0 [f7bbba70]S C02115A2 7792 366 1 556 25 (L-TLB)
f7bbdf88 f7bbbc33 f7bbdfc0 c02115a2 00000000 9046fbbe 00000009 000004d7
f7bbbba8 f7bbba70 f7eb9a70 c1f1f160 9049e422 00000009 00000000 00000001
f7bbc000 c03e6380 c03eae04 f7bbdfb0 c037ffc5 f7bbc000 c012a530 f7bbdfc0
Call Trace:
[<c02115a2>] vsnprintf+0x352/0x610 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c012a530>] daemonize+0x1c0/0x230 (8)
[<c01602b5>] kswapd+0x105/0x120 (32)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (20)
[<c01601b0>] kswapd+0x0/0x120 (16)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
aio/0 [f7a66a70]S 00000100 7764 367 25 368 365 (L-TLB)
f7babf3c 00000080 00000180 00000100 00000100 91801607 00000009 00000185
f7a66ba8 f7a66a70 f7eb4a70 c1f0f160 9185a0b7 00000009 f7babf3c 00000001
f7baa000 f7baa000 f7453ef8 f7babf64 c037ffc5 c0136d8a f798dc24 f7baa000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0136d8a>] do_sigaction+0x1ca/0x210 (4)
[<c013a7e5>] worker_thread+0x215/0x250 (36)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
aio/1 [f7a02a70]S 00000100 7764 368 25 445 367 (L-TLB)
f7b8df3c 00000080 00000180 00000100 00000100 91778bde 00000009 0000014b
f7a02ba8 f7a02a70 f7eb4a70 c1f1f160 918678ff 00000009 f7b8df3c 00000001
f7b8c000 f7b8c000 f7454ef8 f7b8df64 c037ffc5 c0136d8a f7988c24 f7b8c000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0136d8a>] do_sigaction+0x1ca/0x210 (4)
[<c013a7e5>] worker_thread+0x215/0x250 (36)
[<c0122730>] default_wake_function+0x0/0x20 (64)
[<c013a5d0>] worker_thread+0x0/0x250 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 8 [f7027a70]S 00000000 7712 445 25 458 368 (L-TLB)
f7029f7c 00000001 c1f0f160 00000000 00000180 bde245a7 00000009 00000e5c
f7027ba8 f7027a70 f7e0ba70 c1f0f160 bde24bee 00000009 c0450a00 00000000
f7028000 00000008 c03e5e80 f7029fa4 c037ffc5 0000007b 0000007b ffffffef
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01540c1>] do_hardirq+0x61/0x90 (16)
[<c0154203>] do_irqd+0x113/0x1b0 (24)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
kseriod [f705ba70]S F7786DA4 7004 458 25 463 445 (L-TLB)
f705df78 6b17333f 00008080 f7786da4 00000000 8b58afcf 0000000a 0000095f
f705bba8 f705ba70 f7eb9a70 c1f1f160 8b5a421a 0000000a f7786000 00000001
f705c000 f705c000 f705dfac f705dfa0 c037ffc5 f7786da4 c1f215c0 01a84f60
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0176cee>] kfree+0x6e/0x80 (16)
[<c028d730>] serio_thread+0x0/0xf0 (20)
[<c028d7ef>] serio_thread+0xbf/0xf0 (4)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (16)
[<c013e78c>] kthread+0xac/0xb0 (24)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 12 [f7045a70]S FA355A70 7612 463 25 496 458 (L-TLB)
f7047f7c 00000000 0000000c fa355a70 f755655c 8b51f1d6 0000000a 0000073a
f7045ba8 f7045a70 f7eb4a70 c1f0f160 8b59ecb6 0000000a 0000000c 0000000c
f7046000 0000000c c03e5e90 f7047fa4 c037ffc5 00000000 c0450c00 c0450c4c
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0154203>] do_irqd+0x113/0x1b0 (40)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 14 [f78cea70]S C02C0360 7188 496 25 498 463 (L-TLB)
f78d1f7c bca963ab 00000001 c02c0360 f714b854 328c679e 0000000d 00000eb3
f78ceba8 f78cea70 f764da70 c1f0f160 3293ef0e 0000000d 0000000e 0000000e
f78d0000 0000000e c03e5e98 f78d1fa4 c037ffc5 00000000 c0450d00 c0450d4c
Call Trace:
[<c02c0360>] ide_dma_intr+0x0/0xc0 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c0154203>] do_irqd+0x113/0x1b0 (40)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 15 [f7bdaa70]S C02C64B0 7608 498 25 537 496 (L-TLB)
f7bddf7c f7bddf64 f714b770 c02c64b0 f714b770 43623c17 0000000c 000005b9
f7bdaba8 f7bdaa70 c03dfc40 c1f0f160 4363d168 0000000c 0000000f 00000002
f7bdc000 0000000f c03e5e9c f7bddfa4 c037ffc5 00000000 c0450d80 c0450dcc
Call Trace:
[<c02c64b0>] cdrom_pc_intr+0x0/0x290 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c0154203>] do_irqd+0x113/0x1b0 (40)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 1 [f77daa70]S 14150180 [curr] 6628 537 25 545 498 (L-TLB)
c037f881 00000000 00000001 14150180 f7628394 00000000 f77dc000 c04506cc
c0153030 c03dfc40 f7e1fa70 c1f0f160 00000000 00000001 00000000 00000000
c0450680 f7628394 00000001 c04506cc c0153fd2 00000007 c0450680 c04506cc
Call Trace:
[<c037f881>] __schedule+0x331/0x9d0 (4)
[<c0153030>] handle_IRQ_event+0x60/0xe0 (32)
[<c0153fd2>] thread_edge_irq+0x62/0xf0 (48)
[<c0154097>] do_hardirq+0x37/0x90 (24)
[<c01541b0>] do_irqd+0xc0/0x1b0 (16)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 4 [f70c6a70]S 00000060 7644 545 25 956 537 (L-TLB)
f70c9f7c 00000002 00000001 00000060 f5828724 9c595d2c 0000000c 00000b61
f70c6ba8 f70c6a70 f7e1fa70 c1f0f160 9c5bd9d3 0000000c 00000004 00000004
f70c8000 00000004 c03e5e70 f70c9fa4 c037ffc5 00000000 c0450800 c045084c
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0154203>] do_irqd+0x113/0x1b0 (40)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
kjournald [f77cfa70]S 00000000 7528 556 1 561 366 (L-TLB)
f77d1f6c f77d1fa0 00000000 00000000 00000000 a5e3047c 0000000a 00006cfc
f77cfba8 f77cfa70 f7eb9a70 c1f1f160 a5e59c75 0000000a 00000000 00000001
f77d0000 f7373c0c f7373bf8 f77d1f94 c037ffc5 00000000 c01227fc 00000001
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01227fc>] __wake_up+0x3c/0x70 (8)
[<f8867735>] kjournald+0x215/0x230 [jbd] (32)
[<c010336e>] ret_from_fork+0x6/0x14 (28)
[<f8867510>] commit_timeout+0x0/0x10 [jbd] (4)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (20)
[<f8867520>] kjournald+0x0/0x230 [jbd] (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
init [f7001a70]S FFFFFFFF 7296 561 1 562 703 556 (NOTLB)
f7179f1c ffffffff 00000000 ffffffff 00000001 2c871bd5 0000000b 0000065e
f7001ba8 f7001a70 c03dfc40 c1f0f160 2c943a52 0000000b 00000000 00000002
f7178000 00000001 00000004 f7179f44 c037ffc5 00000004 00000004 f7001a70
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01e152a>] task_has_perm+0x2a/0x30 (16)
[<c012c66c>] do_wait+0x2ac/0x420 (24)
[<c0122730>] default_wake_function+0x0/0x20 (52)
[<c012c895>] sys_wait4+0x35/0x40 (28)
[<c012c8c5>] sys_waitpid+0x25/0x30 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
rc.sysinit [f7176a70]S 00000000 6300 562 561 1210 (NOTLB)
f719bf1c c01644cf 3d96e065 00000000 ffc31000 2fa1c9ae 0000000d 0000055e
f7176ba8 f7176a70 f7a96a70 c1f0f160 2fad6483 0000000d 00000000 fd7ffffd
f719a000 00000001 00000004 f719bf44 c037ffc5 00000004 00000004 f7176a70
Call Trace:
[<c01644cf>] do_wp_page+0x18f/0x350 (8)
[<c037ffc5>] schedule+0xa5/0x120 (76)
[<c01e152a>] task_has_perm+0x2a/0x30 (16)
[<c012c66c>] do_wait+0x2ac/0x420 (24)
[<c0122730>] default_wake_function+0x0/0x20 (52)
[<c012c895>] sys_wait4+0x35/0x40 (28)
[<c012c8c5>] sys_waitpid+0x25/0x30 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udevd [f7206a70]S 00000002 6736 703 1 1065 947 561 (NOTLB)
f599dea0 00000002 00000044 00000002 000200d0 3386f79e 0000000d 00001245
f7206ba8 f7206a70 f7603a70 c1f1f160 338b78ae 0000000d f5249e78 c03ead80
f599c000 00000080 00000007 f599dec8 c037ffc5 00000000 00000000 000000d0
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c015a555>] __get_free_pages+0x35/0x90 (20)
[<c03809b5>] schedule_timeout+0x75/0xc0 (20)
[<c018e7f0>] __pollwait+0x80/0xd0 (8)
[<c013ea86>] add_wait_queue+0x16/0x40 (8)
[<c030f014>] datagram_poll+0x14/0xd0 (12)
[<c018ec3f>] do_select+0x2ef/0x330 (20)
[<c018e770>] __pollwait+0x0/0xd0 (96)
[<c018eece>] sys_select+0x21e/0x3c0 (28)
[<c0103447>] sysenter_past_esp+0x54/0x75 (64)
kmodule [f71b4a70]S 00000282 7296 947 1 703 (NOTLB)
f5a9de18 00000246 00000017 00000282 00000017 62a6eed1 0000000c 0000b552
f71b4ba8 f71b4a70 f7eb9a70 c1f1f160 62b1c24e 0000000c 00000000 00000001
f5a9c000 f5b7cd64 f5a9dea4 f5a9de40 c037ffc5 c0174089 c017333f 00000017
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0174089>] poison_obj+0x29/0x60 (4)
[<c017333f>] dbg_redzone1+0x1f/0x60 (4)
[<c03809b5>] schedule_timeout+0x75/0xc0 (32)
[<c013ebbc>] prepare_to_wait_exclusive+0x1c/0x70 (32)
[<c030e773>] wait_for_packet+0x113/0x150 (16)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (12)
[<c030e82f>] skb_recv_datagram+0x7f/0xd0 (28)
[<c037a29c>] unix_accept+0x7c/0x110 (28)
[<c0307ae5>] sys_accept+0x105/0x1e0 (28)
[<c01e037a>] avc_has_perm+0x5a/0x70 (12)
[<c01e4dec>] socket_has_perm+0x5c/0x70 (56)
[<c0212a6e>] copy_from_user+0x4e/0xc0 (72)
[<c0308923>] sys_socketcall+0xf3/0x2a0 (28)
[<c01797f7>] filp_close+0x47/0x90 (40)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
IRQ 6 [f76e4a70]S 00000006 7640 956 25 1059 545 (L-TLB)
f5a2bf7c 00000000 f888b7a3 00000006 f5789c30 6be8b03a 0000000c 00008cb1
f76e4ba8 f76e4a70 f7e0ba70 c1f0f160 6bea6486 0000000c 00000006 00000006
f5a2a000 00000006 c03e5e78 f5a2bfa4 c037ffc5 00000000 c0450900 c045094c
Call Trace:
[<f888b7a3>] floppy_interrupt+0x143/0x1d0 [floppy] (12)
[<c037ffc5>] schedule+0xa5/0x120 (72)
[<c0154203>] do_irqd+0x113/0x1b0 (40)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
IRQ 177 [f76c6a70]S F76C6A70 7712 1059 25 1095 956 (L-TLB)
f5a01f7c ffffffff ffffffff f76c6a70 f5a01f60 bd7edfa0 0000000c 00000446
f76c6ba8 f76c6a70 f76fda70 c1f0f160 bd8335c7 0000000c f5a01f94 00000072
f5a00000 000000b1 c03e6124 f5a01fa4 c037ffc5 00000246 00000423 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c0154203>] do_irqd+0x113/0x1b0 (24)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
udev [f7681a70]S 00000000 6816 1065 703 1096 1098 (NOTLB)
f59b5f1c c01644cf 3dc64065 00000000 c01610bd c825dc82 0000000c 00002047
f7681ba8 f7681a70 f7206a70 c1f0f160 c82de35d 0000000c 00000000 ffffffff
f59b4000 00000001 00000004 f59b5f44 c037ffc5 00000004 00000004 f7681a70
Call Trace:
[<c01644cf>] do_wp_page+0x18f/0x350 (8)
[<c01610bd>] kmap_high+0x12d/0x200 (12)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c01e152a>] task_has_perm+0x2a/0x30 (16)
[<c012c66c>] do_wait+0x2ac/0x420 (24)
[<c0153514>] __do_IRQ+0x104/0x150 (4)
[<c0122730>] default_wake_function+0x0/0x20 (48)
[<c012c895>] sys_wait4+0x35/0x40 (28)
[<c012c8c5>] sys_waitpid+0x25/0x30 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
kgameportd [f751ea70]S 00000000 7824 1095 25 1105 1059 (L-TLB)
f5121f78 00000000 f5121fac 00000000 00000002 c741385d 0000000c 000002dd
f751eba8 f751ea70 f754ea70 c1f0f160 c74f4da7 0000000c 0000a040 c741385d
f5120000 f5120000 f5121fac f5121fa0 c037ffc5 f8981bc0 f5121fac f8981de0
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<f897e800>] gameport_thread+0x0/0xf0 [gameport] (20)
[<f897e800>] gameport_thread+0x0/0xf0 [gameport] (16)
[<f897e8bf>] gameport_thread+0xbf/0xf0 [gameport] (4)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (16)
[<c013e78c>] kthread+0xac/0xb0 (24)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
udev_run_hotp [f755da70]S 00000000 6684 1096 1065 1108 (NOTLB)
f5117f1c c01644cf 3f581065 00000000 ffc54000 ca601bdd 0000000c 00000eb9
f755dba8 f755da70 f71cea70 c1f1f160 ca6a4117 0000000c 00000000 ffffffff
f5116000 00000001 00000004 f5117f44 c037ffc5 00000004 00000004 f755da70
Call Trace:
[<c01644cf>] do_wp_page+0x18f/0x350 (8)
[<c037ffc5>] schedule+0xa5/0x120 (76)
[<c01e152a>] task_has_perm+0x2a/0x30 (16)
[<c012c66c>] do_wait+0x2ac/0x420 (24)
[<c0122730>] default_wake_function+0x0/0x20 (52)
[<c012c895>] sys_wait4+0x35/0x40 (28)
[<c012c8c5>] sys_waitpid+0x25/0x30 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f70bea70]S 00000000 6724 1098 703 1176 1099 1065 (NOTLB)
f50f1f1c c01644cf 3f007065 00000000 c01610bd 05db8b57 0000000d 00003f78
f70beba8 f70bea70 f772da70 c1f0f160 05e2c919 0000000d 00000000 ffffffff
f50f0000 00000001 00000004 f50f1f44 c037ffc5 00000004 00000004 f70bea70
Call Trace:
[<c01644cf>] do_wp_page+0x18f/0x350 (8)
[<c01610bd>] kmap_high+0x12d/0x200 (12)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c01e152a>] task_has_perm+0x2a/0x30 (16)
[<c012c66c>] do_wait+0x2ac/0x420 (24)
[<c0122730>] default_wake_function+0x0/0x20 (52)
[<c012c895>] sys_wait4+0x35/0x40 (28)
[<c012c8c5>] sys_waitpid+0x25/0x30 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f7161a70]D 32F5936E 6728 1099 703 1118 1098 (NOTLB)
f5139ef4 f76fda70 c1f1f160 32f5936e 0000000d 33a54edb 0000000d 00002ec9
f7161ba8 f7161a70 f7845a70 c1f1f160 33a6a429 0000000d ffffffff c1f115c8
f5138000 00800000 ffffffff f5139f1c c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0176cac>] kfree+0x2c/0x80 (80)
[<c017b15e>] __fput+0xbe/0x1b0 (16)
[<c01797f7>] filp_close+0x47/0x90 (36)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
IRQ 185 [f704ca70]S F704CA70 7660 1105 25 1199 1095 (L-TLB)
f5145f7c ffffffff ffffffff f704ca70 f5145f60 c95650c2 0000000c 00000941
f704cba8 f704ca70 f70bea70 c1f0f160 c95c347a 0000000c f5145f94 00000072
f5144000 000000b9 c03e6144 f5145fa4 c037ffc5 00000246 00000451 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0123045>] do_sched_setscheduler+0x75/0xc0 (16)
[<c0154203>] do_irqd+0x113/0x1b0 (24)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
ifup-eth [f71cea70]S FFFFFFFF 6384 1108 1096 1200 (NOTLB)
f5155f1c ffffffff 00000000 ffffffff 00000001 217ee5a8 0000000d 000006fa
f71ceba8 f71cea70 f782aa70 c1f1f160 21873016 0000000d 00000000 00000004
f5154000 00000001 00000004 f5155f44 c037ffc5 00000004 00000004 f71cea70
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c01e152a>] task_has_perm+0x2a/0x30 (16)
[<c012c66c>] do_wait+0x2ac/0x420 (24)
[<c0122730>] default_wake_function+0x0/0x20 (52)
[<c012c895>] sys_wait4+0x35/0x40 (28)
[<c012c8c5>] sys_waitpid+0x25/0x30 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f7845a70]D 32283ED5 6816 1118 703 1121 1099 (NOTLB)
f51afc98 f7158a70 c1f1f160 32283ed5 0000000d 33a54edb 0000000d 0000214a
f7845ba8 f7845a70 f79a1a70 c1f1f160 33a6c573 0000000d ffffffff c1f115c8
f51ae000 00800000 ffffffff f51afcc0 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c01b1ed5>] proc_alloc_inode+0x15/0x70 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c01b1ed5>] proc_alloc_inode+0x15/0x70 (24)
[<c0194ce5>] alloc_inode+0x25/0x1b0 (16)
[<c0195824>] new_inode+0x14/0x90 (20)
[<c01b3bdc>] proc_pid_make_inode+0x1c/0xf0 (12)
[<c01b435e>] proc_pident_lookup+0xae/0x350 (28)
[<c01939d9>] d_alloc+0x149/0x1c0 (16)
[<c01887d8>] real_lookup+0xc8/0x100 (36)
[<c0188b4b>] do_lookup+0x8b/0xa0 (32)
[<c0188cbb>] __link_path_walk+0x15b/0x1010 (24)
[<c011feaa>] wake_idle+0x9a/0xb0 (4)
[<c0189bc3>] link_path_walk+0x53/0x130 (96)
[<c014325b>] release_lock+0x5b/0x80 (28)
[<c0179574>] get_unused_fd+0xb4/0xe0 (32)
[<c0189fca>] path_lookup+0xaa/0x210 (44)
[<c018a178>] __path_lookup_intent_open+0x48/0xa0 (36)
[<c018a1e6>] path_lookup_open+0x16/0x20 (20)
[<c018a990>] open_namei+0x70/0x630 (16)
[<c011e400>] change_page_attr+0x30/0x70 (20)
[<c011e5a4>] kernel_map_pages+0x54/0xe0 (20)
[<c0174089>] poison_obj+0x29/0x60 (8)
[<c0179312>] filp_open+0x22/0x50 (28)
[<c014325b>] release_lock+0x5b/0x80 (16)
[<c0179574>] get_unused_fd+0xb4/0xe0 (32)
[<c01796cd>] do_sys_open+0x3d/0xd0 (36)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
udev [f770ea70]D C011E028 6816 1121 703 1137 1118 (NOTLB)
f519de58 00000000 00000000 c011e028 00000004 339e924e 0000000d 00001d1d
f770eba8 f770ea70 f7574a70 c1f0f160 33a6d2cf 0000000d 00000000 c1f115c8
f519c000 00800000 ffffffff f519de80 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c011e028>] __change_page_attr+0x58/0x400 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c03800a9>] preempt_schedule+0x69/0x80 (4)
[<c0188258>] getname+0x28/0xf0 (24)
[<c018a3fb>] __user_walk+0x1b/0x50 (20)
[<c018410a>] vfs_lstat+0x1a/0x50 (20)
[<c037f881>] __schedule+0x331/0x9d0 (44)
[<c018476f>] sys_lstat64+0xf/0x30 (40)
[<c0380117>] preempt_schedule_irq+0x57/0x80 (40)
[<c01033e8>] need_resched+0x20/0x24 (20)
[<c0103447>] sysenter_past_esp+0x54/0x75 (16)
udev [f71e1a70]D 32F60F7E 6804 1137 703 1138 1121 (NOTLB)
f5107e58 f76fda70 c1f1f160 32f60f7e 0000000d 339e924e 0000000d 00002832
f71e1ba8 f71e1a70 f770ea70 c1f0f160 33a6b5b2 0000000d ffffffff c1f115c8
f5106000 00800000 ffffffff f5107e80 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c03800a9>] preempt_schedule+0x69/0x80 (4)
[<c0188258>] getname+0x28/0xf0 (24)
[<c018a3fb>] __user_walk+0x1b/0x50 (20)
[<c018410a>] vfs_lstat+0x1a/0x50 (20)
[<c0175e9e>] cache_free_debugcheck+0x14e/0x2b0 (20)
[<c0176cdb>] kfree+0x5b/0x80 (24)
[<c018476f>] sys_lstat64+0xf/0x30 (40)
[<c017b1e4>] __fput+0x144/0x1b0 (20)
[<c0143c8f>] atomic_dec_and_spin_lock+0x3f/0x60 (12)
[<c01983f3>] mntput_no_expire+0x13/0x70 (12)
[<c01797f7>] filp_close+0x47/0x90 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f7a96a70]D 00000001 6816 1138 703 1142 1137 (NOTLB)
f5109e44 f5109e50 c01223d9 00000001 00000001 3396197a 0000000d 0000059c
f7a96ba8 f7a96a70 f757fa70 c1f1f160 33a4bd76 0000000d f757fa70 f757ff8c
f5108000 00800000 ffffffff f5109e6c c037ffc5 c0142fbe 00000004 00000000
Call Trace:
[<c01223d9>] dependent_sleeper+0x109/0x460 (12)
[<c037ffc5>] schedule+0xa5/0x120 (72)
[<c0142fbe>] task_blocks_on_lock+0x11e/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c01ee623>] security_sid_to_context+0xa3/0x100 (76)
[<c0176a6b>] __kmalloc_track_caller+0x8b/0x140 (4)
[<c01ee495>] context_struct_to_string+0x95/0x180 (36)
[<c01ee623>] security_sid_to_context+0xa3/0x100 (56)
[<c01e7234>] sel_write_context+0x64/0xd0 (32)
[<c01e7438>] selinux_transaction_write+0x68/0xb0 (40)
[<c01e73d0>] selinux_transaction_write+0x0/0xb0 (28)
[<c017a37b>] vfs_write+0xbb/0x180 (4)
[<c017a4f1>] sys_write+0x41/0x70 (24)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
udev [f70cea70]D 32F73ED4 6816 1142 703 1150 1138 (NOTLB)
f59a9e58 f76fda70 c1f1f160 32f73ed4 0000000d 339e924e 0000000d 00001364
f70ceba8 f70cea70 f71e1a70 c1f0f160 33a68d80 0000000d ffffffff c1f115c8
f59a8000 00800000 ffffffff f59a9e80 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0188258>] getname+0x28/0xf0 (28)
[<c018a3fb>] __user_walk+0x1b/0x50 (20)
[<c018410a>] vfs_lstat+0x1a/0x50 (20)
[<c0156860>] filemap_nopage+0x0/0x3c0 (4)
[<c0165771>] __handle_mm_fault+0x141/0x380 (4)
[<c014382d>] rt_up_read+0x2d/0x80 (56)
[<c018476f>] sys_lstat64+0xf/0x30 (20)
[<c014382d>] rt_up_read+0x2d/0x80 (56)
[<c011d130>] do_page_fault+0x0/0x680 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (8)
udev [f7753a70]D 32F7C907 6804 1150 703 1152 1142 (NOTLB)
f514be58 f76fda70 c1f1f160 32f7c907 0000000d 339e924e 0000000d 0000116f
f7753ba8 f7753a70 f70cea70 c1f0f160 33a67a1c 0000000d ffffffff c1f115c8
f514a000 00800000 ffffffff f514be80 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0188258>] getname+0x28/0xf0 (28)
[<c018a3fb>] __user_walk+0x1b/0x50 (20)
[<c018410a>] vfs_lstat+0x1a/0x50 (20)
[<c0156860>] filemap_nopage+0x0/0x3c0 (4)
[<c0165771>] __handle_mm_fault+0x141/0x380 (4)
[<c014382d>] rt_up_read+0x2d/0x80 (56)
[<c018476f>] sys_lstat64+0xf/0x30 (20)
[<c01797f7>] filp_close+0x47/0x90 (56)
[<c011d130>] do_page_fault+0x0/0x680 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (8)
udev [f79a1a70]D 00000000 6816 1152 703 1158 1150 (L-TLB)
f5b2de9c 3196467d 0000000d 00000000 00000000 33a54edb 0000000d 00001472
f79a1ba8 f79a1a70 f7eb9a70 c1f1f160 33a6d9e5 0000000d f770ea70 00000001
f5b2c000 00800004 ffffffff f5b2dec4 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0176c49>] kmem_cache_free+0x39/0x70 (80)
[<c0166701>] remove_vma+0x41/0x50 (24)
[<c0168937>] exit_mmap+0xe7/0x150 (12)
[<c01257c3>] mmput+0x33/0xa0 (40)
[<c012b418>] do_exit+0x118/0x4b0 (12)
[<c012b828>] do_group_exit+0x38/0xc0 (40)
[<c01797f7>] filp_close+0x47/0x90 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f7574a70]D 00000000 6744 1158 703 1174 1152 (NOTLB)
f59bdef0 c016190f c1ea02b8 00000000 ffd02038 339e924e 0000000d 0000127f
f7574ba8 f7574a70 c03dfc40 c1f0f160 33a6e54e 0000000d 35a3a000 00000002
f59bc000 00800000 ffffffff f59bdf18 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c016190f>] page_address+0xaf/0xc0 (8)
[<c037ffc5>] schedule+0xa5/0x120 (76)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0176894>] __cache_free+0x64/0x70 (4)
[<c0188258>] getname+0x28/0xf0 (24)
[<c01796ac>] do_sys_open+0x1c/0xd0 (20)
[<c01797f7>] filp_close+0x47/0x90 (8)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f757fa70]D C01E1617 6716 1174 703 1178 1158 (NOTLB)
f51a1e9c f51a1ea4 00000006 c01e1617 00000006 33a54edb 0000000d 00000395
f757fba8 f757fa70 f7603a70 c1f1f160 33a58fcb 0000000d 00000062 00000093
f51a0000 00800000 ffffffff f51a1ec4 c037ffc5 c0142fbe 00000004 f524ded8
Call Trace:
[<c01e1617>] inode_has_perm+0x47/0x80 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c0142fbe>] task_blocks_on_lock+0x11e/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c014b9fd>] module_text_address+0xd/0x30 (80)
[<c013c70c>] kernel_text_address+0x1c/0x30 (8)
[<c017402a>] store_stackinfo+0x5a/0x90 (8)
[<c0176c54>] kmem_cache_free+0x44/0x70 (4)
[<c0175f79>] cache_free_debugcheck+0x229/0x2b0 (20)
[<c017932b>] filp_open+0x3b/0x50 (8)
[<c0176c54>] kmem_cache_free+0x44/0x70 (16)
[<c0176856>] __cache_free+0x26/0x70 (24)
[<c0176c54>] kmem_cache_free+0x44/0x70 (20)
[<c0179732>] do_sys_open+0xa2/0xd0 (24)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
udev_run_hotp [f76f6a70]S 00000000 6816 1176 1098 1189 (NOTLB)
f5ac3f1c c01644cf 3e6a6065 00000000 ffc8b000 10a7a70c 0000000d 000075f6
f76f6ba8 f76f6a70 f7644a70 c1f1f160 10b3f11c 0000000d 00000000 ffffffff
f5ac2000 00000001 00000004 f5ac3f44 c037ffc5 00000004 00000004 f76f6a70
Call Trace:
[<c01644cf>] do_wp_page+0x18f/0x350 (8)
[<c037ffc5>] schedule+0xa5/0x120 (76)
[<c01e152a>] task_has_perm+0x2a/0x30 (16)
[<c012c66c>] do_wait+0x2ac/0x420 (24)
[<c0122730>] default_wake_function+0x0/0x20 (52)
[<c012c895>] sys_wait4+0x35/0x40 (28)
[<c012c8c5>] sys_waitpid+0x25/0x30 (12)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f71a6a70]D C0142F53 6788 1178 703 1179 1174 (NOTLB)
f5a55ea0 00000006 c011ff47 c0142f53 c0174089 3396197a 0000000d 00000661
f71a6ba8 f71a6a70 f757fa70 c1f1f160 33a3181a 0000000d 00000000 c0459408
f5a54000 00800000 ffffffff f5a55ec8 c037ffc5 c0142f53 00000004 f5109edc
Call Trace:
[<c011ff47>] try_to_wake_up+0x87/0x4f0 (12)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0174089>] poison_obj+0x29/0x60 (4)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c01ee60a>] security_sid_to_context+0x8a/0x100 (80)
[<c01e7234>] sel_write_context+0x64/0xd0 (32)
[<c019f316>] simple_transaction_get+0xb6/0xd0 (16)
[<c01e7438>] selinux_transaction_write+0x68/0xb0 (24)
[<c01e73d0>] selinux_transaction_write+0x0/0xb0 (28)
[<c017a37b>] vfs_write+0xbb/0x180 (4)
[<c017a4f1>] sys_write+0x41/0x70 (24)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
udev [f7947a70]D 00000004 6608 1179 703 1190 1178 (NOTLB)
f50dbea0 00000000 0000001f 00000004 c0174089 3396197a 0000000d 0000040d
f7947ba8 f7947a70 f772da70 c1f1f160 33a2a331 0000000d f50da000 c0459408
f50da000 00800000 ffffffff f50dbec8 c037ffc5 c0142f53 00000004 f50d9e94
Call Trace:
[<c0174089>] poison_obj+0x29/0x60 (20)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c01ee60a>] security_sid_to_context+0x8a/0x100 (80)
[<c01e7234>] sel_write_context+0x64/0xd0 (32)
[<c019f316>] simple_transaction_get+0xb6/0xd0 (16)
[<c01e7438>] selinux_transaction_write+0x68/0xb0 (24)
[<c01e73d0>] selinux_transaction_write+0x0/0xb0 (28)
[<c017a37b>] vfs_write+0xbb/0x180 (4)
[<c017a4f1>] sys_write+0x41/0x70 (24)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
20-hal.hotplu [f7644a70]D 00000000 6880 1189 1176 (NOTLB)
f5247e4c 00000000 00000202 00000000 c1f0f160 339e924e 0000000d 00001402
f7644ba8 f7644a70 f7753a70 c1f0f160 33a668ad 0000000d c0159faf c1f115c8
f5246000 00800000 ffffffff f5247e74 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c0159faf>] buffered_rmqueue+0x9f/0x180 (60)
[<c037ffc5>] schedule+0xa5/0x120 (24)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c016a26a>] anon_vma_prepare+0xca/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c016a26a>] anon_vma_prepare+0xca/0xf0 (28)
[<c016122b>] kunmap_high+0x9b/0xf0 (4)
[<c01650d4>] do_anonymous_page+0x124/0x240 (20)
[<c01658ff>] __handle_mm_fault+0x2cf/0x380 (36)
[<c011d550>] do_page_fault+0x420/0x680 (68)
[<c0166701>] remove_vma+0x41/0x50 (8)
[<c016857a>] do_munmap+0xea/0x120 (28)
[<c011d130>] do_page_fault+0x0/0x680 (40)
[<c010403f>] error_code+0x4f/0x54 (8)
udev [f772da70]D 00000004 6816 1190 703 1191 1179 (NOTLB)
f5a35ea0 f51a1e84 f5a35e9c 00000004 c0174089 3396197a 0000000d 00000351
f772dba8 f772da70 f7111a70 c1f1f160 33a2ba6d 0000000d f5a35e8c c0459408
f5a34000 00800000 ffffffff f5a35ec8 c037ffc5 c0142f53 00000004 f5a55e94
Call Trace:
[<c0174089>] poison_obj+0x29/0x60 (20)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c01ee60a>] security_sid_to_context+0x8a/0x100 (80)
[<c01e7234>] sel_write_context+0x64/0xd0 (32)
[<c019f316>] simple_transaction_get+0xb6/0xd0 (16)
[<c01e7438>] selinux_transaction_write+0x68/0xb0 (24)
[<c01e73d0>] selinux_transaction_write+0x0/0xb0 (28)
[<c017a37b>] vfs_write+0xbb/0x180 (4)
[<c017a4f1>] sys_write+0x41/0x70 (24)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
udev [f7158a70]D C01E1617 6816 1191 703 1192 1190 (NOTLB)
f524de9c f524dea4 00000006 c01e1617 00000006 33a54edb 0000000d 0000042e
f7158ba8 f7158a70 f7603a70 c1f1f160 33a62bcd 0000000d 00000000 c0450288
f524c000 00800000 ffffffff f524dec4 c037ffc5 c0142f53 00000004 f51a1ed8
Call Trace:
[<c01e1617>] inode_has_perm+0x47/0x80 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c014b9fd>] module_text_address+0xd/0x30 (80)
[<c013c70c>] kernel_text_address+0x1c/0x30 (8)
[<c017402a>] store_stackinfo+0x5a/0x90 (8)
[<c0176c54>] kmem_cache_free+0x44/0x70 (4)
[<c0175f79>] cache_free_debugcheck+0x229/0x2b0 (20)
[<c017932b>] filp_open+0x3b/0x50 (8)
[<c0176c54>] kmem_cache_free+0x44/0x70 (16)
[<c0176856>] __cache_free+0x26/0x70 (24)
[<c0176c54>] kmem_cache_free+0x44/0x70 (20)
[<c0179732>] do_sys_open+0xa2/0xd0 (24)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
udev [f7111a70]D C0142F53 6788 1192 703 1193 1191 (NOTLB)
f50d9ea0 00000006 c011ff47 c0142f53 c0174089 3396197a 0000000d 00000700
f7111ba8 f7111a70 f71a6a70 c1f1f160 33a2eb73 0000000d 00000000 c0459408
f50d8000 00800000 ffffffff f50d9ec8 c037ffc5 c0142f53 00000004 f51a1edc
Call Trace:
[<c011ff47>] try_to_wake_up+0x87/0x4f0 (12)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0174089>] poison_obj+0x29/0x60 (4)
[<c037ffc5>] schedule+0xa5/0x120 (64)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c01ee60a>] security_sid_to_context+0x8a/0x100 (80)
[<c01e7234>] sel_write_context+0x64/0xd0 (32)
[<c019f316>] simple_transaction_get+0xb6/0xd0 (16)
[<c01e7438>] selinux_transaction_write+0x68/0xb0 (24)
[<c01e73d0>] selinux_transaction_write+0x0/0xb0 (28)
[<c017a37b>] vfs_write+0xbb/0x180 (4)
[<c017a4f1>] sys_write+0x41/0x70 (24)
[<c0103447>] sysenter_past_esp+0x54/0x75 (28)
udev [f760ea70]D 33A62097 6816 1193 703 1196 1192 (NOTLB)
f5a1fd20 c03dfc40 c1f0f160 33a62097 0000000d 339e924e 0000000d 000002e0
f760eba8 f760ea70 f7123a70 c1f0f160 33a64232 0000000d ffffffff f5a1e000
f5a1e000 00800000 ffffffff f5a1fd48 c037ffc5 ffffffff 00000000 f760ea70
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0143343>] ____down_mutex+0x93/0x190 (40)
[<c01938ac>] d_alloc+0x1c/0x1c0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c01938ac>] d_alloc+0x1c/0x1c0 (28)
[<c01887c0>] real_lookup+0xb0/0x100 (36)
[<c0188b4b>] do_lookup+0x8b/0xa0 (32)
[<c01892da>] __link_path_walk+0x77a/0x1010 (24)
[<c011e028>] __change_page_attr+0x58/0x400 (12)
[<c0189bc3>] link_path_walk+0x53/0x130 (88)
[<c0175e9e>] cache_free_debugcheck+0x14e/0x2b0 (36)
[<c0189fca>] path_lookup+0xaa/0x210 (68)
[<c018a40f>] __user_walk+0x2f/0x50 (36)
[<c018410a>] vfs_lstat+0x1a/0x50 (20)
[<c0175e9e>] cache_free_debugcheck+0x14e/0x2b0 (20)
[<c018476f>] sys_lstat64+0xf/0x30 (64)
[<c01797f7>] filp_close+0x47/0x90 (56)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udev [f7123a70]D 32F4655D 6800 1196 703 1212 1193 (NOTLB)
f511fe58 f76fda70 c1f1f160 32f4655d 0000000d 339e924e 0000000d 00000628
f7123ba8 f7123a70 f7644a70 c1f0f160 33a654ab 0000000d ffffffff c1f115c8
f511e000 00800000 ffffffff f511fe80 c037ffc5 c0142f53 00000004 f5153e44
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0188258>] getname+0x28/0xf0 (28)
[<c018a3fb>] __user_walk+0x1b/0x50 (20)
[<c01840bd>] vfs_stat+0x1d/0x50 (20)
[<c0156860>] filemap_nopage+0x0/0x3c0 (4)
[<c0165771>] __handle_mm_fault+0x141/0x380 (4)
[<c014382d>] rt_up_read+0x2d/0x80 (56)
[<c018473f>] sys_stat64+0xf/0x30 (20)
[<c011d130>] do_page_fault+0x0/0x680 (68)
[<c0103447>] sysenter_past_esp+0x54/0x75 (8)
IRQ 169 [f7068a70]S C0455ACC 7660 1199 25 1105 (L-TLB)
f510df7c 00000297 c011ff66 c0455acc 00000246 7fea7bed 00000034 00000453
f7068ba8 f7068a70 f7e15a70 c1f0f160 7ff03c7b 00000034 00000010 000000a9
f510c000 000000a9 c03e6104 f510dfa4 c037ffc5 00000007 c03e6104 f510df98
Call Trace:
[<c011ff66>] try_to_wake_up+0xa6/0x4f0 (12)
[<c037ffc5>] schedule+0xa5/0x120 (72)
[<c01203c9>] wake_up_process+0x19/0x20 (16)
[<c0154203>] do_irqd+0x113/0x1b0 (24)
[<c01540f0>] do_irqd+0x0/0x1b0 (32)
[<c013e78c>] kthread+0xac/0xb0 (4)
[<c013e6e0>] kthread+0x0/0xb0 (12)
[<c0101555>] kernel_thread_helper+0x5/0x10 (16)
arping [f782aa70]S 0000000D 6684 1200 1108 (NOTLB)
f50e3d0c 00000000 21cb14e7 0000000d 00002ed7 21cb14e7 0000000d 00000a8a
f782aba8 f782aa70 f757fa70 c1f1f160 21d497c7 0000000d 00000015 f524150c
f50e2000 f5a7dbf8 f50e3d98 f50e3d34 c037ffc5 00000015 000001f0 000001f0
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c03809b5>] schedule_timeout+0x75/0xc0 (40)
[<c01e037a>] avc_has_perm+0x5a/0x70 (28)
[<c013ebbc>] prepare_to_wait_exclusive+0x1c/0x70 (4)
[<c030e773>] wait_for_packet+0x113/0x150 (16)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (12)
[<c030e82f>] skb_recv_datagram+0x7f/0xd0 (28)
[<c037dfdb>] packet_recvmsg+0x6b/0x1b0 (28)
[<c0306942>] sock_recvmsg+0x122/0x160 (52)
[<c013ec80>] autoremove_wake_function+0x0/0x50 (104)
[<c01223d9>] dependent_sleeper+0x109/0x460 (20)
[<c017b2c5>] fget+0x75/0xa0 (64)
[<c03080ae>] sys_recvfrom+0xce/0x140 (32)
[<c0142317>] hrtimer_start+0xa7/0x100 (40)
[<c012ce9a>] do_setitimer+0x15a/0x570 (40)
[<c0156860>] filemap_nopage+0x0/0x3c0 (16)
[<c0308a28>] sys_socketcall+0x1f8/0x2a0 (96)
[<c0103447>] sysenter_past_esp+0x54/0x75 (60)
modprobe [f75f2a70]D 00000001 6060 1210 562 (NOTLB)
f5153e08 00000019 00000048 00000001 00000000 339e924e 0000000d 0000115d
f75f2ba8 f75f2a70 f760ea70 c1f0f160 33a60bb8 0000000d f7158a70 f7158f8c
f5152000 00800100 ffffffff f5153e30 c037ffc5 c0142fbe 00000004 00000000
Call Trace:
[<c037ffc5>] schedule+0xa5/0x120 (84)
[<c0142fbe>] task_blocks_on_lock+0x11e/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0148bef>] use_module+0xaf/0x150 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0148bef>] use_module+0xaf/0x150 (28)
[<f88e5d7c>] snd_pcm_new+0x0/0x15c [snd_pcm] (12)
[<c01497a0>] resolve_symbol+0xb0/0xc0 (16)
[<c0149cd7>] simplify_symbols+0x77/0x140 (40)
[<c0148a2f>] setup_modinfo_srcversion+0xf/0x20 (8)
[<c0148a20>] setup_modinfo_srcversion+0x0/0x20 (4)
[<c014ac34>] load_module+0x6e4/0xb00 (28)
[<c014b0c8>] sys_init_module+0x58/0x200 (148)
[<c0103447>] sysenter_past_esp+0x54/0x75 (24)
udevd [f76fda70]D C016122B 7460 1212 703 1213 1196 (NOTLB)
f5305ef8 00000000 ffc2fd98 c016122b c1e59860 3396197a 0000000d 000009ea
f76fdba8 f76fda70 f7603a70 c1f1f160 33a50006 0000000d 0000000d c1f215c8
f5304000 00800040 ffffffff f5305f20 c037ffc5 c0142f53 00000004 f5109e80
Call Trace:
[<c016122b>] kunmap_high+0x9b/0xf0 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0188258>] getname+0x28/0xf0 (28)
[<c0101f58>] sys_execve+0x18/0x90 (20)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
udevd [f7603a70]D C016122B 7384 1213 703 1212 (NOTLB)
f5249ef8 00000000 ffc47d98 c016122b c1e885e8 33a54edb 0000000d 00001264
f7603ba8 f7603a70 f7161a70 c1f1f160 33a67560 0000000d 800099c4 c1f215c8
f5248000 00800040 ffffffff f5249f20 c037ffc5 c0142f53 00000004 f7c03f14
Call Trace:
[<c016122b>] kunmap_high+0x9b/0xf0 (16)
[<c037ffc5>] schedule+0xa5/0x120 (68)
[<c0142f53>] task_blocks_on_lock+0xb3/0x150 (4)
[<c0143343>] ____down_mutex+0x93/0x190 (36)
[<c0188258>] getname+0x28/0xf0 (76)
[<c01768ee>] kmem_cache_alloc+0x4e/0xe0 (4)
[<c0188258>] getname+0x28/0xf0 (28)
[<c0101f58>] sys_execve+0x18/0x90 (20)
[<c0103447>] sysenter_past_esp+0x54/0x75 (20)
^ permalink raw reply
* Re: problem mounting a jffs2 filesystem
From: Josh Boyer @ 2006-03-09 2:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David Woodhouse, Miguel Blanco, linux-kernel
In-Reply-To: <20060308220710.GQ4006@stusta.de>
On 3/8/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Mon, Mar 06, 2006 at 01:35:31PM +0000, David Woodhouse wrote:
> > On Sun, 2006-03-05 at 14:04 +0100, Miguel Blanco wrote:
> > > divide error: 0000 [#1]
> > > EIP is at jffs2_scan_medium+0xdf/0x55e [jffs2]
> >
> > Can you try it with the attached patch? Or turn off
> > CONFIG_JFFS2_FS_WRITEBUFFER
>
> This patch seems to be 2.61.6 stuff?
I would agree that it could be 2.6.16 material. Especially given that
it fixes a know problem for a user. David?
josh
^ permalink raw reply
* [PATCH] perfc_defn.h - increase VMX reason size array
From: Ben Thomas @ 2006-03-09 2:14 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
If I'm reading the spec correctly, the April 2005 Intel Virtualization
Technology Specification (Appendix A1) indicates that there are 44
potential exit reason codes. Based upon this, increase the size of
the PERFCOUNTER_ARRAY for vmexits.
Signed-off-by: Ben Thomas (bthomas@virtualiron.com)
--
------------------------------------------------------------------------
Ben Thomas Virtual Iron Software
bthomas@virtualiron.com Tower 1, Floor 2
978-849-1214 900 Chelmsford Street
Lowell, MA 01851
[-- Attachment #2: perfc_defn.patch --]
[-- Type: text/x-patch, Size: 641 bytes --]
diff -r 96678f701d42 xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h Mon Mar 6 11:12:48 2006 -0500
+++ b/xen/include/xen/perfc_defn.h Wed Mar 8 21:01:52 2006 -0500
@@ -26,7 +26,7 @@ PERFCOUNTER_ARRAY(hypercalls,
PERFCOUNTER_ARRAY(hypercalls, "hypercalls", NR_hypercalls)
PERFCOUNTER_ARRAY(exceptions, "exceptions", 32)
-#define VMX_PERF_EXIT_REASON_SIZE 37
+#define VMX_PERF_EXIT_REASON_SIZE 44
#define VMX_PERF_VECTOR_SIZE 0x20
PERFCOUNTER_ARRAY(vmexits, "vmexits", VMX_PERF_EXIT_REASON_SIZE)
PERFCOUNTER_ARRAY(cause_vector, "cause vector", VMX_PERF_VECTOR_SIZE)
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* RE: [Bluez-users] ISSC USB dongle can't ping with size 1000
From: Al @ 2006-03-09 2:01 UTC (permalink / raw)
To: bluez-users
[-- Attachment #1: Type: text/plain, Size: 4655 bytes --]
Hi, Marcel:
I think the problem may not be the buffer size (678) that ISSC device
has. When I ping with size 1400 bytes, hcidump shows host breaks 1400 bytes
into serveal 678 byte packets and sends them to device. Both ping request and ping reply from the other side can be captured in air.
Most likely the problem is occured when ISSC device trys to send
packets with large size to host. From the hcidump, I observe that if devices
like CSR receiving packets with size 1400, it breaks 1400 into serveral 300 (something) packets and sends to host. On the other hand, when ISSC device receives packet with size 900, it sends 900 byte packet to host without breaking. But when the size is more than 1000, hcidump shows ISSC device does not send any packet to host.
I have tried to send HCI_Host_Buffer_Size for ALC link (300 byte for example) to ISSC device:
-----------------------------------------------------------------------------------------------------
int dd = hci_open_dev(di.dev_id);
host_buffer_size_cp cp;
struct hci_request rq;
memset(&rq, 0, sizeof(rq));
rq.ogf = OGF_HOST_CTL;
rq.ocf = OCF_HOST_BUFFER_SIZE;
cp.acl_mtu = 300;
cp.sco_mtu = 30;
cp.acl_max_pkt = 5;
cp.sco_max_pkt = 5;
rq.rparam = &cp;
rq.rlen = HOST_BUFFER_SIZE_CP_SIZE;
if (hci_send_req(dd, &rq, 1000) < 0)
return -1;
hci_close_dev(dd);
return 0;
--------------------------------------------------------
After sending HCI_Host_Buffer_Size command, hcidump shows ISSC
device sends max size of 256 byte to host. Ping with 1500 bytes and Internet
access work so far. I only try this with PAN to implement NAP.
Best Regards,
Al
-----Original Message-----
From: bluez-users-admin@lists.sourceforge.net 代理 Marcel Holtmann
Sent: 2006/2/23 [星期四] 下午 07:23
To: bluez-users@lists.sourceforge.net
Cc:
Subject: Re: [Bluez-users] ISSC USB dongle can't ping with size 1000
Hi Al,
> > I have the same problem as below which was posted last month.
> >
> > > I started to play with the ping size. 'ping -s 900' works, 'ping -s 1000'
> > > kills the PAN connection. There was hope! Then I played with MTU (on both
> > > sides): 'ifconfig bnep0 mtu 1000' solves all my problems (default is
> > > 1500)!!! With this setting I've a rock solid 75 kByte/s transfer rate over
> > > ftp. A mtu of 1017 still works, 1018 definitely kills the connection.
> >
> > I wonder if there is other solutions to this problem cause the above solution needs to set MTU to 1000 on both sides.
> >
> > I try ISSC dongle with IVT software as NAP on Windows XP. Ping with size
> > 1500 works fine. It seems ISSC chip has some problems to work with BlueZ, in
> > addition to adding HCI_RESET.
>
> I am pretty sure that your chip is at fault here. I have no internals
> about your chip, but whatever buffer size you tell us, we will use. And
> BlueZ will use it as fast as possible. The latency is very low and the
> HCI flow control works fine. So I assume there exists a race condition
> in your side of the HCI flow control implementation which triggers a
> problem. You can verify with hcidump that we do everything right. The
> faulty application is actually not BNEP here. I think you can reproduce
> it with any program sending big L2CAP packets. So a test setup with
> l2test and different MTU might trigger it more easily.
and I just did a quick search through the mailing list archive and
actually I found these four version:
ACL MTU: 678:12 SCO MTU: 48:5 LMP Ver: 1.1 LMP Subver: 0x172
ACL MTU: 678:8 SCO MTU: 48:5 LMP Ver: 1.1 LMP Subver: 0x1a4
ACL MTU: 678:8 SCO MTU: 48:10 LMP Ver: 1.2 LMP Subver: 0x1ae
ACL MTU: 678:8 SCO MTU: 48:10 LMP Ver: 1.2 LMP Subver: 0x1f4
The LMP Subver must somehow decode into the version number of your
firmware, but I have no idea how. However you see the different ACL MTU
sizes the chip offers and BlueZ is simply using them.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 5012 bytes --]
^ permalink raw reply
* [PATCH] v9fs: replace snprintf to scnprintf in fs/9p/fcprint.c
From: Latchesar Ionkov @ 2006-03-09 2:03 UTC (permalink / raw)
To: akpm; +Cc: v9fs-developer, linux-kernel
fcprint.c incorrectly assumes that snprintf returns the actual number of
bytes saved in the buffer.
This patch fixes the code replacing snprintf with scnprintf.
Signed-off-by: Latchesar Ionkov <lucho@ionkov.net>
---
commit 8dc8afaa254e9a147c9ab3dc548ba0941823622f
tree cf6f0f16883ef7924bedc5958025527766101e00
parent 371103ccfa30054059bf4e9dc183555b343c10f5
author Latchesar Ionkov <lucho@ionkov.net> Wed, 08 Mar 2006 20:57:30 -0500
committer Latchesar Ionkov <lucho@ionkov.net> Wed, 08 Mar 2006 20:57:30 -0500
fs/9p/fcprint.c | 100 ++++++++++++++++++++++++++++---------------------------
1 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/fs/9p/fcprint.c b/fs/9p/fcprint.c
index c435675..8a05603 100644
--- a/fs/9p/fcprint.c
+++ b/fs/9p/fcprint.c
@@ -54,7 +54,7 @@ v9fs_printqid(char *buf, int buflen, str
b[n++] = 'L';
b[n] = '\0';
- return snprintf(buf, buflen, "(%.16llx %x %s)", (long long int) q->path,
+ return scnprintf(buf, buflen, "(%.16llx %x %s)", (long long int) q->path,
q->version, b);
}
@@ -85,7 +85,7 @@ v9fs_printperm(char *buf, int buflen, in
b[n++] = 'L';
b[n] = '\0';
- return snprintf(buf, buflen, "%s%03o", b, perm&077);
+ return scnprintf(buf, buflen, "%s%03o", b, perm&077);
}
int
@@ -93,28 +93,28 @@ v9fs_printstat(char *buf, int buflen, st
{
int n;
- n = snprintf(buf, buflen, "'%.*s' '%.*s'", st->name.len,
+ n = scnprintf(buf, buflen, "'%.*s' '%.*s'", st->name.len,
st->name.str, st->uid.len, st->uid.str);
if (extended)
- n += snprintf(buf+n, buflen-n, "(%d)", st->n_uid);
+ n += scnprintf(buf+n, buflen-n, "(%d)", st->n_uid);
- n += snprintf(buf+n, buflen-n, " '%.*s'", st->gid.len, st->gid.str);
+ n += scnprintf(buf+n, buflen-n, " '%.*s'", st->gid.len, st->gid.str);
if (extended)
- n += snprintf(buf+n, buflen-n, "(%d)", st->n_gid);
+ n += scnprintf(buf+n, buflen-n, "(%d)", st->n_gid);
- n += snprintf(buf+n, buflen-n, " '%.*s'", st->muid.len, st->muid.str);
+ n += scnprintf(buf+n, buflen-n, " '%.*s'", st->muid.len, st->muid.str);
if (extended)
- n += snprintf(buf+n, buflen-n, "(%d)", st->n_muid);
+ n += scnprintf(buf+n, buflen-n, "(%d)", st->n_muid);
- n += snprintf(buf+n, buflen-n, " q ");
+ n += scnprintf(buf+n, buflen-n, " q ");
n += v9fs_printqid(buf+n, buflen-n, &st->qid);
- n += snprintf(buf+n, buflen-n, " m ");
+ n += scnprintf(buf+n, buflen-n, " m ");
n += v9fs_printperm(buf+n, buflen-n, st->mode);
- n += snprintf(buf+n, buflen-n, " at %d mt %d l %lld",
+ n += scnprintf(buf+n, buflen-n, " at %d mt %d l %lld",
st->atime, st->mtime, (long long int) st->length);
if (extended)
- n += snprintf(buf+n, buflen-n, " ext '%.*s'",
+ n += scnprintf(buf+n, buflen-n, " ext '%.*s'",
st->extension.len, st->extension.str);
return n;
@@ -127,15 +127,15 @@ v9fs_dumpdata(char *buf, int buflen, u8
i = n = 0;
while (i < datalen) {
- n += snprintf(buf + n, buflen - n, "%02x", data[i]);
+ n += scnprintf(buf + n, buflen - n, "%02x", data[i]);
if (i%4 == 3)
- n += snprintf(buf + n, buflen - n, " ");
+ n += scnprintf(buf + n, buflen - n, " ");
if (i%32 == 31)
- n += snprintf(buf + n, buflen - n, "\n");
+ n += scnprintf(buf + n, buflen - n, "\n");
i++;
}
- n += snprintf(buf + n, buflen - n, "\n");
+ n += scnprintf(buf + n, buflen - n, "\n");
return n;
}
@@ -152,7 +152,7 @@ v9fs_printfcall(char *buf, int buflen, s
int i, ret, type, tag;
if (!fc)
- return snprintf(buf, buflen, "<NULL>");
+ return scnprintf(buf, buflen, "<NULL>");
type = fc->id;
tag = fc->tag;
@@ -160,21 +160,21 @@ v9fs_printfcall(char *buf, int buflen, s
ret = 0;
switch (type) {
case TVERSION:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Tversion tag %u msize %u version '%.*s'", tag,
fc->params.tversion.msize, fc->params.tversion.version.len,
fc->params.tversion.version.str);
break;
case RVERSION:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Rversion tag %u msize %u version '%.*s'", tag,
fc->params.rversion.msize, fc->params.rversion.version.len,
fc->params.rversion.version.str);
break;
case TAUTH:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Tauth tag %u afid %d uname '%.*s' aname '%.*s'", tag,
fc->params.tauth.afid, fc->params.tauth.uname.len,
fc->params.tauth.uname.str, fc->params.tauth.aname.len,
@@ -182,12 +182,12 @@ v9fs_printfcall(char *buf, int buflen, s
break;
case RAUTH:
- ret += snprintf(buf+ret, buflen-ret, "Rauth tag %u qid ", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rauth tag %u qid ", tag);
v9fs_printqid(buf+ret, buflen-ret, &fc->params.rauth.qid);
break;
case TATTACH:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Tattach tag %u fid %d afid %d uname '%.*s' aname '%.*s'",
tag, fc->params.tattach.fid, fc->params.tattach.afid,
fc->params.tattach.uname.len, fc->params.tattach.uname.str,
@@ -195,41 +195,41 @@ v9fs_printfcall(char *buf, int buflen, s
break;
case RATTACH:
- ret += snprintf(buf+ret, buflen-ret, "Rattach tag %u qid ", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rattach tag %u qid ", tag);
v9fs_printqid(buf+ret, buflen-ret, &fc->params.rattach.qid);
break;
case RERROR:
- ret += snprintf(buf+ret, buflen-ret, "Rerror tag %u ename '%.*s'",
+ ret += scnprintf(buf+ret, buflen-ret, "Rerror tag %u ename '%.*s'",
tag, fc->params.rerror.error.len,
fc->params.rerror.error.str);
if (extended)
- ret += snprintf(buf+ret, buflen-ret, " ecode %d\n",
+ ret += scnprintf(buf+ret, buflen-ret, " ecode %d\n",
fc->params.rerror.errno);
break;
case TFLUSH:
- ret += snprintf(buf+ret, buflen-ret, "Tflush tag %u oldtag %u",
+ ret += scnprintf(buf+ret, buflen-ret, "Tflush tag %u oldtag %u",
tag, fc->params.tflush.oldtag);
break;
case RFLUSH:
- ret += snprintf(buf+ret, buflen-ret, "Rflush tag %u", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rflush tag %u", tag);
break;
case TWALK:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Twalk tag %u fid %d newfid %d nwname %d", tag,
fc->params.twalk.fid, fc->params.twalk.newfid,
fc->params.twalk.nwname);
for(i = 0; i < fc->params.twalk.nwname; i++)
- ret += snprintf(buf+ret, buflen-ret," '%.*s'",
+ ret += scnprintf(buf+ret, buflen-ret," '%.*s'",
fc->params.twalk.wnames[i].len,
fc->params.twalk.wnames[i].str);
break;
case RWALK:
- ret += snprintf(buf+ret, buflen-ret, "Rwalk tag %u nwqid %d",
+ ret += scnprintf(buf+ret, buflen-ret, "Rwalk tag %u nwqid %d",
tag, fc->params.rwalk.nwqid);
for(i = 0; i < fc->params.rwalk.nwqid; i++)
ret += v9fs_printqid(buf+ret, buflen-ret,
@@ -237,38 +237,38 @@ v9fs_printfcall(char *buf, int buflen, s
break;
case TOPEN:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Topen tag %u fid %d mode %d", tag,
fc->params.topen.fid, fc->params.topen.mode);
break;
case ROPEN:
- ret += snprintf(buf+ret, buflen-ret, "Ropen tag %u", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Ropen tag %u", tag);
ret += v9fs_printqid(buf+ret, buflen-ret, &fc->params.ropen.qid);
- ret += snprintf(buf+ret, buflen-ret," iounit %d",
+ ret += scnprintf(buf+ret, buflen-ret," iounit %d",
fc->params.ropen.iounit);
break;
case TCREATE:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Tcreate tag %u fid %d name '%.*s' perm ", tag,
fc->params.tcreate.fid, fc->params.tcreate.name.len,
fc->params.tcreate.name.str);
ret += v9fs_printperm(buf+ret, buflen-ret, fc->params.tcreate.perm);
- ret += snprintf(buf+ret, buflen-ret, " mode %d",
+ ret += scnprintf(buf+ret, buflen-ret, " mode %d",
fc->params.tcreate.mode);
break;
case RCREATE:
- ret += snprintf(buf+ret, buflen-ret, "Rcreate tag %u", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rcreate tag %u", tag);
ret += v9fs_printqid(buf+ret, buflen-ret, &fc->params.rcreate.qid);
- ret += snprintf(buf+ret, buflen-ret, " iounit %d",
+ ret += scnprintf(buf+ret, buflen-ret, " iounit %d",
fc->params.rcreate.iounit);
break;
case TREAD:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Tread tag %u fid %d offset %lld count %u", tag,
fc->params.tread.fid,
(long long int) fc->params.tread.offset,
@@ -276,7 +276,7 @@ v9fs_printfcall(char *buf, int buflen, s
break;
case RREAD:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Rread tag %u count %u data ", tag,
fc->params.rread.count);
ret += v9fs_printdata(buf+ret, buflen-ret, fc->params.rread.data,
@@ -284,7 +284,7 @@ v9fs_printfcall(char *buf, int buflen, s
break;
case TWRITE:
- ret += snprintf(buf+ret, buflen-ret,
+ ret += scnprintf(buf+ret, buflen-ret,
"Twrite tag %u fid %d offset %lld count %u data ",
tag, fc->params.twrite.fid,
(long long int) fc->params.twrite.offset,
@@ -294,52 +294,52 @@ v9fs_printfcall(char *buf, int buflen, s
break;
case RWRITE:
- ret += snprintf(buf+ret, buflen-ret, "Rwrite tag %u count %u",
+ ret += scnprintf(buf+ret, buflen-ret, "Rwrite tag %u count %u",
tag, fc->params.rwrite.count);
break;
case TCLUNK:
- ret += snprintf(buf+ret, buflen-ret, "Tclunk tag %u fid %d",
+ ret += scnprintf(buf+ret, buflen-ret, "Tclunk tag %u fid %d",
tag, fc->params.tclunk.fid);
break;
case RCLUNK:
- ret += snprintf(buf+ret, buflen-ret, "Rclunk tag %u", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rclunk tag %u", tag);
break;
case TREMOVE:
- ret += snprintf(buf+ret, buflen-ret, "Tremove tag %u fid %d",
+ ret += scnprintf(buf+ret, buflen-ret, "Tremove tag %u fid %d",
tag, fc->params.tremove.fid);
break;
case RREMOVE:
- ret += snprintf(buf+ret, buflen-ret, "Rremove tag %u", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rremove tag %u", tag);
break;
case TSTAT:
- ret += snprintf(buf+ret, buflen-ret, "Tstat tag %u fid %d",
+ ret += scnprintf(buf+ret, buflen-ret, "Tstat tag %u fid %d",
tag, fc->params.tstat.fid);
break;
case RSTAT:
- ret += snprintf(buf+ret, buflen-ret, "Rstat tag %u ", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rstat tag %u ", tag);
ret += v9fs_printstat(buf+ret, buflen-ret, &fc->params.rstat.stat,
extended);
break;
case TWSTAT:
- ret += snprintf(buf+ret, buflen-ret, "Twstat tag %u fid %d ",
+ ret += scnprintf(buf+ret, buflen-ret, "Twstat tag %u fid %d ",
tag, fc->params.twstat.fid);
ret += v9fs_printstat(buf+ret, buflen-ret, &fc->params.twstat.stat,
extended);
break;
case RWSTAT:
- ret += snprintf(buf+ret, buflen-ret, "Rwstat tag %u", tag);
+ ret += scnprintf(buf+ret, buflen-ret, "Rwstat tag %u", tag);
break;
default:
- ret += snprintf(buf+ret, buflen-ret, "unknown type %d", type);
+ ret += scnprintf(buf+ret, buflen-ret, "unknown type %d", type);
break;
}
^ permalink raw reply related
* Re: [patch] POLLRDHUP/EPOLLRDHUP handling for half-closed devices notifications ...
From: Davide Libenzi @ 2006-03-09 2:00 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Ulrich Drepper, Linus Torvalds, Andrew Morton, David Miller
In-Reply-To: <Pine.LNX.4.63.0603071247440.15576@localhost.localdomain>
On Tue, 7 Mar 2006, Davide Libenzi wrote:
>
> The attached patch against 2.6.16-rc5 implements the half-closed devices
> notifiation, by adding a new POLLRDHUP (and its alias EPOLLRDHUP) bit to the
> existing poll/select sets. Since the existing POLLHUP handling, that does not
> report correctly half-closed devices, was feared to be changed, this
> implementation leaves the current POLLHUP reporting unchanged and simply add
> a new bit that is set in the few places where it makes sense.
> The same thing was discussed and conceptually agreed quite some time ago:
>
> http://lkml.org/lkml/2003/7/12/116
>
> Since this new event bit is added to the existing Linux poll infrastruture,
> even the existing poll/select system calls will be able to use it. As far as
> the existing POLLHUP handling, the patch leaves it as is.
> The pollrdhup-2.6.16.rc5-0.10.diff defines the POLLRDHUP for all the existing
> archs and sets the bit in the six relevant files.
> The other attached diff is the simple change required to sys/epoll.h to add
> the EPOLLRDHUP definition.
I just added a stupid program to test POLLRDHUP delivery here:
http://www.xmailserver.org/pollrdhup-test.c
It tests poll(2), but since the delivery is same epoll(2) will work equally.
- Davide
^ permalink raw reply
* Re: apm for individual devices
From: Tehn Yit Chin @ 2006-03-09 1:57 UTC (permalink / raw)
To: Pavel Machek; +Cc: Li Qiang-E3422C, linux-pm
In-Reply-To: <20060308155153.GB3669@elf.ucw.cz>
Pavel Machek wrote:
> On Út 07-03-06 10:11:31, Li Qiang-E3422C wrote:
>
>>'0' indicates the device is on. Other values (1-3) indicate the device
>>is in a low power state.
>>You can see ACPI's spec.
>
>
> Actually, no. This is broken interface, please do not use it. 0 == on,
> 2 or 3 == off. But do not use it.
> Pavel
Are you saying not to the the power/state that is present in the
device's sysfs entry? What interface do you recommend that I use?
cheers,
tyc
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Paul Mackerras @ 2006-03-09 1:36 UTC (permalink / raw)
To: Jesse Barnes
Cc: Matthew Wilcox, Linus Torvalds, David Howells, Alan Cox, akpm,
mingo, linux-arch, linuxppc64-dev, linux-kernel
In-Reply-To: <200603081659.05786.jbarnes@virtuousgeek.org>
Jesse Barnes writes:
> It uses a per-node address space to reference the local bridge. The
> local bridge then waits until the remote bridge has acked the write
> before, then sets the outstanding write register to the appropriate
> value.
That sounds like mmiowb can only be used when preemption is disabled,
such as inside a spin-locked region - is that right?
Paul.
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Paul Mackerras @ 2006-03-09 1:57 UTC (permalink / raw)
To: Jesse Barnes
Cc: akpm, linux-arch, linux-kernel, Linus Torvalds, mingo, Alan Cox,
linuxppc64-dev
In-Reply-To: <200603081655.13672.jbarnes@virtuousgeek.org>
Jesse Barnes writes:
> On Wednesday, March 8, 2006 4:35 pm, Paul Mackerras wrote:
> > David Howells writes:
> > > On NUMA PowerPC, should mmiowb() be a SYNC or an EIEIO instruction
> > > then? Those do inter-component synchronisation.
> >
> > We actually have quite heavy synchronization in read*/write* on PPC,
> > and mmiowb can safely be a no-op. It would be nice to be able to have
> > lighter-weight synchronization, but I'm sure we would see lots of
> > subtle driver bugs cropping up if we did. write* do a full memory
> > barrier (sync) after the store, and read* explicitly wait for the data
> > to come back before.
> >
> > If you ask me, the need for mmiowb on some platforms merely shows that
> > those platforms' implementations of spinlocks and read*/write* are
> > buggy...
>
> Or maybe they just wanted to keep them fast. I don't know why you
> compromised so much in your implementation of read/write and
> lock/unlock, but given how expensive synchronization is, I'd think it
> would be better in the long run to make the barrier types explicit (or
> at least a subset of them) to maximize performance.
The PPC read*/write* and in*/out* aim to implement x86 semantics, in
order to minimize the number of subtle driver bugs that only show up
under heavy load.
I agree that in the long run making the barriers more explicit is a
good thing.
> The rules for using
> the barriers really aren't that bad... for mmiowb() you basically want
> to do it before an unlock in any critical section where you've done PIO
> writes.
Do you mean just PIO, or do you mean PIO or MMIO writes?
> Of course, that doesn't mean there isn't confusion about existing
> barriers. There was a long thread a few years ago (Jes worked it all
> out, iirc) regarding some subtle memory ordering bugs in the tty layer
> that ended up being due to ia64's very weak spin_unlock ordering
> guarantees (one way memory barrier only), but I think that's mainly an
> artifact of how ill defined the semantics of the various arch specific
> routines are in some cases.
Yes, there is a lot of confusion, unfortunately. There is also some
difficulty in defining things to be any different from what x86 does.
> That's why I suggested in an earlier thread that you enumerate all the
> memory ordering combinations on ppc and see if we can't define them all.
The main difficulty we strike on PPC is that cacheable accesses tend
to get ordered independently of noncacheable accesses. The only
instruction we have that orders cacheable accesses with respect to
noncacheable accesses is the sync instruction, which is a heavyweight
"synchronize everything" operation. It acts as a full memory barrier
for both cacheable and noncacheable loads and stores.
The other barriers we have are the lwsync instruction and the eieio
instruction. The lwsync instruction (light-weight sync) acts as a
memory barrier for cacheable loads and stores except that it allows a
following load to go before a preceding store.
The eieio instruction has two separate and independent effects. It
acts as a full barrier for accesses to noncacheable nonprefetchable
memory (i.e. MMIO or PIO registers), and it acts as a write barrier
for accesses to cacheable memory. It doesn't do any ordering between
cacheable and noncacheable accesses though.
There is also the isync (instruction synchronize) instruction, which
isn't explicitly a memory barrier. It prevents any following
instructions from executing until the outcome of any previous
conditional branches are known, and until it is known that no previous
instruction can generate an exception. Thus it can be used to create
a one-way barrier in spin_lock and read*.
> Then David can roll the implicit ones up into his document, or we can
> add the appropriate new operations to the kernel. Really getting
> barriers right shouldn't be much harder than getting DMA mapping right,
> from a driver writers POV (though people often get that wrong I guess).
Unfortunately, if you get the barriers wrong your driver will still
work most of the time on pretty much any machine, whereas if you get
the DMA mapping wrong your driver won't work at all on some machines.
Nevertheless, we should get these things defined properly and then try
to make sure drivers do the right things.
Paul.
^ permalink raw reply
* git-fmt-merge-msg cleanup
From: Linus Torvalds @ 2006-03-09 1:56 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Since I've started using the "merge.summary" flag in my repo, my merge
messages look nicer, but I dislike how I get notifications of merges
within merges.
So I'd suggest this trivial change..
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index dae383f..afe80e6 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -47,7 +47,7 @@ sub current_branch {
sub shortlog {
my ($tip) = @_;
my @result;
- foreach ( qx{git-log --topo-order --pretty=oneline $tip ^HEAD} ) {
+ foreach ( qx{git-log --no-merges --topo-order --pretty=oneline $tip ^HEAD} ) {
s/^[0-9a-f]{40}\s+//;
push @result, $_;
}
^ permalink raw reply related
* Re: apm for individual devices
From: Pavel Machek @ 2006-03-09 1:55 UTC (permalink / raw)
To: Tehn Yit Chin; +Cc: Li Qiang-E3422C, linux-pm
In-Reply-To: <440F8B96.5080802@greyinnovation.com>
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
On Čt 09-03-06 12:57:42, Tehn Yit Chin wrote:
> Pavel Machek wrote:
> >On Út 07-03-06 10:11:31, Li Qiang-E3422C wrote:
> >
> >>'0' indicates the device is on. Other values (1-3) indicate the device
> >>is in a low power state.
> >>You can see ACPI's spec.
> >
> >
> >Actually, no. This is broken interface, please do not use it. 0 == on,
> >2 or 3 == off. But do not use it.
>
> Are you saying not to the the power/state that is present in the
> device's sysfs entry? What interface do you recommend that I use?
Parse error. But I'm trying to say that <device>/power/state should
not be used -- it is ugly/broken. Replacement interface is being
prepared by Patrick, I believe, but is not yet in mainline. Feel free
to help Patrick :-).
Pavel
--
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: ACL on NFS, how make it work?
From: J. Bruce Fields @ 2006-03-09 1:49 UTC (permalink / raw)
To: Marco Gaiarin
Cc: Andreas Gruenbacher, Marius Aamodt Eriksen, Jeff Sedlak, nfs,
Gopal Santhanam
In-Reply-To: <20060308170425.GS8060@sv.lnf.it>
On Wed, Mar 08, 2006 at 06:04:25PM +0100, Marco Gaiarin wrote:
> Mandi! J. Bruce Fields
> In chel di` si favelave...
>
> > Actually I got one other NFS/XFS ACL complaint recently, and confirmed
> > that with current kernels I'm able to get and set ext3 ACL's over NFS,
> > and get and set XFS ACL's locally, but I can't use XFS ACL's over NFS.
> > Which is odd--on a first glance it looks like the two filesystems export
> > posix acl's through the same interface, etc. I haven't had the chance
> > to figure out what's going on yet....
>
> If i can do something to debug that, say me.
Could you try the following patch? Fixes the problem for me.
--b.
nfsd4: fix acl xattr length return
We should be using the length from the second vfs_getxattr, in case it
changed. (Note: there's still a small race here; we could end up returning
-ENOMEM if the length increased between the first and second call. Oh
well; I'm not sure it's worth spending a lot of effort to fix that.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
fs/nfsd/vfs.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 5320e5a..ac3a8e4 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -371,7 +371,6 @@ out_nfserr:
static ssize_t nfsd_getxattr(struct dentry *dentry, char *key, void **buf)
{
ssize_t buflen;
- int error;
buflen = vfs_getxattr(dentry, key, NULL, 0);
if (buflen <= 0)
@@ -381,10 +380,7 @@ static ssize_t nfsd_getxattr(struct dent
if (!*buf)
return -ENOMEM;
- error = vfs_getxattr(dentry, key, *buf, buflen);
- if (error < 0)
- return error;
- return buflen;
+ return vfs_getxattr(dentry, key, *buf, buflen);
}
#endif
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply related
* [KJ] my dream come true
From: Jane @ 2006-03-09 1:50 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
Hi there lovely,
I was searching the net few days ago. I am new to this thing.
and saw your profile. I decided to email you cause Ia found
you attractive. I might come down to your city in few waeeks.
Let me know if we can meet each other in person.
I am battractive girl. I am sure you won't regret it.
Reply to my personal email at be@nicerealmail.info
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: [PATCH] Define flush_wc, a way to flush write combining store buffers
From: Bryan O'Sullivan @ 2006-03-09 1:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: akpm, ak, paulus, bcrl, linux-kernel
In-Reply-To: <1141861230.11221.189.camel@localhost.localdomain>
On Thu, 2006-03-09 at 10:40 +1100, Benjamin Herrenschmidt wrote:
> What bothers me is that because of that exact same argument "it makes
> substantial difference for us", we end up with basically barriers
> tailored for architectures... that is as many kind of barriers as we
> have architectuers... like mmiowb :)
Unfortunately, it does express an untidy facet of reality, which is that
you really *do* want about as many different kinds of barrier as you
have kinds of distinct semantics, so that you have some hope of
expressing fairly portable concepts in a somewhat high-performance way.
I can see four problems at hand. You can choose the order of their
importance yourself :-)
1. Linux has a set of barriers that is too small to write
performant code in a portable manner.
2. The semantics of the existing barriers are not well understood.
3. People don't understand when barriers are appropriate in the
first place. Witness the current thread on this topic.
4. If you add more subtle barriers, they'll get misused (see #3)
and inevitably introduce bugs that are a nightmare to find.
Regarding #2, it's not obvious to lots of people why e.g. the
atomic_*_return kinds of routines need to have memory barrier semantics,
in some cases even after reading Documentation/atomic_ops.txt. So this
is a nasty education problem.
Regardless, in the case of the ipath driver, we squeeze every cycle out
of the hardware that we can, and this is our selling point. I'm fine
with a driver-specific hack in this case because it suits my immediate
needs, but it would be nice to have something portable and well-defined
to rely on.
<b
^ permalink raw reply
* Re: [PATCH] compat. ifconf: fix limits
From: David S. Miller @ 2006-03-09 1:41 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, linux-fsdevel, Alexandra.Kossovsky, ak, akpm, torvalds
In-Reply-To: <20060308174116.7cae35e1.rdunlap@xenotime.net>
From: "Randy.Dunlap" <rdunlap@xenotime.net>
Date: Wed, 8 Mar 2006 17:41:16 -0800
> On Wed, 08 Mar 2006 16:46:27 -0800 (PST) David S. Miller wrote:
>
> > Is this one relevant for -stable?
>
> Yes, IMO. Have to wait for it to be merged upstream, right?
I'll take care of everything, thanks Randy.
^ permalink raw reply
* [PATCH] xc_core.c - Fix order of evaluation issue in xc_domain_dumpcore
From: Ben Thomas @ 2006-03-09 1:41 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Fix order-of-evaluation issue in xc_domain_dumpcore. The intent is
to move blocks of memory 4096 pages at a time, and a buffer is
allocated for this. Unfortunately, the #define is without
parentheses and %/* are the same order and evaluated left to right.
Result: very big buffer being used 4 pages at a time. Luckily,
the fix is simple.
Signed-off-by: Ben Thomas (bthomas@virtualiron.com)
--
------------------------------------------------------------------------
Ben Thomas Virtual Iron Software
bthomas@virtualiron.com Tower 1, Floor 2
978-849-1214 900 Chelmsford Street
Lowell, MA 01851
[-- Attachment #2: xc_core.patch --]
[-- Type: text/x-patch, Size: 382 bytes --]
diff -r 96678f701d42 tools/libxc/xc_core.c
--- a/tools/libxc/xc_core.c Mon Mar 6 11:12:48 2006 -0500
+++ b/tools/libxc/xc_core.c Wed Mar 8 20:36:21 2006 -0500
@@ -6,7 +6,7 @@
#include <zlib.h>
/* number of pages to write at a time */
-#define DUMP_INCREMENT 4 * 1024
+#define DUMP_INCREMENT (4 * 1024)
#define round_pgup(_p) (((_p)+(PAGE_SIZE-1))&PAGE_MASK)
static int
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ 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.