This message contains a list of some regressions introduced between 2.6.27 and
2.6.28, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.27
and 2.6.28, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-01-20 144 30 27
2009-01-11 139 33 30
2008-12-21 120 19 17
2008-12-13 111 14 13
2008-12-07 106 20 17
2008-12-04 106 29 21
2008-11-22 93 25 15
2008-11-16 89 32 18
2008-11-09 73 40 27
2008-11-02 55 41 29
2008-10-25 26 25 20
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12500
Subject : r8169: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Submitter : Justin Piszcz <[email protected]>
Date : 2009-01-13 21:19 (7 days old)
References : http://marc.info/?l=linux-kernel&m=123188160811322&w=4
Handled-By : Francois Romieu <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12483
Subject : Reference to inexistent struct dmi_device_id breaks the build
Submitter : Jean Delvare <[email protected]>
Date : 2009-01-19 01:29 (1 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12465
Subject : KVM guests stalling on 2.6.28 (bisected)
Submitter : Kevin Shanahan <[email protected]>
Date : 2009-01-17 03:37 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12426
Subject : TMDC Joystick no longer works in kernel 2.6.28
Submitter : Andrew S. Johnson <[email protected]>
Date : 2009-01-10 21:53 (10 days old)
References : http://marc.info/?l=linux-kernel&m=123162486415366&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12421
Subject : GPF on 2.6.28 & 2.6.28-rc9-git3 e1000e / e1000 issues
Submitter : Doug Bazarnic <[email protected]>
Date : 2009-01-09 21:26 (11 days old)
References : http://marc.info/?l=linux-kernel&m=123153653120204&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12411
Subject : 2.6.28: BUG in r8169
Submitter : Andrey Vul <[email protected]>
Date : 2008-12-31 18:37 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123074869611409&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12409
Subject : NULL pointer dereference at get_stats()
Submitter : Tetsuo Handa <[email protected]>
Date : 2008-12-30 12:53 (21 days old)
References : http://marc.info/?l=linux-kernel&m=123064167008695&w=4
Handled-By : Frederik Deweerdt <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12408
Subject : Funny problem with 2.6.28: Kernel stalls
Submitter : Michael Roth <[email protected]>
Date : 2008-12-25 15:14 (26 days old)
References : http://marc.info/?l=linux-kernel&m=123021931714282&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12407
Subject : Kernel 2.6.28 regression: Hang after hibernate
Submitter : Frank Groeneveld <[email protected]>
Date : 2008-12-28 20:34 (23 days old)
References : http://marc.info/?l=linux-kernel&m=123049651906081&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12405
Subject : oops in __bounce_end_io_read under kvm
Submitter : Christoph Hellwig <[email protected]>
Date : 2008-12-26 17:36 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123031303400676&w=4
Handled-By : Jens Axboe <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12404
Subject : Oops in 2.6.28-rc9 and -rc8 -- mtrr issues / e1000e
Submitter : Kernel <[email protected]>
Date : 2008-12-22 9:37 (29 days old)
References : http://marc.info/?l=linux-kernel&m=122993873320150&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12403
Subject : TTY problem on linux-2.6.28-rc7
Submitter : sasa sasa <[email protected]>
Date : 2008-12-22 4:23 (29 days old)
References : http://marc.info/?l=linux-kernel&m=122991914600390&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12401
Subject : 2.6.28 regression: xbacklight broken on ThinkPad X61s
Submitter : Tino Keitel <[email protected]>
Date : 2009-01-05 8:39 (15 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=22c13f9d8179f4c9caecfcb60a95214562b9addc
References : http://marc.info/?l=linux-kernel&m=123114479110314&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12395
Subject : 2.6.28-rc9: oprofile regression
Submitter : Tim Blechmann <[email protected]>
Date : 2008-12-21 14:23 (30 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b99170288421c79f0c2efa8b33e26e65f4bb7fb8
References : http://marc.info/?l=linux-kernel&m=122986946614791&w=4
Handled-By : Andi Kleen <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12393
Subject : debugging in dosemu causes lots of 'scheduling while atomic'
Submitter : Michal Suchanek <[email protected]>
Date : 2009-01-09 07:28 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12391
Subject : Processor does not go below C2 state until usb.autosuspend is enabled
Submitter : Gergely Imreh <[email protected]>
Date : 2009-01-09 02:35 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12337
Subject : ~100 extra wakeups reported by powertop
Submitter : Alberto Gonzalez <[email protected]>
Date : 2008-12-31 12:25 (20 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12265
Subject : FPU emulation broken in 2.6.28-rc8 ?
Submitter : Rogier Wolff <[email protected]>
Date : 2008-12-17 8:56 (34 days old)
References : http://marc.info/?l=linux-kernel&m=122950463030747&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12264
Subject : i915: switching from kwin in opengl mode to a VT then back to x11, x11 freezes
Submitter : Caleb Cushing <[email protected]>
Date : 2008-12-16 11:40 (35 days old)
References : http://marc.info/?l=linux-kernel&m=122942777030666&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject : Sata soft reset filling log
Submitter : Justin Madru <[email protected]>
Date : 2008-12-13 2:07 (38 days old)
References : http://marc.info/?l=linux-kernel&m=122913412608533&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12224
Subject : journal activity on inactive partition causes inactive harddrive spinup
Submitter : C Sights <[email protected]>
Date : 2008-12-14 11:39 (37 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c87591b719737b4e91eb1a9fa8fd55a4ff1886d6
Handled-By : Eric Sandeen <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12209
Subject : oldish top core dumps (in its meminfo() function)
Submitter : Andreas Mohr <[email protected]>
Date : 2008-12-12 18:49 (39 days old)
References : http://marc.info/?l=linux-kernel&m=122910784006472&w=4
http://marc.info/?l=linux-kernel&m=122907511319288&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12208
Subject : uml is very slow on 2.6.28 host
Submitter : Miklos Szeredi <[email protected]>
Date : 2008-12-12 9:35 (39 days old)
References : http://marc.info/?l=linux-kernel&m=122907463518593&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12160
Subject : networking oops after resume from s2ram (2.6.28-rc6)
Submitter : Marcin Slusarz <[email protected]>
Date : 2008-11-28 21:15 (53 days old)
References : http://marc.info/?l=linux-kernel&m=122790701615723&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12159
Subject : 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver
Submitter : Miles Lane <[email protected]>
Date : 2008-11-27 20:33 (54 days old)
References : http://marc.info/?l=linux-kernel&m=122781805620212&w=4
Handled-By : Takashi Iwai <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12061
Subject : snd_hda_intel: power_save: sound cracks on powerdown
Submitter : Jens Weibler <[email protected]>
Date : 2008-11-18 12:07 (63 days old)
Handled-By : Takashi Iwai <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11849
Subject : default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Submitter : Kumar Gala <[email protected]>
Date : 2008-10-24 12:45 (88 days old)
References : http://marc.info/?l=linux-kernel&m=122485245924125&w=4
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12406
Subject : 2.6.28 thinks that my PS/2 mouse is a touchpad
Submitter : Alexander E. Patrakov <[email protected]>
Date : 2008-12-27 9:06 (24 days old)
References : http://marc.info/?l=linux-kernel&m=123036893817280&w=4
Handled-By : Arjan Opmeer <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=123092147703236&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12396
Subject : hwinfo problem since 2.6.28
Submitter : Beschorner Daniel <[email protected]>
Date : 2009-01-06 8:53 (14 days old)
References : http://marc.info/?l=linux-kernel&m=123123277800835&w=4
Handled-By : Suresh Siddha <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=123154005127497&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12260
Subject : Regression due to commit 2b80848e3818fb1c (p54usb: support LM87 firmwares)
Submitter : Larry Finger <[email protected]>
Date : 2008-12-20 10:45 (31 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b80848e3818fb1c8ccddc105b065a86c68afa9d
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=12260
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.27 and 2.6.28, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=11808
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11849
Subject : default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
Submitter : Kumar Gala <[email protected]>
Date : 2008-10-24 12:45 (88 days old)
References : http://marc.info/?l=linux-kernel&m=122485245924125&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12159
Subject : 2.6.28-rc6-git1 -- No sound produced from Intel HDA ALSA driver
Submitter : Miles Lane <[email protected]>
Date : 2008-11-27 20:33 (54 days old)
References : http://marc.info/?l=linux-kernel&m=122781805620212&w=4
Handled-By : Takashi Iwai <[email protected]>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12208
Subject : uml is very slow on 2.6.28 host
Submitter : Miklos Szeredi <[email protected]>
Date : 2008-12-12 9:35 (39 days old)
References : http://marc.info/?l=linux-kernel&m=122907463518593&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12160
Subject : networking oops after resume from s2ram (2.6.28-rc6)
Submitter : Marcin Slusarz <[email protected]>
Date : 2008-11-28 21:15 (53 days old)
References : http://marc.info/?l=linux-kernel&m=122790701615723&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12061
Subject : snd_hda_intel: power_save: sound cracks on powerdown
Submitter : Jens Weibler <[email protected]>
Date : 2008-11-18 12:07 (63 days old)
Handled-By : Takashi Iwai <[email protected]>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12209
Subject : oldish top core dumps (in its meminfo() function)
Submitter : Andreas Mohr <[email protected]>
Date : 2008-12-12 18:49 (39 days old)
References : http://marc.info/?l=linux-kernel&m=122910784006472&w=4
http://marc.info/?l=linux-kernel&m=122907511319288&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12396
Subject : hwinfo problem since 2.6.28
Submitter : Beschorner Daniel <[email protected]>
Date : 2009-01-06 8:53 (14 days old)
References : http://marc.info/?l=linux-kernel&m=123123277800835&w=4
Handled-By : Suresh Siddha <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=123154005127497&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12395
Subject : 2.6.28-rc9: oprofile regression
Submitter : Tim Blechmann <[email protected]>
Date : 2008-12-21 14:23 (30 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b99170288421c79f0c2efa8b33e26e65f4bb7fb8
References : http://marc.info/?l=linux-kernel&m=122986946614791&w=4
Handled-By : Andi Kleen <[email protected]>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12260
Subject : Regression due to commit 2b80848e3818fb1c (p54usb: support LM87 firmwares)
Submitter : Larry Finger <[email protected]>
Date : 2008-12-20 10:45 (31 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b80848e3818fb1c8ccddc105b065a86c68afa9d
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=12260
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12265
Subject : FPU emulation broken in 2.6.28-rc8 ?
Submitter : Rogier Wolff <[email protected]>
Date : 2008-12-17 8:56 (34 days old)
References : http://marc.info/?l=linux-kernel&m=122950463030747&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12393
Subject : debugging in dosemu causes lots of 'scheduling while atomic'
Submitter : Michal Suchanek <[email protected]>
Date : 2009-01-09 07:28 (11 days old)
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12224
Subject : journal activity on inactive partition causes inactive harddrive spinup
Submitter : C Sights <[email protected]>
Date : 2008-12-14 11:39 (37 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c87591b719737b4e91eb1a9fa8fd55a4ff1886d6
Handled-By : Eric Sandeen <[email protected]>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12264
Subject : i915: switching from kwin in opengl mode to a VT then back to x11, x11 freezes
Submitter : Caleb Cushing <[email protected]>
Date : 2008-12-16 11:40 (35 days old)
References : http://marc.info/?l=linux-kernel&m=122942777030666&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12263
Subject : Sata soft reset filling log
Submitter : Justin Madru <[email protected]>
Date : 2008-12-13 2:07 (38 days old)
References : http://marc.info/?l=linux-kernel&m=122913412608533&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12391
Subject : Processor does not go below C2 state until usb.autosuspend is enabled
Submitter : Gergely Imreh <[email protected]>
Date : 2009-01-09 02:35 (11 days old)
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12337
Subject : ~100 extra wakeups reported by powertop
Submitter : Alberto Gonzalez <[email protected]>
Date : 2008-12-31 12:25 (20 days old)
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12401
Subject : 2.6.28 regression: xbacklight broken on ThinkPad X61s
Submitter : Tino Keitel <[email protected]>
Date : 2009-01-05 8:39 (15 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=22c13f9d8179f4c9caecfcb60a95214562b9addc
References : http://marc.info/?l=linux-kernel&m=123114479110314&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12403
Subject : TTY problem on linux-2.6.28-rc7
Submitter : sasa sasa <[email protected]>
Date : 2008-12-22 4:23 (29 days old)
References : http://marc.info/?l=linux-kernel&m=122991914600390&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12404
Subject : Oops in 2.6.28-rc9 and -rc8 -- mtrr issues / e1000e
Submitter : Kernel <[email protected]>
Date : 2008-12-22 9:37 (29 days old)
References : http://marc.info/?l=linux-kernel&m=122993873320150&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12407
Subject : Kernel 2.6.28 regression: Hang after hibernate
Submitter : Frank Groeneveld <[email protected]>
Date : 2008-12-28 20:34 (23 days old)
References : http://marc.info/?l=linux-kernel&m=123049651906081&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12406
Subject : 2.6.28 thinks that my PS/2 mouse is a touchpad
Submitter : Alexander E. Patrakov <[email protected]>
Date : 2008-12-27 9:06 (24 days old)
References : http://marc.info/?l=linux-kernel&m=123036893817280&w=4
Handled-By : Arjan Opmeer <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=123092147703236&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12408
Subject : Funny problem with 2.6.28: Kernel stalls
Submitter : Michael Roth <[email protected]>
Date : 2008-12-25 15:14 (26 days old)
References : http://marc.info/?l=linux-kernel&m=123021931714282&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12411
Subject : 2.6.28: BUG in r8169
Submitter : Andrey Vul <[email protected]>
Date : 2008-12-31 18:37 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123074869611409&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12405
Subject : oops in __bounce_end_io_read under kvm
Submitter : Christoph Hellwig <[email protected]>
Date : 2008-12-26 17:36 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123031303400676&w=4
Handled-By : Jens Axboe <[email protected]>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12409
Subject : NULL pointer dereference at get_stats()
Submitter : Tetsuo Handa <[email protected]>
Date : 2008-12-30 12:53 (21 days old)
References : http://marc.info/?l=linux-kernel&m=123064167008695&w=4
Handled-By : Frederik Deweerdt <[email protected]>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12426
Subject : TMDC Joystick no longer works in kernel 2.6.28
Submitter : Andrew S. Johnson <[email protected]>
Date : 2009-01-10 21:53 (10 days old)
References : http://marc.info/?l=linux-kernel&m=123162486415366&w=4
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12483
Subject : Reference to inexistent struct dmi_device_id breaks the build
Submitter : Jean Delvare <[email protected]>
Date : 2009-01-19 01:29 (1 days old)
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12465
Subject : KVM guests stalling on 2.6.28 (bisected)
Submitter : Kevin Shanahan <[email protected]>
Date : 2009-01-17 03:37 (3 days old)
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.27 and 2.6.28.
The following bug entry is on the current list of known regressions
introduced between 2.6.27 and 2.6.28. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12500
Subject : r8169: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
Submitter : Justin Piszcz <[email protected]>
Date : 2009-01-13 21:19 (7 days old)
References : http://marc.info/?l=linux-kernel&m=123188160811322&w=4
Handled-By : Francois Romieu <[email protected]>
On Mon, 2009-01-19 at 22:45 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12465
> Subject : KVM guests stalling on 2.6.28 (bisected)
> Submitter : Kevin Shanahan <[email protected]>
> Date : 2009-01-17 03:37 (3 days old)
Yes, please keep this on the list.
Cheers,
Kevin.
On Mon, Jan 19, 2009 at 10:45:42PM +0100, Rafael J. Wysocki wrote:
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
Well. Dmitry hasn't replied yet to my suggestion how to fix this as
presented in the Patch entry. Without help from him as the Linux input
subsystem maintainer there is not a lot I can do.
This means the regression is still present in the current 2.6.29 git tree.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12406
> Subject : 2.6.28 thinks that my PS/2 mouse is a touchpad
> Submitter : Alexander E. Patrakov <[email protected]>
> Date : 2008-12-27 9:06 (24 days old)
> References : http://marc.info/?l=linux-kernel&m=123036893817280&w=4
> Handled-By : Arjan Opmeer <[email protected]>
> Patch : http://marc.info/?l=linux-kernel&m=123092147703236&w=4
Arjan
On Mon, Jan 19, 2009 at 22:45:41 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12401
> Subject : 2.6.28 regression: xbacklight broken on ThinkPad X61s
> Submitter : Tino Keitel <[email protected]>
> Date : 2009-01-05 8:39 (15 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=22c13f9d8179f4c9caecfcb60a95214562b9addc
> References : http://marc.info/?l=linux-kernel&m=123114479110314&w=4
I tried 2.6.28.1 and xbacklight works fine, so this regression is
solved.
Regards,
Tino
On Mon, 19 Jan 2009 22:45:44 +0100 (CET), Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12483
> Subject : Reference to inexistent struct dmi_device_id breaks the build
> Submitter : Jean Delvare <[email protected]>
> Date : 2009-01-19 01:29 (1 days old)
>
Yes, this regression is still present.
--
Jean Delvare
> On Mon, Jan 19, 2009 at 10:45:42PM +0100, Rafael J. Wysocki wrote:> > The following bug entry is on the current list of known regressions> > introduced between 2.6.27 and 2.6.28. Please verify if it still should> > be listed and let me know (either way).>> Well. Dmitry hasn't replied yet to my suggestion how to fix this as> presented in the Patch entry. Without help from him as the Linux input> subsystem maintainer there is not a lot I can do.>> This means the regression is still present in the current 2.6.29 git tree.
Sorry, must have missed that. I think it's gonna be a bit chatty ifuser happens to have Logitech++ device attached, however I think ifwe complement it with the patch below I think it should work OK.
-- Dmitry
Input: psmouse - move Elantech detection towards end of the list
Elantech'd detection routine misfires on Logitech's devices so let'smove it down to prevent false positives.
Signed-off-by: Dmitry Torokhov <[email protected]>---
drivers/input/mouse/psmouse-base.c | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.cindex f8f86de..e4106ba 100644--- a/drivers/input/mouse/psmouse-base.c+++ b/drivers/input/mouse/psmouse-base.c@@ -651,19 +651,6 @@ static int psmouse_extensions(struct psmouse *psmouse, max_proto = PSMOUSE_IMEX; } -/*- * Try Elantech touchpad.- */- if (max_proto > PSMOUSE_IMEX &&- elantech_detect(psmouse, set_properties) == 0) {- if (!set_properties || elantech_init(psmouse) == 0)- return PSMOUSE_ELANTECH;-/*- * Init failed, try basic relative protocols- */- max_proto = PSMOUSE_IMEX;- }- if (max_proto > PSMOUSE_IMEX) { if (genius_detect(psmouse, set_properties) == 0) return PSMOUSE_GENPS;@@ -679,6 +666,19 @@ static int psmouse_extensions(struct psmouse *psmouse, } /*+ * Try Elantech touchpad.+ */+ if (max_proto > PSMOUSE_IMEX &&+ elantech_detect(psmouse, set_properties) == 0) {+ if (!set_properties || elantech_init(psmouse) == 0)+ return PSMOUSE_ELANTECH;+/*+ * Init failed, try basic relative protocols+ */+ max_proto = PSMOUSE_IMEX;+ }++/* * Reset to defaults in case the device got confused by extended * protocol probes. Note that we follow up with full reset because * some mice put themselves to sleep when they see PSMOUSE_RESET_DIS. ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
--- On Mon, 1/19/09, Rafael J. Wysocki wrote:
>
> The following bug entry is on the current list of known
> regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it
> still should
> be listed and let me know (either way).
>
>
> Bug-Entry :
> http://bugzilla.kernel.org/show_bug.cgi?id=12337
> Subject : ~100 extra wakeups reported by powertop
> Submitter : Alberto Gonzalez <[email protected]>
> Date : 2008-12-31 12:25 (20 days old)
Yes, the problem is still present in 2.6.28.1
Thanks,
Alberto.
2009/1/19 Rafael J. Wysocki <[email protected]>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12393
> Subject : debugging in dosemu causes lots of 'scheduling while atomic'
> Submitter : Michal Suchanek <[email protected]>
> Date : 2009-01-09 07:28 (11 days old)
>
>
>
See here:
http://marc.info/?l=linux-kernel&m=123188630319434&w=2
Until the patch is applied the problem will be present. It is probably
still present in 2.6.29-rc1.
Thanks
Michal
* Kevin Shanahan <[email protected]> wrote:
> On Mon, 2009-01-19 at 22:45 +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28. Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12465
> > Subject : KVM guests stalling on 2.6.28 (bisected)
> > Submitter : Kevin Shanahan <[email protected]>
> > Date : 2009-01-17 03:37 (3 days old)
>
> Yes, please keep this on the list.
This only seems to occur under KVM, right? I.e. you tested it with -no-kvm
and the problem went away, correct?
This suggests some sort of KVM-specific problem. Scheduler latencies in
the seconds that occur under normal load situations are noticed and
reported quickly - and there are no such open regressions currently.
Avi, can you reproduce these latencies? A possibly theory would be some
sort of guest wakeup problem/race triggered by a shift in
preemption/scheduling patterns. Or something related to preempt-notifiers
(which KVM is using). A genuine scheduler bug is in the cards too, but the
KVM-only angle of this bug gives it a low probability.
Ingo
Ingo Molnar wrote:
> * Kevin Shanahan <[email protected]> wrote:
>
>
>> On Mon, 2009-01-19 at 22:45 +0100, Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of regressions introduced between 2.6.27 and 2.6.28.
>>>
>>> The following bug entry is on the current list of known regressions
>>> introduced between 2.6.27 and 2.6.28. Please verify if it still should
>>> be listed and let me know (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12465
>>> Subject : KVM guests stalling on 2.6.28 (bisected)
>>> Submitter : Kevin Shanahan <[email protected]>
>>> Date : 2009-01-17 03:37 (3 days old)
>>>
>> Yes, please keep this on the list.
>>
>
> This only seems to occur under KVM, right? I.e. you tested it with -no-kvm
> and the problem went away, correct?
>
> This suggests some sort of KVM-specific problem. Scheduler latencies in
> the seconds that occur under normal load situations are noticed and
> reported quickly - and there are no such open regressions currently.
>
>
Not necessarily. -no-kvm runs with only one thread, compared to kvm
that runs with 1 + nr_cpus threads.
> Avi, can you reproduce these latencies?
No.
> A possibly theory would be some
> sort of guest wakeup problem/race triggered by a shift in
> preemption/scheduling patterns. Or something related to preempt-notifiers
> (which KVM is using). A genuine scheduler bug is in the cards too, but the
> KVM-only angle of this bug gives it a low probability.
>
Can we trace task wakeups somehow? (latency between wakeup and actually
running).
--
error compiling committee.c: too many arguments to function
On Tue, 2009-01-20 at 12:35 +0100, Ingo Molnar wrote:
> * Kevin Shanahan <[email protected]> wrote:
>
> > On Mon, 2009-01-19 at 22:45 +0100, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.27 and 2.6.28.
> > >
> > > The following bug entry is on the current list of known regressions
> > > introduced between 2.6.27 and 2.6.28. Please verify if it still should
> > > be listed and let me know (either way).
> > >
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12465
> > > Subject : KVM guests stalling on 2.6.28 (bisected)
> > > Submitter : Kevin Shanahan <[email protected]>
> > > Date : 2009-01-17 03:37 (3 days old)
> >
> > Yes, please keep this on the list.
>
> This only seems to occur under KVM, right? I.e. you tested it with -no-kvm
> and the problem went away, correct?
Well, the I couldn't make the test conditions identical, but it the
problem didn't occur with the test I was able to do:
http://marc.info/?l=linux-kernel&m=123228728416498&w=2
> This suggests some sort of KVM-specific problem. Scheduler latencies in
> the seconds that occur under normal load situations are noticed and
> reported quickly - and there are no such open regressions currently.
It at least suggests a problem with interaction between the scheduler
and kvm, otherwise reverting that scheduler patch wouldn't have made the
regression go away.
Regards,
Kevin.
* Kevin Shanahan <[email protected]> wrote:
> > This suggests some sort of KVM-specific problem. Scheduler latencies
> > in the seconds that occur under normal load situations are noticed and
> > reported quickly - and there are no such open regressions currently.
>
> It at least suggests a problem with interaction between the scheduler
> and kvm, otherwise reverting that scheduler patch wouldn't have made the
> regression go away.
the scheduler affects almost everything, so almost by definition a
scheduler change can tickle a race or other timing bug in just about any
code - and reverting that change in the scheduler can make the bug go
away. But yes, it could also be a genuine scheduler bug - that is always a
possibility.
Could you please run a cfs-debug-info.sh session on a CONFIG_SCHED_DEBUG=y
and CONFIG_SCHEDSTATS=y kernel, while you are experiencing those
latencies:
http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
and post that (relatively large) somewhere, or send it as a reply after
bzip2 -9 compressing it? It will include a lot of information about the
delays your tasks are experiencing.
Ingo
On Mon, Jan 19, 2009 at 10:45:38PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12224
> Subject : journal activity on inactive partition causes inactive harddrive spinup
> Submitter : C Sights <[email protected]>
> Date : 2008-12-14 11:39 (37 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c87591b719737b4e91eb1a9fa8fd55a4ff1886d6
> Handled-By : Eric Sandeen <[email protected]>
>
Yes, this should still be listed. We have a proposed patch that
should fix this, but it still needs to be finalized and tested.
- Ted
Kevin Shanahan wrote:
> On Tue, 2009-01-20 at 12:35 +0100, Ingo Molnar wrote:
>
>> * Kevin Shanahan <[email protected]> wrote:
>>
>>
>>> On Mon, 2009-01-19 at 22:45 +0100, Rafael J. Wysocki wrote:
>>>
>>>> This message has been generated automatically as a part of a report
>>>> of regressions introduced between 2.6.27 and 2.6.28.
>>>>
>>>> The following bug entry is on the current list of known regressions
>>>> introduced between 2.6.27 and 2.6.28. Please verify if it still should
>>>> be listed and let me know (either way).
>>>>
>>>>
>>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12465
>>>> Subject : KVM guests stalling on 2.6.28 (bisected)
>>>> Submitter : Kevin Shanahan <[email protected]>
>>>> Date : 2009-01-17 03:37 (3 days old)
>>>>
>>> Yes, please keep this on the list.
>>>
>> This only seems to occur under KVM, right? I.e. you tested it with -no-kvm
>> and the problem went away, correct?
>>
>
> Well, the I couldn't make the test conditions identical, but it the
> problem didn't occur with the test I was able to do:
>
> http://marc.info/?l=linux-kernel&m=123228728416498&w=2
>
>
Can you also try with -no-kvm-irqchip?
You will need to comment out the lines
/* ISA IRQs map to GSI 1-1 except for IRQ0 which maps
* to GSI 2. GSI maps to ioapic 1-1. This is not
* the cleanest way of doing it but it should work. */
if (vector == 0)
vector = 2;
in qemu/hw/apic.c (should also fix -no-kvm smp). This will change kvm
wakeups to use signals rather than the in-kernel code, which may be buggy.
--
error compiling committee.c: too many arguments to function
* Ingo Molnar <[email protected]> wrote:
>
> * Kevin Shanahan <[email protected]> wrote:
>
> > > This suggests some sort of KVM-specific problem. Scheduler latencies
> > > in the seconds that occur under normal load situations are noticed and
> > > reported quickly - and there are no such open regressions currently.
> >
> > It at least suggests a problem with interaction between the scheduler
> > and kvm, otherwise reverting that scheduler patch wouldn't have made the
> > regression go away.
>
> the scheduler affects almost everything, so almost by definition a
> scheduler change can tickle a race or other timing bug in just about any
> code - and reverting that change in the scheduler can make the bug go
> away. But yes, it could also be a genuine scheduler bug - that is always a
> possibility.
>
> Could you please run a cfs-debug-info.sh session on a CONFIG_SCHED_DEBUG=y
> and CONFIG_SCHEDSTATS=y kernel, while you are experiencing those
> latencies:
>
> http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
>
> and post that (relatively large) somewhere, or send it as a reply after
> bzip2 -9 compressing it? It will include a lot of information about the
> delays your tasks are experiencing.
Another test would be to build the scheduler latency tracer into your
kernel:
CONFIG_SCHED_TRACER=y
And enable it via:
echo wakeup > /debug/tracing/current_tracer
and you should be seeing the worst-case scheduling latency traces in
/debug/tracing/trace, and the largest observed latency will be in
/debug/tracing/tracing_max_latency [in microseconds].
You can reset the max-latency (and thus restart tracing) via:
echo 0 > /debug/tracing/tracing_max_latency
Latencies up to 100 microseconds are ok. If you see 10 seconds delays
there (values of 10,000,000 or more) then it's probably a scheduler bug.
Please reproduce the latency under KVM and send us the trace. The trace
file will be a lot more verbose and a lot more verbose if you also enable
the function tracer (FUNCTION_TRACER, DYNAMIC_FTRACE and
FUNCTION_GRAPH_TRACER).
Ingo
On Tue, 2009-01-20 at 13:56 +0100, Ingo Molnar wrote:
> * Kevin Shanahan <[email protected]> wrote:
> > > This suggests some sort of KVM-specific problem. Scheduler latencies
> > > in the seconds that occur under normal load situations are noticed and
> > > reported quickly - and there are no such open regressions currently.
> >
> > It at least suggests a problem with interaction between the scheduler
> > and kvm, otherwise reverting that scheduler patch wouldn't have made the
> > regression go away.
>
> the scheduler affects almost everything, so almost by definition a
> scheduler change can tickle a race or other timing bug in just about any
> code - and reverting that change in the scheduler can make the bug go
> away. But yes, it could also be a genuine scheduler bug - that is always a
> possibility.
Okay, I understand.
> Could you please run a cfs-debug-info.sh session on a CONFIG_SCHED_DEBUG=y
> and CONFIG_SCHEDSTATS=y kernel, while you are experiencing those
> latencies:
>
> http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
>
> and post that (relatively large) somewhere, or send it as a reply after
> bzip2 -9 compressing it? It will include a lot of information about the
> delays your tasks are experiencing.
Running it while the problem is occuring will be tricky, as it only
lasts for a few seconds at a time. Is it going to be useful at all to
just see those statistics if the system is running normally?
I might need to modify the script a little. Am I right that everything
above "gathering statistics..." is pretty much static information?
I could run top, vmstat and cat /proc/sched_debug in a loop until the
problem occurs and then trim it. Something like:
while true; do
date >> $FILE
echo "-- top: --" >> $FILE
top -H -c -b -d 1 -n 0.5 >> $FILE 2>/dev/null
echo "-- vmstat: --" >> $FILE
vmstat >> $FILE 2>/dev/null
echo "-- sched_debug #$i: --" >> $FILE
cat /proc/sched_debug >> $FILE 2>/dev/null
done
That should take a snapshot every half second or so.
Regards,
Kevin.
P.S. Please keep [email protected] out of the CC list (it won't
route properly anyway). I don't know how it got added - the only
place it would have appeared was in the "revert" commit message
when I was testing 2.6.28 with the commit I bisected down to
removed.
* Kevin Shanahan <[email protected]> wrote:
> On Tue, 2009-01-20 at 13:56 +0100, Ingo Molnar wrote:
> > * Kevin Shanahan <[email protected]> wrote:
> > > > This suggests some sort of KVM-specific problem. Scheduler latencies
> > > > in the seconds that occur under normal load situations are noticed and
> > > > reported quickly - and there are no such open regressions currently.
> > >
> > > It at least suggests a problem with interaction between the scheduler
> > > and kvm, otherwise reverting that scheduler patch wouldn't have made the
> > > regression go away.
> >
> > the scheduler affects almost everything, so almost by definition a
> > scheduler change can tickle a race or other timing bug in just about any
> > code - and reverting that change in the scheduler can make the bug go
> > away. But yes, it could also be a genuine scheduler bug - that is always a
> > possibility.
>
> Okay, I understand.
>
> > Could you please run a cfs-debug-info.sh session on a CONFIG_SCHED_DEBUG=y
> > and CONFIG_SCHEDSTATS=y kernel, while you are experiencing those
> > latencies:
> >
> > http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
> >
> > and post that (relatively large) somewhere, or send it as a reply after
> > bzip2 -9 compressing it? It will include a lot of information about the
> > delays your tasks are experiencing.
>
> Running it while the problem is occuring will be tricky, as it only
> lasts for a few seconds at a time. Is it going to be useful at all to
> just see those statistics if the system is running normally?
>
> I might need to modify the script a little. Am I right that everything
> above "gathering statistics..." is pretty much static information?
Correct.
> I could run top, vmstat and cat /proc/sched_debug in a loop until the
> problem occurs and then trim it. Something like:
>
> while true; do
> date >> $FILE
> echo "-- top: --" >> $FILE
> top -H -c -b -d 1 -n 0.5 >> $FILE 2>/dev/null
> echo "-- vmstat: --" >> $FILE
> vmstat >> $FILE 2>/dev/null
> echo "-- sched_debug #$i: --" >> $FILE
> cat /proc/sched_debug >> $FILE 2>/dev/null
> done
>
> That should take a snapshot every half second or so.
Yeah, that would be lovely. You dont even have to trim it much - just give
us a timestamp to look at for the delay incident. You might also want to
start the kvm session while the script is already running - that way we'll
get fresh statistics and see the whole thing.
Ingo
2009/1/20 Kevin Shanahan <[email protected]>:
> On Tue, 2009-01-20 at 13:56 +0100, Ingo Molnar wrote:
>> * Kevin Shanahan <[email protected]> wrote:
>> > > This suggests some sort of KVM-specific problem. Scheduler latencies
>> > > in the seconds that occur under normal load situations are noticed and
>> > > reported quickly - and there are no such open regressions currently.
>> >
>> > It at least suggests a problem with interaction between the scheduler
>> > and kvm, otherwise reverting that scheduler patch wouldn't have made the
>> > regression go away.
>>
>> the scheduler affects almost everything, so almost by definition a
>> scheduler change can tickle a race or other timing bug in just about any
>> code - and reverting that change in the scheduler can make the bug go
>> away. But yes, it could also be a genuine scheduler bug - that is always a
>> possibility.
>
> Okay, I understand.
>
>> Could you please run a cfs-debug-info.sh session on a CONFIG_SCHED_DEBUG=y
>> and CONFIG_SCHEDSTATS=y kernel, while you are experiencing those
>> latencies:
>>
>> http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
>>
>> and post that (relatively large) somewhere, or send it as a reply after
>> bzip2 -9 compressing it? It will include a lot of information about the
>> delays your tasks are experiencing.
>
> Running it while the problem is occuring will be tricky, as it only
> lasts for a few seconds at a time. Is it going to be useful at all to
> just see those statistics if the system is running normally?
>
> I might need to modify the script a little. Am I right that everything
> above "gathering statistics..." is pretty much static information?
>
> I could run top, vmstat and cat /proc/sched_debug in a loop until the
> problem occurs and then trim it. Something like:
>
> while true; do
> date >> $FILE
> echo "-- top: --" >> $FILE
> top -H -c -b -d 1 -n 0.5 >> $FILE 2>/dev/null
> echo "-- vmstat: --" >> $FILE
> vmstat >> $FILE 2>/dev/null
> echo "-- sched_debug #$i: --" >> $FILE
> cat /proc/sched_debug >> $FILE 2>/dev/null
> done
>
> That should take a snapshot every half second or so.
>
> Regards,
> Kevin.
>
> P.S. Please keep [email protected] out of the CC list (it won't
> route properly anyway). I don't know how it got added - the only
> place it would have appeared was in the "revert" commit message
> when I was testing 2.6.28 with the commit I bisected down to
> removed.
>
One other thing you can do is enabling CONFIG_FUNCTION_GRAPH_TRACER,
as Ingo suggested, and
trace the schedule() function.
This way you will see the time spent in (almost) each functions called
from schedule() and perhaps find
where is the contention (if it comes from the scheduler).
How to use it?
echo schedule > /debugfs/tracing/set_graph_function
echo function_graph > /debugfs/tracing/current_tracer
cat /debugfs/tracing/trace
Or even through a pipe:
cat /debugfs/tracing/trace_pipe > ~/func_graph.log
To end the tracing: echo nop > /debugfs/tracing/current_tracer
Or just make a pause: echo 0 > /debugfs/tracing/tracing_enabled
On Tue, 20 Jan 2009, Ingo Molnar wrote:
> Another test would be to build the scheduler latency tracer into your
> kernel:
>
> CONFIG_SCHED_TRACER=y
>
> And enable it via:
>
> echo wakeup > /debug/tracing/current_tracer
>
> and you should be seeing the worst-case scheduling latency traces in
> /debug/tracing/trace, and the largest observed latency will be in
> /debug/tracing/tracing_max_latency [in microseconds].
Note, the wakeup latency only tests realtime threads, since other threads
can have other issues for wakeup. I could change the wakeup tracer as
wakeup_rt, and make a new "wakeup" that tests all threads, but it may
be difficult to get something accurate.
-- Steve
* Steven Rostedt <[email protected]> wrote:
> On Tue, 20 Jan 2009, Ingo Molnar wrote:
> > Another test would be to build the scheduler latency tracer into your
> > kernel:
> >
> > CONFIG_SCHED_TRACER=y
> >
> > And enable it via:
> >
> > echo wakeup > /debug/tracing/current_tracer
> >
> > and you should be seeing the worst-case scheduling latency traces in
> > /debug/tracing/trace, and the largest observed latency will be in
> > /debug/tracing/tracing_max_latency [in microseconds].
>
> Note, the wakeup latency only tests realtime threads, since other
> threads can have other issues for wakeup. I could change the wakeup
> tracer as wakeup_rt, and make a new "wakeup" that tests all threads, but
> it may be difficult to get something accurate.
hm, that's a significant regression then. The latency tracer used to
measure the highest-prio task in the system - be that RT or non-rt.
Ingo
On Tue, 2009-01-20 at 15:25 +0100, Ingo Molnar wrote:
> > I could run top, vmstat and cat /proc/sched_debug in a loop until the
> > problem occurs and then trim it. Something like:
> >
> > while true; do
> > date >> $FILE
> > echo "-- top: --" >> $FILE
> > top -H -c -b -d 1 -n 0.5 >> $FILE 2>/dev/null
> > echo "-- vmstat: --" >> $FILE
> > vmstat >> $FILE 2>/dev/null
> > echo "-- sched_debug #$i: --" >> $FILE
> > cat /proc/sched_debug >> $FILE 2>/dev/null
> > done
> >
> > That should take a snapshot every half second or so.
>
> Yeah, that would be lovely. You dont even have to trim it much - just give
> us a timestamp to look at for the delay incident. You might also want to
> start the kvm session while the script is already running - that way we'll
> get fresh statistics and see the whole thing.
I've uploaded the debug info here:
http://disenchant.net/tmp/bug-12465/
Some interesting sections should be around these times:
01:36:04 -> 01:36:27
01:37:30 -> 01:37:42
01:37:52 -> 01:37:56
01:39:37 -> 01:39:40
01:40:01 -> 01:40:14
The output from ping is there too so you can see how the delays usually
show up (e.g. in clusters). The large debug file runs from before I
launched the VMs, right through the ping test. The trimmed file just
cuts out everything before I started ping.
Regards,
Kevin.
* Kevin Shanahan <[email protected]> wrote:
> I've uploaded the debug info here:
> http://disenchant.net/tmp/bug-12465/
one interesting number to watch for is the KVM thread's wait_max in
/proc/*/sched. The largest one seems to be 11 milliseconds:
se.wait_max : 3.175034
se.wait_max : 4.029938
se.wait_max : 4.217674
se.wait_max : 4.957836
se.wait_max : 10.339471
se.wait_max : 11.603943
which would be about right given your latency settings:
/proc/sys/kernel/sched_latency_ns:
60000000
[ 60 msecs ]
but ... i dont specifically see the kvm threads there. Are they not in
/proc/*? Maybe it's in threads and it needs to be accessed via
/proc/*/task/*/sched, as via:
$ grep -h wait_max /proc/*/task/*/sched | sort -t: -n -k 2 | tail -10
se.wait_max : 77.858092
se.wait_max : 78.778409
se.wait_max : 79.379026
se.wait_max : 85.930963
se.wait_max : 87.671842
se.wait_max : 88.008602
se.wait_max : 95.095744
se.wait_max : 157.882573
se.wait_max : 268.714775
se.wait_max : 393.085252
so the worst-case latency
Btw., there's a few weird stats in your logs:
se.wait_max : -284.864857
se.wait_max : -284.843431
se.wait_max : -284.820204
se.wait_max : -284.345294
se.wait_max : -284.298462
se.wait_max : -284.018644
se.wait_max : -284.018070
se.wait_max : -188.022417
se.wait_max : -188.021659
se.wait_max : -92.030204
se.wait_max : -92.027877
that field is not supposed to be negative. Mike, Peter, any ideas?
Ingo
On Tue, 2009-01-20 at 17:06 +0100, Ingo Molnar wrote:
> se.wait_max : -92.027877
>
> that field is not supposed to be negative. Mike, Peter, any ideas?
Possibly unrelated, but whilst I was poking at try_to_wake_up yesterday,
I thought I spotted a site where we fail to update rq clock.
Since we just moved the task to a new cpu (and thus rq) we need to
update_rq_clock() again.
diff --git a/kernel/sched.c b/kernel/sched.c
index d7ae5f4..6cd5e52 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2398,6 +2398,7 @@ static int try_to_wake_up(struct task_struct *p, unsigned int state, int sync)
if (cpu != orig_cpu) {
set_task_cpu(p, cpu);
task_rq_unlock(rq, &flags);
+ update_rq_clock(rq);
/* might preempt at this point */
rq = task_rq_lock(p, &flags);
old_state = p->state;
Steven Rostedt wrote:
> Note, the wakeup latency only tests realtime threads, since other threads
> can have other issues for wakeup. I could change the wakeup tracer as
> wakeup_rt, and make a new "wakeup" that tests all threads, but it may
> be difficult to get something accurate.
>
Kevin, can you retest with kvm at realtime priority?
--
error compiling committee.c: too many arguments to function
On Tue, 20 Jan 2009, Ingo Molnar wrote:
>
> * Steven Rostedt <[email protected]> wrote:
>
> > On Tue, 20 Jan 2009, Ingo Molnar wrote:
> > > Another test would be to build the scheduler latency tracer into your
> > > kernel:
> > >
> > > CONFIG_SCHED_TRACER=y
> > >
> > > And enable it via:
> > >
> > > echo wakeup > /debug/tracing/current_tracer
> > >
> > > and you should be seeing the worst-case scheduling latency traces in
> > > /debug/tracing/trace, and the largest observed latency will be in
> > > /debug/tracing/tracing_max_latency [in microseconds].
> >
> > Note, the wakeup latency only tests realtime threads, since other
> > threads can have other issues for wakeup. I could change the wakeup
> > tracer as wakeup_rt, and make a new "wakeup" that tests all threads, but
> > it may be difficult to get something accurate.
>
> hm, that's a significant regression then. The latency tracer used to
> measure the highest-prio task in the system - be that RT or non-rt.
Well, it is a regression from what was in -rt yes. But not from what ever
was in mainline.
But I needed to change this to detect the problem that we
solved with push and pull of rt tasks. The wake up of a non-rt tasks
always took longer than an -rt task, and by tracing all tasks, I never got
the wake up latency of an rt task.
As I mentioned earlier, I can make a wakeup-rt to do the rt tracing, and
make wakeup do all tasks.
-- Steve
On Tue, 2009-01-20 at 15:04 +0200, Avi Kivity wrote:
> Kevin Shanahan wrote:
> > On Tue, 2009-01-20 at 12:35 +0100, Ingo Molnar wrote:
> >> This only seems to occur under KVM, right? I.e. you tested it with -no-kvm
> >> and the problem went away, correct?
> >>
> >
> > Well, the I couldn't make the test conditions identical, but it the
> > problem didn't occur with the test I was able to do:
> >
> > http://marc.info/?l=linux-kernel&m=123228728416498&w=2
> >
> >
>
> Can you also try with -no-kvm-irqchip?
>
> You will need to comment out the lines
>
> /* ISA IRQs map to GSI 1-1 except for IRQ0 which maps
> * to GSI 2. GSI maps to ioapic 1-1. This is not
> * the cleanest way of doing it but it should work. */
>
> if (vector == 0)
> vector = 2;
>
> in qemu/hw/apic.c (should also fix -no-kvm smp). This will change kvm
> wakeups to use signals rather than the in-kernel code, which may be buggy.
Okay, I commented out those lines and compiled a new kvm-82 userspace
and kernel modules. Using those on a vanilla 2.6.28 kernel, with all
guests run with -no-kvm-irqchip added.
As before a number of the XP guests wanted to chug away at 100% CPU
usage for a long time. Three of the guests clocked up ~40 minutes CPU
time before I decided to just shut them down. Perhaps coincidentally,
these three guests are the only ones with Office 2003 installed on them.
That could be the difference between those guests and the other XP
guests, but that's probably not important for now.
The two Linux SMP guests booted okay this time, though they seem to only
use one CPU on the host (I guess kvm is not multi-threaded in this
mode?). "hermes-old", the guest I am pinging in all my tests, had a lot
of trouble running the apache2 setup - it was so slow it was difficult
to load a complete page from our RT system. The kvm process for this
guest was taking up 100% cpu on the host constantly and all sorts of
wierd stuff could be seen by watching top in the guest:
top - 03:44:17 up 43 min, 1 user, load average: 3.95, 1.55, 0.80
Tasks: 101 total, 4 running, 97 sleeping, 0 stopped, 0 zombie
Cpu(s): 79.7%us, 10.4%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 9.9%si,
0.0%st
Mem: 2075428k total, 391128k used, 1684300k free, 13044k buffers
Swap: 3502160k total, 0k used, 3502160k free, 118488k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2956 postgres 20 0 19704 11m 10m S 1658 0.6 2:55.99 postmaster
2934 www-data 20 0 60392 40m 5132 R 31 2.0 0:17.28 apache2
2958 postgres 20 0 19700 11m 9.8m R 28 0.6 0:20.41 postmaster
2940 www-data 20 0 58652 38m 5016 S 27 1.9 0:04.87 apache2
2937 www-data 20 0 60124 40m 5112 S 18 2.0 0:11.00 apache2
2959 postgres 20 0 19132 5424 4132 S 10 0.3 0:01.50 postmaster
2072 postgres 20 0 8064 1416 548 S 7 0.1 0:23.71 postmaster
2960 postgres 20 0 19132 5368 4060 R 6 0.3 0:01.55 postmaster
2071 postgres 20 0 8560 1972 488 S 5 0.1 0:08.33 postmaster
Running the ping test with without apache2 running in the guest:
--- hermes-old.wumi.org.au ping statistics ---
900 packets transmitted, 900 received, 0% packet loss, time 902740ms
rtt min/avg/max/mdev = 0.568/3.745/272.558/16.990 ms
And with apache2 running:
--- hermes-old.wumi.org.au ping statistics ---
900 packets transmitted, 900 received, 0% packet loss, time 902758ms
rtt min/avg/max/mdev = 0.625/25.634/852.739/76.586 ms
In both cases it's quite variable, but the max latency is still not as
bad as when running with the irq chip enabled.
Anyway, the test is again not ideal, but I hope we're proving something.
That's all I can do for tonight - should be ready for more again
tomorrow night.
Regards,
Kevin.
http://bugs.freedesktop.org/show_bug.cgi?id=18879
fixed here and verified fixed in gentoo. Not sure if the kernel
patches have made it into vanilla-sources. If they have +libdrm fix,
it works.
On 1/19/09, Rafael J. Wysocki <[email protected]> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12264
> Subject : i915: switching from kwin in opengl mode to a VT then back to x11, x11 freezes
> Submitter : Caleb Cushing <[email protected]>
> Date : 2008-12-16 11:40 (35 days old)
> References : http://marc.info/?l=linux-kernel&m=122942777030666&w=4
>
>
>
--
Caleb Cushing
http://xenoterracide.blogspot.com
* Steven Rostedt <[email protected]> wrote:
> > hm, that's a significant regression then. The latency tracer used to
> > measure the highest-prio task in the system - be that RT or non-rt.
>
> Well, it is a regression from what was in -rt yes. But not from what
> ever was in mainline.
indeed, it is not a regression, it is worse: it makes the mainline version
utterly useless in 99% of the cases ... This really needs to be fixed.
Ingo
* Kevin Shanahan <[email protected]> wrote:
> Running the ping test with without apache2 running in the guest:
>
> --- hermes-old.wumi.org.au ping statistics ---
> 900 packets transmitted, 900 received, 0% packet loss, time 902740ms
> rtt min/avg/max/mdev = 0.568/3.745/272.558/16.990 ms
>
> And with apache2 running:
>
> --- hermes-old.wumi.org.au ping statistics ---
> 900 packets transmitted, 900 received, 0% packet loss, time 902758ms
> rtt min/avg/max/mdev = 0.625/25.634/852.739/76.586 ms
>
> In both cases it's quite variable, but the max latency is still not as
> bad as when running with the irq chip enabled.
So the worst-case ping latency is more than 10 times lower?
I'd say this points in the direction of some sort of KVM-internal
wakeup/signalling latency that happens if KVM does not deschedule. For
example it could be a bug like this: if a guest image runs at 100% CPU
time for a long time, IRQ injections might not propagate up until the
preemption callbacks run. (but i'm just speculating here)
Ingo
All p54usb devices need a explicit termination packet, in oder to finish the pending transfer properly.
Else, the firmware could freeze, or simply drop the frame.
Signed-off-by: Christian Lamparter <[email protected]>
Cc: stable <[email protected]>
---
Attached is the patch is for the stable series only.
Bugzilla reference: http://bugzilla.kernel.org/show_bug.cgi?id=12260
(wireless-testing needs a different one)
Rafael, I hope we can close this bug. Greg?
---
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 75d749b..be40369 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -214,6 +214,8 @@ static void p54u_tx_3887(struct ieee80211_hw *dev, struct p54_control_hdr *data,
usb_fill_bulk_urb(data_urb, priv->udev,
usb_sndbulkpipe(priv->udev, P54U_PIPE_DATA), data, len,
free_on_tx ? p54u_tx_free_cb : p54u_tx_cb, dev);
+ addr_urb->transfer_flags |= URB_ZERO_PACKET;
+ data_urb->transfer_flags |= URB_ZERO_PACKET;
usb_submit_urb(addr_urb, GFP_ATOMIC);
usb_submit_urb(data_urb, GFP_ATOMIC);
@@ -251,6 +253,7 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev,
usb_sndbulkpipe(priv->udev, P54U_PIPE_DATA), hdr,
len + sizeof(*hdr), free_on_tx ? p54u_tx_free_cb : p54u_tx_cb,
dev);
+ data_urb->transfer_flags |= URB_ZERO_PACKET;
usb_submit_urb(data_urb, GFP_ATOMIC);
}
@@ -293,11 +296,13 @@ static void p54u_tx_net2280(struct ieee80211_hw *dev, struct p54_control_hdr *da
usb_fill_bulk_urb(int_urb, priv->udev,
usb_sndbulkpipe(priv->udev, P54U_PIPE_DEV), reg, sizeof(*reg),
p54u_tx_free_cb, dev);
+ int_urb->transfer_flags |= URB_ZERO_PACKET;
usb_submit_urb(int_urb, GFP_ATOMIC);
usb_fill_bulk_urb(data_urb, priv->udev,
usb_sndbulkpipe(priv->udev, P54U_PIPE_DATA), hdr, len + sizeof(*hdr),
free_on_tx ? p54u_tx_free_cb : p54u_tx_cb, dev);
+ data_urb->transfer_flags |= URB_ZERO_PACKET;
usb_submit_urb(data_urb, GFP_ATOMIC);
}
On Tuesday 20 January 2009, Christian Lamparter wrote:
> All p54usb devices need a explicit termination packet, in oder to finish the pending transfer properly.
> Else, the firmware could freeze, or simply drop the frame.
>
> Signed-off-by: Christian Lamparter <[email protected]>
> Cc: stable <[email protected]>
> ---
> Attached is the patch is for the stable series only.
> Bugzilla reference: http://bugzilla.kernel.org/show_bug.cgi?id=12260
> (wireless-testing needs a different one)
>
> Rafael, I hope we can close this bug. Greg?
Sure, we can.
Thanks,
Rafael
On Tue, Jan 20, 2009 at 11:11:11PM +0100, Christian Lamparter wrote:
> All p54usb devices need a explicit termination packet, in oder to finish the pending transfer properly.
> Else, the firmware could freeze, or simply drop the frame.
>
> Signed-off-by: Christian Lamparter <[email protected]>
> Cc: stable <[email protected]>
> ---
> Attached is the patch is for the stable series only.
> Bugzilla reference: http://bugzilla.kernel.org/show_bug.cgi?id=12260
> (wireless-testing needs a different one)
What do you mean, this is for 2.6.28-stable or 2.6.27-stable only, and
not 2.6.29? Why?
thanks,
greg k-h
On Tue, Jan 20, 2009 at 02:39:57PM -0800, Greg KH wrote:
> On Tue, Jan 20, 2009 at 11:11:11PM +0100, Christian Lamparter wrote:
> > All p54usb devices need a explicit termination packet, in oder to finish the pending transfer properly.
> > Else, the firmware could freeze, or simply drop the frame.
> >
> > Signed-off-by: Christian Lamparter <[email protected]>
> > Cc: stable <[email protected]>
> > ---
> > Attached is the patch is for the stable series only.
> > Bugzilla reference: http://bugzilla.kernel.org/show_bug.cgi?id=12260
> > (wireless-testing needs a different one)
>
> What do you mean, this is for 2.6.28-stable or 2.6.27-stable only, and
> not 2.6.29? Why?
At least part of that patch is already in 2.6.29. I think Christian
may have combined another patch into the -stable version, one that
he posted today for -rc inclusion.
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Monday 19 January 2009 03:45:43 pm Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a
> report of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known
> regressions introduced between 2.6.27 and 2.6.28. Please verify
> if it still should be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12426
> Subject : TMDC Joystick no longer works in kernel 2.6.28
> Submitter : Andrew S. Johnson <[email protected]>
> Date : 2009-01-10 21:53 (10 days old)
> References :
> http://marc.info/?l=linux-kernel&m=123162486415366&w=4
I have installed kernel 2.6.28.1, and this still does not work.
Andy Johnson
On Wednesday 21 January 2009 00:56:26 John W. Linville wrote:
> On Tue, Jan 20, 2009 at 02:39:57PM -0800, Greg KH wrote:
> > On Tue, Jan 20, 2009 at 11:11:11PM +0100, Christian Lamparter wrote:
> > > All p54usb devices need a explicit termination packet, in oder to finish the pending transfer properly.
> > > Else, the firmware could freeze, or simply drop the frame.
> > >
> > > Signed-off-by: Christian Lamparter <[email protected]>
> > > Cc: stable <[email protected]>
> > > ---
> > > Attached is the patch is for the stable series only.
> > > Bugzilla reference: http://bugzilla.kernel.org/show_bug.cgi?id=12260
> > > (wireless-testing needs a different one)
> >
> > What do you mean, this is for 2.6.28-stable or 2.6.27-stable only, and
> > not 2.6.29? Why?
>
> At least part of that patch is already in 2.6.29. I think Christian
> may have combined another patch into the -stable version, one that
> he posted today for -rc inclusion.
Yup, the -stable patch includes the diff "hunks" for all devices.
linux-wireless is a different affair, because the fix for LM87
(aka "p54usb: fix random traffic stalls (LM87)" ) is already merged.
So the patch I posted on linux-wirelss (-rc inclusion) only has the
diffs for the 1st generation and 2nd generation with old firmwares.
Regards,
Chr
On Tue, 2009-01-20 at 19:47 +0200, Avi Kivity wrote:
> Steven Rostedt wrote:
> > Note, the wakeup latency only tests realtime threads, since other threads
> > can have other issues for wakeup. I could change the wakeup tracer as
> > wakeup_rt, and make a new "wakeup" that tests all threads, but it may
> > be difficult to get something accurate.
>
> Kevin, can you retest with kvm at realtime priority?
Running vanilla Linux 2.6.28, kvm-82. First a control test to check that
the problem is still there when running at normal priority:
--- hermes-old.wumi.org.au ping statistics ---
900 packets transmitted, 900 received, 0% packet loss, time 899283ms
rtt min/avg/max/mdev = 0.119/269.773/13739.426/1230.836 ms, pipe 14
Yeah, sure is.
Okay, so now I set the realtime attributes of the processes for the VM
instance being pinged:
flexo:~# ps ax | grep 6284
6284 ? Sl 6:11 /usr/local/kvm/bin/qemu-system-x86_64 -smp 2
-m 2048 -hda kvm-17-1.img -hdb kvm-17-tmp.img -net
nic,vlan=0,macaddr=52:54:00:12:34:67,model=rtl8139 -net
tap,vlan=0,ifname=tap17,script=no -vnc 127.0.0.1:17 -usbdevice tablet
-daemonize
flexo:~# pstree -p 6284
qemu-system-x86(6284)─┬─{qemu-system-x86}(6285)
├─{qemu-system-x86}(6286)
└─{qemu-system-x86}(6540)
(info cpus on the QEMU console shows 6285 and 6286 being the VCPU
processes. Not sure what the third child is for, maybe vnc?.)
flexo:~# chrt -r -p 3 6284
flexo:~# chrt -r -p 3 6285
flexo:~# chrt -r -p 3 6286
flexo:~# chrt -p 6284
pid 6284's current scheduling policy: SCHED_RR
pid 6284's current scheduling priority: 3
flexo:~# chrt -p 6285
pid 6285's current scheduling policy: SCHED_RR
pid 6285's current scheduling priority: 3
flexo:~# chrt -p 6286
pid 6286's current scheduling policy: SCHED_RR
pid 6286's current scheduling priority: 3
And the result of the ping test now:
--- hermes-old.wumi.org.au ping statistics ---
900 packets transmitted, 900 received, 0% packet loss, time 899326ms
rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
So, a _huge_ difference. But what does it mean?
Regards,
Kevin.
P.S. Can someone tell me if I'm doing the CC: to bugme-daemon wrong? I
thought that was supposed to add the emails as comments to the
bugzilla report?
Kevin Shanahan wrote:
> On Tue, 2009-01-20 at 19:47 +0200, Avi Kivity wrote:
>
>> Steven Rostedt wrote:
>>
>>> Note, the wakeup latency only tests realtime threads, since other threads
>>> can have other issues for wakeup. I could change the wakeup tracer as
>>> wakeup_rt, and make a new "wakeup" that tests all threads, but it may
>>> be difficult to get something accurate.
>>>
>> Kevin, can you retest with kvm at realtime priority?
>>
>
> Running vanilla Linux 2.6.28, kvm-82. First a control test to check that
> the problem is still there when running at normal priority:
>
> --- hermes-old.wumi.org.au ping statistics ---
> 900 packets transmitted, 900 received, 0% packet loss, time 899283ms
> rtt min/avg/max/mdev = 0.119/269.773/13739.426/1230.836 ms, pipe 14
>
> Yeah, sure is.
>
> Okay, so now I set the realtime attributes of the processes for the VM
> instance being pinged:
>
> flexo:~# ps ax | grep 6284
> 6284 ? Sl 6:11 /usr/local/kvm/bin/qemu-system-x86_64 -smp 2
> -m 2048 -hda kvm-17-1.img -hdb kvm-17-tmp.img -net
> nic,vlan=0,macaddr=52:54:00:12:34:67,model=rtl8139 -net
> tap,vlan=0,ifname=tap17,script=no -vnc 127.0.0.1:17 -usbdevice tablet
> -daemonize
> flexo:~# pstree -p 6284
> qemu-system-x86(6284)─┬─{qemu-system-x86}(6285)
> ├─{qemu-system-x86}(6286)
> └─{qemu-system-x86}(6540)
>
> (info cpus on the QEMU console shows 6285 and 6286 being the VCPU
> processes. Not sure what the third child is for, maybe vnc?.)
>
> flexo:~# chrt -r -p 3 6284
> flexo:~# chrt -r -p 3 6285
> flexo:~# chrt -r -p 3 6286
> flexo:~# chrt -p 6284
> pid 6284's current scheduling policy: SCHED_RR
> pid 6284's current scheduling priority: 3
> flexo:~# chrt -p 6285
> pid 6285's current scheduling policy: SCHED_RR
> pid 6285's current scheduling priority: 3
> flexo:~# chrt -p 6286
> pid 6286's current scheduling policy: SCHED_RR
> pid 6286's current scheduling priority: 3
>
> And the result of the ping test now:
>
> --- hermes-old.wumi.org.au ping statistics ---
> 900 packets transmitted, 900 received, 0% packet loss, time 899326ms
> rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
>
> So, a _huge_ difference. But what does it mean?
It means, a scheduling problem. Can you run the latency tracer (which
only works with realtime priority), so we can tell if it is (a) kvm
failing to wake up the vcpu properly or (b) the scheduler delaying the
vcpu from running.
> P.S. Can someone tell me if I'm doing the CC: to bugme-daemon wrong? I
> thought that was supposed to add the emails as comments to the
> bugzilla report?
>
So long as it isn't complaining, you can continue.
--
error compiling committee.c: too many arguments to function
On Wed, 2009-01-21 at 16:34 +0200, Avi Kivity wrote:
> Kevin Shanahan wrote:
> > On Tue, 2009-01-20 at 19:47 +0200, Avi Kivity wrote:
> >> Kevin, can you retest with kvm at realtime priority?
...
> > --- hermes-old.wumi.org.au ping statistics ---
> > 900 packets transmitted, 900 received, 0% packet loss, time 899326ms
> > rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
> >
> > So, a _huge_ difference. But what does it mean?
>
> It means, a scheduling problem. Can you run the latency tracer (which
> only works with realtime priority), so we can tell if it is (a) kvm
> failing to wake up the vcpu properly or (b) the scheduler delaying the
> vcpu from running.
Sorry, but are you sure that's going to be useful?
If it only works on realtime threads and I'm not seeing the problem when
running kvm with realtime priority, is this going to tell you what you
want to know?
Not trying to be difficult, but that just didn't make sense to me.
Regards,
Kevin.
Kevin Shanahan wrote:
>>> --- hermes-old.wumi.org.au ping statistics ---
>>> 900 packets transmitted, 900 received, 0% packet loss, time 899326ms
>>> rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
>>>
>>> So, a _huge_ difference. But what does it mean?
>>>
>> It means, a scheduling problem. Can you run the latency tracer (which
>> only works with realtime priority), so we can tell if it is (a) kvm
>> failing to wake up the vcpu properly or (b) the scheduler delaying the
>> vcpu from running.
>>
>
> Sorry, but are you sure that's going to be useful?
>
> If it only works on realtime threads and I'm not seeing the problem when
> running kvm with realtime priority, is this going to tell you what you
> want to know?
>
> Not trying to be difficult, but that just didn't make sense to me.
>
You're right, wasn't thinking properly.
This is a tough one. I'll see if I can think of something. Ingo, any
ideas?
--
error compiling committee.c: too many arguments to function
On Wed, 21 Jan 2009, Avi Kivity wrote:
> Kevin Shanahan wrote:
> > On Tue, 2009-01-20 at 19:47 +0200, Avi Kivity wrote:
> >
> > > Steven Rostedt wrote:
> > >
> > > > Note, the wakeup latency only tests realtime threads, since other
> > > > threads
> > > > can have other issues for wakeup. I could change the wakeup tracer as
> > > > wakeup_rt, and make a new "wakeup" that tests all threads, but it may
> > > > be difficult to get something accurate.
> > > >
> > > Kevin, can you retest with kvm at realtime priority?
> > >
> >
> > Running vanilla Linux 2.6.28, kvm-82. First a control test to check that
> > the problem is still there when running at normal priority:
> >
> > --- hermes-old.wumi.org.au ping statistics ---
> > 900 packets transmitted, 900 received, 0% packet loss, time 899283ms
> > rtt min/avg/max/mdev = 0.119/269.773/13739.426/1230.836 ms, pipe 14
> >
> > Yeah, sure is.
> >
> > Okay, so now I set the realtime attributes of the processes for the VM
> > instance being pinged:
> >
> > flexo:~# ps ax | grep 6284
> > 6284 ? Sl 6:11 /usr/local/kvm/bin/qemu-system-x86_64 -smp 2
> > -m 2048 -hda kvm-17-1.img -hdb kvm-17-tmp.img -net
> > nic,vlan=0,macaddr=52:54:00:12:34:67,model=rtl8139 -net
> > tap,vlan=0,ifname=tap17,script=no -vnc 127.0.0.1:17 -usbdevice tablet
> > -daemonize
> > flexo:~# pstree -p 6284
> > qemu-system-x86(6284)???{qemu-system-x86}(6285)
> > ??{qemu-system-x86}(6286)
> > ??{qemu-system-x86}(6540)
> >
> > (info cpus on the QEMU console shows 6285 and 6286 being the VCPU
> > processes. Not sure what the third child is for, maybe vnc?.)
> >
> > flexo:~# chrt -r -p 3 6284
> > flexo:~# chrt -r -p 3 6285
> > flexo:~# chrt -r -p 3 6286
> > flexo:~# chrt -p 6284
> > pid 6284's current scheduling policy: SCHED_RR
> > pid 6284's current scheduling priority: 3
> > flexo:~# chrt -p 6285
> > pid 6285's current scheduling policy: SCHED_RR
> > pid 6285's current scheduling priority: 3
> > flexo:~# chrt -p 6286
> > pid 6286's current scheduling policy: SCHED_RR
> > pid 6286's current scheduling priority: 3
> >
> > And the result of the ping test now:
> >
> > --- hermes-old.wumi.org.au ping statistics ---
> > 900 packets transmitted, 900 received, 0% packet loss, time 899326ms
> > rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
> >
> > So, a _huge_ difference. But what does it mean?
>
> It means, a scheduling problem. Can you run the latency tracer (which only
> works with realtime priority), so we can tell if it is (a) kvm failing to wake
> up the vcpu properly or (b) the scheduler delaying the vcpu from running.
>
Note, I'm working on a tracer that will also measure non RT task wake up
times.
-- Steve
On Wed, 21 Jan 2009, Avi Kivity wrote:
> Kevin Shanahan wrote:
> > > > --- hermes-old.wumi.org.au ping statistics ---
> > > > 900 packets transmitted, 900 received, 0% packet loss, time 899326ms
> > > > rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
> > > >
> > > > So, a _huge_ difference. But what does it mean?
> > > >
> > > It means, a scheduling problem. Can you run the latency tracer (which
> > > only works with realtime priority), so we can tell if it is (a) kvm
> > > failing to wake up the vcpu properly or (b) the scheduler delaying the
> > > vcpu from running.
> > >
> >
> > Sorry, but are you sure that's going to be useful?
> >
> > If it only works on realtime threads and I'm not seeing the problem when
> > running kvm with realtime priority, is this going to tell you what you
> > want to know?
> >
> > Not trying to be difficult, but that just didn't make sense to me.
> >
>
> You're right, wasn't thinking properly.
>
> This is a tough one. I'll see if I can think of something. Ingo, any ideas?
>
I should have replied to this email :-)
Yeah, I'm working on making wakeup latency tracer work with non rt tasks.
The "wakeup" tracer will now trace all tasks where as a new "wakeup_rt"
tracer will only trace rt tasks. I did it for rt tasks only because it
only records the highest latency wake ups and the non rt tasks were always
bigger than the rt tasks which made what I was tracing useless (the rt
scheduling).
But by not having an option for all tasks, it makes the wakeup tracer
useless for everyone else ;-)
-- Steve
* Avi Kivity <[email protected]> wrote:
> Kevin Shanahan wrote:
>> On Tue, 2009-01-20 at 19:47 +0200, Avi Kivity wrote:
>>
>>> Steven Rostedt wrote:
>>>
>>>> Note, the wakeup latency only tests realtime threads, since other threads
>>>> can have other issues for wakeup. I could change the wakeup tracer as
>>>> wakeup_rt, and make a new "wakeup" that tests all threads, but it may
>>>> be difficult to get something accurate.
>>>>
>>> Kevin, can you retest with kvm at realtime priority?
>>>
>>
>> Running vanilla Linux 2.6.28, kvm-82. First a control test to check that
>> the problem is still there when running at normal priority:
>>
>> --- hermes-old.wumi.org.au ping statistics ---
>> 900 packets transmitted, 900 received, 0% packet loss, time 899283ms
>> rtt min/avg/max/mdev = 0.119/269.773/13739.426/1230.836 ms, pipe 14
>>
>> Yeah, sure is.
>>
>> Okay, so now I set the realtime attributes of the processes for the VM
>> instance being pinged:
>>
>> flexo:~# ps ax | grep 6284
>> 6284 ? Sl 6:11 /usr/local/kvm/bin/qemu-system-x86_64 -smp 2
>> -m 2048 -hda kvm-17-1.img -hdb kvm-17-tmp.img -net
>> nic,vlan=0,macaddr=52:54:00:12:34:67,model=rtl8139 -net
>> tap,vlan=0,ifname=tap17,script=no -vnc 127.0.0.1:17 -usbdevice tablet
>> -daemonize
>> flexo:~# pstree -p 6284
>> qemu-system-x86(6284)─┬─{qemu-system-x86}(6285)
>> ├─{qemu-system-x86}(6286)
>> └─{qemu-system-x86}(6540)
>>
>> (info cpus on the QEMU console shows 6285 and 6286 being the VCPU
>> processes. Not sure what the third child is for, maybe vnc?.)
>>
>> flexo:~# chrt -r -p 3 6284
>> flexo:~# chrt -r -p 3 6285
>> flexo:~# chrt -r -p 3 6286
>> flexo:~# chrt -p 6284
>> pid 6284's current scheduling policy: SCHED_RR
>> pid 6284's current scheduling priority: 3
>> flexo:~# chrt -p 6285
>> pid 6285's current scheduling policy: SCHED_RR
>> pid 6285's current scheduling priority: 3
>> flexo:~# chrt -p 6286
>> pid 6286's current scheduling policy: SCHED_RR
>> pid 6286's current scheduling priority: 3
>>
>> And the result of the ping test now:
>>
>> --- hermes-old.wumi.org.au ping statistics ---
>> 900 packets transmitted, 900 received, 0% packet loss, time 899326ms
>> rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
>>
>> So, a _huge_ difference. But what does it mean?
>
> It means, a scheduling problem. Can you run the latency tracer (which
> only works with realtime priority), so we can tell if it is (a) kvm
> failing to wake up the vcpu properly or (b) the scheduler delaying the
> vcpu from running.
Could we please get an ftrace capture of the incident?
Firstly, it makes sense to simplify the tracing environment as much as
possible: for example single-CPU traces are much easier to interpret.
Can you reproduce it with just one CPU online? I.e. if you offline all the
other cores via:
echo 0 > /sys/devices/system/cpu/cpu1/online
[etc.]
and keep CPU#0 only, do the latencies still occur?
If they do still occur, then please do the traces that way.
[ If they do not occur then switch back on all CPUs - we'll sort out the
traces ;-) ]
Then please build a function tracer kernel, by enabling:
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
Once you boot into such a kernel, you can switch on function tracing via:
cd /debug/tracing/
echo 0 > tracing_enabled
echo function_graph > current_tracer
echo funcgraph-proc > trace_options
It does not run yet, first find a suitable set of functions to trace. For
example this will be a pretty good starting point for scheduler+KVM
problems:
echo '' > set_ftrace_filter # clear filter functions
echo '*sched*' >> set_ftrace_filter
echo '*wake*' >> set_ftrace_filter
echo '*kvm*' >> set_ftrace_filter
echo 1 > tracing_enabled # let the tracer go
You can see your current selection of functions to trace via 'cat
set_ftrace_filter', and you can see all functions via 'cat
available_filter_functions'.
You can also trace all functions via:
echo '*' > set_ftrace_filter
Tracer output can be captured from the 'trace' file. It should look like
this:
15) cc1-28106 | 0.263 us | page_evictable();
15) cc1-28106 | | lru_cache_add_lru() {
15) cc1-28106 | 0.252 us | __lru_cache_add();
15) cc1-28106 | 0.738 us | }
15) cc1-28106 | + 74.026 us | }
15) cc1-28106 | | up_read() {
15) cc1-28106 | 0.257 us | _spin_lock_irqsave();
15) cc1-28106 | 0.253 us | _spin_unlock_irqrestore();
15) cc1-28106 | 1.329 us | }
To capture a continuous stream of all trace data you can do:
cat trace_pipe > /tmp/trace.txt
(this will also drain the trace ringbuffers.)
Note that this can be quite expensive if there are a lot of functions that
are traced - so it makes sense to trim down the set of traced functions to
only the interesting ones. Which are the interesting ones can be
determined from looking at the traces. You should see your KVM threads
getting active every second as the ping happens.
If you get lost events you can increase the trace buffer size via the
buffer_size_kb control - the default is around 1.4 MB.
Let me know if any of these steps is causing problems or if interpreting
the traces is difficult.
Ingo
On Mon, Jan 19, 2009 at 10:45:43PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12409
> Subject : NULL pointer dereference at get_stats()
> Submitter : Tetsuo Handa <[email protected]>
> Date : 2008-12-30 12:53 (21 days old)
> References : http://marc.info/?l=linux-kernel&m=123064167008695&w=4
> Handled-By : Frederik Deweerdt <[email protected]>
>
>
Hello Rafael,
Not sure what the status should be for that one, it sure seems vmware
related, and I don't have one handy.
Regards,
Frederik
On Wed, 21 Jan 2009, Avi Kivity wrote:
> Kevin Shanahan wrote:
> > > > --- hermes-old.wumi.org.au ping statistics ---
> > > > 900 packets transmitted, 900 received, 0% packet loss, time 899326ms
> > > > rtt min/avg/max/mdev = 0.093/0.157/3.611/0.117 ms
> > > >
> > > > So, a _huge_ difference. But what does it mean?
> > > >
> > > It means, a scheduling problem. Can you run the latency tracer (which
> > > only works with realtime priority), so we can tell if it is (a) kvm
> > > failing to wake up the vcpu properly or (b) the scheduler delaying the
> > > vcpu from running.
> > >
> >
> > Sorry, but are you sure that's going to be useful?
> >
> > If it only works on realtime threads and I'm not seeing the problem when
> > running kvm with realtime priority, is this going to tell you what you
> > want to know?
> >
> > Not trying to be difficult, but that just didn't make sense to me.
> >
>
> You're right, wasn't thinking properly.
>
> This is a tough one. I'll see if I can think of something. Ingo, any ideas?
I fixed up the wakeup latency tracer to work with all tasks (as well as
other fixes). You can checkout the following:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
branch: tip/devel
compile with CONFIG_FUNCTION_TRACER and CONFIG_SCHED_TRACER and just
echo 0 > /debug/tracing/tracing_enabled
echo wakeup > /debug/tracing/current_tracer
echo 1 > /debug/tracing/tracing_enabled
run your test
echo 0 > /debug/tracing/tracing_enabled
and then look at /debug/tracing/latency_trace
-- Steve
Dmitry Torokhov wrote:
> Sorry, must have missed that. I think it's gonna be a bit chatty if
> user happens to have Logitech++ device attached, however I think if
> we complement it with the patch below I think it should work OK.
Dmitry, I don't see the effect of your patch. I.e., both the patch by
Arjan referenced in the bug, and combination of that patch with yours,
produce a working mouse and this dmesg output:
psmouse serio1: ID: 10 00 64<6>elantech.c: Elantech version query result
0x00, 0x01, 0x64.
elantech.c: Probably not a real Elantech touchpad. Aborting.
input: ImExPS/2 Logitech Wheel Mouse as /class/input/input18
--
Alexander E. Patrakov
On Tue, 20 Jan 2009, Andrew S. Johnson wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12426
> > Subject : TMDC Joystick no longer works in kernel 2.6.28
> > Submitter : Andrew S. Johnson <[email protected]>
> > Date : 2009-01-10 21:53 (10 days old)
> > References :
> > http://marc.info/?l=linux-kernel&m=123162486415366&w=4
> I have installed kernel 2.6.28.1, and this still does not work.
What exactly doesn't work? Namely:
- do you see jsX node appearing in /dev after you modprobe joydev
manually?
- do you see the corresponding entry for the gameport in
/sys/bus/gameport/{devices,drivers} ?
--
Jiri Kosina
SUSE Labs
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28.1
# Sun Jan 18 22:04:33 2009
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_CLASSIC_RCU=y
CONFIG_FREEZER=y
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_VSMP is not set
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
CONFIG_MK8=y
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR_64=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_INTEL is not set
CONFIG_X86_MCE_AMD=y
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
# CONFIG_X86_RESERVE_LOW_64K is not set
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x200000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x200000
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management and ACPI options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set
#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
# CONFIG_PCMCIA_IOCTL is not set
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
# CONFIG_IA32_EMULATION is not set
# CONFIG_COMPAT_FOR_U64_ALIGNMENT is not set
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
CONFIG_NF_CONNTRACK=m
# CONFIG_NF_CT_ACCT is not set
# CONFIG_NF_CONNTRACK_MARK is not set
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_DCCP is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=m
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=m
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
# CONFIG_NETFILTER_XT_MATCH_STATE is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_IP_VS is not set
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=m
# CONFIG_IP_NF_TARGET_REJECT is not set
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
# CONFIG_IP_NF_TARGET_MASQUERADE is not set
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_REDIRECT is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_FTP=m
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_PHONET is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211 is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
# CONFIG_WIRELESS_EXT_SYSFS is not set
CONFIG_MAC80211=m
#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_PID=y
# CONFIG_MAC80211_RC_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_IEEE80211 is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_EEPROM_93CX6=m
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_PMP is not set
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
CONFIG_PATA_ATIIXP=y
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
CONFIG_PATA_PCMCIA=m
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_SCH is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# Enable only one of the two stacks, unless you know what you are doing
#
CONFIG_FIREWIRE=y
CONFIG_FIREWIRE_OHCI=y
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=y
CONFIG_IEEE1394=y
CONFIG_IEEE1394_OHCI1394=m
#
# PCILynx controller requires I2C
#
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_RAWIO is not set
# CONFIG_IEEE1394_VIDEO1394 is not set
# CONFIG_IEEE1394_DV1394 is not set
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_ATL2 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH5K is not set
# CONFIG_ATH9K is not set
# CONFIG_IWLCORE is not set
# CONFIG_IWLWIFI_LEDS is not set
# CONFIG_IWLAGN is not set
# CONFIG_IWL3945 is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
CONFIG_RT2X00=m
# CONFIG_RT2400PCI is not set
CONFIG_RT2500PCI=m
# CONFIG_RT61PCI is not set
# CONFIG_RT2500USB is not set
# CONFIG_RT73USB is not set
CONFIG_RT2X00_LIB_PCI=m
CONFIG_RT2X00_LIB=m
CONFIG_RT2X00_LIB_RFKILL=y
# CONFIG_RT2X00_DEBUG is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_NET_PCMCIA is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=m
# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=m
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=m
CONFIG_SERIAL_8250_PNP=m
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
# CONFIG_I2C is not set
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_REGULATOR is not set
#
# Multimedia devices
#
#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set
#
# Multimedia drivers
#
# CONFIG_DAB is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=m
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_SEQUENCER_OSS is not set
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=3
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_USB is not set
# CONFIG_SND_PCMCIA is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
#
# Special HID drivers
#
# CONFIG_HID_COMPAT is not set
CONFIG_HID_A4TECH=m
CONFIG_HID_APPLE=m
CONFIG_HID_BELKIN=m
CONFIG_HID_BRIGHT=m
CONFIG_HID_CHERRY=m
CONFIG_HID_CHICONY=m
CONFIG_HID_CYPRESS=m
CONFIG_HID_DELL=m
CONFIG_HID_EZKEY=m
CONFIG_HID_GYRATION=m
CONFIG_HID_LOGITECH=m
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=m
CONFIG_HID_MONTEREY=m
CONFIG_HID_PANTHERLORD=m
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=m
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
CONFIG_HID_SUNPLUS=m
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed;
#
#
# see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set
# CONFIG_UWB is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=m
# CONFIG_MMC_WBSD is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MMC_SDRICOH_CS is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set
#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=m
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=m
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
CONFIG_NLS_ISO8859_7=m
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
# CONFIG_DLM is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
#
# Tracers
#
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
# CONFIG_DYNAMIC_PRINTK_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_OPTIMIZE_INLINING=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=m
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_X86_64=m
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_LZO=m
#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
On Wed, 2009-01-21 at 16:18 +0100, Ingo Molnar wrote:
> * Avi Kivity <[email protected]> wrote:
> > It means, a scheduling problem. Can you run the latency tracer (which
> > only works with realtime priority), so we can tell if it is (a) kvm
> > failing to wake up the vcpu properly or (b) the scheduler delaying the
> > vcpu from running.
>
> Could we please get an ftrace capture of the incident?
>
> Firstly, it makes sense to simplify the tracing environment as much as
> possible: for example single-CPU traces are much easier to interpret.
>
> Can you reproduce it with just one CPU online? I.e. if you offline all the
> other cores via:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
>
> [etc.]
>
> and keep CPU#0 only, do the latencies still occur?
>
> If they do still occur, then please do the traces that way.
>
> [ If they do not occur then switch back on all CPUs - we'll sort out the
> traces ;-) ]
>
> Then please build a function tracer kernel, by enabling:
>
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=y
> CONFIG_DYNAMIC_FTRACE=y
Looks like the function graph tracer is only in 2.6.29, so I've updated
now to 2.6.29-rc2-00013-gf3b8436.
Again, a control test to make sure the problem still occurs:
--- hermes-old.wumi.org.au ping statistics ---
64 packets transmitted, 64 received, 0% packet loss, time 63080ms
rtt min/avg/max/mdev = 0.168/479.893/4015.950/894.721 ms, pipe 5
Yes, plenty of delays there. Next, checking if I can reproduce with only
one core online:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu3/online
...
--- hermes-old.wumi.org.au ping statistics ---
900 packets transmitted, 900 received, 0% packet loss, time 900253ms
rtt min/avg/max/mdev = 0.127/38.937/2082.347/170.348 ms, pipe 3
--- hermes-old.wumi.org.au ping statistics ---
900 packets transmitted, 900 received, 0% packet loss, time 900995ms
rtt min/avg/max/mdev = 0.127/428.398/17126.227/1634.980 ms, pipe 18
So it looks like I can do the simplified trace. I've run out of time for
that this morning, but I'll spend some time on it over the weekend.
Thanks for the detailed instructions - it doesn't look like it will be
too hard.
Cheers,
Kevin.
* Kevin Shanahan <[email protected]> wrote:
> On Wed, 2009-01-21 at 16:18 +0100, Ingo Molnar wrote:
> > * Avi Kivity <[email protected]> wrote:
> > > It means, a scheduling problem. Can you run the latency tracer (which
> > > only works with realtime priority), so we can tell if it is (a) kvm
> > > failing to wake up the vcpu properly or (b) the scheduler delaying the
> > > vcpu from running.
> >
> > Could we please get an ftrace capture of the incident?
> >
> > Firstly, it makes sense to simplify the tracing environment as much as
> > possible: for example single-CPU traces are much easier to interpret.
> >
> > Can you reproduce it with just one CPU online? I.e. if you offline all the
> > other cores via:
> >
> > echo 0 > /sys/devices/system/cpu/cpu1/online
> >
> > [etc.]
> >
> > and keep CPU#0 only, do the latencies still occur?
> >
> > If they do still occur, then please do the traces that way.
> >
> > [ If they do not occur then switch back on all CPUs - we'll sort out the
> > traces ;-) ]
> >
> > Then please build a function tracer kernel, by enabling:
> >
> > CONFIG_FUNCTION_TRACER=y
> > CONFIG_FUNCTION_GRAPH_TRACER=y
> > CONFIG_DYNAMIC_FTRACE=y
>
> Looks like the function graph tracer is only in 2.6.29, so I've updated
> now to 2.6.29-rc2-00013-gf3b8436.
>
> Again, a control test to make sure the problem still occurs:
>
> --- hermes-old.wumi.org.au ping statistics ---
> 64 packets transmitted, 64 received, 0% packet loss, time 63080ms
> rtt min/avg/max/mdev = 0.168/479.893/4015.950/894.721 ms, pipe 5
>
> Yes, plenty of delays there. Next, checking if I can reproduce with only
> one core online:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo 0 > /sys/devices/system/cpu/cpu2/online
> echo 0 > /sys/devices/system/cpu/cpu3/online
> ...
>
> --- hermes-old.wumi.org.au ping statistics ---
> 900 packets transmitted, 900 received, 0% packet loss, time 900253ms
> rtt min/avg/max/mdev = 0.127/38.937/2082.347/170.348 ms, pipe 3
>
> --- hermes-old.wumi.org.au ping statistics ---
> 900 packets transmitted, 900 received, 0% packet loss, time 900995ms
> rtt min/avg/max/mdev = 0.127/428.398/17126.227/1634.980 ms, pipe 18
>
> So it looks like I can do the simplified trace. [...]
That's good news! Another thing is that happens sometimes is that narrow
races go away if tracing is turned on - the dreaded Heisenbugs. Hopefully
this wont happen, but if it does, tracing is the cheapest when only a few
specific functions are traced.
There are two main types of delays that can occur:
- the delay is CPU time - i.e. anomalously large amount of CPU time spent
somewhere in the kernel. Getting a trace of exactly what that
processing is would be nice.
- the delay is some sort of missed wakeup or other logic error in the
flow of execution. These are harder to trace - you might want to take a
look at trace_options to extend the trace format with various details,
if the need arises.
> [...] I've run out of time for that this morning, but I'll spend some
> time on it over the weekend. Thanks for the detailed instructions - it
> doesn't look like it will be too hard.
ok, looking forward to your traces. Also, let us know if you run into
anything unintuitive / complicated in the ftrace usage side.
Ingo
On Thursday 22 January 2009 07:34:46 am Jiri Kosina wrote:
> On Tue, 20 Jan 2009, Andrew S. Johnson wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12426
> > > Subject : TMDC Joystick no longer works in kernel 2.6.28
> > > Submitter : Andrew S. Johnson <[email protected]>
> > > Date : 2009-01-10 21:53 (10 days old)
> > > References :
> > > http://marc.info/?l=linux-kernel&m=123162486415366&w=4
> >
> > I have installed kernel 2.6.28.1, and this still does not work.
>
> What exactly doesn't work? Namely:
>
> - do you see jsX node appearing in /dev after you modprobe joydev
> manually?
No. Running 2.6.28.1 "find /dev -ls | grep j" returns nothing.
Running 2.6.27.9, the same "find /dev -ls | grep j" returns:
10353 0 lrwxrwxrwx 1 root root 9 Jan 22 18:23 /dev/js0 -> input/js0
10347 0 crw-r--r-- 1 root root Jan 22 18:23 /dev/input/js0
10351 0 drwxr-xr-x 2 root root 60 Jan 22 18:23 /dev/.udev/names/input\\x2fjs0
10352 0 -rw-r--r-- 1 root root 0 Jan 22 18:23 /dev/.udev/names/input\\x2fjs0/\\x2fclass\\x2finput\\x2finput5\\x2fjs0
10349 0 drwxr-xr-x 2 root root 60 Jan 22 18:23 /dev/.udev/names/js0
10350 0 -rw-r--r-- 1 root root 0 Jan 22 18:23 /dev/.udev/names/js0/\\x2fclass\\x2finput\\x2finput5\\x2fjs0
10348 4 -rw-r--r-- 1 root root 66 Jan 22 18:23 /dev/.udev/db/\\x2fclass\\x2finput\\x2finput5\\x2fjs0
> - do you see the corresponding entry for the gameport in
> /sys/bus/gameport/{devices,drivers} ?
These are almost the same when running "find /sys/bus/gameport -ls":
Kernel 2.6.28.1 (missing one line):
9575 0 drwxr-xr-x 4 root root 0 Jan 22 18:13 /sys/bus/gameport
9576 0 --w------- 1 root root 4096 Jan 22 18:16 /sys/bus/gameport/uevent
9577 0 drwxr-xr-x 2 root root 0 Jan 22 18:13 /sys/bus/gameport/devices
9783 0 lrwxrwxrwx 1 root root 0 Jan 22 18:13 /sys/bus/gameport/devices/gameport0 -> ../../../devices/pnp0/00:07/gameport0
9578 0 drwxr-xr-x 3 root root 0 Jan 22 18:15 /sys/bus/gameport/drivers
12186 0 drwxr-xr-x 2 root root 0 Jan 22 18:15 /sys/bus/gameport/drivers/tmdc
12187 0 lrwxrwxrwx 1 root root 0 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/module -> ../../../../module/tmdc
12190 0 --w------- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/uevent
12191 0 -r--r--r-- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/description
12192 0 --w------- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/unbind
12193 0 --w------- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/bind
9579 0 --w------- 1 root root 4096 Jan 22 18:16 /sys/bus/gameport/drivers_probe
9580 0 -rw-r--r-- 1 root root 4096 Jan 22 18:16 /sys/bus/gameport/drivers_autoprobe
Kernel 2.6.27.9 has one more line (see 12040):
9489 0 drwxr-xr-x 4 root root 0 Jan 22 18:23 /sys/bus/gameport
9490 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/uevent
9491 0 drwxr-xr-x 2 root root 0 Jan 22 18:23 /sys/bus/gameport/devices
9774 0 lrwxrwxrwx 1 root root 0 Jan 22 18:23 /sys/bus/gameport/devices/gameport0 -> ../../../devices/pnp0/00:07/gameport0
9492 0 drwxr-xr-x 3 root root 0 Jan 22 18:23 /sys/bus/gameport/drivers
12039 0 drwxr-xr-x 2 root root 0 Jan 22 18:23 /sys/bus/gameport/drivers/tmdc
12040 0 lrwxrwxrwx 1 root root 0 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/gameport0 -> ../../../../devices/pnp0/00:07/gameport0
12078 0 lrwxrwxrwx 1 root root 0 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/module -> ../../../../module/tmdc
12081 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/uevent
12082 0 -r--r--r-- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/description
12083 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/unbind
12084 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/bind
9493 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers_probe
9494 0 -rw-r--r-- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers_autoprobe
If there is anything else I can provide, please let me know.
Andy Johnson
Hello.
Frederik Deweerdt wrote:
> On Mon, Jan 19, 2009 at 10:45:43PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28. Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12409
> > Subject : NULL pointer dereference at get_stats()
> > Submitter : Tetsuo Handa <[email protected]>
> > Date : 2008-12-30 12:53 (21 days old)
> > References : http://marc.info/?l=linux-kernel&m=123064167008695&w=4
> > Handled-By : Frederik Deweerdt <[email protected]>
> >
> >
> Hello Rafael,
>
> Not sure what the status should be for that one, it sure seems vmware
> related, and I don't have one handy.
>
> Regards,
> Frederik
>
The latest post regarding this problem starts at http://lkml.org/lkml/2009/1/4/349 .
It's not a VMware related problem.
A patch at http://lkml.org/lkml/2009/1/5/557 reported that "nolapic" option
doesn't prevent for_each_possible_cpu() from reaching CPU1, and per-CPU pointer
for CPU1 is NULL.
--- First call of for_each_possible_cpu() ---
Entering get_stats()
CPU=0
Leaving get_stats()
--- Second call of for_each_possible_cpu() ---
Entering get_stats()
CPU=0
CPU=1
lb_stats == NULL for CPU 1
Leaving get_stats()
Regards.
Rafael J. Wysocki wrote:
> This message contains a list of some regressions introduced between 2.6.27
> and 2.6.28, for which there are no fixes in the mainline I know of. If any
> of them have been fixed already, please let me know.
>
> If you know of any other unresolved regressions introduced between 2.6.27
> and 2.6.28, please let me know either and I'll add them to the list.
> Also, please let me know if any of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2009-01-20 144 30 27
> 2009-01-11 139 33 30
> 2008-12-21 120 19 17
> 2008-12-13 111 14 13
> 2008-12-07 106 20 17
> 2008-12-04 106 29 21
> 2008-11-22 93 25 15
> 2008-11-16 89 32 18
> 2008-11-09 73 40 27
> 2008-11-02 55 41 29
> 2008-10-25 26 25 20
>
>
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12500
> Subject : r8169: NETDEV WATCHDOG: eth0 (r8169): transmit timed out
> Submitter : Justin Piszcz <[email protected]>
> Date : 2009-01-13 21:19 (7 days old)
> References : http://marc.info/?l=linux-kernel&m=123188160811322&w=4
> Handled-By : Francois Romieu <[email protected]>
This one, as well as 12411, is likely just a dupe of 10109. r8169 has this
problem for more than a year.
Greetings,
Eike
On Wed, 2009-01-21 at 16:18 +0100, Ingo Molnar wrote:
> * Avi Kivity <[email protected]> wrote:
> > It means, a scheduling problem. Can you run the latency tracer (which
> > only works with realtime priority), so we can tell if it is (a) kvm
> > failing to wake up the vcpu properly or (b) the scheduler delaying the
> > vcpu from running.
>
> Could we please get an ftrace capture of the incident?
>
> Firstly, it makes sense to simplify the tracing environment as much as
> possible: for example single-CPU traces are much easier to interpret.
>
> Can you reproduce it with just one CPU online? I.e. if you offline all the
> other cores via:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
>
> [etc.]
>
> and keep CPU#0 only, do the latencies still occur?
>
> If they do still occur, then please do the traces that way.
>
> [ If they do not occur then switch back on all CPUs - we'll sort out the
> traces ;-) ]
>
> Then please build a function tracer kernel, by enabling:
>
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=y
> CONFIG_DYNAMIC_FTRACE=y
>
> Once you boot into such a kernel, you can switch on function tracing via:
>
> cd /debug/tracing/
>
> echo 0 > tracing_enabled
> echo function_graph > current_tracer
> echo funcgraph-proc > trace_options
>
> It does not run yet, first find a suitable set of functions to trace. For
> example this will be a pretty good starting point for scheduler+KVM
> problems:
>
> echo '' > set_ftrace_filter # clear filter functions
> echo '*sched*' >> set_ftrace_filter
> echo '*wake*' >> set_ftrace_filter
> echo '*kvm*' >> set_ftrace_filter
> echo 1 > tracing_enabled # let the tracer go
>
> You can see your current selection of functions to trace via 'cat
> set_ftrace_filter', and you can see all functions via 'cat
> available_filter_functions'.
>
> You can also trace all functions via:
>
> echo '*' > set_ftrace_filter
>
> Tracer output can be captured from the 'trace' file. It should look like
> this:
>
> 15) cc1-28106 | 0.263 us | page_evictable();
> 15) cc1-28106 | | lru_cache_add_lru() {
> 15) cc1-28106 | 0.252 us | __lru_cache_add();
> 15) cc1-28106 | 0.738 us | }
> 15) cc1-28106 | + 74.026 us | }
> 15) cc1-28106 | | up_read() {
> 15) cc1-28106 | 0.257 us | _spin_lock_irqsave();
> 15) cc1-28106 | 0.253 us | _spin_unlock_irqrestore();
> 15) cc1-28106 | 1.329 us | }
>
> To capture a continuous stream of all trace data you can do:
>
> cat trace_pipe > /tmp/trace.txt
>
> (this will also drain the trace ringbuffers.)
>
> Note that this can be quite expensive if there are a lot of functions that
> are traced - so it makes sense to trim down the set of traced functions to
> only the interesting ones. Which are the interesting ones can be
> determined from looking at the traces. You should see your KVM threads
> getting active every second as the ping happens.
>
> If you get lost events you can increase the trace buffer size via the
> buffer_size_kb control - the default is around 1.4 MB.
>
> Let me know if any of these steps is causing problems or if interpreting
> the traces is difficult.
Just carrying out the steps was okay, but I don't really know what I'm
looking at. I've uploaded the trace here (about 10 seconds worth, I
think):
http://disenchant.net/tmp/bug-12465/trace-1/
The guest being pinged is process 4353:
kmshanah@flexo:~$ pstree -p 4353
qemu-system-x86(4353)─┬─{qemu-system-x86}(4354)
├─{qemu-system-x86}(4355)
└─{qemu-system-x86}(4772)
I guess the larger overhead/duration values are what we are looking for,
e.g.:
kmshanah@flexo:~$ bzgrep -E '[[:digit:]]{6,}' trace.txt.bz2
0) ksoftir-4 | ! 3010470 us | }
0) qemu-sy-4354 | ! 250406.2 us | }
0) qemu-sy-4354 | ! 250407.0 us | }
0) qemu-sy-4354 | ! 362946.3 us | }
0) qemu-sy-4354 | ! 362947.0 us | }
0) qemu-sy-4177 | ! 780480.3 us | }
0) qemu-sy-4354 | ! 117685.7 us | }
0) qemu-sy-4354 | ! 117686.5 us | }
That ksoftirqd value is a bit strange (> 3 seconds, or is the formatting
wrong?). I guess I still need some guidance to know what I'm looking at
with this trace and/or what to do next.
Cheers,
Kevin.
On Mon, 19 Jan 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
Yes, still unfixed. There was some private discussion with the
scheduler guys and now I suspect this is not a scheduler regression
but a more longstanding UML bug that was made visible by some
scheduler changes.
Thanks,
Miklos
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12208
> Subject : uml is very slow on 2.6.28 host
> Submitter : Miklos Szeredi <[email protected]>
> Date : 2008-12-12 9:35 (39 days old)
> References : http://marc.info/?l=linux-kernel&m=122907463518593&w=4
>
>
>
On Mon, 2009-01-26 at 20:25 +1030, Kevin Shanahan wrote:
> Just carrying out the steps was okay, but I don't really know what I'm
> looking at. I've uploaded the trace here (about 10 seconds worth, I
> think):
>
> http://disenchant.net/tmp/bug-12465/trace-1/
>
> The guest being pinged is process 4353:
>
> kmshanah@flexo:~$ pstree -p 4353
> qemu-system-x86(4353)─┬─{qemu-system-x86}(4354)
> ├─{qemu-system-x86}(4355)
> └─{qemu-system-x86}(4772)
>
> I guess the larger overhead/duration values are what we are looking for,
> e.g.:
>
> kmshanah@flexo:~$ bzgrep -E '[[:digit:]]{6,}' trace.txt.bz2
> 0) ksoftir-4 | ! 3010470 us | }
> 0) qemu-sy-4354 | ! 250406.2 us | }
> 0) qemu-sy-4354 | ! 250407.0 us | }
> 0) qemu-sy-4354 | ! 362946.3 us | }
> 0) qemu-sy-4354 | ! 362947.0 us | }
> 0) qemu-sy-4177 | ! 780480.3 us | }
> 0) qemu-sy-4354 | ! 117685.7 us | }
> 0) qemu-sy-4354 | ! 117686.5 us | }
>
> That ksoftirqd value is a bit strange (> 3 seconds, or is the formatting
> wrong?). I guess I still need some guidance to know what I'm looking at
> with this trace and/or what to do next.
What happens is that it gets preempted a few times while running a
particular function, say do_softirqd(), or kvm_arch_vcpu_ioctl_run().
Now, when this function ends, it prints the wall-time delay between
start and end of that function, instead of the task-time delay.
So by having been preempted several times, that gets inflated.
That said, the output is slightly 'buggy' in that is seems to miss
context switches at times:
0) qemu-sy-4339 | | schedule() {
0) qemu-sy-4131 | ! 6750.369 us | }
I also find it very hard to attribute all time:
0) qemu-sy-4354 | | kvm_vcpu_ioctl() {
0) qemu-sy-4354 | | kvm_arch_vcpu_ioctl_run() {
0) qemu-sy-4354 | | kvm_arch_vcpu_load() {
0) qemu-sy-4354 | | kvm_write_guest_time() {
0) qemu-sy-4354 | 0.289 us | }
0) qemu-sy-4354 | 0.956 us | }
0) qemu-sy-4354 | | kvm_inject_pending_timer_irqs() {
0) qemu-sy-4354 | | kvm_inject_apic_timer_irqs() {
0) qemu-sy-4354 | 0.295 us | }
0) qemu-sy-4354 | | kvm_inject_pit_timer_irqs() {
0) qemu-sy-4354 | 0.304 us | }
0) qemu-sy-4354 | 1.488 us | }
0) qemu-sy-4354 | | kvm_lapic_enabled() {
0) qemu-sy-4354 | 0.294 us | }
0) qemu-sy-4354 | | kvm_lapic_find_highest_irr() {
0) qemu-sy-4354 | 0.307 us | }
0) qemu-sy-4354 | | kvm_cpu_has_interrupt() {
0) qemu-sy-4354 | | kvm_apic_has_interrupt() {
0) qemu-sy-4354 | 0.325 us | }
0) qemu-sy-4354 | | kvm_apic_accept_pic_intr() {
0) qemu-sy-4354 | 0.298 us | }
0) qemu-sy-4354 | 1.521 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_to_vapic() {
0) qemu-sy-4354 | 0.295 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | autoremove_wake_function() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | | wakeup_preempt_entity() {
0) qemu-sy-4354 | 0.309 us | }
0) qemu-sy-4354 | | resched_task() {
0) qemu-sy-4354 | 0.324 us | }
0) qemu-sy-4354 | 1.614 us | }
0) qemu-sy-4354 | 2.934 us | }
0) qemu-sy-4354 | 3.529 us | }
0) qemu-sy-4354 | 4.118 us | }
0) qemu-sy-4354 | 4.743 us | }
0) qemu-sy-4354 | 5.432 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | autoremove_wake_function() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 => qemu-sy-4294
0) qemu-sy-4237 => qemu-sy-4354
0) qemu-sy-4354 | 5.500 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.316 us | }
0) qemu-sy-4354 | 1.250 us | }
0) qemu-sy-4354 | 1.834 us | }
0) qemu-sy-4354 | 2.434 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.418 us | }
0) qemu-sy-4354 | 1.001 us | }
0) qemu-sy-4354 | 1.608 us | }
0) qemu-sy-4354 | 4.987 us | }
0) qemu-sy-4354 | 5.597 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.325 us | }
0) qemu-sy-4354 | 1.247 us | }
0) qemu-sy-4354 | 1.831 us | }
0) qemu-sy-4354 | 2.435 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.415 us | }
0) qemu-sy-4354 | 0.995 us | }
0) qemu-sy-4354 | 1.587 us | }
0) qemu-sy-4354 | 5.026 us | }
0) qemu-sy-4354 | 5.639 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.313 us | }
0) qemu-sy-4354 | 1.331 us | }
0) qemu-sy-4354 | 1.903 us | }
0) qemu-sy-4354 | 2.507 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.415 us | }
0) qemu-sy-4354 | 0.998 us | }
0) qemu-sy-4354 | 1.596 us | }
0) qemu-sy-4354 | 5.017 us | }
0) qemu-sy-4354 | 5.630 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.318 us | }
0) qemu-sy-4354 | 1.275 us | }
0) qemu-sy-4354 | 1.860 us | }
0) qemu-sy-4354 | 2.474 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.406 us | }
0) qemu-sy-4354 | 0.989 us | }
0) qemu-sy-4354 | 1.581 us | }
0) qemu-sy-4354 | 4.953 us | }
0) qemu-sy-4354 | 5.567 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.313 us | }
0) qemu-sy-4354 | 2.645 us | }
0) qemu-sy-4354 | 3.219 us | }
0) qemu-sy-4354 | 3.824 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.396 us | }
0) qemu-sy-4354 | 0.968 us | }
0) qemu-sy-4354 | 1.557 us | }
0) qemu-sy-4354 | 6.390 us | }
0) qemu-sy-4354 | 7.004 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.310 us | }
0) qemu-sy-4354 | 1.160 us | }
0) qemu-sy-4354 | 1.731 us | }
0) qemu-sy-4354 | 2.330 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.397 us | }
0) qemu-sy-4354 | 0.965 us | }
0) qemu-sy-4354 | 1.554 us | }
0) qemu-sy-4354 | 4.768 us | }
0) qemu-sy-4354 | 5.383 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.307 us | }
0) qemu-sy-4354 | 1.208 us | }
0) qemu-sy-4354 | 1.777 us | }
0) qemu-sy-4354 | 2.377 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.394 us | }
0) qemu-sy-4354 | 0.964 us | }
0) qemu-sy-4354 | 1.554 us | }
0) qemu-sy-4354 | 4.855 us | }
0) qemu-sy-4354 | 5.482 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.307 us | }
0) qemu-sy-4354 | 1.193 us | }
0) qemu-sy-4354 | 1.765 us | }
0) qemu-sy-4354 | 2.368 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.394 us | }
0) qemu-sy-4354 | 0.974 us | }
0) qemu-sy-4354 | 1.560 us | }
0) qemu-sy-4354 | 4.831 us | }
0) qemu-sy-4354 | 5.461 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.318 us | }
0) qemu-sy-4354 | 1.175 us | }
0) qemu-sy-4354 | 1.747 us | }
0) qemu-sy-4354 | 2.344 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 2.029 us | }
0) qemu-sy-4354 | 2.597 us | }
0) qemu-sy-4354 | 3.186 us | }
0) qemu-sy-4354 | 6.430 us | }
0) qemu-sy-4354 | 7.046 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.310 us | }
0) qemu-sy-4354 | 1.199 us | }
0) qemu-sy-4354 | 1.780 us | }
0) qemu-sy-4354 | 2.378 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.397 us | }
0) qemu-sy-4354 | 0.968 us | }
0) qemu-sy-4354 | 1.560 us | }
0) qemu-sy-4354 | 4.933 us | }
0) qemu-sy-4354 | 5.549 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | autoremove_wake_function() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.316 us | }
0) qemu-sy-4354 | 1.202 us | }
0) qemu-sy-4354 | 1.792 us | }
0) qemu-sy-4354 | 2.357 us | }
0) qemu-sy-4354 | 2.973 us | }
0) qemu-sy-4354 | 3.607 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.304 us | }
0) qemu-sy-4354 | 1.149 us | }
0) qemu-sy-4354 | 1.713 us | }
0) qemu-sy-4354 | 2.309 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.405 us | }
0) qemu-sy-4354 | 0.971 us | }
0) qemu-sy-4354 | 1.569 us | }
0) qemu-sy-4354 | 4.800 us | }
0) qemu-sy-4354 | 5.408 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.298 us | }
0) qemu-sy-4354 | 1.127 us | }
0) qemu-sy-4354 | 1.695 us | }
0) qemu-sy-4354 | 2.291 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.403 us | }
0) qemu-sy-4354 | 0.974 us | }
0) qemu-sy-4354 | 1.575 us | }
0) qemu-sy-4354 | 4.888 us | }
0) qemu-sy-4354 | 5.482 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | autoremove_wake_function() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.303 us | }
0) qemu-sy-4354 | 2.428 us | }
0) qemu-sy-4354 | 2.991 us | }
0) qemu-sy-4354 | 3.559 us | }
0) qemu-sy-4354 | 4.157 us | }
0) qemu-sy-4354 | 4.752 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.313 us | }
0) qemu-sy-4354 | 1.437 us | }
0) qemu-sy-4354 | 2.002 us | }
0) qemu-sy-4354 | 2.594 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.418 us | }
0) qemu-sy-4354 | 1.016 us | }
0) qemu-sy-4354 | 1.587 us | }
0) qemu-sy-4354 | 5.077 us | }
0) qemu-sy-4354 | 5.699 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.309 us | }
0) qemu-sy-4354 | 1.314 us | }
0) qemu-sy-4354 | 1.884 us | }
0) qemu-sy-4354 | 2.480 us | }
0) qemu-sy-4354 | | pollwake() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | 0.405 us | }
0) qemu-sy-4354 | 0.977 us | }
0) qemu-sy-4354 | 1.560 us | }
0) qemu-sy-4354 | 4.962 us | }
0) qemu-sy-4354 | 5.591 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | autoremove_wake_function() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.304 us | }
0) qemu-sy-4354 | 1.199 us | }
0) qemu-sy-4354 | 1.765 us | }
0) qemu-sy-4354 | 2.330 us | }
0) qemu-sy-4354 | 2.952 us | }
0) qemu-sy-4354 | 3.547 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | autoremove_wake_function() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.322 us | }
0) qemu-sy-4354 | 1.278 us | }
0) qemu-sy-4354 | 1.839 us | }
0) qemu-sy-4354 | 2.402 us | }
0) qemu-sy-4354 | 3.032 us | }
0) qemu-sy-4354 | 3.658 us | }
0) qemu-sy-4354 | | __wake_up() {
0) qemu-sy-4354 | | __wake_up_common() {
0) qemu-sy-4354 | | autoremove_wake_function() {
0) qemu-sy-4354 | | default_wake_function() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.303 us | }
0) qemu-sy-4354 | 1.208 us | }
0) qemu-sy-4354 | 1.759 us | }
0) qemu-sy-4354 | 2.341 us | }
0) qemu-sy-4354 | 2.949 us | }
0) qemu-sy-4354 | 3.556 us | }
0) qemu-sy-4354 | | scheduler_tick() {
0) qemu-sy-4354 | | sched_slice() {
0) qemu-sy-4354 | 0.342 us | }
0) qemu-sy-4354 | 3.222 us | }
0) qemu-sy-4354 | | wake_up_process() {
0) qemu-sy-4354 | | try_to_wake_up() {
0) qemu-sy-4354 | | check_preempt_wakeup() {
0) qemu-sy-4354 | 0.343 us | }
0) qemu-sy-4354 | 1.331 us | }
0) qemu-sy-4354 | 1.915 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_from_vapic() {
0) qemu-sy-4354 | 0.294 us | }
0) qemu-sy-4354 | | kvm_handle_exit() {
0) qemu-sy-4354 | 0.457 us | }
0) qemu-sy-4354 | | kvm_resched() {
0) qemu-sy-4354 | | _cond_resched() {
0) qemu-sy-4354 | | __cond_resched() {
0) qemu-sy-4354 | | schedule() {
0) qemu-sy-4354 | | wakeup_preempt_entity() {
0) qemu-sy-4354 | 0.294 us | }
0) qemu-sy-4354 | | kvm_sched_out() {
0) qemu-sy-4354 | | kvm_arch_vcpu_put() {
0) qemu-sy-4354 | 0.592 us | }
0) qemu-sy-4354 | 1.218 us | }
0) qemu-sy-4354 => kipmi0-496
0) qemu-sy-4213 => qemu-sy-4354
0) qemu-sy-4354 | | kvm_sched_in() {
0) qemu-sy-4354 | | kvm_arch_vcpu_load() {
0) qemu-sy-4354 | | kvm_write_guest_time() {
0) qemu-sy-4354 | 0.298 us | }
0) qemu-sy-4354 | 1.070 us | }
0) qemu-sy-4354 | 1.665 us | }
0) qemu-sy-4354 | ! 9172.159 us | }
0) qemu-sy-4354 | ! 9172.793 us | }
0) qemu-sy-4354 | ! 9173.422 us | }
0) qemu-sy-4354 | ! 9174.032 us | }
0) qemu-sy-4354 | | kvm_inject_pending_timer_irqs() {
0) qemu-sy-4354 | | kvm_inject_apic_timer_irqs() {
0) qemu-sy-4354 | | kvm_vcpu_kick() {
0) qemu-sy-4354 | 0.291 us | }
0) qemu-sy-4354 | 1.151 us | }
0) qemu-sy-4354 | | kvm_inject_pit_timer_irqs() {
0) qemu-sy-4354 | 0.352 us | }
0) qemu-sy-4354 | 2.429 us | }
0) qemu-sy-4354 | | kvm_lapic_enabled() {
0) qemu-sy-4354 | 0.291 us | }
0) qemu-sy-4354 | | kvm_lapic_find_highest_irr() {
0) qemu-sy-4354 | 0.312 us | }
0) qemu-sy-4354 | | kvm_lapic_get_cr8() {
0) qemu-sy-4354 | 0.298 us | }
0) qemu-sy-4354 | | kvm_cpu_has_interrupt() {
0) qemu-sy-4354 | | kvm_apic_has_interrupt() {
0) qemu-sy-4354 | 0.385 us | }
0) qemu-sy-4354 | 0.980 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_to_vapic() {
0) qemu-sy-4354 | 0.295 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_from_vapic() {
0) qemu-sy-4354 | 0.331 us | }
0) qemu-sy-4354 | | kvm_handle_exit() {
0) qemu-sy-4354 | 0.568 us | }
0) qemu-sy-4354 | | kvm_inject_pending_timer_irqs() {
0) qemu-sy-4354 | | kvm_inject_apic_timer_irqs() {
0) qemu-sy-4354 | | kvm_vcpu_kick() {
0) qemu-sy-4354 | 0.295 us | }
0) qemu-sy-4354 | 0.959 us | }
0) qemu-sy-4354 | | kvm_inject_pit_timer_irqs() {
0) qemu-sy-4354 | 0.313 us | }
0) qemu-sy-4354 | 2.170 us | }
0) qemu-sy-4354 | | kvm_lapic_enabled() {
0) qemu-sy-4354 | 0.310 us | }
0) qemu-sy-4354 | | kvm_lapic_find_highest_irr() {
0) qemu-sy-4354 | 0.295 us | }
0) qemu-sy-4354 | | kvm_lapic_get_cr8() {
0) qemu-sy-4354 | 0.295 us | }
0) qemu-sy-4354 | | kvm_cpu_has_interrupt() {
0) qemu-sy-4354 | | kvm_apic_has_interrupt() {
0) qemu-sy-4354 | 0.325 us | }
0) qemu-sy-4354 | 0.938 us | }
0) qemu-sy-4354 | | kvm_cpu_get_interrupt() {
0) qemu-sy-4354 | | kvm_get_apic_interrupt() {
0) qemu-sy-4354 | | kvm_apic_has_interrupt() {
0) qemu-sy-4354 | 0.322 us | }
0) qemu-sy-4354 | 0.944 us | }
0) qemu-sy-4354 | 1.542 us | }
0) qemu-sy-4354 | | kvm_timer_intr_post() {
0) qemu-sy-4354 | | kvm_apic_timer_intr_post() {
0) qemu-sy-4354 | 0.309 us | }
0) qemu-sy-4354 | 2.059 us | }
0) qemu-sy-4354 | | kvm_cpu_has_interrupt() {
0) qemu-sy-4354 | | kvm_apic_has_interrupt() {
0) qemu-sy-4354 | 0.340 us | }
0) qemu-sy-4354 | | kvm_apic_accept_pic_intr() {
0) qemu-sy-4354 | 0.313 us | }
0) qemu-sy-4354 | 1.560 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_to_vapic() {
0) qemu-sy-4354 | 0.298 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_from_vapic() {
0) qemu-sy-4354 | 0.319 us | }
0) qemu-sy-4354 | | kvm_handle_exit() {
0) qemu-sy-4354 | | kvm_mmu_page_fault() {
0) qemu-sy-4354 | | kvm_read_guest() {
0) qemu-sy-4354 | | kvm_read_guest_page() {
0) qemu-sy-4354 | 0.764 us | }
0) qemu-sy-4354 | 1.377 us | }
0) qemu-sy-4354 | | kvm_read_guest() {
0) qemu-sy-4354 | | kvm_read_guest_page() {
0) qemu-sy-4354 | 0.499 us | }
0) qemu-sy-4354 | 1.088 us | }
0) qemu-sy-4354 | | kvm_release_pfn_clean() {
0) qemu-sy-4354 | 0.349 us | }
0) qemu-sy-4354 | | kvm_read_guest() {
0) qemu-sy-4354 | | kvm_read_guest_page() {
0) qemu-sy-4354 | 0.451 us | }
0) qemu-sy-4354 | 1.046 us | }
0) qemu-sy-4354 | | kvm_read_guest() {
0) qemu-sy-4354 | | kvm_read_guest_page() {
0) qemu-sy-4354 | 0.361 us | }
0) qemu-sy-4354 | 0.956 us | }
0) qemu-sy-4354 | | kvm_read_guest() {
0) qemu-sy-4354 | | kvm_read_guest_page() {
0) qemu-sy-4354 | 0.381 us | }
0) qemu-sy-4354 | 0.974 us | }
0) qemu-sy-4354 | | kvm_read_guest() {
0) qemu-sy-4354 | | kvm_read_guest_page() {
0) qemu-sy-4354 | 0.345 us | }
0) qemu-sy-4354 | 0.959 us | }
0) qemu-sy-4354 | | kvm_read_guest() {
0) qemu-sy-4354 | | kvm_read_guest_page() {
0) qemu-sy-4354 | 0.364 us | }
0) qemu-sy-4354 | 0.965 us | }
0) qemu-sy-4354 | | kvm_ioapic_update_eoi() {
0) qemu-sy-4354 | 0.358 us | }
0) qemu-sy-4354 | + 13.782 us | }
0) qemu-sy-4354 | + 14.681 us | }
0) qemu-sy-4354 | | kvm_inject_pending_timer_irqs() {
0) qemu-sy-4354 | | kvm_inject_apic_timer_irqs() {
0) qemu-sy-4354 | | kvm_vcpu_kick() {
0) qemu-sy-4354 | 0.291 us | }
0) qemu-sy-4354 | 0.953 us | }
0) qemu-sy-4354 | | kvm_inject_pit_timer_irqs() {
0) qemu-sy-4354 | 0.304 us | }
0) qemu-sy-4354 | 2.150 us | }
0) qemu-sy-4354 | | kvm_lapic_enabled() {
0) qemu-sy-4354 | 0.304 us | }
0) qemu-sy-4354 | | kvm_lapic_find_highest_irr() {
0) qemu-sy-4354 | 0.295 us | }
0) qemu-sy-4354 | | kvm_lapic_get_cr8() {
0) qemu-sy-4354 | 0.309 us | }
0) qemu-sy-4354 | | kvm_cpu_has_interrupt() {
0) qemu-sy-4354 | | kvm_apic_has_interrupt() {
0) qemu-sy-4354 | 0.315 us | }
0) qemu-sy-4354 | 0.914 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_to_vapic() {
0) qemu-sy-4354 | 0.297 us | }
0) qemu-sy-4354 | | kvm_lapic_sync_from_vapic() {
0) qemu-sy-4354 | 0.318 us | }
0) qemu-sy-4354 | | kvm_handle_exit() {
0) qemu-sy-4354 | | kvm_emulate_pio() {
0) qemu-sy-4354 | | kvm_io_bus_find_dev() {
0) qemu-sy-4354 | 0.406 us | }
0) qemu-sy-4354 | 1.115 us | }
0) qemu-sy-4354 | 2.026 us | }
0) qemu-sy-4354 | | kvm_get_cr8() {
0) qemu-sy-4354 | | kvm_lapic_get_cr8() {
0) qemu-sy-4354 | 0.292 us | }
0) qemu-sy-4354 | 2.257 us | }
0) qemu-sy-4354 | | kvm_arch_vcpu_put() {
0) qemu-sy-4354 | 0.574 us | }
0) qemu-sy-4354 | ! 250406.2 us | }
0) qemu-sy-4354 | ! 250407.0 us | }
There's 2 preemptions in there, accounting for perhaps 15ms
Then there's about 20 __wake_up()s in there (wth do those come from?)
accounting for 5ms each, totaling 100ms.
There's a scheduler_tick() in there but no IRQ entry ?!
All in all its very hard to get to the total of 250ms.
I suspect __vcpu_run() and vcpu_enter_guest() get inlined, and we might
just be looking at time spend in the guest... bit hard to tell for me,
as this is the first time ever I looked at all this kvm code.
Is there a way to add a wall-time column to this output so that we can
see where the time goes?
Another something nice would be to have ctx switches like:
foo-1 => bar-2 ran: ${time foo spend on the cpu} since: ${time bar spend away from the cpu}
I'll poke me a little at this function graph tracer thingy to see if I
can do that.
On Thu, 22 Jan 2009, Andrew S. Johnson wrote:
> These are almost the same when running "find /sys/bus/gameport -ls":
>
> Kernel 2.6.28.1 (missing one line):
>
> 9575 0 drwxr-xr-x 4 root root 0 Jan 22 18:13 /sys/bus/gameport
> 9576 0 --w------- 1 root root 4096 Jan 22 18:16 /sys/bus/gameport/uevent
> 9577 0 drwxr-xr-x 2 root root 0 Jan 22 18:13 /sys/bus/gameport/devices
> 9783 0 lrwxrwxrwx 1 root root 0 Jan 22 18:13 /sys/bus/gameport/devices/gameport0 -> ../../../devices/pnp0/00:07/gameport0
> 9578 0 drwxr-xr-x 3 root root 0 Jan 22 18:15 /sys/bus/gameport/drivers
> 12186 0 drwxr-xr-x 2 root root 0 Jan 22 18:15 /sys/bus/gameport/drivers/tmdc
> 12187 0 lrwxrwxrwx 1 root root 0 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/module -> ../../../../module/tmdc
> 12190 0 --w------- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/uevent
> 12191 0 -r--r--r-- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/description
> 12192 0 --w------- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/unbind
> 12193 0 --w------- 1 root root 4096 Jan 22 18:17 /sys/bus/gameport/drivers/tmdc/bind
> 9579 0 --w------- 1 root root 4096 Jan 22 18:16 /sys/bus/gameport/drivers_probe
> 9580 0 -rw-r--r-- 1 root root 4096 Jan 22 18:16 /sys/bus/gameport/drivers_autoprobe
>
> Kernel 2.6.27.9 has one more line (see 12040):
>
> 9489 0 drwxr-xr-x 4 root root 0 Jan 22 18:23 /sys/bus/gameport
> 9490 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/uevent
> 9491 0 drwxr-xr-x 2 root root 0 Jan 22 18:23 /sys/bus/gameport/devices
> 9774 0 lrwxrwxrwx 1 root root 0 Jan 22 18:23 /sys/bus/gameport/devices/gameport0 -> ../../../devices/pnp0/00:07/gameport0
> 9492 0 drwxr-xr-x 3 root root 0 Jan 22 18:23 /sys/bus/gameport/drivers
> 12039 0 drwxr-xr-x 2 root root 0 Jan 22 18:23 /sys/bus/gameport/drivers/tmdc
> 12040 0 lrwxrwxrwx 1 root root 0 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/gameport0 -> ../../../../devices/pnp0/00:07/gameport0
> 12078 0 lrwxrwxrwx 1 root root 0 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/module -> ../../../../module/tmdc
> 12081 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/uevent
> 12082 0 -r--r--r-- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/description
> 12083 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/unbind
> 12084 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers/tmdc/bind
> 9493 0 --w------- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers_probe
> 9494 0 -rw-r--r-- 1 root root 4096 Jan 22 18:53 /sys/bus/gameport/drivers_autoprobe
>
> If there is anything else I can provide, please let me know.
Could you please verify whether reverting 6902c0bead4c fixes the issue for
you?
--
Jiri Kosina
SUSE Labs
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it
> still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12396
> Subject : hwinfo problem since 2.6.28
> Submitter : Beschorner Daniel <[email protected]>
> Date : 2009-01-06 8:53 (14 days old)
> References : http://marc.info/?l=linux-kernel&m=123123277800835&w=4
> Handled-By : Suresh Siddha <[email protected]>
> Patch : http://marc.info/?l=linux-kernel&m=123154005127497&w=4
The bug is still present in 2.6.28.2.
Daniel
On Mon, 2009-01-26 at 12:35 +0100, Peter Zijlstra wrote:
>
> Another something nice would be to have ctx switches like:
>
> foo-1 => bar-2 ran: ${time foo spend on the cpu} since: ${time bar
> spend away from the cpu}
Steve, Frederic, how's this?
(compile tested only)
---
include/linux/ftrace.h | 5 ++
kernel/sched_fair.c | 1 -
kernel/trace/Kconfig | 1 +
kernel/trace/trace.c | 51 +++++++++++++++++++
kernel/trace/trace.h | 10 ++++
kernel/trace/trace_functions_graph.c | 88 ++++++++++++++-------------------
6 files changed, 104 insertions(+), 52 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9f7880d..411b027 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -381,6 +381,11 @@ struct ftrace_graph_ret {
int depth;
};
+struct ftrace_graph_switch {
+ pid_t prev, next;
+ u64 ran, since;
+};
+
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
/*
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index f34cf42..fa477ac 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -530,7 +530,6 @@ update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
schedstat_set(se->wait_count, se->wait_count + 1);
schedstat_set(se->wait_sum, se->wait_sum +
rq_of(cfs_rq)->clock - se->wait_start);
- schedstat_set(se->wait_start, 0);
}
static inline void
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index dde1d46..7aa1c13 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -67,6 +67,7 @@ config FUNCTION_GRAPH_TRACER
bool "Kernel Function Graph Tracer"
depends on HAVE_FUNCTION_GRAPH_TRACER
depends on FUNCTION_TRACER
+ select SCHEDSTATS
default y
help
Enable the kernel to trace a function at both its return
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2129ab9..380a334 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -31,6 +31,7 @@
#include <linux/fs.h>
#include <linux/kprobes.h>
#include <linux/writeback.h>
+#include <linux/sched.h>
#include <linux/stacktrace.h>
#include <linux/ring_buffer.h>
@@ -820,6 +821,35 @@ static void __trace_graph_return(struct trace_array *tr,
entry->ret = *trace;
ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
}
+
+static void __trace_graph_switch(struct trace_array *tr,
+ struct trace_array_cpu *data,
+ unsigned long flags, int pc,
+ struct task_struct *prev,
+ struct task_struct *next)
+{
+ struct ring_buffer_event *event;
+ struct ftrace_graph_switch_entry *entry;
+ unsigned long irq_flags;
+
+ if (unlikely(local_read(&__get_cpu_var(ftrace_cpu_disabled))))
+ return;
+
+ event = ring_buffer_lock_reserve(global_trace.buffer, sizeof(*entry),
+ &irq_flags);
+ if (!event)
+ return;
+ entry = ring_buffer_event_data(event);
+ tracing_generic_entry_update(&entry->ent, flags, pc);
+ entry->ent.type = TRACE_GRAPH_SWITCH;
+ entry->ctx.prev = prev->pid;
+ entry->ctx.next = next->pid;
+ entry->ctx.ran = prev->se.sum_exec_runtime -
+ prev->se.prev_sum_exec_runtime;
+ entry->ctx.since = next->se.exec_start - next->se.wait_start;
+
+ ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
+}
#endif
void
@@ -1097,6 +1127,27 @@ void trace_graph_return(struct ftrace_graph_ret *trace)
atomic_dec(&data->disabled);
local_irq_restore(flags);
}
+
+void trace_graph_switch(struct task_struct *prev, struct task_struct *next)
+{
+ struct trace_array *tr = &global_trace;
+ struct trace_array_cpu *data;
+ unsigned long flags;
+ long disabled;
+ int cpu;
+ int pc;
+
+ local_irq_save(flags);
+ cpu = raw_smp_processor_id();
+ data = tr->data[cpu];
+ disabled = atomic_inc_return(&data->disabled);
+ if (likely(disabled == 1)) {
+ pc = preempt_count();
+ __trace_graph_switch(tr, data, flags, pc, prev, next);
+ }
+ atomic_dec(&data->disabled);
+ local_irq_restore(flags);
+}
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
enum trace_file_type {
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index b96037d..781fbce 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -27,6 +27,7 @@ enum trace_type {
TRACE_BOOT_RET,
TRACE_GRAPH_RET,
TRACE_GRAPH_ENT,
+ TRACE_GRAPH_SWITCH,
TRACE_USER_STACK,
TRACE_HW_BRANCHES,
TRACE_KMEM_ALLOC,
@@ -71,6 +72,12 @@ struct ftrace_graph_ret_entry {
struct trace_entry ent;
struct ftrace_graph_ret ret;
};
+
+struct ftrace_graph_switch_entry {
+ struct trace_entry ent;
+ struct ftrace_graph_switch ctx;
+};
+
extern struct tracer boot_tracer;
/*
@@ -295,6 +302,8 @@ extern void __ftrace_bad_type(void);
TRACE_GRAPH_ENT); \
IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry, \
TRACE_GRAPH_RET); \
+ IF_ASSIGN(var, ent, struct ftrace_graph_switch_entry, \
+ TRACE_GRAPH_SWITCH); \
IF_ASSIGN(var, ent, struct hw_branch_entry, TRACE_HW_BRANCHES);\
IF_ASSIGN(var, ent, struct trace_power, TRACE_POWER); \
IF_ASSIGN(var, ent, struct kmemtrace_alloc_entry, \
@@ -438,6 +447,7 @@ void trace_function(struct trace_array *tr,
void trace_graph_return(struct ftrace_graph_ret *trace);
int trace_graph_entry(struct ftrace_graph_ent *trace);
+void trace_graph_switch(struct task_struct *prev, struct task_struct *next);
void tracing_start_cmdline_record(void);
void tracing_stop_cmdline_record(void);
diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index 66fc7b8..cf6494b 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -10,6 +10,7 @@
#include <linux/uaccess.h>
#include <linux/ftrace.h>
#include <linux/fs.h>
+#include <trace/sched.h>
#include "trace.h"
#include "trace_output.h"
@@ -158,28 +159,13 @@ print_graph_proc(struct trace_seq *s, pid_t pid)
return TRACE_TYPE_HANDLED;
}
-
-/* If the pid changed since the last trace, output this event */
static enum print_line_t
-verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
+print_graph_switch(struct ftrace_graph_switch_entry *field, struct trace_seq *s,
+ struct trace_iterator *iter)
{
- pid_t prev_pid;
- pid_t *last_pid;
+ int cpu = iter->cpu;
int ret;
- if (!last_pids_cpu)
- return TRACE_TYPE_HANDLED;
-
- last_pid = per_cpu_ptr(last_pids_cpu, cpu);
-
- if (*last_pid == pid)
- return TRACE_TYPE_HANDLED;
-
- prev_pid = *last_pid;
- *last_pid = pid;
-
- if (prev_pid == -1)
- return TRACE_TYPE_HANDLED;
/*
* Context-switch trace line:
@@ -197,7 +183,7 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
if (ret == TRACE_TYPE_PARTIAL_LINE)
TRACE_TYPE_PARTIAL_LINE;
- ret = print_graph_proc(s, prev_pid);
+ ret = print_graph_proc(s, field->ctx.prev);
if (ret == TRACE_TYPE_PARTIAL_LINE)
TRACE_TYPE_PARTIAL_LINE;
@@ -205,16 +191,21 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
if (!ret)
TRACE_TYPE_PARTIAL_LINE;
- ret = print_graph_proc(s, pid);
+ ret = print_graph_proc(s, field->ctx.next);
if (ret == TRACE_TYPE_PARTIAL_LINE)
TRACE_TYPE_PARTIAL_LINE;
+ ret = trace_seq_printf(s, " ran: %Lu, since: %Lu",
+ field->ctx.ran, field->ctx.since);
+ if (!ret)
+ TRACE_TYPE_PARTIAL_LINE;
+
ret = trace_seq_printf(s,
"\n ------------------------------------------\n\n");
if (!ret)
TRACE_TYPE_PARTIAL_LINE;
- return ret;
+ return TRACE_TYPE_HANDLED;
}
static bool
@@ -471,14 +462,9 @@ print_graph_entry(struct ftrace_graph_ent_entry *field, struct trace_seq *s,
{
int ret;
int cpu = iter->cpu;
- pid_t *last_entry = iter->private;
struct trace_entry *ent = iter->ent;
struct ftrace_graph_ent *call = &field->graph_ent;
- /* Pid */
- if (verif_pid(s, ent->pid, cpu, last_entry) == TRACE_TYPE_PARTIAL_LINE)
- return TRACE_TYPE_PARTIAL_LINE;
-
/* Interrupt */
ret = print_graph_irq(s, call->func, TRACE_GRAPH_ENT, cpu, ent->pid);
if (ret == TRACE_TYPE_PARTIAL_LINE)
@@ -523,12 +509,8 @@ print_graph_return(struct ftrace_graph_ret *trace, struct trace_seq *s,
int i;
int ret;
int cpu = iter->cpu;
- pid_t *last_pid = iter->private;
unsigned long long duration = trace->rettime - trace->calltime;
- /* Pid */
- if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
- return TRACE_TYPE_PARTIAL_LINE;
/* Absolute time */
if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
@@ -600,7 +582,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
int i;
int ret;
int cpu = iter->cpu;
- pid_t *last_pid = iter->private;
/* Absolute time */
if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
@@ -609,10 +590,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
return TRACE_TYPE_PARTIAL_LINE;
}
- /* Pid */
- if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
- return TRACE_TYPE_PARTIAL_LINE;
-
/* Cpu */
if (tracer_flags.val & TRACE_GRAPH_PRINT_CPU) {
ret = print_graph_cpu(s, cpu);
@@ -677,6 +654,11 @@ print_graph_function(struct trace_iterator *iter)
struct trace_entry *entry = iter->ent;
switch (entry->type) {
+ case TRACE_GRAPH_SWITCH: {
+ struct ftrace_graph_switch_entry *field;
+ trace_assign_type(field, entry);
+ return print_graph_switch(field, s, iter);
+ }
case TRACE_GRAPH_ENT: {
struct ftrace_graph_ent_entry *field;
trace_assign_type(field, entry);
@@ -724,34 +706,38 @@ static void print_graph_headers(struct seq_file *s)
seq_printf(s, " | | | |\n");
}
-static void graph_trace_open(struct trace_iterator *iter)
+static void probe_sched_switch(struct rq *rq,
+ struct task_struct *prev,
+ struct task_struct *next)
{
- /* pid on the last trace processed */
- pid_t *last_pid = alloc_percpu(pid_t);
- int cpu;
+ trace_graph_switch(prev, next);
+}
- if (!last_pid)
- pr_warning("function graph tracer: not enough memory\n");
- else
- for_each_possible_cpu(cpu) {
- pid_t *pid = per_cpu_ptr(last_pid, cpu);
- *pid = -1;
- }
+static DEFINE_MUTEX(graph_trace_mutex);
+static int graph_trace_ref;
- iter->private = last_pid;
+static void graph_trace_start(struct trace_array *tr)
+{
+ mutex_lock(&graph_trace_mutex);
+ if (!(graph_trace_ref++))
+ register_trace_sched_switch(probe_sched_switch);
+ mutex_unlock(&graph_trace_mutex);
}
-static void graph_trace_close(struct trace_iterator *iter)
+static void graph_trace_stop(struct trace_array *tr)
{
- percpu_free(iter->private);
+ mutex_lock(&graph_trace_mutex);
+ if (!(--graph_trace_ref))
+ unregister_trace_sched_switch(probe_sched_switch);
+ mutex_unlock(&graph_trace_mutex);
}
static struct tracer graph_trace __read_mostly = {
.name = "function_graph",
- .open = graph_trace_open,
- .close = graph_trace_close,
.init = graph_trace_init,
.reset = graph_trace_reset,
+ .start = graph_trace_start,
+ .stop = graph_trace_stop,
.print_line = print_graph_function,
.print_header = print_graph_headers,
.flags = &tracer_flags,
* Peter Zijlstra <[email protected]> wrote:
> Is there a way to add a wall-time column to this output so that we can
> see where the time goes?
yes, on tip/master:
http://people.redhat.com/mingo/tip.git/README
do something like this:
echo funcgraph-abstime > /debug/tracing/trace_options
when the function-graph plugin is active. This will activate the absolute
timestamps column in the trace output.
> Another something nice would be to have ctx switches like:
>
> foo-1 => bar-2 ran: ${time foo spend on the cpu} since: ${time bar spend away from the cpu}
>
> I'll poke me a little at this function graph tracer thingy to see if I
> can do that.
indeed, tracking the 'scheduling atom duration' would be very nice.
Ingo
2009/1/26 Peter Zijlstra <[email protected]>:
> On Mon, 2009-01-26 at 12:35 +0100, Peter Zijlstra wrote:
>>
>> Another something nice would be to have ctx switches like:
>>
>> foo-1 => bar-2 ran: ${time foo spend on the cpu} since: ${time bar
>> spend away from the cpu}
>
> Steve, Frederic, how's this?
That looks nice after a quick sight. Using the ctx switch probe to
trace the context switches is,
of course, more natural :-)
And we have now these useful time run/wait bits.
Thanks!
> (compile tested only)
>
> ---
> include/linux/ftrace.h | 5 ++
> kernel/sched_fair.c | 1 -
> kernel/trace/Kconfig | 1 +
> kernel/trace/trace.c | 51 +++++++++++++++++++
> kernel/trace/trace.h | 10 ++++
> kernel/trace/trace_functions_graph.c | 88 ++++++++++++++-------------------
> 6 files changed, 104 insertions(+), 52 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 9f7880d..411b027 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -381,6 +381,11 @@ struct ftrace_graph_ret {
> int depth;
> };
>
> +struct ftrace_graph_switch {
> + pid_t prev, next;
> + u64 ran, since;
> +};
> +
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>
> /*
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index f34cf42..fa477ac 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -530,7 +530,6 @@ update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
> schedstat_set(se->wait_count, se->wait_count + 1);
> schedstat_set(se->wait_sum, se->wait_sum +
> rq_of(cfs_rq)->clock - se->wait_start);
> - schedstat_set(se->wait_start, 0);
> }
>
> static inline void
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index dde1d46..7aa1c13 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -67,6 +67,7 @@ config FUNCTION_GRAPH_TRACER
> bool "Kernel Function Graph Tracer"
> depends on HAVE_FUNCTION_GRAPH_TRACER
> depends on FUNCTION_TRACER
> + select SCHEDSTATS
> default y
> help
> Enable the kernel to trace a function at both its return
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 2129ab9..380a334 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -31,6 +31,7 @@
> #include <linux/fs.h>
> #include <linux/kprobes.h>
> #include <linux/writeback.h>
> +#include <linux/sched.h>
>
> #include <linux/stacktrace.h>
> #include <linux/ring_buffer.h>
> @@ -820,6 +821,35 @@ static void __trace_graph_return(struct trace_array *tr,
> entry->ret = *trace;
> ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
> }
> +
> +static void __trace_graph_switch(struct trace_array *tr,
> + struct trace_array_cpu *data,
> + unsigned long flags, int pc,
> + struct task_struct *prev,
> + struct task_struct *next)
> +{
> + struct ring_buffer_event *event;
> + struct ftrace_graph_switch_entry *entry;
> + unsigned long irq_flags;
> +
> + if (unlikely(local_read(&__get_cpu_var(ftrace_cpu_disabled))))
> + return;
> +
> + event = ring_buffer_lock_reserve(global_trace.buffer, sizeof(*entry),
> + &irq_flags);
> + if (!event)
> + return;
> + entry = ring_buffer_event_data(event);
> + tracing_generic_entry_update(&entry->ent, flags, pc);
> + entry->ent.type = TRACE_GRAPH_SWITCH;
> + entry->ctx.prev = prev->pid;
> + entry->ctx.next = next->pid;
> + entry->ctx.ran = prev->se.sum_exec_runtime -
> + prev->se.prev_sum_exec_runtime;
> + entry->ctx.since = next->se.exec_start - next->se.wait_start;
> +
> + ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
> +}
> #endif
>
> void
> @@ -1097,6 +1127,27 @@ void trace_graph_return(struct ftrace_graph_ret *trace)
> atomic_dec(&data->disabled);
> local_irq_restore(flags);
> }
> +
> +void trace_graph_switch(struct task_struct *prev, struct task_struct *next)
> +{
> + struct trace_array *tr = &global_trace;
> + struct trace_array_cpu *data;
> + unsigned long flags;
> + long disabled;
> + int cpu;
> + int pc;
> +
> + local_irq_save(flags);
> + cpu = raw_smp_processor_id();
> + data = tr->data[cpu];
> + disabled = atomic_inc_return(&data->disabled);
> + if (likely(disabled == 1)) {
> + pc = preempt_count();
> + __trace_graph_switch(tr, data, flags, pc, prev, next);
> + }
> + atomic_dec(&data->disabled);
> + local_irq_restore(flags);
> +}
> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>
> enum trace_file_type {
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index b96037d..781fbce 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -27,6 +27,7 @@ enum trace_type {
> TRACE_BOOT_RET,
> TRACE_GRAPH_RET,
> TRACE_GRAPH_ENT,
> + TRACE_GRAPH_SWITCH,
> TRACE_USER_STACK,
> TRACE_HW_BRANCHES,
> TRACE_KMEM_ALLOC,
> @@ -71,6 +72,12 @@ struct ftrace_graph_ret_entry {
> struct trace_entry ent;
> struct ftrace_graph_ret ret;
> };
> +
> +struct ftrace_graph_switch_entry {
> + struct trace_entry ent;
> + struct ftrace_graph_switch ctx;
> +};
> +
> extern struct tracer boot_tracer;
>
> /*
> @@ -295,6 +302,8 @@ extern void __ftrace_bad_type(void);
> TRACE_GRAPH_ENT); \
> IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry, \
> TRACE_GRAPH_RET); \
> + IF_ASSIGN(var, ent, struct ftrace_graph_switch_entry, \
> + TRACE_GRAPH_SWITCH); \
> IF_ASSIGN(var, ent, struct hw_branch_entry, TRACE_HW_BRANCHES);\
> IF_ASSIGN(var, ent, struct trace_power, TRACE_POWER); \
> IF_ASSIGN(var, ent, struct kmemtrace_alloc_entry, \
> @@ -438,6 +447,7 @@ void trace_function(struct trace_array *tr,
>
> void trace_graph_return(struct ftrace_graph_ret *trace);
> int trace_graph_entry(struct ftrace_graph_ent *trace);
> +void trace_graph_switch(struct task_struct *prev, struct task_struct *next);
>
> void tracing_start_cmdline_record(void);
> void tracing_stop_cmdline_record(void);
> diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
> index 66fc7b8..cf6494b 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -10,6 +10,7 @@
> #include <linux/uaccess.h>
> #include <linux/ftrace.h>
> #include <linux/fs.h>
> +#include <trace/sched.h>
>
> #include "trace.h"
> #include "trace_output.h"
> @@ -158,28 +159,13 @@ print_graph_proc(struct trace_seq *s, pid_t pid)
> return TRACE_TYPE_HANDLED;
> }
>
> -
> -/* If the pid changed since the last trace, output this event */
> static enum print_line_t
> -verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> +print_graph_switch(struct ftrace_graph_switch_entry *field, struct trace_seq *s,
> + struct trace_iterator *iter)
> {
> - pid_t prev_pid;
> - pid_t *last_pid;
> + int cpu = iter->cpu;
> int ret;
>
> - if (!last_pids_cpu)
> - return TRACE_TYPE_HANDLED;
> -
> - last_pid = per_cpu_ptr(last_pids_cpu, cpu);
> -
> - if (*last_pid == pid)
> - return TRACE_TYPE_HANDLED;
> -
> - prev_pid = *last_pid;
> - *last_pid = pid;
> -
> - if (prev_pid == -1)
> - return TRACE_TYPE_HANDLED;
> /*
> * Context-switch trace line:
>
> @@ -197,7 +183,7 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> - ret = print_graph_proc(s, prev_pid);
> + ret = print_graph_proc(s, field->ctx.prev);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> @@ -205,16 +191,21 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> if (!ret)
> TRACE_TYPE_PARTIAL_LINE;
>
> - ret = print_graph_proc(s, pid);
> + ret = print_graph_proc(s, field->ctx.next);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> + ret = trace_seq_printf(s, " ran: %Lu, since: %Lu",
> + field->ctx.ran, field->ctx.since);
> + if (!ret)
> + TRACE_TYPE_PARTIAL_LINE;
> +
> ret = trace_seq_printf(s,
> "\n ------------------------------------------\n\n");
> if (!ret)
> TRACE_TYPE_PARTIAL_LINE;
>
> - return ret;
> + return TRACE_TYPE_HANDLED;
> }
>
> static bool
> @@ -471,14 +462,9 @@ print_graph_entry(struct ftrace_graph_ent_entry *field, struct trace_seq *s,
> {
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_entry = iter->private;
> struct trace_entry *ent = iter->ent;
> struct ftrace_graph_ent *call = &field->graph_ent;
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_entry) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
> -
> /* Interrupt */
> ret = print_graph_irq(s, call->func, TRACE_GRAPH_ENT, cpu, ent->pid);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> @@ -523,12 +509,8 @@ print_graph_return(struct ftrace_graph_ret *trace, struct trace_seq *s,
> int i;
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_pid = iter->private;
> unsigned long long duration = trace->rettime - trace->calltime;
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
>
> /* Absolute time */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
> @@ -600,7 +582,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
> int i;
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_pid = iter->private;
>
> /* Absolute time */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
> @@ -609,10 +590,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
> return TRACE_TYPE_PARTIAL_LINE;
> }
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
> -
> /* Cpu */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_CPU) {
> ret = print_graph_cpu(s, cpu);
> @@ -677,6 +654,11 @@ print_graph_function(struct trace_iterator *iter)
> struct trace_entry *entry = iter->ent;
>
> switch (entry->type) {
> + case TRACE_GRAPH_SWITCH: {
> + struct ftrace_graph_switch_entry *field;
> + trace_assign_type(field, entry);
> + return print_graph_switch(field, s, iter);
> + }
> case TRACE_GRAPH_ENT: {
> struct ftrace_graph_ent_entry *field;
> trace_assign_type(field, entry);
> @@ -724,34 +706,38 @@ static void print_graph_headers(struct seq_file *s)
> seq_printf(s, " | | | |\n");
> }
>
> -static void graph_trace_open(struct trace_iterator *iter)
> +static void probe_sched_switch(struct rq *rq,
> + struct task_struct *prev,
> + struct task_struct *next)
> {
> - /* pid on the last trace processed */
> - pid_t *last_pid = alloc_percpu(pid_t);
> - int cpu;
> + trace_graph_switch(prev, next);
> +}
>
> - if (!last_pid)
> - pr_warning("function graph tracer: not enough memory\n");
> - else
> - for_each_possible_cpu(cpu) {
> - pid_t *pid = per_cpu_ptr(last_pid, cpu);
> - *pid = -1;
> - }
> +static DEFINE_MUTEX(graph_trace_mutex);
> +static int graph_trace_ref;
>
> - iter->private = last_pid;
> +static void graph_trace_start(struct trace_array *tr)
> +{
> + mutex_lock(&graph_trace_mutex);
> + if (!(graph_trace_ref++))
> + register_trace_sched_switch(probe_sched_switch);
> + mutex_unlock(&graph_trace_mutex);
> }
>
> -static void graph_trace_close(struct trace_iterator *iter)
> +static void graph_trace_stop(struct trace_array *tr)
> {
> - percpu_free(iter->private);
> + mutex_lock(&graph_trace_mutex);
> + if (!(--graph_trace_ref))
> + unregister_trace_sched_switch(probe_sched_switch);
> + mutex_unlock(&graph_trace_mutex);
> }
>
> static struct tracer graph_trace __read_mostly = {
> .name = "function_graph",
> - .open = graph_trace_open,
> - .close = graph_trace_close,
> .init = graph_trace_init,
> .reset = graph_trace_reset,
> + .start = graph_trace_start,
> + .stop = graph_trace_stop,
> .print_line = print_graph_function,
> .print_header = print_graph_headers,
> .flags = &tracer_flags,
>
>
>
On Mon, 26 Jan 2009, Peter Zijlstra wrote:
> On Mon, 2009-01-26 at 12:35 +0100, Peter Zijlstra wrote:
> >
> > Another something nice would be to have ctx switches like:
> >
> > foo-1 => bar-2 ran: ${time foo spend on the cpu} since: ${time bar
> > spend away from the cpu}
>
> Steve, Frederic, how's this?
>
> (compile tested only)
>
> ---
> include/linux/ftrace.h | 5 ++
> kernel/sched_fair.c | 1 -
> kernel/trace/Kconfig | 1 +
> kernel/trace/trace.c | 51 +++++++++++++++++++
> kernel/trace/trace.h | 10 ++++
> kernel/trace/trace_functions_graph.c | 88 ++++++++++++++-------------------
> 6 files changed, 104 insertions(+), 52 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 9f7880d..411b027 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -381,6 +381,11 @@ struct ftrace_graph_ret {
> int depth;
> };
>
> +struct ftrace_graph_switch {
> + pid_t prev, next;
> + u64 ran, since;
> +};
Does the above need to be in the global ftrace header? Can we stick it
into kernel/trace/trace.h?
> +
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>
> /*
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index f34cf42..fa477ac 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -530,7 +530,6 @@ update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
> schedstat_set(se->wait_count, se->wait_count + 1);
> schedstat_set(se->wait_sum, se->wait_sum +
> rq_of(cfs_rq)->clock - se->wait_start);
> - schedstat_set(se->wait_start, 0);
> }
>
> static inline void
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index dde1d46..7aa1c13 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -67,6 +67,7 @@ config FUNCTION_GRAPH_TRACER
> bool "Kernel Function Graph Tracer"
> depends on HAVE_FUNCTION_GRAPH_TRACER
> depends on FUNCTION_TRACER
> + select SCHEDSTATS
> default y
> help
> Enable the kernel to trace a function at both its return
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 2129ab9..380a334 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -31,6 +31,7 @@
> #include <linux/fs.h>
> #include <linux/kprobes.h>
> #include <linux/writeback.h>
> +#include <linux/sched.h>
>
> #include <linux/stacktrace.h>
> #include <linux/ring_buffer.h>
> @@ -820,6 +821,35 @@ static void __trace_graph_return(struct trace_array *tr,
> entry->ret = *trace;
> ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
> }
> +
> +static void __trace_graph_switch(struct trace_array *tr,
> + struct trace_array_cpu *data,
> + unsigned long flags, int pc,
> + struct task_struct *prev,
> + struct task_struct *next)
> +{
BTW, I'm trying to get rid of functions from trace.c since it is starting
to become a dumping ground. It initially was because there was common
static functions that was only in trace.c. But since then, those static
functions became global. Could you move this into the
trace_function_graph.c file.
> + struct ring_buffer_event *event;
> + struct ftrace_graph_switch_entry *entry;
> + unsigned long irq_flags;
> +
> + if (unlikely(local_read(&__get_cpu_var(ftrace_cpu_disabled))))
> + return;
> +
> + event = ring_buffer_lock_reserve(global_trace.buffer, sizeof(*entry),
> + &irq_flags);
> + if (!event)
> + return;
> + entry = ring_buffer_event_data(event);
> + tracing_generic_entry_update(&entry->ent, flags, pc);
> + entry->ent.type = TRACE_GRAPH_SWITCH;
> + entry->ctx.prev = prev->pid;
> + entry->ctx.next = next->pid;
> + entry->ctx.ran = prev->se.sum_exec_runtime -
> + prev->se.prev_sum_exec_runtime;
> + entry->ctx.since = next->se.exec_start - next->se.wait_start;
> +
> + ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
> +}
> #endif
>
> void
> @@ -1097,6 +1127,27 @@ void trace_graph_return(struct ftrace_graph_ret *trace)
> atomic_dec(&data->disabled);
> local_irq_restore(flags);
> }
> +
> +void trace_graph_switch(struct task_struct *prev, struct task_struct *next)
> +{
> + struct trace_array *tr = &global_trace;
We could get this out of trace.c too, but we would need to assign the tr
to some saved off trace_array. global_trace is only for trace.c.
-- Steve
> + struct trace_array_cpu *data;
> + unsigned long flags;
> + long disabled;
> + int cpu;
> + int pc;
> +
> + local_irq_save(flags);
> + cpu = raw_smp_processor_id();
> + data = tr->data[cpu];
> + disabled = atomic_inc_return(&data->disabled);
> + if (likely(disabled == 1)) {
> + pc = preempt_count();
> + __trace_graph_switch(tr, data, flags, pc, prev, next);
> + }
> + atomic_dec(&data->disabled);
> + local_irq_restore(flags);
> +}
> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>
> enum trace_file_type {
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index b96037d..781fbce 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -27,6 +27,7 @@ enum trace_type {
> TRACE_BOOT_RET,
> TRACE_GRAPH_RET,
> TRACE_GRAPH_ENT,
> + TRACE_GRAPH_SWITCH,
> TRACE_USER_STACK,
> TRACE_HW_BRANCHES,
> TRACE_KMEM_ALLOC,
> @@ -71,6 +72,12 @@ struct ftrace_graph_ret_entry {
> struct trace_entry ent;
> struct ftrace_graph_ret ret;
> };
> +
> +struct ftrace_graph_switch_entry {
> + struct trace_entry ent;
> + struct ftrace_graph_switch ctx;
> +};
> +
> extern struct tracer boot_tracer;
>
> /*
> @@ -295,6 +302,8 @@ extern void __ftrace_bad_type(void);
> TRACE_GRAPH_ENT); \
> IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry, \
> TRACE_GRAPH_RET); \
> + IF_ASSIGN(var, ent, struct ftrace_graph_switch_entry, \
> + TRACE_GRAPH_SWITCH); \
> IF_ASSIGN(var, ent, struct hw_branch_entry, TRACE_HW_BRANCHES);\
> IF_ASSIGN(var, ent, struct trace_power, TRACE_POWER); \
> IF_ASSIGN(var, ent, struct kmemtrace_alloc_entry, \
> @@ -438,6 +447,7 @@ void trace_function(struct trace_array *tr,
>
> void trace_graph_return(struct ftrace_graph_ret *trace);
> int trace_graph_entry(struct ftrace_graph_ent *trace);
> +void trace_graph_switch(struct task_struct *prev, struct task_struct *next);
>
> void tracing_start_cmdline_record(void);
> void tracing_stop_cmdline_record(void);
> diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
> index 66fc7b8..cf6494b 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -10,6 +10,7 @@
> #include <linux/uaccess.h>
> #include <linux/ftrace.h>
> #include <linux/fs.h>
> +#include <trace/sched.h>
>
> #include "trace.h"
> #include "trace_output.h"
> @@ -158,28 +159,13 @@ print_graph_proc(struct trace_seq *s, pid_t pid)
> return TRACE_TYPE_HANDLED;
> }
>
> -
> -/* If the pid changed since the last trace, output this event */
> static enum print_line_t
> -verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> +print_graph_switch(struct ftrace_graph_switch_entry *field, struct trace_seq *s,
> + struct trace_iterator *iter)
> {
> - pid_t prev_pid;
> - pid_t *last_pid;
> + int cpu = iter->cpu;
> int ret;
>
> - if (!last_pids_cpu)
> - return TRACE_TYPE_HANDLED;
> -
> - last_pid = per_cpu_ptr(last_pids_cpu, cpu);
> -
> - if (*last_pid == pid)
> - return TRACE_TYPE_HANDLED;
> -
> - prev_pid = *last_pid;
> - *last_pid = pid;
> -
> - if (prev_pid == -1)
> - return TRACE_TYPE_HANDLED;
> /*
> * Context-switch trace line:
>
> @@ -197,7 +183,7 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> - ret = print_graph_proc(s, prev_pid);
> + ret = print_graph_proc(s, field->ctx.prev);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> @@ -205,16 +191,21 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> if (!ret)
> TRACE_TYPE_PARTIAL_LINE;
>
> - ret = print_graph_proc(s, pid);
> + ret = print_graph_proc(s, field->ctx.next);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> + ret = trace_seq_printf(s, " ran: %Lu, since: %Lu",
> + field->ctx.ran, field->ctx.since);
> + if (!ret)
> + TRACE_TYPE_PARTIAL_LINE;
> +
> ret = trace_seq_printf(s,
> "\n ------------------------------------------\n\n");
> if (!ret)
> TRACE_TYPE_PARTIAL_LINE;
>
> - return ret;
> + return TRACE_TYPE_HANDLED;
> }
>
> static bool
> @@ -471,14 +462,9 @@ print_graph_entry(struct ftrace_graph_ent_entry *field, struct trace_seq *s,
> {
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_entry = iter->private;
> struct trace_entry *ent = iter->ent;
> struct ftrace_graph_ent *call = &field->graph_ent;
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_entry) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
> -
> /* Interrupt */
> ret = print_graph_irq(s, call->func, TRACE_GRAPH_ENT, cpu, ent->pid);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> @@ -523,12 +509,8 @@ print_graph_return(struct ftrace_graph_ret *trace, struct trace_seq *s,
> int i;
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_pid = iter->private;
> unsigned long long duration = trace->rettime - trace->calltime;
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
>
> /* Absolute time */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
> @@ -600,7 +582,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
> int i;
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_pid = iter->private;
>
> /* Absolute time */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
> @@ -609,10 +590,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
> return TRACE_TYPE_PARTIAL_LINE;
> }
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
> -
> /* Cpu */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_CPU) {
> ret = print_graph_cpu(s, cpu);
> @@ -677,6 +654,11 @@ print_graph_function(struct trace_iterator *iter)
> struct trace_entry *entry = iter->ent;
>
> switch (entry->type) {
> + case TRACE_GRAPH_SWITCH: {
> + struct ftrace_graph_switch_entry *field;
> + trace_assign_type(field, entry);
> + return print_graph_switch(field, s, iter);
> + }
> case TRACE_GRAPH_ENT: {
> struct ftrace_graph_ent_entry *field;
> trace_assign_type(field, entry);
> @@ -724,34 +706,38 @@ static void print_graph_headers(struct seq_file *s)
> seq_printf(s, " | | | |\n");
> }
>
> -static void graph_trace_open(struct trace_iterator *iter)
> +static void probe_sched_switch(struct rq *rq,
> + struct task_struct *prev,
> + struct task_struct *next)
> {
> - /* pid on the last trace processed */
> - pid_t *last_pid = alloc_percpu(pid_t);
> - int cpu;
> + trace_graph_switch(prev, next);
> +}
>
> - if (!last_pid)
> - pr_warning("function graph tracer: not enough memory\n");
> - else
> - for_each_possible_cpu(cpu) {
> - pid_t *pid = per_cpu_ptr(last_pid, cpu);
> - *pid = -1;
> - }
> +static DEFINE_MUTEX(graph_trace_mutex);
> +static int graph_trace_ref;
>
> - iter->private = last_pid;
> +static void graph_trace_start(struct trace_array *tr)
> +{
> + mutex_lock(&graph_trace_mutex);
> + if (!(graph_trace_ref++))
> + register_trace_sched_switch(probe_sched_switch);
> + mutex_unlock(&graph_trace_mutex);
> }
>
> -static void graph_trace_close(struct trace_iterator *iter)
> +static void graph_trace_stop(struct trace_array *tr)
> {
> - percpu_free(iter->private);
> + mutex_lock(&graph_trace_mutex);
> + if (!(--graph_trace_ref))
> + unregister_trace_sched_switch(probe_sched_switch);
> + mutex_unlock(&graph_trace_mutex);
> }
>
> static struct tracer graph_trace __read_mostly = {
> .name = "function_graph",
> - .open = graph_trace_open,
> - .close = graph_trace_close,
> .init = graph_trace_init,
> .reset = graph_trace_reset,
> + .start = graph_trace_start,
> + .stop = graph_trace_stop,
> .print_line = print_graph_function,
> .print_header = print_graph_headers,
> .flags = &tracer_flags,
>
>
>
>
On Mon 2009-01-19 22:45:39, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12391
> Subject : Processor does not go below C2 state until usb.autosuspend is enabled
> Submitter : Gergely Imreh <[email protected]>
> Date : 2009-01-09 02:35 (11 days old)
Hmm? That would be quite expected behaviour. USB autosuspend is needed
for C3... (as soon as any USB device is plugged in, at least). Can you
doublecheck that 2.6.27 could run with C3 with active USB? That would
be small miracle...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Fix upstream in tip/x86/urgent:
780eef9492b16a1543a3b2ae9f9526a735fc9856
-Robert
On 23.02.09 23:03:00, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.27 and 2.6.28.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.27 and 2.6.28. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12395
> Subject : 2.6.28-rc9: oprofile regression
> Submitter : Tim Blechmann <[email protected]>
> Date : 2008-12-21 14:23 (65 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b99170288421c79f0c2efa8b33e26e65f4bb7fb8
> References : http://marc.info/?l=linux-kernel&m=122986946614791&w=4
> Handled-By : Andi Kleen <[email protected]>
>
>
>
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: [email protected]
On Tuesday 03 March 2009, Robert Richter wrote:
> Fix upstream in tip/x86/urgent:
>
> 780eef9492b16a1543a3b2ae9f9526a735fc9856
URL, please?
Rafael
> On 23.02.09 23:03:00, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.27 and 2.6.28.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.27 and 2.6.28. Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12395
> > Subject : 2.6.28-rc9: oprofile regression
> > Submitter : Tim Blechmann <[email protected]>
> > Date : 2008-12-21 14:23 (65 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b99170288421c79f0c2efa8b33e26e65f4bb7fb8
> > References : http://marc.info/?l=linux-kernel&m=122986946614791&w=4
> > Handled-By : Andi Kleen <[email protected]>
* Rafael J. Wysocki <[email protected]> wrote:
> On Tuesday 03 March 2009, Robert Richter wrote:
> > Fix upstream in tip/x86/urgent:
> >
> > 780eef9492b16a1543a3b2ae9f9526a735fc9856
>
> URL, please?
The fix is not yet in Linus's tree - the commit is below.
Ingo
------------>
>From 780eef9492b16a1543a3b2ae9f9526a735fc9856 Mon Sep 17 00:00:00 2001
From: Tim Blechmann <[email protected]>
Date: Thu, 19 Feb 2009 17:34:03 +0100
Subject: [PATCH] x86: oprofile: don't set counter width from cpuid on Core2
Impact: fix stuck NMIs and non-working oprofile on certain CPUs
Resetting the counter width of the performance counters on Intel's
Core2 CPUs, breaks the delivery of NMIs, when running in x86_64 mode.
This should fix bug #12395:
http://bugzilla.kernel.org/show_bug.cgi?id=12395
Signed-off-by: Tim Blechmann <[email protected]>
Signed-off-by: Robert Richter <[email protected]>
LKML-Reference: <[email protected]>
Cc: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/oprofile/op_model_ppro.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/oprofile/op_model_ppro.c b/arch/x86/oprofile/op_model_ppro.c
index e9f80c7..10131fb 100644
--- a/arch/x86/oprofile/op_model_ppro.c
+++ b/arch/x86/oprofile/op_model_ppro.c
@@ -78,8 +78,18 @@ static void ppro_setup_ctrs(struct op_msrs const * const msrs)
if (cpu_has_arch_perfmon) {
union cpuid10_eax eax;
eax.full = cpuid_eax(0xa);
- if (counter_width < eax.split.bit_width)
- counter_width = eax.split.bit_width;
+
+ /*
+ * For Core2 (family 6, model 15), don't reset the
+ * counter width:
+ */
+ if (!(eax.split.version_id == 0 &&
+ current_cpu_data.x86 == 6 &&
+ current_cpu_data.x86_model == 15)) {
+
+ if (counter_width < eax.split.bit_width)
+ counter_width = eax.split.bit_width;
+ }
}
/* clear all counters */
On Tuesday 03 March 2009, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[email protected]> wrote:
>
> > On Tuesday 03 March 2009, Robert Richter wrote:
> > > Fix upstream in tip/x86/urgent:
> > >
> > > 780eef9492b16a1543a3b2ae9f9526a735fc9856
> >
> > URL, please?
>
> The fix is not yet in Linus's tree - the commit is below.
Thanks a lot!
Rafael
* Ingo Molnar <[email protected]> wrote:
>
> * Rafael J. Wysocki <[email protected]> wrote:
>
> > On Tuesday 03 March 2009, Robert Richter wrote:
> > > Fix upstream in tip/x86/urgent:
> > >
> > > 780eef9492b16a1543a3b2ae9f9526a735fc9856
> >
> > URL, please?
>
> The fix is not yet in Linus's tree - the commit is below.
The fix is upstream now, included in .29-rc7.
Ingo
On Wednesday 04 March 2009, Ingo Molnar wrote:
>
> * Ingo Molnar <[email protected]> wrote:
>
> >
> > * Rafael J. Wysocki <[email protected]> wrote:
> >
> > > On Tuesday 03 March 2009, Robert Richter wrote:
> > > > Fix upstream in tip/x86/urgent:
> > > >
> > > > 780eef9492b16a1543a3b2ae9f9526a735fc9856
> > >
> > > URL, please?
> >
> > The fix is not yet in Linus's tree - the commit is below.
>
> The fix is upstream now, included in .29-rc7.
Thanks, closed.
Rafael
On Mon, Jan 26, 2009 at 03:38:12PM +0100, Peter Zijlstra wrote:
> On Mon, 2009-01-26 at 12:35 +0100, Peter Zijlstra wrote:
> >
> > Another something nice would be to have ctx switches like:
> >
> > foo-1 => bar-2 ran: ${time foo spend on the cpu} since: ${time bar
> > spend away from the cpu}
>
> Steve, Frederic, how's this?
>
> (compile tested only)
Hi Peter,
This patch was very useful. Would you still like to post
an updated one?
May be this feature could be a separate option so that we can
select it only when needed.
Thanks,
Frederic.
> ---
> include/linux/ftrace.h | 5 ++
> kernel/sched_fair.c | 1 -
> kernel/trace/Kconfig | 1 +
> kernel/trace/trace.c | 51 +++++++++++++++++++
> kernel/trace/trace.h | 10 ++++
> kernel/trace/trace_functions_graph.c | 88 ++++++++++++++-------------------
> 6 files changed, 104 insertions(+), 52 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 9f7880d..411b027 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -381,6 +381,11 @@ struct ftrace_graph_ret {
> int depth;
> };
>
> +struct ftrace_graph_switch {
> + pid_t prev, next;
> + u64 ran, since;
> +};
> +
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>
> /*
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index f34cf42..fa477ac 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -530,7 +530,6 @@ update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
> schedstat_set(se->wait_count, se->wait_count + 1);
> schedstat_set(se->wait_sum, se->wait_sum +
> rq_of(cfs_rq)->clock - se->wait_start);
> - schedstat_set(se->wait_start, 0);
> }
>
> static inline void
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index dde1d46..7aa1c13 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -67,6 +67,7 @@ config FUNCTION_GRAPH_TRACER
> bool "Kernel Function Graph Tracer"
> depends on HAVE_FUNCTION_GRAPH_TRACER
> depends on FUNCTION_TRACER
> + select SCHEDSTATS
> default y
> help
> Enable the kernel to trace a function at both its return
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 2129ab9..380a334 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -31,6 +31,7 @@
> #include <linux/fs.h>
> #include <linux/kprobes.h>
> #include <linux/writeback.h>
> +#include <linux/sched.h>
>
> #include <linux/stacktrace.h>
> #include <linux/ring_buffer.h>
> @@ -820,6 +821,35 @@ static void __trace_graph_return(struct trace_array *tr,
> entry->ret = *trace;
> ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
> }
> +
> +static void __trace_graph_switch(struct trace_array *tr,
> + struct trace_array_cpu *data,
> + unsigned long flags, int pc,
> + struct task_struct *prev,
> + struct task_struct *next)
> +{
> + struct ring_buffer_event *event;
> + struct ftrace_graph_switch_entry *entry;
> + unsigned long irq_flags;
> +
> + if (unlikely(local_read(&__get_cpu_var(ftrace_cpu_disabled))))
> + return;
> +
> + event = ring_buffer_lock_reserve(global_trace.buffer, sizeof(*entry),
> + &irq_flags);
> + if (!event)
> + return;
> + entry = ring_buffer_event_data(event);
> + tracing_generic_entry_update(&entry->ent, flags, pc);
> + entry->ent.type = TRACE_GRAPH_SWITCH;
> + entry->ctx.prev = prev->pid;
> + entry->ctx.next = next->pid;
> + entry->ctx.ran = prev->se.sum_exec_runtime -
> + prev->se.prev_sum_exec_runtime;
> + entry->ctx.since = next->se.exec_start - next->se.wait_start;
> +
> + ring_buffer_unlock_commit(global_trace.buffer, event, irq_flags);
> +}
> #endif
>
> void
> @@ -1097,6 +1127,27 @@ void trace_graph_return(struct ftrace_graph_ret *trace)
> atomic_dec(&data->disabled);
> local_irq_restore(flags);
> }
> +
> +void trace_graph_switch(struct task_struct *prev, struct task_struct *next)
> +{
> + struct trace_array *tr = &global_trace;
> + struct trace_array_cpu *data;
> + unsigned long flags;
> + long disabled;
> + int cpu;
> + int pc;
> +
> + local_irq_save(flags);
> + cpu = raw_smp_processor_id();
> + data = tr->data[cpu];
> + disabled = atomic_inc_return(&data->disabled);
> + if (likely(disabled == 1)) {
> + pc = preempt_count();
> + __trace_graph_switch(tr, data, flags, pc, prev, next);
> + }
> + atomic_dec(&data->disabled);
> + local_irq_restore(flags);
> +}
> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>
> enum trace_file_type {
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index b96037d..781fbce 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -27,6 +27,7 @@ enum trace_type {
> TRACE_BOOT_RET,
> TRACE_GRAPH_RET,
> TRACE_GRAPH_ENT,
> + TRACE_GRAPH_SWITCH,
> TRACE_USER_STACK,
> TRACE_HW_BRANCHES,
> TRACE_KMEM_ALLOC,
> @@ -71,6 +72,12 @@ struct ftrace_graph_ret_entry {
> struct trace_entry ent;
> struct ftrace_graph_ret ret;
> };
> +
> +struct ftrace_graph_switch_entry {
> + struct trace_entry ent;
> + struct ftrace_graph_switch ctx;
> +};
> +
> extern struct tracer boot_tracer;
>
> /*
> @@ -295,6 +302,8 @@ extern void __ftrace_bad_type(void);
> TRACE_GRAPH_ENT); \
> IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry, \
> TRACE_GRAPH_RET); \
> + IF_ASSIGN(var, ent, struct ftrace_graph_switch_entry, \
> + TRACE_GRAPH_SWITCH); \
> IF_ASSIGN(var, ent, struct hw_branch_entry, TRACE_HW_BRANCHES);\
> IF_ASSIGN(var, ent, struct trace_power, TRACE_POWER); \
> IF_ASSIGN(var, ent, struct kmemtrace_alloc_entry, \
> @@ -438,6 +447,7 @@ void trace_function(struct trace_array *tr,
>
> void trace_graph_return(struct ftrace_graph_ret *trace);
> int trace_graph_entry(struct ftrace_graph_ent *trace);
> +void trace_graph_switch(struct task_struct *prev, struct task_struct *next);
>
> void tracing_start_cmdline_record(void);
> void tracing_stop_cmdline_record(void);
> diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
> index 66fc7b8..cf6494b 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -10,6 +10,7 @@
> #include <linux/uaccess.h>
> #include <linux/ftrace.h>
> #include <linux/fs.h>
> +#include <trace/sched.h>
>
> #include "trace.h"
> #include "trace_output.h"
> @@ -158,28 +159,13 @@ print_graph_proc(struct trace_seq *s, pid_t pid)
> return TRACE_TYPE_HANDLED;
> }
>
> -
> -/* If the pid changed since the last trace, output this event */
> static enum print_line_t
> -verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> +print_graph_switch(struct ftrace_graph_switch_entry *field, struct trace_seq *s,
> + struct trace_iterator *iter)
> {
> - pid_t prev_pid;
> - pid_t *last_pid;
> + int cpu = iter->cpu;
> int ret;
>
> - if (!last_pids_cpu)
> - return TRACE_TYPE_HANDLED;
> -
> - last_pid = per_cpu_ptr(last_pids_cpu, cpu);
> -
> - if (*last_pid == pid)
> - return TRACE_TYPE_HANDLED;
> -
> - prev_pid = *last_pid;
> - *last_pid = pid;
> -
> - if (prev_pid == -1)
> - return TRACE_TYPE_HANDLED;
> /*
> * Context-switch trace line:
>
> @@ -197,7 +183,7 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> - ret = print_graph_proc(s, prev_pid);
> + ret = print_graph_proc(s, field->ctx.prev);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> @@ -205,16 +191,21 @@ verif_pid(struct trace_seq *s, pid_t pid, int cpu, pid_t *last_pids_cpu)
> if (!ret)
> TRACE_TYPE_PARTIAL_LINE;
>
> - ret = print_graph_proc(s, pid);
> + ret = print_graph_proc(s, field->ctx.next);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> TRACE_TYPE_PARTIAL_LINE;
>
> + ret = trace_seq_printf(s, " ran: %Lu, since: %Lu",
> + field->ctx.ran, field->ctx.since);
> + if (!ret)
> + TRACE_TYPE_PARTIAL_LINE;
> +
> ret = trace_seq_printf(s,
> "\n ------------------------------------------\n\n");
> if (!ret)
> TRACE_TYPE_PARTIAL_LINE;
>
> - return ret;
> + return TRACE_TYPE_HANDLED;
> }
>
> static bool
> @@ -471,14 +462,9 @@ print_graph_entry(struct ftrace_graph_ent_entry *field, struct trace_seq *s,
> {
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_entry = iter->private;
> struct trace_entry *ent = iter->ent;
> struct ftrace_graph_ent *call = &field->graph_ent;
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_entry) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
> -
> /* Interrupt */
> ret = print_graph_irq(s, call->func, TRACE_GRAPH_ENT, cpu, ent->pid);
> if (ret == TRACE_TYPE_PARTIAL_LINE)
> @@ -523,12 +509,8 @@ print_graph_return(struct ftrace_graph_ret *trace, struct trace_seq *s,
> int i;
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_pid = iter->private;
> unsigned long long duration = trace->rettime - trace->calltime;
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
>
> /* Absolute time */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
> @@ -600,7 +582,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
> int i;
> int ret;
> int cpu = iter->cpu;
> - pid_t *last_pid = iter->private;
>
> /* Absolute time */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_ABS_TIME) {
> @@ -609,10 +590,6 @@ print_graph_comment(struct print_entry *trace, struct trace_seq *s,
> return TRACE_TYPE_PARTIAL_LINE;
> }
>
> - /* Pid */
> - if (verif_pid(s, ent->pid, cpu, last_pid) == TRACE_TYPE_PARTIAL_LINE)
> - return TRACE_TYPE_PARTIAL_LINE;
> -
> /* Cpu */
> if (tracer_flags.val & TRACE_GRAPH_PRINT_CPU) {
> ret = print_graph_cpu(s, cpu);
> @@ -677,6 +654,11 @@ print_graph_function(struct trace_iterator *iter)
> struct trace_entry *entry = iter->ent;
>
> switch (entry->type) {
> + case TRACE_GRAPH_SWITCH: {
> + struct ftrace_graph_switch_entry *field;
> + trace_assign_type(field, entry);
> + return print_graph_switch(field, s, iter);
> + }
> case TRACE_GRAPH_ENT: {
> struct ftrace_graph_ent_entry *field;
> trace_assign_type(field, entry);
> @@ -724,34 +706,38 @@ static void print_graph_headers(struct seq_file *s)
> seq_printf(s, " | | | |\n");
> }
>
> -static void graph_trace_open(struct trace_iterator *iter)
> +static void probe_sched_switch(struct rq *rq,
> + struct task_struct *prev,
> + struct task_struct *next)
> {
> - /* pid on the last trace processed */
> - pid_t *last_pid = alloc_percpu(pid_t);
> - int cpu;
> + trace_graph_switch(prev, next);
> +}
>
> - if (!last_pid)
> - pr_warning("function graph tracer: not enough memory\n");
> - else
> - for_each_possible_cpu(cpu) {
> - pid_t *pid = per_cpu_ptr(last_pid, cpu);
> - *pid = -1;
> - }
> +static DEFINE_MUTEX(graph_trace_mutex);
> +static int graph_trace_ref;
>
> - iter->private = last_pid;
> +static void graph_trace_start(struct trace_array *tr)
> +{
> + mutex_lock(&graph_trace_mutex);
> + if (!(graph_trace_ref++))
> + register_trace_sched_switch(probe_sched_switch);
> + mutex_unlock(&graph_trace_mutex);
> }
>
> -static void graph_trace_close(struct trace_iterator *iter)
> +static void graph_trace_stop(struct trace_array *tr)
> {
> - percpu_free(iter->private);
> + mutex_lock(&graph_trace_mutex);
> + if (!(--graph_trace_ref))
> + unregister_trace_sched_switch(probe_sched_switch);
> + mutex_unlock(&graph_trace_mutex);
> }
>
> static struct tracer graph_trace __read_mostly = {
> .name = "function_graph",
> - .open = graph_trace_open,
> - .close = graph_trace_close,
> .init = graph_trace_init,
> .reset = graph_trace_reset,
> + .start = graph_trace_start,
> + .stop = graph_trace_stop,
> .print_line = print_graph_function,
> .print_header = print_graph_headers,
> .flags = &tracer_flags,
>
>