flight 13677 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-amd 8 guest-stop fail REGR. vs. 13668
test-amd64-i386-qemuu-rhel6hvm-amd 8 guest-stop fail REGR. vs. 13668
test-amd64-i386-qemuu-rhel6hvm-intel 8 guest-stop fail REGR. vs. 13668
test-amd64-i386-rhel6hvm-intel 8 guest-stop fail REGR. vs. 13668
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13668
test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13668
test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13668
test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13668
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
xen 0a9a4549e6b9
baseline version:
xen 7d770de90b7f
------------------------------------------------------------
People who touched revisions under test:
Boris Ostrovsky <boris.ostrovsky@amd.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-qemuu-rhel6hvm-amd fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-i386-i386-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-i386-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 25844:0a9a4549e6b9
tag: tip
user: Boris Ostrovsky <boris.ostrovsky@amd.com>
date: Tue Sep 11 10:57:36 2012 +0200
powernow: Update P-state directly when _PSD''s CoordType is
DOMAIN_COORD_TYPE_HW_ALL
When _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL (i.e. shared_type
is
CPUFREQ_SHARED_TYPE_HW) which most often is the case on servers, there
is no reason to go into on_selected_cpus() code, we call call
transition_pstate() directly.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
changeset: 25843:51090fe1ab97
user: Jan Beulich <jbeulich@suse.com>
date: Tue Sep 11 10:00:06 2012 +0200
x86/HVM: assorted RTC emulation adjustments
- don''t look at RTC_PIE in rtc_timer_update(), and hence
don''t call the
function on REG_B writes at all
- only call alarm_timer_update() on REG_B writes when relevant bits
change
- only call check_update_timer() on REG_B writes when SET changes
- instead properly handle AF and PF when the guest is not also setting
AIE/PIE respectively (for UF this was already the case, only a
comment was slightly inaccurate)
- raise the RTC IRQ not only when UIE gets set while UF was already
set, but generalize this to cover AIE and PIE as well
- properly mask off bit 7 when retrieving the hour values in
alarm_timer_update(), and properly use RTC_HOURS_ALARM''s bit 7
when
converting from 12- to 24-hour value
- also handle the two other possible clock bases
- use RTC_* names in a couple of places where literal numbers were used
so far
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 25842:a1f73e989c24
user: Jan Beulich <jbeulich@suse.com>
date: Mon Sep 10 16:47:31 2012 +0200
x86/hvm: don''t give vector callback higher priority than NMI/MCE
Those two should always be delivered first imo.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
changeset: 25841:7d770de90b7f
user: Jan Beulich <JBeulich@suse.com>
date: Mon Sep 10 11:13:56 2012 +0100
docs: document "ucode=" hypervisor command line option
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)
>>> On 11.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 13677 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-rhel6hvm-amd 8 guest-stop fail REGR. vs. 13668 > test-amd64-i386-qemuu-rhel6hvm-amd 8 guest-stop fail REGR. vs. 13668 > test-amd64-i386-qemuu-rhel6hvm-intel 8 guest-stop fail REGR. vs. 13668 > test-amd64-i386-rhel6hvm-intel 8 guest-stop fail REGR. vs. 13668While it seems very likely that if any, one of the two changes of mine under test here have caused this, looking through the logs I can''t spot anything that would tell me what''s wrong. According to var-log-xen-qemu-dm-redhat.guest.osstest.log, the guest went down (but it didn''t even enter "dying" mode yet according to the diagnostic output in the serial log). Nor can I see any close relation between the behavior and the changsets under test... Any hints/help appreciated, Jan
On Wed, 2012-09-12 at 09:14 +0100, Jan Beulich wrote:> >>> On 11.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote: > > flight 13677 xen-unstable real [real] > > http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-i386-rhel6hvm-amd 8 guest-stop fail REGR. vs. 13668 > > test-amd64-i386-qemuu-rhel6hvm-amd 8 guest-stop fail REGR. vs. 13668 > > test-amd64-i386-qemuu-rhel6hvm-intel 8 guest-stop fail REGR. vs. 13668 > > test-amd64-i386-rhel6hvm-intel 8 guest-stop fail REGR. vs. 13668 > > While it seems very likely that if any, one of the two changes > of mine under test here have caused this, looking through the > logs I can''t spot anything that would tell me what''s wrong. > According to var-log-xen-qemu-dm-redhat.guest.osstest.log, > the guest went down (but it didn''t even enter "dying" mode > yet according to the diagnostic output in the serial log). Nor > can I see any close relation between the behavior and the > changsets under test...Looking at test-amd64-i386-rhel6hvm-amd in flight 13675 which succeeded the guest log ends: Halting system... type=1128 audit(1347348133.094:15071): user pid=1432 uid=0 auid=4294967295 ses=4294967295 msg=''init: exe="/sbin/reboot" hostname=? addr=? terminal=console res=success'' md: stopping all md devices. xenbus_dev_shutdown: device/vkbd/0: Initialising != Connected, skipping xenbus_dev_shutdown: device/vbd/5632: Closed != Connected, skipping ACPI: Preparing to enter system sleep state S5 Disabling non-boot CPUs ... Broke affinity for irq 4 Broke affinity for irq 12 SMP alternatives: switching to UP code Power down. shutdown requested in cpu_handle_ioreq Issued domain 2 poweroff Whereas in the failing case it cuts off after "stopping all md devices". 13675 failed another sequence, lets assume for unrelated reasons. The delta in the commits is just: 25844:0a9a4549e6b9 powernow: Update P-state directly when _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL 25843:51090fe1ab97 x86/HVM: assorted RTC emulation adjustments The first is a host level thing which I doubt would so consistently effect HVM guests (and anyway, Intel tests are also failing). Which pretty much leaves 25843:51090fe1ab97 or some weird heisenbug. Is it outside the realms of possibility that the guest has managed to limp along with the RTC being broken in some subtle way and only eventually trips up when we come to shut down? Looking back at 13675, is it possible that: 25842:a1f73e989c24 x86/hvm: don''t give vector callback higher priority than NMI/MCE is exposing a race in the guest or something? I very much doubt any NMI or MCE are being injected at all though. Ian.
>>> On 12.09.12 at 11:48, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2012-09-12 at 09:14 +0100, Jan Beulich wrote: >> >>> On 11.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote: >> > flight 13677 xen-unstable real [real] >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ >> > >> > Regressions :-( >> > >> > Tests which did not succeed and are blocking, >> > including tests which could not be run: >> > test-amd64-i386-rhel6hvm-amd 8 guest-stop fail REGR. vs. > 13668 >> > test-amd64-i386-qemuu-rhel6hvm-amd 8 guest-stop fail REGR. vs. > 13668 >> > test-amd64-i386-qemuu-rhel6hvm-intel 8 guest-stop fail REGR. vs. > 13668 >> > test-amd64-i386-rhel6hvm-intel 8 guest-stop fail REGR. vs. > 13668 >> >> While it seems very likely that if any, one of the two changes >> of mine under test here have caused this, looking through the >> logs I can''t spot anything that would tell me what''s wrong. >> According to var-log-xen-qemu-dm-redhat.guest.osstest.log, >> the guest went down (but it didn''t even enter "dying" mode >> yet according to the diagnostic output in the serial log). Nor >> can I see any close relation between the behavior and the >> changsets under test... > > Looking at test-amd64-i386-rhel6hvm-amd in flight 13675 which succeeded > the guest log ends: > Halting system... > type=1128 audit(1347348133.094:15071): user pid=1432 uid=0 > auid=4294967295 ses=4294967295 msg=''init: exe="/sbin/reboot" hostname=? > addr=? terminal=console res=success'' > md: stopping all md devices. > xenbus_dev_shutdown: device/vkbd/0: Initialising != Connected, > skipping > xenbus_dev_shutdown: device/vbd/5632: Closed != Connected, skipping > ACPI: Preparing to enter system sleep state S5 > Disabling non-boot CPUs ... > Broke affinity for irq 4 > Broke affinity for irq 12 > SMP alternatives: switching to UP code > Power down. > shutdown requested in cpu_handle_ioreq > Issued domain 2 poweroff > > Whereas in the failing case it cuts off after "stopping all md devices". > > 13675 failed another sequence, lets assume for unrelated reasons. The > delta in the commits is just: > > 25844:0a9a4549e6b9 powernow: Update P-state directly when _PSD''s CoordType > is DOMAIN_COORD_TYPE_HW_ALL > 25843:51090fe1ab97 x86/HVM: assorted RTC emulation adjustments > > The first is a host level thing which I doubt would so consistently > effect HVM guests (and anyway, Intel tests are also failing). Which > pretty much leaves 25843:51090fe1ab97 or some weird heisenbug. > > Is it outside the realms of possibility that the guest has managed to > limp along with the RTC being broken in some subtle way and only > eventually trips up when we come to shut down?That''s certainly not impossible, but afaik Linux doesn''t play with the RTC unless told to by user space (whereas Windows, as we know from the reporter of the problem that triggered putting together these changes, does on its own at least under certain circumstances, yet the Windows tests all go through fine). Certainly this is the most likely candidate for having broken something, and hence would be the prime candidate for reverting. But before doing so, I''d want to see at least another run''s results.> Looking back at 13675, is it possible that: > > 25842:a1f73e989c24 x86/hvm: don''t give vector callback higher priority than > NMI/MCE > > is exposing a race in the guest or something? I very much doubt any NMI > or MCE are being injected at all though.So do I. Jan
On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote:> > Is it outside the realms of possibility that the guest has managed to > > limp along with the RTC being broken in some subtle way and only > > eventually trips up when we come to shut down? > > That''s certainly not impossible, but afaik Linux doesn''t play with > the RTC unless told to by user spaceI did wonder about an /etc/init.d/hwclock type thing, but I think that would have run much earlier than this point.> (whereas Windows, as we > know from the reporter of the problem that triggered putting > together these changes, does on its own at least under certain > circumstances, yet the Windows tests all go through fine). > > Certainly this is the most likely candidate for having broken > something, and hence would be the prime candidate for reverting. > But before doing so, I''d want to see at least another run''s results.Ack. I''m installing a RHEL6.1 HVM guest anyway, since it''s handy to have one in my pocket. The bisector also ought to make short work of this number of changesets. Ian.
On Wed, 2012-09-12 at 11:12 +0100, Ian Campbell wrote:> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote: > > > Is it outside the realms of possibility that the guest has managed to > > > limp along with the RTC being broken in some subtle way and only > > > eventually trips up when we come to shut down? > > > > That''s certainly not impossible, but afaik Linux doesn''t play with > > the RTC unless told to by user space > > I did wonder about an /etc/init.d/hwclock type thing, but I think that > would have run much earlier than this point. > > > (whereas Windows, as we > > know from the reporter of the problem that triggered putting > > together these changes, does on its own at least under certain > > circumstances, yet the Windows tests all go through fine). > > > > Certainly this is the most likely candidate for having broken > > something, and hence would be the prime candidate for reverting. > > But before doing so, I''d want to see at least another run''s results. > > Ack. I''m installing a RHEL6.1 HVM guest anyway, since it''s handy to have > one in my pocket.25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames calculations" for both => hangs: Syncing hardware clock to system time [ OK ] Turning off swap: [ OK ] Unmounting file systems: [ OK ] init: Re-executing /sbin/init <silence> Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation adjustments" on top of 35fa... => works again. Ian.
>>> On 12.09.12 at 12:35, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2012-09-12 at 11:12 +0100, Ian Campbell wrote: >> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote: >> > > Is it outside the realms of possibility that the guest has managed to >> > > limp along with the RTC being broken in some subtle way and only >> > > eventually trips up when we come to shut down? >> > >> > That''s certainly not impossible, but afaik Linux doesn''t play with >> > the RTC unless told to by user space >> >> I did wonder about an /etc/init.d/hwclock type thing, but I think that >> would have run much earlier than this point. >> >> > (whereas Windows, as we >> > know from the reporter of the problem that triggered putting >> > together these changes, does on its own at least under certain >> > circumstances, yet the Windows tests all go through fine). >> > >> > Certainly this is the most likely candidate for having broken >> > something, and hence would be the prime candidate for reverting. >> > But before doing so, I''d want to see at least another run''s results. >> >> Ack. I''m installing a RHEL6.1 HVM guest anyway, since it''s handy to have >> one in my pocket. > > 25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames > calculations" for both => hangs: > Syncing hardware clock to system time [ OK ] > Turning off swap: [ OK ] > Unmounting file systems: [ OK ] > init: Re-executing /sbin/init > <silence> > > Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation > adjustments" on top of 35fa... => works again.In that case I''ll just revert it in -unstable too. No idea what''s wrong with it, though. Jan
On Wed, 2012-09-12 at 12:15 +0100, Jan Beulich wrote:> >>> On 12.09.12 at 12:35, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Wed, 2012-09-12 at 11:12 +0100, Ian Campbell wrote: > >> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote: > >> > > Is it outside the realms of possibility that the guest has managed to > >> > > limp along with the RTC being broken in some subtle way and only > >> > > eventually trips up when we come to shut down? > >> > > >> > That''s certainly not impossible, but afaik Linux doesn''t play with > >> > the RTC unless told to by user space > >> > >> I did wonder about an /etc/init.d/hwclock type thing, but I think that > >> would have run much earlier than this point. > >> > >> > (whereas Windows, as we > >> > know from the reporter of the problem that triggered putting > >> > together these changes, does on its own at least under certain > >> > circumstances, yet the Windows tests all go through fine). > >> > > >> > Certainly this is the most likely candidate for having broken > >> > something, and hence would be the prime candidate for reverting. > >> > But before doing so, I''d want to see at least another run''s results. > >> > >> Ack. I''m installing a RHEL6.1 HVM guest anyway, since it''s handy to have > >> one in my pocket. > > > > 25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames > > calculations" for both => hangs: > > Syncing hardware clock to system time [ OK ] > > Turning off swap: [ OK ] > > Unmounting file systems: [ OK ] > > init: Re-executing /sbin/init > > <silence> > > > > Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation > > adjustments" on top of 35fa... => works again. > > In that case I''ll just revert it in -unstable too. No idea what''s wrong > with it, though.I see you''ve done the revert. In case it is helpful the list of blocked tasks (from SysRQ-t) is below. Not sure if/how ps2 might relate to the rtc... BTW, I couldn''t repro with a Debian Squeeze kernel... Ian. SysRq : Show Blocked State task PC stack pid father init D c0477b83 0 1 0 0x00000000 ee470ab0 00000086 ee485c70 c0477b83 000f4240 00000000 00000000 004dd658 00000000 ef12a200 00000033 00000001 00000033 c0ae2120 c0ae2120 ee470d58 c0ae2120 c0addb54 c0ae2120 ee470d58 ec8ce000 00000000 ee494000 00000004 Call Trace: [<c0477b83>] ? hrtimer_forward+0x163/0x1b0 [<c0463430>] ? run_timer_softirq+0x20/0x2c0 [<c04b6494>] ? __rcu_process_callbacks+0x44/0x2d0 [<c04b6755>] ? rcu_process_callbacks+0x35/0x40 [<c0459c35>] ? __do_softirq+0xb5/0x1b0 [<c08231e5>] ? schedule_timeout+0x195/0x250 [<c05f1245>] ? idr_remove+0x125/0x1b0 [<c055c0b7>] ? fsnotify_add_notify_event+0xf7/0x240 [<c0822f49>] ? wait_for_common+0xe9/0x150 [<c044bf70>] ? default_wake_function+0x0/0x10 [<c04712e0>] ? synchronize_sched+0x40/0x50 [<c04712f0>] ? wakeme_after_rcu+0x0/0x10 [<c04795ac>] ? __synchronize_srcu+0x3c/0xc0 [<c04712a0>] ? synchronize_sched+0x0/0x50 [<c055c46d>] ? fsnotify_put_group+0x4d/0x80 [<c055e7a2>] ? inotify_release+0x12/0x20 [<c052987c>] ? __fput+0xdc/0x1f0 [<c05256b7>] ? filp_close+0x47/0x80 [<c0525757>] ? sys_close+0x67/0xb0 [<c052de9c>] ? setup_new_exec+0x17c/0x240 [<c0569e93>] ? load_elf_binary+0x323/0x1690 [<c05f627b>] ? strrchr+0xb/0x20 [<c04fdb4b>] ? follow_page+0x33b/0x3f0 [<c0502781>] ? __get_user_pages+0xf1/0x430 [<c0473f20>] ? autoremove_wake_function+0x0/0x40 [<c052d35c>] ? acct_arg_size+0x4c/0x70 [<c052e5e8>] ? get_arg_page+0x88/0xb0 [<c0569b70>] ? load_elf_binary+0x0/0x1690 [<c052ecf0>] ? search_binary_handler+0xf0/0x310 [<c052fc3e>] ? do_execve+0x1ee/0x2b0 [<c05fa122>] ? strncpy_from_user+0x32/0x60 [<c0408215>] ? sys_execve+0x25/0x60 [<c0409adf>] ? sysenter_do_call+0x12/0x28 halt D ec151da8 0 1218 1 0x00000080 eec50030 00000082 00000002 ec151da8 c1a03b54 00000000 00000000 c04b2105 0000000c eedee580 00000033 352530de 00000033 c0ae2120 c0ae2120 eec502d8 c0ae2120 c0addb54 c0ae2120 eec502d8 c1a03b54 00000001 fffec5c4 eec50030 Call Trace: [<c04b2105>] ? handle_IRQ_event+0x45/0x140 [<c0459e95>] ? irq_exit+0x35/0x70 [<c040b1c0>] ? do_IRQ+0x50/0xc0 [<c040a030>] ? common_interrupt+0x30/0x38 [<c082317c>] ? schedule_timeout+0x12c/0x250 [<c0824839>] ? _spin_unlock_irqrestore+0x9/0x10 [<c0462de0>] ? process_timeout+0x0/0x10 [<c0726317>] ? __ps2_command+0x247/0x3a0 [<c0473f20>] ? autoremove_wake_function+0x0/0x40 [<c07264e4>] ? ps2_command+0x24/0x40 [<c07233b8>] ? serio_cleanup+0x28/0x40 [<c06ae900>] ? device_shutdown+0x40/0x150 [<c0479bf7>] ? blocking_notifier_call_chain+0x17/0x20 [<c046d86d>] ? kernel_power_off+0xd/0x40 [<c046db38>] ? sys_reboot+0x108/0x210 [<c07702d6>] ? sys_recvfrom+0x146/0x160 [<c0775d28>] ? skb_dequeue+0x48/0x70 [<c07764a4>] ? skb_queue_purge+0x14/0x20 [<c055cbcc>] ? fsnotify_clear_marks_by_inode+0x1c/0xb0 [<c053ca06>] ? dput+0x76/0x110 [<c0529904>] ? __fput+0x164/0x1f0 [<c0541cc5>] ? mntput_no_expire+0x15/0xd0 [<c04adecc>] ? audit_syscall_entry+0x21c/0x240 [<c04adbe6>] ? audit_syscall_exit+0x216/0x240 [<c0409adf>] ? sysenter_do_call+0x12/0x28